February 09, 2003

Presentation: A Comparison of Service-Oriented, Resource-Oriented, and Object-Oriented Architecture Styles

My colleagues at CapeScience.com have now uploaded the slides for my new presentation to be giving next week in Munich, Germany and in April in Philadelphia, PA, so take a look.

Title: A Comparison of Service-Oriented, Resource-Oriented, and Object-Oriented Architecture Styles

Abstract:

This talk compares and contrasts the three common software architecture styles used in distributed systems and XML Web Services. In particular, the key differences between traditional SOAP and REST styles are explored. Guidelines are presented on which style is most applicable for certain application scenarios, and when a combination of styles is necessary.

As always, feedback and comments are very welcome.

Update: The original copy on the Cape Clear website has disappeared, but here's an archited copy of the presentation:
http://www.thearchitect.co.uk/presentations/arch-styles/3-arch-styles.pdf

Posted by Jorgen Thelin at February 9, 2003 11:00 PM - [PermaLink]
 
Comments
Hmmm, I don’t know if you still read comment on this, especially from some Oxonian stranger.. Slide 23 - Service-Oriented Architectures 1 Cookies are good for storing session info about an end-user browser, but are out of place with Web Services. I agree with the WS-I basic profile on this one “R1121 An INSTANCE SHOULD NOT require consumer support for Cookies in order to function correctly. “ and “Being designed for hypertext browsing, Cookies do not have well-defined semantics for Web services, and, because they are external to the SOAP Envelope, are not accommodated by either SOAP 1.1 or WSDL 1.1.” Slide 37 – (?) I'm still waiting for the "Web Services vs. Object Orientation" slide. As you have masterfully explained in a recent paper, interoperable web services can’t rely on remote object references. This put Web Services somehow in competition with distributed object technology as enabler of distributed Client-Server architectures. But when you take away remote object references, you still need something to allow clients to communicate with stateful service instances. Searching for scope left to object orientation in a web service world, one could imagine a Web Service based client-server architecture in which coarse grained services are implemented in an OO fashion. On the other hand when you take away remote object references you still need something to access stateful service instances, for example a Purchase Order Number or other meaningful business data. But having a stateless Facade handling instance routing, usually compromise the oo-designed web service, making it tightly Internally coupled. Furthermore Oasis BPEL4WS and various Ibm/Microsoft security roadmaps seems to be implicitly driving toward fine grained web services, that are even less OO prone! So if we end up basing the overall client-server architecture on Web Services, and if we opt out from using OO inside web services implementations, where's the scope left for OO? This is what I call The object-service impedance mismatch. Where are we heading to? I think we are about to witness The Twilight of OO. Shouldn’t you write about it? ;-) Posted by: Marco Adragna on May 23, 2003 11:42 AM
I think is really difficult to achieve security using a completely new programming paradigm. In the last decades, a great wealth of knowledge has been accumulated on object-oriented design. Such knowledge is partly condensed in the form of Design Patterns and is widely available for businesses, both as mature software development environments and as skilled OO software developers. One knows how to go for application security in distributed OO . With .Net, Microsoft has left the road of distributed object-orientation, (almost) dumping DCOM and advising against J2EE. It could be argued that messaging is inherently better than OO for distributed computing because it increase reliability (receiver can be down) and performance (client doesn't block). It might be the right long-term road, yet in the short term Indigo is a wholly new paradigm that might make it more difficult for the average programmer to understand how to write secure application. In May 2003 I commented your “Comparison of Service-Oriented, Resource-Oriented and Object-Oriented Architecture Style” saying that: “We are about to witness The Twilight of OO. Shouldn’t you write about it?” Now It’s time to say: We are moving toward the end of distributed OO, Shouldn’t you explain us why? Posted by: marco on December 2, 2003 01:58 AM