Dennis, the phrase ""Though it initially acts as an instruction to the developers and testers, it is subsequently utilized by the service consumers and solution architects."" is on the page at this link: http://cbdi.wikispaces.com/Service+Specification
<<No, they don't need to share any low levels details about the service, they need to understand the semantics of the service specification>> Sorry, Dennis, I meant 'low levels details about the service' specification. << Also, the service specification is divided into different sections for different audiences>> We do not know this; this is not necessary!.. <<...there is a section with business-facing properties and another with technically oriented properties>> How we know which part, if it exists, is published, where and whom for? This is not more than a speculation at this point. As I said, Service Description may be derived form the Service Specification (in a particular case, it may be a part of it). What are we discussing here? Actually, I am aware of an example of such thing as 'unified' semantics: there are one initiative in Healthcare in the US and one initiative in the Oil and Gas Industry (US-UK). But more simple and standardised (by OASIS) solution is in the creation of multiple Service Descriptions (versions) of the same version of the service for different audiences, and publishing them in dedicated service registries (the service may be in a repository pointed by all these registrations). -- Michael ________________________________ From: Dennis Djenfer <[email protected]> To: [email protected] Sent: Sat, December 26, 2009 7:56:57 PM Subject: Re: [service-orientated-architecture] Re: Descriptions vs Contracts Michael Poulin wrote: > > >I think, one interesting aspect of service orientation is >berried in this CBDI phrase: use of the spec as a public description >requires much deeper shearing of the service semantics between the >service developers and " the >service consumers and solution architects". >This is a BIG problem! Do you have a link to that particular CBDI phrase? I couldn't find it on the page referred to by Lawrence. > >It limits abilities of the service providers to advertise the >service to different consumer societies, different audiences, and >different areas of Business. To be used in Business, the shared >semantics must be minimal and it is not any close to the development >vocabulary. Thus, I can conclude that the CBDI's approach (based on the >quote posted by Dennis) is good if "developers >and testers, ...service consumers and solution architects" >belong to the same society that shares all low level details about the >service. No, they don't need to share any low levels details about the service, they need to understand the semantics of the service specification. Also, the service specification is divided into different sections for different audiences, e.g. there is a section with business-facing properties and another with technically oriented properties. This >may cause problems even inside the same enterprise if it is large >enough (CORBA Object Trading Service has taught us hard lessons with >this regard). Agreed, but how do we write a service description that is understood by everyone? If a service description should be universally understood we must standardize the syntax and semantics of a service description, which is a huge undertaking. Unfortunately, I'm not aware of any such initiative at the moment. // Dennis Djenfer > >- Michael > > > ________________________________ From: >Dennis Djenfer <d...@algonet. se> >To: service-orientated- architecture@ yahoogroups. com >Sent: Fri, December >25, 2009 12:13:11 AM >Subject: Re: >[service-orientated -architecture] Re: Descriptions vs Contracts > > >Ok. In this case I think CBDI are using the specification both for >internal use by developers and for public use by service consumers. The >CBDI Wiki has the following to say about the Serice Specification: > >>"Though it initially acts as an instruction to the developers and >testers, it is subsequently utilized by the service consumers and >solution architects." > > >>// Dennis Djenfer > > > >>Michael Poulin wrote: > >...actually, the semantic of the name. To my knowledge, OASIS >>used term 'Service Description' to avoid term 'specification' . The >>former was viewed as publicly available 'specification' for the service >>consumers while actual service specification was meant for the internal >>use for the developers. (When Amazon >>>>- publishes PC specification, it is not the real one, it is dedicated >>to the buyers. So, instead of explaining which spec is meant, OASIS >>just used different term). >> >>- >>Michael >> >> ________________________________ From: >>Dennis Djenfer <d...@algonet. se> >>To: service-orientated- >>architecture@ yahoogroups. com >>Sent: Wed, December >>23, 2009 4:01:41 PM >>Subject: Re: >>[service-orientated -architecture] Re: Descriptions vs Contracts >> >> >>Michael Poulin wrote: >>It is very interesting and informative post, Lawrence! >>> >>> >>>Here is a little challenge (again): a service is built >>>against >>>its specification - documented or not. You can derive a public >>>announcement from this spec - Service Description. As Service >>>Description may have versions, as the service spec may have versions. >>>Together, this becomes difficult to manage (on the producer's side). >>>>What makes you believe that the Service Specification is not the same >>thing as a Service Description (except for the name)? >> >>>>// Dennis Djenfer >> >> >> >> >> >>> >>>"we >>>do find a lot of >>>reluctance to make this effort - particularly to make the investment if >>>such a registry/catalog isn't already in place, and as often as not " - is, >>>unfortunately , a common >>>place. We tried to fight it with IT Governance that treated each >>>service as an independent product, i.e. with full and maintained across >>>projects documentation. This, implicitly, answers the question - what >>>should be documented. Because of such governing policy, not many >>>components and RPCs were considered as services (in the end) - only the >>>ones that had particular and strong business/technical meaning. >>> >>> >>>SO as the concept and related Governance must prevent even >>>an >>>idea of shortcutting on service-consumer relationship - they must be >>>treated as independent in spite of any administrative/ management >>>ownership boundaries. This is why I position Architecture above >>>Management. The major principle during the service design >>>and implementation - no concrete assumptions of the future consumers ( >>>and, especially, who will command them); nothing more than a potential >>>category of them. If your team/management violates this principle, they >>>are not service-oriented yet. >>> >>> >>>- Michael >>> >>> >>> ________________________________ From: >>>LAWRENCE <l.wil...@btinternet >>>.com> >>>To: service-orientated- >>>architecture@ yahoogroups. com >>>Sent: Tue, >>>December >>>22, 2009 2:06:20 PM >>>Subject: >>>[service-orientated -architecture] Re: Descriptions vs Contracts >>> >>> >>> >>> >>>>>>--- In service-orientated- >>>architecture@ yahoogroups. com, Michael Poulin <m3pou...@.. .> wrote: >>>>>>> >>>>>>> As I guess, Lawrence, the service specification is an internal >>>document. While I fine with deriving Service Description from the >>>service spec, it would be interesting to know how you have resolved the >>>ownership issue of this specification; does it belong to IT or to >>>Business? Example: consumer provides the instructions and funds and the >>>service invests them accordingly; who is the custodian of the service >>>spec? >>> >>>>>>Our approach is to have a multi-facetted Service Specification that >>>addresses all audiences. As you don't want separate business and IT >>>specifications that drift out of synch, it is better to have them as >>>different properties of the same specification. (of course, that still >>>requires someone to keep the properties in synch - but common ones >>>should be shared, not duplicated) >>> >>>>>>As listed in our wiki, http://cbdi. >>>wikispaces. com/Service+ Specification, we have several sections in >>>our specification >>>>>>* Service properties that provides basic information on the status and >>>history of the service >>>>>>* Business properties that show how the Service supports the business, >>>and who in the business is responsible for the Service >>>>>>Technical properties that provide a more IT-centric view of the Service >>>>>>* Quality of service that is or should be offered by the Service - such >>>as the reliability or security requirements >>> >>>>>>And at the more detailed level >>>>>>* Functional behavior of the individual operations, including the >>>operation signature, together with the pre and post conditions that >>>must be met by the provider and consumer >>>>>>* Details on message exchange >>>>>>* A Service Information Model that details the information that is >>>stored or retrieved by the Service. >>> >>>>>>One of the key challenges though is where/how to document and store >>>such information. Ideally, a template such as ours should be turned >>>into a schema in some form of registry/catalog product - we have for >>>example worked with IBM WebSphere Service Registry and Repository, and >>>SAG Centrasite, and also Orbus Software iServer this year to provide >>>examples of this. It is well beyond the scope of UDDI, so clearly >>>requires some effort. >>> >>>>>>However, we do find a lot of reluctance to make this effort - >>>particularly to make the investment if such a registry/catalog isn't >>>already in place, and as often as not I believe our template just >>>becomes rows in an Excel spreadsheet. ... or pages on a wiki. >>> >>>>>>The other important question to ask is does every service need to be >>>documented to this extent? But this is a much the age old question of >>>do I really need to produce this much documentation as much as anything >>>else. >>>>>>Answers might be, well only if >>>>>>* there is true organizational separation of provider and consumer, or >>>specifier and implementor >>>>>>* it is a shared service - many consumers >>>>>>* the behavior is anything other than obvious (e.g. I think I can guess >>>that the UpdateCustomerPhone Number operation does - but then again, >>>can I? Does it validate the area code? does it allow international >>>numbers? never so simple...) >>> >>>>>>The difficulty then is what doesn't appear to need documenting today, >>>might do tomorrow. e.g. we never thought it would be shared - but it >>>was... >>> >>>>>>One of the things we are working on at the moment is to ensure that as >>>much as possible of our service specification template can be captured >>>in our UML profile, so at least the capture can be 'automated' to some >>>extent (in that properties can be infered from associations for >>>example, and transformations from UML to XML or WS-Protocols) >>> >>>>>>Process-wise, we don't see the Service Spec as something that is fully >>>developed in one pass. Rather it evolves from just description level >>>properties at the planning stage, through the detailed specification of >>>operations at the provisioning stage, to the addition of technical >>>run-time details once provised and deployed. But these are all 'views' >>>of the same asset - not different documents. Equally, new operations >>>may get added over time. >>> >>>>>>- Lawrence Wilkes, Everware-CBDI >>> >>> >>> >> >
