Advanced and future Web services standards

There are many successful implementations of the basic Web Services standards, particularly SOAP and WSDL, but as previously described, many aspects of service interaction and integration are not directly supported by those basic standards, such as security, transactionality, delivery assurance, and process modeling.

The Web services standards are evolving and maturing to address these aspects of interaction and integration, increasing their value to SOA. In this section we

Chapter 3. Web services and service-oriented architecture 59 cover some of the recent and emerging Web services standards that support more sophisticated aspects of service interactions and SOA.

Production-level product support for some of these standards is not yet available, but early implementations exist. The IBM Emerging Technologies Toolkit (ETTK), for example, provides an implementation of WS-ReliableMessaging. The toolkit can be downloaded from:

http://www.alphaworks.ibm.com/tech/ettk

Web services security

In theory, Web services can leverage any security model that is appropriate to the underlying communication technologies. (SOAP/HTTP can utilize basic HTTP authentication or SSL authentication and encryption.) However, such simple point-to-point models are insufficient for the widespread integration needs of SOA. For example:

򐂰 Communication security does not recognize the different between SOAP message headers and the SOAP message body.

򐂰 Credentials may be technology-specific to the communication mechanism, but inappropriate to communication mechanisms that are used farther down the interaction chain.

򐂰 Combining many interactions in a secure overall chain involves trust models between the participants in the chain. Such models are often customized or proprietary, and are not consistent with flexibly changing the participants in the chain as they imply a technology barrier to participation.

In 2002, IBM and Microsoft proposed an architecture and roadmap for Web services security (WS-Security). This set out a framework consisting of several Web services specifications, including WS-Security, WS-Trust, WS-Privacy, and WS-Policy. It also accommodated existing security technologies such as Kerberos, XML Digital Signatures and XML Encryption.

Support for the basic WS-Security standards is available in existing products and can be used to implement secure Web Services solutions. As described in “Security issues affecting the Enterprise Service Bus” on page 89, understanding the security requirements of specific SOA situations and selecting appropriate technologies, include those compliant with the WS-Security standards, is a key decision in SOA implementation.

Further information

򐂰 Security in a Web Services World: a Proposed Architecture and Roadmap http://www.ibm.com/developerworks/library/ws-secmap/

򐂰 Web Services Security: Moving up the stack

http://www.ibm.com/developerworks/webservices/library/ws-secroad/

WS-ReliableMessaging and SOAP/JMS

As discussed previously, the HTTP protocol that is used widely in SOAP

interactions and specified in the WS-I basic profile offers relatively poor reliability in contrast to communication protocols that are often associated with valuable business transactions, such as WebSphere MQ. Many SOA scenarios involve interactions that require a level of delivery assurance beyond that provided by HTTP.

The WS-ReliableMessaging specification defines a protocol for reliable

communication (including SOAP messages) that use a variety of communication technologies, which may themselves be less reliable. An updated specification was published in March 2004, but production support is not yet available in middleware products.

Until WS-ReliableMessaging is widely available, alternative approaches are possible using implementations of SOAP over more reliable communication infrastructures. For example, SOAP messaging is supported through the JMS API to WebSphere MQ by WebSphere MQ, the Web Services Gateway, and WebSphere Business Integration Server Foundation. However, such approaches tend to be implementations by specific technology vendors so, although they are useful in particular SOA implementations, they do not have all of the potential benefits of a fully open-standard implementation.

Further information

򐂰 Updated: Web Services Reliable Messaging: A new protocol for reliable delivery between distributed applications

http://www.ibm.com/developerworks/webservices/library/ws-rm/

򐂰 Implementation Strategies for WS-ReliableMessaging: How

WS-ReliableMessaging can interact with other middleware communication systems

http://www.ibm.com/developerworks/webservices/library/ws-rmimp/

Business Process Execution Language for Web Services

As the encapsulation and exposure of business functions as services in an SOA enables the definition of processes consisting of those services, the Business Process Execution Language for Web Services (BPEL4WS) provides a standard, XML language for expressing business processes consisting of functions that are defined through WSDL interfaces. BPEL4WS supports both short-lived processes and long-lived processes (processes that must wait at certain points until some event occurs, such as the receipt of an event).

