RE: [xml-dev] Re: Major Historical SOA Milestone Today

["Chiusano Joseph" <chiusano_joseph@bah.com>]

<Quote>
But if you apply "object oriented" at the level of IT systems in the
large, I believe that what you end up with is 100% equivalent to a
service oriented architecture. 

Or could someone correct me? If I bumped into a service-oriented IT
system in one bank on one side of the street, and an object-oriented IT
system in another bank on the other side of the street, how would I tell
which was which (other than by the choice of jargon on the Powerpoint
slides)?
</Quote>

Here are some thoughts from the OASIS SOA-RM TC (spec and listserv),
followed by my own personal perspectives:

- From OASIS SOA-RM spec: "Unlike Object Oriented Programming paradigms,
where the focus is on packaging data with operations, the central focus
of SOA is the task or business function - getting something done. This
is a more viable basis for large scale systems because it is a better
fit to the way human activity itself is managed - by delegation."

- From a recent thread on the OASIS SOA-RM list: "OO is usually within a
known environment while SOA does not presuppose the same environment and
must have additional components to explicitly facilitate the
functionality of declaring the details the consumer needs."

- From another recent thread on the OASIS SOA-RM list: "OO started out
as a programming paradigm; SOA started out as a architectural paradigm"

My own personal perspectives:

(1) Objects incorporate both data and functionality with objects, while
services incorporate only functionality. 

- With service orientation, functionality (processing) and data are
viewed as separate entities - which means that a single service may
operate on different sets of data. With object orientation, data and
functionality (processing) are tightly coupled in an object instance,
leading to restricted flexibility and agility as compared to service
orientation.

(2) Distributed object technologies (such as CORBA) do not enable
"composition" of objects, as is possible with services.

- With service orientation, one may combine multiple services to create
a "composite service", in which multiple services are invoked at
run-time by a single service (and these services may invoke other
services, etc.). This limitation of distributed object technologies has
led to their being largely superceded by the current SOA paradigm.

(3) With object orientation, there is a tight coupling between objects;
with service orientation, loose coupling is possible.

- With object orientation, updates such as an object name change result
in ripple effects that necessitate system updates; however, with service
orientation, there is a level of "transparency", or loose coupling, that
shields services and systems that interact with other services from
requiring update if updates are made to a service (though there are
limits to this feature). This is largely due to the use of open
standards in service orientation, which yields platform and programming
language independence.

(4) Also, we can think in terms of the 3 primary aspects of object
orientation and how they map/do not map to SOA:

- Inheritance: Will be mappable for Web services (meaning WSDL-based Web
service). WSDL 2.0 (still in process - W3C Candidate Recommendation as
of 27 March 2006) has a feature for interface inheritance through the
"extends" attribute information item.

- Polymorphism: AFAIK, not mappable. That is, there is no standard
mechanism for polymorphism for a Web service (i.e. "service context"). I
foresee the need for a standard for this this in the future.

- Encapsulation: Mappable. Both SOA and OO have the notion of data model
(for SOA a service's data model, for OO an object's data model); also,
with SOA, methods may be exposed as part of a service to access
instances of the service's data model, while with OO, accessor methods
may be exposed to interact with the data. Please note that this
explanation was influenced by comments made by Duane Nickull on the
SOA-RM TC list.

Joe

Joseph Chiusano
Associate
Booz Allen Hamilton
 
700 13th St. NW, Suite 1100
Washington, DC 20005
O: 202-508-6514  
C: 202-251-0731
Visit us online@ http://www.boozallen.com

-----Original Message-----
From: Michael Kay [mailto:mike@saxonica.com] 
Sent: Thursday, May 11, 2006 3:27 PM
To: Chiusano Joseph; 'Nathan Young -X (natyoung - Artizen at Cisco)';
'Bullard, Claude L (Len)'; andrzej@chaeron.com; xml-dev@lists.xml.org
Subject: RE: [xml-dev] Re: Major Historical SOA Milestone Today

> 
> Yes, object oriented is a great example (not to denegrate the others 
> either).

But if you apply "object oriented" at the level of IT systems in the
large, I believe that what you end up with is 100% equivalent to a
service oriented architecture. 

Or could someone correct me? If I bumped into a service-oriented IT
system in one bank on one side of the street, and an object-oriented IT
system in another bank on the other side of the street, how would I tell
which was which (other than by the choice of jargon on the Powerpoint
slides)?

Michael Kay
http://www.saxonica.com/