A very good summary of the state of the asynchronous web services applications.
I think that a standard reliable transport may be covered by the ebxml-msg and JAXM specifications. It appears that some of the JAXM implementations use JMS internally for queuing and reliable semantics. http://www.oasis-open.org/committees/ebxml-msg/ http://java.sun.com/xml/jaxm/ But open implementations are practically non-existant, there are some "toy" implementations but nothing that I would use in the enterprise apart from maybe GLUE, but I haven't used that in anger yet. I do agree that more energy needs to be put into this disorganised area, as we seem to be far from anything for B2B enterprise level applications. Simon... Jacques TALBOT wrote: >So we all agree we need asynchronous, reliable, standard web services. >Reliability is because applications, being pretty dumb, cannot cope, >like human beings with http rather erratic semantics. >Asynchronous because we know from EAI times that it is better. >Standard because this is what Web Services are all about. > >So is SOAP on JMS the solution? >Partly yes because it is indeed asynchronous and >with guaranteed once&onlyonce semantics >Partly no because of 2 problems, one small (semantics mismatch) >and one big (standard protocol) > >The small problem: >the semantics problem is related to the fact that JMS embeds a model >with queues (one to one messaging) and topics (publish and subscribe) >This does not map so obviouly on SOAP+WSDL >IMHO, it is very difficult to imagine that the programmer ignore he/she >is using a queue or a topic, or defer that decision to deployment time >as some seem to hope. >As a consequence, there will be many ways to do the semantic mapping >and they will not interoperate. > >The big problem >JMS is only an API, not a protocol, and protocol implementations are >proprietary >So it is limited to the intranet. This is rather contradictory with the Web >model >where the same protocols are used inside and outside the firewall, >with the nice lowering of costs attached to this standardisation. > >Looking now at Sonic's contribution: >http://www.oetrends.com/cgi-bin/page_display.cgi?109 >what exactly is Sonic/Apache proposing to solve this dilemna? >and BTW what is delivered in Axis 1.0? is it only a client >"SOAP/WSDL to JMS" binding or also the JMS MOM engine? If no engine, >do you have to buy one, considering that open source JMS engines are not >so popular, even if they exist (JORAM, SwiftMQ, activeJMS...)? >Furthermore, it is pretty easy to design a quick and dirty JMS provider >with none of the reliability of MQseries (or Sonic BTW :-) > >Now if we count SOAP on JMS out for B2B, what is proposed? >Holt Adams from IBM proposes 4 patterns in: >http://www-106.ibm.com/developerworks/webservices/library/ws-asynch1.html?dw >zone=webservices >Patterns 3 and 4 which can run on http are sort of toys IMHO >I am not criticizing the proposal, but I do believe that any web service >going beyond "get a quote" needs some semantic guarantees from the transport >because it is VERY different to deal with a transport loosing one message >out of 1000 and another one loosing one message out of 1 million; >Pattern 3 is polling: back to 1960 ;-) can you imagine your mobile phone >polling the network? >Pattern 4 is "build your own MOM at the application level" >which is TOO DIFFICULT for the "average programmer". >So we are back to Patterns 1 and 2 which, unfortunately, have only >one possible transport outside the firewall, httpr >(unless of course you do no want reliability, back to toy applications) >But httpr is only an IBM proposal, nothing like a standard for the time >being >Running into circles! > >Looks like we have no solution ... > >Now, some techno politic fiction .. what I believe is really happening >behind the curtains: >All the IBM and Microsoft technical luminaries have understood all of the >above >since at least one year. So they probably meet monthly in >a nice wooden hotel in a Colorado ski resort to try to come up with a >solution for the world. >IBM is pushing a solution at transport level, httpr. >Microsoft is pushing a WS-RM (reliable messaging) at the SOAP level. >The problem is: how come the white smoke is not out already, is it so >difficult >to find a technical solution, are there more political issues that I cannot >even imagine? >Why is it that they managed to converge on WS-T and WS-C, which, IMHO, is >something >which is not really needed for the next 2 years, and that the more useful >and better >understood WS-RM convergence is not happening? > >There is no irony above, I do believe this duopolistic process is quite >acceptable >to move things forward, considering that W3C is going forward at a pretty >low speed. > >Your opinion is welcome on the fictional aspect of the above ... > >Disclaimer: It is entirely possible that, from my remote french location, I >cannot really >see behind the curtains and as a consequence, my fairy tale can be entirely >wrong, >or I may have missed some key aspect ... > >The bottom line is that as a consultant, I would like to be able to tell >my customers to use WS for serious business, but I honestly cannot. >If we collectively do not solve the WS-RM issue in the next 12 months, WS >will go down the Gartner hype curve at a very dangerous speed and our >customers >will label it as yet another techno fad. > >If you are still reading at this point, I can only thank you for yor >patience :-) >and hope for the best > > >-- >Jacques Talbot - Architecture Consultant - Teamlog 10 rue Lavoisier - 38330 >Montbonnot >Tél: +33 4 76 61 37 12 Mél: [EMAIL PROTECTED] >Tél. mobile +33 6 07 83 42 00 > > > >
