[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"?
D'oh!! Got me.. ;-) Chiusano Joseph wrote: >I believe we already discussed that recently. > >Joe > >Joseph Chiusano >Booz Allen Hamilton >O: 703-902-6923 >C: 202-251-0731 >Visit us online@ http://www.boozallen.com > > > > >>-----Original Message----- >>From: Behera, Prasanta [mailto:pbehera@visa.com] >>Sent: Tuesday, September 06, 2005 6:29 PM >>To: Duane Nickull; Chiusano Joseph >>Cc: soa-rm@lists.oasis-open.org >>Subject: RE: [soa-rm] [Duane, need clarification] RE: >>[soa-rm] Amazon.com and Hurricane Katrina - Service Context? >>Service "Veneer"? >> >>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]