[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Definition(s) of "service"
I was thinking about this more and I'd basically agree with Michael
but I'm not sure the service consumer is the distinguishing
point. Try this: if you want to order a pizza by phone, the pizza
place provides both a local and an 800 number -- the two numbers are
different bindings to the same service.
(Note: when I first moved to the Washington DC area, it wasn't
unusual for businesses to have separate Virginia, Maryland, and DC
phone numbers so people wouldn't be put off by having to make a toll
call. The "service" they accessed was identical in all cases.)
(Second note: if the different phone numbers reached different
fulfillment contacts, these would represent different services, even
if they eventually made use of the same identifiable capabilities.)
Ken
At 06:09 PM 8/15/2005, Michael Stiefel wrote:
>I disagree. These are not bindings. These are three different
>applications that use the same service. We get into these problems
>if we forget about the Service Consumer.
>
>Michael
>
>At 05:56 PM 8/15/2005, Chiusano Joseph wrote:
>>Just got a thought on this thread from last week - original question
>>was:
>>
>> >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
>>
>>I would say no - these are separate bindings (akin to SOAP's various
>>bindings).
>>
>>Joe
>>
>>Joseph Chiusano
>>Booz Allen Hamilton
>>O: 703-902-6923
>>C: 202-251-0731
>>Visit us online@ http://www.boozallen.com
>>
>>
>> > -----Original Message-----
>> > From: Ken Laskey [mailto:klaskey@mitre.org]
>> > Sent: Monday, August 08, 2005 10:43 AM
>> > To: soa-rm@lists.oasis-open.org
>> > Subject: RE: [soa-rm] Definition(s) of "service"
>> >
>> > 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 /
----------------------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]