[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Service definition at nauseum (restarted)
Should your new opening phrase
read: A service (in the context of SOA) is a capability that is exposed as a business function in the context
of the following constraints… This would qualify the (SOA) service,
rather than the capability… Peter From: Laskey, Ken [mailto:klaskey@mitre.org] [I tried collecting a bunch of
thoughts in a blank email but Outlook takes exception when I try to paste these
into a simple reply. So this is a continuation but will appear as a new
thread.] A collection of comments (that do
not address the composition part of the thread): Rex, Thu 4/22/2010 10:15 AM “… At the
Reference Model level, where the idea of means or mechanism is
problematic, I think we can say that a service is a capability” If we say this without
qualification, I think we lose an important point. From the RM: The service concept above emphasizes
a distinction between a capability that represents some functionality created
to address a need and the point of access where that capability is brought to
bear in the context of SOA. It is assumed that capabilities exist outside
of SOA. In actual use, maintaining this distinction may not be critical (i.e.
the service may be talked about in terms of being the capability) but the
separation is pertinent in terms of a clear expression of the nature of SOA and
the value it provides. Chris, Thu 4/22/2010 2:21 PM “We have to look at what
makes a ‘SOA Service’ different from what is not a ‘SOA
service’. Whatever definition we come up with should fail if
applied to a ‘non-SOA service’.” I think this is important because
a great deal of the confusion I see is people trying to apply SOA art when
their problem is really one of business process. If you keep the
distinction, it is much easier to push for a business solution before counting
on an IT implementation. Rex, Thu 4/22/2010 2:54 PM “I disagree with
"Whatever definition we come up with should fail if applied to a non-SOA
service." Our SOA definition must build from the root, not contradict
it.” The RM quote above gives a way to
relate the SOA service and the capability which is often the instantiation of
the business functionality. I don’t mind a SOA service falling
under the general definition of service, but we run into trouble if all
services can be considered SOA services. Frank, Thu 4/22/2010 3:13 PM “… there are
significant differences in the kinds of capabilities that can be accessed in
the different scenarios …” No, the RM says there is the same
capability but each service can expose a different subset. True, the
subset exposed by the ATM does not include processing a loan, although it could
be set up to do something akin to online pre-approval. It isn’t
that it can’t but more that it doesn’t. “…no interesting
definition of service can distinguish between electronically mediated and
physically mediated services …” But a basic premise of the RM is
we are talking about services in the software domain and not every possible
service. From the RM: While service-orientation may be
a popular concept found in a broad variety of applications, this reference
model focuses on the field of software architecture. The
concepts and relationships described may apply to other "service"
environments; however, this specification makes no attempt to completely
account for use outside of the software domain. “A SOA service is a service
that is accessed by message exchange across an electronic medium.” The RM, I believe at
Frank’s insistence, did not limit SOA to message exchange. To
quote: In many cases, this [interaction]
is accomplished by sending and receiving messages, but there are other modes
possible that do not involve explicit message transmission. Boris, Thu 4/22/2010 3:19 PM “Building an SOA
implementation through exposing a stovepipe functionality using service
interface is a very valid approach to building services.” Indeed. From the RM: There are no constraints on what
constitutes the underlying capability or how access is implemented by the
service provider. Rex, Thu 4/22/2010 3:59 PM “I don't see it as SOA vs
non SOA, but Service AND SOA Service.” Now this is a good starting point
for a distinction. Jeff, Thu 4/22/2010 6:01 PM “A SOA service is accessed
using a prescribed technology-neutral interface.” This, at a minimum, needs some
tweaking. A typical Web Service uses a SOAP interface. This is not
technology-neutral. Insisting it is, even in some abstract sense, will be
trouble. {I see Frank also commented on this.] “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.” I think I already agreed with
this. “A service IS a capability
but a capability is NOT NECESSARILY a service (unless it is a service-enabled
capability).” Ditto “…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 …” I tend to talk about the business
service as the business function supplied by the capability, i.e. the
capability provides the business service. Most people (at least in a
class setting) can deal with this and find the distinction makes sense.
The greater danger is still people who want to apply SOA to solve business
problems they do not understand. We need a first line of defense against
SOA pixie dust. Frank, Thu 4/22/2010 6:19 PM “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.” I would argue that equivalence of
service has nothing to do with goals. Two services are equivalent is they
provide the same real world effects when the interactions occur within the same
execution contexts. However, we still have the problem that there may be
“hidden” effects (i.e. not visible through shared state) that could
cause the two not to be equivalent. Nailing this down would be difficult
and is probably not something we want to tackle. Chris, Fri 4/23/2010 10:15 AM “offered
by a provider for a ‘generic consumer’” “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’.” Good concepts
to make sure we don’t lose, even though some wordsmithing is still
required. Dan, Fri 4/23/2010 10:28 AM “service
offered by a provider ‘as-is’ for market use” “…
the service is how that capability is realized …” Good
points that I think circle back to the original RM discussions. Kudos to
the new guy J Frank, Fri 4/23/2010 12:33 PM “These definitions are
starting to read like essays, not definitions.” J So I guess it is time for me to
take a crack. A service (in the context of
SOA) is a capability that exposes a business function in the context of the
following constraints: -
The service is offered and packaged by a provider
and made accessible to consumers -
access is provided using a prescribed interface that
abstracts (or hides) the implementation details of the capability or function,
and -
the service is exercised consistent with the
contracts and policies as specified by its description. In general, the specifics of
the business function should be known independent of the service that exposes
it. Ken --------------------------------------------------------------------------- Dr. Kenneth Laskey MITRE Corporation, M/S
H305
phone: 703-983-7934 7515 Colshire
Drive
fax: 703-983-1379 McLean VA 22102-7508 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]