Sun Microsystems have released Milestone 4 of WSIT. One of the new features in there is support for WS-AtomicTransaction and WS-Coordination. According to the announcement they've also shown interoperability with .NET 3.0. As Ryan Shoemaker says:
It's interesting that with the exception of WS-CAF and it's associated WS-TransactionManagement, Sun were not very active in the OASIS WS-TX technical committee. That group held several interoperability events over the years, based on complex interoperability scenarios developed within the group. IBM, IONA Technologies, JBoss/Red Hat and Microsoft participated, but Sun was notable by their absence (as was BEA, one of the original specification authors). Oracle are the other traditional transaction vendor who has remained silent (since WS-CAF).
It will be interesting to see if Sun moves to support WS-BusinessActivity, or remains with WS-AtomicTransaction. It's true that if you have JTA then doing WS-AtomicTransaction should be straightforward, but WS-BusinessActivity addresses a whole different range of use cases that are quite important in long running, loosely coupled interactions.
Supporting these standards in our web services stack allows you to write fault tolerant applications that bridge across heterogeneous systems. Java EE developers can easily write applications that take advantage of distributed transactions that span multiple Java EE application servers (without needing WSIT). What WSIT adds is the ability to include transacted web service methods (think "container managed transactions for servlets") and also bridge across heterogeneous systems (think "Microsoft"). In a homogeneous GlassFish system, distributed transactions flow across RMI/IIOP. In a heterogenous web service environment, the transactions use the WS-Coordination and WS-AtomicTransaction protocols to flow transactional context and execute the two-phase commit protocol.There's a screencast available too that shows the system in action.
It's interesting that with the exception of WS-CAF and it's associated WS-TransactionManagement, Sun were not very active in the OASIS WS-TX technical committee. That group held several interoperability events over the years, based on complex interoperability scenarios developed within the group. IBM, IONA Technologies, JBoss/Red Hat and Microsoft participated, but Sun was notable by their absence (as was BEA, one of the original specification authors). Oracle are the other traditional transaction vendor who has remained silent (since WS-CAF).
It will be interesting to see if Sun moves to support WS-BusinessActivity, or remains with WS-AtomicTransaction. It's true that if you have JTA then doing WS-AtomicTransaction should be straightforward, but WS-BusinessActivity addresses a whole different range of use cases that are quite important in long running, loosely coupled interactions.
/filters:no_upscale()/sponsorship/topic/25afca57-6bcb-4c42-9a70-fbea10ce4fc7/MicrosoftLogoRSB-1678874949003.png)
/articles/azure-functions-quarkus/en/smallimage/azure-functions-on-quarkus-3-1685542580748.jpg)
/minibooks/architecture-2023/en/smallimage/logo-1685600892155.jpg){kind=logo}
/presentations/lyft-cd-benefits-challenges/en/smallimage/tom-wanielista-small-1685002834068.jpg)
/presentations/green-software-growth/en/smallimage/Marco-Valtas-small-1685609473905.jpg)
/articles/test-automation-ci-cd/en/smallimage/effective-test-automation-approaches-for-modern-CI-CD-pipelines-small-1685355310638.jpg)
/articles/impact-machine-learning-climate/en/smallimage/minimising-the-impact-of-machine-learning-on-our-climate-small-1685091723283.jpg)
/articles/kafka-clusters-cloudflare/en/smallimage/tales-of-Kafka-at-Cloudflare-small-1684768928637.jpg)
/presentations/refactoring-cleaning-code/en/smallimage/kent-beck-small-1684908700538.jpg)
/presentations/devsusops/en/smallimage/adrian-cockcroft-small-1684908390875.jpg)
/articles/gdpr-with-spring-and-aop/en/smallimage/easy-implementation-of-GDPR-with-aspect-oriented-programming-small-1684505109873.jpg)
/articles/software-delivery-performance-indicators/en/smallimage/software-delivery-performance-indicators-at-different-granularities-small-1684312207072.jpg)
Community comments
Further details
by Alastair Green,
Further details
by Alastair Green,
Your message is awaiting moderation. Thank you for participating in the discussion.
1. I think Sun didn't take part in the WS-TX interops because they hadn't got their code base ready in time.
2. Interop of protocols (in the manner of the TC interop tests) is a very different matter from producing genuine interoperable distributed transaction environments. For example: the J2EE JTA interface doesn't allow importation of external transactions, and the JTS interface (which does, and is implemented by WAS or JBoss/Arjuna) is CORBA-dependent. The issues of transaction propagation, sub-coordination, and application participant writing are the real problems yet to be solved for WS transactions. Some are standard interface issues for language environments. But application participant writing is an area where industry practice is in its infancy.
Beware protocol testers masquerading as usable distributed transactional environments.
3. Choreology also participated in the WS-AT WS-TX interops, but not in the WS-BA tests.
4. WS-CAF (Context etc) is/was a quite separate initiative from WS-TX.
5. I'd have said that Sun was virtually invisible in the transactional chapter of WS-CAF (which died a death when IONA and Arjuna-then-JBoss went over to WS-TX). Sun put more oomph into WS-TX, in the context of their WS interoperation work with Microsoft, one of whose fruits we are now seeing in this announcement.