How to choose between SOAP Web Services and RESTful services?

Posted by Mohaideen Jamil in RESTful Services, Soap Web Service, Soap-UI, Web Service | 2 comments

Choose SOAP:

• If you require asynchronous processing
• In your service operations are statefull
• If you need formal contract/Interfaces

Choose RESTful Services:

• If you have limited bandwidth
• If your clients require caching.
• If your operations are stateless

Concept associated with web service technology

Posted by Mohaideen Jamil in Soap Web Service, Web Service | 4 comments

 
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
 

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,

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

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 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.
 

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.
 

Introduction to Web Services

Posted by Mohaideen Jamil in Soap Web Service, Web Service | 1 comment

 
In this article we will get an introduction about what an web services is. In case of web service there are primarily two different types

1. SOAP Web Service
2. RESTful Web Service

Basically, we can say that everything available online are services. Difference between a standard website and a Web Services is, a website stands for human consumption but a Web Services stands for code consumption.

Let us try to understand that better..

Imagine your friend has an existing application which takes a particular day as input and returns the events that take place on that specific day. Lets say it has a method getEvents() which takes the input date and returns a List of Strings containing the events. For a general website, this application is present in MVC form and  is deployed in an application server. This way, the functionality is available to the end users who can send their input to the application and get their desired result.

Suppose I have a completely different App server, and I wants to use the getEvents() functionality of my friend’s application into mine.

Then one way I can do it by  Getting jar of original server.

 The disadvantage of this method is,

1. My friend’s application may have different application server, database and have other business which I’m not interested in.

2. If my friend changes the jar, then I need to get it and build it again.

Then Solution of the above problem is to use  Web Services

Web Services allows two different applications running on different machine to communicate with each other. But there should be a network connecting these two applications.

The best part of Web Services is inter operability, i.e. java can call .net and vice versa

Illustration:

In the above diagram, application (A1) calls a function in application (A2).

The application (A1) which gives a call to the function is called web service client; the application (A2) which gives services to the request is called the web service endpoint.
 
Note: In general words, “web service endpoint” is a service which published outside for user to access; where “web service client” is the party who access the published service.

This is a basic level over view of web services. In the next tutorial we will learn about some terminology used in web service.