[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Service definition at nauseum (restarted)
Two important distinctions. First – One could identify the banking service, and one
could identify the savings service, checking service, loan service, etc.
The latter are “subsets” of the former, or one could say the former
is some sort of orchestration or aggregation of the latter. This is sort
of the “goals” that Frank is getting to. If we equate the
service and the capability, we run into this problem of “what, really, is
the service?” Second – as for equivalence. This, I think, is a *very*
difficult issue. Suppose we have a two banking services, one is offered
by Bank of America and the other is offered by BB&T. They are
functionally equivalent, the real-world effects are exactly the same, and the
interfaces and policies are exactly the same. When we say they are
equivalent, we are talking about ontological equivalence (these are both the
same banking services) but not actual equivalence (but one is offered by BoA,
and the other by BB&T). I suppose you could say the execution
contexts are different, because they are offered at two different end points,
and the capability being provided is being provided by different providers.
But now, suppose the BB&T banking service is offered at two different
endpoints, but accesses the same provider’s capability, are they
equivalent? They are certainly ontologically equivalent, but are they
actually equivalent? Not so sure. If we say the service IS the
capability, then the answer is “yes”, if we say the service is the
mechanism for accessing the capability, the answer is “no”. Back to Frank’s distinction of the ATM and the account
access service. Is each ATM a unique service, or is there just one
service (account access) and each ATM is something else (not sure what,
actually). Good discussion! From: Laskey, Ken [mailto:klaskey@mitre.org] Frank, A couple points in response: -
The fact that there is an underlying bank capability is of the
essence of my argument. Without it, there is no useful ATM service.
Unfortunately, I have seen too many attempts to build the ATM service without
the bank. -
To what extent does the bank capability disappear when the bank
lobby closes? I look at it as the capability to make a withdrawal exists
at 5:01 PM without an ATM, i.e. all the bank assets, bank records, and bank
processes exist, but there is no way to access that capability. In those
terms, I have lots of folks who when considering SOA for their problems can
define a useful service to provide access to a relevant capability. -
Any enhanced access brings more value to the capability and MAY
constitute a new business service. Finding an appropriate way to say that
seems to be at the core of our discussion. I think that is what you mean
by “The point being that a key part of the functionality may well
include the fact that the capability is accessed as a SOA service.”
And I think it is more than just packaging. I think the equivalence
discussion is interesting but, again, I suggest we avoid the diversion because
I don’t think it adds anything to the primary question. Ken From: Francis McCabe [mailto:fmccabe@gmail.com] Ken I agree that your definition
is a nice reconstruction of what has been going on in the thread. I need to
make a couple of responses though, because I think that you have not understood
my earlier comments. The fact that an ATM enables
access to an account at all times IS OF THE ESSENCE of the ATM service. The
fact that online banking enables access at home is similarly OF THE ESSENCE.
(Sorry for shouting) It is true that the capabilities offered are not the same;
but I do not think that it is a simple subset relationship. The point being that a key
part of the functionality may well include the fact that the capability is
accessed as a SOA service. I stress this because, as
software engineers, we are used to 'abstracting unnecessary details'. However,
one person's unnecessary details are absolute requirements for someone else.
So, I do not agree that one can say:
People in the packaging
industry will naturally understand this point I believe. Equivalence of services is a
useful tool for understanding them. It is obvious that two services are not
equivalent if the goals you are trying to achieve are not achievable with both
of them. However, taking the ATM example, an ATM is equivalent to online
banking and real teller if what you want to do get your current balance. They
are not equivalent if it it outside banking hours or you are trying to get
cash. Equivalence depends on your situation and the goals you are trying to
achieve. A more IT-ish example would be
accessing corporate email out of the office. One can use a VPN to access the
entire corporate network and then access email in the regular way. On the other
hand, the company might offer a webmail service to give you access to your
email. If your goal is to read
email then the two approaches are equivalent. If your goal is to link email
with your existing threads in your mail browser the two approaches are not the
same. The message is that,
depending on the requirements, the form of the service can be critical. With apologies to Macluhan,
"the medium is the service". Incidentally, I believe that
100% equivalence of services (where EVERY offered action is the same and the
MEANS OF ACCESS is the same) is pretty uninteresting. Even in automated service
discovery you do not want this; you are more interested in service equivalence
in relation to what you are trying to achieve. Finally, I am not at all
sure why we need:
specifically, I do not understand
why we need to say anything about how things are implemented. For me, this
would be enough:
Frank On Apr 25, 2010, at 2:32 PM,
Laskey, Ken wrote: [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]