RE: REST, Conversations and Reliability

I agree that wire formats are the thing for interop.  Hence my comments
about use of SOAP from an infoset versus syntax perspective.

In addition to possibly this being on ws-arch, I guess this might also be a
potential topic for WS-I and the profiles work.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Martin Chapman
> Sent: Wednesday, August 07, 2002 4:54 PM
> To: 'Ugo Corda'; 'Champion, Mike'; www-ws-arch@w3.org
> Subject: RE: REST, Conversations and Reliability
>
>
>
> Here he goes again on his corba experiences:-)
> The corba event and notification service defines  interfaces for the
> transmission of events.
> The specs say nothing about wire formats.
> Different vendors did different things (some using udp, some using MQ)
> and guess what there is no interoperability.
> Neither is their for JMS, which is just an api. Even if you bridge two
> such queues via  a standard interface
> you will need to some common formats for addresses and
> routing at least.
>
> Do we really want this in Web Service-land; is there any
> point without a
> wire format?
>
> Cheers,
>     Martin,
>
> > -----Original Message-----
> > From: www-ws-arch-request@w3.org
> > [mailto:www-ws-arch-request@w3.org] On Behalf Of Ugo Corda
> > Sent: Wednesday, August 07, 2002 4:30 PM
> > To: 'Champion, Mike'; www-ws-arch@w3.org
> > Subject: 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 20:17:06 UTC