J2EE Platform Web Services

Table 8-1. Quality of Services Analysis

8.4.3 Major Design Items

There are some major design items that need to be addressed in the technical design. We may not have answers to these questions for this case study yet. But they are good for consideration. These design items are also applicable to any major Web Services development.

Security. Should we use HTTPS with SSL only, or a mixture of HTTPS and WS-Security? Do we use hardware SSL Accelerator to enhance encryption and decryption performance?

It is more desirable to use HTTPS and WS-Security together. However, we use HTTP and WS-Security instead for instructional purposes. In this demo, we use VeriSign's TSIK to provide XML encryption and XML digital signatures over SOAP messages. For details, please refer to chapter 7 Web Services Security. In production, it would be better to use hardware SSL accelerator to enhance encryption and decryption performance.

Single Sign-on Approach. Assuming we adopt SAML (or Liberty's Single Sign-on specification using extended SAML) to implement Single Sign-on, should we use the approach of Federated Directory Server with Liberty-compliant agents (off-the-shelf components) or use Netegrity's jSAML-like toolkit to build home-grown components ? Liberty is a security specification defined by multiple technology vendors and industry communities to enable federated identity management and cross-domain Single Sign-on. It extends the existing SAML specification for Single Sign-on integration with Directory Servers. Sun ONE Identity Server 6.0 is currently the first commercial implementation that supports both SAML and Liberty functionality. Refer to http://www.projectliberty.org/ and Chapter 7, Web Services Security, for details.

There is no best answer to this question. However, for instructional purposes we choose to use Netegrity's jSAML toolkit to illustrate how to implement Single Sign-on with home-grown components.

Application Tooling. What kind of application tooling is necessary for successful Web Services development? When do we use any Application Server Analyzer, Java Unit Testing tool, Web Services Stress Testing tool, or TCP/IP monitor for Web Services?

Web Services application tools are very useful. Owing to resource constraints, we do not cover these tools in this Case Study.

XML Messaging Standards. Should we adopt industry-specific XML messages such as fpML, even though the remote Web Services engine may be using a proprietary XML message structure? Should we use XSLT (XML stylesheet processor) to transcode from a proprietary XML message structure to an industry-specific XML message structure?

As we do not require FX deal-order processing, we do not need to use any industry-specific XML messages such as fpML. If both industry-specific and proprietary XML messages are used, it would be useful to customize XSLT to handle the transcoding.

Private Label Customization. Where should we design and implement the customization components, especially for implementing Private Label customers? Should we duplicate different Control Servlets for each Private Label customer or use XML stylesheets?

We do not have any Private Label customization requirements in this Case Study. If we have, then we may need to consider a different technology approach. There is no best approach for every customization requirement.

Use of DOM/SAX Versus JAXP. For simple programs, should we use DOM or SAX directly, or should we use JAXP all through for consistency and portability purposes?

JAXP is better for portability.

Interoperability With External Systems. What Web Services functionality should we expose? This is a matter of coarse-grained versus fine-grained Web Services design. The design considerations for coarse-grained or fine-grained Web Services design include the number of APIs to be maintained and the extensibility and flexibility when developers need to modify the data structure or interfaces.

This Case Study only covers two Web Services (remote FX Spot Rate Quote and reference data retrieval), and it is out of its scope to elaborate on whether developers should adopt coarse-grained or fine-grained Web Services design.

8.4.4 Technology and Patterns Applied

Technology Applied

Open Standards technology JAX-RPC, JAXR, and WS-Security using Java Web Services Developer Pack and TSIK are illustrated in this demo. These technologies are also supplemented by a Single Sign-on technology built on top of jSAML Toolkit.

Design Patterns Applied

Two Design Patterns are applied: Model-View-Controller Pattern (J2EE Design Pattern) and Service ConsolidationBroker Integration Pattern (B2Bi Pattern). The former denotes that the Control Servlet acts as a Controller (Presentation Tier) for the Model (business logic) and different Views (data sources or remote Web Services). It provides a cleaner approach to decouple the business logic and data from the presentation. The latter denotes a typical Web Services deployment scenario where a Service Broker needs to consolidate and aggregate information from multiple data sources (or remote Web Services).

Single Sign-on Design

The following components work together to provide Single Sign-on capability (see Figure 8-5):

The sequence diagram in Figure 8-6 further depicts the detailed process between the Client and different components of the Single Sign-on process in Figure 8-5. This includes:

1. The Client enters user id and password to sign on.

2. The Login process will create a one-time session id and cookie. It will redirect the Client to a login page and pass control to the Contents Servlet.

3. The Contents Servlet generates a contents page (aka menu page) with a list of partner Web site URLs.

4. The Contents Servlet will return the newly generated contents page to the Client.

5. The Client clicks on the contents page links and submits request.

6. The Forward Servlet will create a SAML Assertion request and send it to the Article Servlet.

7. The Article Servlet makes a call-back to the Ticket Desk with the SAML Assertion request. This ensures the appropriate trading partner has received and acknowledged the request.

8. The Ticket Desk provides the associated SAML Assertion request again to the Article Servlet.

9. The Article Servlet processes the SAML Assertion request and redirects the target partner Web site page to the Client if access is granted.

8.4.5 FX Quote Service Design

The following components work together to provide FX Quote Service capability. They help to explain the service components in Figures 8-7 and 8-8.

Figures 8-7, 8-8, and 8-9 further depict the detailed process between the Client and different components of the Request for FX Spot Rate Quote process. This includes:

1. The Client specifies the Sell and Buy Currency using 3-letter ISO currency codes.

2. The Control Servlet creates a proxy to get an FX price based on the cross-currency pair.

3. The FX Price looks up the UDDI registry to locate the remote FX Spot Rate Quote Web Services Service Provider.

4. Once the remote Web Service is found, the FX Price will bind the service with the service end-point URL.

5. The FX Price will then invoke the remote Web Service via FXProviderIF.

6. The FXProviderIF will use FXProviderImpl to invoke the remote FX Spot Rate Quote Service. FXProviderImpl will fetch the spot rate from the remote Service Provider and return it to the FXPrice via JAX-RPC. The FXPrice returns the Spot Rate Quote to the Control Servlet.

7. The Control Servlet creates a proxy to look up the Buy Currency name from CurrencyProfile via ProfileRequest.

8. The Profile Request looks up the currency name using Profile Servlet via JAXM with TSIK secure message provider.

9. The ProfileServlet returns the currency name in a text to Profile Request, then to the Control Servlet. The Control Servlet displays the FX quote and the currency name to the Client.

8.4.6 Physical Architecture

Based on the logical architecture depicted in Figures 8-4 and 8-7, we may derive a physical architecture that is ready for deployment based on the Service-Level Requirements. Assuming the transaction processing requirements of handling 300,000 Request for Quotes per day and the need to support 24 X 7 X 365 high-availability requirements, we may recommend the following physical architecture:

• Two load balancers for handling HTTP traffic

• Three Web Services (FX Spot Rate Quote Service, reference data or profile retrieval, and UDDI discovery service) to handle HTTP requests from client browsers

• Two instances of Application Servers to host the business logic to support High Availability

• Two instances of Reference Data servers to host the common trade reference data to support High Availability

• Two instances of Database Servers using Sun Cluster to host all FX trade transactions to support High Availability

• Two optional servers in the future to host the Directory Servers and Service Registry

The physical architecture diagram in Figure 8-10 is a sample for instructional purposes. It does not trace back to the Service Level Requirements.

In reality, we need to conduct a hardware sizing exercise to analyze the data requirements, transaction volumes , and application resource requirements before we derive the physical architecture. Besides, the hardware sizing needs to trace back to the Special Requirements (which is Service-Level Requirements) in the Use Cases.

8.4.7 Future Deployment Architecture

The logical and physical architecture diagrams depicted in Figures 8-4, 8-7, and 8-10 refer to the Use Case based on a simplified demo scenario. Once the demo system is ready to extend to a full-scale production scenario, we may need to include other enterprise components so that they can be operational to support 24 X 7 X 365 non-stop services.

The sample deployment architecture in Figure 8-11 shows a possible deployment when the demo system is extended and integrated in a typical financial institution's Enterprise Architecture, where there may be different delivery channels supporting SMS, WAP phone, Fax and email, and interfaces with the external parties, such as the Stock Exchange and Market Data feed providers. Figures 4-4 and 4-5 have some discussion of this sample future deployment architecture. The integration of the Web Services components will be handled either by a public or private Service Registry and a SOAP RPC Router. It is beyond the scope of this Case Study to cover all aspects of integration.