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