[
Lists Home |
Date Index |
Thread Index
]
On Wed, 12 Mar 2003 14:09:18 +0000, Bill de hÓra <bill.dehora@propylon.com>
wrote:
>
> in other words, what we want are dataflow architectures to work their way
> in from the Internet to the systems code, not for the systems code and
> associated idioms (including object oriented programming) to spill out
> across the Internet....
>
> Integration becomes more a matter of data and transformations, and less a
> matter of APIs and function calls.
Ah yes, the Propylon dogma :-) I fully agree. SOAP, HTTP, REST, XSLT,
XQuery, whatever are alternative, often complementary ways ways to do this
and shouldn't be thought of as paradigms within which solutions must be
crafted.
>
> The dogma I see comes in two forms. One, when people say you don't need
> SOAP/WSDL at all, that it has no architectural value or significance for
> application integration over an d above the Web. Two, when people say you
> can blow out the data formats from the code, the tools will take care of
> it. (there's a huge amount of misunderstanding on the ground on how to
> use and build a WS. WS are not about sending a Java linked list to a Perl
> script using SOAP as a serialization and HTTP POST as the delivery
> mechanism, but you wouldn't know that from some fora).
I think I agree -- SOAP is neither the evil "end of the web as we know it"
nor the panacea that lets us forget about the nasty networking stuff and
just think about objects and methods. It's a convention for *data*
interchange (that also supports some RPC conventions that are sometimes
useful but considerably over-emphasized at present). The real value will
come if/when standardized headers defining information needed by
intermediaries that support encryption, identity/authentication,
authorization, multi-protocol routing, delivery confirmation / retry
management (AKA "reliable messaging"), multi-message choreography, etc.
come into widespread use. Those features could be exploited by RESTful,
RPC-ish, or dataflow/transformation architectural styles.
> The thing is, to do anything interesting, are the users being burdened
> with reinventing protocols? As Geoff Arnold pointed out recently, API and
> protocol design require very different mindsets and approaches. Just
> shipping data around, really means just shipping data around /with/
> service level agreements.
To be honest, this is something I'm having a hard time coming to grips
with. The RESTifarians make a strong point that every WSDL file defines a
new "protocol", and that ordinary users can't be expected to grasp the
subtleties of protocol design. Getting back to my original point, that
seems like saying that the specific message format that a CGI (or
ASP/JSP/etc.) backend expects is a "protocol." True in the literal sense
of the word "protocol" in English, but I'm not sure it means anything more
than "the minimal expectation by the server of the information content
needed to do its job" (which is my understanding of the position that folks
including Walter Perry and Sean McGrath advocate). It is VERY TRUE that
the Web services industry has given WSDL users immense lengths of rope with
which they can hang themselves by generating tightly-coupled, RPC-style
code for both sides from the WSDL file. I'm not convinced, however, that
that's anything but a temporary abberation that the industry will move
beyond once the well-known scalability problems of tightly coupled systems
are exposed once again.
|
