Thursday, February 24, 2011

SOAP Processing Model

    In this article we try and take a look at the SOAP Processing Model. Pre-knowledge of SOAP is a must and can be obtained here. The importance of SOAP lies in its ability to be extremely flexible and extensible. These features are provided by the SOAP Processing Model. The SOAP Processing model is the lifecycle of a single SOAP message in isolation from any other SOAP message. It does not maintain any state; perform any correlation or co-ordination between messages.



Initial Sender – The message originator
Ultimate Receiver – The intended recipient
Intermediaries – Processing blocks that operate on the soap message before it reaches the ultimate receiver.

The extensibility and flexibility in SOAP is provided because of the presence of intermediaries which in an unobtrusive manner allow SOAP messages to be processed. The intermediaries work by intercepting messages, performing their function, and forwarding the altered message to the ultimate receiver. In an implementation, intermediaries are like a listener. They intercept the message and process it and then pass it on.

Before we actually look at features like how to identify an intermediary and how to process, let us try to understand why and where does an intermediary come in the picture. Take the example that a SOAP message is being sent from Client A to Server B. Client A's company has a standard disclaimer which is appended to the header in every message. Instead of every client implementing the disclaimer addition, the company has a gateway which intercepts any SOAP message and adds to its header code in the form of disclaimer. Ex.

 <soap:Header>  
 <company:Disclaimer>All intended recipients … </company:Disclaimer>  
 </soap:Header>  


