Web Services Foundation

General Definition
Put in the most general terms, Web Services are applications that can talk to other types of softwares over a network.

Criteria for applications to be Web Services
More specifically a Web Service is an application that fits into the following criteria.


1. It has the ability to describe itself to other applications

2. It can be located by other applications by use of a directory service (provided of course, that the Web Service is registered with one).

3. The functionality it exposes can be invoked by other applications

“Ok, sounds cool ! but all these criteria are satisfied by components deployed in most existing distributed systems”. Take for instance an EJBService, the interface of an EJB describes the service that the EJB intends to provide (Criteria 1 satisfied). A lookup service like an implementation of JNDI, LDAP etc can be used by client application to locate registered EJBs (Criteria 2. satisifed). The clients can then obtain a Remote reference to the EJB (interface) and invoke methods on it (Criteria 3. satisfied) . So why is all this hype about Web Services ?

True, quite true, web services are not a great technological innovation but what set them apart from existing distributed systems is that they present themselves, while satisfying the all of the 3 criteria above, in a way that can be understood by an application developed and deployed on any software platform. Now thats something that is outside the scope of an EJB Service, for example how would a Visual Basic client possibly understand or even import, into its environment a reference of the EJB's remote interface. Since it cant do so, at least not in a straight forward way, it has missed the service it wanted to use. The EJB vendor/owner on the other hand has lost a client. What holds good in this case for EJB's Remote Interface does also hold good for The Directory Service and the stub instance; ie neither can be imported and used by the VB Client. All of these, the remote interface, the handle to the Directory Service and the stub instance, represent the EJB service using JAVA Objects (and references) and JAVA objects ( as with objects/variables of any other platform/language) are entities encoded by the JAVA runtime and they thus make sense only in the JAVA runtime domain. Conclusion ? we cannot export any of these into a non-Java system unless of course that there is a Object Broker available. For an arbitrarily selected client and server pair there can be no guarantee that there would exist a Common Object Broker between the two platforms they are running on. The problem we are faced here with is thus one where the EJB service satisfies all the criteria as a web service but only partially, since not any selected client need necessarily understand (and thus be able to use) the service.

The base of this hindrance to interoperatability lies in the fact that we cannot expect non-Java client to support JAVA Serialization Framework. The non-JAVA Client is unable to un-marshal an object serialized by a JAVA based server, into a representation native to its platform because it does not understand the format in which the object is represented in the serialized state. There could be only one solution to this problem and that is to serialize the object in some way that is understood by both JAVA or non-JAVA platforms.The most obvious and simple to do this is to represent the object ( actually data in the object ) as simple text. Since text is understood by all software platforms, the client could then take this data and encode it an Object representation that is native to its platform (here platform means software platform). The client code can then work with this newly created object. Extending on the same idea forward we can also encode Remote Procedural Calls (RPC)as text.

Thus where we have used the JAVA-Text serializer, the client (say a C++ program) is able to receive the Object as simple text Data (“hello”) and can construct an object of, say MyString's (some class written in C++) object from it. Another scenario would be where the client makes a RPC call by sending the following text encoding to the server


encoding=“UTF-8”

communication_reason=“RPC_REQUEST”

invoke_process=“calculate”

value=“12*12”


Now so long as both parties agree on some basic formats (example : The string appearing after “value=” is considered by both as 'value of the Object' and that “RPC_REQUEST” stands for saying “client is requesting an rpc call” on the process specified in “invoke_process” ) they can communicate.

Thus all such clients that need to communicate with our server will have to just learn the format of serialization and they can communicate. But this implies that different service vendors may have different formats, for example some service vendor may say he doesn't like value and would like his client to rather use the word parameter. This means that the client's code will have to be changed in order to incorporate this vendors requirements. And then changed again for some other vendor.Won't it then be great if only one format specification were made and accepted by all. The format would then become an Industry Standard for data communication between heterogeneous systems and any service using that format would then become a web service in true sense.

