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