RE: [soa-rm] Revisiting: Definition of Service Orientation and how it relates to SOA

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

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