Database as IPC antipattern

Question

I've written a layered web application that consists of a rich-web client (PHP) that interacts with a java service. The web client is hosted on an apache server, and the java service runs on the same physical machine (to reiterate: the entire app, client and service, are running on the same physical machine).

User Request --> DB <-- Poller --> RequestHandler --> StoreResult in DB --> Web Client updates page with the result (AJAX).

Communication between the client and service uses a relational database to pass messages. The java service has a single-thread poller, which looks for and then processes any messages/requests from the client. The system works, but I am not confident in my design choice.

Does anyone have any comments about this strategy? I've read that using a Database as IPC antipattern is poor practice, or at least an inappropriate one. However, the alternatives--XMLRPC, named pipes--seem to involve additional dependencies.

Thanks for looking.

Answer 1

If it were me, and I needed PHP to grab/consume data from a java service, i'd dump the DB.

Have the java service w/ HTTP listening on 127.0.0.1, port 5544 (or some random #). Have a servlet/jsp take RESTful requests, and spit out JSON results. So if its a search, the URL would be:

h ttp://127.0.0.1:5544/search_zip_code/80203

and the result would be simple json:

{ "city": "Denver", "state": "Colorado" }

and then on the PHP side do a curl request - build the URL with the parameters from the user input, do the curl request, get the data back and json_decode it ( $result_array = json_decode($curl_result); ).

It'd be simple. This way, you can test either component easily (do a curl/wget from command line to test the java service, or check the access_logs on the server side to see the search parameters and the connection from the client).

For the PHP side, use curl_exec and json_decode (search for those functions in the PHP manual).

Here's a random link I found for the java side:

Parsing JSON data with java servlet struts

This way would be scalable (its easy to separate the services), modular (easy to test either component), and a lot faster for delivering results back to the client.

Answer 2

I see following arguments for DB as IPC:

1)You need to store all (or for some period) messages you ever received.

2)You need high reliability and don't want to loose any messages.

3)Perfomance of DB opposite sides is very different. In this way left client side can generate huge amount of messages and many clients on right side will process them. So DB is like passive load balancer with high reliability.

Do you need any of this features? I think no. You can't use it as load balancer because all processes are on the same host. And I think that you don't need to store all web requests.

In this case I would choose simple sockets.