4.4 What Is a Reference Architecture?

In this book, a reference architecture has the following characteristics:

  • Underlying Architecture Framework ” This provides a structure (meta-architecture) that defines the logical and physical components that constitute the business services, and the processes used to develop it.

  • Architectural Principles ” These are rules and guidelines that help design and govern scalable, reliable architecture.

  • Design Patterns ” These are models that tell when and what technology to use.

  • Supporting Software Tools ” A reference architecture is not a laboratory product. It should have supporting commercial implementations and off-the-shelf vendor products. An overview of what product solution options are available.

Apart from the development methodology, the Vnified Process also provides a good approach to define and depict architecture, for instance, in terms of tiers and layers . This book will leverage on the architecture views and concepts to define reference architecture for Web Services technology.

4.4.1 Architecture Framework

A meta-architecture abstracts what the architecture components should have, so that the architecture can be easily extended or simplified based on the business needs. The meta-architecture is to the architecture as grammar is to a language. Nevertheless, it may sound too abstract or unnecessary for some practitioners .

A good meta-architecture should be product- and platform-neutral. Product architecture provides product-specific components. An application can derive the application architecture from a meta-architecture based on the business architecture (for example, data architecture and business object modeling) and technical architecture (for example, vendor products and physical infrastructure) components of the business system functionality.

Reference architecture can be defined for each domain based on a meta-architecture (for example, online securities trading) and used as a blueprint for designing and building applications. It provides a better context and vocabulary for developers and practitioners.

Sun ONE TM is a good example of a meta-architecture. It defines a Web Services architecture with seven meta-components (for lack of a better word), with each having different architecture components to interact with one another. Figure 4-1 shows the first published example of a Sun ONE Web Services architecture ”Zefer. Each meta-component (for example, identity and policy) consists of different components and services, (for example, directory services, privacy, and policy). Service Delivery components (for example, delivery channels) may have multi-channel gateways (for example, Web wireless access and WAP). Services components (Web Services) may have an accounting system, such as a billing engine. Service Management components provide provisioning of business services (such as allocating an IP address to a wireless J2ME device), monitoring of the service level, and metering the business services for services billing. Service process components (for example, service orchestration) are the integration channels to the back-end systems or external trading partners .

Figure 4-1. Zefer's Web Services Architecture With Sun ONE Framework

graphics/04fig01.gif

Service Requesters (or consumers) may be accessing the business services from a variety of mobile devices or a browser. This belongs to the consumer domain. All other architecture components are part of the Service Provider domain. A client may use a phone to inquire about his account balance, where the relevant Web Services components will process the balance inquiry and perform transcoding for different client devices wherever necessary. A client may receive his account balance from his PDA, WAP phone, or another device based on his personalization profile.

Figure 4-2 depicts a detailed Web Services architecture Zefer has adopted. In the Service Delivery component, there is a controller servlet that can handle service requests from the Service Requester's mobile devices or browser. The Service Requester will initially look up the business service from a service directory (in this example, it is a UDDI registry) via the service directory proxy.

Figure 4-2. Zefer's Web Services Architecture

graphics/04fig02.gif

If this is a SOAP call, the controller servlet will pass control to the processor, which will then pass the SOAP service request to a service proxy (SOAP client proxy). The service proxy is a client stub and will communicate with the RPC router servlet (SOAP server). The RPC router servlet, which runs under a service container (such as J2EE application server), will determine whether this is an RPC call (service proxy), RMI-IIOP call to EJBs (EJB proxy), or another asynchronous message provider (JMS proxy).

Any business data returned from the RPC router servlet will be captured by the service proxy in XML format. The presentation manager can reformat the data and transcode into HTML, or WML using XSL if applicable . This enables the Service Requester to view in a format that is displayable on any mobile device or browser.

4.4.2 Architecture Methodology and Development Life Cycle

