[
Lists Home |
Date Index |
Thread Index
]
Mike Champion wrote:
>> CGI defines an interface between applications/scripts and websevers.
>> It has nothing to do with the Web's client/server contract; that's
>> defined already by HTTP/SMTP/FTP and so on.
>
>
> Sorry, I just don't buy that. For GET (and PUT/DELETE in theory but not
> widespread practice) HTTP defines a reasonable and useful contract. But
> much of the real Web that really works is a bunch of arbitrary stuff
> POSTED from HTML forms or whatever, and the "CGI" details are the
> interface that matters if you are writing a form to work with existing
> back end code or back end code to process a form. My point was that this
> interface is no more late bound than a "Web service".
I'm not saying CGI isn't real or important. Just that it's
incidental to client server contract (POST is not incidental). Where
CGI matters, 'architecturally', is hooking up back-end apps and
scripts to web servers, not clients to back end apps.
>> The difference is that most (all?) successful Internet systems are
>> keyed off protocols. As protocols they have semantics that make them
>> distinct from the 'protocol neutral' architecture implied by
>> SOAP/WSDL; something imvho needs to downgraded to 'transport neutral'
>> in the long term - there ain't no getting away from protocols if we're
>> serious about interoperating applications.
>
> That is the REST dogma, and I buy it as far as the synergy between HTML
> links and HTTP GET is concerned.
I don't think it's REST dogma (but I may be wrong there). All I'm
suggesting is that it's (imho) good that SOAP gets you transport
neutrality. I'm less sure about protocol neutrality (being that it's
true for SOAP, or desirable for SOAP based apps).
> And as far as 'transport neutral' is concerned, I very strongly suspect
> that many successful websites are forwarding that information collected
> over HTTP (by GET, POST, or whatever) to backoffice systems that are
> linked by all sorts of proprietary protocols that most of us have only
> the dimmest awareness of.
Sure. But it's a good thing that the details of people's backend
systems are hidden by behind protocols and shared data formats
rather than API gateways, because it drives you towards dataflow
architectures.
You wouldn't want to go from this:
client [--protocol --] server [-- gateway --] backend
where there are preserving transformations of data along the way, to
this:
client [--] [------------ gateway -------------] backend
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. Think of it as the
retreat from Moscow after a few terrible winters in the API wars -
working from code outwards is what we know doesn't work so well for
application integration and is precisely backways methodologically.
Integration becomes more a matter of data and transformations, and
less a matter of APIs and function calls.
Especially so in a world where the backend and the clients are own
by different people. For n-tiered system we now have to push the
code back to where it belongs
What SOAP seems to offer that is valuable, is a way for web servers
to act as connectors for backend systems. So this:
client [---------protocol ----------] server [--] backend
might be a better description of its practical if not quite
architectural significance.
In other words using SOAP gets us two (at least) useful things.
First it can help eradicate bogus exposures of code-faces in check,
second it allows a dataflow to move across different transports. But
it does not remove the need for protocols, data, and transformations.
Note that we still want all the OO and procedural goodness when it
comes to building the applications themselves and extending them
(via plugins and whatnot).
Where clients are other backends, you have:
[backend-] ws client [--- protocol ---] ws server [-backend]
Thus my issue with comparing SOAP with CGI as in the same style
architecturally, sorry it's not shorter.
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).
> The whole point of SOAP for many such users is
> indeed to "get away from the protocols" and just ship the data around
> without regard to language, platform, or vendor, or the underlying
> protocol. That's what XML is good for, and why the Web services people
> latched onto it. [much to the annoyance of Mr. St. Laurent and Mr.
> Harold :-) ]
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. For example
reliable delivery is becoming a hotspot where WS vendors are happy
to compete on specs+tools (granted it's a step up from apis+tools),
for now. Maybe it's too early to standardize, or maybe the thinking
is that layers over SOAP/WSDL are valuable enough not to
commoditize. But I do feel claims about protocol neutrality are
borrowing trouble.
Bill de hÓra
|
