More Web Services Performance Improvements in WAS 7.0.0.7

Back in WAS 7.0, I blogged about impressive web services performance improvements.

We have continued that improvement in fixpack 7 (7.0.0.7). Given this is a fix pack, we decided to make the new functional optional (until 8.0). You can learn about how to turn it on in PK94109. Basically you enable it by setting a system property on your application server instance.

This improvement is on the JAXB to XML marshalling (serialization) side. On the server, this would be important when responses are large (the typical case is responses are larger than requests). On the client, this would be important on requests.

As before, this not only helps web services using JAXB, but also anyone using JAXB directly in the application server.

In our tests in the labs we see approximately 20% increase in performance for some representative web services. If you are using JAX-WS JAXB based web services, turn this one with 7.0.0.7 and let me know what you see.

SPEC working on standard SOA Benchmark

I continue to be interested in helping customers understand the performance of Service Oriented Architect (SOA) applications. As you can see here, I'm working (as the chair) in this SPEC working group, along with considerable input from Oracle and VMware on pushing forward on a standard benchmark for SOA based applications and the middleware infrastructure on which they run.

The interesting parts (in my opinion) of this press release are:

The benchmark will be developed by a trusted benchmarking organization with input from all SPEC members. Also, as mentioned in the press release, we're looking for participation by other interested parties. If you're interested in joining SPEC or providing input, let Bob Cramblitt know. I'm truly excited to see a SOA benchmark come from SPEC as they have a proven track record in creating industry trusted benchmarks for middleware performance.

While the initial focus is Web Services, Enterprise Service Buses, and Business Process Management (BPEL), the group realizes these technologies are only part of the entire SOA picture. It's good to see the group start with a sensible core and grow the effort over time.

The group is working to stay flexible on its support of multiple approaches to implementing these technologies. This is key, as SOA is an architectural approach and there are multiple ways to implement such technologies. However, in an industry standard benchmark it's important to audit and standardize common implementations to confirm they would be used in typical customer implementations.

I'll continue to post publically shareable information as the work group makes progress. If you have any quick questions, post them here and I'll ask them at the working group.

Another reason for DataPower SOA appliances - XML Threat Protection

I've gotten a few questions on recent XML security buzz. On today's blog post by Rich Salz (lead architect of our appliances) discussed how XML threat protection is a required tool when exposing important services to untrusted sources. He talked about this due to the recent press interest in "XML Exploits" which was started by some XML fuzzing work by Codenomicon.

I wanted to post about it here to make sure this wasn't an unknown concept to our customers. Rich talks about "defense in depth", which is what most of our WebSphere customers are doing today. To quote Keys Botzum (one of our lead security consultants for WebSphere, "Anyone that is exposing services to untrusted sources absolutely needs to be running a XML firewall, like DataPower)". In my world, defense in depth means putting a WebSphere DataPower XML Security Gateway XS40 in front of any services that could be called by untrusted sources. Also, given the performance characteristics of the DataPower devices (basically no latency impact), you likely want to do this on all services (as sometimes hacks aren't intention and sometimes hacks come from internal sources).

If you haven't heard of XML firewalls or XML threat protection, think about network firewalls. Network firewalls are great for protecting us from threats that can be detected at the network level (like the recent Twitter and FaceBook distributed denial of service attacks), but they don't help you with threats that are in the payloads of messages themselves. XML Firewalls help you with such application level threats by turning away bad messages before they enter your enterprise applications.

If you have any questions on the concept, feel free to pop over to Rich's blog and ask.

More information on the TPC SOA benchmark

As I mentioned previously, the TPC (Transaction Processing Performance Council) is looking at SOA benchmarking. SearchDataCenter.com has an article that summarizes alot of the new and upcoming TPC work. You will see the TPC chairman, Mike Molloy, talk about the popular existing TPC benchmarks (TPC-C, TPC-E, TPC-H, and TPC-App) as well as new benchmarking efforts around energy (consumption with focus on greening of the data center), virtualization (across all new workloads), ETL (Database Extract, Transform, Load), and SOA.

