Introduction

In addition to the Web services features that were introduced in Version 6.0.x, WebSphere Application Server V6.1 provides support for:

• Web Services Transaction (WS-Transaction), which involves three separate specifications:
• Web Services Coordination (WS-Coordination)
• Web Services AtomicTransaction (WS-AT)
• Web Services BusinessActivity (WS-BA)
• Web Services Notification (WS-Notification), also knows as pub/sub for Web services
• Web Services Interoperability (WS-I) Basic Security Profile
• Web Services Resource Framework (WS-Resource Framework).

WebSphere Application Server V6.1 also provides enhanced performance for Web services security, which is a support for hardware cryptographic devices that secure keys or accelerate cryptography. Several existing Web services features have been enhanced, including:

• Parser enhancement
• SAAJ 1.2 enhancements for better performance
• Client support for JMS Server connection caching
• Enhanced support for WS-Addressing support.

Figure 1 shows Web services features that were introduced in WebSphere Application Server V6, and additional features available in V6.1.

The sections that follow discuss each new Web services feature with regard to WebSphere Application Server V6.1.

Back to top

WS-Transaction

WS-Transaction (see Resources for the actual specifications) is a standard developed by IBM, BEA Systems, Microsoft®, and others, and describes the coordination types that are used in conjunction with the extensible framework described in the WS-Coordination specification. WS-Transaction defines two coordination types:

• WS-AtomicTransaction
• WS-BusinessActivity

and involves three separate specifications:

• WS-Coordination
• WS-AtomicTransaction
• WS-BusinessActivity.

Figure 2 illustrates the relationship between these specifications and WS-Transaction.

WS-Coordination

Beginning with Version 6.0, WebSphere Application Server supports the WS-Coordination specification, which describes an extensible framework for providing protocols that coordinate the actions of distributed applications. These coordination protocols are used to support a number of applications, including those that have to reach consistent agreement on the outcome of distributed activities. The coordination protocols that can be defined in this framework can accommodate a wide variety of activities, including protocols for simple short-lived operations and protocols for complex long-lived business activities.

WS- AtomicTransaction (WS-AT)

Also beginning with Version 6.0, WebSphere Application Server supports the WS-AtomicTransaction specification, which refers to the atomic transaction coordination type that is based on the WS-Coordination, and defines an atomic transaction context and its usage. Atomic transactions are typically short in duration and commonly require a high level of trust between participants. The WS-AT specification defines protocols that enable existing transaction processing systems to wrap their proprietary protocols and interoperate across different hardware and software vendors.

WebSphere Application Server V6.0 implements the WS-AT specification, enabling the Web services application to participate in global transactions distributed across a heterogeneous Web services environment.

As a transaction manager, WebSphere Application Server supports the coordination of resource managers through their XAResource interfaces and participates in distributed global transactions with transaction managers that support WS-AT. WS-AT is a two-phase commit transaction and is suitable only for micro transactions (short running). The best practice is to use WS-AT within a single enterprise, avoiding WS-AT usage across enterprise domains. From a development perspective, there are no specific development tasks required for taking advantage of WS-AT for Web services other than specifying it in the deployment descriptor (by enabling Send Web Services Atomic Transactions on Requests). The WebSphere Application Server runtime takes responsibility for registering WS-AT participants in the same way as XA resources are registered in the JTA transaction to which the WS-AT transaction is federated.

WS-Business Activity (WS-BA)

New in Version 6.1, WebSphere Application Server supports the WS-BusinessActivity specification. A business activity is a collection of tasks that are linked together to achieve a complex outcome. Unlike atomic transactions, activities such as sending an e-mail can be difficult or impossible to roll back atomically, and so a compensation process is required in the event that an error occurs in one or more of the tasks.

The compensation support pattern is similar to IBM WebSphere Process Server Business Process Choreography compensation. WebSphere Application Server V6.1 supports compensation, as well as WS-AT and WS-BA context propagation, through a firewall.

WS-BA support in WebSphere Application Server enables Web services on disparate systems to coordinate activities that are more loosely coupled than atomic transactions. WS-BA enables such work to be handled in two phases (to be completed and later compensated) and also enables compensation for one phase work. WS-BA can coordinate a compensation pattern across different platforms/architectures/implementations, and can be used over different transports such as HTTP, JMS, and IIOP (in the case of WebSphere Application Server to WebSphere Application Server). The scope of the Business Activity (BAScope) has a one-to-one relationship with a WebSphere Application Server unit of work.

In addition to WS-BA support in Web services, WebSphere Application Server supports WS-BA in EJB components using the container-managed transaction. WS-BA tooling support is available in both IBM Rational® Application Developer and the Application Server Tool Kit.

Enabling WS-BA

