[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Definition(s) of "service"
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 /
----------------------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]