Re: [soa-rm] SOA System

[Francis McCabe <fgm@fla.fujitsu.com>]

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
>
>