OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm] [Duane,need clarification] RE: [soa-rm] Amazon.comandHurricane Catrina - ServiceContext? Service "Veneer"?


I actually have a cache service in _my_ architecture which is stateless 
from the services point of view.  The service takes two parameters:  
UUID, Object.  The invoker, or in some cases, orchestration engine, 
checks with the cache service to see if it has an Object for a given UUID.

-matt


John Harby wrote:

> What if someone wanted to create a caching service?
>
> On 9/8/05, *Matthew MacKenzie* <mattm@adobe.com 
> <mailto:mattm@adobe.com>> wrote:
>
>     First off, the RM should not care what you decide to feed into your
>     services.  Even though it is bad form to require services to
>     understand
>     operations outside of its scope (think reusability), it is not our
>     place
>     as RM authors to discourage bad architecture.
>
>     Secondly, the whole idea of composite services and orchestration
>     is out
>     of scope.  People, we have to get beyond this fixation with
>     particular
>     architectures, it is getting tiresome and is not helping us get to our
>     goal of publishing an RM.  And I'll throw in a note about
>     orchestration:
>     IT IS THE ORCHESTRATOR'S JOB TO MANAGE STATE!  This can be done
>     without
>     passing that state between each step of the orchestration.  Think
>     about
>     the inherent orchestration involved in shipping a container from
>     Singapore to Boise, Idaho.  Does the crane operator in Singapore
>     who is
>     dropping the container onto a ship care that the box is destined for
>     Idaho?  Hell no.  He is told: ContainerA -> Ship1.  When the ship hits
>     San Fran or wherever, the container number is delivered to its owner,
>     who then figures out where it has to go.  It is important that in a
>     disconnected, service oriented world that state be avoided wherever
>     possible so that services can be reused and included in diverse
>     orchestrations.  NONE of this really matters to the RM, only the RAs.
>
>     -matt
>
>     McGregor.Wesley@tbs-sct.gc.ca
>     <mailto:McGregor.Wesley@tbs-sct.gc.ca> wrote:
>
>     >Respectfully I disagree.
>     >
>     >You are stating that a service MUST NOT have any input that is
>     state oriented. I believe that notion is too strict and hence the
>     usage of the term SHOULD is more appropriate.
>     >
>     >By saying MUST NOT implies that any derived architecture and
>     their services can NEVER have a state as input which would render
>     a lot of collaboration services impossible. Intra-enterprise
>     services which can greatly benefit from state-based input could
>     never exist then.
>     >
>     >I would allow for MUST NOT (greater restriction) on an RA but
>     SHOULD (open ended) on an RM.
>     >
>     >Wes
>     >
>     >
>     > -----Original Message-----
>     >From:  Duane Nickull [mailto:dnickull@adobe.com
>     <mailto:dnickull@adobe.com>]
>     >Sent:  September 7, 2005 5:15 PM
>     >To:    McGregor, Wesley
>     >Cc:    chiusano_joseph@bah.com <mailto:chiusano_joseph@bah.com>;
>     soa-rm@lists.oasis-open.org <mailto:soa-rm@lists.oasis-open.org>
>     >Subject:       Re: [soa-rm] [Duane, need clarification] RE:
>     [soa-rm] Amazon.comandHurricane Catrina - Service Context? Service
>     "Veneer"?
>     >
>     >Wes:
>     >
>     >There is a differentiator.  A service may be designed and
>     configured to
>     >support an orchestration.  It may even be split into two services to
>     >support commit and rollback functionality.  However, at the time
>     it gets
>     >called, it has no notion (state) what lies beyond its' event horizon
>     >(its' interface/service/action boundary etc).
>     >
>     >Duane
>     >
>     >
>     >McGregor.Wesley@tbs-sct.gc.ca
>     <mailto:McGregor.Wesley@tbs-sct.gc.ca> wrote:
>     >
>     >
>     >
>     >>I would argue that the Service Description allows for the
>     possibility that this information can be made requisite.
>     >>
>     >>The Service Description is vague enough at this point not to
>     preclude it. Thus the word SHOULD is appropriate.
>     >>
>     >>-----Original Message-----
>     >>From:         Duane Nickull [mailto: dnickull@adobe.com
>     <mailto:dnickull@adobe.com>]
>     >>Sent: September 6, 2005 6:08 PM
>     >>To:   Chiusano Joseph
>     >>Cc:   soa-rm@lists.oasis-open.org
>     <mailto:soa-rm@lists.oasis-open.org>
>     >>Subject:      Re: [soa-rm] [Duane, need clarification] RE:
>     [soa-rm] Amazon.com <http://Amazon.com> andHurricane Catrina -
>     Service Context? Service "Veneer"?
>     >>
>     >>Joseph et al:
>     >>
>     >>This is partially true. Orchestration of multiple services is not
>     >>something that will be a normative component of the RM, however
>     it may
>     >>be mentioned for illustration purposes. See Vancouver meeting
>     notes for
>     >>more details.
>     >>
>     >>There are many reasons for this. Services themselves would not
>     be aware
>     >>of whether they are being called as part of a larger
>     orchestration vs. a
>     >>single request, nor should they. There is no fundamental
>     difference in
>     >>the way a service may be called that distinguish these two things.
>     >>
>     >>I am very tied up right now but we can table this for our next call
>     >>(Agenda pending).
>     >>
>     >>Duane
>     >>
>     >>Chiusano Joseph wrote:
>     >>
>     >>
>     >>
>     >>
>     >>
>     >>>Okey-dokey. I request clarification from the Chair at this
>     point for
>     >>>us all, please, on where orchestration fits in/will fit in with
>     our RM
>     >>>once our 12-month (per our charter) product is released.
>     >>>Joe
>     >>>Joseph Chiusano
>     >>>Booz Allen Hamilton
>     >>>O: 703-902-6923
>     >>>C: 202-251-0731
>     >>>Visit us online@ http://www.boozallen.com
>     <http://www.boozallen.com/ <http://www.boozallen.com/>>
>     >>>
>     >>>  
>     ------------------------------------------------------------------------
>     >>>   *From:* John Harby [mailto:jharby@gmail.com
>     <mailto:jharby@gmail.com>]
>     >>>   *Sent:* Tuesday, September 06, 2005 1:14 PM
>     >>>   *To:* soa-rm@lists.oasis-open.org
>     <mailto:soa-rm@lists.oasis-open.org>
>     >>>   *Subject:* Re: [soa-rm] Amazon.com <http://Amazon.com> and
>     Hurricane Catrina - Service
>     >>>   Context? Service "Veneer"?
>     >>>
>     >>>   I may have missed something several months ago but I would call
>     >>>   that approach questionable at best.
>     >>>
>     >>>   On 9/6/05, *Chiusano Joseph* < chiusano_joseph@bah.com
>     <mailto:chiusano_joseph@bah.com>
>     >>>   <mailto:chiusano_joseph@bah.com
>     <mailto:chiusano_joseph@bah.com>>> wrote:
>     >>>
>     >>>       John,
>     >>>       I believe this was determined several months ago (I say that
>     >>>       in a helpful way, not in a criticizing way). I don't believe
>     >>>       we are limited at all in our capability to define service.
>     >>>       It's just that we need to define certain "basic" aspects
>     >>>       first, and have other TCs (or perhaps this one in a later
>     >>>       phase) extend our RM to include capabilities such as
>     >>>       orchestration. We've sometimes referred to this as a POA
>     >>>       (Process-Oriented Architecture).
>     >>>       Hang in there, we'll get there.....
>     >>>       Joe
>     >>>       Joseph Chiusano
>     >>>       Booz Allen Hamilton
>     >>>       O: 703-902-6923
>     >>>       C: 202-251-0731
>     >>>       Visit us online@ http://www.boozallen.com
>     >>>       <http://www.boozallen.com/>
>     >>>
>     >>>          
>     ------------------------------------------------------------------------
>
>     >>>           *From:* John Harby [mailto:jharby@gmail.com
>     <mailto:jharby@gmail.com>
>     >>>           <mailto:jharby@gmail.com <mailto:jharby@gmail.com>>]
>     >>>           *Sent:* Tuesday, September 06, 2005 12:44 PM
>     >>>
>     >>>           *To:* soa-rm@lists.oasis-open.org
>     <mailto:soa-rm@lists.oasis-open.org>
>     >>>           <mailto:soa-rm@lists.oasis-open.org
>     <mailto:soa-rm@lists.oasis-open.org>>
>     >>>           *Subject:* Re: [soa-rm] Amazon.com
>     <http://Amazon.com> <http://Amazon.com> and
>     >>>           Hurricane Catrina - Service Context? Service "Veneer"?
>     >>>
>     >>>           I'm surprised that orchestration is out of scope. I
>     could
>     >>>           understand how specifics such as BPEL
>     >>>           would be out of scope but many people will call things
>     >>>           services that are lorchestrations of other
>     >>>           services. If orchestration is out of scope then are we
>     >>>           limited in our capability to define "service"?
>     >>>
>     >>>           On 9/6/05, *Chiusano Joseph* <
>     chiusano_joseph@bah.com <mailto:chiusano_joseph@bah.com>
>     >>>           <mailto:chiusano_joseph@bah.com
>     <mailto:chiusano_joseph@bah.com>>> wrote:
>     >>>
>     >>>               Emphasizing that orchestration is out of scope
>     for our
>     >>>               RM (it's for another RM that can be built on top of
>     >>>               ours), and speaking only of Web Services: I
>     would say
>     >>>               that all Web Services are orchestrable, but not all
>     >>>               Web Services are "orchestration-ready". That is, in
>     >>>               order to be "orchestration-ready" a Web Service may
>     >>>               need to have the ability to participate in a certain
>     >>>               protocol (e.g. the OASIS WS-CAF coordination
>     protocol,
>     >>>               which can be part of orchestration) by implementing
>     >>>               that protocol.
>     >>>               For example, a Web Service may need to have the
>     >>>               capability to register itself with a coordinator
>     service.
>     >>>               Joe
>     >>>               Joseph Chiusano
>     >>>               Booz Allen Hamilton
>     >>>               O: 703-902-6923
>     >>>               C: 202-251-0731
>     >>>               Visit us online@ http://www.boozallen.com
>     >>>               <http://www.boozallen.com/>
>     >>>
>     >>>                  
>     ------------------------------------------------------------------------
>     >>>                   *From:* John Harby [mailto:jharby@gmail.com
>     <mailto:jharby@gmail.com>
>     >>>                   <mailto:jharby@gmail.com
>     <mailto:jharby@gmail.com>>]
>     >>>                   *Sent:* Tuesday, September 06, 2005 12:03 PM
>     >>>                   *To:* soa-rm@lists.oasis-open.org
>     <mailto:soa-rm@lists.oasis-open.org>
>     >>>                   <mailto:soa-rm@lists.oasis-open.org
>     <mailto:soa-rm@lists.oasis-open.org>>
>     >>>
>     >>>                   *Subject:* Re: [soa-rm] Amazon.com
>     <http://Amazon.com>
>     >>>                   <http://Amazon.com> and Hurricane Catrina -
>     >>>                   Service Context? Service "Veneer"?
>     >>>
>     >>>                   One question I had was can all services be
>     >>>                   orchestrated or are there "orchestratable
>     >>>                   services" and "non-orchestratable services". If
>     >>>                   there is a distinction, would this orchestration
>     >>>                   capability be mitigated via policy?
>     >>>
>     >>>                   John Harby
>     >>>
>     >>>                   On 9/6/05, *Ken Laskey* <klaskey@mitre.org
>     <mailto:klaskey@mitre.org>
>     >>>                   <mailto:klaskey@mitre.org
>     <mailto:klaskey@mitre.org>>> wrote:
>     >>>
>     >>>                       The actual collection (orchestration?) of
>     >>>                       services (or more basically,
>     capabilities that
>     >>>                       the services access?) will reflect the
>     >>>                       particular business process, but at a
>     >>>                       reference model level we can't build a
>     >>>                       different model for each business
>     process. The
>     >>>                       challenge is to identify the concepts from
>     >>>                       which you can support any business process.
>     >>>                       (Question: have the previous drafts of
>     SOA-RM
>     >>>                       missed any of these concepts?) A previous
>     >>>                       difficulty when looking at typical use cases
>     >>>                       is that not every SOA challenge will have a
>     >>>                       purchase order and a credit card number.
>     While
>     >>>                       purchasing is an important use case, a SOA
>     >>>                       tailored to support the variations of
>     >>>                       purchasing may fail badly in addressing,
>     say,
>     >>>                       the need to find and access real time
>     disaster
>     >>>                       data.
>     >>>
>     >>>                       Ken
>     >>>
>     >>>                       At 11:23 AM 9/6/2005,
>     marchadr@wellsfargo.com <mailto:marchadr@wellsfargo.com>
>     >>>                       <mailto:marchadr@wellsfargo.com
>     <mailto:marchadr@wellsfargo.com>> wrote:
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>>                       I tend to agree with Steve's point about
>     >>>>                       having the model reflect the business
>     >>>>                       processes and then deriving the service
>     >>>>                       definition from the type of processes the
>     >>>>                       service will aggregate or use. In
>     theory, the
>     >>>>                       payment of a product, service or
>     donation is
>     >>>>                       not that different since at the end of the
>     >>>>                       day it becomes a transaction of a total
>     >>>>                       amount from one account to the other
>     >>>>                       (Amazon's in this case) and the entities
>     >>>>                       (product, service, or donation) are a means
>     >>>>                       to an end.
>     >>>>
>     >>>>                       The separation of the order versus the
>     >>>>                       purchasing would probably be the best
>     >>>>                       approach for the interface design,
>     since the
>     >>>>                       order could vary and have polymorphistic
>     >>>>                       behavior depending on the type of entities
>     >>>>                       that are a part of the order. (In some
>     cases,
>     >>>>                       the order would have a possibility of
>     having
>     >>>>                       a donation and a product in the same order
>     >>>>                       from the UI point of view.) The order would
>     >>>>                       be used to hold products and start the back
>     >>>>                       office processing, while the purchase would
>     >>>>                       make the transaction of money based on a
>     >>>>                       total amount of the order.
>     >>>>
>     >>>>                       This brings up an issue in some ways of
>     >>>>                       whether or not the order triggers the
>     >>>>                       purchase which would result in a service
>     >>>>                       invoking another service.
>     >>>>                       The other issue I have been finding is a
>     >>>>                       return is similar to a purchase since it is
>     >>>>                       the reverse of the transaction (one account
>     >>>>                       to another with an amount), since
>     usually it
>     >>>>                       is to late to reverse it before it actual
>     >>>>                       makes a charge. Also in the case of
>     >>>>                       purchasing large amounts of products and
>     >>>>                       paying for them and in some back office
>     >>>>                       process one product is determined to be
>     >>>>                       discontinued then the reversal of a
>     >>>>                       transaction will really be based on the
>     >>>>                       amount of that discontinued transaction and
>     >>>>                       not the total amount which would almost be
>     >>>>                       like purchasing the product back from the
>     >>>>                       customer.
>     >>>>
>     >>>>                       Something to think about. The context seems
>     >>>>                       to be a good approach for the ordering and
>     >>>>                       purchasing scenario.
>     >>>>
>     >>>>                       Dan
>     >>>>
>     >>>>                           -----Original Message-----
>     >>>>                           From: Jones, Steve G [
>     >>>>                           mailto:steve.g.jones@capgemini.com
>     <mailto:steve.g.jones@capgemini.com>]
>     >>>>                           Sent: Monday, September 05, 2005
>     7:30 AM
>     >>>>                           To: Ken Laskey; SOA-RM
>     >>>>                           Subject: RE: [soa-rm] Amazon.com
>     <http://Amazon.com>
>     >>>>                           <http://Amazon.com> and Hurricane
>     Catrina
>     >>>>                           - Service Context? Service "Veneer"?
>     >>>>
>     >>>>                           I've found that the only way to model
>     >>>>                           this is to ensure that you have a
>     >>>>                           hierarchy of service that models
>     the full
>     >>>>                           business rather than concentrating
>     on the
>     >>>>                           technical delivery elements. So you
>     must
>     >>>>                           model (but not have to directly
>     >>>>                           implement) the two types of services,
>     >>>>                           which then act as containers for the
>     >>>>                           technical services. The higher order
>     >>>>                           service then has different business
>     >>>>                           processes that give different results,
>     >>>>                           but these are hidden from the service
>     >>>>                           consumers.
>     >>>>
>     >>>>                           What has been the biggest problem
>     for me
>     >>>>                           has been how to represent the change in
>     >>>>                           contract (but not interface) of a
>     service
>     >>>>                           due to its different domain. This
>     isn't a
>     >>>>                           huge technical challenge at the moment
>     >>>>                           (as we can't define contracts at all!)
>     >>>>                           but could become a much bigger
>     challenge
>     >>>>                           is future. Some concept of contract
>     >>>>                           inheritance might work here...
>     >>>>
>     >>>>                           I'm wary of describing groups as things
>     >>>>                           (like a payment service) as a
>     capability
>     >>>>                           rather than a service as it gets tricky
>     >>>>                           on granularity, unless you mean that a
>     >>>>                           capability is a single invocation on a
>     >>>>                           service?
>     >>>>
>     >>>>                           If we deal in RM around Service
>     >>>>                           boundaries and the concept of hierarchy
>     >>>>                           then we don't have a new service just a
>     >>>>                           different context. Where it gets tricky
>     >>>>                           for me is when you have a service
>     that IS
>     >>>>                           clearly re-used but is actually
>     >>>>                           completely separate. You get this
>     in some
>     >>>>                           compliance sensitive areas where
>     they use
>     >>>>                           identical solutions but completely
>     >>>>                           separate instances. This is
>     different to
>     >>>>                           ones where they do that just
>     because they
>     >>>>                           can, there is a broader context that
>     >>>>                           means they MUST be kept separate...
>     a real
>     >>>>                           bugger to model.
>     >>>>
>     >>>>                           In part I'm interested in how we are
>     >>>>                           putting hierarchy into the RM?
>     >>>>
>     >>>>                           Steve
>     >>>>
>     >>>>
>     >>>>                          
>     ------------------------------------------------------------------------
>     >>>>                           From: Ken Laskey [
>     mailto:klaskey@mitre.org <mailto:klaskey@mitre.org>]
>     >>>>                           Sent: 05 September 2005 15:12
>     >>>>                           To: SOA-RM
>     >>>>                           Subject: Re: [soa-rm] Amazon.com
>     <http://Amazon.com>
>     >>>>                           <http://Amazon.com> and Hurricane
>     Catrina
>     >>>>                           - Service Context? Service "Veneer"?
>     >>>>
>     >>>>
>     >>>>
>     >>>>
>     >>>>
>     >>>                       Steve,
>     >>>
>     >>>                       I believe we are saying the same thing.
>     If the
>     >>>                       service is specifying the item to be
>     purchased
>     >>>                       by UPC, it is the same service in a
>     different
>     >>>                       context. In this case, the donation would be
>     >>>                       added to the general catalog and the user
>     >>>                       interaction would be the same. I'd consider
>     >>>                       the "broader service" to be what I call the
>     >>>                       underlying capability, i.e. the money
>     >>>                       collection in return for something. The
>     >>>                       consumer sees the real world effect of that
>     >>>                       capability existing and there being a
>     service
>     >>>                       to access it, but never sees the capability
>     >>>                       itself.
>     >>>
>     >>>                       However, note that with both Amazon and
>     Apple
>     >>>                       there are new means to invoke the service
>     >>>                       (special links) and the service
>     interacts with
>     >>>                       the consumer in ways different than the
>     usual.
>     >>>                       For these reasons I'd say that for the new
>     >>>                       context Amazon and Apple created new
>     services
>     >>>                       (where here I mean services in the SOA
>     >>>                       context) to repurpose existing
>     capability (the
>     >>>                       provisioning of which may be called a
>     service
>     >>>                       in the more general business context).
>     I'm not
>     >>>                       sure what Amazon and Apple did made use
>     of any
>     >>>                       SOA magic but it was nice reuse of
>     capability.
>     >>>
>     >>>                       Does this bugger things up? I think it does
>     >>>                       only if we need to be definitive when you
>     >>>                       cross the line from reusing a service to
>     >>>                       having a new one. I'm not sure for the
>     SOA-RM
>     >>>                       that we need to draw that line or even
>     >>>                       acknowledge that it may exist.
>     >>>
>     >>>                       Ken
>     >>>
>     >>>
>     >>>                       On Sep 5, 2005, at 4:37 AM, Jones, Steve
>     G wrote:
>     >>>
>     >>>
>     >>>                       Again not to raise old threads... but
>     >>>
>     >>>                       This for me is the concept of context, the
>     >>>                       context has changed which means the
>     impact of
>     >>>                       the service is different, its implementation
>     >>>                       and execution may however remain
>     identical. So
>     >>>                       the "Collection" service in this case always
>     >>>                       results in Money being taken and added to a
>     >>>                       general leger with a UPC for the product
>     code
>     >>>                       (for example). The difference is that in the
>     >>>                       charity domain it results in the further
>     >>>                       sending of that money onto the charity
>     >>>                       represented by the UPC, whereas in the
>     >>>                       purchasing domain you get a song to
>     download.
>     >>>                       The actual collection service therefore
>     >>>                       remains unchanged but there is a broader
>     >>>                       service (whose interface you don't directly
>     >>>                       see but assume) which controls the whole
>     process.
>     >>>
>     >>>                       And I can safely say that these things
>     can be
>     >>>                       a bugger to model.
>     >>>
>     >>>
>     >>>                      
>     ------------------------------------------------------------------------
>     >>>                       From: Ken Laskey
>     [mailto:klaskey@mitre.org <mailto:klaskey@mitre.org>]
>     >>>                       Sent: 05 September 2005 01:29
>     >>>                       To: SOA-RM
>     >>>                       Subject: Re: [soa-rm] Amazon.com
>     <http://Amazon.com>
>     >>>                       <http://Amazon.com> and Hurricane Catrina -
>     >>>                       Service Context? Service "Veneer"?
>     >>>
>     >>>                       And the answer, as always, is it depends. In
>     >>>                       my example of buying by UPC symbol, it
>     is the
>     >>>                       same but possibly because the use of the UPC
>     >>>                       symbol has been expanded. In the case of
>     >>>                       having a new service that, let's say,
>     >>>                       automatically substitutes the charity item
>     >>>                       number for your choice of a song item number
>     >>>                       and maybe gives specialized feedback to the
>     >>>                       consumer saying thank you for responding to
>     >>>                       the hurricane emergency, I'd say it is a
>     >>>                       different service. It is derived from the
>     >>>                       original but I'd say it is different.
>     >>>
>     >>>                       Ken
>     >>>
>     >>>                       P.S. and with this busy hurricane season, we
>     >>>                       are up to Katrina.
>     >>>
>     >>>                       P.P.S. Another interesting aspect is if you
>     >>>                       had a computer that hadn't already accepted
>     >>>                       the iTunes terms and conditions, you were
>     >>>                       first presented with their click-through
>     >>>                       agreement before you contribute. So we also
>     >>>                       have an interesting reuse of policy and the
>     >>>                       need to form a contract.
>     >>>
>     >>>
>     >>>                       On Sep 4, 2005, at 7:14 PM, Chiusano
>     Joseph wrote:
>     >>>
>     >>>                       <Quote>
>     >>>                       Is there also a concept of a service having
>     >>>                       the same interface but by operating in a
>     >>>                       different domain (e.g. charity) it acts
>     >>>                       different for the same interface?
>     >>>                       </Quote>
>     >>>
>     >>>                       Which raises another question we've been
>     >>>                       through before in the TC (several months
>     ago):
>     >>>                       Is it the same service in both cases?
>     That is,
>     >>>                       are the "normal" Amazon.com
>     <http://Amazon.com>
>     >>>                       <http://Amazon.com> order placement service
>     >>>                       (with credit card info on file, and
>     selectable
>     >>>                       each time) and this new "hurricane donation"
>     >>>                       service really the same service?
>     >>>
>     >>>                       Joe
>     >>>
>     >>>                       P.S. Not trying to resurrect a permathread -
>     >>>                       just tying a recent observation in with
>     a past
>     >>>                       exchange, to see it in a new light.
>     >>>
>     >>>                      
>     ------------------------------------------------------------------------
>     >>>                       From: Jones, Steve G [
>     >>>                       mailto:steve.g.jones@capgemini.com
>     <mailto:steve.g.jones@capgemini.com>]
>     >>>                       Sent: Sun 9/4/2005 5:25 PM
>     >>>                       To: Ken Laskey; Chiusano Joseph
>     >>>                       Cc: SOA-RM
>     >>>                       Subject: RE: [soa-rm] Amazon.com
>     <http://Amazon.com>
>     >>>                       <http://Amazon.com> and Hurricane Catrina -
>     >>>                       Service Context? Service "Veneer"?
>     >>>                       Is there also a concept of a service having
>     >>>                       the same interface but by operating in a
>     >>>                       different domain (e.g. charity) it acts
>     >>>                       different for the same interface? In effect
>     >>>                       its business contract is changed by a
>     business
>     >>>                       driver outside of its scope, while its
>     >>>                       functionality (collecting money) remains the
>     >>>                       same its imperative is changed by the wider
>     >>>                       business context in which it now sits.
>     >>>
>     >>>                       Steve
>     >>>
>     >>>                      
>     ------------------------------------------------------------------------
>     >>>                       From: Ken Laskey
>     [mailto:klaskey@mitre.org <mailto:klaskey@mitre.org>]
>     >>>                       Sent: 04 September 2005 21:22
>     >>>                       To: Chiusano Joseph
>     >>>                       Cc: SOA-RM
>     >>>                       Subject: Re: [soa-rm] Amazon.com
>     <http://Amazon.com>
>     >>>                       <http://Amazon.com> and Hurricane Catrina -
>     >>>                       Service Context? Service "Veneer"?
>     >>>
>     >>>                       Apple also did this with their iTunes Music
>     >>>                       Store: click the link and you order a
>     donation
>     >>>                       instead of a song.
>     >>>
>     >>>                       This is why I keep insisting on
>     >>>                       differentiating between the service and the
>     >>>                       capability. The underlying capability is to
>     >>>                       collect money for a purpose. The service
>     >>>                       provides the interface for doing that.
>     >>>                       Typically, you invoke the capability
>     through a
>     >>>                       service that enables you to buy a book (or a
>     >>>                       song) but a new service invokes that
>     >>>                       capability (with a new user facing interface
>     >>>                       for Apple; I haven't checked Amazon) to
>     "buy"
>     >>>                       a donation. The power is the capability is
>     >>>                       reusable by making it accessible through a
>     >>>                       different service.
>     >>>
>     >>>                       Now note if I buy something through a
>     service
>     >>>                       that allowed me to specify the UPC code, I
>     >>>                       could buy a donation through their existing
>     >>>                       service with that UPC, i.e. reusing the
>     >>>                       service for a purpose similar to but
>     different
>     >>>                       from its original purpose. In fact, several
>     >>>                       supermarkets around here do support that
>     >>>                       because they have little tear-off tablets at
>     >>>                       the checkout for certain hunger
>     organizations
>     >>>                       and you can hand the clerk a page for
>     $1, $5,
>     >>>                       or $10.
>     >>>
>     >>>                       Many interesting variations and our RM just
>     >>>                       has to capture the concepts that can
>     describe
>     >>>                       any of them. I think I'll mow the lawn and
>     >>>                       think about this some more.
>     >>>
>     >>>                       Ken
>     >>>
>     >>>                       On Sep 4, 2005, at 4:06 PM, Chiusano
>     Joseph wrote:
>     >>>
>     >>>                       One thing that I discovered regarding the
>     >>>                       horrible catastrophe in the Southern US is
>     >>>                       that Amazon.com <http://Amazon.com>
>     <http://Amazon.com> enabled
>     >>>                       people to use its online ordering service to
>     >>>                       make a donation. One could use the
>     credit card
>     >>>                       information that Amazon.com
>     <http://Amazon.com>
>     >>>                       <http://Amazon.com> already had online
>     to make
>     >>>                       a donation in what it called "1-Click
>     >>>                       Donation" (or something similar).
>     >>>                       So instead of placing an order for a
>     book, CD,
>     >>>                       etc., your "order" was your donation,
>     and you
>     >>>                       could view your "order" online, which (as I
>     >>>                       recall) would show the amount that you
>     donated.
>     >>>
>     >>>                       Something that came to my mind is: What
>     would
>     >>>                       this placing of a "new face" on a existing
>     >>>                       service be called? Is it a different context
>     >>>                       for the ordering service? (i.e. in the
>     context
>     >>>                       of Hurrican Katrina) Is it a "veneer"
>     that was
>     >>>                       placed on top of the existing service?
>     None of
>     >>>                       the above?
>     >>>
>     >>>                       Joe
>     >>>
>     >>>                       Joseph Chiusano
>     >>>                       Booz Allen Hamilton
>     >>>                       O: 703-902-6923
>     >>>                       C: 202-251-0731
>     >>>                       Visit us online@ http://www.boozallen.com
>     >>>                       <http://www.boozallen.com/>
>     >>>
>     >>>
>     >>>                       ---
>     >>>                       Ken Laskey
>     >>>                       MITRE Corporation, M/S H305 phone:
>     703-983-7934
>     >>>                       7515 Colshire Drive fax: 703-983-1379
>     >>>                       McLean VA 22102-7508
>     >>>
>     >>>
>     >>>
>     >>>                       This message contains information that
>     may be
>     >>>                       privileged or confidential and is the
>     property
>     >>>                       of the Capgemini Group. It is intended only
>     >>>                       for the person to whom it is addressed.
>     If you
>     >>>                       are not the intended recipient, you are not
>     >>>                       authorized to read, print, retain, copy,
>     >>>                       disseminate, distribute, or use this message
>     >>>                       or any part thereof. If you receive this
>     >>>                       message in error, please notify the sender
>     >>>                       immediately and delete all copies of
>     this message.
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>                       ---
>     >>>                       Ken Laskey
>     >>>                       MITRE Corporation, M/S H305 phone:
>     703-983-7934
>     >>>                       7515 Colshire Drive fax: 703-983-1379
>     >>>                       McLean VA 22102-7508
>     >>>
>     >>>
>     >>>
>     >>>                       This message contains information that
>     may be
>     >>>                       privileged or confidential and is the
>     property
>     >>>                       of the Capgemini Group. It is intended only
>     >>>                       for the person to whom it is addressed.
>     If you
>     >>>                       are not the intended recipient, you are not
>     >>>                       authorized to read, print, retain, copy,
>     >>>                       disseminate, distribute, or use this message
>     >>>                       or any part thereof. If you receive this
>     >>>                       message in error, please notify the sender
>     >>>                       immediately and delete all copies of
>     this message.
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>                       ---
>     >>>                       Ken Laskey
>     >>>                       MITRE Corporation, M/S H305 phone:
>     703-983-7934
>     >>>                       7515 Colshire Drive fax: 703-983-1379
>     >>>                       McLean VA 22102-7508
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>                       This message contains information that
>     may be
>     >>>                       privileged or confidential and is the
>     property
>     >>>                       of the Capgemini Group. It is intended only
>     >>>                       for the person to whom it is addressed.
>     If you
>     >>>                       are not the intended recipient, you are not
>     >>>                       authorized to read, print, retain, copy,
>     >>>                       disseminate, distribute, or use this message
>     >>>                       or any part thereof. If you receive this
>     >>>                       message in error, please notify the sender
>     >>>                       immediately and delete all copies of
>     this message.
>     >>>                   --
>     >>>                  
>     ---------------------------------------------------------------------------------
>     >>>                   / Ken Laskey \
>     >>>                   | MITRE Corporation, M/S H305 phone:
>     703-983-7934 |
>     >>>                   | 7515 Colshire Drive fax: 703-983-1379 |
>     >>>                   \ McLean VA 22102-7508 /
>     >>>                  
>     ----------------------------------------------------------------------------------
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>
>     >>
>     >>
>     >>
>     >>
>     >
>     >
>     >
>     >
>     >
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]