Web Services Fundamentals

The technical field of Web services brings with it its very own set of terminology and jargons. Because of the modern heritage of Web services technology, this set of terminology is independent of those of Java development, server-side development, and even J2EE development.

As a Geronimo administrator, you will need to be versed in this terminology to communicate effectively with developers, application assemblers, and Web services users. This initial section of the chapter introduces the following:

• The basic concepts in Web services, especially as they pertain to J2EE

• Why Web services are very important

• When and where Web services may be used

• How the Geronimo server supports Web services

Anatomy of a Web Service

Fundamentally, a Web service operates through the exchange of messages, typically over the HyperText Transport Protocol (HTTP and its secured SSL-based variant).

Important

Although Web services can theoretically be carried over transport protocol other than HTTP/HTTPS, this is seldom done in practice.

HTTP is the enabling protocol of the World Wild Web and is well supported by the Internet, as well as today’s enterprise networks. Using HTTP as the transport protocol allows Web services to leverage the well-established network infrastructure to pass its messages. Other additional benefits of using HTTP as the transport protocol include the following:

• Ability to communicate through firewalls (most firewalls are designed to pass HTTP traffic)

• Support and diagnostic expertise is widely available

Unlike most network communication protocols (where the messages actually passed are in binary), the messages passed by Web services are in XML format. More particularly, the messages passed are formatted according to an industry standard called Simple Object Access Protocol (SOAP).

XML, SOAP, and JAX-RPC

Typically, a Web service client invokes a Web service by sending a message. This message specifies the details of the request, to be processed by the Web service. The Web service is responsible for sending the response back to the client after processing. Again, the response is sent back to the client via a Web service message. This pattern of interaction is often called a Request Response Message Exchange Pattern (MEP).

To process the incoming request, the Web service may elect to forward the message to another processor to do all or a portion of the work. The message format(s) specified by the SOAP protocol is designed to facilitate this style of message passing. Figure 14-1 shows the sequence of events that occurs when a Web service is invoked by a Web service client.

Figure 14-1: Web service interactions

In Figure 14-1, the Web service client finds out about the feature of a Web service via its description. A Web service’s description is captured in an XML document, created to a World Wide Web Consortium (W3C) standard format called Web Service Description Language (WSDL).

The Web service client itself can be written in any programming language - it does not have to be Java. In fact, other operating system and platforms, such as Microsoft’s .Net on Win32 systems, have very rich support for creation of Web service client. Script languages such as Python and Grovvy can also be used to easily create Web service client.

Based on the description in the WSDL, the Web service client can then create properly formatted SOAP messages and send them to the Web service for processing. The features of a Web service are described in the form of a Web service interface. A Web service interface contains method names and parameter descriptions that enable the client to formulate messages to call methods on the interface. Again, the message is sent over HTTP.

On the Web service end, the service logic must decode the incoming SOAP messages. It then must process the message and formulate a SOAP message response. This response message is sent back to the client after processing, via the response mechanism of HTTP.

Note that Web services leverage the Request Response MEP inherent in the HTTP protocol (supported by all Web browsers) to invoke functionality exposed by the Web service. Instead of sending a request for a Web page (as in Web browsing), it sends a SOAP message that invokes Web service features. Instead of receiving a Web page as a response (as in Web browsing), it receives the processing response from the Web service.

It may appear from this description that creation of Web services and clients will require a lot of XML message parsing and manipulation. However, with the support of modern development tools, this is often not the case.

For example, if the Web service (or Web service client) is to be implemented using the Java programming language, a J2EE technology called Java API for XML Remote Procedure Call (JAX-RPC) can greatly simplify the creation of Web service and its associated client. JAX-RPC simplifies the process by completely automating, and, therefore, eliminating the need for the implementation code to parse XML. Figure 14-2 reveals how JAX-RPC does its work, in the context of a J2EE 1.4 compatible server such as Geronimo.

Figure 14-2: JAX-RPC simplifies coding of Java Web services and Web service clients

In Figure 14-2, the JAX-RPC run-time support mechanism intercepts between the Java-based Web service client and the Java-based Web services implementation. Instead of working with a complex XML-based description of the Web service interface, Java code written to JAX-RPC can work with a programming interface in the Java programming language. This interface is called s Service Endpoint Interface (SEI).

