[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 think I’m ok with this,
but there is some tweaking we need to do still. I’m thinking about
the “offered by a provider for a consumer” part. There is a
subtlety here that is important to get at, and that I believe you were
attempting to get at when you mentioned “accessed via a technology
nuetral interface” in a previous email. I think the basic idea is something
along the lines of “offered by a provider for a class of consumers”,
or “offered by a provider for a ‘generic consumer’” or
something along those lines. What we are getting at is that the service
is sort of generic in nature, it is not optimized for a particular customer. The way we “used to”
do things was to focus on the capability and do specific integrations as
necessary if anyone “else” wanted to make use of that
capability. With SOA, the emphasis is on the “offered to others”,
and all that that entails (especially when the “others” are part of
another ownership domain). That’s really what we were
trying to get at when using the term “mechanism to access a capability”.
I’ve been thinking about
this a *lot* because I realize that the definition that we currently
have in the RM has been distasteful for many, and I think has been the cause
for less adoption of the RM than we would have hoped. The concept is correct,
but the language has been a stumbling block. So ... if we can capture the
idea of “offering for the generic others” I think we will be in
good shape. Note also that the term
capability is really a potential for something, not the actual doing of
something. The noun “service” is the “performance of
duties or work for another”. Another definition has the “performance
of a function for another”. The term function may be more
applicable than capability, where capability speaks of the potential to do work
(capability: qualities, abilities, features,
etc., that can be used or developed; potential) and function speaks more of a
repeatable “chunk” of work. How’s this for a tweak? A service (in the context of
SOA) is a capability or function offered and packaged by a provider and made
accessible to consumers where access is provided using a prescribed interface
that abstracts (or hides) the implementation details of the capability or function,
and is exercised consistent with the contracts and policies as specified by its
description. From: Estefan, Jeff A (3100)
[mailto:jeffrey.a.estefan@jpl.nasa.gov] Colleagues, Now that some of the message
traffic has settled, here’s another update to the proposed SOA service
definition that should be closer to the mark while allowing for a little wiggle
room. A service (in the context of
SOA) is a capability offered by a provider for a consumer where access is
provided using a prescribed interface that abstracts (or hides) the
implementation details of the capability, and is exercised consistent with the
contracts and policies as specified by its description. Will follow up the threads after
the weekend. Regards... - Jeff |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]