Lists Home |
Date Index |
What are the local and long term costs for optimization
for the global case?
What are the efficiencies gained by tight coupling of
enterprise (intra and extra) processes vs the loose
couplings based on standard document types?
Even with a global namespace, the same questions
have to be asked. Use of a global namespace is
not the issue as far as I can tell. You may
have a hard time defining "distributed hypermedia"
to everyone's satisfaction. See Dexter Reference
From: Leigh Dodds [mailto:email@example.com]
Fieldings dissertation presents a number of architectural styles, and
evaluates each of them within a defined context: distributed hypermedia.
However he doesn't cover RPC in this classification (correct me if I'm wrong,
I've only read through the whole thing once). RPC is mentioned in a
later section  though.
So why not define RPC as an architectural style -- in all likelihood derived
from others that Fielding does classify -- so it can be objectively compared
Might that not provide a clear evaluation of the architectures separate
to any issues with the specific technologies (SOAP, WSDL, .NET, etc)?
It may be that RPC doesn't compare favourably to REST in a distributed
hypermedia environment, but does in others (e.g. the canonical 'inside the firewall'
example). It may be that RPC *can* be used in successfully used in some environments
across the public internet, just not distributed hypermedia. It may
be that these can exist side by side, although no doubt there will be efforts 
to make the distinctions disappear.
Identifying the suitable contexts for different architectural styles seems like a
best practice discussion -- there will be no single right answer.
At this point we could argue over whether there ought to be several different
Internet architectures (i.e. "there is no (single) Web"), or whether every effort should be
made to optimise for the general case, i.e. REST. Personally I'm in the latter camp.