RE: Web services and CORBA

<snip/>

> I agree that we want to extend the Web to do things like reliability,
> transactions, conversations, etc..  I just think that what most people
> are using SOAP for, is not that.  It's changing the way the Web works
> (putting the method name in the POST body, rather than using HTTP's
> methods), and then building the extensions on top of that
> changed thing.
> SOAP actually has a use, that I worked hard on in the XMLP WG, that
> allows it to be used in this manner.
>

I think there might be a requirement and usage scenario that the SOAP/POST
binding meets that you don't agree with.  My take at expressing these are:

Ease of multiple protocol deployment requirement: It shall be possible to
use a variety of protocols under SOAP to send/receive SOAP messages, without
the application developer having to know method specific details about the
protocol underlying SOAP.  Usage Scenario: An application developer creates
a web service and expose it via HTTP, JMS, and SMTP.  The application
developer performs minimal work when deploying the web service on each
different protocol.  The application developer chooses the underlying
protocol(s) based upon features expressed in the protocols, such as JMS'
reliable messaging features.

By using just POST, this requirement/scenario is met.

FWIW, this is the way I would like to have discussions.  What requirements
and usage scenarios are met/not met with particular architecture decisions.

Cheers,
Dave

Received on Monday, 27 May 2002 18:18:33 UTC