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


Title: RE: [soa-rm] Loose Coupling

Joe,
 
I am uncomfortable with the term "system" - as that strikes me as more concrete than architecture.  Did we really agree to use that term?  If so, I guess I just read past that earlier - maybe while focusing on some other point. 


From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
Sent: Friday, May 20, 2005 10:19 AM
To: soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] Loose Coupling

A service-oriented system is a system that is based on SOA principles. I used the term "SOA-based system" a while back, and Duane recommended using "service-oriented system". "Evolved" instead of "managed" is fine with me.
 
Thanks,
Joe
 
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
 


From: Christopher Bashioum [mailto:cbashioum@mitre.org]
Sent: Friday, May 20, 2005 9:55 AM
To: soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] Loose Coupling

Joe,
 
what is a "service oriented system?".  Also, I would be more comfortable with the definition if you dropped the word 'evolved' and added the word 'managed'. 


From: McGregor.Wesley@tbs-sct.gc.ca [mailto:McGregor.Wesley@tbs-sct.gc.ca]
Sent: Friday, May 20, 2005 9:47 AM
To: chiusano_joseph@bah.com; soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] Loose Coupling

Joe,

 

Your definition seems reasonable.

 

Wes

-----Original Message-----
From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
Sent: May 19, 2005 10:37 PM
To: soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] Loose Coupling

 

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



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