OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm] SOA System


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]