On SOA, Mike explains, "TPC's SOA benchmark is only in the proposal stage, but the tentative plan is to focus on common industry-accepted portions of SOA infrastructure, mainly Web services, the enterprise service bus, and business process choreography. As advanced SOA practices become more standard in the industry, TPC will expand the benchmark to incorporate additional SOA infrastructural services".

I'm excited to work within the TPC to continue driving this SOA performance benchmark to reality. There are no other standard benchmarks that tackle these common SOA infrastructural components. If you have interest in seeing such a benchmark or comments on how it would help you, please post a comment. I'll relay them back to the TPC.

Using WS-Policy to configure WS-ReliableMessaging

My good friend Eleanor Harley sent me this link to 'Real Snail Mail' the other day. It seems like a fantastic idea; probably carbon neutral although arguably not the simplest thing that could possibly work. It is however an entertaining use case for WS-ReliableMessaging which I have been working on for WebSphere Application Server v7.0. Those snail's squish very easily, and without your Acknowledgement snail you'd never know if that vital message was delivered, or had come under some salty security attack.

Did I mention that WS-ReliableMessaging has just shipped in WebSphere Application Server v7.0? Previously delivered as part of the Web Services Feature Pack for WebSphere Application Server v6.1, the function has been enhanced by conformance to the WS-I Reliable Secure Profile and the impact of WS-Policy on configuring WS-ReliableMessaging.

Using WS-Policy with WS-ReliableMessaging provides improved levels of flexibility on when this quality of service is applied to your Web Service messages. We have introduced a new 'strictlyEnforceWSRM' property that can be applied to the client and the service.

It enables you to chose whether your service and client want to enforce Reliable Messaging or simply support Reliable Messaging. WS-Policy then determines what the common configuration option is between the client and server. For example, if your server policy states that it supports WS-ReliableMessaging , and the client is configured to enforce WS-ReliableMessaging , then WS-ReliableMessaging will be used. However, if the client has no WS-ReliableMessaging configured then the server will not use it.

Finally, unlike Real Snail Mail, we have been working hard on WS-ReliableMessaging performance this release as well. I hope you'll appreciate the results.

New WAS v7.0 Web Services Functionality

The Feature Pack for Web Services that WebSphere released on top of WebSphere v6.1 dropped a large chunk of new Java EE 5 functionality related to Web Services in an early fashion. However, version 7.0 completes that work plus introduces some new capabilities that make it easier to developer web services for application developers.

The work (from a technology perspective) focused on 2 specific areas:

• JCP-based programming model updates
• Continuation of filling out the Web Services Roadmap

From a JCP-based perspective, the support for JAX-WS and JAXB have been upgraded from the Feature Pack to their 2.1 equivalents. This adds several minor maturity improvements in both cases (such as @XmlSeeAlso support for type substitution) as well as support for a WS-Addressing API for usage within JAX-WS. What this means for end-users is easier and better support for using/developing web services. From an integration perspective, version 7.0 now allows EJB 3.0 developed beans to also be exposed natively as web services. Lastly, v7.0 also introduces support for JSR 109 metadata. This allows annotation information to be overridden, handlers to be defined, and allows testcases like common JAX-WS providers to be used with different types of metadata.

Extending beyond what's in just the JCP specification, the combination of EJB 3.0 beans and JAX-WS annotations also brings support for SOAP/JMS-based beans to JAX-WS-based services. This makes it consistent for those developers looking to use existing reliable transports as a way to send/receive their web services requests. As part of that support, we are tracking the emerging SOAP/JMS standard being developed at W3C.

