[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Core Tenets of SOA (Was RE: [soa-rm] Revisiting: Definition of Service Orientation and how it relates to SOA)
> -----Original Message-----
> From: Christopher Bashioum [mailto:cbashioum@mitre.org]
> Sent: Thursday, May 26, 2005 8:49 AM
> To: soa-rm@lists.oasis-open.org
> Subject: RE: [soa-rm] Revisiting: Definition of Service
> Orientation and how it relates to SOA
>
> I would say that if you have tight coupling, you don't have
> opaque interfaces - which is a core tenet of SOA.
Has anyone begun a list of what we are discussing as the "core tenets of
SOA"? If not, I would be happy to accumulate this list (without regard
to what should be in or out - we can tackle that at another,
near-future, point).
So far:
1. Opaque interfaces
2. Flexibility
(need to re-review spec for others)
Joe (out of town/off e-mail for rest of week)
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
> Therefore,
> I agree with Joe that if we have tightly coupled endpoints,
> we don't have SOA
>
> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Wednesday, May 25, 2005 9:20 PM
> To: soa-rm@lists.oasis-open.org
> Subject: RE: [soa-rm] Revisiting: Definition of Service
> Orientation and how it relates to SOA
>
> >4. A system that is tightly bound where two endpoints can
> communicate
> >only with each other and not accept any other endpoints into their
> >MEP's may be a bad design but still quality as SOA.
> >Question: If such a system exists and there are dependencies between
> >the endpoints, is it SOA?
>
> Good question - I think it depends on what we consider SOA to
> be (which is the point of this question - I think I'm going
> in circles!;) Can we consider this tight endpoint binding to
> be "tight coupling"? (although not in the sense of the
> coupling between contracts/interfaces that many speak of for
> SOA) If we can't label it "tight coupling", it certainly is
> "restrictive" and "inflexible".
>
> IMO, it's apart from the flexible spirit of SOA - so I would
> say no, it isn't SOA ("say it isn't SOA...")
>
> Q: Is flexibility a characteristic of what we believe SOA to be?
>
> Joe
>
> Joseph Chiusano
> Booz Allen Hamilton
> Visit us online@ http://www.boozallen.com
>
>
> > -----Original Message-----
> > From: Rex Brooks [mailto:rexb@starbourne.com]
> > Sent: Wednesday, May 25, 2005 8:57 PM
> > To: Duane Nickull
> > Cc: soa-rm@lists.oasis-open.org
> > Subject: Re: [soa-rm] Revisiting: Definition of Service Orientation
> > and how it relates to SOA
> >
> > A couple of points I had not arrived at myself. Inline.
> >
> > At 4:28 PM -0700 5/25/05, Duane Nickull wrote:
> > >I love this question - very tough to answer ;-)
> > >
> > >Metz Rebekah wrote:
> > >
> > >>Service Orientation: "Is that an 'orientation towards
> > services'? If
> > >>so, who is doing the orienting? Is there another position
> > that would
> > >>be opposite 'services'? What would we call that? What's
> the polar
> > >>opposite of services?"
> > >>
> > >It would be interesting to pose this question to the
> > analysts and press
> > >who talk about SOA a lot.
> > >
> > >Collected thoughts so far from this TC?
> > >
> > >1. The opposite of SOA is duplication of functionality in every
> > >application that needs it. (paraphrased from Joseph's
> > comment on "Re
> > >purposing").
> >
> > This, along with the distinction requiring service and service
> > consumer really does a good job of ruling out the "not SOA."
> >
> > >2. The opposite of SOA is procedural duplication of
> > functionality that
> > >is constrained to only being consumed by one process/thread
> > rather than
> > >multiple processes and threads.
> > >3. SOA is more than OO; it is OO with a set of separate
> elements to
> > >address it working over multiple environments.
> >
> > Yes, and is optionally aggregatable without specific inheritance
> >
> > >4. A system that is tightly bound where two endpoints can
> > communicate
> > >only with each other and not accept any other endpoints into their
> > >MEP's may be a bad design but still quality as SOA.
> > >Question: If such a system exists and there are
> dependencies between
> > >the endpoints, is it SOA?
> >
> > Makes sense to me. Yes it is, as long as there is a service and
> > service consumer that are otherwise separate (I won't ask
> that it be
> > extended to subsequent multipurposing the service once
> consumed since
> > that would then be within a single system if the original
> service were
> > not involved.)
> >
> > >I am probably not making sense anymore. Time to quit....
> >
> > Me, too.
> >
> >
> > >Duane
> >
> >
> > Ciao,
> > Rex
> >
> >
> >
> > --
> > Rex Brooks
> > President, CEO
> > Starbourne Communications Design
> > GeoAddress: 1361-A Addison
> > Berkeley, CA 94702
> > Tel: 510-849-2309
> >
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]