OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Jeff, 
 I sympathize and agree with much of this.
 I have a couple of sticking points: I do not think that you should even mention technology neutrality. A given service may or may not be offered in a technology neutral way (somehow I think that all actual services will have actual technologies). From the SOA paradigm perspective, it is enough to say that the technology is not necessarily important.
 Similarly, while it may be good practice to hide implementation details, it is better to say that implementation details are not intrinsic to the concept of a SOA service.
 The caveat on descriptions is important. It is one of the characteristics of SOA that descriptions be appropriately available.
 I personally think that access is part of the service; even if we do not always want to see it.

 On a related thought, we can ask when two services are equal. This is critical when understanding when it is ok to use automated methods for discovery.
 One approach:
 Two services are equivalent for a given purpose and interaction scenario (provider and consumer) and set of goals when both services may be used to address the goals and when the service requirements (execution contexts) are equally satisfied.

Frank
On Apr 22, 2010, at 3:01 PM, Estefan, Jeff A (3100) wrote:

Colleagues,
 
After reading e-mail thread after e-mail thread and giving this some intense thought, here’s how I see it.
 
Starting with the base concept of service defined as follows (slightly paraphrased from CBDI SAE metamodel):
 
* A service in the general (notional) sense is a capability offered by a provider to a consumer according to a contract.
 
Caveats:
 
* A service IS a capability but a capability is NOT NECESSARILY a service (unless it is a service-enabled capability).
 
* A service may or may not expose the internal workings of the capability offered.
 
Therefore,
 
* A service (in the context of SOA, i.e., “SOA service”) [or any other paradigm for that matter] is a specialization of this more general notion of service.
 
This implies that:
 
* A SOA service IS NOT a mechanism.
 
* A SOA service IS NOT an interface.
 
* A SOA service IS NOT an interaction or connection point.
 
* A SOA service IS a capability!
 
These other concepts are all very important in capturing the dynamics and meta-level aspects of a SOA service, but they are not the service itself.
 
For the paradigm of SOA, we take the specialization of the general (notional) concept of service a step further:
 
* A SOA service is opaque to the implementation of the capability offered.
 
* A SOA service is accessed using a prescribed technology-neutral interface.
 
* A SOA service is exercised consistent with contracts and policies as specified by its description.
 
Now that we have that out of the way, let me suggest a more formal definition of SOA  service:
 
* A service (in the context of SOA) is a capability that is offered by a provider for a consumer where the implementations details of the capability offered is opaque to the consumer.  Its access is provided using a prescribed technology-neutral interface, and is exercised consistent with the contracts and policies as specified by its description.
 
The proposed definition above is close to what we provided in the RM but it’s not exactly the same.  The differences I have noted in bold text in the above bullet points and I purposefully dropped the introductory text on “mechanism” as well as a few repetitive words.
 
Perhaps we can make the minor adjustments in the RAF, but unless I see major objections, this is how I’m going to start talking referring to the core concept of service (in the context of SOA) with my constituents.  It is not that far off from the RM definition but I believe it is not only accurate, it is more precise.
 
Finally, while I think we all understand the subtle distinction between a service and a capability (i.e., a service IS a capability but not all capabilities are services), the attempt to distinguish a “SOA Service” from a “business service” is a red herring and it’s going to cause us nothing but headache in my opinion.  First, I have seen no evidence of a formal industry standard definition of what a business service actually is or what constitutes such a service.  To me, we would be better served if such a concept were referred to as “business capability” from which one could derive the notion of a “service-enabled business capability” but, again, I think this is just going to drive us down a big rat hole and I’d rather not go there – IMHO.
 
Regards…
 
 - Jeff E., NASA/JPL
 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]