Utilisation de Zend Java Bridge – Part 1

Par défaut
Malgré que ce ne soit pas ma tasse de thé, aujourd’hui je vais m’essayer à la rédaction d’un billet un peu technique … je suis plutôt du genre codeur bourru (et barbu) qui a du mal à formaliser ses idées. N’hésitez donc pas à intervenir si vous voyez des erreurs.
Préambule

Je vais vous parler de JavaBridge, un composant où plutôt une fonctionnalité du Zend Server qui, pour faire simple, permet d’utiliser du code Java directement en PHP. A l’aide d’un exemple ces quelques billets vous monteront comment utiliser et structurer votre code afin de le rendre évolutif et mutualisable.

JavaBridge
Comme je le disais juste au dessus, JavaBridge, c’est le moyen d’utiliser des objets Java en PHP. Il existe deux « JavaBridge », le premier prenant la forme d’un module PHP indépendant et l’autre fournit avec Zend Server. Je ne me suis pas penché sur le sujet depuis longtemps mais je crois me souvenir que le premier choix comportait quelques limites, notamment au niveau des performances : une JVM de lancée par processus; Zend Server de son coté ne lance qu’une seule JVM.
Il n’y a pas meilleur exemple que le code :
$date = new Java('java.util.Date');
echo $date->getTime()

Aujourd’hui bon nombre de sociétés orientent leur architecture vers de la SOA pour des raisons de couts et d’évolutivités. Dans ce schéma on imagine donc parfaitement un serveur d’application Java (par exemple JBoss) portant le métier pour ensuite mettre à disposition un ensemble de services. En face, la partie cliente, des applications PHP diverses et variées utilisant des Frameworks (Symfony, Zend Framework) tout comme des CMS (Typo3, Drupal).

Les choses sont en place, un serveur Jboss SOA d’un coté et un Zend Server de l’autre utilisant JavaBridge. L’objectif est donc de consommer des services métiers Java en PHP. Petit exemple extrait de la page de Zend JavaBridge :
// Configuration pour EJB JBoss. Les autres serveurs d'applications Java peuvent nécessiter une configuration différente.
// Notez que le CLASSPATH doit contenir ces classes.
$envt = array(
"java.naming.factory.initial" => "org.jnp.interfaces.NamingContextFactory",
"java.naming.factory.url.pkgs" => "org.jboss.naming:org.jnp.interfaces",
"java.naming.provider.url" => " jnp://yourflowers.com:1099"
);
$ctx = new Java("javax.naming.InitialContext", $envt);

// Recherche de l'objet
$obj = $ctx->lookup("YourflowersBean");

// Ici, nous trouvons un objet - pas de gestion d'erreur dans cet exemple.
$rmi = new Java("javax.rmi.PortableRemoteObject");
$home = $rmi->narrow($obj, new Java("com.yourflowers.StoreHome"));

// $hw contient notre objet bean
$store = $home->create();

// ajoutez une commande au bean
$store->place_order($_GET['client_id'], $_GET['item_id']);
print "Order placed. Current shopping cart: ";

// récupération des données du caddie depuis le bean
$cart = $store->get_cart($_GET['client_id']);
foreach($cart as $item)

// Libére l'objet
$store->remove();

Comme vous pouvez le voir la mise en oeuvre est quand même relativement simple. Maintenant complexifions un peu la chose.

L’environnement de développement
Imaginons que nous ayons à développer une gestion de compte propre au métier d’une société au sein d’un CMS, Typo3 par exemple. Le CMS s’occupe uniquement de l’authentification front-office et nous laissons donc au serveur d’applications Java le soin de porter la gestion de compte qui comportera spécificités propres au métier de la société. Au passage, notre société s’appellera « Paypal ».
Un compte aurait comme caractéristiques le nom, le prénom, la date de naissance et le numéro de compte bancaire de la personne. Il y aurait aussi un autre type de compte, un compte dit « vérifié » où l’on aurait un peu plus d’informations : adresse postal et nom de naissance).
Bien, dans Typo3 nous aurons donc une extension que nous appellerons « gestcompte ». Dans cette extension nous aurons plusieurs plugins, l’un pour afficher les informations du compte (p1) et l’autre pour les éditer (pi2).
Assez rapidement nous allons nous rendre compte qu’une bonne partie du code risque d’être écrit plusieurs fois, notamment tout ce qui est connection au serveur JBoss. Il est aussi fort probable que nous ayons à récupérer l’adresse d’un compte ou tout autres informations depuis d’autres plugins.
Dans ce billet je m’appuie sur un IHM supporté par Typo3 mais la logique est la même que se soit pour une application « from scratch » ou conçue à l’aide d’un Framework. L’exemple est même relativement bidon :)
 
Nous allons donc essayer de développer une « librairie » mutualisable qui s’appuiera sur quelques design patterns. Nous l’appellerons « business-lib« .