Hello Jacques, These are all great discussion points. There is never one correct answer. I can't speak for all of the Axis developers, but I will try and explain Sonic's point of view for doing this.
The biggest benefit is having a common set of API's and surrounding infrastructure that abstracts away the details of whether you are using HTTP, reliable messaging, or some other transport. JMS is just another protocol from that point of view...one that provides reliable delivery of data across your enterprise. JMS is not just a client API. It also prescribes a set of required behavioral semantics-like once-and-only-once delivery of data. What we're saying here is that the behavioral semantics is more important than the JMS API. We have embedded the JMS API inside of a layer that takes care of some of its deficiencies, and have chosen to expose the Axis API as the only thing that the client application uses. Your observation about using JMS as a solution for the Intranet is a great discussion point. The real question to consider is how does one characterize the "Intranet" these days, and where is the "edge" of the network anyhow? For lack of a better word, I would characterize the "Intranet" as the realm of networking and IT infrastructure that is under your corporate control, where you have the ability to install and maintain the software of your choice (like a JMS provider). The "edge" of the network is that place where that level of control ceases to exist. What we (Sonic) are seeing repeatedly in real deployment scenarios is the desire to use SOAP over reliable messaging across the enterprise, and use SOAP over HTTP to bridge the boundaries at the "edge" of the network. This "Intranet" can be very large as well, covering global deployments between headquarters, field offices, warehouses etc. Even for the "edge" situations -- there are JMS providers that are capable of traversing firewalls in a secure and reliable fashion. It may also be possible to ask your business partner to use the Axis client in conjunction with the JMS client of your choice, in order to communicate with you. In the "edge" of the network cases where SOAP over HTTP is the desirable option, then that's great, do it. If a SOAP-over-HTTP message arrives at your door, then gets placed on a JMS queue, it is now safe within a reliable communications infrastructure throughout its entire tour through you business processes. If an outbound request needs to be made from one of your systems across the Internet using SOAP-over-HTTP, and that request fails, then that's OK too, because the message that caused the request to be made is still sitting in the queue. A truly interoperable, reliable SOAP communication is an area that can always be improved, and I'm real excited about seeing that happen. We are also real interested in exploring things like WS-Txn, HTTPR, and all of the evolving proposals that can help solidify the SOAP-over-HTTP communication to make it more reliable. I think the widespread adoption, of whatever that winds up being, is a few years away. For the time being, enterprise messaging is here-and-now, and has widespread adoption already. In the Axis submission we are providing a nice and easy way of blending together these two worlds using a common SOAP stack. We look forward to addressing other reliable protocols as they evolve, and providing ways of bridging the gaps. Dave 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 -- Sonic Software - Backbone of the Extended Enterprise -- David Chappell <[EMAIL PROTECTED]> Office: (781)999-7099 Mobile: (617)510-6566 Vice President and Chief Technology Evangelist, Sonic Software co-author,"Java Web Services", (O'Reilly 2002) "The Java Message Service", (O'Reilly 2000) "Professional ebXML Foundations", (Wrox 2001) --
begin:vcard n:Chappell;Dave tel;cell:617-510-6566 tel;work:781-999-7099 x-mozilla-html:FALSE url:www.sonicsoftware.com org:Sonic Software Corp. <BR><IMG SRC="http://www.sonicsoftware.com/media/general/logos/sonic_logo1.gif"; VSPACE="10"> adr:;;14 Oak Park;Bedford;MA;01730;USA version:2.1 email;internet:[EMAIL PROTECTED] title:vice president & chief technology evangelist fn:Dave Chappell end:vcard
![http://www.sonicsoftware.com/media/general/logos/sonic_logo1.gif"](http://www.sonicsoftware.com/media/general/logos/sonic_logo1.gif"){kind=link}