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


Don,

For my work, the policies, contracts, metadata and semantics are the key items I require to base a whole of government approach to SOA.

Further to this is the governance aspect that, although not considered here, is critical for an enterprise as large as the Government of Canada.

Wes
-----Original Message-----
From: Don Flinn [mailto:flinn@alum.mit.edu]
Sent: May 19, 2005 1:20 PM
To: SOA-RM
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(r)-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*(tm), 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]