With respect to filling out the Web Services roadmap, WebSphere v7.0 upgrades support for numerous OASIS and W3C specifications to their official standardized levels (as well as providing support for their pre-OASIS levels for versions previously introduced within WebSphere). OASIS WS-AtomicTransactions and WS-BusinessActivity were both upgraded to their 1.1 levels (so WebSphere supports both 1.0 and 1.1 levels now). The OASIS WS-Trust and WS-SecureConversation specifications have also been upgraded to their OASIS 1.3 levels as well as support for OASIS WS-SecurityPolicy 1.2 being introduced. The OASIS Kerberos Token Profile 1.1 is also now supported in v7.0 providing support for single signon with Keberos tokens.
With the addition of WS-SecurityPolicy also means that we've introduced support for W3C's WS-Policy 1.5 specification. As such, WebSphere now supports the ability to expose WS-Policy assertions for services exposing WSDL endpoints supporting the qualities of service attached at that endpoint (including Security, ReliableMessaging, Addressing, and Transactions). That information is available via the typical ?wsdl exposed for the service as well as a WS-MetadataExchange request to the service endpoint too.

To continue focusing on improving the ease-of-use experience for WS-Policy, WebSphere has also exposed the ability on the client side to configure itself based on the policy assertions exposed in the published service's WSDL file. This makes it easy to have the client configure itself (or calculate an effective policy based on the clients capabilities).

In addition to the standards upgrades, v7.0 continues to focus on other enhancements to the existing functionality (both functional and non-functional) which continues to enhance the maturity and ease-of-use to the development and adminstration of web services. For example, WS-Notification services now can take advantage of PolicySets. PolicySets themselves have been enhanced to support naming the configurations as well as the bindings. These can now be imported and exported easily to allow these pre-configured systems to be moved from one topology to another. For example, moving from a development environment to a test environment to a production environment.

Andrew Spyker had already talked about some of the dramatic performance improvements introduced in v7.0 for web services.

I guess to make a long story short, there's lots of good new stuff in the web services space. I hope that you find the links provided above as a good starting point to quickly get pointers to more information on the topics discussed.

What's so great about WS-Policy?

It's just over a year now since the WS-Policy Specification http://www.w3.org/TR/ws-policy/ moved to RECOMMENDED, and last week WAS 7.0 went GA with support for this spec.

So, exactly what does WS-Policy give us? Conceptually, it's pretty simple: a standard XML format for expressing requirements or capabilities (policies) of a system. To be more precise, it just provides a framework for expressing policies. This is an excellent model for flexibility and extensibility because you can add policies of any 'flavour' within this framework.

A policy flavour or 'domain' might be a proprietary policy - for example, a policy relating to a logging. Alternatively, you can express policies relating to pre-canned standard domains such as WS-SecurityPolicy. So this opens a whole new opportunity: so long as communicating systems understand WS-Policy and the same policy domains, they can exchange information about requirements and capabilities in a standard format. Here are some example uses of this:

• A client could configure itself based on a server's configuration (even if the client and server use different proprietary formats for representing their configurations internally)
  
  
• In a large, heterogeneous environment, a standard policy configuration for many machines could be held in a central repository
  
  
• A service endpoint could advertise its requirements to all its clients in a non-proprietary way

The WS-Policy framework also provides an operator ("All") for combining policies and an operator ("ExactlyOne") for expressing more than one possible option (a policy choice). It may be useful for a service to advertise a choice of requirements, for example, in order to satisfy differing capabilities of a number of clients. This allows for a loose coupling in terms of configuration - because the configuration of an interaction with a service may be flexible and depend on the client.

Finally, WS-Policy provides an algorithm (called intersection) for combining 2 policies together to find an acceptable policy for all parties. So if a client has requirements but also needs to conform to the requirements of the service, you can take the two policies, perform intersection and out pops a policy acceptable to both the client and service.

More about ws-policy support in WAS 7 to follow...

Web Service Performance Improvements in WAS V7.0 (up to 3x)

Two weeks ago, I said I'd be doing a weeklong series of posts on WAS V7.0 performance.  A week late, but here we go.  I guess I can say I delayed until WAS V7.0 was generally available, which it is now (trial download here)!  WAS V7.0 should be available by other supported download methods as well.