Such an interceptor could be called as an intermediary. Other common examples of intermediaries would be a logging intermediary, an encryption intermediary, a caching intermediary. Often these intermediaries may want some special input. This input can be provided in the form of targeted header blocks. To target a header block to an intermediary, SOAP provides us with an attribute called soap:actor (in SOAP 1.2 it's called soap:role). This attribute take the value of an URI which is understood by the SOAP intermediary. Ex.

 <soap:Header role=”http://mycompany.com/disclaimer” mustUnderstand=”1”>  
 <company:AddDisclaimer>true</company:AddDisclaimer>  
 </soap:Header>  


In the above example, we have added a SOAP header that can help the intermediary to decide whether the disclaimer should be added or not. To make sure that only our intermediary processes the block we have added a role attribute which tells all the intermediaries whether they are supposed to process the header block or not. Also we have added another attribute soap:mustUnderstand. This takes the value of 1 or 0 and tells if the processing of this block is mandatory for the intended intermediary (i.e. the intermediary with whom the role/actor attribute matches). There are two types of intermediaries

  1. Forwarding intermediaries
  2. Active intermediaries
I will not be going into the details of these because knowledge of intermediaries types is not of much importance to most developers except those working on SOAP implementation tollkits (i.e. creating something like Axis). The SOAP processing model however is of great importance because it lays the foundation for an extensible framework which is the base for most web service implementations like Axis and JAX-WS. The basic knowledge of the horizontal extensibility of SOAP due to the presence of intermediaries is a very important concept. There are a few other details regarding SOAP roles which are available here.

Sunday, February 20, 2011

SOAP Encoding

This article is intended for users who understand the syntax of SOAP and want to know more about the power of SOAP. For people who want to know more read here.

The real power of SOAP stems from some of the capability discussed before. Let us try to look at one of them here- "The SOAP encoding mechanism".

Let us first understand the meaning and utility encoding. We understand and appreciate that the power of SOAP comes from its ability to transfer messages in XML format. Encoding is the process of converting any user specific data into XML format. This data could be any of the following:

  1. A remote procedure call (RPC) to a special function/procedure at the remote computer.
  2. A request/order that is valid in the business sense and the remote computer is capable of understanding.
  3. Java objects that are to be transferred to the other end.
  4. A physical document (ex. A mail message or text document) that has to be transferred.
To bring in flexibility in the approach it is very essential that we have a standard way of doing things. We have a standard way of "encoding" the data so that either computer can easily understand the data. This is where the SOAP Encoding comes into picture. The SOAP Encoding allows us to transfer messages of any type within the SOAP envelope. There are two types of encoding

  1. SOAP encoding.
  2. Literal encoding.
SOAP encoding is a set of rules defined in the SOAP specification that tell us how to convert any data into XML format. It follows the concept of SOAP Data Model, which views all data as Object graphs and provides a way to "encode" this graph into XML. Some of the salient features provided by them are:

  1. All data is viewed as nodes which have some value.
  2. The nodes could be connected to other nodes via directional edges called labels.
  3. A node could have incoming-edge, outgoing-edge or both.
  4. A simple value edge with a labeled inbound edge will be serialized into single XML element with label as element name and value as element's text content.
  5. When serializing a node into an XML element, an xsi:type can be added to specify the type of this node.
  6. A compound value node with labeled outbound edges, a data structure, will be serialized into a single XML element with child elements. One outbound edge will be serialized into one child element with element's name equal to edge's label.

     
Example of a Data Model:


class Product{
     String desc;
     String type;
     String sku;
     double price;
}
A java class
A graph notation


The above can be represented in XML format as according to the rules defined in SOAP spec as below:

<product>
<type xsi:type="xs:string">type of prod</type>
<desc xsi:type="xs:string">desc of product</desc>
<price xsi:type="xs:double">100.00</price>
<sku xsi:type="xs:string">xyz</sku>
</product>


This form of encoding has certain disadvantages:

  1. There is no way to tell if the encoding is valid or not (since we can't perform any validation on the message)
  2. The presence of xsi:type is not recommended by WS-I Basic Profile 1.0
  3. SOAP encoding is not supported by WS-I Basic Profile 1.0


"Literal" means a XML document fragment that can be validated against its XML Schema. The biggest advantage of the literal encoding is the possibility to "validate" a XML message at every stage of the message. Literal supports 2 messaging modes:

  1. Document/literal
  2. Document wrapped/literal
  3. RPC/literal
Document/Literal – In the Document/Literal SOAP messaging mode, the Body element of a SOAP message contains an XML document fragment i.e. a well formed XML element that contains arbitrary data and belongs to an XML schema and namespace separate from the SOAP message's XML schema and namespace.

    The term "arbitrary data" signifies that it does not pertain to any standardized (e.g. w3c,ws-i) namespace. It could/should however have some business significance, something that makes logical sense to the requester and servicer. The second thing to note in the Document/Literal encoding is that the SOAP Body can have more than one child elements.

<soap:Envelope><soap:Body>
<product>
<price xsi:type="xs:double">100.00</price>
<sku xsi:type="xs:string">xyz</sku>
</product>
<product>
<price xsi:type="xs:double">200.00</price>
<sku xsi:type="xs:string">abc</sku>
</product>
</soap:Body></soap:Envelope>
<soap:Envelope><soap:Body>
<getProducts>
<product>
<price xsi:type="xs:double">100.00</price>
<sku xsi:type="xs:string">xyz</sku>
</product>
<product>
<price xsi:type="xs:double">200.00</price>
<sku xsi:type="xs:string">abc</sku>
</product>
</getProducts>
</soap:Body></soap:Envelope>
Document/Literal
Document wrapped/literal


Document Wrapped/Literal – This differs from the Document Literal in only one feature namely that it can contain only one child element. If there are to be multiple elements the SOAP encoding style takes care of "wrapping" it. It uses the name of the operation/method to create a parent element for the "Document".

RPC/literal – The RPC/literal style of encoding is used to expose the traditional components as web services. Such components do not explicitly exchange XML data but have methods with parameters and return values. Unlike the above encoding style which may contain any arbitrary data, the SOAP specification fixes some rules for the RPC/literal.

  1. The name of the method to be invoked will be the child element of the SOAP:Body element.
  2. The name of the method appended with "Response" will be the child element of SOAP:Body for the response.
  3. The name of the method parameters will be the child element of the method name in order that they appear.
  4. The response of the method will contain a child called "return".
The biggest difference between the RPC/literal and RPC/encoded however is the use of xsi:type tags which are used with encoding. Also under literal encoding it is possible and advised to have a XSD available to validate the XML request.



Though all the above encoding styles can be used, the one that is most recommended is the Document/Literal with only on child element of SOAP:Body. This provides the complete flexibility with XML messaging and also provides validation mechanisms like XSD. One more very important thing to understand is that these encoding styles make a lot of difference to any API that implements the SOAP specification. For an end-user, there is very little difference between these encoding styles other than to predict the sample request/response for any operation. However if we specify any of the above encoding styles to the API it will tackle the request correspondingly and treat it as per the rules defined above.


SOAP – The Indispensable

In the articles about SOAP, I try not to re-invent the wheel. For syntax of SOAP messages and other "freely and easily available" information I will refer to standard links. I try to explain the real nuances of SOAP messaging which makes it such a simple yet powerful tool.

What makes SOAP indispensable?

Let us try to look at some of the features provided by SOAP specifications that make it a nirvana for almost all web service needs.

  1. It provides a mechanism for defining the unit of communication. When we transfer SOAP we have a single unit of measurement in the form of a SOAP envelope. This "holder" allows the recipient and sender both to know when the message ends and when the next message starts. [via. The SOAP Envelope]
  2. It provides a mechanism for error handling that can allow us to identify the source and cause of error and allows for diagnostic information to be exchanged between the participants. [via. The SOAP fault]
  3. An extensibility mechanism, so that there is no lock-in to a protocol. This in my opinion is the real crown jewel with SOAP which makes it such a unique and indispensible asset. It satisfies two major needs of extensibility i.e. orthogonal extension and de-centralized extensions. [via. SOAP Headers]
  4. Mechanism to bind to any network including (but not limited to) HTTP and support for Remote Procedure Calls (RPC's) and mapping for Documents. [via. SOAP encoding]
To know more about the SOAP envelope syntax refer here.










 

Tuesday, February 15, 2011

Evolution of web services

        In the last decade there has been more work on web services than on any other open-source effort. The main reason for the same is the fact that apart from having massive support from open-source communities' web services also enjoys un-paralleled support from industry stalwarts like IBM, Microsoft and Sun. This article attempts at having a glance at the evolution of different components involved in web services. We first have a look at the 3 most important components of any web service the Network, the XML Messaging Layer and the IDL.

    Network – There are a number of concerns like security and reliability which are essential for any web service system to succeed. When web services was still at its nascent stage the most preferred way to communicate between web services in a reliable way was JMS. And when people wanted high levels of security they adopted SSL/TLS methodologies of communication. Though there was no inherent disadvantage with using these existing facilities, they severely restricted the flexibility that was expected in a web service environment. JMS networks are not popular across the web while SSL/TLS limit the capability to have selective encryption of messages. As web services evolved, other standards for security and reliability have been developed which can be put on top of the network (in the XML Messaging Layer) allowing us to use HTTP as the default network for web services. A few of them are listed here. "SAML", "User Name Token Profile", "WS-Security", "XACML", "XKMS" and the "Liberty Project" are the well known alternatives for security and "WS-Reliability" is a recommended alternative for reliable messaging.

    XML Messaging – The evolution of XML Protocols started with the First Generation XML Protocols efforts – WDDX (Web Distributed Data Exchange) and XML-RPC (please note the XML part of the acronym). These protocols had limitations of generic extensibility and support for only DTD. These deficits were overcome in SOAP 1.1 specification which was spearheaded by Microsoft and IBM who jointly published it. This is the most popular industry standard even today and is recommended in WSI BASIC Profile 1.1. The latest developments in the field of XML Messaging are SOAP 1.2 and ReST. While SOAP 1.2 improves on the features provided by SOAP 1.1, ReST is a simple and easy way to do XML Messaging. We will discuss these in later articles.

    Service Description – IDL's (Interface Description Language) as a concept have existed since 1994 when IDL's were created for CORBA. The first standard IDL work that was created for Web Services was WSDL 1.1. This specification was the result of a joint effort by Microsoft and IBM and aims at providing a standard way to describe (in XML) network services as a set of endpoints operating on XML messages. Though the industry still largely uses WSDL 1.1, a newer version of IDL (WSDL 2.0) is now available with enhanced features as compared to WSDL 1.1. I will discuss both WSDL 1.1 and WSDL 2.0 in the later sessions.

    Implementations – Since the inception of the Web Services stack in 2001, there have been a number of popular open-source implementation efforts that have tried to implement all or some of the features specified in the Stack. The first ever project was the Apache SOAP project created by IBM and donated to Apache Group in 2001 making it open source. This was followed by the Axis 1.x and JAX-RPC. The JAX-RPC was an implementation by java/Sun to do web services using Java 1.4. The recent years have seen efforts by a number of groups like Spring, Spring-WS, Axis 2, Metro (Glassfish), JAX-WS (Sun's JavaEE5 compliant) etc. In the course of time we will discuss some of the major implementations that are available.


 

Web services stack de-mystified – Case study

    In my previous article I touched upon the topic of WS-Stack. Here I try to go into details of the stack, trying to de-mystify the complexity that is associated with any web service implementation of the stack. For the case of discussion let us consider a Case Study –

Project: A Stock Ticker Service. – This service is provided by a Stock broker to all his clients who can check the price of any stock in real time using web services.

Requirements: Input of the Stock Ticker Service will be a 4 digit stock code. Output will be the price in Rs.

Stack: HTTP/SOAP/WSDL

    With this basic information under the belt let us start to build the representation of such a service. The actual "service" implementation would be a complex method that derives the price based on lots of parameters but for simplicity let us keep the method simple.

public float getStockTicker(String stockCode){
  if(stockCode.equals("STC1"){
    return 100.50;
  }
  else
    return 0.00;
}


The above method as discussed in the requirements takes an input of a string stock code and returns the price of the stock. Now if we were to create a sample message for the same using SOAP the message would look like.

<env:Envelope xmlns: env="http://www.w3.org/2003/05/soap-envelope" >
  <env:Header></env:Header>
  <env:Body>
    <st:getStockTicker xmlns:st="http://stockticker.example/sample" >
      <st:stockCode>STC1</st:stockCode>
    </st:getStockTicker>
  </env:Body>
</env:Envelope>


And the response to the above would look like the below:

<env:Envelope xmlns: env="http://www.w3.org/2003/05/soap-envelope" >
  <env:Header></env:Header>
  <env:Body>
    <st:getStockTickerResponse xmlns:st="http://stockticker.example/sample" >
        <st:price>100.50</st:price>
    </st:getStockTickerResponse>
  </env:Body>
</env:Envelope>


Without going too much into the details of the SOAP let us briefly look at the highlights of SOAP.

SOAP is an XML protocol which contains an Envelope in a namespace defined by "http://www.w3.org/2003/05/soap-envelope" (henceforth denoted as SOAP: ). The Envelope contains 2 child elements The SOAP:Header and SOAP:Body. The header element contains information dealing with extensibility data while the Body contains information pertaining to the request/response. More details about SOAP would be discussed in the further articles. In the meantime you can read more about SOAP here. The main advantage of SOAP is that it allows us to define a standard structure for the XML message that is being passed. For example when we see the above message we know that the contents of the SOAP:Body tag are of use to the function that we have written.

Now once we know the details of the request and response we need to send it to all the clients who want to use it. For such a small request/response sending a sample request/response and some documentation is enough but if the sample request is much more complicated then we need a standard way to describe the request/response and also the location of the service. This standard way is provided by WSDL. Have a look at the sample WSDL created for the above example.

<wsdl:definitions name="StockQuote" targetNamspace="http://stockticker.example/sample/wsdl" 
  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl" xmlns:sample="http://stockticker.example/sample" 
  xmlns:tns="http://stockticker.example/sample/wsdl">
  <wsdl:types> <!-- defines the xml schema for the required input and response -->
    <xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema" 
        targetNamespace="http://stockticker.example/sample">
      <xsd:complexType name="getStockTicker"> <!-- request schema definition -->
        <xsd:all>
          <xsd:element name="stockCode" type="xsd:string" />
        </xsd:all>
      </xsd:complexType>

      <xsd:complexType name="getStockTickerResponse"> <!-- response schema definition -->
        <xsd:all>
          <xsd:element name="price" type="xsd:float" />
        </xsd:all>
      </xsd:complexType>
    </xsd:schema>
  </wsdl:types>

  <!-- message defines the request and response for an operation. -->
  <wsdl:message name="getStockTicker"  >
    <wsdl:part name="request" element="sample:getStockTicker" />
  </wsdl:message>

  <wsdl:message name="getStockTickerResponse"  >
    <wsdl:part name="response" element="sample:getStockTickerResponse" />
  </wsdl:message>

  <!-- port Type is a collection of operations. This is like an interface definition. 
           The operations that are exposed in a web service are given out here-->
  <wsdl:portType name="StockTickerPortType" >
    <wsdl:operation name="getStockTicker">
      <wsdl:input message="tns:getStockTicker"/>
      <wsdl:output  message="tns:getStockTickerResponse"/>
    </wsdl:operation>
  </wsdl:portType>


  <!-- The above information tells us what are the different services 
         that are exposed and what are the request response params -->
  <!-- The next part describes HOW to access the request / response and where to access them -->


  <wsdl:binding name="StockTickerBinding" type="tns:StockTickerPortType">
    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
    <wsdl:operation name="getStockTicker">
      <soap:operationsoapAction="" />
      <wsdl:input message="tns:getStockTicker">
        <soap:body use="literal" parts="request" />
      </wsdl:input>
      <wsdl:output  message="tns:getStockTickerResponse">
      <soap:body use="literal" parts="response" />
      </wsdl:output>
    </wsdl:operation>
  </wsdl:binding>

  <!-- In the above mapping we describe that we want the operation getStockTicker to use SOAP binding. 
       The request and response content format i.e. the contents of the SOAP body are also defined.-->


  <wsdl:service name="StockTickerService">
    <wsdl:port name="StockTickerPort" binding="tns:StockTickerBinding">
      <soap:address location="http://stockticker.example/service/getStockTicker" />
    </wsdl:port>
  </wsdl:service>

  <!-- The wsdl service is used to provide the actual endpoint 
      of the service at which it would be available -->
</wsdl:definitions>

The comments for the WSDL are provided inline. The basic job of the WSDL is divided into two parts. In the first part the WSDL defined the input and output parameters and also describes the operations that are exposed. In the second part the WSDL describes how the operation can be invoked (what scheme of XML messaging and which network protocol to use) and also the location at which it is available. Now if we are able to provide this sample WSDL to any client. They can understand from the WSDL how to create a sample request and call the service. To do the same the client needs to parse the WSDL, create the SOAP message from Objects , Connect to the server , wait for response , convert response into objects. This entire process is done by any implementation API (ex. Axis, JAX-WS or Spring-WS etc..). The UDDI and BPL are advanced concepts that would be discussed in details later.





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.


 

Why use XML in Webservices

The importance of communication in our day to day life can never be understated. We need to communicate between ourselves in order to have any “meaningful” interaction. Analogously computers also need to “communicate” between each other in order to have a meaningful interaction.

Communication is always wonderful until we come across a situation where we need to communicate with people who don’t understand our language and we don’t understand theirs.
For a computer program to “talk”, he needs to be able to call another program’s method/function.  Again this is great as long as the caller and callee are on the same platform, but once we talk of distributed computing such an assumption is outrageous if not downright stupid. Often we come across situations where we need to be able to call a PHP script from JAVA, .NET function from JAVA, COBOL procedures from JAVA and vice versa.

This is similar to 4 guys talking in 4 different languages (let’s say Hindi, Chinese, German and French) trying to ask a question each. We can’t really communicate with each other till either

   a)      We have an interpreter who knows all the four languages and translates amongst us
                                                    OR
   b)      We all know a common language (let’s say English)

Translating the above solution to our similar predicament with computers, the computing world provides us with 2 similar solutions:

    a)      Object Request Broker (ORB)
    b)      XML

ORB:
To quote from Wikipedia: “In distributed computing, an object request broker (ORB) is a piece of middleware software that allows programmers to make program calls from one computer to another via a network. ORBs promote interoperability of distributed object systems because they enable users to build systems by piecing together objects from different vendors, so that they communicate with each other via the ORB.”
To put in simple words, an ORB is our interpreter. The main task of the ORB can be highlighted as below:

   a)      Convert the “method call request” from the language of requester (this includes serializing custom data
             types, method name to be called)
   b)      Convert into bytes and transfer over the network
   c)       Re-convert the bytes into the language understood by the requested function (and reverse the bytes
             into the data types understood by the called language).

