An excellent summary !! Another BIG thing about the Web Service and JMS semantic mismatch is about the way they look at TRANSACTION (although there is not a widely-accepted one at this moment, so I'm talking about the model behind "BTP" and "WS-Transaction").
In JMS, it is NOT possible to send an async request and get back its response (asynchronously) within a single transaction. Your request message will not be possible to reach the server before the transaction commit successfully. In WS-Transaction (and BTP) model, the request message can reach the server with an associated context. And there is a 2-phase co-ordinating protocol at transaction termination time so that the effect on the server side can be back off in case the client abort his transaction. This semantic mismatch is another BIG thing to me. I think the challenge to establish a reliability delivery standard now is there is no consensus in whether this should be done at the "TRANSPORT" level or the "SOAP MESSAGE EXCHANGE" level, and both camp have very good reasons on that. So there is NO solution today that is inter-operable, but if you have control in both the client and server side (which is a very common deployment scenario when people test our web services in their intranet), then there are at least a couple solution that I can think of .... 1) Implement a handshaking protocol (ack / retry) at the client handler and service handler -- (both sides need to be AXIS that has these handlers installed) 2) Use JMS as your underlying transport -- (of course, you are using the same JMS vendor on both side) 3) Use HTTPR -- (I haven't tried this yet) 4) Do the handshaking at the application level Would love to hear other people's suggestion .... Rgds, Ricky At 10:25 AM 10/14/2002 +0200, 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
