[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
________________________________
From: Hamid Ben Malek [mailto:HMalek@us.fujitsu.com]=20
Sent: Thursday, May 19, 2005 6:47 PM
To: Francis McCabe; Don Flinn
Cc: SOA-RM
Subject: RE: [soa-rm] Corba vs SOA
=09
=09
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.
=20
Regards,
=20
Hamid.
=20
-----Original Message-----
From: Francis McCabe [mailto:fgm@fla.fujitsu.com]=20
Sent: Thursday, May 19, 2005 2:43 PM
To: Don Flinn
Cc: SOA-RM
Subject: Re: [soa-rm] SOA System
=20
Well,
I wasn't aware that CORBA name servers had anything other
than =20
IDLs in them; but be that as it may ...
Is there a problem in recasting CORBA as an SOA? Or casting
SOA as =20
distributed computing?
=20
There will be many factors that affect scalability in the
design =20
of an architecture. The service-orientedness is just one of
those =20
factors. To paraphrase an old maxim, there are few ways to be =20
scalable and many ways to be fragile:)
=20
I.e., SOA is one property of an architecture - the focus on
public =20
interactions etc. etc. To model that we need descriptions,
semantics =20
etc.
To build a high-class SOA, we will need to consider other
things; =20
and we will need to apply the SOA RM to the architecture.
=20
Clear as mud, I guess, as my 'ole pappy used to say.
Frank
=20
=20
=20
=20
On May 19, 2005, at 2:30 PM, Don Flinn wrote:
=20
> Hi Frank
>=20
> 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.
>=20
> You mentioned "the focus on the public description of things".
Is =20
> this
> the only thing that makes an SOA different and what our
reference =20
> model
> should discuss? Even there, again using poor old CORBA, at an
> abstract
> level the CORBA naming service is a public description of
things.
>=20
> What I'm driving at and what we all are trying to grapple with
is =20
> 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 =20
> 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 =20
> model is
> abstracted to such a high level that we are delivering a
reference =20
> model
> for any distributed computing model. Specifically, what are
the
> abstract qualities that distinguish an SOA from a generic
distributed
> model?
>=20
> Don
>=20
> On Thu, 2005-05-19 at 10:57 -0700, Francis McCabe wrote:
>=20
>> And the problem is ...
>>=20
>> 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.
>>=20
>> SOA *is* different from random distributed computing, because
of the
>> focus on public descriptions of things.
>>=20
>> Frank
>>=20
>>=20
>> On May 19, 2005, at 10:20 AM, Don Flinn wrote:
>>=20
>>=20
>>> To All
>>>=20
>>> 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 =20
>>> 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?
>>>=20
>>> Don
>>>=20
>>> On Thu, 2005-05-19 at 09:10 -0700, Francis McCabe wrote:
>>>=20
>>>=20
>>>> Matt, et. al.
>>>> In case this thought has not been raised in future emails
... :)
>>>>=20
>>>> I believe that I am correct in stating that, in practice,
the =20
>>>> best
>>>> aspects of languages like Java is not features such as
inheritance
>>>> but the ease with which applications can be slotted
together. =20
>>>> The key
>>>> feature that enables this Lego(r)-style assembly is the =20
>>>> *interface*. It
>>>> turns out that interfaces make the task of programming
large =20
>>>> systems
>>>> significantly easier.
>>>>=20
>>>> 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 =20
>>>> etc.
>>>>=20
>>>> So, at one level of abstraction, it may be useful to
think of =20
>>>> 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.
>>>>=20
>>>> 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*(tm), semantic interfaces, tons of descriptions.
>>>>=20
>>>> Frank
>>>>=20
>>>> On May 18, 2005, at 7:22 PM, Matthew MacKenzie wrote:
>>>>=20
>>>>=20
>>>>=20
>>>>> Michael,
>>>>>=20
>>>>> On 18-May-05, at 5:55 PM, Michael Stiefel wrote:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> Matt, re your comment that "SO is OO, basically, with
some value-
>>>>>> add infrastructure such as discovery and description."
>>>>>>=20
>>>>>> 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 =20
>>>>>> coupled.
>>>>>>=20
>>>>>> Would you maintain that OO systems that can work with
wire =20
>>>>>> formats
>>>>>> of object systems (such as COM and CORBA) that allowed
runtime
>>>>>> dynamic binding of heterogenous systems fall into the SO
>>>>>> category?
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>> 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!
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>> I love loose coupling...but yeah, I do just view it as "a
good
>>>>> thing", and not a necessary element of SOA.
>>>>>=20
>>>>> -matt
>>>>>=20
>>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>> --=20
>>> Don Flinn
>>> President, Flint Security LLC
>>> Tel: 781-856-7230
>>> Fax: 781-631-7693
>>> e-mail: flinn@alum.mit.edu
>>> http://flintsecurity.com
>>>=20
>>>=20
>>>=20
>>=20
>>=20
>>=20
> --=20
> Don Flinn
> President, Flint Security LLC
> Tel: 781-856-7230
> Fax: 781-631-7693
> e-mail: flinn@alum.mit.edu
> http://flintsecurity.com
>=20
>=20
------_=_NextPart_001_01C55CDD.6C7E3F5C
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40"; xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1479" name=3DGENERATOR><o:SmartTagType =
name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@page Section1 {size: 8.5in 11.0in; margin: 1.0in 77.95pt 1.0in =
77.95pt; }
P.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
COLOR: purple; TEXT-DECORATION: underline
}
P.MsoPlainText {
FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
LI.MsoPlainText {
FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
DIV.MsoPlainText {
FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
DIV.Section1 {
page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2><SPAN=20
class=3D416414001-20052005><Quote></SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2>It suffices to =
only cite one=20
reason which is related to the third SOA principle (“Contracts and =
Schemas”).=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D416414001-20052005></Quote></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D416414001-20052005></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D416414001-20052005>From =
where can we=20
obtain this set of principles, so that we may know the first and second =
as=20
well?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D416414001-20052005></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D416414001-20052005>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2><SPAN=20
class=3D416414001-20052005><Quote></SPAN></FONT></DIV>Corba is =
RPC-based,=20
and the message that goes inside the wire is a binary OO-RPC call.=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D416414001-20052005>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2><SPAN=20
class=3D416414001-20052005></Quote></SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2><SPAN=20
class=3D416414001-20052005></SPAN></FONT> </DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2><SPAN=20
class=3D416414001-20052005>Yes - and SOA operations in general can also =
be=20
RPC-based, or asynchronous. If there is a human interacting with a=20
service-oriented system and they perform a query for information, =
shouldn't=20
that be handled in a synchronous manner?</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2><SPAN=20
class=3D416414001-20052005></SPAN></FONT> </DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2><SPAN=20
class=3D416414001-20052005>Joe</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial size=3D2><SPAN=20
class=3D416414001-20052005></SPAN></FONT> </DIV></SPAN></FONT></DIV>=
<DIV align=3Dleft><FONT face=3DArial size=3D2>Joseph =
Chiusano</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Booz Allen =
Hamilton</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Visit us online@ </FONT><A =
title=3Dhttp://www.boozallen.com/ =
href=3D"http://www.boozallen.com/";><FONT=20
title=3Dhttp://www.boozallen.com/ face=3DArial=20
size=3D2>http://www.boozallen.com</FONT></A></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV><FONT face=3DArial=20
size=3D2></FONT><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px =
solid; MARGIN-RIGHT: 0px">
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Hamid Ben Malek=20
[mailto:HMalek@us.fujitsu.com] <BR><B>Sent:</B> Thursday, May 19, 2005 =
6:47=20
PM<BR><B>To:</B> Francis McCabe; Don Flinn<BR><B>Cc:</B>=20
SOA-RM<BR><B>Subject:</B> RE: [soa-rm] Corba vs =
SOA<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=3DSection1>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">Frank,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">Using Matt's expression, Corba could be put =
in the=20
category of "OO + extra things". Corba is Object-Oriented, has =
discovery=20
services, interfaces, language neutral, a communication bus, and so =
many other=20
features. However, Corba is definitely NOT SOA. Why? There are many =
reasons=20
for this. It suffices to only cite one reason which is related to the =
third=20
SOA principle (“Contracts and Schemas”). Corba does not =
satify the third=20
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.=20
The limitations of OO-RPC calls for applications that go beyond the =
enterprise=20
scope are well known (problems related to very tight-coupling, =
versioning=20
problems, etc…). The third principle in SOA roughly states that =
the calls=20
between SOA services and between a client and an SOA service are all =
XML=20
messages and that only the contrats and schemas are shared between =
services=20
and clients (no RPC interfaces such as those described in Corba by =
IDL, or=20
other OO artifats). The third principle ensures loose-coupling through =
the use=20
of contracts and schemas. This is not the case in=20
Corba.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">Regards,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">Hamid.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">-----Original Message-----<BR>From: Francis =
McCabe=20
[mailto:fgm@fla.fujitsu.com] <BR>Sent: Thursday, May 19, 2005 2:43 =
PM<BR>To:=20
Don Flinn<BR>Cc: SOA-RM<BR>Subject: Re: [soa-rm] SOA =
System</SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">Well,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"> I wasn't aware that CORBA name =
servers=20
had anything other than <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">IDLs in them; but be that as it may=20
...<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"> Is there a problem in recasting =
CORBA as=20
an SOA? Or casting SOA as <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">distributed =
computing?<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"> There will be many factors that =
affect=20
scalability in the design <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">of an architecture. The service-orientedness =
is just=20
one of those <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">factors. To paraphrase an old maxim, there =
are few=20
ways to be <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">scalable and many ways to be=20
fragile:)<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"> I.e., SOA is one property of an =
architecture - the focus on public <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">interactions etc. etc. To model that we need =
descriptions, semantics <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">etc.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"> To build a high-class SOA, we =
will need=20
to consider other things; <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">and we will need to apply the SOA RM to the=20
architecture.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"> Clear as mud, I guess, as my =
'ole pappy=20
used to say.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">Frank<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">On May 19, 2005, at 2:30 PM, Don Flinn=20
wrote:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt"><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> Hi Frank<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> My point was not to discuss CORBA's =
problems or=20
lack of such. (I was<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> one of the OMG/CORBA specification =
chairs during=20
CORBA'S hay-days :-)<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> But to ask at what level of abstraction =
does our=20
RM specify that which<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> makes it a reference model for an =
SOA. I=20
know that an SOA is <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> different<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> from previous distributed models, but =
what=20
qualities in our abstract<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> model do we discuss that makes it =
different from=20
a specification of a<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> generic distributed=20
model.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> You mentioned "the focus on the public=20
description of things". Is <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> this<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> the only thing that makes an SOA =
different and=20
what our reference <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> model<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> should discuss? Even there, again =
using=20
poor old CORBA, at an <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> abstract<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> level the CORBA naming service is a =
public=20
description of things.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> What I'm driving at and what we all are =
trying to=20
grapple with is <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> where<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> on the abstract spectrum should we be. =
At one=20
extreme, one enters the<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> world of metaphysics and the question =
become=20
"What is the meaning of<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> life :-)" My question is simpler, =
maybe.=20
Where on the abstract <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> spectrum<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> should we be to model an SOA as opposed =
to any=20
distributed model? I<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> don't believe that we can produce a =
usable=20
specification if the <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> model is<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> abstracted to such a high level that we =
are=20
delivering a reference <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> model<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> for any distributed computing =
model. =20
Specifically, what are the<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> abstract qualities that distinguish an =
SOA from a=20
generic distributed<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> model?<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> Don<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> On Thu, 2005-05-19 at 10:57 -0700, =
Francis McCabe=20
wrote:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>> And the problem is=20
...<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>> I think that CORBA's problems did =
not come at=20
this level of<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>> abstraction, but in the low-level=20
realization. E.g., IDL is C++ in a<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>> different syntax. It is rigid, and =
not=20
capable of incorporating<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>> descriptions of policies,=20
etc.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>> SOA *is* different from random =
distributed=20
computing, because of the<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>> focus on public descriptions of=20
things.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>> Frank<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>> On May 19, 2005, at 10:20 AM, Don =
Flinn=20
wrote:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> To =
All<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> As we abstract and restrict our =
reference=20
model, I begin to wonder<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> =
what<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> makes this reference model a =
SOA=20
reference model as opposed to say a<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> CORBA reference model. =
CORBA had=20
interfaces as one of its primary<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> constructs and had a specific =
language,=20
IDL, to define the <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> =
interfaces.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> The interfaces were the =
external=20
front-end to Impls, which at our<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> =
level<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> of abstraction were the same as =
services=20
and CORBA had the notion of<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> metadata. It also had a =
Discovery=20
& Advertise entity, the naming<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> service. This comparison =
is not=20
limited to CORBA, but could include<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> DCE, DCOM, J2EE, etc. to a =
greater or=20
lesser extent. So my<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> question =
is;<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> At the level of abstraction =
that we are=20
going, what makes our<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> =
reference<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> model a SOA reference model and =
not a=20
generic distributed computing<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> model? If the answer is =
the latter,=20
is this what the world is<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> =
expecting<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> from =
us?<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> =
Don<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> On Thu, 2005-05-19 at 09:10 =
-0700,=20
Francis McCabe wrote:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> Matt, et.=20
al.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> In case this =
thought has=20
not been raised in future emails ... :)<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> I believe that =
I am=20
correct in stating that, in practice, the =
<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> =
best<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> aspects of languages like =
Java is not=20
features such as inheritance<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> but the ease with which =
applications=20
can be slotted together. <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> The =
key<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> feature that enables this =
Lego®-style=20
assembly is the <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> *interface*.=20
It<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> turns out that interfaces =
make the=20
task of programming large <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> =
systems<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> significantly=20
easier.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> The logical =
development=20
of the type-only interface is the<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> *semantic* interface. But =
in any=20
case, modern SOAs represent one<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> aspect of the trend towards =
focusing=20
on interfaces as a way of<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> controlling complexity and =
enabling=20
rapid development/deployment <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> =
etc.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> So, at one =
level of=20
abstraction, it may be useful to think of =
<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> =
SOAs<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> as a system of interfaces =
that allow=20
architectures to be crossed,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> ownership domains to be =
crossed,=20
different implementation languages<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> to be used, different =
versions to=20
coexists, etc. etc.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> Our task is to =
try to=20
pick out the keystones that bear the SOA<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> hallmark; which seem to me =
to be what=20
we have: services as *action<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> boundaries*™, =
semantic interfaces,=20
tons of descriptions.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> =
Frank<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>> On May 18, 2005, at 7:22 =
PM, Matthew=20
MacKenzie wrote:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>>=20
Michael,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>> On 18-May-05, at 5:55 =
PM, Michael=20
Stiefel wrote:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>>> Matt, re your =
comment that=20
"SO is OO, basically, with some value-<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>>> add infrastructure =
such as=20
discovery and description."<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>>> Now this raises an=20
interesting point in our definition of =
service<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>>> abstraction. =
Normally people=20
cite as one of the differences<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>>> between SO and OO =
the fact=20
that the former is more loosely <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>>>=20
coupled.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>>> Would you maintain =
that OO=20
systems that can work with wire <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>>>=20
formats<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>>> of object systems =
(such as=20
COM and CORBA) that allowed runtime<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>>> dynamic binding of=20
heterogenous systems fall into the SO =
<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>>>=20
category?<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>> I maintain that in =
certain=20
situations that they *could* fall into<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>> the SO category. =
I think=20
that the "loosely coupled" argument is<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>> sort of weak, because I =
am not=20
completely certain that even things<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>> like web services end =
up creating=20
loosely coupled systems!<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>>> Or do you see =
looser coupling=20
as a useful feature that is much<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>>> more easily =
achieved with=20
newer implementation technologies such<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>>> as Web services, =
and=20
therefore have nothing to do with SO.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>> I love loose =
coupling...but yeah,=20
I do just view it as "a good<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>> thing", and not a =
necessary=20
element of SOA.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>>>=20
-matt<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> -- =
<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> Don =
Flinn<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> President, <st1:City =
w:st=3D"on"><st1:place=20
w:st=3D"on">Flint</st1:place></st1:City> Security=20
LLC<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> Tel:=20
781-856-7230<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> Fax:=20
781-631-7693<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>> e-mail:=20
flinn@alum.mit.edu<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>>>=20
http://flintsecurity.com<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">>>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> -- <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> Don Flinn<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> President, <st1:City =
w:st=3D"on"><st1:place=20
w:st=3D"on">Flint</st1:place></st1:City> Security=20
LLC<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> Tel: =
781-856-7230<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> Fax: =
781-631-7693<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">> e-mail:=20
flinn@alum.mit.edu<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">>=20
http://flintsecurity.com<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">><o:p> </o:p></SPAN></FONT></P>
<P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
style=3D"FONT-SIZE: =
10pt">><o:p> </o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></=
HTML>
------_=_NextPart_001_01C55CDD.6C7E3F5C--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]