[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Here, Here
Well said Joe.
I SHOULD abstain from comments until then but MAY NOT.
Wes
-----Original Message-----
From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
Sent: September 8, 2005 12:22 PM
To: soa-rm@lists.oasis-open.org
Subject: [soa-rm] RE: My last commnet on this...
A new version of our draft spec is about to come out soon. I can't wait
(meant completely sincerely)...
Joe
Joseph Chiusano
Booz Allen Hamilton
O: 703-902-6923
C: 202-251-0731
Visit us online@ http://www.boozallen.com
> -----Original Message-----
> From: McGregor.Wesley@tbs-sct.gc.ca
> [mailto:McGregor.Wesley@tbs-sct.gc.ca]
> Sent: Thursday, September 08, 2005 12:00 PM
> To: Chiusano Joseph; soa-rm@lists.oasis-open.org
> Subject: My last commnet on this...
>
> Matt, Joe,
>
> I am not talking about orchestration at all.
>
> I am talking about the properties of an abstract service
> which has yet to be defined with any clarity. We should not
> limit (without careful consideration) too much at the top of
> the model.
>
> Wes
>
> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: September 8, 2005 11:29 AM
> To: soa-rm@lists.oasis-open.org
> Subject: RE: [soa-rm] [Duane,need clarification] RE:
> [soa-rm] Amazon.comandHurricane Catrina - ServiceContext?
> Service "Veneer"?
>
> I can actually understand Matt's tone, given that we have
> been through this question (is orchestration within our RM
> scope) over and over again. I think Matt was quite nice about
> it, actually.
>
> Joe
>
> Joseph Chiusano
> Booz Allen Hamilton
> O: 703-902-6923
> C: 202-251-0731
> Visit us online@ http://www.boozallen.com
>
>
> > -----Original Message-----
> > From: McGregor.Wesley@tbs-sct.gc.ca
> > [mailto:McGregor.Wesley@tbs-sct.gc.ca]
> > Sent: Thursday, September 08, 2005 11:23 AM
> > To: mattm@adobe.com
> > Cc: dnickull@adobe.com; Chiusano Joseph; soa-rm@lists.oasis-open.org
> > Subject: RE: [soa-rm] [Duane,need clarification] RE: [soa-rm]
> > Amazon.comandHurricane Catrina - ServiceContext? Service "Veneer"?
> >
> > 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]