[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Loose Coupling
Joe
Here's a quote attributed to Anne Thomas Manes in TechTarget:
According to Anne Thomas Manes, a vice president and research director
at Midvale, Utah-based Burton Group, an SOA fabric is really just a
managed communication environment.
"At a minimum, [an SOA fabric] needs to have Web services management and
Web services registry functionality built into it," she said.
I hope that Anne was quoted correctly.
Don
On Thu, 2005-05-19 at 22:37 -0400, Chiusano Joseph wrote:
> ?
> Can someone please provide what they believe to be a definition of
> "SOA Fabric"? By this I don't mean "I don't know what it is so I am
> seeking meaning", but rather "I am not sure that we are all in
> semantic alignment/agreement for this term".
>
> I will start with my definition: "A SOA Fabric is an abstract concept
> to represent the environment in which a service within a service-
> oriented system resides, is discovered, is invoked, and is evolved."
>
> Please poke lots of holes in it.:)
>
> Joe
>
> P.S. I didn't even get into the notion of a "SOA Fabric Softener":p
>
> Kind Regards,
> Joseph Chiusano
> Booz Allen Hamilton
> Visit us online@ http://www.boozallen.com
>
>
>
> ______________________________________________________________
> From: Rex Brooks [mailto:rexb@starbourne.com]
> Sent: Thursday, May 19, 2005 10:15 PM
> To: Hamid Ben Malek; Michael Stiefel; soa-rm@lists.oasis-
> open.org
> Subject: RE: [soa-rm] Loose Coupling
>
>
> I don't actually intend to get into this, but I wanted to
> point out, Hamid, that you are assuming or presuming that we
> all go along with concept of an SOA Fabric as the best, or
> even one of the contenders for the best working description
> and governance model for SOA. I don't happen to subscribe to
> that viewpoint, nor do I subscribe to the Enterprise Service
> Bus Model. However, there are important concepts and modeling
> elements within both of those schools of thought on SOA with
> which I do agree and have every intention of adopting for
> myself, whether or not the TC decides to include those
> concepts in the Reference Model. As for loose-coupling, I
> consider it one of those options best described in a primer or
> as part of a user guide or implementation guide, as a best-
> practice recommendation just because it is more flexible.
>
>
> That doesn't mean that I think all tightly coupled SOAs will
> be inferior, just more limited and difficult to work with.
>
>
> Ciao,
> Rex
>
>
> I would encourage folks to have a look at
>
>
> At 6:17 PM -0700 5/19/05, Hamid Ben Malek wrote:
> > Michael,
> > You have a good analysis; however, you are missing many
> > points. I unfortunately cannot explain this clearly by email
> > because it needs few pages of verbosity. I certainly hope I
> > will have time to write a good article in which I explain
> > these things. I just hope to make the deadline for spec
> > review (next Wednesday) and submit the article along with my
> > reviews included in the spreadsheet. Let me try here to
> > summarize the points you are missing in your analysis below:
> >
> > I believe that in your analysis, the concept of "loose-
> > coupling" is not well understood in its right context. When
> > we talk about loose-coupling in SOA, it refers to a much
> > strict concept that touches directly the boundaries of the
> > services and the service consumers. If the coupling remains
> > inside the SOA Fabric and does not directly touch a service
> > and/or a service consumer, this kind of coupling is not a
> > "coupling" in the context of SOA. For example, when you talk
> > about "policy requirements" and things alike, these concepts
> > are actually handled by the SOA Fabric and not directly by a
> > service and/or a service consumer in the sense that the
> > implementation of it may have to change or accommodate in a
> > certain way to ensure interoperability. The third principle
> > of SOA (about "Contracts and Schemas") is really ensuring
> > the strict concept of "loose-coupling" by pushing any other
> > types of couplings to the SOA Fabric which is able to handle
> > to job and take off the work load from service consumers by
> > using data transformations.
> >
> > Regards,
> >
> > Hamid.
> >
> >
> > -----Original Message-----
> > From: Michael Stiefel
> > [mailto:development@reliablesoftware.com]
> > Sent: Thursday, May 19, 2005 5:37 PM
> > To: soa-rm@lists.oasis-open.org
> > Subject: [soa-rm] Loose Coupling
> >
> > While I agree that in general loose coupling is good in a
> > SOA, the
> > definition of a SOA should not include loose coupling.
> >
> > Loose coupling is a design attribute, and therefore a
> > concrete not an
> > abstract attribute. It is also a question of degree. How
> > much loose
> > coupling you have is a tradeoff among various design
> > factors.
> >
> > In theory you could have a tightly coupled SOA. How? If the
> > policy
> > requirements of the service were so rigid, and tightly
> > patterned after many
> > implementation details, I would consider that a tightly
> > coupled SOA.
> >
> > However, our SOA RM should include the idea of multiple
> > services and the
> > appropriate abstract attributes that go along with that. I
> > would think we
> > could then use that as a reference point to talk about how
> > tightly coupled
> > a particular concrete architecture would be.
> >
> > Michael
> >
> >
> > At 07:48 PM 5/19/2005, Don Flinn wrote:
> > >Hamid
> > >
> > >I agree with your differences between the older distributed
> > models,
> > >where CORBA is an example, BUT I believe that some of the
> > members of the
> > >TC would reject them for inclusion in the RM as being too
> > concrete. For
> > >example, loose-coupling has been rejected by some members
> > as being too
> > >concrete a concept. IMHO this is one of the distinguishing
> > features
> > >that differentiate an SOA from the previous distributed
> > systems.
> > >
> > >Don
> > >
> > >On Thu, 2005-05-19 at 15:46 -0700, Hamid Ben Malek wrote:
> > > > Frank,
> > > >
> > > > Using Matt's expression, Corba could be put in the
> > category of "OO +
> > > > extra things". Corba is Object-Oriented, has discovery
> > services,
> > > > interfaces, language neutral, a communication bus, and
> > so many other
> > > > features. However, Corba is definitely NOT SOA. Why?
> > There are many
> > > > reasons for this. It suffices to only cite one reason
> > which is related
> > > > to the third SOA principle (â°Ë†Contracts and Schemasâ
> > °Ëù). Corba does not
> > > > satify the third principle (actually it does not satify
> > other
> > > > principles too). Corba is RPC-based, and the message
> > that goes inside
> > > > the wire is a binary OO-RPC call. The limitations of OO-
> > RPC calls for
> > > > applications that go beyond the enterprise scope are
> > well known
> > > > (problems related to very tight-coupling, versioning
> > problems, etcâ°ËÝ).
> > > > The third principle in SOA roughly states that the calls
> > between SOA
> > > > services and between a client and an SOA service are all
> > XML messages
> > > > and that only the contrats and schemas are shared
> > between services and
> > > > clients (no RPC interfaces such as those described in
> > Corba by IDL, or
> > > > other OO artifats). The third principle ensures loose-
> > coupling through
> > > > the use of contracts and schemas. This is not the case
> > in Corba.
> > > >
> > > >
> > > >
> > > > Regards,
> > > >
> > > >
> > > >
> > > > Hamid.
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
> > > > Sent: Thursday, May 19, 2005 2:43 PM
> > > > To: Don Flinn
> > > > Cc: SOA-RM
> > > > Subject: Re: [soa-rm] SOA System
> > > >
> > > >
> > > >
> > > > Well,
> > > >
> > > > I wasn't aware that CORBA name servers had anything
> > other than
> > > >
> > > > IDLs in them; but be that as it may ....
> > > >
> > > > Is there a problem in recasting CORBA as an SOA? Or
> > casting SOA
> > > > as
> > > >
> > > > distributed computing?
> > > >
> > > >
> > > >
> > > > There will be many factors that affect scalability in
> > the design
> > > >
> > > > of an architecture. The service-orientedness is just one
> > of those
> > > >
> > > > factors. To paraphrase an old maxim, there are few ways
> > to be
> > > >
> > > > scalable and many ways to be fragile:)
> > > >
> > > >
> > > >
> > > > I.e., SOA is one property of an architecture - the
> > focus on
> > > > public
> > > >
> > > > interactions etc. etc. To model that we need
> > descriptions, semantics
> > > >
> > > > etc.
> > > >
> > > > To build a high-class SOA, we will need to consider
> > other things;
> > > >
> > > > and we will need to apply the SOA RM to the
> > architecture.
> > > >
> > > >
> > > >
> > > > Clear as mud, I guess, as my 'ole pappy used to say.
> > > >
> > > > Frank
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On May 19, 2005, at 2:30 PM, Don Flinn wrote:
> > > >
> > > >
> > > >
> > > > > Hi Frank
> > > >
> > > > >
> > > >
> > > > > My point was not to discuss CORBA's problems or lack
> > of such. (I
> > > > was
> > > >
> > > > > one of the OMG/CORBA specification chairs during
> > CORBA'S hay-
> > > > days :-)
> > > >
> > > > > But to ask at what level of abstraction does our RM
> > specify that
> > > > which
> > > >
> > > > > makes it a reference model for an SOA. I know that an
> > SOA is
> > > >
> > > > > different
> > > >
> > > > > from previous distributed models, but what qualities
> > in our abstract
> > > >
> > > > > model do we discuss that makes it different from a
> > specification of
> > > > a
> > > >
> > > > > generic distributed model.
> > > >
> > > > >
> > > >
> > > > > You mentioned "the focus on the public description of
> > things". Is
> > > >
> > > > > this
> > > >
> > > > > the only thing that makes an SOA different and what
> > our reference
> > > >
> > > > > model
> > > >
> > > > > should discuss? Even there, again using poor old
> > CORBA, at an
> > > >
> > > > > abstract
> > > >
> > > > > level the CORBA naming service is a public description
> > of things.
> > > >
> > > > >
> > > >
> > > > > What I'm driving at and what we all are trying to
> > grapple with is
> > > >
> > > > > where
> > > >
> > > > > on the abstract spectrum should we be. At one extreme,
> > one enters
> > > > the
> > > >
> > > > > world of metaphysics and the question become "What is
> > the meaning of
> > > >
> > > > > life :-)" My question is simpler, maybe. Where on the
> > abstract
> > > >
> > > > > spectrum
> > > >
> > > > > should we be to model an SOA as opposed to any
> > distributed model? I
> > > >
> > > > > don't believe that we can produce a usable
> > specification if the
> > > >
> > > > > model is
> > > >
> > > > > abstracted to such a high level that we are delivering
> > a reference
> > > >
> > > > > model
> > > >
> > > > > for any distributed computing model. Specifically,
> > what are the
> > > >
> > > > > abstract qualities that distinguish an SOA from a
> > generic
> > > > distributed
> > > >
> > > > > model?
> > > >
> > > > >
> > > >
> > > > > Don
> > > >
> > > > >
> > > >
> > > > > On Thu, 2005-05-19 at 10:57 -0700, Francis McCabe
> > wrote:
> > > >
> > > > >
> > > >
> > > > >> And the problem is ....
> > > >
> > > > >>
> > > >
> > > > >> I think that CORBA's problems did not come at this
> > level of
> > > >
> > > > >> abstraction, but in the low-level realization. E.g.,
> > IDL is C++ in
> > > > a
> > > >
> > > > >> different syntax. It is rigid, and not capable of
> > incorporating
> > > >
> > > > >> descriptions of policies, etc.
> > > >
> > > > >>
> > > >
> > > > >> SOA *is* different from random distributed computing,
> > because of
> > > > the
> > > >
> > > > >> focus on public descriptions of things.
> > > >
> > > > >>
> > > >
> > > > >> Frank
> > > >
> > > > >>
> > > >
> > > > >>
> > > >
> > > > >> On May 19, 2005, at 10:20 AM, Don Flinn wrote:
> > > >
> > > > >>
> > > >
> > > > >>
> > > >
> > > > >>> To All
> > > >
> > > > >>>
> > > >
> > > > >>> As we abstract and restrict our reference model, I
> > begin to wonder
> > > >
> > > > >>> what
> > > >
> > > > >>> makes this reference model a SOA reference model as
> > opposed to say
> > > > a
> > > >
> > > > >>> CORBA reference model. CORBA had interfaces as one
> > of its primary
> > > >
> > > > >>> constructs and had a specific language, IDL, to
> > define the
> > > >
> > > > >>> interfaces.
> > > >
> > > > >>> The interfaces were the external front-end to Impls,
> > which at our
> > > >
> > > > >>> level
> > > >
> > > > >>> of abstraction were the same as services and CORBA
> > had the notion
> > > > of
> > > >
> > > > >>> metadata. It also had a Discovery & Advertise
> > entity, the naming
> > > >
> > > > >>> service. This comparison is not limited to CORBA,
> > but could
> > > > include
> > > >
> > > > >>> DCE, DCOM, J2EE, etc. to a greater or lesser extent.
> > So my
> > > >
> > > > >>> question is;
> > > >
> > > > >>> At the level of abstraction that we are going, what
> > makes our
> > > >
> > > > >>> reference
> > > >
> > > > >>> model a SOA reference model and not a generic
> > distributed
> > > > computing
> > > >
> > > > >>> model? If the answer is the latter, is this what
> > the world is
> > > >
> > > > >>> expecting
> > > >
> > > > >>> from us?
> > > >
> > > > >>>
> > > >
> > > > >>> Don
> > > >
> > > > >>>
> > > >
> > > > >>> On Thu, 2005-05-19 at 09:10 -0700, Francis McCabe
> > wrote:
> > > >
> > > > >>>
> > > >
> > > > >>>
> > > >
> > > > >>>> Matt, et. al.
> > > >
> > > > >>>> In case this thought has not been raised in
> > future
> > > > emails ... :)
> > > >
> > > > >>>>
> > > >
> > > > >>>> I believe that I am correct in stating that, in
> > practice, the
> > > >
> > > > >>>> best
> > > >
> > > > >>>> aspects of languages like Java is not features such
> > as
> > > > inheritance
> > > >
> > > > >>>> but the ease with which applications can be slotted
> > together.
> > > >
> > > > >>>> The key
> > > >
> > > > >>>> feature that enables this Lego®-style assembly is
> > the
> > > >
> > > > >>>> *interface*. It
> > > >
> > > > >>>> turns out that interfaces make the task of
> > programming large
> > > >
> > > > >>>> systems
> > > >
> > > > >>>> significantly easier.
> > > >
> > > > >>>>
> > > >
> > > > >>>> The logical development of the type-only
> > interface is the
> > > >
> > > > >>>> *semantic* interface. But in any case, modern SOAs
> > represent one
> > > >
> > > > >>>> aspect of the trend towards focusing on interfaces
> > as a way of
> > > >
> > > > >>>> controlling complexity and enabling rapid
> > > > development/deployment
> > > >
> > > > >>>> etc.
> > > >
> > > > >>>>
> > > >
> > > > >>>> So, at one level of abstraction, it may be useful
> > to think of
> > > >
> > > > >>>> SOAs
> > > >
> > > > >>>> as a system of interfaces that allow architectures
> > to be crossed,
> > > >
> > > > >>>> ownership domains to be crossed, different
> > implementation
> > > > languages
> > > >
> > > > >>>> to be used, different versions to coexists, etc.
> > etc.
> > > >
> > > > >>>>
> > > >
> > > > >>>> Our task is to try to pick out the keystones that
> > bear the SOA
> > > >
> > > > >>>> hallmark; which seem to me to be what we have:
> > services as
> > > > *action
> > > >
> > > > >>>> boundaries*?, semantic interfaces, tons of
> > descriptions.
> > > >
> > > > >>>>
> > > >
> > > > >>>> Frank
> > > >
> > > > >>>>
> > > >
> > > > >>>> On May 18, 2005, at 7:22 PM, Matthew MacKenzie
> > wrote:
> > > >
> > > > >>>>
> > > >
> > > > >>>>
> > > >
> > > > >>>>
> > > >
> > > > >>>>> Michael,
> > > >
> > > > >>>>>
> > > >
> > > > >>>>> On 18-May-05, at 5:55 PM, Michael Stiefel wrote:
> > > >
> > > > >>>>>
> > > >
> > > > >>>>>
> > > >
> > > > >>>>>
> > > >
> > > > >>>>>> Matt, re your comment that "SO is OO, basically,
> > with some
> > > > value-
> > > >
> > > > >>>>>> add infrastructure such as discovery and
> > description."
> > > >
> > > > >>>>>>
> > > >
> > > > >>>>>> Now this raises an interesting point in our
> > definition of
> > > > service
> > > >
> > > > >>>>>> abstraction. Normally people cite as one of the
> > differences
> > > >
> > > > >>>>>> between SO and OO the fact that the former is
> > more loosely
> > > >
> > > > >>>>>> coupled.
> > > >
> > > > >>>>>>
> > > >
> > > > >>>>>> Would you maintain that OO systems that can work
> > with wire
> > > >
> > > > >>>>>> formats
> > > >
> > > > >>>>>> of object systems (such as COM and CORBA) that
> > allowed runtime
> > > >
> > > > >>>>>> dynamic binding of heterogenous systems fall into
> > the SO
> > > >
> > > > >>>>>> category?
> > > >
> > > > >>>>>>
> > > >
> > > > >>>>>>
> > > >
> > > > >>>>>
> > > >
> > > > >>>>> I maintain that in certain situations that they
> > *could* fall
> > > > into
> > > >
> > > > >>>>> the SO category. I think that the "loosely
> > coupled" argument is
> > > >
> > > > >>>>> sort of weak, because I am not completely certain
> > that even
> > > > things
> > > >
> > > > >>>>> like web services end up creating loosely coupled
> > systems!
> > > >
> > > > >>>>>
> > > >
> > > > >>>>>
> > > >
> > > > >>>>>
> > > >
> > > > >>>>>>
> > > >
> > > > >>>>>> Or do you see looser coupling as a useful feature
> > that is much
> > > >
> > > > >>>>>> more easily achieved with newer implementation
> > technologies
> > > > such
> > > >
> > > > >>>>>> as Web services, and therefore have nothing to do
> > with SO.
> > > >
> > > > >>>>>>
> > > >
> > > > >>>>>>
> > > >
> > > > >>>>>
> > > >
> > > > >>>>> I love loose coupling...but yeah, I do just view
> > it as "a good
> > > >
> > > > >>>>> thing", and not a necessary element of SOA.
> > > >
> > > > >>>>>
> > > >
> > > > >>>>> -matt
> > > >
> > > > >>>>>
> > > >
> > > > >>>>>
> > > >
> > > > >>>>
> > > >
> > > > >>>>
> > > >
> > > > >>>>
> > > >
> > > > >>>>
> > > >
> > > > >>> --
> > > >
> > > > >>> Don Flinn
> > > >
> > > > >>> President, Flint Security LLC
> > > >
> > > > >>> Tel: 781-856-7230
> > > >
> > > > >>> Fax: 781-631-7693
> > > >
> > > > >>> e-mail: flinn@alum.mit.edu
> > > >
> > > > >>> http://flintsecurity.com
> > > >
> > > > >>>
> > > >
> > > > >>>
> > > >
> > > > >>>
> > > >
> > > > >>
> > > >
> > > > >>
> > > >
> > > > >>
> > > >
> > > > > --
> > > >
> > > > > Don Flinn
> > > >
> > > > > President, Flint Security LLC
> > > >
> > > > > Tel: 781-856-7230
> > > >
> > > > > Fax: 781-631-7693
> > > >
> > > > > e-mail: flinn@alum.mit.edu
> > > >
> > > > > http://flintsecurity.com
> > > >
> > > > >
> > > >
> > > > >
> > > >
> > > >
> > >--
> > >Don Flinn
> > >President, Flint Security LLC
> > >Tel: 781-856-7230
> > >Fax: 781-631-7693
> > >e-mail: flinn@alum.mit.edu
> > >http://flintsecurity.com
> >
>
>
>
>
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-849-2309
--
Don Flinn
President, Flint Security LLC
Tel: 781-856-7230
Fax: 781-631-7693
e-mail: flinn@alum.mit.edu
http://flintsecurity.com
--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]