[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)
This is a housekeeping item.
I would like to suggest this thread to converge with the other now entitled
What is SOA (Really???) [was: David Linthicum Says: "ESB versus
Fabric.Stop It!"]]
We should also truncate the [was: David Linthi....] bits too.
since they are both now focusing on the core tenets of SOA.
Duane
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 <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 <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]