As a service provider and service consumer

[Mike Thomson]

Everyone is trying with following example for starting web service:
http://www.onjava.com/lpt/a/1578

With respect to this:

As a service provider of fibonacci service:

1. Writes an interface and its implemenation
2. Using Axis Java2WSDL tool, generates the WSDL file from the above interface/implemenation
3. Generates the Server side coding from generated WSDL using WDL2Java.
DOUBT: Whether I need to konw in and out of all the details like Service, ServiceLocatort, Stub. Actually what these files are doing?
4. Deploy the service in the tomcat server.
5. Send the WSDL alone to the client thru mail / posint the wsdl itself in UDDI.
DOUBT: Whether as a service provider semding the WSDL is enough for the client to access the service or the client required any other details other than WSDL file

As a service consumer (client):

1. Retrieve the WSDL from email / from UDDI
2. Write the client program accoring to the WSDL and inovke the required service.
DOUBT: Client will have only the WSDL file. Is't correct? or whether the client will know all the package structure and how it is deployed in the service provider side?

[Peer Reynders]

Originally posted by Mike Thomson:
DOUBT: Whether I need to konw in and out of all the details like Service, ServiceLocatort, Stub. Actually what these files are doing?[/b]

Look at the client code (FibonacciTester):

The ServiceLocator (FibanocciServiceLocator) is used to obtain the Service (FibanocciService) class. The Service class cannot work in a vaccum, so �new FibanocciService()� can't work unless you want to include all sorts of creational code in the service implementation - which wouldn't be practicing proper separation of concerns. So the client needs the ServiceLocator to create the client Service class.

The client Stub contains a lot of the lower level generated (un)marshalling code that are necessary for the Service class' methods to function.

DOUBT: Whether as a service provider semding the WSDL is enough for the client to access the service or the client required any other details other than WSDL file[/b]

In general the client shouldn't need anything else. There are exceptions though.

Whenever a web service uses a "encoded" (rather than "literal") messaging style, the encoding scheme must be understood by both the client and the server. The WSDL identifies the encoding - but it does not define it. The fibanocci example actually uses SOAP encoding which has caused interoperability problems between different SOAP toolkits (more modern examples always use "literal"). In this case it isn't a problem because both the server and client are generated by the same toolkit. When transferring more complex objects, you need to supply custom (de)serializers - that you then have to supply together with the WSDL; in essence you are defining your own serialization protocol for complex objects. The lessons: don't use "encoded" and don't try to "beam over" objects - you are building a message.

However even with the "literal" messaging style there are some holes. If you have a WSDL that uses the xsd:any or xsd:anyTye then you are basically looking at an incomplete contract - the WSDL doesn't specify the XML that may appear in the elements of that type. So the structure of the XML in those elements must be communicated elsewhere.

DOUBT: Client will have only the WSDL file. Is't correct? or whether the client will know all the package structure and how it is deployed in the service provider side?

The WSDL tells the client the address of the web service endpoint and what the valid SOAP request and response messages are with the various operations. The client does not need to know which language the web service is implemented in or in which environment it is deployed; the client itself may not even be implemented in Java - so communicating details like the "package structure" is pointless.