Base de données en tant qu'antipattern IPC

Question

J'ai écrit une application Web en couches composée d'un client Web riche (PHP) qui interagit avec un service Java. Le client Web est hébergé sur un serveur Apache et le service Java s'exécute sur la même machine physique (pour réitérer: l'application entière, le client et le service, s'exécutent sur la même machine physique).

Demande d'utilisateur -> DB < - Poller -> RequestHandler -> StoreResult dans DB -> page de mises à jour Web Client avec le résultat (AJAX).

La communication entre le client et le service utilise une base de données relationnelle pour transmettre des messages. Le service Java dispose d'un scrutateur à thread unique qui recherche et traite les messages/demandes du client. Le système fonctionne, mais je ne suis pas confiant dans mon choix de conception.

Quelqu'un a-t-il des commentaires à propos de cette stratégie? J'ai lu que l'utilisation d'une base de données comme antipattern IPC est une mauvaise pratique, ou du moins inappropriée. Cependant, les alternatives - XMLRPC, pipes nommées - semblent impliquer des dépendances supplémentaires.

Merci de votre visite.

Answer 1

Si c'était moi, et j'avais besoin de PHP pour récupérer/consommer des données d'un service Java, je viderais la base de données. Avoir le service java w/écoute HTTP sur 127.0.0.1, port 5544 (ou un certain # aléatoire). Demandez à une servlet/jsp de prendre des requêtes RESTful et de cracher des résultats JSON. Donc, si c'est une recherche, l'URL serait:

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

et le résultat serait simple JSON:

{ "ville": "Denver", "Etat": "Colorado"}

puis sur le côté PHP faire une requête curl - construire l'URL avec les paramètres de l'entrée utilisateur, faire la requête curl, récupérer les données et json_decode ($ result_array = json_decode ($ curl_result);).

Ce serait simple. De cette façon, vous pouvez facilement tester l'un ou l'autre des composants (faites un curl/wget depuis la ligne de commande pour tester le service java, ou vérifiez les access_logs côté serveur pour voir les paramètres de recherche et la connexion du client). Pour le côté PHP, utilisez curl_exec et json_decode (recherchez ces fonctions dans le manuel PHP).

Voici un lien au hasard que je trouve pour le côté java:

Parsing JSON data with java servlet struts

De cette façon serait évolutive (il est facile de séparer les services), modulaire (facile à tester l'un des composants), et beaucoup plus rapide pour livrer les résultats au client.

Answer 2

Je vois les arguments suivants pour DB IPC:

1) Vous devez conserver tous (ou pendant une certaine période) les messages que vous avez jamais reçu.

2) Vous avez besoin d'une grande fiabilité et ne voulez pas perdre de messages.

3) La performance des côtés opposés de DB est très différente. De cette façon, le côté client peut générer énormément de messages et de nombreux clients du côté droit les traiteront. Donc DB est comme un équilibreur de charge passif avec une grande fiabilité.

Avez-vous besoin de l'une de ces fonctionnalités? Je pense que non. Vous ne pouvez pas l'utiliser comme équilibreur de charge car tous les processus sont sur le même hôte. Et je pense que vous n'avez pas besoin de stocker toutes les demandes Web.

Dans ce cas, je choisirais des douilles simples.

Answer 3

C'est un hack, mais cela fonctionne évidemment pour vous. Here is a web site sur la façon d'implémenter une file d'attente de messages avec une table DB en PHP.

Answer 4

Si vous avez juste besoin de passer des messages pour PHP, utilisez simplement ActiveMQ - tout comme les files d'attente de messages dans UNIX IPC. Toutefois, la base de données peut être un bon équivalent de mémoire partagée et de sémaphores connus sous UNIX IPC. Donc, ayant ActiveMQ et base de données, vous pouvez faire la même chose que vous pourriez faire avec UNIX IPC, mais il peut être mis en grappe si un serveur sera trop petit pour vous.