http://www.oreillynet.com/pub/wlg/2171
---
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, pr
> 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
Dave -
Thanks for responding
---
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, proprietar
pond 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 c
ECTED]
cc:
Subject:Re: SOAP on JMS, a solution to which problem? [Scanned for
known viruses] (Document link: Database 'Kevin Bedell', View '
($Sent)')
In looking at this I felt it was something worth communicating to the rest
of the world - I've put t
ell/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
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 u
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 - t
ravels 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:
ravels 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]
>Subje
D] [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 i
(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
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 simil
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 abstrac
An excellent summary !!
Another BIG thing about the Web Service and JMS semantic mismatch is about
the way they look at TRANSACTION (although there is not a widely-accepted
one at this moment, so I'm talking about the model behind "BTP" and
"WS-Transaction").
In JMS, it is NOT possible to sen
A very good summary of the state of the asynchronous web services
applications.
I think that a standard reliable transport may be covered by the
ebxml-msg and JAXM specifications. It appears that some of the JAXM
implementations use JMS internally for queuing and reliable semantics.
http://ww
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 Service
17 matches
Mail list logo
