The Process Centric vs. Information Centric approach to SOA

[Latest News Headlines]

 

In his well articulated article, Johan den Haan talks about the merits of choosing an Information Centric approach to your SOA over a Process Centric one.   He writes:

An alternative for the previously presented process centric approach to SOA is, what I like to call, the information centric approach to SOA. This approach attempts to solve some of the problems of the process centric approach. Instead of supporting business processes by defining service orchestrations as fixed flows, the information centric approach supports business processes by defining activities with pre and post conditions. Simply said: each activity in a business process is represented by an implementation of that activity and a pre and post condition for this implementation.

The Process Centric vs. Information Centric approach to SOA

My thinking is that both centricities are good and valid in certain cases.  The traditional ESB/BPEL service/orchestration model is useful in many cases where, for example, and order needs to be taken in, validated, and sent the the various back-end systems that handle the request.  Some of these calls are fire and forget by the fact that these systems are often autonomous and without full SOA API’s.  The BPEL process can manage the various fire-and-forget as synchronous calls with numerous approaches (polling, response queues, etc…).

My take on the Info centric approach is that it strives to make each operation ultra self sufficient because the services need to be built to handle pre and post conditions.  I worry that this approach takes the idea of atomic operations to a whole new level and risks death by over engineering.

Where I do see value is making sure that you have a canonical model for managing and normalizing the shape of the data as it passes through the SOA layer.  Also each atomic service can and should have the appropriate CRUD operations on it.  The service should not have the logic in it to know what to do if a failure is met, but should report that error to the orchestration layer so it can decide what to do.  This is important because the “what to do” can be very context-driven based on who or what is calling that service.

 

Just my thoughts (at this moment) on the subject.



More from the Enterprise Architecture at Oracle Blog ...