There are many impressive areas of performance improvements in WAS V7.0, but I'll start with the one nearest and dearest to my heart - Web Services.  In the past, I talked about web services performance through the years.  I mentioned a possible follow-up blog post on what Feature Pack for Web Services performance.  I never followed up on that (hrm, a theme in my slow blogging), but now that the same code is available in WAS V7.0, I will.  In fact, we've made even more improvements to web services performance in WAS V7.0 that would truly make the "performance through the years" chart from my previous blog post much more impressive.

WAS V6.1 supports the J2EE 1.4 JAX-RPC web service programming model.  Last year, we added Java EE 5 support for the JAX-WS web service programming model (expanded functionality, standards support, easier programming model, and enhanced management support for services) through the Feature Pack for Web Services.  While WAS V7.0 continues support of both the JAX-RPC and JAX-WS programming models so that existing JAX-RPC web services applications deployed on previous versions of WebSphere will run on V7 unmodified, the development and performance resources were almost exclusively dedicated to the JAX-WS work.  We encourage customers to move to this new programming model to take advantage of the new features as well as the significant performance gains.  Many customers I know of have moved to the Feature Pack for Web Services already, but now that it's natively supported in WAS V7.0, I expect even more customers to make a move from JAX-RPC to JAX-WS.

The chart below compares WAS V6.1 JAX-RPC performance to WAS V7.0 JAX-WS performance.  JAX-WS web services significantly outperform JAX-RPC web services for all message payload sizes shown.  For a 3k(input)/3k(output) message size, JAX-WS achieves a 70% higher throughput and for 10k/10k message size JAX-WS achieves over 2x higher performance.  For 10k/3k, 10k/10k, 100k/100k JAX-WS achieves over 3x/2.5x/2.5x higher performance, respectively.

There are many reasons for these performance gains, but the most significant one is the optimized data binding using JAXB in JAX-WS.  JAXB provides JAX-WS the framework to unmarshal XML documents into Java objects or marshal Java objects into XML.  We have done very impressive optimizations in our JAXB implementation to achieve these performance gains, well beyond what most JAXB implementations can do with StAX or SAX.  Getting high performance XML parsing combined with JAXB's full support for XML Schema is an impressive accomplishment.

Some things that matter to you specifically:  This is a primitive benchmark as it only measures web services performance (no business logic).  Therefore, your application using web services will not go 2-3 times faster just by switching to JAX-WS and JAXB, but it should markedly improve.  Specifically the additional latency involved in exposing business logic to web services and XML should go down by 1/2-2/3, which in many scenarios is substantial.  Also, even though you can handle XML yourself in JAX-WS by getting the data as a stream or DOM, it's best if you use JAXB as you'll get the most performance benefit of our optimizations.

I'm interested in feedback from users that have tried the new engine.

Web Services performance through the years

On my travels I get asked the simple question many times ... "are web services fast"?

I usually answer by showing the above graphic. Back when I started on Web Services in 2002, the answer was no. As you can see over 5 years, the answer has definitely changed to "it depends".

I say "it depends" with a little sarcasm. Obviously the performance shown in this chart tells you web services performs. However, in practice I find misuses of performance data and/or web services.

The first thing to be wary of is people trying to prove web services aren't viable are folks using "Hello World" string in/string out web services compared to legacy communication protocol xyz. I usually ask such folks how many distributed services in their architecture are string in string out with such small payloads. The answer is none. Usually the service uses complex industry standard schemas and has a small payload in with a large payload out. The above graph therefore is based on a 3k input document using banking industry standard schemas with a 10k output document.

The second thing to be wary of is primitive web services testing. The above graph is an example of primitive web services testing. This is because my team works on optimizing web services. It shows very clearly the impact of web services calling services that have zero business logic. If we optimize the performance of this primitive we will help in all scenario using web services. However, for customers you need to understand that when you add business logic, the performance impact of web services is far less of a concern. To accurately gauge performance impacts of web services in your application, I would suggest a measuring a vertical slice of your entire application, starting at the web service interface, then calling business logic, and finally any database logic. Comparing that vertical slice between web services and legacy communication protocol xyz is a useful comparison.

