Thursday, February 10, 2011

SOA, Web Services, WSDL, SOAP, UDDI, JAX, where they all fit?

The most common fallacy that I have come across when discussing web services is the use of the term SOA and Web Services interchangeably (I must plead guilty as charged myself). In this blog I try to explain the difference between SOA and Web Services and where exactly do other terminologies like SOAP/WSDL/JAX/UDDI etc. fit in. For a beginner's insight into web services read my earlier article.

First let's look at the history of SOA. In 1990's all e-business and web sites were concentrating on the e-commerce model. People were interested in setting up websites only to sell products to human's who logged onto the web from a browser. The advent of SOA gained prominence when we diversified from e-commerce to e-business. Here we started looking at other avenues to gain revenue and the first option that came to mind was "Information is power, Power costs money, let's sell information". This simple idea gave birth to a change in perception of websites. And we started exploring newer models of implementing a site and trying to make it more service oriented where we could sell services (this service could also be information services). This idea was incorporated as a "conceptual architecture" which is SOA. Here the word conceptual is very important because one needs to understand that SOA is an idea. It's a way to do things; one of such ways is web services. But just using web services doesn't mean that we are using SOA. The closest example is people often confused that using C++ (or Java for that matter) meant they were doing object oriented programming. But just using an OOP language doesn't mean we are doing OOP. We need to visualize the problem in an OO Paradigm to actually claim we are implementing OOP.

The next logical evolution in the SOA concept was the advent of dynamic e-business. This model of e-business required us to be able to "dynamically" lookup potential business partners/services and be able to connect to them seamlessly in real-time and exchange information. Analogous to a scenario where we want to watch a movie and choose to go to the multiplex, so that we have a number of options and we choose our best fit. We don't need any pre-booking or watch the only one movie that's playing (as in single screen theaters). With these requirements of SOA a general best-fit implementation was Web Services with the usage of xml as a mode of communication and a whole host of choice of network solutions. However if one desires there are other ways to implement SOA using proprietary technologies (thought then they may not really qualify as dynamic). Thus to paraphrase Web Services is one choice (and most popular) of implementing SOA but not every web service implementation is an SOA implementation.

Now looking at the other terms, IBM defines Web Services as - "Web Services are self contained, modular applications that can be described, publishes, located and invoked over a network generally World Wide Web.". To put it in simple terms, web services is an interface (not Java interface but interface in general) that describe a collection of operations (which are the offered service) that are network accessible through standardized XML messaging (read to know why). To be truly dynamic it needs to be described using a standard, formal XML notation, called its "service description", which covers all details that are necessary to interact with the service including message formats (input/output parameters), transport protocols and location. This interface hides the implementation details of the service, allowing it to be used independently of the hardware of software platform on which it is written. This "service description" should be searchable in a registry where potential users can look-up the service providers and connect to them dynamically. Thus a dynamic e-business (using web services) should be able to perform 3 actions that are shown in the below figure:

Service Provider – From business perspective is the owner of the service and from architectural perspective is the platform that hosts the service

Service Requester – From business perspective requests certain functions to be satisfied and architecturally is the application looking for and invoking or initiating an interaction with a service.

Service Registry – Is a searchable registry of service descriptions where service providers publish their "service descriptions" and service requestors find services.

Web Services Stack – A conceptual stack is necessary to be able to perform the 3 operations discussed above by web services. The most popular stack is shown below:

WS – Standard Stack

The upper layers in the stack build on the capabilities provided by the lower layers.

The vertical towers represent the requirements that must be addressed at every lower level of the stack. They are cross cutting concerns that when applied at every layer allow the service to be ready for real e-business.

If we briefly describe each layer :

  1. Network – The foundation of the stack, Web Services need to be network accessible to be invoked by a service requestor.
  2. XML Messaging – Two common implementations are SOAP and ReST. The importance of XML is discussed above. The details of ReST and SOAP we will discuss at a later discussion
  3. Service Description – This is the heart of the stack when it comes to dynamic interoperability. This description allows us to define details of the service pertaining to the how and where of the service. If we have a valid WSDL for a service we are in a position to access that service and get any data from it.
  4. Service Publication / Service Discovery – This layer is which allows us to dynamically look up service providers. It is a registry of valid providers. We can look up the registry (similar to a search engine) using UDDI and access the exposed WSDL's to be able to connect to the actual service. Please Note: There are cases where the providers are pre-negotiated. In such cases the role of the UDDI is eliminated since the provider can provide us the WSDL during design/development of the Client itself.
  5. Service Flow – For any real e-business to occur, an interaction would span over multiple operations. This requirement is understood by the stack and it provides BPL (Business Process language) a standardized way to formulate our processes such that a logical flow can be designed. (Enterprise Service Buses are an generally implementation of Service Flow).

Since the above stack is standardized and all layers are majorly governed by XML, we have a number of web service implementations which provide us API's and solutions to be able to, dynamically or statically, do a UDDI lookup, parse a WSDL file, generate the required code to create a XML based messaging and finally connect to the actual service over the chosen network. These implementations are "tools" like JAX-WS (Java 5) , JAX-RPC (before java 5) , Axis (apache group), Spring-WS (Spring-source) etc. These are implementations of the standards that are available in the stack and can be used to access any Web Service.

In the next article we go more into the details of the individual elements of the Web Service Stack.



  1. Great explanation. Thanks. Can you explain stuff about SOAP in detail

  2. Very clear way of explaining! Especially about the UDDI.

  3. I doubt your explanation about layer 2

    "XML Messaging – Two common implementations are SOAP and ReST. The importance of XML is discussed above. The details of ReST and SOAP we will discuss at a later discussion"

    As per my understanding ReST is a architecture like SOA.

  4. Great article. Thanks

  5. great!thanks alot abi

  6. You should write a book. You explain so well.