Some of the common implementations of ORB are CORBA, RMI (inter java communication), DCOM, .NET Remoting. The biggest challenge/limitation of an ORB is the complexity associated with its implementation.  I shall not go much into details of ORB but you can probably look up RMI and CORBA in any site.

XML:
XML is to computers what English is to humans. The usage of XML allows us to communicate between many different languages using a common and “simple to understand language” structure which is portable and independent of implementing technology. By itself XML has no meaning (it just a bunch of tags put together) however when put into a relevant context they contain a lot of information.
At expense of repeating myself the biggest advantage of XML are:

   a)      Interoperability
   b)      Technology independence
   c)       Portability

And it is this power of XML that is utilized in SOAP which will be topic of discussion in my next article.

Web services – Practical example – (beginners only)

This article is intended only at first time web service users. People who do not have the required visibility of distributed computing and web services. All other users please refer to the next article in this series.

Time and again we hear from people that they are using “webservices”. Let’s take a brief glimpse into the world of web services and understand a practical scenario where and why we may want to use webservices.
Case Study: Take the case of a Travel Website (the likes of Yatra.com, makemytrip.com, cleartrip.com etc.). A normal operation between a user and the travel site would look like:-
  1. User logs onto website
  2. Searches for flights on a particular day
  3. Selects the flight most suited
  4. Enters passenger data for the flight
  5. Makes a payment on a banking gateway
  6. On successful payment gets a confirmed PNR number.
