[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]