Ian Robinson's Weblog

WAS V8.5 Alpha and the WebSphere Liberty Profile

2011-10-15T15:41:00.019+01:00

Earlier this year I took on the role of Chief Architect of the WebSphere foundation and have been busy with the team since then working on the development of our next release. We launched the first fruits of our labour last week through our new WASdev community site: the WAS V8.5 Alpha. This is an early glimpse of what's coming next in WAS and it is heavily focussed on making the WAS runtime and tools the best environment possible for developing and testing web applications. At the heart of the Alpha is a new dynamic profile of the WebSphere runtime that we've called the WAS Liberty Profile. Rather than being a static profile of runtime features, Liberty adapts to the requirements of the application and ensures - at a really fine-grained level - that only the necessary application container functions are started. It gives you the freedom to deploy web applications with wide-ranging requirements and provides all the pieces they need (like security, transaction management, connection pooling, persistence through JPA or JDBC, and so on) without pulling in any more than they need. And it provides fidelity with the full-profile WAS runtime to which applications are deployed in production because the containers and services started by the Liberty profile are the same.

One of the key innovations in Liberty is a new kernel that processes the specific "features" required by an application to load the required container(s) and WebSphere platform services: WAS has been an OSGi-based runtime for many years (since WAS V6.1) but, with the Liberty profile in the WAS V8.5 Alpha, we've moved beyond simply modularity and gone to town on exploitation of dynamic OSGi services. This is what delivers the tiny runtime footprint and a WAS server that starts up in a couple of seconds. And this is only one aspect of what's new for developers - we've also dramatically simplified server runtime configuration so that a test/debug WAS server instance can be configured easily, either inside or outside an Eclipse environment, with a single XML file covering all aspects of the server, the applications and the resources required by the applications. If you've ever looked at a WAS configuration and wished you could treat it more like a development artefact - storing the configuration in an SCM system, versioning or diffing it, sharing it between developers - well now you can. While the server config can be as simple as a single XML file, there are also flexible ways to compose a configuration from fragments that are aggregated through include statements.

The WASdev home page lists "8.5 Reasons why the WAS Liberty Profile is awesome". For more details, including an overview of the new simplified server config, take a look at the Introduction to the Liberty Profile article I posted to WASdev.

And did I mention that its free? And so, now, are our most popular web development tools which we're making available as Eclipse features (in addition to being bundled inside RAD). You can get all this from WASdev downloads page.

But enough talk....lets see how quickly we can download the tools, the WAS server, configure a server instance, install a simple app and bring the whole thing up. I'll assume you already have the Eclipse IDE for Java EE but if not you can get that from the Eclipse site. The only other thing you need is an IBM ID for the downloads - if you don't have one then simply register for one here.

OK. Open up your Eclipse IDE (3.7 or 3.6.2), start your stopwatch and follow these steps:

