An Example of Application Servers and Web Services

In this example, the retail clients and in-house clients of a financial company use the portfolio management portal to monitor their investments. The front-end of the portal is built using Microsoft technology (Active Server Pages (ASPs), Internet Information Services (IIS) Web Server, and VB Script; note that although these are not .NET products, the approach is essentially the same). One of the features provided within the portal application is quote information. Using this feature, the clients can retrieve real-time quotation for any stock. When the client requests a quote for any stock, the request is sent from the browser to the Web Server.

The quote service is provided as a Web Service by a middleware application within the company to multiple clients, with our portfolio management portal being just one of those clients. Another client, as shown in the figure, is a VB application.

The information about Web Services offered by this middleware application is obtained from the private internal UDDI registry and invoked over the intranet. The implementation of the business methods exposed by the Web Service is provided by EJBs contained in another Application server.

This is a typical example of cross-platform application server integration using Web Services. The binding information for frequently used Web Services, such as those for requesting quotes, can be cached by the client application, to avoid the resource intensive and time consuming dynamic binding. In this example, Web Services loosely integrates the portfolio management (Microsoft technology-based) application with the (J2EE-based) middleware application that interfaces with the Mainframe to receive the quote.

The sequence of steps is as follows:

1. The user requests quotes for a specific company on an Web front-end that is passed over to the portfolio management portal running within Microsoft IIS. Here for sake of simplicity it is assumed that the user has already successfully logged into the application and has a valid session established.
2. The .NET-based portal application gets information about Web Services made available by the J2EE-based middleware application by doing a look up in the private UDDI registry.
3. The location of and WSDL binding information for Web Services is sent to the portal application as a SOAP-based message.
4. The portal application invokes the Web Service published by the middleware application, passing the stock symbol as a part of a SOAP-based message.
5. The actual implementation of the Web Service is provided by EJBs running within another J2EE-based application server. The EJBs use the JDBC API to get information from the data source, which in this case is IBM's DB2.
6. The EJBs send the Web Services response to the portal application as a SOAP-based message.
7. The response is formatted in XSLT/HTML format and sent back to the client browser-based application.
8. Another VB custom application within the company intranet invokes the same Web Service, thereby being another client of the quote Web Service. The communication happens based on SOAP.