[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"?
John, Respectfully, you're talking crazy talk now. This issue was almost certainly discussed at a quorate meeting if our esteemed chair was so bold as to indicate it as a closed issue. We cannot put out a ballot for every line of the specification, instead, its everyone on the TC's duty to attend meetings and get involved in discussions. -matt John Harby wrote: > Well maybe there should be actually polls created here for these > issues so we can > see that the issue was resolved and the votes recorded. > > On 9/8/05, *Chiusano Joseph* <chiusano_joseph@bah.com > <mailto:chiusano_joseph@bah.com>> wrote: > > 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> > > [mailto: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 <mailto:mattm@adobe.com> > > Cc: dnickull@adobe.com <mailto:dnickull@adobe.com>; Chiusano > Joseph; 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 - 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 > <mailto:mattm@adobe.com>] > > Sent: September 8, 2005 11:06 AM > > To: McGregor, Wesley > > Cc: dnickull@adobe.com <mailto:dnickull@adobe.com>; > 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 - 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 > <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]