Service Oriented Architecture - Component Responsibility

Question

Working on an ecommerce project whereby a PHP application (back-end & non-customer facing) is currently responsible for processing an order from checkout stage through to generating profit/loss reports, processing the order and also performing various algorithms on behalf of a data science team.

The algorithmic components will be extracted out to a separate application (python). PHP will be sending a json payload via curl through to a python application end-point / passing the payload over to a beanstalk queue or similar. However there is mixed opinion relating to which application is responsible for what.

The python developer wishes for the PHP dev to prepare and send over a large payload (qty, order value, user demographics etc.). Basically everything that the python developer requires in order to perform their algorithms.

The Php developer believes that all the python service requires is the order_id and from this, it can mine all the information it needs to run whatever algorithms it requires from the database. The php developer further argues, that if it is doing all the preparation of the data, then it may as well run the algorithms too as the passing responsibility to the service becomes redundant as much of the work has already been done.

Is there a right or wrong choice? could somebody provide any decent arguments for both sides to consider? Could anybody recommend any resources to assist in understanding of "internal" service oriented architecture?

Answer 1

If the front end is made responsible for the 'large payload' for the processing by the Python back-end then you have a high degree of implementation coupling between the two systems that means maintenance, change management, or refactoring becomes more complex as both sides of the communication require significant interdependent re-engineeering in order to deal with the sending and receiving of the data.

In addition, implicitly, a new data store is being created in the transmission protocols (albeit transitory) as the data is formatted by the front end, transmitted, and parsed by the back-end.

By sending only the index into the data in the database you remove the issue of strong coupling and changes to either end of the process may take place with (usually) little dependence on the other side. You also have fewer places for errors to creep in because there is no formatting of large messages and then the parsing of those messages. In addition you have easy scalability because in future you would be able to add more front-end processing and more back-end processing without being concerned about which front-ends connect to which back-ends (that's all handled by the back-ends reading from a common data store).

This assumes you have, and will continue to have, direct access to the database by both systems i.e. that you're not planning to relocate either sides of the dialogue to remove systems in the future. If you relocate one of the systems away from direct connectivity to the database in future then

Of course the issues of sending large messages like this are manageable (for some systems there is no direct access to a shared database) but they add a layer of complexity that it appears you don't need to consider.

Answer 2

I would try to avoid any solution which requires sharing a database between the front end and a back-end service, because my experience is that shared databases cause a lot more coupling that is much harder to detangle than a complex exchange format does.

I presume the data is initially gathered by the front end and then passed to the service once the order is complete. In this case, tying the back-end service in via the database means that any change in data format is likely to require both front and back end to change.

There are also security implications. It is desirable to run services in as secure an environment as possible; this often means they are run on a separate machine to the front end, which must be exposed to the internet at large. Ideally, we would have a secure database for the service which is not accessible from the front end machine; this minimizes the consequences of a compromise at the front end (preventing a hacker from, say, modifying already accepted orders to add additional items). This is harder to achieve if the service must also access the front end databse. This may not be something you intend to do now, but by choosing to switch to soa you gain this kind of flexibility for future Iimprovements, so it would seem a shame to close them off before you really begin.