Miko- We're thinking along the same lines. I've posted an even more in depth response on my blog. My mind couldn't stop going on this one. I even pulled in some thought on EDA and BPM.
http://www.biske.com/blog/?p=32 -tb On Feb 24, 2006, at 11:54 AM, miko_68 wrote: > 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 > > > > > > 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/
