RE: REST, Conversations and Reliability

>They (or IBM, or a 3rd
>party) write standard SOAP interfaces to the proprietary MOM stuff, the
>other systems can choose any of a wide range of SOAP toolkits, and they're
>getting message level communication between the backend systems and the
>clients out on the intranet or internet

Yes, but wouldn't there be a QoS degradation (using today's technology) on
the non-MOM segment, which implies a QoS degradation (reliability, etc.) in
the end-to-end connection? 

So I think the issue is to have non-proprietary implementations of
message-oriented SOAP (over HTTP or other standard transport, using
standardized header extensions, etc.) that offer similar QoS as that
provided by using SOAP over proprietary MOMs. What I was saying before is
that, as far as I can see, that is not available today. So, in practical
terms, I still have to use a proprietary MOM end-to-end if I want to do
message-oriented SOAP which is effective from the point of view of
conducting business. Am I wrong?

Ugo

-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
Sent: Wednesday, August 07, 2002 3:42 PM
To: www-ws-arch@w3.org
Subject: RE: REST, Conversations and Reliability





> -----Original Message-----
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> Sent: Wednesday, August 07, 2002 4:37 PM
> To: 'Champion, Mike'; www-ws-arch@w3.org
> Subject: RE: REST, Conversations and Reliability
> 
> Systems like MQSeries are usually mentioned as having better QoS than
> provided by open standards, so that if I want to 
> realistically use SOAP
>  messaging for business I have to rely on one of those proprietary
> frameworks.

From the customer situations I've seen where MQSeries and SOAP are  on the
table at the same time, I think it's the other way around.  The point is to
use exploit SOAP's protocol independence and support for intermediaries, not
to rely on the MOM systems to use SOAP.  

For example, consider an enterprise that has standardized on MQSeries (or
some other proprietary MOM) for its internal communications, and wants to
integrate those with other enterprise "stovepipes", or other systems in
their supply chain, and potentially customers or agents out on the internet.
They can't re-write the backend systems to use open standards, and they know
that they can't get the supply chain / customers to use the proprietary
MOMs.  So, they see SOAP riding to the rescue:  They (or IBM, or a 3rd
party) write standard SOAP interfaces to the proprietary MOM stuff, the
other systems can choose any of a wide range of SOAP toolkits, and they're
getting message level communication between the backend systems and the
clients out on the intranet or internet. Of course there are intermediaries
that bridge the Web world and the MOM world, but these are transparent to
either end.  They write WSDL descriptions of the backend processes, import
them into some web services toolkit, and then they have business processes
working between the client systems and the legacy stuff.

That's the vision anyway; AFAIK it's also reasonably close to current
reality.  Someone from IBM or another company with a proprietary MOM system
might want to correct me or elaborate here. Anyway, I don't see the
proprietary MOM scenario as "lipstick on a pig". 

Anyway, whatever binary serialization the MOM vendor or 3rd party developer
does is its own business; obviously they have to convert back and forth from
standard XML syntax to interoperate with anyone else, so I don't think
that's W3C's problem.  (Likewise, as I understand it, folks such as
cellphone vendors are working on compressed InfoSet serializations a la
WAP/WML, and again that;s their business not ours).  All the WSA has to do,
IMHO, is not build the assumption of XML syntax deeply into the
architecture, but SOAP 1.2 has already done that for us.

I can imagine that we might want to spawn off a particular InfoSet
serialization WG (e.g., for URIs, perhaps using more URI-friendly
delimiters, hashing namespace names, whatever it takes to serialize a
non-trivial InfoSet representation in a way that would fit into a practical
URI).  Or maybe not; there may be better ways to deal with read-only web
services that require a bunch of SOAP headers via HTTP.

Received on Wednesday, 7 August 2002 19:30:15 UTC