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