OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-editors message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [soa-rm-editors] Fwd: [soa-rm] Definition(s) of "service"


This isn't about us answering back to the TC on our work plan but us figuring out how to tackle the problem.  If we are successful, the TC sees the benefit from us organizing the material in a way they can comment easily and, if necessary, vote.  Duane's request is reasonable and probably necessary but not trivial.

That's what I had in mind.

Ken

At 10:29 AM 8/11/2005, Matthew MacKenzie wrote:
We need not respond.  We do what we want.
 
Iím not going to take notes at the editors meeting for the TCís benefitÖthe product of the meeting should speak for itself, no?
 

From: Ken Laskey [ mailto:klaskey@mitre.org]
Sent: Wednesday, August 10, 2005 11:22 PM
To: soa-rm-editors@lists.oasis-open.org
Subject: [soa-rm-editors] Fwd: [soa-rm] Definition(s) of "service"
 
So,how do we respond to this?
 
The wiki may help on this but I think one of the topics at the editors' mtg may be how to glean key thoughts from an overactive email list, using the service definition as a first challenge.
 
Ken
 
Begin forwarded message:


From: Duane Nickull <dnickull@adobe.com>
Date: August 10, 2005 3:50:32 PM EDT
To: Ken Laskey <klaskey@mitre.org>
Cc: soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Definition(s) of "service"
 
 
Ken:
 
Thank you for owning this! Good luck next week.
 
May I suggest that the Editors use the WIKI page during their meeting?
 
Duane
 
Ken Laskey wrote:
 


Duane,
 
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.
 
Ken
 
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?
Duane
 
 
 
Frank McCabe wrote:
 


I strongly resist the tendency of equating service with the 'back end
capability' (or whatever). This is a dangerous and non-scalable
direction to go in:
 
1. The implementation of a service is none of the service consumer's
business.
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
SQL)
 
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.
 
 
Frank
 
 
On Aug 8, 2005, at 3:02 PM, Chiusano Joseph wrote:
 


-----Original Message-----
From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: Monday, August 08, 2005 5:50 PM
To: soa-rm@lists.oasis-open.org
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.
 
Joe
 
Joseph Chiusano
Booz Allen Hamilton
O: 703-902-6923
C: 202-251-0731
Visit us online@ http://www.boozallen.com
 
 


and our
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.
 
Ken
 
At 05:03 PM 8/8/2005, Chiusano Joseph wrote:
 


-----Original Message-----
From: Frank McCabe [ mailto:frank.mccabe@us.fujitsu.com]
Sent: Monday, August 08, 2005 12:10 PM
To: Ken Laskey
Cc: soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Definition(s) of "service"
 
This is going in a weird direction.
I believed that there was significant consensus that the
 
 
 
notion of
 


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
 
 
 
is, by the
 


way, best described using agent terminology.
 
 
 
Respectful non-concur. IMHO, the service *is* the
 
 
capability, and the
 


service *has* an interface through which interaction with that
capability may be possible.
 
Joe
 
Joseph Chiusano
Booz Allen Hamilton
O: 703-902-6923
C: 202-251-0731
Visit us online@ http://www.boozallen.com
 
 


Frank
 
On Aug 8, 2005, at 8:50 AM, Ken Laskey wrote:
 
 


This is good because it highlights the bits of
 
 
 
confusion we have
 


to explain our way around.
 
The user interface is the facade through which the user
 
 
interacts with
 


a service (i.e. inputting information/requests, viewing
results) but there may be delivery capabilities that
 
 
 
are invoked
 


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
 
 
an image and
 


as part of that request, information about my connectivity is
provided, logic (capability) can be executed (possibly
 
 
invoked through
 


a service) to decide which delivery mechanism is most
 
 
 
appropriate
 


(e.g. high res or low res, what kind of compression, ...).
 
Ken
 
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
 
 
 
applications.
 


The user interface (i.e. the actually delivery mechanism)
 
 
 
is not part
 


of the service, or strictly speaking part of the SOA.
 
Michael
 
At 10:43 AM 8/8/2005, Ken Laskey wrote:
 
 


I'd have to think about this further but in general I
 
 
 
would say yes.
 


The underlying capability is making pizza and offering
 
 
 
the product
 


for sale. The mechanisms for accessing the capability are in
person, by phone, online. Note, the capability existed
 
 
 
before there
 


was online ordering and this is just another
 
 
 
mechanism to access
 


a capability that already existed.
Interestingly from an orchestration/choreography sense,
 
 
 
the delivery
 


of the pizza (in person pickup, delivery service from
 
 
 
pizza place,
 


third-party delivery (e.g. Takeout Taxi around
here)) constitutes another set of capabilities that can
 
 
 
have service
 


interfaces and can be combined in response to invoking
 
 
 
the ordering
 


service. All of these can be used for delivery of things
 
 
 
other than
 


pizza (even the pizza place might also deliver sandwiches).
 
I think part of the confusion is that a *physical*
 
 
 
delivery service
 


is a millennia-old, longstanding capability that has
 
 
 
