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