[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 and Hurricane Katrina - Service Context? Service "Veneer"?
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]