8.4 Case Study Design

Table 8-1. Quality of Services Analysis
 

Client

Presentation

Tiers Business

Integration

Resource

Application Platform Layer

User id and password are used for authentication

Control Servlet uses HTML and JSP for presentation and inquiry.

JSPs can be cached to enhance performance.

Java beans are used to implement some of the business logic.

The remote FX Quote Service is a black box, accessible via JAX-RPC.

N/A

N/A

Virtual Platform Layer

HTTP

HTTPS with SSL can be used for better security.

HTTP

HTTPS with SSL can be used for better security.

JAXM-TSIK Message Provider provides secure messaging transport for SOAP messages over HTTP.

JAX-RPC, JAXM are used to integrate different remote services.

JAXR is used to access the Service Registry

Upper Platform Layer

In the future, 128-bit SSL can be used for better security.

HTTP load balancing can be used for better scalability.

N/A

In the future, server clustering can be used for availability.

In the future, server clustering can be used for availability.

Lower Platform Layer

Basic Operating System security is provided with id and password.

N/A

N/A

N/A

N/A

Hardware Platform Layer

SSL accelerator can be added in the future for faster performance when using HTTPS.

Reliability and securability can be enhanced in the future with server hardening, firewall configuration, and hardware clustering.

Reliability and securability can be enhanced in the future with server hardening, firewall configuration, and hardware clustering.

N/A

Reliability and securability can be enhanced in the future with server hardening, firewall configuration, and hardware clustering.

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):

Figure 8-5. Interaction Between Single Sign-on Components

graphics/08fig05.gif

Login

The Login.jsp accepts the Client's user id and password for performing Single Sign-on. The Single Sign-on Servlet will generate a one-time session id and display in the URL (functioning as the parameter for the next servlet), as in http://localhost:8080/MMC/login/login.jsp;jsessionid=85881E55BC4467368B94B2EF0508DC02

Contents Servlet

The Contents Servlet generates a list of contents URLs (partner Web sites) as the menu page where the Client can choose to access.

Forward Servlet

The Forward Servlet forwards the Client to the target partner Web site URL once the SAML Assertion request is processed successfully and sufficient access rights are validated .

Ticket Desk

The Ticket Desk handles each SAML Assertion as a request ticket for each partner Web site access. It sends the SAML Assertion request to the Article Servlet of the target Web site for processing.

SAML Engine

The SAML APIs that handle SAML Assertion requests and respond to the Client requester.

Article Servlet

This is a module that handles forwarding the partner service Web site page to the Client upon successful Single Sign-on.

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.

Figure 8-6. Sequence Diagram for Single Sign-on Process

graphics/08fig06.gif

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.

Figure 8-7. FX Quote Web Services Components

graphics/08fig07.gif

Figure 8-8. Interaction Between FX Quote Service Components

graphics/08fig08.gif

Control Servlet

The Control Servlet acts as the Presentation Tier for user interaction to request an FX Spot Rate Quote.

Price Fetcher

The Price Fetcher sets the properties of the remote service end-point and operation name , and gets ready to invoke the remote FX Spot Rate Quote Service.

FXPrice

The FXPrice will find or discover existing Request for FX Spot Rate Quote Services from the UDDI Service Registry.

JAXRQueryByName

A function to query the UDDI Service Registry by name.

ProfileRequest

The ProfileRequest implements how to retrieve the currency name with a given currency code.

CurrencyProfile

This is the service call to ProfileRequest.

FXProviderIF

This is the interface file to FXProviderImpl.

FXProviderImpl

This is the implementation for the FXProvider, which creates a Web Services call to a remote Service Provider for a FX Spot Rate Quote.

OrgPublisher

This is a utility to publish the organization information into the UDDI Service Registry.

OrgRemover

This is a utility to remove the organization information from the UDDI Service Registry.

JAXRPublisher

This is the utility to invoke a JAXR publish API.

JAXRRemover

This is the utility to invoke a JAXR remove API.

ProfileServlet

The ProfileServlet parses the SOAP request (stored in the file "request.xml" ) using the JAXM/TSIK Message Provider.

SOAP_KeyStore

This is the key store (storing user credentials) used by TSIK Message Provider for secure SOAP messaging (for example, XML Encryption and XML digital signature).

JAX-RPC Run time

This is the stub or tie (skeleton) to support JAX-RPC.

JAXM/TSIK Run time

This is the TSIK API (stub or tie/skeleton) to support JAXM/TSIK secure SOAP messaging.

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.

Figure 8-9. Sequence Diagram for Request for FX Spot Rate Quote Process

graphics/08fig09.gif

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.

Figure 8-10. Sample Physical Architecture

graphics/08fig10.gif

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.

Figure 8-11. Sample Future Deployment Architecture

graphics/08fig11.gif



J2EE Platform Web Services
J2EE Platform Web Services
ISBN: 0131014021
EAN: 2147483647
Year: 2002
Pages: 127
Authors: Ray Lai

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net