OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm] Core Tenets of SOA


So the attributes we are describing are those of service-orientation and we are creating a RM of an environment that will facilitate/enable/support the realization of those attributes. The environment doesn't guarantee you will receive the benefits (and drawbacks) of those attributes, only that there is a framework which makes seeing those attributes more likely.

Ken


On May 26, 2005, at 10:01 AM, Michael Stiefel wrote:

What makes SOA different from other distributed technologies?

I think it is because SOA offers the possibility of certain benefits. In other words, it is an enabling technology. But SOA does not guarantee these benefits.

Think of the transition from structured programming to objects. Many people's first programs were just structured programming in an OOP language (i.e. writing C style code in C++). It is in the implementation  (i.e. being concrete) not in the SOA abstraction where the benefits are. You can use service orientation and create an architecture that is just as tightly coupled as any other (XML messages that are direct translations of the internal object model of the service, for example).

Among the potential benefits: Interoperability between heterogenous systems, reusability, loose coupling, opacity, business agility, etc. that are greater than in previous architectures (such as OO). I think of service orientation just a further evolution of the ideas behind OO.

However all these things are not absolutes, but exist in degrees, or shades of grey. They are the result of design tradeoffs in concrete architectures. What we need to do is not only list them, but show how the SOA RM makes these things possible.

Michael Stiefel

At 08:56 AM 5/26/2005, Chiusano Joseph wrote:

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


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