Michael Gilfix Online

Work's been keeping me very busy lately. So, I plan on writing about a commonly asked question around the new converged HTTP/SIP capabilities in WebSphere Application server (WAS) V6.1. So first, what is a converged service? A converged service is an application that spans communication over multiple protocols to provide higher level function. In the case of the HTTP & SIP protocols, a converged service joins together session information from both protocols, allowing interactions over one protocol to influence communication over the other (subjects to the constraints of the protocol). WAS provides a Servlet programming model for both HTTP & SIP. Unification of those protocols is achieved though a converged web container solution, whereby sessions for both protocols may live in a single parent "application session" instance under the covers -the application session concept being first introduced as a SIPApplicationSession concept in the JSR116 SIP Servlet programming model.

The basic benefit to converged services? For SIP enabled applications, HTTP provides an ideal control protocol for communication with SIP signaling logic, which may participate in many different sessions, and may be constantly sending and receiving signaling messages asynchronously out the back-end. However, SIP also supports the notion of a basic request and response exchange, so what makes HTTP so ideal? First, you don't have to deal with the unreliability in SIP in a situation where decisive action is needed. But then enter Web Services. Central to Web Services is the notion of a Web Service Definition Language (WSDL) document that describes the structure of the request being issued. While you can always stuff a bunch of XML into an HTTP or SIP request to communicate with the application, WSDL provides the formal structure to allow you to communicate that interface to others. This approach also provides a path to interoperability with other programming stacks.

When people typically think of Web Services, they think of remote calls that cross system boundaries and typically networks. Web Services is also typically used with the design philosophy of Service-Oriented Architecture (SOA), which suggests encapsulating a bunch of business logic and function as a callable service with a more granular interface. A huge advantage of Web Services is how is supports a loosely coupled componentization model. This can be a boon for developing flexible, scalable systems that support dynamic selection of function at runtime; Web Services can effectively be used to bind together internal components of the system as well as exposing more granular services. This technique of binding together the system also supports a very flexible packaging model. In J2EE parlance, components can be bundled as multiple WAR files in a single EAR or as a set of EARs, where each EAR contains a single and very self-contained component.

The usual concern with this approach of moving one step down in granularity from the service level is one of performance: in the CPU cost and latency of making the Web Service invocation. This is where local Web Services optimization comes in. Within a cluster of application servers, all components can be distributed to each application server; each application server contains a copy and executes all the code for each components. In this example, each component is packaged in its own EAR -this comes with advantages discussed below. When calling shared components, the fronting service or component is configured with a local endpoint is given to the Web Service runtime: http://localhost/foo/endpoint. Each copy of the service code makes an invocation with the localhost endpoint, thereby hitting local code.

As Web Service component models become more prominent (thanks to the push for Service-Oriented Architecture (SOA) style of design), more and more J2EE applications are starting to contain dynamic client-side Web Services that link together many SOA capabilities. Such applications make use of dynamic Web Services in that the endpoints for the Web Service are only known at runtime -perhaps as a result of user profile information or dynamic configuration.

The most common and widely used way to perform Web Service client invocations is through the use of a stub, using the model described in JSR 109. An auxiliary tool, such as WSDL2JAVA, is used to read the WSDL description of the Web Service interface and generate Java code that can be used to call the Web Service. This code presents itself to the user in the form of a Stub, which is a piece of code whose interface hides the entry point into the Web Services runtime used to make the actual invocation. Typically, the stub contains operations and arguments that map between XSD schema types and Java types; the idea being to hide the details of the Web Service invocation infrastructure from the programmer. Note: some of this will be alleviated by the new JAX WS specification for Web Services, described in JSR 224.