In this simple interaction between the user and the travel site, the travel site had to perform 2 major interactions (excluding the payment part of it):

    a) Get the data for flights
    b) Confirm the payment and reserve a seat

On the front of it these are simple database operations with one common exception, this data should NOT be maintained by the travel site. We do not want that the data on flights (including fares) are provided from the travel site’s database because they might/will not be updated with latest figures. We definitely do NOT want the reservation of the tickets to be done at the travel site front. (Imagine a scenario that the travel site forgets to update the carrier about your ticket and on the day of flying you realize that your ticket is not valid because your travel site “forgot” to update the ticket details with the airlines.)

Soln:- The simplest solution that is available to us is to ask the travel site to get the latest data from the actual carrier and once a payment is made contact the carrier and get a PNR through them. Since in this particular case the interaction would be directly with the carrier (through a travel site) all our data is up to date and reservations are “meaningful”.

This simple and practical scenario highlights the importance of inter-computer interactions, which add meaning to the operations of a site. But (there’s always a ‘but’) there is one catch. As long as the sites are working on a common platform communication between them is easy (a simple method call will suffice). But what happens when we have different vendors for each site.

Ex:

Webservice Case study

This is where web services gains prominence. The usage of Web services will provide us a simple and effective way to communicate between the 2 (or more) computers to allow for a meaningful interaction. How it achieves this interaction is explained in greater details in the next article.

