> From: Simon St.Laurent [mailto:]
>
> If you want an approach that uses the same encoding for all requests,
I
> strongly suggest that you look someplace other than HTTP. Microsoft
> seems to be headed in that direction anyway.
That is what I want from SOAP. I want use SOAP to build distributed
systems based entirely on message passing. Dealing with all messages in
exactly the same way makes doing this simpler. Using XML as the message
format has lots of benefits that I don't think are in dispute.
For me, SOAP is much more then RPC over HTTP using POST. If that is all
that SOAP offered, I wouldn't care for it much. Resolving the questions
around the relationship between SOAP, XML Web Services, the Web, REST,
and HTTP will help SOAP move past it's (IMO, misguided) RPC over HTTP
beginnings. If, when all is said and done, I'm left with something that
should be called "XML Services" or "XML Internet Services," instead of
"XML Web Services," I really don't care.
There are many other uses for XML on the web besides building message
passing distributed systems. I am all for those uses. They should ALL be
used as needed.
>
> > OK. First, we should be clear about exactly what is being compared
here.
> > Are we comparing SOAP to the ad-hock sending XML messages? Are we
> > comparing SOAP to DCOM, CORBA, or other RPC protocols? Are we
comparing
> > SOAP to a more RESTful methodology?
>
> From my perspective, we're comparing SOAP to ad hoc XML, likely in a
> RESTful context - "SGML for the Web", remember? DCOM, CORBA, and RPC
> don't seem to add much value to the conversation.
>
As I indicated above, what I think that SOAP is useful for does not
necessarily take place in a RESTful context. If a binding for SOAP over
HTTP that is RESTful is defined, great! If SOAP can't use HTTP because
SOAP is found to be fundamentally non-RESTful (which I do NOT believe is
the case), then I will still find SOAP valuable for building the kinds
of systems it is intended to be used for.
So, from my perspective, it seems we are left with a discussion about
using SOAP versus passing around ad hoc XML.
First, I assert it should be possible for distributed systems to be
created and maintained by decentralized uncoordinated entities.
Controlling (designing and implementing) both the sender and receiver of
a message is a special, and relatively uninteresting, case.
More importantly, I assert that to be robust, such systems must be able
to evolve without centralized control. Specifically, the definition of
what comprises a correct message may be changed independently by the
sender and the receiver at any time. That is not to say the system
should continue to work when such changes occur, but that it must fail
in a predictable way when it is broken.
To support this, there must be a shared formal description of how
messages should be structured, how they should be delivered, and how
they should be processed. Only then can you reliably detect when you
receive a message you didn't expect and, when possible, communicate this
failure in an unambiguous way to the sender of the message.
SOAP is nothing more, and nothing less, then such a formal description.
We may debate about whether SOAP is perfect (I'm sure it isn't, it is a
compromise created by many different individuals with different
concerns), but the need for such a system should be clear. Do you agree?
== Mike ==
