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
-
Web Services transaction problems addressed in new specs (26 messages)
- Posted by: Floyd Marinescu
- Posted on: July 28 2003 15:40 EDT
Threaded Messages (26)
- Web Services transaction problems addressed in new specs by Stefano Fornari on July 28 2003 16:01 EDT
- Re: Web Services transaction problems addressed in new specs by Eric Jain on July 28 2003 16:41 EDT
- Re: Web Services transaction problems addressed in new specs by Stefano Fornari on July 29 2003 02:00 EDT
- Keep the eye on the (Web services stack) ball by Doron Sherman on July 28 2003 22:01 EDT
- Re: Web Services transaction problems addressed in new specs by Eric Jain on July 28 2003 16:41 EDT
- Fan-bleedin-tastic... by Neil Bartlett on July 28 2003 16:25 EDT
- Fan-bleedin-tastic... by Stefan Zobel on July 28 2003 16:58 EDT
- Fan-bleedin-tastic... by Cameron Purdy on July 28 2003 22:24 EDT
- Web Services transaction problems addressed in new specs by John Harby on July 28 2003 17:05 EDT
- Web Services transaction problems addressed in new specs by Mike Spille on July 29 2003 00:23 EDT
- Web Services transaction problems addressed in new specs by Mark Little on July 29 2003 07:46 EDT
- Web Services transaction problems addressed in new specs by Mark Little on July 29 2003 07:40 EDT
- Web Services transaction problems addressed in new specs by Mike Spille on July 29 2003 00:23 EDT
- WS-CAF, WS-Transaction by Sean Sullivan on July 28 2003 17:22 EDT
- WS-CAF, WS-Transaction by Mark Little on July 29 2003 07:19 EDT
- Confusion is the key to success by sean decor on July 28 2003 17:46 EDT
- Web Services transaction problems addressed in new specs by Paul Danckaert on July 28 2003 17:56 EDT
- Web Services transaction problems addressed in new specs by anon anon on July 29 2003 05:00 EDT
- JSR 95, JSR 156 by Sean Sullivan on July 29 2003 13:58 EDT
- JSR 95, JSR 156 by Mark Little on July 31 2003 07:17 EDT
-
JSR 95, JSR 156 by John Harby on August 09 2003 11:27 EDT
-
JSR 95, JSR 156 by Brian Miller on August 11 2003 10:38 EDT
- JSR 95, JSR 156 by John Harby on August 17 2003 12:05 EDT
-
JSR 95, JSR 156 by Brian Miller on August 11 2003 10:38 EDT
-
JSR 95, JSR 156 by John Harby on August 09 2003 11:27 EDT
- JSR 95, JSR 156 by Mark Little on July 31 2003 07:17 EDT
- What the hell the specifications are for ? by Somashekhar Shetty on July 30 2003 08:12 EDT
- What the hell the specifications are for ? by Mark Little on July 31 2003 07:18 EDT
- WS-CAF discussion forum by Mark Little on August 04 2003 06:39 EDT
- Web Services Atomic Transaction (WS-AtomicTransaction) by Sean Sullivan on September 24 2003 12:30 EDT
- article @ ibm.com by Sean Sullivan on October 07 2003 20:55 EDT
-
Web Services transaction problems addressed in new specs[ Go to top ]
- Posted by: Stefano Fornari
- Posted on: July 28 2003 16:01 EDT
- in response to Floyd Marinescu
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 :-) .... -
Re: Web Services transaction problems addressed in new specs[ Go to top ]
- Posted by: Eric Jain
- Posted on: July 28 2003 16:41 EDT
- in response to Stefano Fornari
Long ago it was SOAP... Simple Object Access Protocol
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... -
Re: Web Services transaction problems addressed in new specs[ Go to top ]
- Posted by: Stefano Fornari
- Posted on: July 29 2003 02:00 EDT
- in response to Eric Jain
Long ago it was SOAP... Simple Object Access Protocol
>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 -
Keep the eye on the (Web services stack) ball[ Go to top ]
- Posted by: Doron Sherman
- Posted on: July 28 2003 22:01 EDT
- in response to Stefano Fornari
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. -
Fan-bleedin-tastic...[ Go to top ]
- Posted by: Neil Bartlett
- Posted on: July 28 2003 16:25 EDT
- in response to Floyd Marinescu
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? -
Fan-bleedin-tastic...[ Go to top ]
- Posted by: Stefan Zobel
- Posted on: July 28 2003 16:58 EDT
- in response to Neil Bartlett
Well spoken, i'm sick of all those "standards" ...
Just my 2c,
Stefan -
Fan-bleedin-tastic...[ Go to top ]
- Posted by: Cameron Purdy
- Posted on: July 28 2003 22:24 EDT
- in response to Neil Bartlett
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! -
Web Services transaction problems addressed in new specs[ Go to top ]
- Posted by: John Harby
- Posted on: July 28 2003 17:05 EDT
- in response to Floyd Marinescu
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. -
Web Services transaction problems addressed in new specs[ Go to top ]
- Posted by: Mike Spille
- Posted on: July 29 2003 00:23 EDT
- in response to John Harby
\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 -
Web Services transaction problems addressed in new specs[ Go to top ]
- Posted by: Mark Little
- Posted on: July 29 2003 07:46 EDT
- in response to Mike Spille
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. -
Web Services transaction problems addressed in new specs[ Go to top ]
- Posted by: Mark Little
- Posted on: July 29 2003 07:40 EDT
- in response to John Harby
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. -
WS-CAF, WS-Transaction[ Go to top ]
- Posted by: Sean Sullivan
- Posted on: July 28 2003 17:22 EDT
- in response to Floyd Marinescu
Is WS-CAF complementary to WS-Transaction?
Do these specifications overlap?
http://www-106.ibm.com/developerworks/library/ws-transpec/ -
WS-CAF, WS-Transaction[ Go to top ]
- Posted by: Mark Little
- Posted on: July 29 2003 07:19 EDT
- in response to Sean Sullivan
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. -
Confusion is the key to success[ Go to top ]
- Posted by: sean decor
- Posted on: July 28 2003 17:46 EDT
- in response to Floyd Marinescu
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 .. -
Web Services transaction problems addressed in new specs[ Go to top ]
- Posted by: Paul Danckaert
- Posted on: July 28 2003 17:56 EDT
- in response to Floyd Marinescu
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.. -
Web Services transaction problems addressed in new specs[ Go to top ]
- Posted by: anon anon
- Posted on: July 29 2003 05:00 EDT
- in response to Floyd Marinescu
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, JSR 156[ Go to top ]
- Posted by: Sean Sullivan
- Posted on: July 29 2003 13:58 EDT
- in response to Floyd Marinescu
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 -
JSR 95, JSR 156[ Go to top ]
- Posted by: Mark Little
- Posted on: July 31 2003 07:17 EDT
- in response to Sean Sullivan
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. -
JSR 95, JSR 156[ Go to top ]
- Posted by: John Harby
- Posted on: August 09 2003 11:27 EDT
- in response to Mark Little
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 -
JSR 95, JSR 156[ Go to top ]
- Posted by: Brian Miller
- Posted on: August 11 2003 10:38 EDT
- in response to John Harby
Basically, web services were invented at HP Labs.
Yes, the Chai project. -
JSR 95, JSR 156[ Go to top ]
- Posted by: John Harby
- Posted on: August 17 2003 00:05 EDT
- in response to Brian Miller
More precisely, e-speak. -
What the hell the specifications are for ?[ Go to top ]
- Posted by: Somashekhar Shetty
- Posted on: July 30 2003 08:12 EDT
- in response to Floyd Marinescu
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. -
What the hell the specifications are for ?[ Go to top ]
- Posted by: Mark Little
- Posted on: July 31 2003 07:18 EDT
- in response to Somashekhar Shetty
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. -
WS-CAF discussion forum[ Go to top ]
- Posted by: Mark Little
- Posted on: August 04 2003 06:39 EDT
- in response to Floyd Marinescu
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)[ Go to top ]
- Posted by: Sean Sullivan
- Posted on: September 24 2003 12:30 EDT
- in response to Floyd Marinescu
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* -
article @ ibm.com[ Go to top ]
- Posted by: Sean Sullivan
- Posted on: October 07 2003 20:55 EDT
- in response to Floyd Marinescu
A comparison of Web services transaction protocols
http://www-106.ibm.com/developerworks/webservices/library/ws-comproto/