Date:
August 10, 2005 3:50:32 PM EDT
Subject:
Re: [soa-rm] Definition(s) of
"service"
Thank you for owning this! Good
luck next week.
May I suggest that the Editors use the WIKI page during their meeting?
I hate to say this (and my fellow co-editors may disagree) but I think
the task needs to be taken on by the editing team as a whole. My SOA mailbox has over 2300 messages with
many threads having a bearing on this, and even a cursory scan will be a
significant effort. Also, as the
current designated editor for the service section, I don't see a good way of
just dumping it onto someone else.
I would be willing to be talked out of this position.
At 12:25 PM 8/9/2005, Duane Nickull wrote:
I would like to request a volunteer or volunteers to own this issue and
ensure that none of the depth of this conversation is lost. We have passed around heaps of good
thoughts. The owner would essentially
be responsible for capturing the views / opposing views and keeping
documentation up to date as this gets discussed. The owner would not be entitled to simply
gloss over with their own point of view but would act much like an editor -
reflecting the consensus or the TC or noting the lack thereof.
Anyone interested in owning this?
I strongly resist the tendency of equating service with the 'back end
capability' (or whatever). This is a dangerous and non-scalable
1. The implementation of a service is none of the service consumer's
2. The service consumer should not even be able to figure out how a
service is delivered. If it can, then you will get security risks and/
or scalability issues
3. A given capability may not be fully exposed in a given service
4. A given service provider agent may not *have* the capability
offered in its service -- it may know someone who knows ... it may
not be possible to characterize the capabilities of a service provider.
5. From the point of view of the service consumer, fundamentally, it
cannot (normally) distinguish the surface aspects of interacting with
a service and the deeper aspects that rely on the service's
realization (e.g. this is an Oracle database so be careful with your
On the other hand, the service consumer interacts with a service in
order to achieve an effect. In most interesting cases this is a 'real-
world effect'. The consumer is interested in the fact that the bank
account has been credited.
Interestingly, these real world effects can *also* be expressed in
public semantic terms -- without relying on representing the internal
state of the resource. For example, a bank customer wants to know
that his or her account has a certain balance. This is a fact that is
warranted by the bank; not simply by the database resource that the
bank happened to use to store the account information. I.e., there is
a public 'on-the-wire' assertion that the bank attests whenever a
authorized request (again, note the on-the-wire nature of this) is
made to the appropriate bank service.
On Aug 8, 2005, at 3:02 PM, Chiusano Joseph wrote:
-----Original Message-----
Sent: Monday, August 08, 2005 5:50 PM
Subject: RE: [soa-rm] Definition(s) of "service"
As appeared earlier in this thread, there are contexts in
which it is not necessary to discriminate between the
capability and the service that accesses it,
Ken, are you equating capability with resource? I recall a reference to
resource that fits the above description, but not one to capability.
discussion of service can make this clear. However, I think
this thread has also shown ample examples of where the
service and the capability are clearly separate concepts and
where it may be useful to allow that difference to be
captured. For example, it is
likely for someone to ask if
two services are the same. While
we do not address that
particular question, it is far simpler to handle if we know
whether the underlying capability is the same than if we
obscure that difference at first principles.
At 05:03 PM 8/8/2005, Chiusano Joseph wrote:
-----Original Message-----
Sent: Monday, August 08, 2005 12:10 PM
Subject: Re: [soa-rm] Definition(s) of "service"
This is going in a weird direction.
I believed that there was significant consensus that the
service that we are interested in *is* the
interface/boundary/offering.
The capability behind the service -- that which makes the service
possible -- is private and out of bounds. That capability
way, best described using agent terminology.
Respectful non-concur. IMHO, the service *is* the
service *has* an interface through which interaction with that
capability may be possible.
On Aug 8, 2005, at 8:50 AM, Ken Laskey wrote:
This is good because it highlights the bits of
to explain our way around.
The user interface is the facade through which the user
a service (i.e. inputting information/requests, viewing
results) but there may be delivery capabilities that
through relevant services and the delivery capabilities are the
mechanisms through which results are packaged and sent to the
requester/consumer. For
example, if I make a request for
as part of that request, information about my connectivity is
provided, logic (capability) can be executed (possibly
a service) to decide which delivery mechanism is most
(e.g. high res or low res, what kind of compression, ...).
At 11:18 AM 8/8/2005, Michael Stiefel wrote:
Actually, I think two things are being confused here.
There is one service being used by several different
The user interface (i.e. the actually delivery mechanism)
of the service, or strictly speaking part of the SOA.
At 10:43 AM 8/8/2005, Ken Laskey wrote:
I'd have to think about this further but in general I
The underlying capability is making pizza and offering
for sale. The mechanisms for
accessing the capability are in
person, by phone, online. Note,
the capability existed
was online ordering and this is just another
a capability that already existed.
Interestingly from an orchestration/choreography sense,
of the pizza (in person pickup, delivery service from
third-party delivery (e.g. Takeout Taxi around
here)) constitutes another set of capabilities that can
interfaces and can be combined in response to invoking
service. All of these can be
used for delivery of things
pizza (even the pizza place might also deliver sandwiches).
I think part of the confusion is that a *physical*
is a millennia-old, longstanding capability that has
with SOA and is *not* the service in the SOA sense
different aspect of the S word.
Does this imply that if I order a pizza online vs. order a
pizza over the phone vs. order a pizza by walking into the
store, that these are all separate services?
-----Original Message-----
Sent: Thursday, August 04, 2005 12:35 PM
Subject: RE: [soa-rm] Definition(s) of "service"
This gets back to the previous discussion when we
resources, i.e to what extent the service is the
access (possibly coordinate) capability vs. when is it
I think any consideration of the service as the
At 11:07 AM 8/4/2005, Chiusano Joseph wrote:
-----Original Message-----
Sent: Thursday, August 04, 2005 11:04 AM
Subject: RE: [soa-rm] Definition(s) of "service"
Somehow saying service *provides* capabilities
motivation to provide an effective way to bring together
need to solve a problem. Integration
is often
that exist for their own purposes. Service
can help
the challenge is to make use of the tools/resources/
that already exist, not to create new stovepipes.
service provides all this is a tempting
will trivialize the concepts most in need of
Agree - and I should clarify that I was merely saying that a
provides capabilities (in general). Combining a
capability there, here a capability, there a capability,
capability (oops sorry - that's the EIEIO song), we
At 10:35 AM 8/4/2005, Chiusano Joseph wrote:
-----Original Message-----
Sent: Thursday, August 04, 2005 10:18 AM
Subject: RE: [soa-rm] Definition(s) of "service"
I'd still like to emphasize service as the access to
capabilities for which there are extra-service
their existence and requirements for use of the
"A service is a mechanism to enable access
I would say that access control mechanisms enable such
the service *provides* the capabilities. Note: Use of
is too concrete for our RM - I stated it only to
where the access is provided using a prescribed
exercised consistent with constraints and policies as
the service description."
Just trying to sort through this; some common themes
A service provides capabilities.
A service is accessible. (If this is true, then
verb.) A service has an interface. (If this is true,
a boundary.) A service interface is
interface are distinct, and the interface has
I'm not sure this is true, the interface may
sure it has rules. In fact,
I'm inclined to
defines the rules for accessing the service. Which
to suggest that the service interface is more than a
data model, but also of the policies
A service is a set of behaviors. (Not
sure I'm on
something about behaviors doesn't sit well.)
Given this, perhaps something like:
"A service is a bounded set of capabilities that are
P.S. I think this definition might just be
the service offer/contract discussion also.
-----Original Message-----
Sent: Thursday, July 28, 2005 12:32 PM
Subject: RE: [soa-rm] Definition(s) of "service"
While I believe that the previously proposed
I offer the following as a compromise.
"capabilities" addresses your issue of
"A service is a set of behaviors to provide
-----Original Message-----
Sent: Thursday, July 28, 2005 10:10 AM
Subject: Re: [soa-rm] Definition(s) of "service"
I hesitate to spoil this party ... but I'm
1. There is a distinction between action and result.
roboticist) Behaviour sounds a child
discernible effect. Computer Scientists have a
the purely technical aspects of their work: bytes
at random within hopefully enormous memories.
2. Also, we have to bear in mind that nobody invests
even 100's of them) in systems that
business payoff. I think that we have to directly
reason that services are deployed. 3. One of the
best practice aspects of SOAs is
and 'separation' between the providers of
services leads to more scalable and robust
All of the above is fuzzy language; but, at the
is a set of behaviors accessible via a prescribed
sounds a lot like bureauspeak.
I believe that there is strong consensus on the
a. The concept of service is 'at the
providers and consumers. b. The service is
the engine that performs the tasks.
c. There is a reason for using a service.
d. There is a lot of extra metalogical information
make it possible for third parties to
I, for one, would prefer a strongly anglo-saxon
definition of service that speaks to these points.
--------------------------------------------------------------
| MITRE Corporation, M/S H305 phone:
| 7515 Colshire Drive fax:
--------------------------------------------------------------
--------------------------------------------------------------
| MITRE Corporation, M/S H305 phone:
| 7515 Colshire Drive fax:
--------------------------------------------------------------
-------------------------------------------------------------------
| MITRE Corporation, M/S H305 phone:
| 7515 Colshire Drive fax:
-------------------------------------------------------------------
--------------------------------------------------------------------
| MITRE Corporation, M/S H305 phone: 703-983-7934
|
| 7515 Colshire Drive fax:
--------------------------------------------------------------------
--------------------------------------------------------------------
| MITRE Corporation, M/S H305 phone: 703-983-7934
|
| 7515 Colshire Drive fax:
--------------------------------------------------------------------
--------------------------------------------------------------
| MITRE Corporation, M/S H305 phone: 703-983-7934
|
| 7515 Colshire Drive fax:
--------------------------------------------------------------
---------------------------------------------------------------------------------
| MITRE Corporation, M/S H305 phone: 703-983-7934
|
| 7515 Colshire Drive fax: 703-983-1379
|
----------------------------------------------------------------------------------