For my current project (an enterprise application for a well known big oil company) I have chosen the SOA approach as the base for the application architecture. At this moment I have to put emphasis on the word “application” architecture (SOA as Service Oriented Application supporting SOA as Service Oriented Architecture), thus a way of writing SOA enabled applications that leverage ideas of services not only for EAI purpose but also, and as the main approach, internally. The main problem about SOA in my opinion is the idea of some architects to define it as the way of integrating applications within enterprise and to completely forget about the architecture of those applications (not all of them are old legacy systems, some of them have to be re-written or re-designed - there is a big need for an application architecture that supports SOA).

So to leverage SOA I have decided to structure my application on business processes basis, not on development layers basis. In this way I have defined services for calculating, manipulating data etc. I was able to talk with the business guys using their language. Of course internally all my services use n-tier architecture with clear data and business layers, but as I said I was able to hide those “details” from the business guys. Secondly this approach made it possible to easily structure my development team. Due to the fact that SOA clearly defines the owner of the process and data, there ware no problems to set up developer groups on that “ownership basis”. So far, everything was brilliant…

The problem that I have faced was the ownership of business entities. For the data and business layers of services there is not such challenge, we can clearly define the owner. But the entities that are based on OO principles are much more complicated. Lets take an example of a customer entity, which has to be “combined” with a contract entity. I would expect to be able to have within the customer entity a collection that contains all contracts entities of this customer. In the other way I would expect that the contract entity would contain the information about customer entity… Both information (about customers and contracts) will than have to be loaded by two separate services (due to ownership assignment); lets say Customers Service and Contracts Service… And that is the breaking point. One of the main principles of SOA is the independence of services.

Ok, lets say we would build some kind of intermediary service to consolidate those both services, to be able to fill our customer or contract service. But this causes next big problem. The methods responsible for filling entities should always deliver, I would call it, a “full loaded” entity. It is a bad idea to do it partially and to leave the responsibility of assuring the deterministic way of filling entities on developers’ shoulders. It will be always error prone.

Next problem are additional services, which also have to combine “their” entities with the “foreign” entities from other services like, lets assume, Billing Service that would own a payment entity which should also contain the customer entity…

Yes I had a problem… The whole SOA was suddenly only a buzzword for me…

But wait for the second part: SOA vs. Business Entities Part 2/2 (The Peace)