[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Definition(s) of "service"
> -----Original Message----- > From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com] > Sent: Tuesday, August 09, 2005 11:56 AM > To: Chiusano Joseph > Cc: soa-rm@lists.oasis-open.org > Subject: Re: [soa-rm] Definition(s) of "service" > > I strongly resist the tendency of equating service with the > 'back end capability' (or whatever). So do I. Who said anything about "back end capability"?:) My reference was only to the capabilities of the service, or "what the service does". For example, a shoe shining service shines shoes (it has shoe shining capabilities), a car wash service washes cars (it has car wash capabilities), etc. I was thinking much higher-level. Joe Joseph Chiusano Booz Allen Hamilton O: 703-902-6923 C: 202-251-0731 Visit us online@ http://www.boozallen.com > 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]