By default, WS-BA is disabled in WebSphere Application Server V6.1, and so it needs to be enabled as part the IT topology and application server planning process before you can exploit this specification. Each participating application needs to implement a compensation handler interface. This interface needs to be created so the WS-BA application component can reference it, and then be executed at run time. Each application then needs to be configured using Rational Application Developer or the Application Server Tool Kit to set the compensation handler class in the deployment descriptor.

To enable WS-BA:

1. In the WebSphere Application Server 6.1 administrative console, select Servers => Application servers => server_name => [Container Settings] Container Services => Compensation Service. Select Enable service at server startup, and then restart all the servers for the changes to take effect. (Figure 4)

   
   
   Figure 4. Enable service at server startup
   
   
   

2. Create a new Java class that implements the com.ibm.websphere.wsba.CompensationHandler interface. Implement the close and compensate methods on the new compensation handler object to perform appropriate actions, depending on the SDO (Service Data Objects) data that will be passed to the handler when it is invoked.

3. Open the application component of the Application Server Toolkit or Rational Application Developer. Open the deployment descriptor for the application component in the deployment descriptor viewer. Scroll to the Compensation section and select Run EJB methods under a BusinessActivity scope. In the Compensation handler class text field, type the fully qualified class name of the compensation handler class that you created earlier, then Save the deployment descriptor. (Figure 5)

   
   
   Figure 5. Run EJB methods under a BusinessActivity scope
   
   
   

Build the application, including both the application component and the compensation handler. If the application is a Web service, then the application must be compliant with the JSR 109 standard. Deploy the application onto an application server that is business activity-enabled.

Back to top

WS-Notification

New in Version 6.1, WS-Notification defines a standardized way for Web services to interact using the notification (or publish/subscribe) pattern. In this pattern, a Web service (or other entity) disseminates information to a set of other Web services without the need of having prior knowledge of these other Web services.

WS-Notification is comprised of WS-BaseNotification, WS-BrokeredNotification, and WS-Topics specifications. WebSphere Application Server V6.1 provides support at the WS-Notification level. Figure 6 shows the relationship of these three specifications with respect to WS-Notification.

Inherent in the WS-Notification specifications are the following terms:

• NotificationProducer -- a Web service that wants to insert event notifications into the system.
• NotificationConsumer -- a Web service that receives NotificationMessages from a NotificationProducer.
• SubscriptionManager -- a Web service that implements message exchanges associated with the SubscriptionManager interface.
• PullPoint interface -- defines an endpoint that accumulates notification messages and enables a requestor to retrieve accumulated notification messages.

WebSphere Application Server supports WS-Notification in the following manner:

• WS-BaseNotification defines the port types for applications for both NotificationProducer and NotificationConsumer Web services. WebSphere Application Server V6.1 provides NotificationProducer, NotificationConsumer, SubscriptionManager and PullPoint support for the WS-BaseNotification specification.

• WS-BrokeredNotification defines how an intermediary NotificationBroker is responsible for disseminating messages produced by one or more publishers to zero or more consumers. WebSphere Application Server V6.1 provides NotificationBroker support, which extends the NotificationProducer and NotificationConsumer pair, and the RegisterPublisher and PublisherRegistrationManager pair, for demand-based publishing for WS-BrokeredNotification (See Resources).

• The WS-Topics specification defines topics to which a NotificationProducer can associate its messages. WebSphere Application Server V6.1 supports three expression dialects: simple, concrete, and full (Table 1).

Configure WS-Notification

You can configure WS-Notification either through the admin console or by using wsadmin scripts. For a simple case, you need to configure five basic configuration resources in the Service Integration Bus section of WebSphere Application Server V6.1 administration. Remember that the configuration resources differ depending upon usage pattern and topology. In the simple case shown in Figure 7, the configuration resources need to be configured in a hierarchical fashion.

Defining a WS-Notification service on a bus indicates intent to provide access to some or all of the resources of the bus to WS-Notification applications. One or more WS-Notification services may be defined on a service integration bus.

Creation of a WS-Notification service point instructs the server runtime to expose Web service endpoints on the selected server through which WS-Notification applications can interact with the NotificationBroker. The administrator is able to define any number of WS-Notification service points for a given WS-Notification service.

A permanent topic namespace requires the administrator to statically define the association between a WS-Notification topic namespace URI and a service integration bus topic space destination as part of the configuration settings.

An administered subscriber contains the name of an application NotificationProducer or NotificationBroker endpoint, and details of a subscription request (that is, topic, selector, and so on) that the WS-Notification service point should register as part of the server startup procedure.

Back to top

WS-Interoperability Basic Security Profile

The Web Services Interoperability Organization was founded specifically with the intent of facilitating interoperability of Web services between different vendor products and to clarify gaps or ambiguities between the various standards and standards bodies. It formulated the concept of profiles to solve this problem and reduce complexity. Profiles consist of implementation guidelines for how related Web services specifications should be used together for best interoperability.

