[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Definition(s) of "service"
I thought Michael was referring to the visual display, not the entity
that provides the access to the capability. Rereading what I said, I
can see where it starts getting confusing.
Ken
At 12:09 PM 8/8/2005, Frank McCabe wrote:
>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.
>
>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 /
----------------------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]