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

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

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


Subject: Re: [soa-rm] Definition(s) of "service"


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


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