The WS-I Basic Profile, as of Version 1.1, has been split into two separate profiles. Conformance to WS-I Basic Profile V1.1, plus conformance to the Simple SOAP Binding Profile V1.0, is roughly equivalent to a combined conformance claim of WS-I Basic Profile V1.0 plus the published errata.

The WS-I Basic Profile begins with a basis of the following set of open standards:

• SOAP V1.1
• WSDL V1.1
• UDDI V2.0
• XML V1.0 (Second Edition)
• XML Schema Part 1: Structures
• XML Schema Part 2: Datatypes
• RFC2246: The Transport Layer Security (TLS) Protocol V1.0
• RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• RFC2616: HyperText Transfer Protocol V1.1
• RFC2818: HTTP over TLS
• RFC2965: HTTP State Management Mechanism
• The Secure Sockets Layer (SSL) Protocol V3.0.

In addition to WS-I Basic Profile support, WebSphere Application Server V6.1 supports WS-I Basic Security Profile (BSP) 1.0, which promotes interoperability by providing clarifications and amplifications to a set of non-proprietary Web services specifications. The BSP is an extension profile to the Basic Profile, meaning it is consistent with the Basic Profile but provides additional functionality, such as add conformant security features to the Basic Profile when needed.

As an extension of the Basic Profile, the BSP is designed to support the addition of security functionality to SOAP messaging in an interoperable manner. The Basic Profile contains requirements on the content of SOAP envelopes (or, as in Basic Profile 1.0, the format of SOAP messages). You can achieve BSP compliance using the Application Server Tool Kit assembly tool.

Back to top

WS-Resource Framework

The Web Services Resource Framework defines the specifications for accessing stateful resources using Web services. The specifications include:

• WS-ResourceProperties
• WS-ResourceLifetime
• WS-BaseFaults
• WS-ServiceGroup.

Figure 8 shows the relationship between all four specifications with respect to the WS-Resource Framework.

WS-Resource Framework is essential where the stateful resources involved in the Web services interaction such as shopping cart, printer, print job, and so on.

WS-ResourceProperties

WS-ResourceProperties defines:

• Usage of XML schema to model elements of the resource state
• Association of the resource’s state model with WSDL port type
• Operations
• Standard mechanism to use WS-Notification to subscribe in the event of state change.

Figure 9 explains the operations defined in the WS-ResourcesProperties.

WS-ResourceLifeTime

WS-ResourceLifeTime defines:

• Synchronous destruction operation (immediate)
• Time based destruction operation (scheduled)
• Resource Properties (current time and termination time)
• Notification in the event of resource termination.

In a nutshell, this specification clearly defines how WS-Resources can be destroyed. Figure 10 shows the operations defined in the WS- ResourceLifeTime.

WS-BaseFaults

The WS-BaseFaults defines

• Common set of fault properties
• Convention for specializing common fault.

Figure 11 shows the operations defined in the WS-BaseFaults.

End point references (EPR) and Quality of Service

WebSphere Application Server supports three levels of qualities of service:

• Workload balanced end point reference
• Fragile end point reference
• Highly available end point reference.

In the case of workload balanced end point references (EPR), the request is load balanced across servers in the cluster. This would be useful where there is no volatile state cached and the state is equally available across the cluster. Figure 12 shows the interaction between the Web services client with EPRs in clusters.

In the case of a fragile EPR, the end point reference is created in one server with server affinity. It would be useful where there is high volatile state and cache involved. Figure 13 shows the interaction between the Web services client with EPR in one server.

In the case of the highly available EPR, the end points have server affinity and can be failed over. This would be useful where the WS-Resource State is maintained by a stateful session bean and WebSphere Application Server stateful session bean failover is enabled. Figure 14 shows the interaction between the Web services client with highly available EPR in a cluster.

Back to top

Conclusion

This article noted several new Web services features and enhancements in WebSphere Application Server V6.1, and discussed details about WS-Business Activity, WS-Notification, WS-I Basic Security Profile and WS-Resource Framework specifications with respect to this new version. This release supports many new Web Services features, and provides many ways for you to take advantage of Web services in your applications.

Back to top

Acknowledgements

I would like to thank my colleagues Arnauld Desprets, Hanumanth Kanthi and Larry Feuer in preparing this article.

Resources

• Web Services Transactions specifications
  
  
• Web Services Notification specifications
  
  
• Web Services Resource Framework specifications
  
  
• OASIS Standards: Web Services Notification
  
  
• Brokered Notification
  
  
• WebSphere Application Server 6.1 Info center
  
  
• WebSphere Application Server 6.0 Info Center
  
  
• WebSphere Version 6 Web Services Handbook Development and Deployment - SG24-6461-00
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• WS-Transaction
• WS-Notification
• WS-Interoperability Basic Security Profile
• WS-Resource Framework
• Conclusion
• Acknowledgements
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Webcast: Using Rational Application Developer with WebSphere Application Server to increase productivity
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

My developerWorks community

Dig deeper into WebSphere on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers