8.4 Case Study Design

8.4.1 High-Level Design

A Web Services architecture ( please also refer to Chapter 4, Web Services Architecture and Best Practices) typically consists of a Web Services Consumer (who uses and invokes the services), Web Services Service Registry (which provides a directory of business services available and points to their service end-point URLs) and Web Services Service Provider (the business functionality provided to serve the consumers).

The Web Services Consumer finds or discovers different business services from the Web Services Service Registry. In this case, the Web Services Consumer wants to find a Request for FX Spot Rate Quote Service. The Web Services Service Registry hosts all business services information, such as organization name and service end-point URLs where these services can be found. Web Services Service Providers previously publish or register with the Service Registry. Once the Web Services Consumers finds the required business service, the system will bind the service end-point and invoke the business service.

In this demo, we have chosen Sun Microsystems's Java Web Services Developer Pack. It comes with Tomcat 4.0, Xindice database, and UDDI Service Registry. We have also used Netegrity's TSIK as the secure message provider. Please refer to Figure 8-2 for the high-level design. The Web Services Consumer uses JWSDP and TSIK on top of the Tomcat Web server to find/discover business services from the Web Services Service Registry. The Service Registry is implemented using JWSDP with a Xindice server on top of the Tomcat Web server. The Web Services Service Provider registers with the Service Registry and publishes business services to the Service Registry, which can be invoked by the Web Services Consumer.

Figure 8-2. FX Spot Rate Quote Web Services Relationship

We need to identify the Open Standards messaging protocols used for the interaction between different components . From a high-level perspective, we have five major entities: Clients, Control Servlet (aka Front Controller to handle Presentation- Tier requests ; The concept of Front Controller is discussed in Alur, Crupi, and Malks ([2001], Core J2EE Patterns , p. 172), Currency Profile (or Reference Data), FX Price Provider (Service Provider for the FX Spot Rate Quote Service), and the Registry Server. The interaction between these components is depicted in Figure 8-3. The Service Requester (client) accesses the Web Services from the Front Controller via HTTP. The Front Controller acts as a SOAP client to look up the business services dynamically using JAXR, retrieves reference data (currency profile) using JAXM, and invokes remote business service (FX currency rate quote) using JAX-RPC.

Figure 8-3. Interaction Between Components

We have chosen to use HTTP instead of HTTPS between the Client and the Control Servlet, because it is easier to configure for instructional purposes. From the Control Servlet, requests and messages are sent in secure SOAP messaging using the TSIK message provider. This denotes that Reference Data such as currency code will be transmitted securely over HTTP. Any service lookup, publish, or removal from the registry request to the Registry Server will be using JAXR so that it can shield off from registry-specific APIs or codes. This will ease migration to ebXML Service Registry or switch to another UDDI Service Registry in the future. Between the Control Servlet and the FX Price Provider, we decide to use JAX-RPC as we assume we need a synchronous connectivity to the remote Service Provider.

8.4.2 Logical Architecture

Based on the Use Case scenarios (as in Figure 8-1), we have come up with the following logical components using the Tomcat Application Server platform (also refer to Figure 8-4).

Figure 8-4. Logical Architecture for FX Spot Rate Quote Service

Controller	User interface for Clients to perform Single Sign-on, and specify the Sell and Buy Currency codes to request an FX Spot Rate Quote. This is similar to the Front Controller pattern described in Alur, Crupi, and Malks ([2001], Core J2EE Patterns , p. 172).
Single Sign-On Components	These Single Sign-on components are derived from Netegrity's jSAML Toolkit. They include Login Servlet, Contents Servlet, Forward Servlet, Ticket Desk, Article Servlet, and the SAML engine on the Service Provider's side.
Service Registry	This resembles the UDDI Service Registry that comes with the Java Web Services Developer Pack. It is UDDI 2.0 “compliant.
Web Container	In this demo, the run-time Web Services engine is Apache Tomcat Application Server 4.1.2. It supports JSP and servlets.
Remote Web Services	These remote Web Services resemble different back-end systems, including Liquidity Engine (aka FX deal system that handles request for quote, deal order management, and so forth), Market Data server (which takes in FX feeds from the Stock Exchange), and Reference Data (such as a currency code description). These systems may reside on a legacy mainframe or be remotely hosted by another Service Provider. The Control Servlet takes in a client request and invokes a remote Web Service (via Server Tie or Skeleton) using the Client Stub.
Article Servlet	This is a module that handles forwarding the partner service Web page to the Client upon successful Single Sign-on.

The Quality of Service matrix in Table 8-1 denotes an analysis of different logical components, how they provide scalability, reliability, and availability today, and how they can be extended in the future. Chapter 4, Web Services Architecture and Best Practices, also discusses how to perform a Quality of Services analysis for a Web Services architecture. Although this is a small-scale demo sample, it is educational to illustrate the "ilities" aspects of the Case Study architecture.

The different platform layers refer to different layers of the software stack, from Hardware Platform Layer (for example, hardware and storage), Lower Platform Layer (for example, Operating System), Upper Platform Layer (for example, Application Server), Virtual Platform Layer (for example, middleware) to Application Platform Layer (for example, business applications). The different tiers refer to different components that can be categorized by the physical boundaries of hardware and software products, from Client Tier (for example, Web browser), Presentation Tier (for example, Web Server), Business Tier (for example, EJBs), Integration Tier (for example, messaging services) to Resource Tier (for example, database). Details of these architecture classifications can be found in Unified Process (e.g., http://www.omg.org ) or SunTone Architecture Methodology (refer to Sun Professional Services (2001) Dot-com and Beyond , pp. 67 “98.)