Object orientation has been around for a long time and seems the de facto standard for any new development project. It has helped the development community to develop reusable components, replacing `good old’ procedural designed software. This software was hard to maintain and, except for useful libraries, was far from reusable.
Having arrived in the `age’ of SOA the focus has shifted from reusable components to business processes and reuse of services. In essence SOA is about the flow of data inside a business process across several services.
The figure shows a simple business process.
There are two services used in this business process: [DetermineInvoices] and [Deliverproducts]. The state of the process between services is determined by the data that flowed from the service DetermineInvoices. One can say that the process is data-driven. Many of the services will be implemented in an object oriented language but the business-process is only interested in the service response, which is just structured data. The process is ignorant regarding the object structure serving up the service.
This leads us to the question whether the services should actually be build according to an OO design. Do we really need living objects when the sole responsibility of the service is to transfer the requested data to their destiny? There is really no user interaction on the instantiated objects during a service request so why bother having those objects around? Only when dealing with an user-interface living objects are really handy, as we can modify them, turn them around, change their color and so on. This is also the place where all those wonderful design patterns find their origin. However services should be implemented as simple as possible. One could argue that changing insight will require the implementation of a true domain model, but in practice domain models never last and will most likely get corrupted with time. The data driven design is most likely much simpler and easier to implement.
