Enter The JBoss Matrix Where JBossians blog

Over the past few years we have made a conscious choice to separate community projects from commercial platforms. Why is this the case? What differentiates between our community and commercial software? Probably the most obvious difference is that we sell support (24x7) on commercial platforms whereas projects are given a best-effort support through public forums. But really there are benefits and trade-offs associated with either option.

Project

With this option the projects are always at the cutting edge. They release frequently (usually every 8 to 10 weeks) and they drive a lot of our innovation. We have many community contributors, in the form of code donations, use cases, feature requests etc. Technical direction is set by a combination of the project lead and the community. Interfaces and capabilities may change frequently as the developers and users of the project learn and shape their requirements based on experiences gained. As mentioned above, the support given to project code is best effort, with help from the community and Red Hat employees where possible. But you should not rely on it being available all of the time. However, this is definitely the place to be if you want to be on the bleeding edge and influence next generation technology and direction.

Platform

The projects try hard to ensure that where there are cross-project dependencies they work well together. However, because they release frequently, this is not always possible. Furthermore, the amount of testing across different operating systems, databases (and their drivers) and VMs that the projects can/should do is limited. As well as the 24x7 support they offer, this is where the platforms come in to their own. A platform is a point-cut of specific projects and is typically many months behind those projects when it is released. The reason for this is the amount of testing and qualification that goes into driving a project to become part of a platform. This can often be between 3 and 9 months of effort. As well as giving this significant testing regime, platforms also provide a very strict evolution path: interfaces and capabilities cannot simply change from one release to another, and not everything that is within a project may be within a platform, e.g., something that was beta quality when the project was accepted within the platform effort will typically be removed by the platform process. If long term stability and support are what you are after then this is the place to be.

For as long as I can recall I've always liked good tools and been infuriated with those that get in the way of me being "creative" or working "efficiently". (Subjective terms, I know.) Whether it was the MetaComCo C/Pascal compiler tools for my Atari those many years back (great customization capabilities) or plain emacs (yes, it's a tool!) I've admired those groups who can make good tools. Over the years I've met many tooling groups from HP, Bluestone, BEA, Microsoft and of course JBoss/Red Hat. Some of the more successful groups have been staffed by a combination of good engineers but also people who have good HCI skills (including psychology backgrounds). But they've all usually had the same comments to make about how tooling is seen by developers: under appreciated and an afterthought. That's a shame because as far as I'm concerned a good tooling experience can bring a better ROI than adding some super cool feature here or there.

I think the key to good tooling is having the involvement of the developers on the product for which tooling is being developed as early as possible. Where I've seen this work well is when there's actually a tooling person sitting in that team full time, learning about the requirements and acting as a conduit to impart that knowledge to the rest of the tooling team. To do it otherwise can often take longer (inefficient?) and may result in something that isn't quite what is required. Despite the fact that they're all engineers, there is often an impedance mismatch between tooling engineers and project engineers; almost a language barrier. But for good tooling to work well, the conversations need to be bi-directional. This is another reason why the approach of having a tooling person sitting in the project works well, as it provides immediacy of responses.

Max, our tooling lead, is keen to say that good tools shouldn't be used to cover up poor underlying projects. He's right! I've seen that happen a lot across the industry, where the tools look fantastic but there's very little under the covers, or what is there is horribly baroque and hard to understand. Designing for tooling from the outset should be considered in the same way as designing for robustness or performance or security. It's not something that is easy to retro-fit.

Good tools (and yes, I count JBDS in that list) also grow with you. Too often I've seen tools that are either way too complex to use for beginners or are so basic as to encourage you to grow out of them pretty quickly and look for something else. (There's a reason I've been using shell and emacs for 20 years.) And of course in this world of ever changing runtimes, you really want a tool suite (or IDE in this case) that can work with more than one at a time: I hate having to fire up different IDEs for different versions of the same product, especially when there may only be a few months age difference between the runtime versions.

Fortunately we have some great people here who are passionate about tooling and understand its importance in making the whole product experience work well. That doesn't mean we've got to that nirvana just yet, but we are on the right path. We need to work more closely with the projects and vice versa in order to push this mantra of thinking about tooling through all phases of the project lifecycle and not just after the fact. The improvements we've made over the past couple of years are pretty significant and there's much more to come. I'm excited and maybe this will finally encourage me to move away from emacs ;-)

BTW, thanks to Max for the title of this entry!

