This is actually a very interesting question. I think Anne hits all the technical points right on the nose (as she always does). There are some elements that Anne points out that do differentiate a well- defined interface in the Web Services world from a typical Java or C# class or interface definition. The bulk of it is centered around the non-functional aspects and interoperability goals of a Web Services based SOA. If we're dealing with local invocation of objects, the transport, message formats, etc. are all defined by the underlying platform. Some non-functional aspects can be externalized, such as Security, in the same way that WS-Security and WS-SecurityPolicy externalize it within a Web Services model.
If you move to a remote invocations, as long as you stay within a platform-specific model, such as .NET Enterprise Services or Java RMI, things like transport bindings may still be defined or implied by the platform. CORBA moves into a more heterogeneous model, with CORBA IDL being more analogous to WSDL, but I think each new description language has tackled the problem better than the predecessors. Now, the more interesting part of the question to me are the qualitative aspects of "well-defined." You can have WSDL and WS- Policy and still have something that does not constitute well-defined in terms of benefit to an SOA. Here's where having a background in usability or human factors come into play. User interfaces are clearly NOT well-defined. A bad user interface may lack clarity of purpose, be mismatched to the context in which it is being used, have hidden elements, etc. The same thing applies to a services interface, or even an object interface. Simply put, the interface should demonstrate to the consumer exactly what behavior will be executed, no more and no less, and all of the constraints associated with it. A very easy example to comprehend is the notion of side effects. If I have a "deposit" operation in my bank account interface, I expect that it will increase my balance by the amount I deposit. If, however, it takes out $2.00 for a processing fee and I'm not aware of that, it's a poorly defined interface. These aspects may not always be easy to define in terms of a functional interface. Actually, this is a better example than I thought for the discussion. To the pundits out there, where should the processing fee be represented in a Web Services world? Would these be something to specify via WS-Policy? In the real world, examples of this include ATM machines that now warn you that you're going to be assessed bank charges prior to executing a transaction, and TurboTax, which gives you multiple options for paying for the filing fees at the time you submit your return. It can be paid via credit card, deducted from your refund (if you're getting one), etc. If it automatically took it out of a refund without telling you, that would be bad. I'm interested in what others have to say. Now I'll go back and try to help my wife figure out which button in the minivan is the rear defroster versus the front defroster. One button has a rectangular window with wavy lines in it, one button has an arced window with wavy lines in it. Completely intuitive, right? For those of you with an interest in human factors, Mark Hurst has a newsletter and blog available from http://www.goodexperience.com/ and also maintains a site with examples of bad interfaces at http:// www.thisisbroken.com/. -tb On Feb 24, 2006, at 8:37 AM, Jan Algermissen wrote: > Anne, > > thanks - but... > > Any common OO API is then also 'well defined' because what I need > technically is all right there in the method signatures (and it is > even machine readable, too - of course). > > What is not in a common OO API is the order in which the methods are > to be called - that 'additional semantic information' just gets hard > coded in the client. > > But with SOAs the situation is exactly the same. There is nothing in > the API definition that is machine readable and would provide > information about the call order. > > So, how is moving the API description into an XML file any more 'well > defined' than traditional OO API class definitions with method > signatures? > > IMHO, the notion of well definedness of an API just doesn't hold as a > distinguishing ... umm ... constraint ... between the SOA and the OO > paradigm. > > Remaining confused... > > Jan > > > > On Feb 24, 2006, at 2:20 PM, Anne Thomas Manes wrote: > >> A well-defined interface is an interface that is defined using >> standard interface description languages. The interface description >> should be machine-readable so that code can be generated from it. A >> comprehensive interface description should describe the location of >> the service (or some means to find it), the protocol bindings >> supported by the interface, the operations supported by the >> service, the message formats that are exchanged with each >> operation, any constraints and capabilities associated with the >> interface, supported interchange patterns, and semantic information. > > >> >> >> In web services, a comprehensive interface description would be >> defined using XML Schema, WSDL, WS-Policy, WS-CDL, and RDF. >> >> A poorly-defined interface requires human communication to >> determine the formats and protocols required to access the service. >> >> Anne >> >> On 2/23/06, Jan Algermissen <[EMAIL PROTECTED]> wrote: >> SOAists, >> >> I keep reading about "consumers communicating with services through >> *well defined interfaces*" as being one of the essential aspects of a >> SOA. >> >> But I cannot figure out, what it means that an interface is "well >> defined". Especially I do not understand what an interface is that is >> *not* well defined. >> >> Can someone shed some light on this? >> >> Jan >> >> >> _____________________________________________________________________ >> _ >> __ >> _______________ >> Jan Algermissen, Consultant & Programmer >> http://jalgermissen.com >> Tugboat Consulting, 'Applying Web technology to enterprise IT' >> http://www.tugboat.de >> >> >> >> >> >> >> >> >> >> Yahoo! Groups Links >> >> >> >> >> >> >> >> >> >> 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. >> >> > > ______________________________________________________________________ > __ > _______________ > Jan Algermissen, Consultant & Programmer > http://jalgermissen.com > Tugboat Consulting, 'Applying Web technology to enterprise IT' > http://www.tugboat.de > > > > > > > > > > Yahoo! Groups Links > > > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
