[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
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.”
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).”
“…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.”
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.
---------------------------------------------------------------------------
MITRE Corporation, M/S
H305
phone: 703-983-7934
7515 Colshire
Drive
fax: 703-983-1379