The Right Orientation: Object, Service or Resource
We are continuously striving to represent the software concepts in such a way so that we can easily relate them to the real world entities and activities. IT provided automation and tools to create and facilitate a better business environment. Along this journey somewhere the solution (IT) to solve the business problems itself became a problem due to the complexities it created, which paved the way for creating new approaches to solve the business problems. The journey showed us the various styles of software representations and highlighted the differences in thought process in creating the software.
The various styles or architecture approaches so far being used are
- Procedural oriented architecture
- Object oriented architecture
- Service oriented architecture
- Resource oriented architecture
Procedural orientation provided the early automation but created complexities due to the separation of data and operations. Object orientation encapsulated the data and operations (methods) and moved us closer to the real world entities and simplified the programming model. Service orientation moved us even closer to the real world by aligning us to the business processes. The fundamental difference between object orientation and service orientation as I see it is the data vs. process emphasis. Object orientation approaches from the data entities point of view where it creates the objects which can encapsulate the data and methods related to that entity or object. Service orientation approached from the process point of view which encapsulated a process or a number of processes along with the entities participating in that process/s. Resource oriented approach is still evolving and is largely based on the concept of the World Wide Web. Everything that can represent itself and can be addressed by a request is treated as a ‘resource’. Unlike the object a resource does not have a state. Each state of the object itself can be represented as a resource.
There are multiple pros and cons of each of these architecture styles. These architecture styles can co-reside while addressing a business problem. It’s important to have the right business orientation rather than being religious about object or service or resource orientation. In my view, Business Oriented Architecture should be the right orientation and need to be adopted as a guiding principle while providing the IT solution to address the business problem.
Comments
Shreyas
Rightly said, the business orientation is what distinguishes SOA's relative higher levels of acceptance by the business community. I would like to further add a simple dichotomy of the object versus service design approaches, while modeling objects our concentration is on modeling the nouns of the universe with appropriate relationships (hierarchy etc), and verbs take a back seat as internal operations in the nouns, while in services catering to businesses, it is important to identify reusable verbs, which are reusable across maximum nouns.
Regarding the resource oriented architectures (also termed now as WOA - web oriented architecture), one key benefit that is emerging is the relative lightweight nature of the messages being sent across, which is a huge asset from a scalability point of view. However as i have highlighted in the article at http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1278423,00.html
a key issue in WOA is the proliferation of APIs and lack of any standards.
that will be a deterrent in enterprise adoption of WOA
Posted by: Dr. Srinivas Padmanabhuni | June 11, 2008 7:03 PM