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] What is NOT an SOA?


Greg - 

I agree that a DOA can be epitomized by CORBA.  However, I would look at
CORBA as an implementation of DOA.  I would go back to my distributed
systems learning to focus on "passing of messages between
systems/objects/components as the only means of communication amongst
the parts" as the distinguishing characteristic.   I am wary of
introducing the concept of a naming object as an integral part of a DOA.
I am not convinced that a distributed system identifies a specific way
in which all the parts know about each other.  As an example, I would
consider a P2P system, say the KaZaa network, as a distributed system
that is purposefully without a naming object.  Although there are
bootstrapping mechanisms in place, the system, once functioning, doesn't
rely on those mechanisms for continued operations.  


Now, interestingly, when I read the division between DOA and CBA, the
question comes to mind:  what are the differentiators between an object
of a DOA and a component of a CBA?  Certainly, I would be comfortable
suggesting that a SOA is a distributed architecture (see definition
above), in which a service demonstrates the characteristics of a
component, as you defined in the CBA.  As we drill down, I see the
Client-Server architecture focusing on a different facet of the overall
system, namely the interaction pattern.  Why couldn't a DOA be a CSA?
How about a CBA?

For me, technically, SOA is really about combining the characteristics
of a DOA and a CBA.  I do need to be careful here with semantics because
I do believe that a component view of the world looks at business value
and function from the vantage of modules of code somewhere.  The essence
of SOA is more than the technical aspects, it's also about the
perception of the world.  Thus, I would ask, what is the critical
difference between a component and a service?

I think that's enough rhetorical questioning before lunch.

Rebekah

Rebekah Metz
Associate
Booz Allen Hamilton
Voice:  (703) 377-1471
Fax:     (703) 902-3457


> -----Original Message-----
> From: Gregory A. Kohring [mailto:kohring@ccrl-nece.de]
> Sent: Tuesday, May 31, 2005 6:16 AM
> To: soa-rm@lists.oasis-open.org
> Subject: [soa-rm] What is NOT an SOA?
> 
> Duane's challenge to create examples of software architectures
> which are not SOA still has me a bit puzzled and I wonder if we
> can reach a better understanding of an SOA by determining
> the predecessor of the SOA.
> 
> Three possible predecessors to the SOA:
> 
> Distributed Object Architectures
> 
>     Epitomized by CORBA. In a DOA all the constituents
>     are objects and there exists a naming object for finding objects
>     to satisfy a particular request.
> 
> Component Based Architectures
> 
>     Examples include CCA. In a CBA the components have well defined
>     behaviors, standardized interfaces and their granularity should
>     be such as to encourage reuse.
> 
> Client-Server Architectures
> 
>     An FTP server is a good example. In a CSA, the server encapsulates
>     a set of known behaviors and the client knows how to access
>     the server to activate the behaviors.
> 
> 
> If we claim our SOA RM extends DOA, then our SOA RM should contain
> the extension of an object and the extension of the naming object.
> 
> If we claim our SOA RM extends CBA, then our SOA RM need only contain
> the extension of a component.
> 
> If we claim our SOA RM extends CSA, then our SOA RM should contain the
> extension of the client and the server.
> 
> 
> I am sure others can nominate more examples of base architectures
> to extend from; however, this does not subtract from my conclusion
> that in order to determine what are the minimum constituents for our
> SOA RM, we need to determine where we are starting from and what the
> minimum requirements are to significantly differentiate our SOA RM
> from the base model.
> 
> 
> -- Greg
> 
> --
> ======================================================================
> G.A. Kohring
> C&C Research Laboratories, NEC Europe Ltd.
> ======================================================================


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