Re: [soa-rm] SOA System

[Don Flinn <flinn@alum.mit.edu>]

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