nothing to do
 


with SOA and is *not* the service in the SOA sense
 
 
 
but it uses a
 


different aspect of the S word.
 
Ken
 
At 07:11 PM 8/7/2005, joe@pantella.net wrote:
 
 


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?
 
--JJP
 
-----Original Message-----
From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: Thursday, August 04, 2005 12:35 PM
To: soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] Definition(s) of "service"
 
 
This gets back to the previous discussion when we
 
 
 
talked about
 


resources, i.e to what extent the service is the
 
 
 
mechanism to
 


access (possibly coordinate) capability vs. when is it
 
 
 
considered
 


the capability itself.
 
I think any consideration of the service as the
 
 
 
capability/resource
 


should be very limited.
 
Ken
 
At 11:07 AM 8/4/2005, Chiusano Joseph wrote:
 


-----Original Message-----
From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: Thursday, August 04, 2005 11:04 AM
To: Chiusano Joseph; soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] Definition(s) of "service"
 
Somehow saying service *provides* capabilities
 
 
 
misses the SOA
 


motivation to provide an effective way to bring together
the
 
 
 
parts I
 


need to solve a problem. Integration is often
 
 
 
of disparate
 


parts
 


that exist for their own purposes. Service can help
 
 
 
coordinate but
 


the challenge is to make use of the tools/resources/
 
 
 
capabilities
 


that already exist, not to create new stovepipes.
 
 
 
Saying the
 


service provides all this is a tempting
 
 
 
simplification but
 


I
 
 
 
fear it
 


will trivialize the concepts most in need of
 
 
 
clarification.
 


 
Agree - and I should clarify that I was merely saying that a
 
 
service
 


provides capabilities (in general). Combining a
 
 
 
capability here, a
 


capability there, here a capability, there a capability,
 
 
everywhere a
 


capability (oops sorry - that's the EIEIO song), we
 
 
 
have composite
 


capabilities.
 
Joe
 
Joseph Chiusano
Booz Allen Hamilton
O: 703-902-6923
C: 202-251-0731
Visit us online@ http://www.boozallen.com
 
 


Ken
 
At 10:35 AM 8/4/2005, Chiusano Joseph wrote:
 


-----Original Message-----
From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: Thursday, August 04, 2005 10:18 AM
To: soa-rm@lists.oasis-open.org
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
 
 
 
motivations for
 


their existence and requirements for use of the
 
 
 
capabilities
 


that must be
 
 
 
navigated
 


by the service. Thus,
 
"A service is a mechanism to enable access
 
 
 
to a set of
 


capabilities,
 


 
I would say that access control mechanisms enable such
 
 
access, and that
 


the service *provides* the capabilities. Note: Use of
 
 
"access control"
 


is too concrete for our RM - I stated it only to
illustrate
 
 
the point.
 


 
Joe
 
Joseph Chiusano
Booz Allen Hamilton
O: 703-902-6923
C: 202-251-0731
Visit us online@ http://www.boozallen.com
 
 


where the access is provided using a prescribed
 
 
 
interface and is
 


exercised consistent with constraints and policies as
 
 
 
specified by
 


the service description."
 
Ken
 
At 11:15 PM 8/3/2005, joe@pantella.net wrote:
 
 


Just trying to sort through this; some common themes
 
 
 
that seem to
 


be
acceptable:
 
A service provides capabilities.
A service is accessible. (If this is true, then
service
 
 
 
cannot be a
 


verb.) A service has an interface. (If this is true,
 
 
 
then a
 


service has
 


a boundary.) A service interface is
 
 
 
prescribed. (Then
 


a
 
 
service and its
 


interface are distinct, and the interface has
 
 
 
associated rules.
 


I'm not sure this is true, the interface may
 
 
 
describe the
 


rules,
 
 
but Im not
 


sure it has rules. In fact, I'm inclined to
 
 
 
suggest that
 


the interface
 


defines the rules for accessing the service. Which
 
 
 
would lead me
 


to suggest that the service interface is more than a
 
 
specification of the
 


data model, but also of the policies
 
 
 
associated with
 


the
 
 
 
service.)
 


A service is a set of behaviors. (Not sure I'm on
board
 
 
 
with this,
 


something about behaviors doesn't sit well.)
 
Given this, perhaps something like:
 
"A service is a bounded set of capabilities that are
 
 
accessible through
 


a prescribed interface."
 
 
-- JJP
 
P.S. I think this definition might just be
 
 
 
flexible enough
 


to navigate
 


the service offer/contract discussion also.
 
 
-----Original Message-----
From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com ]
Sent: Thursday, July 28, 2005 12:32 PM
To: Frank McCabe; SOA-RM
Subject: RE: [soa-rm] Definition(s) of "service"
 
 
Frank,
 
While I believe that the previously proposed
 
 
 
definition is
 


sufficient,
 


I offer the following as a compromise.
 
 
 
Hopefully, the
 


notion of
 


"capabilities" addresses your issue of
 
 
 
needing to get
 


things done.
 


 
"A service is a set of behaviors to provide
capabilities
 
 
accessible via
 


a prescribed interface."
 
Ron
 
 
-----Original Message-----
From: Frank McCabe
[ mailto:frank.mccabe@us.fujitsu.com]
Sent: Thursday, July 28, 2005 10:10 AM
To: SOA-RM
Subject: Re: [soa-rm] Definition(s) of "service"
 
 
I hesitate to spoil this party ... but I'm
 
 
 
going to :)

 


 
1. There is a distinction between action and result.
 
 
 