Lastly, don't replace every legacy communication protocol xyz in every application with web services. Web Services has been documented by almost every vendor to be useful when the service calls are coarse grained. Replacing "services" with calls that are under 1k of input with 1k of output (example a string in, a simple bean out) isn't usually a good idea. Reusable services in a SOA (for example) are typically much larger in payloads as they tend to be calling services that are not fine grained in payload or function.

Now, you may be asking two questions ...

1) How did we improve the performance over the years
2) What is the performance story for 2007 and the new Web Services Feature Pack?

I think those are two good posts to add in the next week or two ...

WAS V6.1 - Web Services Feature Pack is available

Quick note - the Web Service Feature Pack for WAS V6.1 that has been mentioned here before as a beta product is now complete and available - the announcement is here.

The new drop of the Web Services feature pack beta is available

It can be downloaded from the Early Programs site.

The beta, like the eventual GA version of the feature pack, is an optionally installable package. If you need the latest web services standards, you can add them onto WebSphere Application Server V6.1. If you don't, you can ignore it.

The latest beta is basically a fully functional version of the feature pack that is going through additional testing now. The feature pack has support for:

• Web Services Reliable Messaging (WS-RM)
• Web Services Addressing (WS-Addressing)
• SOAP Message Transmission Optimization Mechanism (MTOM)
• Web Services Secure Conversations (WS-SC)
• Java API for XML Web Services (JAX-WS 2.0)
• Java Architecture for XML Binding (JAXB 2.0)
• SOAP with Attachments API for Java (SAAJ 1.3)
• Streaming API for XML (StAX 1.0)

That's right - it's like Christmas morning for early adopting Java developers!

My surreal work experience for the day

I noted the title of an eWeek article called, "Microsoft to Reach Out to IBM, Cisco on Interoperability" and decided to take a look. Microsoft's on-again, off-again relationship with interoperability is frustrating for our customers, for example when they choose subsets of a given specification to support. So if Microsoft wants to be serious about interoperability, it can only be a good thing, right?

So here's what Bob Muglia, Microsoft's senior vice president for the Server and Tools division, had to say:

"[Our customer council] basically told me, pretty directly, that while Microsoft's implementation was in great shape, IBM's and others were not, and that Microsoft needed to do a better job helping them do a better implementation," Muglia said. "And I had to think about that, as it is one thing for us to work with customers around interoperability, but quite another to go out and help a competitor build a better product to enable interoperability."

But Microsoft has now decided to go and talk to IBM and BEA Systems and a few others to help improve and define their interoperability. "Ultimately these guys have to make their products good, but there is a lot we can do working with them to make their products interoperate better with us," Muglia said.

IBM could not be immediately reached for comment on Muglia's remarks or its thoughts about improving interoperability with Microsoft.

After I picked myself off the floor, I asked myself, "Why would eWeek allow itself to be used like this?" Clearly, this was simply a marketing move, not a signal of genuine intention to work with IBM. If Microsoft really wanted to work with IBM on interoperability, would it launch this activity by telling eWeek that the goal was for Microsoft to help IBM with our implementation? And without a response from IBM? This is not a news story, it's an advertisement.

Web Service Transaction support in WAS

The OASIS standards consortium recently announced the completion of the WS-Transaction 1.1 standard which specifies Web services protocols for 2 well-known transaction models: WS-AtomicTransaction (WS-AT) for atomic two-phase commit (2PC) transactions and WS-BusinessActivity (WS-BA) for compensating transactions.

WAS has provided support for WS-AT 1.0 and WS-BA 1.0 (the input specifications to the OASIS WS-Transaction Technical Committee) since 6.0 and 6.1 respectively.

WS-AT support in WAS (since 6.0)

WS-AT is suited to short-running, tightly-coupled services due to its 2PC nature and the consequence that participants/resources are held in-doubt during the second phase of 2PC. It is used to distribute an atomic transaction context between multiple application components such that any resources (e.g. databases, JMS providers, JCA resource adapters) used by those components are coordinated by WAS (using XA) to an atomic outcome. It is typically used between components deployed within a single enterprise where there are two primary scenarios requiring WS-AT:

