Core Tenets of SOA (Was RE: [soa-rm] Revisiting: Definition of Service Orientation and how it relates to SOA)

["Chiusano Joseph" <chiusano_joseph@bah.com>]

> -----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
> > 
> 
> 
> 
>