What is Webservices in layman terms?

Web services and S.O.A. (Service Oriented Architecture) are the latest fad that has taken the world by storm. But I have rarely come across a good book or a good site that  explains Web Services in a simple and prosaic manner. So lets have a layman’s view into the web service paradigm and explain the Basic’s of Web services (WS).

Before We delve into the technical details of WS lets look at it in a simple context. If we break down the term it comes from 2 words
  • Web
  • Services.
Services - A service is a facility or service that is provided by some body. This could be a paid service (for example a hair cut) or a free service (waiter at a restaurant).The main actors (design parlance) in this are
  • The person who provides the service (provider) and
  • The person who utilizes this service or consumes this service (Consumer / Client)
Web - The World Wide Web  or internet which serve’s as a common platform for communicating. There are 2 factors that come into play when  we consider the term Web.
  • There needs to a channel for communication on which 2 parties (i.e. Provider and Consumer) can meet
  • There needs to be a common mode of communication between the two.
If I were to build on an example of a real life scenario of you going for a hair cut.
There are 2 actors or parties in this interaction. The barber and you.
The Barber who gives you a hair cut is the “Provider“. You are the “Client/Consumer” who would receive the haircut. The barber shop is the place where you get the service. To reach to the barber shop you take a Car or Walk. Once you reach the shop you need to explain to the barber what your inputs on the type of haircut and this has to be communicated to the barber effectively and in a common language that both parties understand. At the end of the service you make a payment (and if this is complimentary it may be free of charge).

Now when we translate the same scenario to the virtual world,consider a scenario where you build a program which needs a real time conversion of currency from dollars to local currency. There is a provider(your local travel agent’s website) who has offered to provide this service. To enable your program to be able to communicate to the service agent’s website/computer you need to connect to his computer (using http or jms) and send him input in a format that he can understand (and is preferably standardized) which in this case becomes SOAP/XML.  If we were to paraphrase this interaction:

Any webservice has the following elements :
  • Provider – A provider of a service/facility on the web. This could be something like a IP Geolocation tracker or A currency converter.
  • Consumer/Client – A program that intends to consume or utilize the service that the provider is providing.
  • SOAP/XML – A common way of transfer of data such that it is possible for both the entities to understand and exchange data. This has to be a standard way of communicating so that independent of the programming language used.
  • http/jms/smtp – A standard channel of communication that can be initiated / developed between 2 programs.
In my next post i will develop more on the topic of how webservice communication takes place and where WSDL/SOAP and HTTP come into picture exactly.