[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [xml-dev] Web Service: SOAP or {HTML + Servlets}?
- From: Bill de hOra <bdehora@interx.com>
- To: xml-dev@lists.xml.org
- Date: Thu, 11 Oct 2001 15:05:09 +0100
> 2. SOAP provides a (very) loose framework for sending
> data/requests to a
> server. Basically, it leaves a bunch of "empty space" in the framework
> where you can put stuff:
>
> <Envelope>
> <Header>
> - put anything here
> </Header>
> <Body>
> - put anything here
> </Body>
> </Envelope>
>
> That's about the extent of the semantics of SOAP. Presumably, each
> vendor must define what elements can go in the Header element, and the
> semantics of those elements. Not a very attractive prospect from a
> cross-vendor point of view.
> [...]
> On the other hand, if I were to implement Web Services using HTML +
> Servlets then the semantics of all the HTML elements are concretely
> defined. There is rich (standard, non-vendor-specific) support for
> things such as HTTP sessions, authentication, security, etc. None of
> this exists with SOAP.
Well, no, of course not, SOAP just a spec for sending XML messages (or
documents if you prefer). RPC is one thing you can do with it; I'd be
inclined to agree that SOAP as RPC is a narrow take, but RPC is what
most people know. I'm not sure about semantics, but the elements and
attributes of SOAP are just messaging infrastructure to enable machines
to communicate with each other. The content of those messages are a
different matter: anything that can be rendered down to XML can go into
them, modulo some syntactic restrictions.
If your clients are going to spit out to a person, then servlets+markup
should do fine, but servlets+markup won't solve that cross-vendor matter
for you either; you're depending on people, which is fine. People are
the state of the art in screen scrapers, and you get around some very
hard problems by keeping them in the loop. If your clients are going to
spit out to another machine or receive services from another machine,
SOAP's worth evaluating.
> My vision of next generation Web Services is an XML-document-based
> architecture, with a well-defined set of elements. I envision the XML
> documents conforming to an XML Schema. I envision schema
> validation of
> the documents. I don't see any of this in SOAP.
I think by document-centric, you mean message-centric, but I'm not sure.
It's all about the contracts. If SOAP works out as promised, it will
allow us to get to closer the real interop problem, which is how to get
machines to negotiate a contract in band and them communicate
effectively using that contract. Web services is symptomatic of this.
Calling what is sent a document or a message won't solve that problem,
nor will RPC.
There seem to be roughly 3 schools of thought on how to do this, all
based around language. Either agree on a domain specific protocol to
define a contract for the domain (use components), agree on a logical
formalism from which domain contracts can be built (use inference), or
agree it can't be properly automated yet and repeatedly reconfigure
systems to use new contracts (use systems integrators). The machine
interop breakthrough start to should occur when we can get machines to
ask and answer questions like: 'what does X mean?', 'by X, I mean Y'.
SOAP as pipework, I hope, gets us to a higher level of confusion, from
where non-interop can have some light shed on it. Failing that lofty
goal, if we can build services infrastructure that is highly
configurable then people can strategically define the contracts out of
band and reconfigure the machines: maybe the tactical data transfer side
can be automated for a broad combination of services, and the code has a
fighting chance of staying current with changing requirements.
regards,
Bill de hÓra
--
InterX
bdehora at interx.com
dehora at acm.org
+44(0)20-8817-4039
www.interx.com