• A SOA deployment requiring atomic transactional outcomes between two or more service components.
• Transaction federation between heterogeneous runtime environments. WAS WS-AT interoperability has been tested with CICS and with Microsoft .NET 3.0 framework in Windows Vista.

WS-AT is to Web services as Object Transaction Service (OTS) is to remote EJBs and in WAS neither of these require any coding, on the part of the application developer, to use. WAS ensures that the transaction context of the requester component is established by the container of the target component regardless of whether the target is invoked as an EJB (using the EJB remote interface) or a Web service (using JAX-RPC). The transaction can be started at the requester using the standard UserTransaction interface or, in the case of an EJB, as a standard EJB container-managed transaction; WAS takes care of deciding whether to use OTS or WS-AT to propagate that transaction context on remote requests depending on the type of invocation - no Java coding is required. If the requester is a Web service client then the application assembler simply needs to indicate, when assembling the requester component in AST or RAD, that Web Services Atomic Transaction should be used on requests, as described in the task Configuring transactional deployment attributes in the InfoCenter.

Distributed transactions in WAS, whether distributed between remote EJBs using OTS or Web services using WS-AT, benefit from WAS transaction high-availability (HA) support. In a non-HA WAS configuration, transaction recovery following a server failure occurs when the WAS server is restarted. In a WAS HA configuration, transaction recovery may also occur when a failed server restarts but in-doubt transactions can also be peer-recovered by an active server (which is processing its own, separate, transactional workload) in the same core group. Configuring WAS for transactional high availability is described in the InfoCenter topic Transactional high availability and also in a dedicated paper with some additional background, Transactional high availability and deployment considerations in WebSphere Application Server V6.

There is further information on WS-AT in the topic Web Services Atomic Transaction support in WebSphere Application Server in the InfoCenter.

Additional features of the WS-AT support in WAS 6.1

A documented limitation with the WAS 6.0 WS-AT support is that the WAS WS-AT context cannot be propagated through a firewall. Actually, the context itself can be propagated through a firewall but the participant registration protocol flow that follows typically cannot. Since WS-AT is primarily used within a single enterprise this is not too onerous a restriction but it clearly limits the topologies in which WS-AT can be used in WAS 6.0. This limitation is removed in WAS 6.1 where the WS-AT service can be configured with the hostname of the HTTP(S) proxy server to which protocol messages should be sent for routing to the WS-AT service. While any generic HTTP proxy can be used, there are additional capabilities built into the WebSphere Proxy Server (shipped as part of WAS ND) that recognize WS-AT context and WS-AT protocol messages to provide edge-of-domain support for WS-AT high-availability and work-load-management, essentially extending these capabilities to non-WAS clients. The InfoCenter has more information on this in the topic Web Services transactions, firewalls and intermediary nodes.

WS-BA support in WAS (since 6.1)

WS-BA is appropriate for long-running and loosely-coupled services. Its compensation model means that resource manager locks are not held for the duration of the transaction, as a consequence of which intermediate results are exposed to other transactions.But WS-BA is not exclusively for use by long-running applications - short-duration, tightly-coupled applications can benefit from a compensating transaction model just as much. Scenarios where short-running applications may chose a compensating rather than ACID model include:

• the use of resources which cannot be rolled back as part of a global (2PC) transaction. For example, an application that sends an email cannot roll this back after it has been sent - but it could send a follow-up email. Other examples of non-2PC resources are LocalTransaction/NoTransaction resource adapters (RAs) in J2EE.
• avoidance of in-doubt transactions in resource managers, where the application wishes for an atomic outcome but can tolerate intermediate state being available to other transactions.