Go the WASdev download page to install the WAS Liberty Profile tools into Eclipse. This gives you a rich set of web development tools along with the ability to launch and control instances of the WAS Liberty Profile server. For Eclipse 3.7, its as easy as dragging the install button from that page onto your Eclipse IDE title bar.
Accept the license terms (I'll take the liberty of assuming that, under these "beat the clock" conditions, you have already squared this with your friends in the legal department) for the install to proceed. The total size of the tools being added to your Eclipse environment here is less than 3M.
Restart Eclipse. The tools are now installed - we can use these to now install the WAS server runtime itself for use testing and debugging applications. This is going to download and install a whole WAS Liberty profile server. Sounds scary? It isn't - the whole runtime is just another 25M and there's no additional installation program required.
In the Eclipse workbench, open the Servers view. Right-click the Servers view and select New > Server. Under the server type list, expand IBM then select the WebSphere Application Server v8.5 Alpha Liberty Profile server type. Click Next.
The WebSphere Runtime Environment page is displayed. In the Installation folder section, click download and install. Choose the WebSphere Application Server V8.5 Alpha site and enter your IBM ID and password and click Next. Accept the license terms for the runtime. (You'll have already mentioned this to the same lawyer you talked to about the tools license). Click Next.
In the Download and Install page, specify the installation target folder for the WAS runtime to be installed to. (Just 25M, remember).
Click Next. WAS is now installed. (Note that, if you just want to install the WAS Liberty profile runtime independently of the tools for test and debug puposes, then you can skip all the steps above and simply download the WAS Liberty Profile runtime directly from the WASdev downloads page and unzip it).
There's a pre-configured defaultServer instance but lets go all the way and create our own server instance using the New button. Call it whatever you like e.g. firstserver. Click Finish. You now have a WAS server instance to which you can install and test web applications. On your filesystem, there will be a firstserver directory structure in the usr/servers directory of your new WAS install.
Now we need to deploy a web app to this server and run it. You can download this simple StopWatch WAR file and import it into Eclipse.
In Eclipse: File > Import WAR file. Click Next. Enter the location of the WAR file on your filesystem and make sure the Target runtime is set to WebSphere Application Server V8.5 Alpha Liberty Profile. Click Finish.
In the Project Explorer, right click on the new StopWatch project and choose Run As > Run on Server.
The WebSphere Application Server V8.5 Alpha Liberty Profile should already be highlighted. Click Finsh.
Stop the Clock!

If you're looking for the fastest, cheapest and easiest way to develop web apps for WAS then this is it.

I've been busy spreading the message about Liberty since we started the WAS V8.5 Alpha - you can take a look at my slides from the WebSphere Technical Conference in Berlin, where we launched the Alpha:

WAS Liberty Profile

And if you happen to be in Mumbai on Oct 19 or 20, come and hear me talk about Liberty at the IBM Software Universe.

God Dad, You're Soooo Embarrassing

2011-06-18T12:28:00.003+01:00

...the words every proud parent longs to hear, to know they've succeeded in keeping their offspring alive long enough for them to become a teenager. I heard this as I walked through the door yesterday and was doubly pleased when I found out why. The video I made a little while ago to kick off the new Enterprise OSGi YouTube channel has successfully attracted enough attention for my daughter to be teased at school, once again proving the value and reach of social media. Result.

OSGi and SCA come together in the WebSphere OSGi Application Feature Pack

2010-05-28T13:22:00.001+01:00

28 May 2010: The WebSphere V7 OSGi Application and JPA 2.0 feature pack is now generally available (and free!) and supported for production use. This is something we're pretty excited about in the WebSphere team as it offers some truly powerful techniques to simplify the development, management and maintenence of complex enterprise applications. I described some of the primary use cases for enterprise OSGi applications in a previous post about the early program we've been running since the end of 2009. Some significant additional capabilities have been added since then.

The first one I'd like to talk about is SCA. If you install both the OSGi Application feature pack and SCA feature pack then you'll find not only do you have the ability to assemble SCA composites and OSGi applications but you can also include OSGi applications as components in SCA composites - the combination of these two feature packs is greater than the sum of the parts. So what does it mean to use SCA with OSGi? The two technologies are used for quite different purposes but are extremely complimentary.

OSGi provides a means to break down your enterprise application into (i) modules (bundles) that are specific to the applicaton and (ii) bundles that are common across applications. The latter can be separated out from the application archive and placed in a common OSGi bundle repository that WebSphere is configured to use during application deployment. Immediate benefits include smaller applications, a standard mechanism for using shared libraries in enterprise applications and a smaller memory footprint when two or more enterprise applications share common libraries. And you haven't needed to write any new or different Java code to take advantage of this. Another feature OSGi brings is a standard extensibility model - through OSGi services. You can design your application to take advantage of OSGi's rich and dynamic service-based model to consume services from the OSGi service registry. Service interfaces then become extension points that you can design into your application and extend it in the future via service provider implementations introduced through separate bundles with no change to the original application code. OSGi defines Java APIs for registering and discovery OSGi services but a declarative approach to use OSGi services is much simpler. This is where the OSGi Blueprint container comes in - the Blueprint container (which is added to the WebSphere runtime when the feature pack is installed) manages the lifecycle and dependency injection of POJO bean components and is configured through an application-level XML bean definition file which is a standards-based evolution of the Spring bean definition XML. Blueprint provides a fine-grained bean assembly model for OSGi applications and simple declarative means to publish a service provided by a POJO bean component. For example, the following bean definition snippet defines a bloggingServiceComponent bean, implemented by the BloggingServiceImpl class for which a BloggingService service is registered to the OSGi service registry.


<blueprint>
  <bean id="bloggingServiceComponent" class="com.ibm.ws.eba.example.blog.BloggingServiceImpl">
    <property name="blogEntryManager" ref="blogEntryManager"/>
    <property name="blogAuthorManager" ref="blogAuthorManager"/>
    <property name="blogCommentManager" ref="blogCommentManager"/>
  </bean>
  <service ref="bloggingServiceComponent" interface="com.ibm.ws.eba.example.blog.api.BloggingService"/>
</blueprint>

So now we can build a modular, extensible application assembled from POJO components described by a standardized XML bean definition file. No SCA so far - when does that become interesting?

Say you wanted to remotely publish the BloggingService and make is available over an ATOM binding. Or you wanted to compose your OSGi application into a coarse-grained composite with other non-OSGi components. These two scenarios are where SCA comes in. The WebSphere OSGi and SCA feature packs support both these patterns through the introduction of a new SCA implementation type, impl.osgiapp. By defining an SCA component for your OSGi application you can assemble it into an SCA composite with any other SCA implementation type - for example an EJB component (impl.ejb). And by promoting the OSGi <service> definition into an SCA component definition, the service becomes remotable with a choice of any of the standard SCA bindings to determine how the service invocation and parameters should be serialized. Thats a pretty powerful extension to raw OSGi applications and enables OSGi applications to be used as part of a SOA application deployed to WebSphere.

And then there's the tooling. The second major addition to our OSGi Application support that I wanted to mention is our Eclipse-based tooling to simplify the development and deployment of OSGi Applications. Integrated into the new RAD Beta are new project types for OSGi Applications, graphical tools for editing OSGi Application and OSGi bundle manifests and a Blueprint XML editor for blueprint module definition files. These offer familiar design and source views so you can choose to edit the metadata directly or through a form-based editor. And of course there's all the content assist, validation and re-factoring productivity tools familiar in RAD. The RAD Beta also integrates a test server environment augmented with the OSGi feature pack to enable simple run-on-server testing.

RAD Beta OSGi Blueprint XML Editor

The feature pack contains a number of comprehensive samples that illustrate the primary use cases. Try it out - and if you have any questions or comments, visit the OSGi Application feature pack technical discussion forum.

Apache Aries - An open source project for Enterprise OSGi Applications

2010-03-08T14:47:00.002Z

I spoke at the recent OSGi DevCon London conference (part of JAX-London 2010) as it extended late into the evening - Oracle's Mike Keith and I were competing with the bar in the 9-10pm slot as we talked about the Apache Aries and Eclipse Gemini open source projects. For those of you who chose the bar, or who couldn't make it to the gathering in West London, here are my slides on Apache Aries. They describe the primary goals and capabilities of Apache Aries, including how to get involved.
The 1-line summary is: Take a look at Aries if you want ready-to-use components that provide enterprise OSGi capability or if you want to join the development community to drive the technology forward.

Apache Aries Overview

View more presentations from irobins.

WebSphere: up to its EARs in OSGi

2009-12-27T19:08:00.001Z

WebSphere Appplication Server has been up to its neck in OSGi for ages, running as a collection of OSGi bundles on an Equinox framework since WAS 6.1 was released in 2006; now, with the WAS V7 OSGi Application Alpha, its up to its EARs as well enabling enterprise web applications to be optionally developed, assembled, deployed and managed as a collection of versioned OSGi bundles. The Alpha is an early program to showcase and get feedback on WAS enablement of OSGi exploitation by applications.

OSGi Application support in WAS is complementary to the Java EE programming model and aims to enable the use of familiar Java EE technologies - for building web UI components, accessing resources, using container managed transactions and security - as well as familar WebSphere adminstrative tasks for application deployment and management. OSGi Applications are assembed from a collection of modules and optional metadata into an archive and deployed to WAS in a similar manner to Java EE applications. There are several differences to standard Java EE assembly and deployment though. First of all, while the ".eba" archive (enterprise bundle archive) may contain all the application's modules and dependencies within it, as a Java EE EAR typically does, it may also refer (through application-metadata) to some or all of the application content as explicit dependencies and omit those from the archive. Of course, these have to be provisioned from somewhere, which is where the WAS configured OSGi bundle repository comes in. Application modules and common libraries that need to be shared between applications can be installed (through WAS admin) into one of the configured OSGi bundle repositories and these repositories are used by WAS admin during application deployment to ensure that all an application's dependencies are resolved. For example, one of the Alpha samples uses a JSON library that can be installed into the integrated WAS bundle repository and shared between the sample application and other applications - the WAS Admin view on the bundle repository is shown below:

WAS can be configured to use existing repositories instead of or as well as the integrated internal repository. At the application level, it is not necessary in the application metadata to describe a transitively closed set of dependencies - WAS works this out during deployment and produces deployment metadata that describes precisely which modules the application consists of. If deployment metadata already exists then it can be used during application deployment - this is useful if an application has been tested in a QA deployment and is ready to be rolled out to a production system - you now want the application you tested to be deployed rather than a newly resolved version of it.

If you have many applications using common libraries then having a single copy of those modules shared between applications is better then deploying a copy of the common library in each EAR. Having the dependencies resolved at deployment time ensures that applications cannot be started unless all their dependencies are present, eliminating hard-to-debug ClassNotFoundExceptions that can occur in more loosely-managed shared-library installations. Since OSGi modules are versioned, different applications can easily move to new versions of a common library at their own pace, independent of other applications. And horrible second-order dependency clashes are avoided by module-versioning so that if an application has two libraries, A and B, which need both a third library C - but at different versions - then the application will deploy successfully with both versions of C.

Once the application is installed, it is ready to be started just like any other WebSphere applications. Starting the application is what causes the bundles to be "installed" in the application-level OSGi framework (and started). This is "install" in the OSGi lifecycle sense - the applications have already been installed in the WebSphere sense to the target WAS servers.

An installed OSGi application can be managed at the bundle level - if later versions of bundles are added to the configured OSGi bundle repository after the application has been installed these will not affect the applicaiton but will be available in the WAS Admin console if the application is to be updated to such later levels.

By way of illustration, the WAS Alpha sample mentioned above delivers 3 bundles, one of which is a web application which has a dependency on a common JSON library. From a management perspective, the application consistents of the set of four libraries, one of which is denoted as being shared. If a later version of the JSON library were to be be deployed to the configured bundle repository then it would show up in the drop-down list of available versions in the view shown below. Selecting that version would cause a re-resolve of the application which, if successful, would offer the administrator the opportunity to save the configuration and update the application.

I've mentioned web applications a few times. The migration step to convert an existing Java EE enterprise web application, consisting of one of more web archives (WARs), into an OSGi application involves renaming the archive from .ear to .eba prior to deploying to WAS. For most web apps its as simple as that. WAS introspects any WARs within a .eba archive and generates the OSGi metadata required to convert this to a web application bundle.

One final note - one of the innovative technologies included in the WAS V7 OSGi Application Alpha is an integrated OSGi Blueprint container. This is a dependency injection container whose heritage is derived from the Spring framework; it enables business logic to be built from simple POJO components whose lifecycle and dependencies - including references to other components and to resources such as JDBC and JMS providers - are described in an XML "blueprint" and managed by the Blueprint container.This and other features of the WebSphere OSGi Application support are being developed as open source components of the Apache Aries project and integrated into WAS.

Thats all for now - do take a look at the Alpha and let us know what you think.

OSGi 4.2 Published

2009-09-25T18:35:00.001+01:00

My previous post mentioned early drafts of the OSGi 4.2 specifications which define part of the enterprise OSGi programming model that the new Apache Aries project is implementing. Since then the OSGi Service Platform V4.2 have been finalized and published by the OSGi Alliance. The platform is defined in two specifications - the "core" and "compendium" specifications. The latter includes the new Blueprint container specification mentioned in the previous post, an important part of the enterprise OSGi programming model we're implementing in Aries.

OSGi in the Enterprise – the Apache Aries incubator

2009-09-08T17:53:00.002+01:00

There have been an increasing numbers of discussions recently - these two on TheServerSide are pretty representative - over the role of OSGi technology in enterprise Java applications. On the one hand it can be an asset in enabling a more modular approach to building enterprise applications: not only is a significant amount of enterprise Java middleware built on OSGi for this reason but so are some significant applications such as LinkedIn and the Jazz Team Server. On the other hand is the question of just how OSGi features in the programming model for enterprise applications. What is the web component model? The persistence model? How does the vast landscape of existing Java EE components begin to take some advantage from OSGi?

These are the questions the OSGi Alliance Enterprise Expert Group (EEG) are addressing through a set of specifications related to how existing, familiar Java EE technologies are exploited in an OSGi environment. For example, the EEG's Web Application specification (RFC 66) describes how an OSGi web container manages the lifecycle of application components written to the Servlet and JSP specifications and how existing WAR files are transformed to a web application bundle whose web components are then managed by that container. Other EEG specifications follow a similar pattern, describing how JPA, JTA, JNDI and other technologies in common use in Java EE applications should be catered for in an OSGi environment. And the Spring framework is relevant here too as the inspiration for the OSGi Blueprint container specification. This defines a standard dependency injection container including the application configuration XML (the application "blueprint") used by the container to manage, wire and configure simple Java components and optionally publish/consume these as services in the OSGi service registry. A public draft roll-up of these specifications was published earlier this year by the OSGi Alliance, ahead of finalization.

The broad adoption of OSGi as part of the enterprise Java application programming model depends not only on the EEG specifications - to encourage consistency of behaviour across enterprise OSGi platforms, to ensure application portability and avoid vendor lock-in - but also on their widespread implementation. This is the primary motivation of the Aries incubator, which aims to deliver implementation of the EEG specifications that are part of the enterprise OSGi programming model. Aries sets out to provide enterprise OSGi componentry that can be integrated into application or integration server runtimes - such as Geronimo and ServiceMix - without being tied to any one of these. Some of the work - for example the Blueprint container implementation - actually started inside Geronimo but, as it evolved, it seemed better to move it into a new incubator to help develop a community with a focus on enterprise OSGi that was independent of any specific target runtime.

Want to help develop Aries? Have a look at the proposal and discussion and get involved.

Spring and WebSphere – fish and chips, or fish on a bike?

2008-05-06T23:34:00.000+01:00

The announcement by SpringSource last week of a Spring-OSGi based application server – the SpringSource Application Platform – has generated quite a storm of discussion in the blogosphere from fans and detractors alike. Is all the excitement merited? And what impact, if any, does it have on WebSphere's support for Spring applications?

I think its merited - that's why I'm writing about it. The Spring framework has done a lot to shake up the Java Enterprise world by popularising the dependency injection (DI) pattern both as a way to wire application components together and as a way to provide the enterprise services those applications need. This was a “good thing”, as was the adoption by EJB3/JPA and JAX-WS Web Services of DI-based POJO programming models, enabling POJO-based business logic to be developed and more easily tested outside a JEE environment thus accelerating and simplifying the development experience. Enterprise qualities of service, such as security and transactions, get applied by the JEE container without requiring changes to the application when the application is deployed into the JEE container. The Spring framework goes further with this than Java EE because the Spring framework is itself a “lightweight container” that is bundled with the application regardless of whether the application runs in a Java SE or Java EE environment. The lightweight container that is a part of the Spring framework spring.jar abstracts away some of the differences between an underlying Java EE runtime vs an underlying Java SE runtime. For example, the Spring framework transaction support provides a common local transaction demarcation model regardless of whether the underlying runtime is SE or EE. Actual transactional work within the demarcation scope is delegated to the underlying resource managers wired into the application – for example JDBC or JMS providers.

A common misunderstanding I see from people coming into contact with the Spring framework for the first time is that the Spring framework itself provides many of the enterprise qualities of service available in a Java EE container. Again, Spring support for transactions is a good illustrative example. The Spring framework reference documentation, for example, says “One of the most compelling reasons to use the Spring Framework is the comprehensive transaction support.” In my opinion, comprehensive transaction support is one of the most compelling reasons to use a JEE AppServer which actually provides a recoverable 2PC transaction manager. The Spring framework does not – it simply delegates to whatever is already there. In a Java SE environment, this means the resource (JDBC, JMS etc) provider; in a Java EE environment this means the JEE AppServer’s JTA transaction manager.

The core Spring framework has done a good job of integrating with various underlying Java EE providers. Its complimentary nature and popular adoption by Java developers have led WebSphere and all of the major JEE vendors to demonstrate integration with and exploitation by the Spring framework. People like the Spring framework because it provides a nice, simple composition and deployment model and gives them portability between Java SE and EE runtimes.
This portability is different from portability of JEE applications between JEE vendors. Portability across Java EE vendors is at the level of Java EE APIs (EJB, JMS, JTA etc) standardized through the Java Community Process. The Spring framework libraries define their own Java programming interfaces; these interfaces are not part of any standard but applications that use them are portable between Java SE and EE runtimes because the Spring framework libraries are packaged as part of the application rather than as part of the underlying runtime platform. This Spring "lightweight container" isolates the application from the differences between SE and EE runtimes. In an EE runtime, the lightweight container delegates to the EE container to engage the EE qualities of service.

While there clearly is synergy between JEE providers and the core Spring framework, it remains to be seen how the new SpringSource Application Platform will change the dynamics of the relationship between SpringSource and the other JEE vendors. I say “other” because SpringSource now, for the first time, is going to be positioned as a JEE vendor. This may not be SpringSource’s primary intention but it is inevitable given comments like “It is highly likely that the SpringSource Application server will become Java EE 6 Compliant in some form” from SpringSource’s Rod Johnson on InfoQ. But JEE is not the SpringSource end game here – OSGi is. There has been a great deal of interest expressed over the last year in combining OSGi’s modularity with Spring’s application configuration model, which is what the Spring Dynamic Modules project offers – under an Apache open source license. The next logical step is the dynamically provisioned application server platform that hosts Spring-OSGi applications as the deployable unit, a step SpringSource have taken with their new SpringSource Application Platform offering. But there remains a “roll-your-own” approach towards familiar JEE enterprise services such as messaging, persistence and transaction support – these are services that need to be plugged in, they are not provided by "S2AP" itself. Perhaps that will change over time and S2AP will evolve its own positioning into a complete enterprise Java application server.

Does any of this affect WebSphere? Well, nothing has changed in the core Spring framework. Regardless of what the future holds for the SpringSource Application Platform, the core Spring framework project remains complimentary to WebSphere. Like fish and chips.

Is WS-Transaction useable in the real world today?

2007-08-20T09:55:00.000+01:00

The WS-Transaction specifications can be used by a Web service to include the processing of the service in a distributed transaction. But Web services themselves are often simply a means to integrate existing applications into new composites and/or a means to expose those applications to new types of clients/channels. So, in a bottom-up design where new Web services that can exploit WS-Transaction capabilities are wrappering existing back-end applications, do the back-end applications have to have been designed to be used with transactions?

The answer is: it depends...

The back-end applications might provide a core business service that has been doing its job well for many years and runs in an environment that ensures the transactional integrity of any data updates performed by the application, such as a CICS program. Or the back-end application might be a database stored procedure, or a purchase order workflow or anything else.

Most of them will have been around for longer than the WS-Transaction specifications but equally most of them can be exposed through Web services that exploit WS-Transaction capability.

WS-AT is typically useful only when the back-end application runs in an environment that supports some form of distributed 2PC, although the precise manner of the 2PC really doesn't matter since the WS-AT provider can adapt the AT protocol messages to the desired domain-specific transaction protocols. So, for example, WebSphere Application Server represents a received WS-AT context as a JTA transaction within the AppServer process and hence subordinates any XA resource managers (including XATransaction JCA resource adapters) and downstream OTS resources (and on zOS, any RRS unit of recovery) to the received WS-AT context.
WS-BA is typically useful when any work performed by the back-end application can be undone/reversed through a compensation handler that drives another back-end application (or by the same back-end application with a different set of data). The compensation handler logic itself is application logic but the determination of when/if such a compensation handler should be driven and the recoverable recording of data to be used by the compensation handler is what the WS-BA infrastructure must provide.

WAS provides robust runtime support and application assembly for Web services to exploit WS-AT or WS-BA which can be used in highly available configurations as well as mediated/proxied toplogies. The development tasks associated with supporting WS-AT and WS-BA in WAS are focussed on application assembly and configuration rather than Java programming, the only coding requirement being the CompensationHandler class (a plain old Java object) in the case of WS-BA.

There's plenty of information in the WAS 6.0 and 6.1 InfoCenters on how to use this feature of WAS and samples that can be downloaded from developerWorks. As a general guide through all that information, I posted an article on Web Service Transaction support in WAS on the WebSphere Community Blog. There's also a good article on Building transactional Web services with WebSphere Application Server and Microsoft .NET using WS-AtomicTransaction that describes how to configures both systems for WS-AT interoperability.

Going back to the title of this article, I believe the answer is a resounding Yes and there are numerous commercial runtimes - including IBM's WebSphere Application Server and CICS - that have tried and tested production-ready support available today.

Feel free to comment on any gaps in the information that could be usefully filled.

Web Services Transaction 1.1 OASIS Standard published

2007-05-09T09:24:00.000+01:00

OASIS, the international standards consortium, announced on 8 May 2007 that its members have approved Web Services Transaction (WS-Transaction) version 1.1 as an OASIS Standard, a status that signifies the highest level of ratification.

The final open standard versions of the WS-Transaction 1.1 are now available at the locations referenced in my earlier post.

Which J2EE platform does Ségolène Royal use?

2007-04-20T11:10:00.001+01:00

Ségolène Royal
Originally uploaded by Fr@nçois.

WS-Transaction 1.1 has been committed

2007-04-17T21:26:00.001+01:00

The WS-Tx TC - which IONA's Eric Newcomer and I chair - has now delivered the WS-Transaction 1.1 OASIS Standard which comprises the following specifications:

WS-Coordination 1.1 - which describes a common framework for Web services transaction models,
WS-AtomicTransaction 1.1 - which uses WS-Coordination and describes a Web services protocol for atomic, 2PC transactions,
WS-BusinessActivity 1.1 - which uses WS-Coordination and describes a Web services protocol for compensating transactions.

The TC held its first meeting in November 2005 and took, as input, drafts of these three specs that were contributed by members of the TC including IBM, Microsoft, IONA, Hitachi and BEA. During the course of the TC a number of the companies involved in the TC (IBM, Microsoft and JBoss/RedHat) developed implementations of the specifications to test the completeness of the specification by driving a number of pre-agreed AT and BA interop scenarios. We did this remotely using internet endpoints and it successfully validated all the parts of the specs covered by the scenarios. You can view the results for AT and BA scenarios.

Follow-on work

The TC will continue in maintenance mode to work on any maintenance issues brought to our attention and to produce a new version of the specifications with an updated references to WS-Policy 1.5 once the W3C has published a W3C Recommendation for WS-Policy 1.5 anticipated in August 2007.

Tags: ws-tx, WS-Transaction, WS-AtomicTransaction, WS-Coordination, WS-BusinessActivity, WS-AT, WS-BA

The roots of WS-Coordination

2007-04-03T19:50:00.001+01:00

When the OASIS WS-Tx TC was formed, Eric and I (as the co-chairs) did a number of press and analyst interviews to explain what it was all about. Eric, being the urbane and media-savvy CTO, made observations such as "I think everybody saw where it was going early on in the dot-com days, but it's taken a while to get there". My pearl of wisdom that got used in the same article:

Though WS-Coordination is the first spec in line for approval, Robinson called it "perhaps the hardest to understand."
"It deals with the context of the transactions," he said.

Well I'm glad that's clear then.

So what are the origins of the WS-Coordination part of WS-Transaction and what is it all about? WS-Coordination is one of three specs that together comprise WS-Transaction 1.1. The underlying two-phase commit (2PC) and compensating transaction models that underpin the other two specs - WS-AtomicTransaction (WS-AT) and WS-BusinessActivity (WS-BA) - are well-known from the literature (for example Gray&Reuter); WS-AT and WS-BA pretty much just describe an XML structure for the 2PC and compensation model protocol messages that defines those two transaction models. But what about WS-Coordination?

The origins of WS-Coordination are in the CORBA Activity service, which itself was the result of an OMG request for proposals to specify Additional Structuring Mechanisms for the OTS Specification.

CORBA Activity Service.
The Activity service defines a CORBA framework for extended transaction models, recognizing the common attributes of distributed transaction models without preferring any specific one of them. Specifically, the framework defines:

a generic Activity context that is distributed to Activity participants
a generic ActivityCoordinator with which Activity participants are registered and which is extended by model-specific SignalSets
the notion of a transaction-model-specific SignalSet which produces model-specific Signals that the ActivityCoordinator delivers to the registered Actions (participants) and consumes Outcomes that are returned by the Actions. For example, a 2PC SignalSet produces "Prepare", "Commit", "Rollback" etc Signals and consumes "Prepared", "Committed", "Aborted" etc Outcomes.

A specific transaction model is defined in terms of its SignalSet, the Signals produced by the SignalSet and the Outcomes consumed by the SignalSet. The participants in any specific transaction model are Actions which must be implemented to understand the model-specific set of Signals and Outcomes.

The Activity service specification defines an overall extended transaction framework architecture but does not explicitly distinguish which parts of the architecture are intended to be provided by middleware infrastructure and which parts are intended to be provided by the transaction-model-provider. Such architectural partitioning is explicitly specified in the J2EE rendering of this architecture - the J2EE Activity service (JSR 95), which finalized in 2006.

J2EE Activity Service
The J2EE Activity service defines Java interfaces for the Activity service objects. It defines the notion of a "High Level Service" (HLS) which embodies a specific transaction model. The J2EE Activity service specification defines a specific contract between a J2EE container and a HLS in much the same way that the Java Connector Architecture specification defines a contract between a J2EE container and a resource adapter.

In the J2EE Architecture, the server runtime implements the ActivityCoordinator interface which supports the registration of participants (Actions), and the UserActivity interface which supports Activity demarcation. The server runtime also marshals/demarshals Activity contexts on remote invocations; the J2EE architecture leverages the CORBA Activity service specification for its definition of interoperable Activity service contexts in much the same way that the EJB specs leverages the CORBA OTS specification for its definition of interoperable transaction service context. Providers of specific transaction protocols can then register a transaction protocol-specific HLS with the container's Activity service to integrate transaction-specific behaviour into the container. Such an HLS implements the SignalSet, Signal, Action and Outcome interfaces that the Activity service drives. The HLS and Activity service cooperate together during transaction completion but maintain separation of concern: the ActivityCoordinator maintains knowledge of which participants are registered, obtains each distinct protocol Signal from the local HLS SignalSet, distributes it to each of those registered participants ("Actions") and feeds the results ("Outcomes") back into the SignalSet.

WS-Coordination
The WS-Transaction architecture is a Web services evolution of the Activity service, focusing on the interoperable context and Web service messages that flow between coordinator and participant. WS-AT and WS-BA each essentially describe an HLS, defining a transaction-model-specific set of messages. WS-Coordination fulfils the role of the container-provided Activity service, defining the interoperable XML CoordinationContext and the means for participants to be registered with an Activity.

The focus of WS-Transaction is the interoperability between coordinators and participants in different systems; consideration of intra-process separation between the transaction service provider itself and the runtime (application-hosting) container and/or hosted applications is a domain-specific detail that is outside the scope of the Web service specifications. As a result, the WS-Transaction specifications do not define any equivalent of the HLS SignalSet interface nor do they define a generic mechanism for producing and consuming a single (extensible) typed Signal. Instead the WS-Transaction architecture requires each transaction model-specific protocol specification (such a WS-AT and WS-BA) to define its own set of XML protocol messages along with coordinator and participant WSDL portTypes to consume these messages. In common with Activity service HLS's, individual WS-Transaction protocol specifications are at liberty to define model-specific interfaces/protocols to enable applications to demarcate transaction boundaries. WS-AT, for example, defines a Completion portType and protocol through which an application can request the completion of an AT transaction (which then causes the 2PC protocol to be initiated with the registered participants).

Since the WS-Transaction architecture is a Web services evolution of the Activity service, it should be possible to implement it on top of an existing Activity service architecture, right? After all, a significant amount of Web services infrastructure is a thin XML veneer on top of something else, right? Well, yes. I'll blog about how we do that in WebSphere Application Server another day.

Further Reading
This posting has focused on how the CORBA/J2EE Activity service provided much of the inspiration for WS-Coordination. For a discussion on where a number of other extended transaction models, such as BTP and WS-CAF, fit in and compare with WS-Transaction the following articles are useful:

The final WS-Tx TC meeting?

2007-01-24T13:01:00.000Z

Last week we had what will probably be the final WS-Transaction TC (WS-Tx) face-to-face meeting, here in Hursley in the UK. Its nice to have everyone else do all the travelling now and again.
I have co-chaired the TC with Eric since November 2005 and we are now nearing the end of the standardization process.

The TC will shortly vote on the approval of committee specification status for our 3 specs - WS-Coordination, WS-AtomicTransaction and WS-BusinessActivity. This is the penultimate stage before submitting to the OASIS membership for consideration as an OASIS standard.

You can see the excitement on the faces of the technical committee as we prepare for the final stage of the standards effort...

The photo was taken in the Kings Head in Hursley, by Bob Freund.

Its been a long and winding road - early drafts of the input specs were published as long ago as 2002 and the foundation WS-Coordination specification was itself inspired by earlier work on the CORBA Activity service. There are already several generally available implementations of the input specifications and pre-production implementations of the proposed final standard. It is to be hoped that the proven success of the WS-Tx protocols in existing, commercially available products together with the extensible nature of WS-Coordination will make this technology the obvious base for new types of coordination protocols. Time will tell...

Margaret Thatcher and me

2007-01-22T16:07:00.000Z

I am proud to have one thing in common with The Iron Lady.

Before she married Dennis, became Prime Minister, destroyed Britain's coal industry, and gave us all a laugh by leaving Downing Street in tears, Margaret Roberts was a research chemist whose work included the study of Langmuir-Blodgett films, the topic of my own PhD. Margaret and I both moved on from our careers in research.

Ultimately though, neither of us was as successful as Katherine Blodgett who, as you can see from the link, went on to become Queen Elizabeth II.

WS-ResourceTransfer update

2007-01-22T14:19:00.001Z

In 2006 IBM, Microsoft, HP and Intel announced an initiative to unify the WSDM and WS-Management standards supporting service management. This initiative includes the unification of the infrastructure that underpins WSDM and WS-Management. I'm the editor of the first specification published (in Aug 2006) as part of that initiative - WS-ResourceTransfer (WS-RT) - which defines a Web service retrieval and update protocol for manageable resources. This specification took as its inputs the WS-Transfer W3C member submission and the WS-ResourceFramework (WSRF) OASIS standard; our goal is to bring together the two communities using these specifications, and those that build on them,

At the time of writing the most recent activity on this specification was the public feedback workshop held in Cupertino, CA, on 6 Dec 2006. The feedback we received was generally very positive and will be factored in a future revision of this specification. A foilset that describes the WS-RT specification and the feedback we received are available through the WS-RT Workshop YahooGroup.

2007-01-22T10:48:00.000Z