Re: [soa-rm] SOA System

[Duane Nickull <dnickull@adobe.com>]

Don:

I am satisfied that SOA is different that CORBA, OO, IBD, CBA etc.

It would have been very funny however if during our activity we found it 
wasn't.  I can see the news release now:

"The OASIS SOA RM TC concluded that SOA is no different from a bunch of 
other stuff and recommends everybody just stop talking about it...."

;-)

This TC was really Matt Mackenzie's brainchild.  His thoughts were:

1. If SOA is architecture, as the name implies, how do we define it as 
architecture?
2. What is distinctive about SOA when compared to other architectures?

While the first two hours were a bit scary, we did eventually conclude 
that SOA is unique in it's core composition of elements. 

Duane

Rex Brooks wrote:

> What makes our reference model a SOA reference model? Services.
>
> Services are fairly specific kinds of objects that do something. It is 
> about as close to an actual verb as we get. We'd like it to be 
> something useful, but that is in the eye or infrastructure of the 
> beholder. I don't think we can actually stipulate that at this level 
> of abstraction. An SOA needs a Service and a Service Consumer, in my 
> opinion, to become an architecture, with a small a. A service by 
> itself is more akin to sound of one hand clapping.
>
> While it may have a lot in common with CORBA, and other OO constructs, 
> I think that is pretty specific.
>
> For an SOA with capital A? Do we even want to consider that? I thought 
> we did at the start, but I don't now.
>
> Rex
>
>
> At 2:51 PM -0400 5/19/05, <McGregor.Wesley@tbs-sct.gc.ca> wrote:
>
>> 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
>
>
>