Chapter 3. Web services and service-oriented architecture 61 As with WSDL, BPEL4WS has both design time and runtime uses. At design time, development or modeling tools can use, import, or export BPEL4WS to enable business analysts to specify processes and developers to refine them and bind process steps to specific service implementations. However, runtime choreography and workflow engines can use BPEL4WS to control the execution of process and invoke the services that are required to implement them.

Although BPEL4WS is a relatively new standard, product support such as WebSphere Business Integration Server Foundation V5.1 is available. This provides additional facilities to compensate failed processes (a proprietary equivalent to the WS-BusinessActivity standard described in the next section, “Web services transactions”) and provide a user workflow interface to enable human actions to fulfill WSDL-defined steps in a BPEL4WS process.

Further information

http://www.ibm.com/developerworks/library/ws-bpel/

򐂰 Business Process with BPEL4WS, a series of introductory articles and references

http://www.ibm.com/developerworks/webservices/library/ws-bpelcol1/

򐂰 BPEL4WS support in WebSphere Business Integration Server Foundation http://www.ibm.com/software/integration/wbisf/features/

򐂰 BPEL4WS support in WebSphere Studio Application Developer Integration Edition

http://www.ibm.com/software/integration/wsadie/features/

Web services transactions

Although WS-ReliableMessaging will provide a means to assure the delivery of individual communications in a Web services interaction, a means is also required to control the integrity of business transactions in an SOA that consist of one or more Web services invocations or interactions.

Within the framework of the Web services coordination (WS-Coordination) specification, both synchronous (WS-AtomicTransaction) and long-lived

(WS-BusinessActivity) transaction models have been defined. These replace the previous WS-Transaction specification.

The WS-AtomicTransaction specifies a model for synchronous, two-phase committal of distributed transactions using Web services protocols.

WS-BusinessActivity defines an asynchronous model for compensating failed processes using undo actions to reverse the affects of individual steps of the process. Neither specification has mature product support to date.

Further information

򐂰 WS-AtomicTransaction specification

http://www.ibm.com/developerworks/library/ws-atomtran/

򐂰 WS-BusinessActivity specification

http://www.ibm.com/developerworks/webservices/library/ws-busact/

򐂰 Transactions in the world of Web Services, part 1 and part 2 http://www.ibm.com/developerworks/webservices/library/ws-wstx1/ http://www.ibm.com/developerworks/webservices/library/ws-wstx2/

򐂰 WS-Coordination specification

http://www.ibm.com/developerworks/library/ws-coor/

Web Services Policy Framework (WS-Policy)

The Web Services Policy Framework is intended to provide a set of languages by which service requesters and providers can express their requirements and capabilities concerning QoS of service interactions, such as security,

transactionality, and communication reliability. Eventually a framework of such languages, supported by Enterprise Service Bus middleware, will enable open-standard implementations of negotiated coupling between various aspects of service interactions. (See 3.2.1, “Coupling and decoupling of aspects of service interactions” on page 39.)

A WS-Policy specification is available, although specific policy languages for quality of service aspects such as security are still required, and product support has yet to emerge.

Further information

򐂰 WS-Policy framework specification

http://www.ibm.com/developerworks/library/ws-polfram/

򐂰 Web Services Policy Framework: New specifications improve WS-Security http://www.ibm.com/developerworks/webservices/library/ws-polfram/summary.ht ml

Web Services Resource Framework (WS-ResourceFramework)

As we write this book, WS-ResourceFramework is an architectural proposal rather than a standard, but it relates to some of the aspects of SOA that we have only touched on in the discussion of Web services (namely the design, rather than technical, characterization of services). In 3.2.2, “Designing connectionless services” on page 45, we discussed the relationship between service definitions, processes and stateful behavior, and suggested some techniques for designing flexible services to participate in stateful interactions.

Chapter 3. Web services and service-oriented architecture 63 In order to enable middleware to provide increasingly sophisticated support for such stateful interactions, the Web Services Resource Framework provides a model for associating Web services with stateful resources (for example data, such as rows in a database), as opposed to stateful processes (as can be accomplished with BPEL4WS), which is essentially a model for making Web services middleware and infrastructure aware of stateful identifiers such as transaction IDs.

Further information

򐂰 WS-ResourceFramework overview

http://www.ibm.com/developerworks/webservices/library/ws-resource/ws-wsrfpa per.html

3.4 Emerging infrastructure components for Web