In our example ( value=“hello” ) above the format used was ( propertyName =“propertyValue”) however in case of almost all real life applications the data to be sent will not have such a flat structure, also that the data's complex structure will be required to be maintained. For example : Person (Object) has-an Address (Object) “which in turn” has-a Street (Object) and so on and Person Object makes sense only when such has-a and is-a relations are maintained. It is well known that XML is the best way to express complex data and for this reason it becomes quite obvious that the data exchange format that we want all to use must be an XML based format. Fortunately for us such a format already exists and has been accepted by virtually all players of the industry as suitable for not just communicating data but also for indicating making remote procedural calls (RPCs) across heterogeneous systems. This format is nothing else but the much spoken of, SOAP and now you know why it is so much is spoken of it. Any RPC system/infrastructure that uses SOAP to communicate with peer is thus called XML-Based-RPC system. Note that there are also other standards like SOAP but SOAP is by far the most widely accepted one and we shall continue to concentrate on it. For the ongoing discussion so much of knowledge about SOAP is sufficient however you may refer to the this tutorial for more information.

This is a typical SOAPMessage a client will send to a server while requesting invocation of a method with the following signature.

public void setAddress(Address clientAddress);

Note that this method must be one of the methods exposed by the service. But how does the client know which methods are exposed?

As is evident from the xml, the description of what setAddress(...) is, would be available in some XML with targetNameSpace as “http://mywebservices.com/wsdl” . Similarly the description of the data type “Address” would be available in some XML with targetNamespace “http://mywebservices.com/types”.

Did not follow the last couple of lines? No problem! thats possibly because you aren't comfortable with the “Namespaces” concepts of xml. However good news is that you don't have to bother your self with that. My suggestion is to just read those lines carefully once again and keep them in mind and go ahead!

Usually the clients side code would have two layers. The client code ( Business logic code) is the upper layer and the Java-Soap converter (this is what we would call Java-Text Serialzer) forming the lower layers ( and passes those parameters to the lower layer, that it wants to send across to the remote server). When ever the client wants to make an RPC call,it invokes suitable method on the lower layer. The lower layer then makes the Soap Message and send it across.

Typically, when a client is interested in using some remote service then it would take the remote interface of that service and run some kind of a tool providing the interface as input generate classes of that the JAVA-SOAP converter. The classes generated (stubs) by the tool would have the same method signatures as the Interface but the definitions of these methods would have the code to generate (Send and recieveResponse) a SOAP message requesting the server to invoke that particular method. But in all this there is a problem. All this discussion has been w.r.t JAVA. Thus if our client is a VBClient then it would require a VB-SOAP converter and we should also expect the tool to be a VB based tool. We cannot expect our VB based tool to understand method signatures of our Remote Interface. Clearly there is a need for a platform neutral way to describe services. But what do we really mean by “describing a service”. Well , we essentially mean two things.

1. Description of the methods
a. Names of the methods
b. What they take as i/p
c. What they return back.

2. Description of the datatypes used for parameters and the return type.
This is needed because DataType of a parameter or of the return
type would be defined using some constructs in the language in which the server is coded
and which don't really make sense outside the scope of that language.

Thus we must have some way to express what a JAVA class

say,“Address” really means. The client side platforms can then use

a suitable datatype Object to mirror our "Address Class

Fortunately we do have an XML based specification that helps describe a service. So this specification would let you express your EJB Interface in XML. This standard is called WSDL ie. Web Services Definition Language.

A WSDL document is expected to expresses much more that just the methods in the interface. For the ongoing discussion so much of knowledge about WSDL is sufficient however you may refer to the this tutorial for more information.

Yet another XML Based format, the UDDI (Universal Discovery, Description and Integration) lets you locate a Web Service. Refer this tutorial for more information.

Thus any network enabled service that

1. Describes itself using WSDL (fulfillment of criteria 1)

2. lets to locate itself using UDDI Registry (fulfillment of criteria 2)

3. supports XML-Based-RPC (thus fulfilling criteria 3)

is a true Web Service.

In this chapter we have seen how web services are different from existing distributed Systems. We have taken a look at the corner stones of Web Services like SOAP, WSDL and UDDI at a much abstract level. In the next section our intention would be to actually write a Web Service and its client so as to better understand and appreciate each of these corner stones and the framework that binds them together.



Table of Contents Next Previous