samedi 9 mars 2013

Stub/Skeleton pourquoi?

Comme je l'ai déjà expliqué dans un précédent post RMI est une technologie qui permet l'invocation de méthodes sur des objets distants.

Dans ce type d'invocation, les objets sont hébergés sur un serveur RMI distant. Celui-ci les rend accessible depuis l’extérieur en les publiant dans un annuaire (RMI registry).
Il est alors possible pour un client d'obtenir une référence à ces objets en faisant une recherche dans cet annuaire (lookup).

Stub pourquoi?

La référence retournée par le serveur lors d'un lookup n'est pas vraiment celle de l'objet distant.
En effet, le serveur RMI renvoie un proxy. Ce proxy va réaliser pour le client les opérations liées aux caractères distribué et éventuellement réparti (load-balancé si je peux me permetre :-)) des appels de méthodes. Ce proxy qui s’exécute coté client est appelé Stub.

Skeleton pourquoi?

Coté client, les appels de méthode se font sur l'objet stub. C'est au stub que revient la charge de réaliser l'appel sur l'objet distant coté serveur. cet objet coté serveur est le skeleton ou tie.
Dans la technologie EJB, le skeleton est un autre proxy qui implémente les services du conteneur EJB tels que la sécurité, la concurrence et la gestion des transactions.

On dit souvent en informatique qu'un diagramme clair et compréhensible vaut bien des discours.
Je suis bien d'accord :-), j'espère juste que mon diagramme sera assez clair pour tout le monde.


samedi 20 octobre 2012

DTOs pourquoi ?

Les DTOs ou Data Transfert Objects sont des POJOs Java servant à véhiculer des données la plupart du temps entre la couche présentation et la couche métier au sein d'une même application. Certains les appellent Value Objects (VO), d'autres Beans en réference à la spec java beans.

DTOs pourquoi?

Ce pattern a été mis en place avec l'arrivée des spec EJB 1.x, CMP et les fameux et très controversés entity beans. En effet les entity beans étaient des EJBs à part entière avec une interface locale ou distante et n'étaient pas sérialisables! C'est là que se trouvait le problème.
Il était donc impossible de faire passer par le réseau un entity beans lors d'une communication de type remote. Il fallait pour cela copier l'entity bean dans un nouvel objet sérialisable afin de pouvoir le faire transiter : le DTO.
Par ailleurs, pour les utilisations des entity beans via leurs interfaces locales, un entity bean restait toujours connecté, s'il était transmit tel quel à la couche présentation, toute modification de l'objet par cette dernière aurait pour conséquence une mise à jour directe de la donnée en base.

Le DTO est-il vraiment mort?

La persistance est sortie des specs EJB 3.0 et 3.1, et est portée par la spec JPA. une entitée JPA est un POJO avec des métadonnés (annotations) permettant au moteur de persistance de persister le POJO en base de données. Ces POJO sont sérialisables et donc véhiculables à travers le réseau, de plus, la notion de scope de persistance permet de garantir que les POJOs retournés en sortie d'une méthode sont automatiquement déconnectés de la base par exemple.

Le pattern DTO n'est donc plus obligatoire, il reste selon moi toujours utile lorsque l'affichage d'une page nécessite un ou plusieurs sous ensembles d'entités différentes. Le DTO permet dans ce cas d'avoir un objet d’agrégation et de ne renvoyer à l'IHM qu'un seul objet contenant par contre toutes les informations nécessaires à l'affichage.

samedi 28 juillet 2012

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 :-)

lundi 16 juillet 2012

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é.