Web Services - a specification or a framework or ...

[HS Thomas]

How should Web Services be viewed and what goes to make it up?
SOAP, XML , JAX-RPC or JAXM, EJB as a first stab.
regards
[ May 15, 2003: Message edited by: HS Thomas ]

[HS Thomas]

Hi,
Is it XML standards that provides the glue between the different technologies ?
regards

[srinivasrao marri]

A webservice should be viewed as a business logic where it can be used by anyone in distributed environment. SOAP, WSDL and RPC mechnisms are making this possible.

[JeanLouis Marechaux]

Definition from Gartner :
Gartner 2001 : �Web Services are loosely coupled software components delivered over Internet standard technologies�
Ok, I acknowledge this definition does not help a lot :roll:
Maybe you can see WebServices as a bunch of technologies :
XML (Extensible Markup Language)
SOAP (Simple Object Access Protocol)
WSDL (Web Services Description Language)
UDDI (Universal Description, Discovery, Integration)

but I disagree to add EJBs, JAX-RPC or JAXM which are Java specific, while WebServices are all about interoperability
[ May 15, 2003: Message edited by: Jean-Louis Marechaux ]

[HS Thomas]

Thanks srinivasrao and Jean-Loius.
Another simple (naive) question.
Does each component have a single request / response from a Web service provider or can it have many requests and responses from many Web Service providers.
How simple is it to design a Web Service component from a re-usability and replacability
standpoint (if you want to switch Web Service providers).
regards
[ May 15, 2003: Message edited by: HS Thomas ]

[Lasse Koskela]

Originally posted by HS Thomas:
Does each component have a single request / response from a Web service provider or can it have many requests and responses from many Web Service providers.

I assume that by "each component" you are referring to the client calling a web service...
Regarding the single/multiple request/responses, the client needs to repeat the request to each deployed service in order to solicit a response. You send one, you get one back. Unless you call an aggregating service, which forwards the request to several service providers, combines the responses and sends them back to the client as a single response (but again you're technically getting only one response back).

Originally posted by HS Thomas:
How simple is it to design a Web Service component from a re-usability and replacability
standpoint (if you want to switch Web Service providers).

Are you talking about switching the vendor of the platform on which you are deploying your web service or about switching your web service client to use another web service provider?
The former should become a lot easier along with J2EE 1.4, which incorporates JAXRPC to appservers. The latter is totally dependent on the interfaces your service providers are exposing. If they all provide some industry standard interface for, say, getting a stock quote, then the switch should be just about changing URLs. If they provide the same logical service (stock quotes) with different interfaces (different WSDLs), you should probably write an intermediate adapter to encapsulate the anticipated future changes into that component and avoid touching every client using the stock quote service(s).

[srinivasrao marri]

request/response of a webservice will happen one way only. once u register a webservice, ur component wont sits in the registry server. The registry server gives only description of the webservice i.e thru wsdl and the actual component sits in the service creator server. U can modify or replace the service without changing the signatures of the business logic. i hope this answers ur question.
[ May 15, 2003: Message edited by: srinivasrao marri ]

[HS Thomas]

Thanks Lasse and srinivasrao .Your explanation goes a long way in helping understand.
quoted by Lasse :

If they provide the same logical service (stock quotes) with different interfaces (different WSDLs), you should probably write an intermediate adapter to encapsulate the anticipated future changes into that component and avoid touching every client using the stock quote service(s).

quoted by srinivasrao :

The registry server gives only description of the webservice i.e thru wsdl and the actual component sits in the service creator server. U can modify or replace the service without changing the signatures of the business logic. i hope this answers ur question.

I expect Standardized business logic interfaces will do away with the need for adapters , hence it should be relatively easy to switch Services.
You seem to both in agreement. But existing interfaces , may require adapters to be plugged in.
Lasse, I am surprised that there is an issue with which Platforms provide the service. Is this technology not Platform independent ? Oh , I see now that you said switching the vendor will depend on whether the vendor platform uses JAX/RPC.

regards
[ May 16, 2003: Message edited by: HS Thomas ]

[HS Thomas]

Hi , I understand that only certain kinds of business logic are suitable to be encapsulated in a Web Service.
As businesses need to differentiate to be competitive , how do Business Analysts cope with the differentiation. Are they likely to be surfing certain vendor friendly registries and picking up components then discuss which ones to test /adopt/reject.
How do you tell whether a component is good or bad without testing it with users first. And if it is rejected - the business writes it's own ?
More interestingly , how does a Web Service provider cope with change requests - write a new component? I guess they wouldn't want to provide components for business logic that differentiates your business - ie no one else is likely to want (so it's not cost-effective) or your business would likely want publicised (in order to stay competitive).
Or turning that on its head, if the business is in partnerships with companies , they may want to share rather more logic and hence it would be cost-effective..
But for that are you better off using EJBs, that gives the partnerships some degree of control.
This is all very confusing.
I guess there are global savings somewhere along the line...
regards
[ May 19, 2003: Message edited by: HS Thomas ]

