Mutualiser un MDS de type FileStore entre plusieurs applications composites

Le MetaDataStore ou MDS est à la SOA Suite ce qu'est une cour commune à une co-propriété (bon..je sais j'aurrai pû faire mieux mais j'avoue que je séchais un peu :-)). Il a pour but de centraliser et de mutualiser des ressources nécessaires à plusieurs composites. Ces ressources sont stockées dans l'infrastructure SOA Suite puis rendues disponibles au runtime pour les applications composites. Ces ressources peuvent être de tout genre : fichier texte, xsd, wsdl, fichier xml etc.
Dans la définition du composite (composite.xml) on fait alors directement appel à la ressource depuis le MDS en utilisant le protocole oramds.

Le MDS devient alors une partie intrinsèque de la définition du composite et est alors nécessaire à sa compilation. Il existe 2 types de MDS :

• Ceux de type DBStore, les ressources sont alors stockées dans le schéma MDS de l'installation SOA Suite
• Ceux de type FileStore, les ressources se trouvent sur le système de fichier local

En mode développement avoir un MDS de type FileStore possède plusieurs avantages :

• Gain en temps sur l'alimentation du MDS, il est plus facile de rajouter un wsdl dans un dossier sur la machine locale que de devoir le faire via une fonction wlst comme c'est le cas avec un MDS de type DBStore
• Gain sur les temps de compilation en évitant de devoir initialiser systhématiquement une connexion à une base de données à chaque compilation

Soit le fichier adf-config.xml décrivant le MDS pour mon application

Ce fichier est propre à chaque application et possède en dur le chemin vers mon MDS en local. C'est là que mon article prend du sens, imaginez que vous ayez une vingtaine d'application (Si si c'est possible et c'est mon cas), il faudrait alors que chaque développeur en local modifie systhématiquement tous les fichier adf-config.xml de toutes les applications. Vous me direz, ben...un bon coup de WinMerge et le tour est joué, c'est vrai mais à chaque fois que de nouveaux projets sont rajoutés et que vous les checkouté depuis votre scm préferré rebelotte.

Si comme moi, rien que cette idée vous herrisse tous les poils du corps alors ma solution va peut être vous interesser.

Voici un fichier adf-config.xml qui comporte une variable. Cette variable est censée représenter pour chaque développeur le chemin de son MDS.


Cette variable peut être valorisée une fois pour toute en rajoutant des lignes dans les fichiers :

• <JDev_HOME>\jdeveloper\bin\ant-sca-compile.xml


Cette modification permet de passer au SCA compiler (scac), en tant que paramètre JVM, la valeur de la propriété ${bpel.mds.root} contenue dans le fichier adf-config.xml
• <JDev_HOME>\jdev\bin\conf\jdev.conf


Cette modification permet à JDeveloper d'ouvrir une application déclarant dans son descripteur adf-config.xml une variable ${bpel.ms.root}

Avec la solution décrite ci-dessus, les descripteurs des applications (adf-config.xml) peuvent être stockés comme tel dans le scm de votre choix. A chaque checkout d'une nouvelle application, plus aucune action n'est necessaire avant de pouvoir builder en local => CQFD :-)

RMI/RPC pourquoi ?

Notre chère plateforme JavaEE tend à la simplification des développements  pour que le développeur n’ait à se concentrer que sur la logique métier qu’il doit implémenter et ne s’attarde pas sur les problématiques techniques que sont la concurrence des accès, la sécurité ou la scalabilité. C’est fort louable, mais mon ressenti c’est que nous « jeunes » développeurs, n’ayant pas forcément l’historique des erreurs du passé, ne comprenons pas vraiment ce que nous faisons aujourd’hui. En effet, nous sommes incapables de faire une analyse technique poussée lors de problèmes critiques.

C’est pour cela  qu’il m’arrive de temps en temps de chercher à savoir qui ou quoi était au commencement, puis de tirer la corde des simplifications pour en arriver à ce que nous avons aujourd’hui.

Je n’ai pas toujours le temps de le faire par ce qu’en entreprise il faut travailler quand même -:) mais dès que je peux je le fais.

Et pour fêter mon premier post je propose de répondre à une petite question :

RMI/RPC pourquoi ?
RMI: Remote Method Ivocation (EJB)
PS : Si vous pensiez au Revenu Minimum d’Insertion en venant sur cette page passez votre chemin J


RPC : Remote Procedure Call (JAX-RPC, JAX-WS)


RMI et RPC sont des modèles de programmation qui s’appliquent aux architectures distribuées. On parle d’architecture distribuée dès lors que l’un des composants de votre application n’est pas hébergé au même endroit que les autres (Autre JVM, autre machine etc.). Comme leurs noms l’indiquent, ces styles architecturaux permettent d’invoquer des services distants.
Ces services sont alors modélisés, « exposés », matérialisés dans des méthodes d’objets distants, localisés sur un serveur d’application par exemple. Ces objets peuvent être enregistrés dans un annuaire (JNDI dans un cas UDDI dans l’autre) puis retrouvés par « lookup ».
Cette modélisation a pour but de masquer le caractère distribué de ces services (on masque le réseau) et d’offrir un modèle de programmation unifié pour le développeur. Ainsi, on sait à peine si on manipule un objet distant ou un objet local. On fera toujours

MonObjet.monService()

pour obtenir un service

A savoir :
RMI est :
- utilisable entre composants Java ou composants java et CORBA grâce au protocole IIOP.
- Peu performant car nécessite sérialisation/désérialisation des objets
En outre, les composants communiquant via RMI/RPC sont fortement couplés de par les messages qu’ils échangent :


Autre alternative : REST
Il existe d’autres façons de modéliser des services distants, notamment REST (Representational State Transfert) ou le modèle du web.
REST est un modèle où tout service est considéré comme une ressource web c'est-à-dire accessible depuis une URL.
Par exemple, le cours de l’action BNP Paribas peut être obtenu à l’adresse suivante :
http://www.bourseenligne.com/bourse/cours/action/bnpparibas
Ce modèle utilise les standards du web en terme de transport c'est-à-dire HTTP, XML sur HTTP ou JSON.
Le réseau n’est pas masqué au développeur :


REST a pour avantage d’utiliser une pile de protocoles plus légère ce qui le rend plus performant. Comme l’exemple le montre, le couplage est lâche entre l’application appelante et le service sollicité.