Concept associated with web service technology

 
In last article we learned about what web services is. In this tutorial we will try to understand some of the concepts associated with web services technology.

Let stat with the scenario, let us say I’m writing a java implementation class, if I want to share this implementation with other consumer class, then the best way to share the implementation class is through the interface
 

Normal web application

So Interface is a standard way in which you can share any contract (implementation class) to a consumer.

so now think about how this could work in case of web service

Now let’s say I have a web service implementation, I want to share the details of web service to the consumer through an interface,

Web service demo

In this case the consumer can be in any language and so the web service, So the interface that we are going to share with the web service consumer must be technology independent, it should be something that any technology can understand, so the concept of interface will not work here.

In order to cater to the need for a platform independent format for interaction, XML format was adopted for this purpose. Now when we create a web service, we will share its contract(implementation) as XML document.

This XML is called WSDL

Web service

WSDL document will contain the contract of the web service. So when we create a web service we will share the WSDL to the consumer class.

WSDL for an existing web service can be generated either manually or automatically (through available tools)

Contents of WSDL:

1. Methods

2. Argument

3. Return type.

This is a high level representation of WSDL.

Therefore through WSDL we will get to know what information needs to be sent and its return type.

Now let us say that you are going to create your own application and you are about to call a web service

Now there occurs a question, how consumer is able to locate WSDL for a particular Web Services?

As we know that the one way to get web service information is through the WSDL, but now how do we get hold of the WSDL?

Solution : Here there are 2 solutions for this,

1. If Web Services knows the consumer, then it can directly give the WSDL to the consumer establish web services connection.
2. There is an registry called UDDI on internet. It is a directory, where all service providers who want to issue their web services would 1^st need to register the web services with UDDI using WSDL and make themselves available through it for discovery.
    

Now consumer who is looking for a particular service would go and hit UDDI, and will search for a particular service that it is looking for. Now UDDI will return all service providers who offer that service. And then Consumer will choose one service provider from it, and get its WSDL, now with the help of WSDL, consumer will able to access web services.
 

 

 
Now we got the WSDL, so we know what information needs to be sent and its return type.

Now let us assume that you are writing a client application (in java) to call a web service (in C++), so now we can get the WSDL by querying the UDDI.
 

 
But now the question is how do we actually send the information and how the exchange happens?
 
The parameter sent from our consumer class (say, some complicated object) might not be recognized by the other language in the web service which we are about to call. Thus, the object passed will make no sense to the web services and hence the web services will not be able to process the input parameter.
 
For example I have a java String as input parameter which is needed to be sent to web service which is written in C++.
As we know a string in java is different from string in c++. So how do we exchange the data between client application and web server?
 
So the information passed (input arguments) and the information received (return types) should be in a common format. Again XML format comes to the rescue.
 
There is a protocol by which both sender and receiver understands this format (XML).

This protocol is known as SOAP.
 

 

 

 
Now you know what a web services is and you know what needs to be sent (WSDL) and how to send it (SOAP).
 
But now who does the conversion?
 
Referring to the above assumption, how to do the conversion from java objects to SOAP message takes place?
 
Well this conversion is done by an intermediate class in the client application which is SEI.
 

 

 
SEI acts as an interface to your web service endpoint. SEI takes care of converting client object to a SOAP message. And we don’t need to write this class ourselves, we can generate it automatically.

Note:When you are about to make a web service call, you don’t need to worry about where the web service is and where you need to call. All you have to do is to have this SEI generated/Created and you can call the method of SEI.

One good thing about SEI is that, you can actually have interface specific to what you are developing.

For example, if my client is in java application, then I can have a SEI specific to java application, which knows to convert java objects to soap objects. Similarly for dot net, SEI will be in dot net, which converts dot net code to SOAP messages.

I.e. SEI takes care of all web service call.
 

Web Service Design

 
There are two approaches in implementing a web service and they are bottom-up and top-down.
 

Bottom Up Approach

 
Bottom up approach is where we first define the logic of a web service and then using that we will build the WSDL file. There are tools available to generate the wsdl file automatically based on it.
Refer: Create and Deploy Web Service and Web Service Client using bottom up approach
 

Top Down Approach

 
Top down is the reverse of bottom up approach. First the business logic is written up and then we create the WSDL. The complete business definition, message format, transport protocol, security and everything will be described in WSDL. Using that wsdl the skeleton code is generated automatically.
 
Summary
 
In this tutorial we have learnt 4 terminologies so far.

1. WSDL – describes what a web service is in an XML format.

2. UDDI – it is a directory where any publisher can publish their web services and a consumer can query and get access to all different web services.

3. SOAP – it’s basically a protocol that is used to encode and decode messages. When you make a call to web service, it ends up as SOAP message that gets transferred over the network.

4. SEI – it’s an interface to the service endpoint (web service), that provides a way for client application irrespective of the technology to call the web service. Depending on the technology you get a SEI for that technology. This can be generated out of the WSDL itself.
These are some of the important concepts about web service. We will see some more detail in the next tutorial.