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




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