[
Lists Home |
Date Index |
Thread Index
]
Mike Champion wrote:
> > In the realm of services hard-coded to talk to each other, you are
> > entirely right. In the realm of services that are more loosely connected
> > (for instance through pipes and filters), I do not think you are.
>
> I think this is a key point. Definitely, the more one has to discover
> services on the fly and late-bind to them, the more the principles of the Web
> As We Know it (such as hyperlinks, the ability to leverage Google, ...) will
> be important for Web services people to use and appreciate. A lot of the
> disconnect between the "Web as We Know It" folks and the "Web services" folks
> is that "discovered-on-the-fly, loosely-coupled services invoked over the
> Web" exist mostly in marketechtures and white papers now.
On the contrary, the beauty and appeal of truly Web-based loosely-coupled
services is that they don't require marketechture, paradigm buy-in, venture
capitalist mindshare, first-mover advantage nor any of the host of horrors of
dot commieism. They can be built (as some of us routinely do) without
compromise using simple generic tools on the "Web as We Know It" today. It is
instead the malignantly-named Web Services which require a priori agreements
and intimate mutual knowledge between sender and receiver which are anathema to
the 'web'.
> The SOAP/WSDL/RPC paradigm works pretty well (at least compared to the easily
> available alternatives) for application integration on secure, highspeed
> LANs, and the people actually doing that stuff resist being lectured to by
> RESTifarians.
Sure, and what they have reinvented is the homogenous enterprise network,
suitable for two-phase commit transaction processing, but ostensibly
implemented on the world-wide internetwork. It isn't really the internetwork,
of course, because the premises of the internetwork are that every node is
directly addressable from every other, at the price of all nodes giving up an
intimate knowledge of what any other nodes expect, or intend. On the
internetwork, one node knows, beyond the address of another, only what that
other node produces, as may be observed in the content which it publishes.
> Some interesting dialogues are going to take place when people start working
> in the fuzzy middle where services must be loosely connected to each other
> yet tightly integrated with exisiting back-end systems.
There is no fuzzy middle in the internetwork architecture. Functional nodes
create and publish content at addressable locations. Other nodes fetch that
content, instantiate it together with other content into data structures unique
to their own functions and then execute those functions, publishing the output
in turn at addressable locations. Within the process boundary there is tight
coupling, and both the details of function and the nature of data are opaque to
all outside observers. Between nodes there is the direct addressability of
human-readable plaintext content.
> IMHO, neither the pure "design everything as a resource and access
> representations over the Web" nor the pure "design everything as an object
> and pretend the Web isn't there" approaches will suffice, so they'll have to
> cross-pollinate each other.
IMHO, the Web--that is, the internetwork--cannot be cross-pollinated by the
utterly inimical premises of the homogenous enterprise network hiding behind
the firewall and within the cozy club of the cartel.
Respectfully,
Walter Perry
|