(Just ask any
 


roboticist) Behaviour sounds a child
 
 
 
misbehaving with no
 


discernible effect. Computer Scientists have a
tendency
 
 
 
to focus on
 


the purely technical aspects of their work: bytes
 
 
 
shuffling around
 


at random within hopefully enormous memories.
2. Also, we have to bear in mind that nobody invests
 
 
millions of $s (or
 


even 100's of them) in systems that
 
 
 
contemplate their
 


navels
 


or have no
 


business payoff. I think that we have to directly
 
 
 
address the
 


reason that services are deployed. 3. One of the
 
 
 
movitating
 


best practice aspects of SOAs is
 
 
that clarity
 


and 'separation' between the providers of
 
 
 
services and the
 


consumers of
 


services leads to more scalable and robust
 
 
 
architectures.
 


 
All of the above is fuzzy language; but, at the
 
 
 
same time,
 


"A service
 


is a set of behaviors accessible via a prescribed
 
 
 
interface."
 


sounds a lot like bureauspeak.
 
I believe that there is strong consensus on the
 
 
 
following
 


characteristics:
a. The concept of service is 'at the
 
 
 
boundary' between
 


service
 


providers and consumers. b. The service is
 
 
 
'there' to get
 


things done; but doesn't
 
 
itself denote
 


the engine that performs the tasks.
c. There is a reason for using a service.
d. There is a lot of extra metalogical information
about
 
 
services that
 


make it possible for third parties to
 
 
 
develop partners
 


for services.
 


 
I, for one, would prefer a strongly anglo-saxon
 
 
 
phrasing of the
 


definition of service that speaks to these points.
 
Frank
ti
 
 
 
--
 
 
 
 
 
--------------------------------------------------------------
 


-------------------
/ Ken
Laskey
\
| MITRE Corporation, M/S H305 phone:
 
 
 
703-983-7934 |
 


| 7515 Colshire Drive fax:
703-983-1379 |
\ McLean VA 22102-7508
/
 
 
 
 
 
--------------------------------------------------------------
 


--------------------
 
 
 
 
 
 
--
 
 
 
--------------------------------------------------------------
 


-------------------
/ Ken
Laskey
\
| MITRE Corporation, M/S H305 phone:
 
 
 
703-983-7934 |
 


| 7515 Colshire Drive fax:
703-983-1379 |
\ McLean VA 22102-7508
/
 
 
 
--------------------------------------------------------------
 


--------------------
 
 
 
 
 
 
--
 
 
 
 
-------------------------------------------------------------------
 


--------------
/ Ken
Laskey
 
 
 
 
 


\
| MITRE Corporation, M/S H305 phone:
 
 
 
703-983-7934 |
 


| 7515 Colshire Drive fax:
703-983-1379 |
\ McLean VA
22102-7508 /
 
 
 
 
-------------------------------------------------------------------
 


---------------
 
 
 
 
-
 
 
 
--
 
 
 
 
--------------------------------------------------------------------
 


-------------
/ Ken
Laskey
 
 
 
 
 


\
| MITRE Corporation, M/S H305 phone: 703-983-7934 |
| 7515 Colshire Drive fax:
703-983-1379 |
\ McLean VA
22102-7508 /
 
 
 
 
--------------------------------------------------------------------
 


--------------
 
 
 
 
 
 
 
--
 
 
 
 
 
--------------------------------------------------------------------
 


--
 


-----------
/ Ken
Laskey
 
 
 
 


\
| MITRE Corporation, M/S H305 phone: 703-983-7934 |
| 7515 Colshire Drive fax:
703-983-1379 |
\ McLean VA
22102-7508 /
 
 
 
 
 
--------------------------------------------------------------------
 


--
 


------------
 
 
 
 
 
 
 
 
--
 
--------------------------------------------------------------
-------------------
/ Ken
Laskey
\
| MITRE Corporation, M/S H305 phone: 703-983-7934 |
| 7515 Colshire Drive fax:
703-983-1379 |
\ McLean VA 22102-7508
/
 
--------------------------------------------------------------
--------------------
 
 
 
 
 
--
---------------------------------------------------------------------------------
/ Ken Laskey \
| MITRE Corporation, M/S H305 phone: 703-983-7934 |
| 7515 Colshire Drive fax: 703-983-1379 |
\ McLean VA 22102-7508 /
----------------------------------------------------------------------------------
 
 
 
 
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
 


 

--
     ---------------------------------------------------------------------------------
  /   Ken 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]