[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.com andHurricane Katrina - Service Context? Service "Veneer"?
That is covered in Robert's rules. Any item decided is out of order to raise again, unless 2/3's of the members support the issue being reopened. Duane Behera, Prasanta wrote: >One thing we should figure out (I didn't say discuss) is how to "not >discuss" items/issues which has been discussed and resolved (somewhat). > >Thanks, >/Prasanta > > >-----Original Message----- >From: Duane Nickull [mailto:dnickull@adobe.com] >Sent: Tuesday, September 06, 2005 3:08 PM >To: Chiusano Joseph >Cc: soa-rm@lists.oasis-open.org >Subject: Re: [soa-rm] [Duane, need clarification] RE: [soa-rm] >Amazon.com and Hurricane 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]