Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Re: Major Historical SOA Milestone Today
 <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@s...] Sent: Thursday, May 11, 2006 3:27 PM To: Chiusano Joseph; 'Nathan Young -X (natyoung - Artizen at Cisco)'; 'Bullard, Claude L (Len)'; andrzej@c...; xml-dev@l... Subject: RE: 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/ 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