[Lasse Koskela]

Originally posted by HS Thomas:
Lasse, I am surprised that there is an issue with which Platforms provide the service. Is this technology not Platform independent ? Oh , I see now that you said switching the vendor will depend on whether the vendor platform uses JAX/RPC.

I didn't mean that JAX-RPC was the only standard. It's just officially supported by the next J2EE specification. Application servers will support other WS invocation models as well (they need to in order to keep/gain market share). So in that sense JAX-RPC would be a safe choice but not the only one.

[Lasse Koskela]

Originally posted by HS Thomas:
As businesses need to differentiate to be competitive , how do Business Analysts cope with the differentiation. Are they likely to be surfing certain vendor friendly registries and picking up components then discuss which ones to test/adopt/reject.

Well, this (business analyst surfing a registry) is the envisioned way of finding and starting to use 3rd party web services. We'll see if it works out that way...

How do you tell whether a component is good or bad without testing it with users first. And if it is rejected - the business writes it's own ?

One key to large-scale component based development in an organization is the standardization of component interfaces and component descriptions. The fact is, you can't really compare components except based on what their creator says in the documentation. The only viable way to select components would therefore be a two-step process: first scramble a short list, then examine (test if necessary) those few in more detail.

More interestingly , how does a Web Service provider cope with change requests - write a new component? I guess they wouldn't want to provide components for business logic that differentiates your business - ie no one else is likely to want (so it's not cost-effective) or your business would likely want publicised (in order to stay competitive).
Or turning that on its head, if the business is in partnerships with companies , they may want to share raher more logic and hence it would be cost-effective..
But for that are you better off using EJBs, that gives the partnerships some degree of control.

Now we're entering the world of the dreaded Business Case... In fact, this has nothing to do with web services -- it's just a way to expose the "differentiating" services.
For example, Amazon provides a free web service, related to browsing/searching its online catalog. Why are they doing this? To stay in the lead. To keep that money flowing. If there is a change request from the customer (that being potential buyers), Amazon needs to make a judgement whether the requested feature is worth the trouble. Increased user base vs increased costs. This differs in no way from change request processes in other fields of software.

[HS Thomas]

Thanks Lasse.
How difficult is the following likely to be :
Is there a standard process to achieve this?

One key to large-scale component based development in an organization is the standardization of component interfaces and component descriptions.

By component descriptions do you mean just the name and what objects make up the response ?

For example, Amazon provides a free web service, related to browsing/searching its online catalog.

But Amazon has been around for a while . Before the term "Web Service" was coined. What can Amazon do with the new Web Services that it couldn't do before? Or perhaps they are taking a true component-based development approach.
Can you now use Web Services in secure transactions ?
regards
[ May 17, 2003: Message edited by: HS Thomas ]

[Lasse Koskela]

How difficult is the following likely to be :
Is there a standard process to achieve this?
One key to large-scale component based development in an organization is the standardization of component interfaces and component descriptions.

Unfortunately successful component-based development is pretty rare. Depending on the industry, though. Electronics manufacturers' software development organizations have been the groundbreakers in CBD (component based dev) as their product line-oriented business supports the scheme well. However, this is not the case with, say, web application development. There is only so much reuse that can be done (and most of that is done by the appserver/webserver vendor already for you).
There are really no standards for component based development, that is, unless you count EJB/COM/CORBA/WS, which support CBD by means of encapsulation of business logic. There are some organizational management approaches for CBD however. Perhaps the most common is the Experience Factory, which is basically an organization separate from a project organization (which brings in the dough) and from which the project organizations get ready-to-use components if applicable. The projects in turn contribute their development to the Experience Factory which generalizes the input into reusable components.
Ok. That was a mess. You better go Google if you're interested about EF...

By component descriptions do you mean just the name and what objects make up the response ?

No, not just those. In CBD a component is much more than a piece of code, although sometimes it can be just that. A component might consist of the compiled code, source code, user documentation, technical documentation, etc.
What I especially meant by "component descriptions" was some kind of a corporate standard template which eases the job of the project architect when she browses the component library.

But Amazon has been around for a while . Before the term "Web Service" was coined. What can Amazon do with the new Web Services that it couldn't do before? Or perhaps they are taking a true component-based development approach.

Well, before web services they would've needed to do proprietary integrations. Now? Now they publish a WSDL and willing parties can use off-the-shelf IDEs to generate client proxies.

