[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: My last commnet on this...
A new version of our draft spec is about to come out soon. I can't wait (meant completely sincerely)... 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 12:00 PM > To: Chiusano Joseph; soa-rm@lists.oasis-open.org > Subject: My last commnet on this... > > Matt, Joe, > > I am not talking about orchestration at all. > > I am talking about the properties of an abstract service > which has yet to be defined with any clarity. We should not > limit (without careful consideration) too much at the top of > the model. > > Wes > > -----Original Message----- > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] > Sent: September 8, 2005 11:29 AM > To: soa-rm@lists.oasis-open.org > 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]