You've probably all seen or heard of Transformers ("Transformers ... robots in disguise.") The gist is that these robot are flexible enough to be reconfigured into a variety of different forms depending upon the need at hand. Pretty important if you need to battle enemies from the stars and then make your way silently through the streets disguised as a Bugatti Veyron. But what, you ask, has this to do with JBoss? Well we've been working on our own adaptable infrastructure for a few years; not so we can fight Decepticons, but so that we can offer a way for the same software components to be used in a variety of different environments without requiring major rewrites, different implementations, recompilations or several months of on-site consultants. We also want to support a range of different frameworks or component models, such as SCA, Ruby and OSGi.

So how have we been able to accomplish this? With the JBoss Microcontainer. It's been in development for several years as well as being an evolution from the original JMX Micro-kernel. The basic concept is pretty simple: you can define your core services/components and their interdependencies no matter what their flavour (e.g., POJOs, MBeans) dynamically and potentially on-the-fly. What was a full-featured JEE Application Server one minute could be a scaled down embedded ESB the next. What was a basic Web server yesterday could seamlessly acquire transactions and security tomorrow.

The aim here is clear though: to allow existing investments in components that have proven their maturity over the years to be used in both lightweight and heavyweight environments. Other approaches to solving this problem typically revolve around completely different technology stacks, requiring different expertise, learning curves, support contracts etc. And that kind of solution does not evolve with your changing requirements (at least not without going back to the vendor to arrange delivery of the new product, learning it, training etc.)

But what about other deployment models, such as OSGi and Spring? Although JBoss is popular there are people who need to use these alternative frameworks/component models. In the past they meant embracing that entire framework for everything in the assumption that the choice you make today is the right choice for tomorrow. Unfortunately frameworks come and go, as well as requirements changing. So an investment in something today is not necessarily the right approach for the future. But in that case what do you do when you're left with an OSGi bundle and you don't want to stay with OSGi, for example? Well fortunately the JBoss Microcontainer offers a possible solution there too. supporting a flexible state machine model of components we can support native component model deployments as well as foreign component models on the same codebase and track dependencies across those component models.

The architecture of the Microcontainer has evolved over the past few years, so even if you looked at it a while ago it's worth looking again. For example, we've added increased flexibility to the deployment model such that we now support an AOP-like manipulation of a metadata pipeline down to the final component deployer. There's also a Virtual File System for deployments, which is a major improvement over the past. Finally it's now possible to declare that any implementors of an interface should be "injected/un-injected" via specified methods, which allows for containers to specify plugin interfaces and easily have plugin implementors associated with the container as the plugins are instantiated. These examples and others just go to prove how much thought and effort has gone into this new architecture in order for us to be able to deliver on the promise of flexibility and adaptability for user requirements now and in the future. We spent a lot of time doing this so that we could do it right once and for all time: the future is bright for JBoss and its users, because we know now that we don't have to worry about re-architecting again in a years time when another deployment environment comes along, or some subtle differences in needs force a rethink of "fat" versus "thin" deployments or "rich" versus "poor". You can safely deploy to the new Microcontainer in the knowledge that it's future-proofing you.

As an industry one thing that we often fail to remember is that standards come and go, but core requirements remain. If you look at the evolution of distributed systems over the past 4 decades, for example, you'll see the transition through DCE, CORBA, JEE, Web Services etc. These all define their own component model(s), APIs, development methodologies etc. Yet at the heart of them all critical services such as transactions, messaging, security etc. remain the same. The only thing that changes is the way in which they are wrapped into the infrastructure. Well that's something we've tried to embrace with the new Microcontainer: leveraging our tried and tested components and providing a way to use them in environments/standards past, present and future.

We are co-sponsoring CloudCamp this year. Come along to the Newcastle or Edinburgh events if you get a chance.

Sometimes standards evolution can read a bit like a religious work! For example: in the beginning there was the word and the word was "events". Some of the Web Services architects looked at the word and came up with WS-Events. The rest of the Web Services world looked on that specification and found it wanting so begat WS-Notification. But this wasn't enough for some and they begat WS-Eventing. As with so many of the standardization efforts in those prehistoric days (WS-CAF vs WS-TX, WS-Reliability vs WS-Reliable Messaging etc.), this lead to confusion for the people, especially as none of these approaches were standards initially.