Can you now use Web Services in secure transactions ?

Yes, you can. There is a 'but' however. There are a couple of competing wannabe standards (from different standard organizations) for implementing the security, so you either need to be confident enough to pick one or possibly maintain several web service interfaces for the different encryption/authentication standards.

[HS Thomas]

Thanks Lasse.
I've had some very limited exposure to rapid development along with CBD. Looked at some links on EF and can't see anything that's blindingly new. Re-use has been around for some time in some form. Paper files to Computer Files to relational databases increased re-use . EJBs and Web Services and the underlying network infra-structure are taking re-usability to a new level.
Experience Factory
And as you said:

No, not just those. In CBD a component is much more than a piece of code, although sometimes it can be just that. A component might consist of the compiled code, source code, user documentation, technical documentation, etc.

I suppose you can have a simple CBD model to a more complex CBD models. Has the Experience Factory thrown up any current and mature CBD models that are publicly available?
regards
[ May 19, 2003: Message edited by: HS Thomas ]

[Lasse Koskela]

Originally posted by HS Thomas:
Has the Experience Factory thrown up any current mature CBD models that are publicly available?

I don't work with process improvement directly so I have limited exposure to developments in that area (i.e. what I know is based on literature, not first hand experience).
What exactly do you mean by "throwing up a current mature CBD model"?

[HS Thomas]

Well, imagine this scenario.
A global company has operations on several continents , in several countries.
To support the operations it has different systems on different platforms integrated by reusable databases , files , CGI , dedicated network links, etc.
The strategic arm of the company wants to integrate some of it's operations and have been told that Web Services is the way to achieve this. Experience has taught them that the best way to go about it is to use their existing
Experience Factory :
quoted from Lasse's post

which is basically an organization separate from a project organization (which brings in the dough) and from which the project organizations get ready-to-use components if applicable. The projects in turn contribute their development to the Experience Factory which generalizes the input into reusable components.

The Experience Factory then picks up the current existing model and starts adding new strategy directives (use Java) and standards(enforce Java programming standards) to the list.
One project organization A bounces back with "We do not want to use Java 'cos there are rubbish Java development platforms out there and we prefer to use C#- with better development platforms" .The project org also wants to buy some time as they have no idea what to do with Java and are not really switched on to OO - hence the move to continue developing green screens and reports.)
But project organisation B sees past the temporary irritants . Write their own development tools , re-usable business logic , really start flying with massive project savings.
The Experience Factory adds this experience to the model - looks for IDE's that match these experience and sends out a strategic directive to use these IDE's , train staff in OO and particular methodologies.
And the continous process continues. (life goes on meanwhile between strategic directives)
The lazy approach would be to latch onto one of these models , get/have the know-how to get going with Web Services development and miss out on life experiences (Sad , sad people).Personally, I'd miss the confrontations and emotional see-saws, bonding, that gets one clinging to a project / idea and what a project organisation thrives on.

I believe there are some companies that have achieved the highest capability currently possible with Web Services.
It would be nice to see what the re-usable essentials (common shared experiences )are to get going with CBD .These may even set the standards for future development. Bits of the model may even help a project to get going with OO.
regards
[ May 19, 2003: Message edited by: HS Thomas ]

[Lasse Koskela]

In my opinion, the Experience Factory should not "send out directives" at all. Their responsibility is to maintain a library of reusable assets (and assist in choosing among them but the choice should be made by the project).
What you said about missing the see-saw's is a problem. It's about change management. Everybody (well, almost) knows that they should reuse if feasible, but in my experience the developer is often too keen on DIY and insists on reinventing the wheel. The solution is to teach the staff about the benefits of component-based reuse etc., and promote professionalism instead of guruism. Easier said than done...
[ May 19, 2003: Message edited by: Lasse Koskela ]

[HS Thomas]

In my opinion, the Experience Factory should not "send out directives" at all. Their responsibility is to maintain a library of reusable assets (and assist in choosing among them but the choice should be made by the project).

The Experience Factory I was talking about was in terms of a globally led Company which may mean directives are required but if a project organization achieves the goal by some other means , that will be added to the EF knowledge base. Other directives e.g to release funding may follow.
The Experience Factory I think you mean is the seller of Web Services. And the components are there available for re-use at the projects discretion.
It seems that it is not easy to introduce Web Services technology in a piecemeal fashion, as the technology may be defined by the vendor providing the development platform.
As far as developers doing DIY ,that gradually will get less as development gets more hide-bound by the chosen development platform to promote re-usability.
But it would be useful to keep your developers DIYing.( for e.g the Top-Coder site)
Question is Does the business get more hide-bound to the Web Service provider?
Difficult trying to imagine what the new breed of Business Analyst is likely to be. Try slapping some business contexts on the components descriptions you see on the Top Coder site. I find that very difficult but then I'm only partially OO.
In my opinion, a DIYing developer and DIYing Business Analyst seems to be the way to start, providing an in-house Web Service components for internal re-use if that's possible.
The directives used in my example of EF(globally led company -
management strategists ---> leaders ----> change managers) could be applied in the in-house Web Services scenario).
What do you think?
regards
[ May 19, 2003: Message edited by: HS Thomas ]