WAS 6.1 introduces a construct called a BAScope which is essentially an attribute that can be added to any WAS core unit of work (UOW), for example a global transaction (e.g. started by the EJB container for an EJB using container-managed transactions (CMT) or by a bean using the JTA UserTransaction API). A BAScope associates a Business Activity with whatever WAS core UOW an application runs under, and has a context that is implicitly propagated on remote calls made by that application. If the remote calls are Web service calls then the BAScope context is propagated as a WS-BA CoordinationContext. If the remote calls are RMI/IIOP EJB calls then the BAScope is propagated in an IIOP ServiceContext encapsulation of a WS-BA CoordinationContext (which is actually a CORBA Activity Service context as mentioned in the footnote of this post).

Any deployed WAS component runs in a WAS core UOW scope - for example a global transaction or a local transaction containment (which is the WAS environment for what the EJB spec refers to as an "unspecified transaction context"). Any resources (JDBC, JMS, JCA RAs) used by the component are accessed in the context of that UOW. For example, an EJB with a transaction attribute of "RequiresNew" accesses resources in the scope of a global transaction. So here's what is new with BAScopes: any EJB deployed in WAS 6.1 or later may be assembled to have a BAScope associated with its core UOW, where the BAScope has the same lifecycle as the core UOW to which it is associated and completes in the same direction. An EJB that runs under a BAScope (regardless of the core UOW) may be configured (through assembly) with a compensation handler, which is a plain old Java object that implements the com.ibm.websphere.wsba.CompensationHandler interface methods close and compensate. The compensation handler logic needs to be provided as part of the application (and is assembled into the application EAR file) but it is the WAS BAScope infrastructure which ensures that the compensation handler gets driven appropriately when the BAScope ends, regardless of any process failures. The BAScope infrastructure also persists any compensation instance data provided by the EJB during forward processing for later use by the compensation handier.

The figure below shows the AST pane for adding a BAScope compensation handler to an EJB

In the above example, the ScenarioBFlightProviderACompensationHandler application class implements close and compensate methods. If the EJB's transaction is rolled back, then the compensate method will be driven which is an opportunity to compensate any non-transactional work. If the EJB's transaction is committed then the WAS BAScope support either promotes the compensation handler to any parent BAScope or, if there is no parent, drives the close method (which might typically perform some simple clean-up or else just be a no-op). BAScope parent-child relationships are managed by WAS and can be used to compensate work previously committed as part of a global transaction. For example, if EJBa running under transaction T1 calls EJBb running under transaction T2 and both EJBs are configured to run under a BAScope, then the BAScope associated with T2 is a child of the BAScope associated with T1 as illustrated in the diagram below.


EJBb can define a compensation handler class and register some data relevant to transaction T2. If T2 commits, then that compensation handler (and compensation data) is promoted to BAScope2. If EJBa then hits an exception so that its transaction T1 is rolled back, the compensation handler is called to compensate for the work previously committed in T2.

For further information on WS-BA, you can read the topic Transaction compensation and business activity support in the InfoCenter. There is a also a simple and yet comprehensive WAS 6.1 WS-BA sample that can be downloaded from developerWorks.

It should be noted that the compensation support in WAS 6.1 is focused exclusively on tightly-coupled components using a synchronous request-response interaction pattern and has no notion of any business process choreography associated. More complex compensation support for microflows and BPEL processes, including WID development tooling, requires WebSphere Process Server.

Footnote: WAS BAScopes and standards
A little while ago I wrote a short piece on the heritage of WS-Coordination and its relationship with the CORBA Activity service and the J2EE Activity service (JSR 95). When we designed the BAScope feature for WAS 6.1, we chose to use the J2EE Activity service architecture as the basis for our WS-BA implementation. The WAS 6.1 BAScope support is architected as a J2EE Activity "High Level Service" (HLS). This is purely internal and has no impact on applications that use BAScope interfaces - we already had, in WAS, this extensible Activity service infrastructure (which is also used as the basis for WAS ActivitySession support ) and simply built on this for our BAScope support. So while the WAS BAScope Java application programming interface is WAS-specific, the BAScope support itself is built upon open standards specifications. As mentioned earlier, BAScope contexts distributed between Web services use a standard WS-BA CoordinationContext and BAScope contexts distributed between EJBs use a standard CORBA CosActivity::ActivityContext service context.

-- Ian Robinson