8.6 Quality of Service capabilities

 < Day Day Up > 

8.6 Quality of Service capabilities

In this section we discuss Quality of Service capabilities and considerations specific to Web services.

For further discussion on Quality of Services see the IBM developerWorks article Understanding quality of service for Web services:

  • http://www.ibm.com/developerworks/library/ws-quality.html

8.6.1 Autonomic

Log and trace facilities are important for fault monitoring and isolation. WebSphere Application Server provides a number of log files. JVM logs are located in the <WAS_HOME>/logs/<applicationServerName> directory, and by default are named SystemOut.log and SystemErr.log.

The Diagnostic Trace Service can be used to enable tracing of application server components. The following trace specification can be used when diagnosing Web services problems:


The TCPMon tool described in 8.5.3, "Monitoring SOAP messages" on page 172 allows you to view the contents of the SOAP messages being generated by the interaction between the source and target applications.

8.6.2 Availability

The Patterns for e-business define a set of high-availability patterns that provide the node redundancy and failover capabilities needed to eliminate single-point-of-failure for the end-to-end production system. The following Non-Functional Requirements::High Availability: Runtime patterns are defined:

  • High Availability: Basic Runtime pattern

  • High Availability: Runtime pattern: Single load balancer

  • High Availability: Runtime pattern: Load balancer hot standby

  • High Availability: Runtime pattern: Mutual high availability

  • High Availability: Runtime pattern: Wide area load balancing

Many of the same principles that apply to any Web application can be applied to Web services when it comes to availability.

See the IBM Redbook Patterns for the Edge of Network, SG24-6822, for details on how these Non-Functional Requirements custom designs are applied to Web applications.

8.6.3 Performance

The Patterns for e-business also define a set of high performance patterns that provide the scalability and workload management capabilities needed to meet performance and throughput requirements. The following Non-Functional Requirements::High Performance: Runtime patterns are defined:

  • High Performance: Basic Runtime pattern

  • High Performance: Runtime pattern: Redirectors

  • High Performance: Runtime pattern: Separation

  • High Performance: Runtime pattern: Caching proxy

Many of the same principles that apply to any Web application can be applied to Web services when it comes to performance.

See the IBM Redbook Patterns for the Edge of Network, SG24-6822, for details on how these Non-Functional Requirements custom designs are applied to Web applications.

XML parsing

The WebSphere V5.0.2 Web services runtime uses SAX (event-based) parsing, achieving improved performance over the earlier versions of Apache SOAP, which used DOM parsing. Still, in order to minimize the effect on performance of XML parsing, some steps can be taken:

  • Avoid chaining services if possible, since this will increase path lengths.

  • Design for coarse-grained, document-based interactions.

  • Balance architecting service re-use with number of invocations per transaction.

Usually the performance loss from using an XML parser such as SAX is negligible compared to the effort necessary to build up the communication itself. The highest performance results can be expected from using the appropriate transport protocol. For example, consider using RMI instead, if appropriate. You can always expose the EJB as Web services later, if needed.

8.6.4 Security

Web services security for IBM WebSphere Application Server V5.0.2 is based on standards included in the Web services security (WS-Security) specification. Web services security is a message-level standard, based on securing SOAP messages through XML digital signatures, confidentiality through XML encryption and credential propagation through security tokens.

Transport-level security is based on the Secured Sockets Layer (SSL) or Transport Layer Security (TLS) mechanisms across the HTTP protocol. SSL and TLS provide security features including authentication, data protection, and cryptographic token support for secure HTTP connections. To run with HTTPS, the service endpoint address must be in the form of https://.

For further details on Web services security for WebSphere V5.0.2, see the InfoCenter article Securing Web services at:

  • http://www.ibm.com/software/webservers/appserv/infocenter.html

UDDI security

One reason for the delay in widespread adoption of UDDI is the lack of security standards that would allow companies to restrict Web services access information to trusted partners. The third version of the UDDI standard will include security specifications.

8.6.5 Standards compliance

By utilizing open standards, Web services can, in theory, enable any two software components to communicate—no matter what technologies or platforms are used to create or deploy them. Interoperability across heterogeneous platforms is one of the key value propositions of Web services.

Unfortunately, there is still no common, agreed-upon definition of what a Web service is, many needed standards are still in their infancy, and some are still competing against each other. To address the potential problems, the Web Services Interoperability (WS-I) Group released the Web Services Basic Profile 1.0 on October 17, 2002.

See the WS-I Basic Profile Version 1.0 specification for more details:

  • http://www.ws-i.org/Profiles/Basic/2002-10/BasicProfile-1.0-WGD.htm

8.6.6 Transactionality

Almost every party agrees that we need a standard that accommodates both classical ACID (XA or database-style transactions) and long-running, compensating transactions. But there is still sharply divided opinion on where such standards fit in the Web services stack.

The Business Transaction Protocol (BTP) from OASIS was backed by a number of smaller vendors (BEA, HP, Choreology, Oracle) and Version 1.0 was released in May 2002. BTP tries to adopt XML-based technology for business transactions on the Internet and tackles such challenges as transactions that span multiple enterprises and long-lasting transactions. BTP has been criticized as being too complex, and still lacks backing from an industry heavyweight (like IBM or Microsoft).

In August 2002, IBM, Microsoft, and BEA published two draft specifications:

  • WS-Coordination is a general purpose and extensible framework for providing protocols that coordinate the actions of distributed transactions. The defined framework enables an application service to create a context needed to propagate an activity to other services and to register for coordination protocols. The framework also enables existing transaction processing, workflow, and other systems for coordination to hide their proprietary protocols and to operate in a heterogeneous environment. It can be used with message sequencing and state machine synchronization.

    See http://www.ibm.com/developerworks/library/ws-coor/ for the published specification.

  • WS-Transaction includes support for the two types of transactions. It describes coordination types that are used with the extensible coordination framework as described in WS-Coordination. Two coordination types are defined: Atomic Transaction (AT) and Business Activity (BA). WS-Transaction is a building block used with other specifications (for example, WS-Coordination, WS-Security) and application-specific protocols that are able to accommodate a wide variety of coordination protocols related to the coordination actions of distributed applications.

    See http://www.ibm.com/developerworks/library/ws-transpec/ for the published specification.

While these proposals and specifications are still evolving, it is recommended that we, as architects and developers, actively participate in, review, comment on, and help improve the specifications. Also evaluate early implementations for inclusion in corporate architecture standards and possible application implementation. If there is urgent need for designing and implementing a Web services-based transactional infrastructure and related business services, we recommend using the principles behind the new specifications.

 < Day Day Up > 

Patterns Direct Connections for Intra- And Inter-Enterprise. Direct Connections for Intra- And Inter-Enterprise (IBM Redbook) (Paperback)
Patterns Direct Connections for Intra- And Inter-Enterprise. Direct Connections for Intra- And Inter-Enterprise (IBM Redbook) (Paperback)
Year: 2003
Pages: 139

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