Unified Process has a structured approach or methodology to define and analyze any architecture (including Web Services) by tiers, layers, or platform with different views. Rational Unified Process from IBM Rational is one of the commercial implementations commonly used in the IT industry. Large vendors usually have a customized version of Unified Process-based methodology (for example, Sun's SunTone Architecture Methodology). The Unified Process methodology defines different stages of IT development, ranging from the Inception phase (where requirements are defined), the Elaboration phase (where design or proof of concept is done), the Construction phase (where software is being built), the Transition phase (where software is being configured and deployed), the Production phase (where software enters into service), and the Retirement phase (where software reaches end-of-life). http://www.enterpriseunifiedprocess. info shows an example of the Unified Process methodology.

Architecture is usually defined during the Inception (for example, reference architecture, logical components) and Elaboration (for example, detailed application architecture design) phases of a development life cycle. It is important to trace back the architecture design from the functional requirements ”that is, validate each architecture component from the functional requirements and service level. For instance, you would not have a component (say, personalization server) that is not supported by requirements.

The architecture methodology and development life cycle are generic to application development, including Web Services technology. The following diagram depicts an example of different activities of the architecture methodology with respect to the development life cycle.

Figure 4-3 shows an example of a Web Services development life cycle using the Unified Process development methodology. A Web Services project should be no different from any other IT project. A Web Services project usually starts with defining the business vision and strategy (Inception phase), then moves to crafting the architecture design (Elaboration phase), developing the integration and interoperability modules, integrating with the back-end systems and trading partners (Construction phase), testing, and finally deploying to production (Transition phase). Due to the nature of Web Services technology, there may be less development effort, but more integration effort and interoperability testing.

Figure 4-3. Web Services Development Life Cycle

graphics/04fig03.gif

4.4.3 Example ”Securities Trading Reference Architecture

Figures 4-4 and 4-5 show an example of a reference architecture for securities trading, with the two diagrams showing servers and logical components respectively.

Figure 4-4. Securities Trading Reference Architecture ”Server Level

graphics/04fig04.gif

Figure 4-5. Securities Trading Reference Architecture ”Logical Components

graphics/04fig05.gif

Figure 4-4 depicts a server-level architecture view of a securities trading (or brokerage) firm that adopts Web Services technology. The architecture components are categorized into five different tiers based on their functionality or role (these five tiers are depicted in SunTone Architecture Methodology under http://www.sun.com/service/sunps/jdc/suntonearchmethod.html ). Between the tiers, there are usually separate routers (thus creating different IP subnets) and firewalls that segregate the servers for security and network management reasons.

The Business Tier contains service components that provide the core business logic. Here, the core online securities trading applications run on clustered J2EE application servers. A private Service Registry (for dynamic service look-up), a set of SOAP servers (acting as a service proxy to back-end legacy systems or remote trading partners' systems), and a market data server (for publishing foreign exchange rates and latest stock prices) also reside in the same Business Tier.

The Integration Tier hosts the integration components (such as messaging bus), gateways (such as Host Gateway for legacy mainframe systems, and Exchanges gateway for Stock Exchanges), and security components (such as Directory Server and Policy Server). The Host Gateway provides a channel to invoke applications running on legacy mainframes. There is also an Exchanges gateway, which acts as a channel to execute trade orders with local exchanges (such as NASDAQ and JASDAQ) or other markets (such as Instinet, which is an Electronic Communication Network), subscribe market data from market data feeds providers (such as Reuters or Bloomberg), and clear trade orders with local clearing organizations (such as Hong Kong Exchange, Deposit Trust, and Clearing Corporation). The Directory Server provides enterprise-level authentication. The Policy Server stores access rights and policies that govern the access level of each service component or system by users and by roles. These security components actually span different tiers.

The Resource Tier typically hosts all data stores (such as customer account master and trade data residing on a database server running a relational database), data warehouse, Enterprise Resource Planning (ERP) systems, and legacy mainframe applications. These resources may physically reside on a Storage Area Network (SAN) for better data availability and management.

On the client side, the Client Tier consists of any client front-end that accesses the online securities trading functionality. This includes browser, rich client (such as Java SWING client), and mobile devices (such as PDA and WAP phones).

The Presentation Tier handles HTTP requests from the client side, processes the presentation logic, and transforms it into some other messaging format. This includes the HTTP Web servers (handling static Web pages), a portal server (personalizing contents and aggregating information), and messaging servers (such as SMS server or WAP gateway).

The SOAP server and UDDI Service Registry are two key architecture components that characterize a Web Services architecture. In this example, Web Services technology is used for internal applications, not for public consumer use. The UDDI Service Registry is used as a private Service Registry and thus reduces the risk of external security attack. For similar reasons, both the SOAP servers and UDDI Service Registries reside in the Business Tier. If Web Services are provided to public consumers, then the UDDI Service Registry (public Service Registry) and SOAP server are likely to reside in the Presentation Tier. Segregating the SOAP server and UDDI Service Registry from the application server can lower the security risk of all servers being exploited.

The architecture components in Figure 4-4 are described as follows :

Web Servers. HTTP Web server farms that handle HTTP requests (such as Web pages navigation) from the browsers or mobile devices

Portal Server. Provides personalization of contents and channels to aggregate information contents and/or transactions

Messaging Servers. Delivery channels for emails (SMTP), pagers (SMS), WAP phones (WML), and faxes

Private Service Registry. UDDI or ebXML business Service Registry where users can look up any Service Providers by names , product codes, or industry categories

Application Servers. Servlets or EJB containers to support the complete life cycle of application services and data

SOAP Server. Servlet that handles SOAP messaging

Market Data Server. Market data feeds handler and administration to receive and broadcast multiple market data feeds

Databases. Back-end databases that provide data store for common data and codes, customer account master, trade data, and data mart/warehouses

Host Gateway. Gateway that connects and provides access to the back-end hosts or legacy systems

Directory/Policy Server. Directory server that stores user credentials and access rights; policy server stores access rights and security policies

Exchanges Gateway. Gateway that connects to and accesses external parties and exchanges

Figure 4-5 elaborates on the previous architecture diagram in Figure 4-4 by depicting the logical components in each server. Using the unified process methodology, this logical view is usually defined in the Inception phase, and it acts as a starting point to design the Quality of Services, such as reliability, availability, and scalability, for each component. The following describes the functionality of the logical components in the Business Tier, which may reside in one or multiple application servers.

  • Price Discovery. This includes a quote server that provides the latest stock price quotes or foreign exchange rates based on the market data and a market data server that hosts all market data from market data feeds Service Providers.

  • Order Management. An application that helps brokers handle trade orders from customers. This includes getting a quote, placing a trade order, acknowledging a trade order, confirming a trade order, routing a trade order, and executing a trade order.

  • Trade Settlement . An application that performs matching between trade orders and executed trade orders and prepares for trade settlement with local clearing organizations.

  • Securities Accounting. A back-office system that manages the accounting of trade orders, clearing, and settlement.

  • Business Intelligence. This provides analytics (operations reporting), data mining (for cross-selling and marketing), and customer reporting (for compliance purposes).

  • Customer Relationship Management. This makes use of different delivery channels or touch points to manage the life cycle of customers by cross-selling, up-selling, and call center services.

In a securities trading business, the logical components (such as order management and price discovery) resemble multiple business services, which can be exposed as Web Services. This logical view can help identify new service components that can be shared and reused. In this example, Web Services technology can help aggregate customer and account information that is captured in a trade order (order management), past credit history (risk management), and past trading history (securities accounting) to support cross-selling and customer sales analytics (CRM) in real-time. Without Web Services, architects may need to build interfaces to extract the customer information into a data warehouse. These interfaces may not be real-time, and may not be reusable for other systems.

Tiers Versus Platform Layers

Categorizing the architecture components in tiers helps architects segment the components, showing how each component operates and interacts with other components in different levels. Architects can also scale up the architecture components by exposing and distributing the business services into multiple machine instances (horizontal scaling) or by allocating workload to different instances by business functionality (for example, instance A performs equities trade orders for retail customers and instance B performs equities trade orders for private customers and options). These are different options showing how architects can improve the Quality of Service of the business services using Web Services technology. Thus, architects can scale up (or down) the workload easily without rewriting the application.

Analyzing the technology stacks by platform layers also helps improve the Quality of Services. The book Dot-Com and Beyond: Breakthrough Internet-based Architectures and Methodologies (2001) discusses what the tiers and platform layers are, and how to define the Quality of Services by comparing the tiers and platform layers (also see Tables 4-1 and 4-2). The platform layer categorization refers to the technology stack, from hardware to the application. The Application Platform Layer denotes the applications (such as risk management system) running on a host with the business logic. The Virtual Platform Layer denotes the middleware or protocol that communicates with the operating system, application server, or other external components, such as SOAP protocol, J2EE RMI/IIOP. The Upper Platform Layer is typically the application server, which consists of the Web container (such as a Web server) and the EJB container (such as a J2EE application server). This provides the application infrastructure for the applications with the business logic. The Lower Platform Layer is usually the operating system, such as Solaris OE. The Hardware Platform Layer refers to the underlying hardware, including the Sparc machine and the associated storage solutions.

Analyzing the architecture components by platform layers can help identify areas where Quality of Services measures (such as vertical scaling and high availability) can be applied. For instance, architects can use hardware and database clustering technology to improve the service level of availability for the UDDI service registries. The tiers versus platform layers analysis (as in Table 4-1) identifies the service components that need to be scaled or made reliable. Then a Quality of Services analysis (as in Table 4-2) can be applied to each tier or platform layer, so that reliability, availability, and scalability options are identified prior to the Web Services implementation.

Table 4-1 shows an example of categorizing the logical components by tiers and platform layers. Please note that some components may span tiers. This is the first step in determining what business services are available, where the service components are, and which ones can be made reliable, available, and scalable. For instance, Service Requesters around the world need to browse through a UDDI Service Registry for different products and services and to look up and invoke appropriate remote business services, such as placing a trade order. Therefore, it is crucial that the Service Registry be able to operate around the clock (7 days x 24 hours). Because the Service Registry resides in the Integration Tier and in the Application Platform Layer, architects may review options within this tier or layer to scale up the Application Platform Layer, and to make it highly available.

Table 4-1. Tiers Versus Platform Layer Architecture Analysis

Tiers/Platform Layer

Client Tier

Presentation Tier

Business Tier

Integration Tier

Resource Tier

Application Platform Layer

   

Order management Trade settlement Risk management Price discovery Securities accounting CRM Business Intelligence

Service Registry

ERP systems

Policy Server

Directory Server

Virtual Platform Layer

 

J2EE

 

SOAP ebXML

Policy Server

Directory Server

Upper Platform Layer

Client Browser

Messaging Servers

Web Server

Portal Server

Application Serve

 

Database Server

Policy Server

Directory Server

Lower Platform Layer

PDA

WAP phone

Solaris OE

Solaris OE

Solaris OE

Policy Server Directory Server

Hardware Platform Layer

PDA

WAP phone

Sparc Unix

   

Mainframe Storage devices/SAN

Quality of Services Analysis Matrix

The Quality of Services matrix shown in Table 4-2 shows how each component can support different "ilities" in different tiers and layers. This is particularly useful for identifying areas for improving scalability and availability. The "ilities" column shows a list of Quality of Services attributes, such as performance, throughput, and scalability. The other columns show different technology options that can be used to design the Quality of Services attributes under different tiers. For instance, reliability and availability for a UDDI Service Registry can be done by clustering the Service Registry hardware. Under a clustered Service Registry, if the master Service Registry has a hardware failure, it will fail over to the secondary Service Registry, without disrupting the lookup service (there may be a short failover lead time of less than 10 minutes though). This can meet around-the-clock service level (7 days x 24 hours). The technical details can be referred to the pattern "High Availability Service Registry" discussed in the following Web Services design pattern section.

Table 4-2. Quality of Services Analysis Matrix

"ilities"

Client Tier

Presentation Tier

Business Tier

Integration Tier

Resource Tier

Performance, throughput, and scalability

 

HTTP-based load balancing for SOAP servlet SOAP/XML cache

Vertical scaling Horizontal scaling

HTTP-based load balancer for Service Registry SOAP/XML cache

Federated Directory Server

Reliability and availability

Reliable and clustered hardware platform

Reliable and clustered hardware platform Clustered messaging servers

Reliable and clustered hardware platform Clustered Application Server

Clustered Service Registry

Master-slave Directory Server for HA

Parallel database server

Standby database server Reliable and clustered hardware platform

Security

HTTPS VPN gateway

HTTPS VPN gateway

HTTPS

XML security (e.g., DSIG, WS-security)

XML security standards (e.g., SAML, XACML) Trusted Solaris OE

Manageability

System management tools

System management tools

System management tools

System management tools

System management tools

Flexibility

 

Decoupling presentation from business (e.g., XML for data, HTML for presentation)

 

Update URL end-point in Service Registry without re-binding run-time (re-compilation)

 

Reusability

   

SOAP-enabled business services

SOAP-enabled business services

SOAP-enabled business services



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