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 apologize if you interpreted my tone negatively.

Why bother with SOA if you don't plan to enforce some basic rules of 
reusability?  In the government context, I would expect that reusability 
would be important as a way of reconfiguring business processes in a non 
destructive way.  In fact, as a Canadian citzen...I'd hope that it is 
important :-)

If a service is not composable without context, perhaps the service 
needs to be split up.

*shrug*, YMMV.

-matt

McGregor.Wesley@tbs-sct.gc.ca wrote:

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



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