Service Endpoint Interface (SEI)

The Web service client code, written in Java, in Figure 14-2 makes a local (non-networked) call to the method foo(). The method foo() is one of the method on the SEI Java interface. The client code need not know in advance that it is actually making a remote call to a Web service.

A JAX-RPC generated run-time component, a stub, intercepts this local call and prepares the SOAP message that is required to access the remote Web service running in Geronimo. After preparing the SOAP message, the stub sends the message via HTTP to the Web service running on Geronimo.

On the server end, the picture is quite similar. The Web service implementation is simply a software component written in the Java programming language that implements the SEI. Since the SEI is in Java, implementing the SEI is straightforward and does not require any XML parsing or tricky wiring performed by the service logic. Instead, the service logic only has to provide an implementation for the foo() method of the SEI.

Another JAX-RPC generated component, the interface proxy/tie component, will receive the SOAP message coming in from the Web service client, decode it, and then invoke the foo() method on Web service implementation. Return values, traveling from the Web service back to the client, are SOAP response messages that are created by the proxy/tie and received by the stub on the client side.

In summary, JAX-RPC provides standard Java-calling semantics support between Web service and Web service client writing in the Java programming language.

However, since the client side and Web service side of the JAX-RPC are essentially independent, JAX-RPC Web services can be consumed (invoked) by any Web service client - and not restricted to just Java-based clients. This will, of course, require the generation of a WSDL to be used by the non-Java-based client. JAX-RPC includes the capability to map SEI to WSDL. Figure 14-3 illustrates how JAX-RPC enables interoperation with non-JAX-RPC client.

Figure 14-3: JAX-RPC interoperation with non-Java Web service clients

In Figure 14-3, the Java-based Web service logic component implements the foo() method on the SEI (a Java interface). JAX-RPC provides the Web service interface implementation and handles the parsing and decoding of SOAP messages. Meanwhile, any Web service client (even if they are not written using JAX-RPC or Java) can access the foo() method implementation by sending SOAP request message over HTTP to the Web service hosted in Geronimo.

Web Services and Geronimo

Right about now, you may be wondering how Web services relate to the Web-tier and business-tier components that have been discussed thus far in J2EE. The answer to this question also reveals how Geronimo supports Web services.

First, since Web-tier and business-tier components are all written in the Java programming language, they can readily take advantage of JAX-RPC’s ability to access any Web service. This means that application components in Geronimo, in business or Web tier, can consume external Web services.

More interesting to Geronimo server administrators, however, is the ability of Geronimo to expose functionality as Web services. Figure 14-4 shows the possibilities.

Figure 14-4: Geronimo server exposing application components as Web services

In Figure 14-4, you can see two Geronimo-hosted application components being exposed as Web services. The EJB interface of a business-tier EJB (typically a stateless session bean) can be exposed via Geronimo as a Web service. Essentially, the SEI is the EJB interface.

Another application component, a Web tier servlet, can also expose a Java-based interface (a JAX-RPC SEI) that can implement a Web service to be hosted by Geronimo.

Internally, Geronimo makes use of the JAX-RPC server-side support provided by Apache AXIS to process the incoming SOAP requests.

Clients consuming the Web service must process the associated WSDL to understand how to invoke the Geronimo-hosted Web services. This WSDL must be generated by the developer from the SEI of the component.

Improtant

Note that Release 1.1 of the Geronimo server does not come with the tools required to create and generate code for JAX-RPC to WSDL mapping. As a result, you are likely to be working with WAR and EAR Web services modules that are created using another J2EE server’s tool such as those provided by Sun’s Java Web Service Developers Pack (JWSDP) (http://java.sun.com/webservices/jwsdp/index.jsp) reference implementation.

One important thing to note in Figure 14-4 is the grayed out component(s) called business logic implementation. What this figure attempts to show is the fact that the component that implements the SEI is typically not the only component involved in providing the Web service feature. In fact, the component providing the SEI is just the entry point component into the J2EE application logic-which in itself may involve tens or hundreds of other application components. An example may be a query Web service (handled by a servlet implementing the SEI) that utilizes the business Logic implementation to search a large airline reservation system. In this case, the Web service component is a front end, or faade, for the larger system.