Sun, Oracle, IONA, Fujitsu, & Arjuna today announed the release of Web Services Composite Applications Framework (WS-CAF), a collection of three key specs that define how web services can share transaction context, coordinate and manage transactions. The vendors plan to contribute the specs royalty-free to an industry standards group.

Read:
Industry Leaders Drive Convergence, Publish Web Services Specifications to Coordinate Business Applications (press release)
Sun, Oracle, others propose transaction specification.


   The Web Services Composite Application Framework (WS-CAF) is comprised of three specifications:
 
-- Web Service Context (WS-CTX), a lightweight framework for simple context management that helps enable all Web services participating in an activity share a common context and exchange information about a common outcome.
-- Web Service Coordination Framework (WS-CF), a sharable mechanism that manages context augmentation and lifecycle and provides the notification of outcome messages to Web services participating in a particular transaction.
-- Web Services Transaction Management (WS-TXM), is comprised of three distinct, interoperable transaction protocols that can be used across multiple transaction managers. WS-TXM supports multiple transaction models to help enable participants to negotiate outcomes with each other and make a common decision about how to behave, especially in the case of failure, regardless whether the execution environment is CORBA, Enterprise JavaBeans(TM) (EJB(TM)), .NET, Java(TM) Message Service (JMS), or some combination.

The Web Services - Composite Applications Framework specifications (WS-CAF) can be found here:

Arjuna Technologies Ltd. - http://www.arjuna.com/standards/ws-caf
Fujitsu Software - http://www.fsw.fujitsu.com/standards/ws-caf
IONA Technologies PLC - http://www.iona.com/devcenter/standards/WS-CAF/
Oracle Corporation -http://otn.oracle.com/tech/webservices/htdocs/spec/ws-caf.html
Sun Microsystems - http://developers.sun.com/techtopics/webservices/wscaf/index.html

That's funny.... Long ago it was SOAP... Simple Object Access Protocol... now it's becoming a new CORBA stack, just more inefficient and complex (if possible :-) ....

I'm afraid the 'S' in 'SOAP' was never meant to refer to the 'P(rotocol)', but to 'O(bject)'. Meaning that the protocol is only suitable for the most simple objects...

>I'm afraid the 'S' in 'SOAP' was never meant to refer to the 'P(rotocol)', but to >'O(bject)'. Meaning that the protocol is only suitable for the most simple >objects...

Oh! Now I see.... A complex protocol for accessing simple objects. Interesting.
I suppose MIcrosoft couldn't do any better! :-)

Stefano

As the old saying goes - it will get worse before it will get better. We just need to keep our eyes on the ball. The WS stack is continuing to develop now that people realize that the true benefits of Web services are going to be realized by applying them to real business problems.

Unlike the early phases of WS development, where the focus was on RPC-style Web services (resulting in maturation of SOAP/WSDL as the Web service publishing part of the stack), now the focus is shifting to Document-style asynchronous Web services and the need to coordinate their long-running/multi-step interactions.

The Web services stack is evolving to address the challenges of orchestration, a far more challenging problem than providing access to services through SOAP/WSDL. The new standards under development are centered around BPEL (now at OASIS) and include asynchronous callback support (WS-Addressing), guaranteed delivery (WS-ReliableMessaging or WS-Reliability) and distributed loosely-coupled, aka compensating transactions (WS-Coordination/WS-Transaction or WS-CAF).

The critical mass of vendor support now garnered behind BPEL, will be instrumental in the rapid consolidation of the supportive standards (see above) lower than BPEL in the Web services stack, all of which are essential for Web service orchestration. There are indeed quite a few trees in this forrest, but if you step and watch from far enough, you can actually see the forrest coming together.

Doron\
Collaxa, Inc.

Yet another load of "standards" in the Web Service space, competing with the other load of "standards" defined by the likes of IBM, MS etc.

WS-Transaction or WS-TXM or BTP? BPML or BPEL4WS? WS-CF? WTF?!??

How the hell are end users supposed to decide which part of this alphabet soup to target without being hung out to dry when Sun/BEA/Oracle/whoever finds a new best friend to play with?

Well spoken, i'm sick of all those "standards" ...

Just my 2c,
Stefan

Neil: WS-Transaction or WS-TXM or BTP? BPML or BPEL4WS? WS-CF? WTF?!??

Yes, we use WTF. It is the most straight-forward and human-readable of them all. Debugging is fairly easy, if occasionally painful. Nobody asks to see the spec twice. Not a bad deal.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster!

I think the WS-TXN will be the one to watch. Transactions propagating across an internet model have been a concern to all. I recall hearing Don Box say once, "Would I want to lock my database based on the result of a call going out on the internet?". Working on e-speak at HP several years ago we had proposed defining internet transaction support only for point-in-time failure rather than 2-phase commit.

