Understanding and Working with Web Services
Web services are loosely coupled, reusable software components that semantically encapsulate discrete functionality and are distributed and pro grammatically accessible over standard Internet protocols. It can be accessed pro grammatically. Unlike web sites and desktop applications, web services are not designed for direct human interaction, and they do not have a graphical user interface. Web Information which is available through a Web Service will always be accessed by software, never directly by a human. Even though Web Services rely heavily on existing Web technologies (such as HTTP, as we will see in a moment), they have no relation to web browsers and HTML. Always remember “websites for humans, Web Services for software”
Web services are distributed over the Internet. Web services make use of existing, ubiquitous transport protocols like HTTP. Web services leverage existing infrastructure and can comply with current corporate firewall policies.
Understanding Web Services
What is Web Services?
Web services are Web-based enterprise applications that use open, XML-based standards and transport protocols to exchange data with calling clients.
Let’s understand it with very common example which is widely used at many places in the world. Consider an agency which provides weather information on the basis of requested pin code.
The clients (programs that want to access the weather information) would then contact the Web Service (in the server), and send a service request (pin code) asking for the weather information. The server would return the forecast through a service response.
Now, the very next thought in the mind is that “this process can also be performed by RMI, EJB, CORBA and many other existing web technologies. Then, why Web Services?
Well, web services have certain advantages over other technologies:
- Web Services are platform-independent and language-independent, since they use standard XML languages. This means that the client program can be programmed in C++ and running under Windows, while the Web Service is programmed in Java and running under Linux.
- Most Web Services use HTTP for transmitting messages (such as the service request and response).This is a major advantage if you want to build an Internet-scale application, since most of the Internet’s proxies and firewalls won’t mess with HTTP traffic (unlike CORBA, which usually has trouble with firewalls).
Along with these advantages, web services also have some disadvantages…
- Overhead. Transmitting all your data in XML is obviously not as efficient as using a proprietary binary code. What you win in portability, you lose in efficiency. Even so, this overhead is usually acceptable for most applications, but you will probably never find a critical real-time application that uses Web Services.
- Lack of versatility. Currently, Web Services are not very versatile, since they only allow for some very basic forms of service invocation. CORBA, for example, offers programmers a lot of supporting services (such as persistency, notifications, lifecycle management, transactions, etc.).
Invocation of Web Services
- A client may have no knowledge of what service is going to invoke. So the first step is to discover a web service that meets requirements. We’ll do this by contacting discovery service (which is itself a Web service). The discover service will reply, tells what servers can provide the required services.
- Now, we know the location of the service but no idea, How to invoke the service. For this we have to ask to service to describe itself, the web service in a language called WSDL (Web Services Description Language).
- Now finally we know where the service is located and how to invoke the service. The invocation is done in a language called SOAP (Simple Object Access Protocol). So client will first send a SOAP request to web service , in response to this request the service will reply with a SOAP response.
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 (Hyper Text 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.
The highly acceptable approach of web services developers is to first write WSDL file. Once we’ve reached a point where our client application needs to invoke a Web Service, we delegate that task on a piece of software called a stub. The good news is that there are plenty of tools available that will generate stubs automatically for us, usually based on the WSDL description of the Web Service.
Using stubs simplifies our applications considerably. We don’t have to write a complex client program that dynamically generates SOAP requests and interprets SOAP responses (and similarly for the server side of our application). We can simply concentrate on writing the client and/or server code, and leave all the dirty work to the stubs (which, again, we don’t even have to write ourselves… they can be generated automatically from the WSDL description of a web service).
A Typical Web Service Invocation
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? This is depicted below
- 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.
- 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)
- 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.
- The result of the requested operation is handed to the server stub, which will turn it into a SOAP response.
- 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.
- Finally the application receives the result of the Web Service invocation and uses it.
The server side of Web Services
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.
The server side in a Web Services application
- 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 (http://ws.apache.org/axis/). 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 (http://jakarta.apache.org/tomcat/) server, a Java Servlet and Java ServerPages container that is frequently used with Apache Axis. 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 (http://httpd.apache.org/), one of the most popular web servers in the Internet.
(Web Services Container = SOAP Engine + HTTP Server + Application Server)
In next post , we will cover Installing and set up of Apache Axis web services