[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] RE: Service definition at nauseum
|
Chris, I agree that we need to generalize
to a “category” of consumers, if you will. In one sense, it’s saying “service
offered by a provider ‘as-is’ for market use”. This gets at the non-specialized
nature of the service and also uses the concept of market segmentation which is
familiar to businesses. I’m not tied to the specific words but the “as-is”
concept is important. I also firmly believe that the
capability is not the service. Rather, the service is how that capability is
realized. In one case, the capability of withdrawing money from the bank is
realized through teller services and in another, realized through ATM services.
The distinction also gets at the governance/management relationship. Governance
and management in SOA Ecosystems is not applied to capabilities but to the
realization of those capabilities: how they are realized, how they are used,
how they are offered. Sort of like the Government doesn’t legislate what your
business can do but it does legislate how you can do it, offer it, and how
consumers can access it. My opinions… Dan Hestand Lead Software Systems Engineer The MITRE Corp 781.271.3755 phestand@mitre.org From: Bashioum, Christopher D
[mailto:cbashioum@mitre.org] 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]