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