"Axis: Next Generation Java SOAP", published by Wrox Press, 2002, has an interesting section on writing an AXIS transport handler with the transport being JMS (see pgs 154-166). It has been discussed in this mailing list previously.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 5:30 PM To: [EMAIL PROTECTED] Subject: Re: SOAP on JMS, a solution to which problem? Ok. can you please elaborate on how you define "SOAP over JMS". Since JMS is not a wire level protocol like HTTP/FTP/SMTP/other this term IMHO is misleading. "SOAP over JMS", really means using the JMS API to send a SOAP message.. right ? So unless you use a standard wire protocol no two vendors will ever interoperate. Look at Sonics solution... even though its "SOAP over JMS" You cant use that with anything else because only Sonic understands what the XML on the wire is (ie a popertitory packaging of the SOAP message in a multiplart message) And you have to use their properitory API to decode that message. So what exactly are you talking about here when you say "SOAP over JMS" ? I can undertand the reverse "JMS over SOAP" where the wire level binding is a SOAP message and travels over another protocol like HTTP (eg the Systinet product). /S Original Message: ----------------- From: Ricky Ho [EMAIL PROTECTED] Date: Mon, 14 Oct 2002 11:36:48 -0700 To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: SOAP on JMS, a solution to which problem? I agree that SOAP over JMS over the intranet (to Dave's definition) is a very practical approach today. although we still need to be aware of other conflicting approaches as well .... Without knowing the Sonic contribution, I', not sure if the message correlation id is an explicit field similar to JMS approach. If so, this is different from the philosophy of the Orchestration camp who believes correlation should be done via the business message itself rather than an explicit id. The SOAP/HTTP at the edge is where the end-to-end reliability breaks. The request message may have been lost before even getting into your JMS queue. Does using BTP with SOAP/HTTP can achieve reliability today ?? Best regards, Ricky Response embedded >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) >-- -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ .
