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. >---------------------------------------------------------------------------
