[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] [Duane,need clarification] RE: [soa-rm] Amazon.comandHurricane Catrina - ServiceContext? Service "Veneer"?
I can actually understand Matt's tone, given that we have been through this question (is orchestration within our RM scope) over and over again. I think Matt was quite nice about it, actually. Joe Joseph Chiusano Booz Allen Hamilton O: 703-902-6923 C: 202-251-0731 Visit us online@ http://www.boozallen.com > -----Original Message----- > From: McGregor.Wesley@tbs-sct.gc.ca > [mailto:McGregor.Wesley@tbs-sct.gc.ca] > Sent: Thursday, September 08, 2005 11:23 AM > To: mattm@adobe.com > Cc: dnickull@adobe.com; Chiusano Joseph; soa-rm@lists.oasis-open.org > Subject: RE: [soa-rm] [Duane,need clarification] RE: [soa-rm] > Amazon.comandHurricane Catrina - ServiceContext? Service "Veneer"? > > Matt, > > I take exception to your tone. > > Each concept in the reference model must clearly define its > boundaries. Failure to do so will only have the work ignored > due to lack of clarity. > > You must remember that not all services are reusable nor > should they be. Just having a sound service description > available somewhere is enough in a lot of cases for initial > take-up and System of Record. > > We all strive for reusability, but in the majority of cases > it is very hard to create given the nature of the business > (especially in a government context). > > Wes > > > -----Original Message----- > From: Matthew MacKenzie [mailto:mattm@adobe.com] > Sent: September 8, 2005 11:06 AM > To: McGregor, Wesley > Cc: dnickull@adobe.com; chiusano_joseph@bah.com; > soa-rm@lists.oasis-open.org > Subject: Re: [soa-rm] [Duane,need clarification] RE: > [soa-rm] Amazon.comandHurricane Catrina - ServiceContext? > Service "Veneer"? > > First off, the RM should not care what you decide to feed > into your services. Even though it is bad form to require > services to understand operations outside of its scope (think > reusability), it is not our place as RM authors to discourage > bad architecture. > > Secondly, the whole idea of composite services and > orchestration is out of scope. People, we have to get beyond > this fixation with particular architectures, it is getting > tiresome and is not helping us get to our goal of publishing > an RM. And I'll throw in a note about orchestration: > IT IS THE ORCHESTRATOR'S JOB TO MANAGE STATE! This can be > done without passing that state between each step of the > orchestration. Think about the inherent orchestration > involved in shipping a container from Singapore to Boise, > Idaho. Does the crane operator in Singapore who is dropping > the container onto a ship care that the box is destined for > Idaho? Hell no. He is told: ContainerA -> Ship1. When the > ship hits San Fran or wherever, the container number is > delivered to its owner, who then figures out where it has to > go. It is important that in a disconnected, service oriented > world that state be avoided wherever possible so that > services can be reused and included in diverse > orchestrations. NONE of this really matters to the RM, only the RAs. > > -matt > > McGregor.Wesley@tbs-sct.gc.ca wrote: > > >Respectfully I disagree. > > > >You are stating that a service MUST NOT have any input that > is state oriented. I believe that notion is too strict and > hence the usage of the term SHOULD is more appropriate. > > > >By saying MUST NOT implies that any derived architecture and > their services can NEVER have a state as input which would > render a lot of collaboration services impossible. > Intra-enterprise services which can greatly benefit from > state-based input could never exist then. > > > >I would allow for MUST NOT (greater restriction) on an RA > but SHOULD (open ended) on an RM. > > > >Wes > > > > > > -----Original Message----- > >From: Duane Nickull [mailto:dnickull@adobe.com] > >Sent: September 7, 2005 5:15 PM > >To: McGregor, Wesley > >Cc: chiusano_joseph@bah.com; soa-rm@lists.oasis-open.org > >Subject: Re: [soa-rm] [Duane, need clarification] RE: > [soa-rm] Amazon.comandHurricane Catrina - Service Context? > Service "Veneer"? > > > >Wes: > > > >There is a differentiator. A service may be designed and > configured to > >support an orchestration. It may even be split into two services to > >support commit and rollback functionality. However, at the time it > >gets called, it has no notion (state) what lies beyond its' event > >horizon (its' interface/service/action boundary etc). > > > >Duane > > > > > >McGregor.Wesley@tbs-sct.gc.ca wrote: > > > > > > > >>I would argue that the Service Description allows for the > possibility that this information can be made requisite. > >> > >>The Service Description is vague enough at this point not > to preclude it. Thus the word SHOULD is appropriate. > >> > >>-----Original Message----- > >>From: Duane Nickull [mailto:dnickull@adobe.com] > >>Sent: September 6, 2005 6:08 PM > >>To: Chiusano Joseph > >>Cc: soa-rm@lists.oasis-open.org > >>Subject: Re: [soa-rm] [Duane, need clarification] RE: > [soa-rm] Amazon.com andHurricane Catrina - Service Context? > Service "Veneer"? > >> > >>Joseph et al: > >> > >>This is partially true. Orchestration of multiple services is not > >>something that will be a normative component of the RM, > however it may > >>be mentioned for illustration purposes. See Vancouver meeting notes > >>for more details. > >> > >>There are many reasons for this. Services themselves would not be > >>aware of whether they are being called as part of a larger > >>orchestration vs. a single request, nor should they. There is no > >>fundamental difference in the way a service may be called > that distinguish these two things. > >> > >>I am very tied up right now but we can table this for our next call > >>(Agenda pending). > >> > >>Duane > >> > >>Chiusano Joseph wrote: > >> > >> > >> > >> > >> > >>>Okey-dokey. I request clarification from the Chair at this > point for > >>>us all, please, on where orchestration fits in/will fit in > with our > >>>RM once our 12-month (per our charter) product is released. > >>>Joe > >>>Joseph Chiusano > >>>Booz Allen Hamilton > >>>O: 703-902-6923 > >>>C: 202-251-0731 > >>>Visit us online@ http://www.boozallen.com > <http://www.boozallen.com/> > >>> > >>> > -------------------------------------------------------------- > ---------- > >>> *From:* John Harby [mailto:jharby@gmail.com] > >>> *Sent:* Tuesday, September 06, 2005 1:14 PM > >>> *To:* soa-rm@lists.oasis-open.org > >>> *Subject:* Re: [soa-rm] Amazon.com and Hurricane > Catrina - Service > >>> Context? Service "Veneer"? > >>> > >>> I may have missed something several months ago but I would call > >>> that approach questionable at best. > >>> > >>> On 9/6/05, *Chiusano Joseph* < chiusano_joseph@bah.com > >>> <mailto:chiusano_joseph@bah.com>> wrote: > >>> > >>> John, > >>> I believe this was determined several months ago (I say that > >>> in a helpful way, not in a criticizing way). I don't believe > >>> we are limited at all in our capability to define service. > >>> It's just that we need to define certain "basic" aspects > >>> first, and have other TCs (or perhaps this one in a later > >>> phase) extend our RM to include capabilities such as > >>> orchestration. We've sometimes referred to this as a POA > >>> (Process-Oriented Architecture). > >>> Hang in there, we'll get there..... > >>> Joe > >>> Joseph Chiusano > >>> Booz Allen Hamilton > >>> O: 703-902-6923 > >>> C: 202-251-0731 > >>> Visit us online@ http://www.boozallen.com > >>> <http://www.boozallen.com/> > >>> > >>> > -------------------------------------------------------------- > ---------- > >>> *From:* John Harby [mailto:jharby@gmail.com > >>> <mailto:jharby@gmail.com>] > >>> *Sent:* Tuesday, September 06, 2005 12:44 PM > >>> > >>> *To:* soa-rm@lists.oasis-open.org > >>> <mailto:soa-rm@lists.oasis-open.org> > >>> *Subject:* Re: [soa-rm] Amazon.com > <http://Amazon.com> and > >>> Hurricane Catrina - Service Context? Service "Veneer"? > >>> > >>> I'm surprised that orchestration is out of > scope. I could > >>> understand how specifics such as BPEL > >>> would be out of scope but many people will call things > >>> services that are lorchestrations of other > >>> services. If orchestration is out of scope then are we > >>> limited in our capability to define "service"? > >>> > >>> On 9/6/05, *Chiusano Joseph* < chiusano_joseph@bah.com > >>> <mailto:chiusano_joseph@bah.com>> wrote: > >>> > >>> Emphasizing that orchestration is out of > scope for our > >>> RM (it's for another RM that can be built on top of > >>> ours), and speaking only of Web Services: I > would say > >>> that all Web Services are orchestrable, but not all > >>> Web Services are "orchestration-ready". That is, in > >>> order to be "orchestration-ready" a Web Service may > >>> need to have the ability to participate in a certain > >>> protocol (e.g. the OASIS WS-CAF > coordination protocol, > >>> which can be part of orchestration) by implementing > >>> that protocol. > >>> For example, a Web Service may need to have the > >>> capability to register itself with a > coordinator service. > >>> Joe > >>> Joseph Chiusano > >>> Booz Allen Hamilton > >>> O: 703-902-6923 > >>> C: 202-251-0731 > >>> Visit us online@ http://www.boozallen.com > >>> <http://www.boozallen.com/> > >>> > >>> > -------------------------------------------------------------- > ---------- > >>> *From:* John Harby [mailto:jharby@gmail.com > >>> <mailto:jharby@gmail.com>] > >>> *Sent:* Tuesday, September 06, 2005 12:03 PM > >>> *To:* soa-rm@lists.oasis-open.org > >>> <mailto:soa-rm@lists.oasis-open.org> > >>> > >>> *Subject:* Re: [soa-rm] Amazon.com > >>> <http://Amazon.com> and Hurricane Catrina - > >>> Service Context? Service "Veneer"? > >>> > >>> One question I had was can all services be > >>> orchestrated or are there "orchestratable > >>> services" and "non-orchestratable services". If > >>> there is a distinction, would this orchestration > >>> capability be mitigated via policy? > >>> > >>> John Harby > >>> > >>> On 9/6/05, *Ken Laskey* <klaskey@mitre.org > >>> <mailto:klaskey@mitre.org>> wrote: > >>> > >>> The actual collection (orchestration?) of > >>> services (or more basically, > capabilities that > >>> the services access?) will reflect the > >>> particular business process, but at a > >>> reference model level we can't build a > >>> different model for each business > process. The > >>> challenge is to identify the concepts from > >>> which you can support any business process. > >>> (Question: have the previous drafts > of SOA-RM > >>> missed any of these concepts?) A previous > >>> difficulty when looking at typical use cases > >>> is that not every SOA challenge will have a > >>> purchase order and a credit card > number. While > >>> purchasing is an important use case, a SOA > >>> tailored to support the variations of > >>> purchasing may fail badly in > addressing, say, > >>> the need to find and access real > time disaster > >>> data. > >>> > >>> Ken > >>> > >>> At 11:23 AM 9/6/2005, > marchadr@wellsfargo.com > >>> <mailto:marchadr@wellsfargo.com> wrote: > >>> > >>> > >>> > >>> > >>> > >>>> I tend to agree with Steve's point about > >>>> having the model reflect the business > >>>> processes and then deriving the service > >>>> definition from the type of processes the > >>>> service will aggregate or use. In > theory, the > >>>> payment of a product, service or > donation is > >>>> not that different since at the end of the > >>>> day it becomes a transaction of a total > >>>> amount from one account to the other > >>>> (Amazon's in this case) and the entities > >>>> (product, service, or donation) are a means > >>>> to an end. > >>>> > >>>> The separation of the order versus the > >>>> purchasing would probably be the best > >>>> approach for the interface design, > since the > >>>> order could vary and have polymorphistic > >>>> behavior depending on the type of entities > >>>> that are a part of the order. (In > some cases, > >>>> the order would have a possibility > of having > >>>> a donation and a product in the same order > >>>> from the UI point of view.) The order would > >>>> be used to hold products and start the back > >>>> office processing, while the purchase would > >>>> make the transaction of money based on a > >>>> total amount of the order. > >>>> > >>>> This brings up an issue in some ways of > >>>> whether or not the order triggers the > >>>> purchase which would result in a service > >>>> invoking another service. > >>>> The other issue I have been finding is a > >>>> return is similar to a purchase since it is > >>>> the reverse of the transaction (one account > >>>> to another with an amount), since > usually it > >>>> is to late to reverse it before it actual > >>>> makes a charge. Also in the case of > >>>> purchasing large amounts of products and > >>>> paying for them and in some back office > >>>> process one product is determined to be > >>>> discontinued then the reversal of a > >>>> transaction will really be based on the > >>>> amount of that discontinued transaction and > >>>> not the total amount which would almost be > >>>> like purchasing the product back from the > >>>> customer. > >>>> > >>>> Something to think about. The context seems > >>>> to be a good approach for the ordering and > >>>> purchasing scenario. > >>>> > >>>> Dan > >>>> > >>>> -----Original Message----- > >>>> From: Jones, Steve G [ > >>>> mailto:steve.g.jones@capgemini.com] > >>>> Sent: Monday, September 05, > 2005 7:30 AM > >>>> To: Ken Laskey; SOA-RM > >>>> Subject: RE: [soa-rm] Amazon.com > >>>> <http://Amazon.com> and > Hurricane Catrina > >>>> - Service Context? Service "Veneer"? > >>>> > >>>> I've found that the only way to model > >>>> this is to ensure that you have a > >>>> hierarchy of service that > models the full > >>>> business rather than > concentrating on the > >>>> technical delivery elements. > So you must > >>>> model (but not have to directly > >>>> implement) the two types of services, > >>>> which then act as containers for the > >>>> technical services. The higher order > >>>> service then has different business > >>>> processes that give different results, > >>>> but these are hidden from the service > >>>> consumers. > >>>> > >>>> What has been the biggest > problem for me > >>>> has been how to represent the change in > >>>> contract (but not interface) > of a service > >>>> due to its different domain. > This isn't a > >>>> huge technical challenge at the moment > >>>> (as we can't define contracts at all!) > >>>> but could become a much bigger > challenge > >>>> is future. Some concept of contract > >>>> inheritance might work here... > >>>> > >>>> I'm wary of describing groups as things > >>>> (like a payment service) as a > capability > >>>> rather than a service as it gets tricky > >>>> on granularity, unless you mean that a > >>>> capability is a single invocation on a > >>>> service? > >>>> > >>>> If we deal in RM around Service > >>>> boundaries and the concept of hierarchy > >>>> then we don't have a new service just a > >>>> different context. Where it gets tricky > >>>> for me is when you have a > service that IS > >>>> clearly re-used but is actually > >>>> completely separate. You get > this in some > >>>> compliance sensitive areas > where they use > >>>> identical solutions but completely > >>>> separate instances. This is > different to > >>>> ones where they do that just > because they > >>>> can, there is a broader context that > >>>> means they MUST be kept > separate... a real > >>>> bugger to model. > >>>> > >>>> In part I'm interested in how we are > >>>> putting hierarchy into the RM? > >>>> > >>>> Steve > >>>> > >>>> > >>>> > -------------------------------------------------------------- > ---------- > >>>> From: Ken Laskey [ > mailto:klaskey@mitre.org] > >>>> Sent: 05 September 2005 15:12 > >>>> To: SOA-RM > >>>> Subject: Re: [soa-rm] Amazon.com > >>>> <http://Amazon.com> and > Hurricane Catrina > >>>> - Service Context? Service "Veneer"? > >>>> > >>>> > >>>> > >>>> > >>>> > >>> Steve, > >>> > >>> I believe we are saying the same > thing. If the > >>> service is specifying the item to > be purchased > >>> by UPC, it is the same service in a > different > >>> context. In this case, the donation would be > >>> added to the general catalog and the user > >>> interaction would be the same. I'd consider > >>> the "broader service" to be what I call the > >>> underlying capability, i.e. the money > >>> collection in return for something. The > >>> consumer sees the real world effect of that > >>> capability existing and there being > a service > >>> to access it, but never sees the capability > >>> itself. > >>> > >>> However, note that with both Amazon > and Apple > >>> there are new means to invoke the service > >>> (special links) and the service > interacts with > >>> the consumer in ways different than > the usual. > >>> For these reasons I'd say that for the new > >>> context Amazon and Apple created > new services > >>> (where here I mean services in the SOA > >>> context) to repurpose existing > capability (the > >>> provisioning of which may be called > a service > >>> in the more general business > context). I'm not > >>> sure what Amazon and Apple did made > use of any > >>> SOA magic but it was nice reuse of > capability. > >>> > >>> Does this bugger things up? I think it does > >>> only if we need to be definitive when you > >>> cross the line from reusing a service to > >>> having a new one. I'm not sure for > the SOA-RM > >>> that we need to draw that line or even > >>> acknowledge that it may exist. > >>> > >>> Ken > >>> > >>> > >>> On Sep 5, 2005, at 4:37 AM, Jones, > Steve G wrote: > >>> > >>> > >>> Again not to raise old threads... but > >>> > >>> This for me is the concept of context, the > >>> context has changed which means the > impact of > >>> the service is different, its implementation > >>> and execution may however remain > identical. So > >>> the "Collection" service in this case always > >>> results in Money being taken and added to a > >>> general leger with a UPC for the > product code > >>> (for example). The difference is that in the > >>> charity domain it results in the further > >>> sending of that money onto the charity > >>> represented by the UPC, whereas in the > >>> purchasing domain you get a song to > download. > >>> The actual collection service therefore > >>> remains unchanged but there is a broader > >>> service (whose interface you don't directly > >>> see but assume) which controls the > whole process. > >>> > >>> And I can safely say that these > things can be > >>> a bugger to model. > >>> > >>> > >>> > -------------------------------------------------------------- > ---------- > >>> From: Ken Laskey [mailto:klaskey@mitre.org] > >>> Sent: 05 September 2005 01:29 > >>> To: SOA-RM > >>> Subject: Re: [soa-rm] Amazon.com > >>> <http://Amazon.com> and Hurricane Catrina - > >>> Service Context? Service "Veneer"? > >>> > >>> And the answer, as always, is it depends. In > >>> my example of buying by UPC symbol, > it is the > >>> same but possibly because the use of the UPC > >>> symbol has been expanded. In the case of > >>> having a new service that, let's say, > >>> automatically substitutes the charity item > >>> number for your choice of a song item number > >>> and maybe gives specialized feedback to the > >>> consumer saying thank you for responding to > >>> the hurricane emergency, I'd say it is a > >>> different service. It is derived from the > >>> original but I'd say it is different. > >>> > >>> Ken > >>> > >>> P.S. and with this busy hurricane season, we > >>> are up to Katrina. > >>> > >>> P.P.S. Another interesting aspect is if you > >>> had a computer that hadn't already accepted > >>> the iTunes terms and conditions, you were > >>> first presented with their click-through > >>> agreement before you contribute. So we also > >>> have an interesting reuse of policy and the > >>> need to form a contract. > >>> > >>> > >>> On Sep 4, 2005, at 7:14 PM, > Chiusano Joseph wrote: > >>> > >>> <Quote> > >>> Is there also a concept of a service having > >>> the same interface but by operating in a > >>> different domain (e.g. charity) it acts > >>> different for the same interface? > >>> </Quote> > >>> > >>> Which raises another question we've been > >>> through before in the TC (several > months ago): > >>> Is it the same service in both > cases? That is, > >>> are the "normal" Amazon.com > >>> <http://Amazon.com> order placement service > >>> (with credit card info on file, and > selectable > >>> each time) and this new "hurricane donation" > >>> service really the same service? > >>> > >>> Joe > >>> > >>> P.S. Not trying to resurrect a permathread - > >>> just tying a recent observation in > with a past > >>> exchange, to see it in a new light. > >>> > >>> > -------------------------------------------------------------- > ---------- > >>> From: Jones, Steve G [ > >>> mailto:steve.g.jones@capgemini.com] > >>> Sent: Sun 9/4/2005 5:25 PM > >>> To: Ken Laskey; Chiusano Joseph > >>> Cc: SOA-RM > >>> Subject: RE: [soa-rm] Amazon.com > >>> <http://Amazon.com> and Hurricane Catrina - > >>> Service Context? Service "Veneer"? > >>> Is there also a concept of a service having > >>> the same interface but by operating in a > >>> different domain (e.g. charity) it acts > >>> different for the same interface? In effect > >>> its business contract is changed by > a business > >>> driver outside of its scope, while its > >>> functionality (collecting money) remains the > >>> same its imperative is changed by the wider > >>> business context in which it now sits. > >>> > >>> Steve > >>> > >>> > -------------------------------------------------------------- > ---------- > >>> From: Ken Laskey [mailto:klaskey@mitre.org] > >>> Sent: 04 September 2005 21:22 > >>> To: Chiusano Joseph > >>> Cc: SOA-RM > >>> Subject: Re: [soa-rm] Amazon.com > >>> <http://Amazon.com> and Hurricane Catrina - > >>> Service Context? Service "Veneer"? > >>> > >>> Apple also did this with their iTunes Music > >>> Store: click the link and you order > a donation > >>> instead of a song. > >>> > >>> This is why I keep insisting on > >>> differentiating between the service and the > >>> capability. The underlying capability is to > >>> collect money for a purpose. The service > >>> provides the interface for doing that. > >>> Typically, you invoke the > capability through a > >>> service that enables you to buy a book (or a > >>> song) but a new service invokes that > >>> capability (with a new user facing interface > >>> for Apple; I haven't checked > Amazon) to "buy" > >>> a donation. The power is the capability is > >>> reusable by making it accessible through a > >>> different service. > >>> > >>> Now note if I buy something through > a service > >>> that allowed me to specify the UPC code, I > >>> could buy a donation through their existing > >>> service with that UPC, i.e. reusing the > >>> service for a purpose similar to > but different > >>> from its original purpose. In fact, several > >>> supermarkets around here do support that > >>> because they have little tear-off tablets at > >>> the checkout for certain hunger > organizations > >>> and you can hand the clerk a page > for $1, $5, > >>> or $10. > >>> > >>> Many interesting variations and our RM just > >>> has to capture the concepts that > can describe > >>> any of them. I think I'll mow the lawn and > >>> think about this some more. > >>> > >>> Ken > >>> > >>> On Sep 4, 2005, at 4:06 PM, > Chiusano Joseph wrote: > >>> > >>> One thing that I discovered regarding the > >>> horrible catastrophe in the Southern US is > >>> that Amazon.com <http://Amazon.com> enabled > >>> people to use its online ordering service to > >>> make a donation. One could use the > credit card > >>> information that Amazon.com > >>> <http://Amazon.com> already had > online to make > >>> a donation in what it called "1-Click > >>> Donation" (or something similar). > >>> So instead of placing an order for > a book, CD, > >>> etc., your "order" was your > donation, and you > >>> could view your "order" online, which (as I > >>> recall) would show the amount that > you donated. > >>> > >>> Something that came to my mind is: > What would > >>> this placing of a "new face" on a existing > >>> service be called? Is it a different context > >>> for the ordering service? (i.e. in > the context > >>> of Hurrican Katrina) Is it a > "veneer" that was > >>> placed on top of the existing > service? None of > >>> the above? > >>> > >>> Joe > >>> > >>> Joseph Chiusano > >>> Booz Allen Hamilton > >>> O: 703-902-6923 > >>> C: 202-251-0731 > >>> Visit us online@ http://www.boozallen.com > >>> <http://www.boozallen.com/> > >>> > >>> > >>> --- > >>> Ken Laskey > >>> MITRE Corporation, M/S H305 phone: > 703-983-7934 > >>> 7515 Colshire Drive fax: 703-983-1379 > >>> McLean VA 22102-7508 > >>> > >>> > >>> > >>> This message contains information > that may be > >>> privileged or confidential and is > the property > >>> of the Capgemini Group. It is intended only > >>> for the person to whom it is > addressed. If you > >>> are not the intended recipient, you are not > >>> authorized to read, print, retain, copy, > >>> disseminate, distribute, or use this message > >>> or any part thereof. If you receive this > >>> message in error, please notify the sender > >>> immediately and delete all copies > of this message. > >>> > >>> > >>> > >>> > >>> --- > >>> Ken Laskey > >>> MITRE Corporation, M/S H305 phone: > 703-983-7934 > >>> 7515 Colshire Drive fax: 703-983-1379 > >>> McLean VA 22102-7508 > >>> > >>> > >>> > >>> This message contains information > that may be > >>> privileged or confidential and is > the property > >>> of the Capgemini Group. It is intended only > >>> for the person to whom it is > addressed. If you > >>> are not the intended recipient, you are not > >>> authorized to read, print, retain, copy, > >>> disseminate, distribute, or use this message > >>> or any part thereof. If you receive this > >>> message in error, please notify the sender > >>> immediately and delete all copies > of this message. > >>> > >>> > >>> > >>> > >>> --- > >>> Ken Laskey > >>> MITRE Corporation, M/S H305 phone: > 703-983-7934 > >>> 7515 Colshire Drive fax: 703-983-1379 > >>> McLean VA 22102-7508 > >>> > >>> > >>> > >>> > >>> This message contains information > that may be > >>> privileged or confidential and is > the property > >>> of the Capgemini Group. It is intended only > >>> for the person to whom it is > addressed. If you > >>> are not the intended recipient, you are not > >>> authorized to read, print, retain, copy, > >>> disseminate, distribute, or use this message > >>> or any part thereof. If you receive this > >>> message in error, please notify the sender > >>> immediately and delete all copies > of this message. > >>> -- > >>> > -------------------------------------------------------------- > ------------------- > >>> / 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]