</> MV Techbytes

Web Services provide loosely coupled communication between enterprise systems.
Web Services also enables the enterprise systems to expose business functions to Web-enabled clients.
Web Services can be accessed by wider variety of Clients.
Web Services provide Security and quality services such as availability, reliability and transactions.

There are two principle models in web services. These are:
Document oriented Model.
Remote procedure call oriented Model.

Web Services can be implemented by two ways
Synchronous Web Services
Asynchronous Web Services.

Web Services should be used when you need interoperability across heterogeneous platforms. That is, When you need to expose all or part of your application to other applications on different platforms.
Implementing Web Service make sense when your web services clients are potentially non J2EE enterprise applications.

Invoking the Web Service:

1.As we said before, a client may have no knowledge of what Web Service it is going to invoke. So, our first step will be to discover a Web Service that meets our requirements. For example, we might be interested in locating a public Web Service which can give me the weather forecast in US cities. We’ll do this by contacting a discovery service (which is itself a Web service)
2.The discovery service will reply, telling us what servers can provide us the service we require.
3.We now know the location of a Web Service, but we have no idea of how to actually invoke it. Sure, we know it can give me the forecast for a US city, but how do we perform the actual service invocation? The method I have to invoke might be called “string getCityForecast(int CityPostalCode)”, but it could also be called “string getUSCityWeather(string cityName, bool isFarenheit)”. We have to ask the Web Service to describe itself (i.e. tell us how exactly we should invoke it)
4.The Web Service replies in a language called WSDL.
5.We finally know where the Web Service is located and how to invoke it. The invocation itself is done in a language called SOAP. Therefore, we will first send a SOAP request asking for the weather forecast of a certain city.
6.The Web Service will kindly reply with a SOAP response which includes the forecast we asked for, or maybe an error message if our SOAP request was incorrect.

Web Services Architecture
So, what exactly are SOAP and WSDL? They’re essential parts of the Web Services Architecture:
Fig: The Web Services architecture

Service Processes: This part of the architecture generally involves more than one Web service. For example, discovery belongs in this part of the architecture, since it allows us to locate one particular service from among a collection of Web services.
Service Description: One of the most interesting features of Web Services is that they are self-describing. This means that, once you’ve located a Web Service, you can ask it to ‘describe itself’ and tell you what operations it supports and how to invoke it. This is handled by the Web Services Description Language (WSDL).
Service Invocation: Invoking a Web Service (and, in general, any kind of distributed service such as a CORBA object or an Enterprise Java Bean) involves passing messages between the client and the server. SOAP (Simple Object Access Protocol) specifies how we should format requests to the server, and how the server should format its responses. In theory, we could use other service invocation languages (such as XML-RPC, or even some ad hoc XML language). However, SOAP is by far the most popular choice for Web Services.
Transport: Finally, all these messages must be transmitted somehow between the server and the client. The protocol of choice for this part of the architecture is HTTP (HyperText Transfer Protocol), the same protocol used to access conventional web pages on the Internet. Again, in theory we could be able to use other protocols, but HTTP is currently the most used one.
A Typical Web Service Invocation (redux)
So, let’s suppose that we’ve already located the Web Service we want to use (either because we consulted a discovery service, or because the Web service URI was given to us), and we’ve generated the client stubs from the WSDL description. What exactly happens when we want to invoke a Web service operation from a program?
Figure: A typical Web Service invocation (more detailed)

1.Whenever the client application needs to invoke the Web Service, it will really call the client stub. The client stub will turn this ‘local invocation’ into a proper SOAP request. This is often called the marshaling or serializing process.
2.The SOAP request is sent over a network using the HTTP protocol. The server receives the SOAP requests and hands it to the server stub. The server stub will convert the SOAP request into something the service implementation can understand (this is usually called unmarshaling or deserializing)
3.Once the SOAP request has been deserialized, the server stub invokes the service implementation, which then carries out the work it has been asked to do.
4.The result of the requested operation is handed to the server stub, which will turn it into a SOAP response.
5.The SOAP response is sent over a network using the HTTP protocol. The client stub receives the SOAP response and turns it into something the client application can understand.
6.Finally the application receives the result of the Web Service invocation and uses it.
Server Requirements for Web Service Application:
Finally, let’s take a close look at what the server looks like, specially what software we should expect to have to get Web services up and running on our server.

Web service: First and foremost, we have our Web service. As we have seen, this is basically a piece of software that exposes a set of operations. For example, if we are implementing our Web service in Java, our service will be a Java class (and the operations will be implemented as Java methods). Obviously, we want a set of clients to be able to invoke those operations. However, our Web service implementation knows nothing about how to interpret SOAP requests and how to create SOAP responses. That’s why we need a…
SOAP engine: This is a piece of software that knows how to handle SOAP requests and responses. In practice, it is more common to use a generic SOAP engine than to actually generate server stubs for each individual Web service (note, however, that we still need client stubs for the client). One good example of a SOAP engine is Apache Axis (this is, in fact, the SOAP engine used by the Globus Toolkit). However, the functionality of the SOAP engine is usually limited to manipulating SOAP. To actually function as a server that can receive requests from different clients, the SOAP engine usually runs within an…

Application server: This is a piece of software that provides a ‘living space’ for applications that must be accessed by different clients. The SOAP engine runs as an application inside the application server. A good example is the Jakarta Tomcat server, a Java Servlet and Java ServerPages container that is frequently used with Apache Axis and the Globus Toolkit.
Many application servers already include some HTTP functionality, so we can have Web services up and running by installing a SOAP engine and an application server. However, when an application server lacks HTTP functionality, we also need an…
HTTP Server: This is more commonly called a ‘Web server’. It is a piece of software that knows how to handle HTTP messages. A good example is the Apache HTTP Server, one of the most popular web servers in the Internet.