I think the value proposition changes depending on where your perspective is -
1) Inside the organization looking across your own infrastructure, and also out to other business partners. This is where SOAP over messaging over some lower level protocol has the most value. Having XML data packaged up in SOAP envelopes as a uniform way of representing data is a good thing. Having a common API to access (Axis) those envelopes is a good thing. Having that traverse over reliable messaging is a good thing. There's a lot of value just in that. If you make an outbound invocation to your business partner as a SOAP over HTTP, and the connection drops or you don't get back an HTTP OK in a reasonable amount of time, then that can be considered an error. Its still in the queue, send it again. There's no guarantee that it won't be received twice but in the overall picture we're still better off than we were before we brought reliable messaging into the picture. A globally accepted reliable end-to-end solution that could extend into your business partner's enterprise would be great here. In the meantime, perhaps the business partner also uses some kind of reliable messaging with its infrastructure. Ideally that's where an HTTPR-like protocol would come in very handy to bridge the gap, or perhaps an ack-based MEP at the SOAP envelope level would work too. 2) The Internet is at the center, and all the end points are sitting at the edge, or inside of, multiple organizations implemented across multiple platforms. This is where SOAP and interoperability has the most focus. In your scenario Kevin, the fact that there is a queue at either end, on the other side of an intermediary proxy or protocol bridge is less important since the HTTP communication is the weakest link. 3) The perspective doesn't matter, because everyone communicates over a universally adopted, end-to-end reliable infrastructure. That's a great goal to achieve over time and we're all excited about that. The choice of reliable protocol may change over time. The common things to focus on over time, regardless of the underlying protocol, are infrastructure things like what actually implements the coordination protocol? Where are the buckets to place things in when good messages go bad, and how does it all get managed? Perhaps I'm getting too off-topic here. Dave [EMAIL PROTECTED] wrote: > > Please everyone understand that I posted this to make sue I had the facts > correct. Don't assume I do - that's why I was asking. > > Ricky Ho <[EMAIL PROTECTED]> on 10/15/2002 01:40:17 PM > > Please respond to [EMAIL PROTECTED] > > To: [EMAIL PROTECTED] > cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) > Subject: Re: SOAP on JMS, a solution to which problem? > > Comments and questions as embedded ... > > >The second answer (for Axis again) is using HTTP for communications > >between the SOAP client and server, but having the SOAP messages be > >persisted in JMS inside the Web Service client before they are > >sent. It could also mean persisting the SOAP Messages using JMS inside the > Web > >Service server application once they are received. These two features > >still allow for integration with other Web Service architectures, such > >as .NET, but provide additional reliability by using JMS. > > Under what failure situation will the saved SOAP message at the sender side > being used ? and how do you use it ? > Same questions at the receiver side ? > > >One approach to enhancing the reliability of Web Service > >communications is to use JMS as the underlying transport directly when > >communicating inside your enterprise (on the 'Intranet'), and then > >bridge from JMS to HTTP at the 'edge' of the enterprise (when going to > >the 'Internet' or an 'Extranet'). > > Does this mean you ONLY has reliability within your enterprise ? Once you > need to talk across the edge, you no longer has reliability guarantee ? > If so, we still don't have an end-to-end reliable solution. > > Best regards, > Ricky > > At 11:07 AM 10/15/2002 -0400, [EMAIL PROTECTED] wrote: > > >In looking at this I felt it was something worth communicating to the rest > >of the world - I've put together a short blog entry/article below. Before > I > >post it to O'Reilly's site I was wondering if I could get a few comments > >from the list just to make sure I know what I'm talking about. BTW - this > >looks very cool. I use WebLogic here at work and have been doing JMS apps > >with it for a while. I'm going to look at transferring some of our SOAP > >apps to this approach. I lost a Web Service RPC request on an app last > week > >and it caused a problem for me :-< > > > >Any comments would be appreciated - to me directly or to the list if they > >are valuable for everyone. I'm mainly concerned that I actually undertand > >this and am communicating it correctly! > > > >Thanks - > >Kevin > > > > > > > > > >Title: > > > >Soap over JMS - what does it mean and why should I care? > > > >Teaser: > > > >As corporate developers look to deploy enterprise applications using > >Web Services, will Soap over JMS become a standard for > >high-reliability applications? > > > >Blog Entry: > > > >I'm a big proponent of using Web Services. I'm convinced that they are > >just a better way of getting certain things done. In particular, I > >think that Web Services provide a great way of integrating two systems > >that are built using different technologies. > > > >But there's a problem. Some applications require very high > >reliability for individual transactions. Soap over HTTP is limited in > >this type of application. The basic problem is that HTTP itself just > >doesn't provide guaranteed delivery. It wasn't designed to and it > >doesn't look as if, without modification to the protocol, it ever > >will. (In fact, <a > >href="http://www-106.ibm.com/developerworks/library/ws-phtt/";>the > >HTTPR proposal from IBM</a> is designed to meet this > >challenge. Unfortunately it is still just a proposal...) > > > >One way that companies are beginning to get over this challange is by > >running SOAP over JMS. What is SOAP over JMS? There are a couple > >answers to this question. > > > >The first answer lies in using JMS as a replacement for HTTP as the > >underlying transport for SOAP communications. Using Apache Axis, this > >means sending messages using the Axis API's, but having the actual > >communications to the SOAP server be processed using JMS instead of > >being sent over HTTP. This is a great improvement in reliability for > >mission critical applications. > > > >The second answer (for Axis again) is using HTTP for communications > >between the SOAP client and server, but having the SOAP messages be > >persisted in JMS inside the Web Service client before they are > >sent. It could also mean persisting the SOAP Messages using JMS inside the > Web > >Service server application once they are received. These two features > >still allow for integration with other Web Service architectures, such > >as .NET, but provide additional reliability by using JMS. > > > >One approach to enhancing the reliability of Web Service > >communications is to use JMS as the underlying transport directly when > >communicating inside your enterprise (on the 'Intranet'), and then > >bridge from JMS to HTTP at the 'edge' of the enterprise (when going to > >the 'Internet' or an 'Extranet'). > > > >Both these features are available today in Apache Axis 1.0. For more > >information please see <a > >href="http://www.oetrends.com/cgi-bin/page_display.cgi?109";>this > >article</a> recently posted on the Open Enterprise Trends site or the > >Apache Axis site at http://xml.apache.org/axis . > > > > > > > > > > > > > --------------------------------------------------------------------------- > >This e-mail message (including attachments, if any) is intended for the > use > >of the individual or entity to which it is addressed and may contain > >information that is privileged, proprietary , confidential and exempt from > >disclosure. If you are not the intended recipient, you are notified that > >any dissemination, distribution or copying of this communication is > >strictly prohibited. If you have received this communication in error, > >please notify the sender and erase this e-mail message immediately. > > > --------------------------------------------------------------------------- > > --------------------------------------------------------------------------- > This e-mail message (including attachments, if any) is intended for the use > of the individual or entity to which it is addressed and may contain > information that is privileged, proprietary , confidential and exempt from > disclosure. If you are not the intended recipient, you are notified that > any dissemination, distribution or copying of this communication is > strictly prohibited. If you have received this communication in error, > please notify the sender and erase this e-mail message immediately. > --------------------------------------------------------------------------- -- 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}