Fortunately WS-Notification eventually went to OASIS and became a standard, but it lacked the support of all major vendors. A modified version of WS-Eventing became a W3C Note around the same time but this is significantly less than a standards stamp of approval, though it did have some of the author companies from the other specifications involved. Yet more confusion abounded! Event notification ranks up there with security, transactions and messaging as core to most distributed system technologies over the past 4 decades. So it was no surprise that it would eventually come to pass that events would find their way into Web Services. Unfortunately because there is no single standards body for all Web Services work, that tends to lead to competing specifications (and standards). It's getting a lot better these days than it was back in the early 2000's, but it's still not perfect.

In an effort to solve the confusion around events all of the main protagonists (ourselves included) got together last year to form the Web Services Resource Access (WS-RA) technical committee within W3C. Part of that effort will standardize WS-Eventing. The timescale is fairly aggressive, with final standards due in June 2010 (which will include interoperability efforts).

But what do you do in the meantime? Events are important. Some vendors have implementations of one or more of these specifications/standards. What does that mean now that WS-RA is changing things? Well it definitely means that if you're already using a product based on one of the existing documents you will have to change something: backward compatibility is not a key aspect of the WS-RA effort. Of course change for change's sake won't happen, but some changes are inevitable (e.g., because the specs were broken or experience has shown a better approach). I'm sure some vendors will try to provide means to allow their existing products to continue to work with the next generation, but it is likely that changes will be driven right up to the developer. So be warned.

In terms of our own WS-Eventing offering, it's based on the older documents and is a community-only release. We're going to be working on providing a version based on the evolving standard and may have early access releases before the standard comes out (being on the committee helps!) So feel free to use what we've got for now in the community and watch the forums as we begin to work on the next generation.

Back when I was a kid one of my weekly high-points was watching the original Twilight Zone (yes, in black and white). Many of those episodes started off with Rod Serling stood slightly off camera to the opening scenes, smoking and uttering the immortal words: "Submitted for your approval ..." as he whisked the viewer off on to some strange parallel reality where weird and wonderful (and sometimes scarey) things happened. With that in mind ...

"There is a fifth dimension beyond that which is known to man. It is a dimension as vast as space and as timeless as infinity. It is the middle ground between light and shadow, between science and imagination, and it lies between the pit of man's fears and the summit of his knowledge. This is the dimension of imagination. It is an area which we call the Twilight Zone"

If you've ever had to buy a car (or even a house), you probably know how things go in our world. You first decide what type of car you want (make, colour, cash range), then you look for a dealership. Next you visit the dealerships and, depending upon how good the sales guys are, may even reconsider everything you did in stage 1, coming away eventually with something you didn't evision when you first started (but hopefully something you still want!) Relatively painless. If there are any problems with the car within warranty, you go back to the dealer and they fix them for you. In all likelihood, if you get good service you'll probably keep going back to the dealership even when the warranty expires. Plus, if you choose the right type of car, the dealership is the manufacturer, with the obvious benefits that affords.

Now let's pay a visit to a strange alternate reality where things aren't quite so simple. In this world you go to the dealership and they tell you that the car you want isn't available as a single item to buy. Unfortunately in this world you have to choose all of the individual components yourself (wheels, engine, colour, brakes, airbag, ...) But not only that, you have to deal directly with the individual manufacturers in the way the dealership did in our reality. The dealership may give you recommendations, but they only provide support for the chasis (for example). Plus, that's all they will provide cover for: if you have problems with the engine, you've got to deal directly with its manufacturer because the dealership doesn't have the expertise. Bummer. (It's left as an exercise for the interested reader to map this to buying a house.)

Now fairly obviously this parallel universe is not a very nice or efficient place to live. As a consumer the last thing you want to have to worry about it keeping track of which versions of the engine work in which versions of the chasis and with which versions of the electronics, etc. Plus, you don't want to have to try to keep track of any issues the individual manufacturers may report. If there were only a few components, then maybe it's something you could do, particularly if it were cheap enough. But it really doesn't scale. What you want is the ideal of the first universe: you get everything you need from a single place and let them worry about the individual components on your behalf. Even better if that single place actually developed all of the components themselves, because then they don't have the hassle of talking to other manufacturers. It really would be one throat to choke.

The same is the case in the computer industry. Back in the late 1980's and early 1990's it was a very regular occurrence to see people buying components and building their own (cheaper) PCs than the ones they could get from IBM or Apple. Yes they had the hassle of checking which components worked together, but the results were significantly cheaper than the commercial finished products. Some people even build their own components from scratch and sold them on much cheaper (very early open source?) But as the markets matured, we saw the arrival of companies such as Viglen (UK), Gateway and Dell who really pushed the price of entry level machines down so low that it became ridiculous to even consider building your own. (It's arguable that this effect also caused the premature death of Sun's Java Station - it was just far too expensive for what you got!) These days very few people build their own and are more content to go to a single manufacturer for the product, even if the individual components are sourced elsewhere.

In the software market, we saw a similar effect. Particularly around middleware stacks. Which are always evolving. Before the advent of open source, you had to buy your complete stack from a single vendor. There were a few exceptions to this, but on the whole you were left with little choice. It simply wasn't worth the price of trading one commercial component in a complete solution for a different commercial component (even if it was supported). Open source threw us into the alternative reality for a while because it really was cheaper (100's or 1000's of times) to do it yourself; and most of the time it just worked (tm). But as the amount of open source offerings increased along with the number of them that people found useful, the support problems grew for the end user (remember the car?) This made Professional Open Source a fairly obvious solution: go to one vendor for all of your open source requirements and let them handle the support, which they can do because they wrote the stuff in the first place! Now there are not many companies that can offer the entire stack in this way. Sure there are some dealerships that can offer you "support" (notice the quotes) for the stack, but when you look deeper you'll find that most of the components you need come from elsewhere. If you like the headache and worries that can cause, then maybe it's worth exploring. However, are they really so much cheaper (and better) than going to a one-stop-shop? It's hard to be objective, for sure. But at the moment the market is clearly showing that Red Hat/JBoss are the best place to go for the middleware stack: people who tried living in that parallel universe soon found out that the cost was detrimental.

We now return you to your regularly scheduled program.

A reprint from the JBossESB blog:

In May 2006, Swedish Railroads (SJ) was looking to upgrade its internal software delivery system in order to provide a shared platform for all IT systems. The integration of the IT systems is essential for SJ as it uses a diverse range of applications ranging from HR to sales, which need to be accessed across a range of interfaces, from PCs to PDAs. Within SJ, a new department was established with the task of building an integration platform and delivering new services for the business to operate on the platform. Swedish Railways is the national railway operator in Sweden. The company has around 350 stations, carrying 70,000 passengers per day. The company employs approximately 3200 staff and has a turnover of approximately $1 billion.

SJ put the contract out to tender, receiving proposals from many of the large SOA/ESB vendors, including JBoss. After extensive trial period SJ selected JBoss middleware solutions for its integration platform, due to its satisfaction with the product, its use of open standards and the impressive performance when compared to the other solutions.

Working with Redpill, the JBoss-based Integration Platform was launched in January 2007. The first major project, in May 2007, was the creation of a ticket auction system to sell unsold tickets on Tradera.com, the Swedish auction website owned by Ebay Inc. Using the ESB, any tickets which have not been sold by SJ with 2 days of departure are automatically transferred to the Tradera system, where they are available for auction until 6 hours before departure. On the 4th of October 2007 SJ went live with JBossESB! SJ's CEO did a live demo at a press conference to announce the release. The news was reported by every major paper and news channels, so this is a great success for SR, Redpill and JBossESB.

As the first test of the new SJ Integration Platform, the Tradera.com integration project based on JBossESB was a resounding success, and completed within only 4 months. SJ is now able to sell thousands more tickets per week, which previously went unsold. The entire process is automated, with the details of the unsold tickets being passed directly to the Tradera system.

Now that the Integration Platform is up and running, SJ plans to deliver a new project every 2 months. The upcoming projects come from both internal and external demand, for projects which could either be consolidating existing systems or creating new products.

A couple of weeks ago Thomas Erl, one of the main authors on all things SOA, donated his Service Modeler invention to Red Hat. As Thomas says:

"Service modeling is an increasingly important area for SOA. By providing a simple, platform-agnostic tool that can be used by a range of IT professionals to conceptualize, define and manage inventories of services and service compositions, this technology has the potential to drive more widespread adoption and improve the end results of SOA initiative"

The modeler should play a very important role in the development and lifecycle of services; something which, until now, has been missing or developers have been forced to use inadequate or ad hoc techniques and tools. As Thomas mentions and others agree(ourselves included), Web Services do not infer SOA (apart from the fact that one is an implementation technique whilst the other is an architectural style). So although some of what the modeler provides is available in pure-play Web Services environments, that doesn't help those users who don't want to, or can't, use Web Services. Plus, even in a Web Services environment, we're confident the modeler provides good value add.

This is a good thing for Red Hat, but also for the open source community. The invention and any patents around it will be covered by the standard Red Hat Patent Promise. But it's gratifying that Thomas chose Red Hat as the home for the modeler. As he said:

"Red Hat is an ideal place for SOA-related open source innovation today. I have great confidence in Red Hat's ability to oversee the open source project being based around this service modeler and transform it into a mass-market solution."

At the moment there is no implementation of the modeler invention, but we'll be trying to rectify that soon. The aim is to fold this technology into the Red Hat SOA Platform and our ESB as soon as we can with the help of the community. Innovation continues to grow!

I was at the Accenture Technology Architecture Workshop last week in London, as an invited member of the panel on "Platform Strategy" along with IBM, Microsoft, BEA, Oracle, Sun and SAP. It was a packed audience of senior management and architects and for once I decided that T-shirt and jeans were not appropriate.

For the panel, we were asked to give a brief 5 minute presentation on where we thought THE platform was going. I think we all agreed that there was not such thing as a single platform (another example where one-size does not fit all). There were a few minor differences of opinion on the importance of interoperability and portability. Each of us was asked to say something on SOA and the message was that it's important. At times it felt a bit like a sales pitch from one vendor or another to the audience; "things are great if only you'd use our products and services". I obviously kept Red Hat's offerings in the running, but pointed out that SOA isn't just about software: it's as much about the way in which you think about your systems and architect them. I pointed out that tooling (from all vendors) is still seriously lacking in this regard: it still encourages a closely coupled, distributed object approach for building applications. Not good.

• "With the complexity of standards around SOA, and with your company being a primary participant in driving standards, how are you going to make the approach to SOA easier for customers to consume?" Better tooling and education of sales forces/consultants in order to better educate the customer, were pretty much the agreed answers.
• "How do you view in the market the coexistence of 2 trends, one being Open Source and the other the traditional platform development? How do you take advantage of one or the other? Where is the trend going? What are you doing on Open Source and how (if) do you see this evolving?" Well there were the usual cries of how open source is good for certain things, but closed source was just as viable. It was pretty clear from the audience that they trust open source a lot more these days than they did several years ago. The fact that each of the vendors, even Microsoft, now does some activity in open source, spoke volumes.

I got some good vibrations from the panel discussion for our platform strategy as a whole and specifically for the SOA Platform. After the meeting these feelings were confirmed when I spoke with quite a few people from the audience. Everyone seemed to get the whole platform=stability equation. Some even said that it raised the chances of them using Red Hat middleware more now than in the past. I did wonder if I'd get pulled for us not having JBossAS 5.0 GA out yet, but instead concentrating on JBossAS 4.2 and the Enterprise Platform. That question came up twice, but both times it was as a "thank you" related directly to the stability aspect. One person even likened it to XP/2000 versus Vista: "We know we need to get there eventually, but at the moment the 4.x series gives us 95% of what we need now. All we were missing was stability and a solid base on which to deploy for the next 5 years."

Over all it was a great conference to attend!

Then in the 1990's we started to look at interoperability through CORBA (portability was still mostly a nice-to-have until the end of the century). When Java and J2EE came on the scene portability took centre stage and interoperability (between heterogeneous implementations) dropped away, unless you wanted to embed a CORBA ORB in your application server. Now we're into the Web Services age and interoperability is king and portability is nothing to do with Web Services specifications or standards bodies: that's the domain of implementation and other organizations such as JCP. It can often be a strange and inefficient approach: at least with CORBA you (eventually) got interoperability between different implementations and languages along with portability in the same package. With Web Services, you get interoperability out-of-the-box as soon as you implement (assuming you conform to the specifications and understand what they say, or don't say); but portability may not come for months or years!

