[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Loose Coupling
Joe, Your
definition seems reasonable. Wes -----Original
Message----- 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] 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----- 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]