Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