JBoss/Red Hat is heavily into portability and interoperability, as well as standards compliance. Over the past years we've been looking out for any opportunities to help out customers in these areas, including joining the Interoperability Vendor Alliance, participating in a range of Web Services events, and working on standards committees such as WS-BPEL, WS-TX, WS-Addressing and WS-Policy. Standards compliance is critically important for us and our customers: we want to avoid a return to the bad days of vendor lock-in. We take interoperability as a must when developing our products, rather than as a second thought, by which time it's often difficult to retro-fit for existing customers. Portability is a given because of our strong support for JEE.

In that light, we've recently been taking part in a number of important interoperability related events. The Burton Group are hosting the OASIS XACML interoperability workshop and we will be there to participate along with IBM, BEA, Oracle, CA, Securent, Jericho Systems and SymLabs. I'm sure this will be a good event and very successful. Then the W3C has been holding a workshop on transparent eGovernment. Our presentation on eGovernment Portals, is very relevant to our overall goal of interoperability and portability for our customers. Expect more from us around security, federation and transactions over the coming months, as well as interoperability across the board.

With that in mind it may explain why we've been discussing a successor to JBI with Sun for over a year, cunningly named JBI 2.0. As you can see, there are a lot of companies associated with the effort. The things we're going to look at include:

• Alignment with SCA.
• Performance optimisations (e.g., it doesn't always make sense to normalize your messages).
• Be clearer about where transactions, security etc. play in a JBI environment.
• Explicitly address distributed JBI.
• Leveraging OSGi where it makes sense.

As part of JavaOne 2007, Sun had a JBI 2.0 evening of BOFs, covering developer and user feedback on JBI 1.0 as well as a one targeted specifically at what users expect from JBI 2.0. That one was driven by Red Hat and was very well attended. The audience was very receptive to the initial discussion, which was meant to fuel the debate. Everyone seemed to agree that JBI 2.0 should become the standards-based deployment platform for ESB/SOA. There were few people interested in deploying to SCA, but it was "on the radar" as something they may need in conjunction with JBI. Plus, versioning of services is critical. This is interesting, because we've been saying the same thing since JBossESB started. It's good to see everyone else agreeing with us. The general conclusion from the entire JBI evening was that JBI 2.0 is needed and will be an important addition to the JEE platform. Both user and developer communities want to see more adoption. With any luck, 2008 will be the year of JBI (at long last!)

We're pleased to announce the general availability of JBossESB 4.0. As you can see, there have been some significant updates to this release since the first Beta Release late last year. Some of these updates haven't been to the feature set of the ESB, but to improving the out-of-the-box experience. which is very important too.

• We now have a lot of quick start examples, each one aimed at illustrating a particular way of using or developing on the ESB.
• There are some on-line tutorials, covering various aspects of the transformation engine and associated console.
• Amongst (S)FTP, email, SQL, file and other transports, we support JMS in various flavours, including JBossMQ and MQSeries. We'll be adding support for JBoss Messaging as soon as that is released later this month.
• The documentation suite has been updated based on feedback from the community.

We've in increased the size of the development community over the past few months and we're hoping that the user community will follow. This has been a community effort, but it's only the first steps towards our final goal. Don't forget, if you have any questions on using JBossESB then post them to the User Forum. Likewise, we're always happy to receive design questions or suggestions from the community. If you want to join our developer list, then email me.

We're currently taking part in the OASIS WS-TX interoperability event around the WS-BusinessActivity specification. This is the last part of the WS-TX specification to be tested for interoperability and we can finally see the light at the end of the tunnel. It's been a long road to get here, including OASIS BTP and OASIS WS-CAF and almost 7 years of effort.

JBoss Transactions has been involved with all of the specifications/standards over the years and used to demonstrate interoperability of them all. If you want to see how we're doing compared to the likes of IBM and Microsoft then check out the interoperability status page. Unfortunately as last time the names have been anonymised to protect the innocent. However, once again thanks to Kevin Conner our implementation is doing extremely well.

Once completed, the 1.1 version of the specifications will become a standard that will eventually be supported by all of the major Web Services vendors. At the moment and like the other participants, JBossTS supports the 1.0 specification. Expect 1.1 support from us in 2007, but note that we'll have to support both 1.0 and 1.1 for sometime to come.

JBoss has just spent the past few weeks working closely with IBM, Microsoft and other members of the OASIS WS-TX technical committee to validate the interoperability goals of the WS-AtomicTransaction specification. I'm pleased to say that, as with the first interoperability workshop, the committee has achieved its goals and demonstrated interoperability between a number of heterogeneous implementations. Next steps will be to make the specification a standard and to move on the interoperability of WS-BusinessActivity.

As far as JBoss is concerned, we used the JBossTransactions product as the basis of our interoperability effort. Because the technical committee is working on the next version of the WS-TX standards, this is not the same version of JBossTS we're shipping that currently has Web Services transactions support, simply because that release is only compliant with the previous specifications. Expect to see a release of JBossTS that supports both versions of the specifications in 2007, once the technical committee has finished its work. We'll also try to find a way to make sure our endpoint remains available in case anyone wants to use it.

If you want to see how we (and others) got on with interoperability, you can check the interoperability matrix. Unfortunately the table treats the participants anonymously and randomly: P1 now may be a different participant to P1 in a minutes time.