>Loose Coupling the Implementation >Web Services certainly fits the bill as does REST >and other styles of Service implementation. Indeed, >it's not the choice of interoperable specification (whether XML based or not) >that enables this level of loose coupling, but rather the Service contract. .... >Loose Coupling the Service Contract >First, a proper Service contract that is interface-neutral >will alleviate much of the problem of Service contract change management... >Active management and Service intermediaries further simplify the Service contract change... Hmm.. The emphasis here seems to be on the Service Contract as the center of the universe.. But if I am understanding the RESTian approach correctly, service contracts are not emphasized all that much in that particular approach. While I definitely resonate standards based definition and access to services, based on my admittedly neophyte's understanding of REST, the combination of the usage of HTTP as an application protocol that supports REST principles combined with the tenet of "Hypermedia as the engine of application state" blows out of the water the ease with which you deal with the issues of both of the coupling concerns mentioned above.
>use of late-binding approaches that leverage run-time registries and contract-based binding.. I am sorry, but I have never bought into this particular fantasy in the SOAP world.. Until we have resolved the issues of seamless interoperability across web service stacks (primarily arising from the XML to Object databinding issues), run time binding to services by consumers which involve the generation and implementation of dynamic client side proxies is nothing more than a VisionQuest! The only run-time approach that will work in the current environment that DOES "leverage run-time registries and contract-based binding" is limited to dynamic binding to different SOAP endpoint's (which could come from a run-time lookup against a registry) if and only if a priori interoperability testing has been done between potential producer and consumer web service code. >The Service Description Framework (SDF) shared by ZapThink in our Licensed >ZapThink Architect (LZA) boot camps is one of those >technology-neutral Service contract templates. The way that I have heard Chris Bashioum from MITRE (and others) who developed the SDF [1] describe it has been more from the perspective of "What are the things that are needed to describe a service?" and they too have always had a heavy service-contract-ish/schema/ontology/taxonomy spin on it... [1] http://colab.cim3.net/file/work/SICoP/2006-08-15/ServiceDefinitionFramew orkSOAFWGv3.ppt I just want a Loose Coupling "Make it Easy" Level :-) Regards, - Anil :- :- Anil John :- http://www.aniltj.com/blog/ :-
