[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Loose Coupling
That is the term I have favored too. From the charter: *Reference Model *- A reference model is an abstract framework for understanding significant relationships among the entities of some environment, and for the development of consistent standards or specifications supporting that environment. +1 D Christopher Bashioum wrote: > I like that better > > ------------------------------------------------------------------------ > *From:* Smith, Martin [mailto:Martin.Smith@DHS.GOV] > *Sent:* Friday, May 20, 2005 6:16 PM > *To:* Christopher Bashioum; soa-rm@lists.oasis-open.org > *Subject:* RE: [soa-rm] Loose Coupling > > “Environment”? > > > > Martin > > > > > > -----Original Message----- > *From:* Christopher Bashioum [mailto:cbashioum@mitre.org] > *Sent:* Friday, May 20, 2005 1:44 PM > *To:* soa-rm@lists.oasis-open.org > *Subject:* 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 > <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 > <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]