[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Here, Here
Ok, that's fair enough.
On 9/8/05, McGregor.Wesley@tbs-sct.gc.ca < McGregor.Wesley@tbs-sct.gc.ca> wrote:
- 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