This is a great topic, thanks for bringing it up. The great thing about this is that the discussion highlights the differences between a technically complete description of the method signatures which define the inputs and outputs of a system and getting value out of the system, which is more of a business concept.
Services are defined in many ways, but some common themes include the abstraction of the interface from the implementation, and also the delivery of some value across that interface. I have some fun with this idea in my "Pizza Shop Blueprint" blog post here: http://www.soacenter.com/?p=33 But the general idea is that "here's how I talk to a service" is really about the exchange of information--but in order to exchange value you most likely need to know more than how to talk to a service. Additional service descriptions needed beyond the method signature depends considerably on the type of value you are seeking. Examples of value which might neccesitate further interface description might include: Development reuse value: What similar services exist in the registry context? Semantic reuse value: If you are attempting to couple unlike systems, knowing more about the meaning of the terms used in the interface description is key. For example "currency translation" can be achieved in several hundred different ways, each of which can produce significantly different economic results. Transaction value: If you want to transact with a service, you may want additional information about reliability, service levels, Business context: If you want to transact with a service repeatedly over time, you may want information about the business context, whether legal and contractual or more "loosely coupled". orchestration use value: An area well defined by CDL--answering the question of how a given service behaves in the context of orchestration sequence and the rules by which services want to be ordered. lifecycle management value: Understanding whether a given service is in deployment, staging, testing or any other state may be of value. access control value: If you or your organization derives value from protecting, hiding, securing or otherwise preventing unauthorized users from a service, a description of the policies pertaining to access are needed. Of course this is insufficient to the actual purpose--a policy enforcement mechanism is needed to ensure that those access policy descriptions are followed. business performance value: If you want to compare how one service is doing vs another from a business value perspective, additional descriptions including run time data feeds may be useful to describe the service as a real time transacting entity. brand value: Aggregating all of the intangible factors of service from a human perspective, it may be useful for you to know something about the provider identity of a service. For example, an escrow service on the internet may have more value if you think it is provided by eBay.com than by ripyouoff.com What's interesting is the following--I could keep going all day long describing different use cases where people of different types are all trying to get value out of a service and each needing increasingly ornate service descriptions. This might be a good point to pause and reflect on the preceeding list. 1) Many descriptions of a service changes over time 2) Services are "live" and can be described by such terms as popularity, transaction volume and other real time information 3) Sometimes the only recourse to understanding the true semantics of a service is to look at the implementation of that service. 4) Many "descriptions" of services require commensurate enforcement (such as service levels, access control etc) The third point is interesting. This suggests several observations-- one of which I can credit to Paul Fremantle of WSO2. Paul said that his view of the value of Open Source was that you could see the implementation in a completely semantically unambiguous way. To borrow a zen phrase from Sun Microsystems (who invented "The Network is The Computer"), I'll say that the "Description is the Implementation". This only becomes completely true if you think of all of the policy enforcement apparatus as an extension of the service. I'll let you ponder the zen of that, but lets move on. This suggests something kind of interesting also--that many of the descriptions can be embedded in declarative or metadata form. Examples of these descriptions include of course WSDL, but also WS- CDL, WS-BPEL and other intriguingly parseable forms. In addition, Infravio adds policy description via JSR94 rules as well as an identity based policy enforcement construct we call "Service Delivery Contracts". I mention these because they are extensions of service description which are also declarative XML constructs. So what gets interesting is when the descriptions are parseable and interpretable not just by enforcement systems, but also by discovery systems. Since the best description of a service semantic is the implementation, the implementations themselves should be parseable. I know Radovan is very pro the use of XQuery for this kind of parsing, and of course this seems very sensible for this type of use case. Obviously the service implementations written in compiled languages are a bit harder to parse in such a way, although bytecode instrumentation and other virtualized container technology might enable us to see the implementation of those types of services as well. So I'm going to sign off by saying that service description is non trivial, and dependent on role, use case, and what value the constituency is trying to derive from the service. Many of the descriptions of the service require some form of policy enforcement mechanism, and also some form of metadata repositing system. For posterity, I will also post this text on my blog at http://www.soacenter.com Miko --- In [email protected], Jan Algermissen <[EMAIL PROTECTED]> 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 <*> 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/
