Re: [soa-rm] SOA System

[Duane Nickull <dnickull@adobe.com>]

I also find this interesting topic and do not have the answers at this time.

Duane

Christopher Bashioum wrote:

> Duane,
>
>I find this thread very interesting.  I have been of the opinion that one
>could implement an SOA using CORBA.  In the book "Understanding SOA with Web
>Services" but Eric Newcomer and Greg Lomow - they mention the following:
>"Many CORBA deployments are SOAs ..."  Taken in context he is discussing the
>difference between using CORBA vs. using Web services to build SOAs - but it
>is very clear throughout this book, and in other literature that many people
>consider CORBA to be an early implementation of SOA.
>
>So ... I am not defending this position just yet - but I am asking the
>question "how is CORBA not an SOA?"
>
>-----Original Message-----
>From: Duane Nickull [mailto:dnickull@adobe.com] 
>Sent: Thursday, May 19, 2005 10:47 PM
>Cc: soa-rm@lists.oasis-open.org
>Subject: Re: [soa-rm] SOA System
>
>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
>>>      
>>>
>>
>>    
>>
>
>
>
>  
>