[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] [Duane, need clarification]
I'll get on my horse here.... The following assumes that by atomic you mean that a service can not encapsulate other services e.g within an SOA - Service A is said to contain B,C & D and you cannot call the internal services except by express permission of the parent, or (more common) as an indirect result of calling the parent. A service should most definitely not be atomic. By making a service atomic means that service architecture must be a flat thing. This prevents services from mapping to an enterprise (inherently a structured element), it also means that all services must be considered equal and without structure which makes management a nightmare. This has nothing to do with orchestration (which is about invocation) but about domains of control. For service architectures to represent a business they must also represent the functional structure of that business (N.B not the same as an org chart) which means a service can be a collection of services. My experience of flat service architectures is that the process model becomes overly dominant (and large) and phenomenally difficult to change. Have Services as non-atomic and providing structure actually increases re-use as it makes much clearer how services are to be re-used and makes them often easier to find. Of course if you meant that from the perspective of the CALLER of a service that it should be considered atomic then this is normally but not always the case as the encapsulating domain can be the policy/access controller for invocation of the lower order services. > -----Original Message----- > From: Charlton Barreto [mailto:cbarreto@adobe.com] > Sent: 08 September 2005 17:19 > To: McGregor.Wesley@tbs-sct.gc.ca; chiusano_joseph@bah.com; soa- > rm@lists.oasis-open.org > Subject: RE: [soa-rm] [Duane, need clarification] > > Wes, > > At the same time, we should not be too loose in defining the basis of an > abstract service. Assuming state-gnostic services is essentially opening a > Pandora's Box. A service should be 'atomic' and thus agnostic of the > internals of other services which may use it or be used with it. Having it > otherwise breaks reuse, any hope of peer-to-peer interactivity, state > management orthogonality, controller compatibility, etc. > > -Charlton. > > -----Original Message----- > From: McGregor.Wesley@tbs-sct.gc.ca [mailto:McGregor.Wesley@tbs-sct.gc.ca] > Sent: Thursday, September 08, 2005 9:00 AM > To: chiusano_joseph@bah.com; soa-rm@lists.oasis-open.org > Subject: [soa-rm] 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 / > > >>> > > >>> > > -------------------------------------------------------------------- > > >>> -------------- > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >> > > >> > > >> > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]