[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 actually have a cache service in _my_ architecture which is stateless from the services point of view. The service takes two parameters: UUID, Object. The invoker, or in some cases, orchestration engine, checks with the cache service to see if it has an Object for a given UUID. -matt John Harby wrote: > What if someone wanted to create a caching service? > > On 9/8/05, *Matthew MacKenzie* <mattm@adobe.com > <mailto:mattm@adobe.com>> wrote: > > 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 > <mailto: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 > <mailto:dnickull@adobe.com>] > >Sent: September 7, 2005 5:15 PM > >To: McGregor, Wesley > >Cc: chiusano_joseph@bah.com <mailto:chiusano_joseph@bah.com>; > soa-rm@lists.oasis-open.org <mailto: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 > <mailto: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 > <mailto:dnickull@adobe.com>] > >>Sent: September 6, 2005 6:08 PM > >>To: Chiusano Joseph > >>Cc: soa-rm@lists.oasis-open.org > <mailto:soa-rm@lists.oasis-open.org> > >>Subject: Re: [soa-rm] [Duane, need clarification] RE: > [soa-rm] Amazon.com <http://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/ <http://www.boozallen.com/>> > >>> > >>> > ------------------------------------------------------------------------ > >>> *From:* John Harby [mailto:jharby@gmail.com > <mailto:jharby@gmail.com>] > >>> *Sent:* Tuesday, September 06, 2005 1:14 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 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> > >>> <mailto: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> > >>> <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> > >>> <mailto:soa-rm@lists.oasis-open.org > <mailto:soa-rm@lists.oasis-open.org>> > >>> *Subject:* Re: [soa-rm] Amazon.com > <http://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> > >>> <mailto: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> > >>> <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> > >>> <mailto:soa-rm@lists.oasis-open.org > <mailto:soa-rm@lists.oasis-open.org>> > >>> > >>> *Subject:* Re: [soa-rm] Amazon.com > <http://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> > >>> <mailto: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> > >>> <mailto: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 > <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> > >>>> <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 <mailto:klaskey@mitre.org>] > >>>> Sent: 05 September 2005 15:12 > >>>> To: SOA-RM > >>>> Subject: Re: [soa-rm] Amazon.com > <http://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 <mailto:klaskey@mitre.org>] > >>> Sent: 05 September 2005 01:29 > >>> To: SOA-RM > >>> Subject: Re: [soa-rm] Amazon.com > <http://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> > >>> <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 > <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> > >>> <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 <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> > >>> <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> > <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> > >>> <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]