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 <[email protected]>
*To:* [email protected]
*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
<mailto:service-orientated-architecture%40yahoogroups.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, <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
