Re: [soa-rm] RE: Service definition at nauseum

[Rex Brooks <rexb@starbourne.com>]

Yup.

Cheers,
Rex

Hestand, Dan wrote:
> Rex,
>
> You just said something about composite services that made me stop and think. I never think of a composition/aggregation as something that requires knowing details of the service implementation. Primarily, I've always assumed this stance because if a detail changes and the composition relies on that changed detail, then the composite service would be invalid, nonfunctional, or incorrect. Did I interpret your statement correctly?
>
> Dan Hestand
> Lead Software Systems Engineer
> The MITRE Corp
> 781.271.3755
> phestand@mitre.org
>
>
> -----Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com] 
> Sent: Friday, April 23, 2010 4:25 PM
> To: Estefan, Jeff A (3100)
> Cc: soa-rm@lists.oasis-open.org
> Subject: Re: [soa-rm] RE: Service definition at nauseum
>
> Well said Jeff,
>
> I ran into this in the DM2 meeting today when I gave a cut down version 
> of this, saying that a SOA Service offered a capability according to a 
> contract and then added that the details were contained in the service 
> description but not necessarily revealed to an end user but might be to 
> another service provider for use in a composition or aggregation. What 
> was heard was "SOA Service offered a capability according to a 
> contract." Fortunately Dave and I took on the Action Item to clarify 
> that and a few other things, so we can convey our consensus.
>
> However the one sentence rule applies.
>
> Cheers,
> Rex
>
> Estefan, Jeff A (3100) wrote:
>   
>> Frank,
>>
>> Your right, however, the alternative would be to chunk up the formal 
>> definition into separate sentences, which I would ordinarily be OK 
>> with but clearly from our experience, the stakeholder community out 
>> there ends up adopting a one sentence definition. For example, if we 
>> simply defined a SOA service as a capability offered and stopped 
>> there, nobody would get the essence of what services means in the 
>> context of SOA.
>>
>> There are some key elements to our *service* (in the context of SOA) 
>> definition that it has to embody. One, is to articulate that a SOA 
>> service IS a capability offered by a provider for a consumer. Second, 
>> that access is provided using a prescribed *[service] interface* that 
>> abstracts (or hides) the implementation details of the capability. And 
>> finally, that it (the service) is exercised consistent with *contract* 
>> and *policy *constraints* *as specified by its *[service] description*.
>>
>> <SIDEBAR> The last sentence is a slight variation from my earlier 
>> proposed definition and could be worded using slightly better English. 
>> What I noticed missing from the original definition of service in the 
>> RM was the notion of *contract* and it originally stated "...constraints 
>> and policies..." and we know, of course, that contracts are key to ANY 
>> service paradigm, and that both contracts and policies are just 
>> specific types of constraints. If somebody could clean up the wording 
>> a bit, that would be great. Maybe it's OK as written above.</SIDEBAR>
>>
>> I'm OK if we chunk these key characteristics of the definition for SOA 
>> service into separate sentences but they MUST be articulated in such a 
>> way that the collective whole constitutes the formal definition of 
>> this very important core concept of the SOA paradigm.
>>
>> Cheers!
>>
>> - Jeff
>>
>>     
>
>   

-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670