Re: [service-orientated-architecture] Re: What is a "well defined interface"?

[Keith Harrison-Broninski]

Steve Ross-Talbot wrote: The benefit of having more distinct operations is really about capturing meaning and making the architecture cleaner and clearer - so transparency is a key. A "doit" operation does not help but having "doA" followed by "doB" makes in clear that A preceeds B. Having "doit" and "doit" does not make it clear at all so we can see that it does not help with understanding or clarity. This assumes a choreography perspective, doesn't it - that you can view doA and doB in the context of a process that calls them both.  And this is the paradox at the heart of SOA. SOA is supposedly both: About removing a process context from software, so that services are not dependent on a particular process and can thus be re-used for different purposes About enabling a process context in business, so that monolithic applications can be decomposed into atomic units composable into a variety of processes. But does it hold up in practice?  From the discussion we have all been having, one questions just how much re-use is ever achieved via SOA.  On balance, are many services ever used in more than one process without significant change?  You read a lot about enabling service re-use, but very little about organizations that actually achieve it on anything beyond a trivial scale. Perhaps Ron and Anne have some statistics, but my feeling is that designing interfaces generic enough to be useful in several different processes is very hard, however you try to do it.  For my sins, I spent a few years in the mid-1990s helping people deploy and customize ERP packages, and know from this experience that: The investment of time and effort required to build generic pieces of software is huge.  It took Oracle, for example, many generations of their core financials product set before they arrived at a set of components that were general-purpose enough to suit most customers. The upgrades necessary to achieve this were often not backwards-compatible - new versions of an interface often required extra information to be supplied, or changed the value sets of parameters/results, and in a production system it is not safe just to rely on the defaults chosen by the supplier or assume that old values still have the previous meaning. Even after all these upgrades, most people that deploy ERP still customize it, simply because some of the functionality they need is missing from the interfaces on offer. As with most things in enterprise IT, textbook examples about pizzas and sandwiches do little but mislead.  The bugbear of putting this stuff into practice is not learning or choosing technologies, but grappling with the immense and untidy complexity of the real world.  I argue every day with  people who believe on a theoretical basis that (for example) system X can cater for situation Y, but from the views they put forward you can tell they have never tried it in a real-world situation. It's like Aristotle believing that women had fewer teeth than men.  Supposedly the diets of Mediterranean women at the time were deficient in vitamin C and D, which meant they probably lost more teeth than men did.  You have to be careful about the evidence on which you base your views ... -- All the best Keith http://keith.harrison-broninski.info SPONSORED LINKS Computer software Computer aided design software Computer job Soa Service-oriented architecture YAHOO! GROUPS LINKS  Visit your group "service-orientated-architecture" on the web.    To unsubscribe from this group, send an email to:  [EMAIL PROTECTED]    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.