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