-
1. Re: official Java WS-T standard/reference implementation?
The WS-AT and WS-BA specs are not JSRs, don't specify language level APIs and don't require a reference implementation. We do participate in the interop work for these standards, so we have a fair picture of who else has implementations and how compliant, or at least how interoperable, they are, but that's as far as it goes.
There is no JSR for inclusion of WS-AT or WS-BA into JEE, but there is JSR-156 to provide a standardized Java language API to those and similar extended tx protocols. As and when I get around to it the JBoss impl will probably become the reference impl for -156. There is no plan to include it into JEE at this time. -
2. Re: official Java WS-T standard/reference implementation?
JBoss seams way ahead of other JEE providers re: full WS-T capability
Xftlocksmiths, JBoss is very much a leader in the Java EE transactions space. JBoss gave the following presentation at JavaOne 2008 ... you may find it helpful re: WS-AT, WS-BA, JSR-156, etc.
http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-6268.pdf
. -
3. Re: official Java WS-T standard/reference implementation?
Thank you for this responses. There seams to be bad gap with JEE transactions. We think the ability to design _generic_ WS-AT and WS-BA transaction deployed to JEE is impossible. For example if we design a generic Corba IDL transaction deployed by OMG standard OTS server it will work on Orbix Visibroker the same. If we design a generic JTA transaction to be deployed by JEE standard JTS server it will work on JBoss Webspher Weblogic the same. But this is not true when web services are attempted in the same because JEE does not include WS-AT and WS-BA as standard. We looked at JSR-156 but there is nothing detailed. Maybe we are missing facts. Do JBoss agree that there is no solution now to overcome the gap with JEE to design _generic_ web service transaction with WS-AT and WS-BA?
-
4. Re: official Java WS-T standard/reference implementation?
... We looked at JSR-156 but there is nothing detailed. Maybe we are missing facts. ...
JSR-156 is not yet published GA, so its many DRAFT details are not yet available outside of the JCP.
Do JBoss agree that there is no solution now to overcome the gap with JEE to design _generic_ web service transaction with WS-AT and WS-BA?
As was pointed out in jhalliday's response to your initial post, WS-AT and WS-BA are not part of JEE. So your expectation to design/deploy WS-AT/WS-BA transaction services generically to a JEE compliant server is, at this time, a bit unrealistic.
But this is not true when web services are attempted in the same because JEE does not include WS-AT and WS-BA as standard.
Agreed. This is the exact answer to your question.
Details aside, I agree with the general concern of your "There seams to be a bad gap" assertion. The intended purpose of JSR-156 is to exactly address this concern, providing a Java standard API to WS-AT/WS-BA. Once standard, all of JBoss, Websphere, WebLogic, etc. would then supply JSR-156 compliant implementations. -
5. Re: official Java WS-T standard/reference implementation?
It is our expectation and we think it is _reasonable_ expectation. It is bad gap for JEE if it is true that our expectation is ", at this time, a bit unrealistic". If JSR-156 is published and allof JBoss,Websphere,Weblogic provide implementation that is standard and gives generic SPI to WS-AT and WS-BA transaction designers then maybe that is the ideal solution but it is not published and is not standard. It seams from www.jcp.org that "JSR-156 is not yet published GA" is true since 2005. why?
-
6. Re: official Java WS-T standard/reference implementation?
> why?
Mostly because we have limited manpower and users are screaming more loudly for other things, like transaction bridging, interop and the BA framework.
Also to some degree because we are not big fans of early specification. Until the real world issues with building transactional web apps are well understood, it won't be clear what the API for it should look like and we run the risk of producing a standard API that does not get widely adopted because it does not do the job right.
Sure there is some degree of catch-22 here, in that more conservative users won't adopt tx web apps until there is a standard API, but I think there is a large enough community of early adopters who see the benefits of the technology and can handle a bit of temporary vendor lock-in. Hibernate was widely used and its API refined for years before the JPA spec came along, never mind made it into JEE.
If you are keen to see a standard API for web service transactions the best thing you can do is start using the one we have already and give us feedback on it based on your real world experiences, so that we can improve and refine it into something other vendors are keen to adopt. -
7. Re: official Java WS-T standard/reference implementation?
We will do _exactly_ this. Thanks everybody for this responses. It helps us much.