RE: [soa-rm] Loose Coupling

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

<Quote>
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.
</Quote>

+1

Joe

Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
 

> -----Original Message-----
> From: Michael Stiefel [mailto:development@reliablesoftware.com] 
> Sent: Thursday, May 19, 2005 8: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
> 
> 
>