I don't know if the project you mention is still active. Certainly Ricardo has moved on to Web Services transactions, and OASIS WS-CAF in particular. I was one of the main authors on the OMG's Additional Structuring Mechanisms for the OTS (aka Activity Service) and on the JEE equivalent (JSR 95) and developed the first Java implementation of both. Although the concepts are good (check out http://www.amazon.com/gp/product/013035290X/qid=1136975705/sr=8-1/ref=pd_bbs_1/103-3295277-9563863?n=507846&s=books&v=glance for an indepth description) and we got it through the JCP process, it's not a mandatory part of JEE and I'm not sure it ever will be. As a result, it's had limited take up within the JEE community - there was much more interest within the OMG, but that faded about a 18 months ago too.

Most of the transaction community moved on to Web Services, or providing "transactions everywhere" technologies, such as ArjunaCore or the equivalent within Indigo.

So will JBoss support JSR 95? I don't know. Certainly there's the expertise, as I indicated above, and there may be implementations already, but it really depends upon customer/community requirements. At the moment, I don't see it (which from a personal perspective is a shame).

JSR 95 can certainly be used as the basis for workflow technologies. That as one of the key design choices we made back in the OMG. Although there are good reasons to choose something like it for doing workflow, if you've already got a workflow implementation, then it is often difficult to justify the refactoring/rearchitecting involved. The only projects I know that did that were Hewlett-Packard (back when I was a DE, I consulted with the workflow tteam architect on that exercise) and IBM.

Mark.

Although JBoss doesn't currently have an implementation of JSR 95, if you want to send me any questions, feel free.

As for ATS integration: yes, we're working on adding the entire ATS source code tree to subversion at the moment.

Mark.

Hi all,

I´m one of the persons involved in the JASS project. The JASS project is alive.

Related to the JSR-95, I updated the CVS repository of the project (accessible through http://jass.objectweb.org) to include the new version (0.2) of the J2EE Activity Service implementation. JASS Activity Service and the Open Nested Transactions (ONT) High Level Service reside now in two different projects in the CVS repository (j2ee-activityservice and j2ee-ont). Some bugs on the Activity Service engine have been fixed and the ONT Service has been rewriten from the scratch. The ONT project includes an example (a travel agency) that shows the functionality of the ONT model on top of the Activity Service. Both implementations run on the JBoss application server (versions 3.x and 4.x).

If you have any question about the implementation you can use the project mailing list (jass@objectweb.org).

The mailing list can be accessed from the JASS project website: http://jass.objectweb.org

A packaged distribution for version JASS Activity Service 0.2 will be available soon on the website.

Thanks for your interest,

Francisco Pérez-Sorrosal

As one of the authors of both the original OMG and JEE specifications, I'm glad the project is still going. I think we did a great job on supporting extended transaction models, but for CORBA (and possibly even JEE) it was probably too late.

All the best,

Mark.

Hello Mark,

Do you know what is/are the reason/s because the JSR95 it's not a mandatory part of JEE and why (it is probable) it will never be? Why the JCP JSR-95 site does not inform about it (It seems frozen since 2004-03-25 for the reader)?

In the end, who decides (or who has decided) to approve or not the final draft in the JCP process?

Thanks in advance,

Francisco Pérez-Sorrosal

Although we got the JSR through the final approval vote, I just don't think there's been enough interest to justify it going into the mandatory part of the architecture. Even as one of the authors, I wouldn't argue for that. Within the OMG, the Additional Structuring specification wasn't a core service (by definition, services which you should support).

Mark.

There's no direct relationship. JSR 156 is meant to define a set of APIs for different loosely-coupled/Web Services transactions protocols, such as those defined in WS-TX or WS-CAF. You could certainly layer a JSR 95 implementation underneath (we did something similar a few years back whilst in HP, with a BTP implementation on JSR 95).

Mark.