[Lasse Koskela]

Originally posted by HS Thomas:
The Experience Factory I think you mean is the seller of Web Services. And the components are there available for re-use at the projects discretion.
It seems that it is not easy to introduce Web Services technology in a piecemeal fashion, as the technology may be defined by the vendor providing the development platform.

No, I was talking about a classical EF not related to selling anything at all. The Experience Factory has been developed for internal reuse. A company selling web services (hosting or giving away compiled/source code) can use an EF type of support organization to implement component reuse internally but that doesn't show to customers in any way except, hopefully, increased quality and faster time-to-market of new web service offerings.

As far as developers doing DIY ,that gradually will get less as development gets more hide-bound by the chosen development platform to promote re-usability.

True. But DIY won't die completely, I presume, it just moves across abstraction levels. Yesterday a developer insisted on writing his own HTTP server, today the developer insists on writing his own application server, and tomorrow it's the business process engine... Maybe I'm a bit too pessimistic.

But it would be useful to keep your developers DIYing.( for e.g the Top-Coder site)

...and it would be useful to keep your developers from dying as well

Question is Does the business get more hide-bound to the Web Service provider?

What do you mean? Could you elaborate a bit more cause I'm not following you here...

Difficult trying to imagine what the new breed of Business Analyst is likely to be. Try slapping some business contexts on the components descriptions you see on the Top Coder site. I find that very difficult but then I'm only partially OO.

Web Services by itself won't allow "business analysts" to assemble applications from (ws-)components. The creation of business process language standards and libraries (both code libraries and vocabularies) is envisioned to give a boost to business application integration and the like.
It could be something like this (and this is purely fiction):
1. The business analyst, with a degree in economics or business administration or whatever, browses a public registry of available service providers.
2. She finds a service provider who claims to provide the wanted service supporting the BPEL4WS specification (Business Process Execution Language for Web Services) and the purchase order templates defined by RosettaNet PIP number 1234.
3. She checks that BPEL4WS and the PIP number match the ones given to her by the technical staff (who know how their own application is built and which standards they support).
4. She finds that the service pricing/licensing fits the budget and pushes the button. Component selected.
There are some pigholes in here alright. For example, why would the business analyst be given the task of finding suitable business logic components if she doesn't know enough about the technology to make choices beyond simple, manual "regexping?" It might very well be that the business analyst only produces a list of products/services which claim to match the functionality and leaves validation for the technical staff.
Well, in any case this will be an interesting show to watch... I can't wait to see what will happen during the mid-00's.

In my opinio, a DIYing developer and DIYing Business Analyst seems to be the way to start, providing an in-house Web Service components for internal re-use if that's possible.

Yep. That's the currently most viable application of Web Services and reuse as we know it -- in-house web services components.

[HS Thomas]

Thanks Lasse,

...and it would be useful to keep your developers from dying as well

nothing that a regular injection of cash and other factors in the emotional see-saw won't cure(other than death). It amazes me how the Top-Coder site has grown so quickly. I haven't heard of any of their developers making a fortune though. So it isn't pure greed. Nice source of a regular income and fed egos as they compete for rankings. The sites developers may have a killer application or two and are making a fortune . Companies do source some projects from there also.

quote:
--------------------------------------------------------------------------------
Question is Does the business get more hide-bound to the Web Service provider?
--------------------------------------------------------------------------------
What do you mean? Could you elaborate a bit more cause I'm not following you here...

You've answered this question with the Business Analyst scenario. I thought there was a danger of falling into the trap of serving the interests of the vendor and not the business.
As long as they are kept focused on the business goals , with a clear separation between the implementation.
Some physical separation may be called for too. Many a time has there been a BA involved in change management breathing down a developers neck making sure that he/she has got it just right for the following night's software release.

Thanks Lasse, You have been really helpful and covered a lot of ground. Enough to know what to watch out for. Getting a handle on WS feels a bit like getting into a Time Machine and hope you can forcast the future.
regards
[ May 19, 2003: Message edited by: HS Thomas ]

[Lasse Koskela]

Thanks to you as well. These discussions really force me to think and rethink my views from time to time.