Last week, I posted the following facetious comment about Service Oriented Architecture (SOA).<\/p>\n\n\n\n
\nPosted By: Ben Eng on May 24, 2004 @ 09:27 PM in response to Message #123260<\/a><\/p>\n\n\n\n
Strip all the behavior off of our domain objects. Define data structures to pass around. Provide sets of operations as stateless services, which perform functions on data, and return data to its callers. That sounds revolutionary.<\/p>\n\n\n\n
All we have to do now is eliminate the object-oriented programmers, and the revolution will be complete.<\/p>\n<\/blockquote>\n\n\n\n
There is a serious side to the issue. The recent popularity of SOA should give object oriented programmers much pause. Where do objects fit in the world of services? Are objects pass\u00e9?<\/p>\n\n\n\n
In the book Bitter EJB<\/a> (p.57), the distinction is made between service-driven and domain-driven approaches. I am strong proponent of domain-driven approaches. However, maybe three years ago, I began feeling that a purely domain-driven approach was awkward for modeling object graphs with very sophisticated global constraints. This is a natural topic of interest, considering that I model telecommunications networks for a living.<\/p>\n\n\n\n
Factoring out the global constraints, instead of embedding them within the domain objects, seemed natural. I started to develop stateless session local interfaces (using plain old Java objects, not EJB), which use domain objects as parameters and return values. Then I found myself adding conversational state to the session objects. I’m not sure, where I’m going with this yet. We’ll see after a few more weeks or months of experimentation.<\/p>\n\n\n\n
After having developers fumble around with EJBs for the past four years, I am becoming disillusioned with the technology. XML and Web Services is going even further down the road of coarse-grained distributed components, which are a consequence of high latency due to expensive data marshaling and remote communications. Whenever EJB or Web Services is involved, the client code looks like garbage – calling functions on data, rather than methods on objects. Optimizing the interface to reduce client-server round trips pollutes the interface, until it also looks like garbage; objects become so polluted with denormalized data that the concepts are no longer recognizable. When faced with sophisticated object graphs, rather than simple services, the approach leads ultimately to garbage and more garbage. I’m tempted to call the approach Garbage Oriented Architecture, rather than SOA.<\/p>\n","protected":false},"excerpt":{"rendered":"
Last week, I posted the following facetious comment about Service Oriented Architecture (SOA). Posted By: Ben Eng on May 24, 2004 @ 09:27 PM in response to Message #123260 Strip all the behavior off of our domain objects. Define data structures to pass around. Provide sets of operations as stateless services, which perform functions on … Continue reading OOPs, here comes SOA (again)<\/span>