[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-editors] Fwd: [soa-rm] Definition(s) of "service"
Concur - it was only a suggestion but if it creates unnecessary work, it is not worth it. D Matthew MacKenzie wrote: > We need not respond. We do what we want. > > I’m not going to take notes at the editors meeting for the TC’s > benefit…the product of the meeting should speak for itself, no? > > ------------------------------------------------------------------------ > > *From:* Ken Laskey [mailto:klaskey@mitre.org] > *Sent:* Wednesday, August 10, 2005 11:22 PM > *To:* soa-rm-editors@lists.oasis-open.org > *Subject:* [soa-rm-editors] Fwd: [soa-rm] Definition(s) of "service" > > So,how do we respond to this? > > The wiki may help on this but I think one of the topics at the > editors' mtg may be how to glean key thoughts from an overactive email > list, using the service definition as a first challenge. > > Ken > > Begin forwarded message: > > > > *From: *Duane Nickull <dnickull@adobe.com <mailto:dnickull@adobe.com>> > > *Date: *August 10, 2005 3:50:32 PM EDT > > *To: *Ken Laskey <klaskey@mitre.org <mailto:klaskey@mitre.org>> > > *Cc: *soa-rm@lists.oasis-open.org <mailto:soa-rm@lists.oasis-open.org> > > *Subject: **Re: [soa-rm] Definition(s) of "service"* > > Ken: > > Thank you for owning this! Good luck next week. > > May I suggest that the Editors use the WIKI page during their meeting? > > Duane > > Ken Laskey wrote: > > > > 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 >>>>>> <mailto: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 <mailto: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 >>>>>>>> <mailto: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 / > > ---------------------------------------------------------------------------------- > > > 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]