How to setup communication between frontend and backend programs

Question

I am working on a perl backend project which performs operations based on input supplied by a JSP web app. Both are running on a linux based server. After performing the requested operations, the backend needs to send confirmation/acknowledgement of the same to the frontend - and this needs to happen in realtime.

I was advised to use files as a means for communication between these frontend and backend programs. As per the design, there would one file for frontend to backend messages and another for the reverse, i.e., backend to frontend messages. Both would be read on a continuous basis by the frontend/backend processes which will take the appropriate action based on control messages read from these files.

The code for this has not been written yet, as I am still unsure if this is the best way to do it. I have heard of Inter-Process Communication but not really sure of how to implement it in my case. I am really new to this sort of thing and am looking for advice/suggestions or a good reference which would point me in the right direction towards solving this problem.

Answer 1

If I understand your question correctly, you have two separate applications that run on your server.

1. Application A is an application server or servlet engine (e.g. Tomcat) which hosts a web application that consists of JSP pages.
2. Application B is some PERL based backend application.

Now A wants to communication with B. Correct?

I agree with the BarneySchmale and his comment. I would not implement the communication based on input/output files. First, because this forces you that both applications have read/write access on the same files, which makes the setup not very scalable. Second, because you always have to listen for changes in the files. This could be tricky to implement in a performant way for synchronous communication.

My advice would be to do the communication via HTTP calls from application A to B. You could for example use a RESTful approach. There should be plenty of libraries to help you implement this. It is scalable, means if you decide to put application B on a different server it still works. You can put firewalls between them, switch to secure communication, no problem. And it is relatively easy to debug.

Of course, there are some questions to consider before choosing the final architecture, like:

• Is the direction only one way: frontend sends a request to the backend and backend sends the response, or are there cases, where the backend must instantiate the communication?
• What happens if the backend is down or not responding? Does the frontend have to queue the requests or is it enough to show an error in the frontend?
• Do you really need synchronous communication all the time? Sometimes asynchronous calls are more user friendly as the fronted is not forced to wait for the response.

Of course, if you start with asynchronous communication you must have some kind of queing. Or even a message broker between application A and B, if it gets complex.