Re: [soa-rm] comments collected from SOA-RM presentation

[Michael Stiefel <development@reliablesoftware.com>]

I think another big difference
between SOA and OO is that OO views the world as constrained objects
(i.e. a chair has four legs) while SOA view the world as relationships (a
chair is something you sit on, and sitting is a relationship between a
part of the human anatomy and a piece of furniture.

Michael

> 1.  As expected, there was
> considerable discussion on how SOA is different, especially how it
> relates to OO.  Some points from emails, real-time discussions, and
> after discussions for consideration in expanding our discussion in the RM
> follow. 
>
> - Both OO and SOA are as much a way of thinking about representing things
> and actions in the world as these are about the specifics of building a
> system.  The important thing is understanding and applying the
> paradigm.  So the question is not “what is a service?” any more than
> it is “what is an object?”  Anything can be a service in the same
> way anything can be an object.  The challenge is to apply the
> paradigms to enhance clarity and get things done. 
>
> - OO has intentional melding of methods to a given data object.  The
> methods can be thought of as a property of the object.  For SOA, one
> can think of the services as being the access to methods but the actual
> existence of methods and any connection to objects is incidental. 
> The service accesses a capability and the invocation of the service
> generates the real world effect from the capability.  The capability
> can be implemented using OO techniques but this is not required.  A
> data model for a service is exposed through its service description, but
> the implementation of the data model, the service, or the underlying
> capability are opaque to the service consumer.  Thus while an OO
> implementation is possible for the service or the capability, it is not
> required nor does it play an essential role in the use of the service
> itself. 
>
> - You instantiate an object to use it, but you interact with a service
> where it exists. 
>
> - An object exposes structure but no way to express semantics other than
> what can be captured as comments in the class definition.  SOA
> emphasizes the need for clear semantics.