\John Harby\
I think the WS-TXN will be the one to watch. Transactions propagating across an internet model have been a concern to all. I recall hearing Don Box say once, "Would I want to lock my database based on the result of a call going out on the internet?". Working on e-speak at HP several years ago we had proposed defining internet transaction support only for point-in-time failure rather than 2-phase commit.
\John Harby\

Any transaction model propogated over the Internet that could bubble down to something like an RDBMS is the quintessential Bad Idea in my opinion. Any sort of in-doubt transaction is bad news and you try your best to minimize the windows when they happen in general. In an Internet system where you can't even reliably tell if someone's still connect to you? <shiver>. An in-doubt hanging for 10 seconds is a nightmare for existing app-server based applications. I can't imagine trying to use something where transaction timeouts would almost have to be defined in terms of minutes....

     -Mike

Agreed. Both WS-CAF and WS-Tx from IBM/MSFT have an Atomic Transaction protocol, but that's really for interoperability across existing TP systems (something that hasn't really be accomplished before). The extended transaction models (LRA, BP in WS-CAF, and BA in WS-Tx) are meant for the long duration interactions where locking of resources (databases etc.) isn't appropriate.

Mark.

I think that WS-CTX (the context service) is also worth watching. Nearly ever service/specification has a notion of context by they're all doing it in a slightly different manner. Hopefully this is a way of unifying those approaches.

Mark.

Is WS-CAF complementary to WS-Transaction?

Do these specifications overlap?

http://www-106.ibm.com/developerworks/library/ws-transpec/

I'm not sure if the press release is clear enough, but the intention was the CAF wouldn't be a competitor for WS-Tx but rather be able to work with it. You should be able to plug WS-Tx into CAF if you want to.

Mark.

This gives sales guys from IBM/BEA/Oracle etc to fool our not-so-techy managers/VPs and sell the same thinsg under different name ...

I thought W3C web services was the best thing to have ever happened to the development community. But this is just toooooo much to remember - They should keep things simple ...atleast on terminology level ..

Does anybody have a good summary of the transaction, security, lookup, event, and other management specs related to web services? I would also want to figure out which specs are supported across the board (Anything besides SOAP?) and which are backed by different groups? Transactions and Security both seem to be in different camps right now..

Sigh,

more and more specifications, I thought Web services where meant to be simple?

I guess at the end of the day the inability for all the vendors to agree will result Web services being another DCOM/Corba scenario.

Hail to the Vendors who have ripped off IT customers yet again, always talking about "Open systems" or "Open protocols" but the reality is that Vendor Lock in is the name of the game now as much as it was thirty years ago...

JSR 95
J2EE Activity Service for Extended Transactions

"The Activity Service supports flexible ways of composing an application using transactions, and can enable the application to possess some or all ACID properties."

URL: http://www.jcp.org/en/jsr/detail?id=95
URL: http://jcp.org/aboutJava/communityprocess/review/jsr095/index.html

JSR 156

"JAXTX provides an API for packaging and transporting ACID transactions (as in JTA) and extended transactions (e.g., the BTP from OASIS) using the protocols being defined by OASIS, W3C."

URL: http://www.jcp.org/en/jsr/detail?id=156

At the moment JSR 95 isn't appropriate for Web services. The technical committee concentrated on taking the original OMG work (Additional Structuring Mechanisms for the OTS [http://www.omg.org/cgi-bin/apps/do_doc?formal/02-09-03.pdf]) which fairly obviously was based on closely-coupled (IIOP-based) environments and transposing it into J2EE. So, currently all interactions are based on IIOP.

JAXTX (JSR 156) is going to support BTP, JTA, WS-T and now WS-CAF/TXM.

Mark.

Basically, web services were invented at HP Labs. This is a good paper coming from that group, you might also want to search their site for others.

http://www.hpl.hp.com/personal/Akhil_Sahai/papers/recent/wecwis.pdf

Basically, web services were invented at HP Labs.

Yes, the Chai project.

More precisely, e-speak.

There are so many specifications evolving. Developers are going mad by seeing those specifications. These specs makes the developers life very difficult and very confusing.

Agreed, which is why all of the representatives of the various specs. need to get together and thrash things out to produce a single standard. Hopefully that will happen, but I wouldn't like to put bets on when: vendor lock-in is a very powerful driving force for some companies, unfortunately.

Mark.

If anyone's interested in discussing the technical merits of these specifications, check out http://www.arjuna.com/forum/list.php?f=3

Mark.

Web Services Atomic Transaction (WS-AtomicTransaction)

*http://www-106.ibm.com/developerworks/library/ws-atomtran/*

*ftp://www6.software.ibm.com/software/developer/library/ws-atomictransaction.pdf*

A comparison of Web services transaction protocols

http://www-106.ibm.com/developerworks/webservices/library/ws-comproto/