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 19:54:54 UTC