WebSphere Extended Deployment, Version 6.0.x     Systèmes d'exploitation : AIX, HP-UX, Linux, Solaris, Windows, z/OS

ObjectGrid

ObjectGrid est une structure de mise en cache d'objets transactionnels extensible pour les applications J2SE (Java 2 Platform, Standard Edition) et J2EE (Java 2 Platform, Enterprise Edition).

Vous pouvez utiliser l'API ObjectGrid lors du développement d'applications pour extraire, stocker, supprimer et mettre à jour des objets dans ObjectGrid. Vous pouvez également implémenter des plug-ins personnalisés qui surveillent les mises à jour de la mémoire cache, extraient et stockent des données avec des sources de données externes, gèrent la suppression d'entrées dans la mémoire cache et traitent la fonction de mise en cache en arrière-plan pour votre propre environnement d'application ObjectGrid.

API basée sur Map

ObjectGrid fournit une API qui repose sur l'interface java.util.Map. Elle est étendue pour prendre en charge le regroupement d'opérations en blocs transactionnels. Cette interface est un sur-ensemble de l'interface java.util.Map et offre la prise en charge des opérations par lots, l'invalidation, l'association de mots-clés, l'insertion et la mise à jour explicite. La sémantique Java Map est améliorée à l'aide de points d'extension, rendant possible la mise en oeuvre des améliorations suivantes :

[Version 6.0.1 and later] Environnement ObjectGrid

[Version 6.0.1 and later] Vous pouvez utiliser la structure ObjectGrid en installant l'une des offres existantes : Dans les deux cas, ObjectGrid prend en charge les fonctions client/serveur. L'exécution serveur prend en charge la mise en cluster, la réplication et le partitionnement des caches d'objets distribués. L'exécution client prend en charge le concept de cache local (near cache) et de logique de routage de gestion de charge sur des clusters éloignés. L'exécution client prend également en charge la création de mappes d'objets locales.
[Version 6.0.1 and later] Le niveau de prise en charge dépend de l'exécution (client ou serveur) et de la structure ObjectGrid (intégrée ou autonome).
Structure ObjectGrid intégrée à WebSphere Extended Deployment
Exécution serveur : l'exécution serveur est intégrée. Pour WebSphere Extended Deployment version 6.0.1, l'exécution intégrée n'est pas prise en charge sur la plateforme z/OS.

Exécution client : l'exécution client est prise en charge dans l'environnement J2SE et J2EE avec un JDK de niveau 1.3.1 ou ultérieur incluant WebSphere Application Server version 5.0.2 ou ultérieure. Elle est entièrement prise en charge sur la plateforme z/OS.

Structure ObjectGrid autonome
Exécution serveur : l'exécution serveur est possible dans une machine virtuelle Java (JVM) autonome en tant que serveur unique ou cluster de serveurs. Le serveur autonome est pris en charge sur la plupart des plateformes J2SE et J2EE avec un JDK de niveau 1.4.2 ou ultérieur. Il est pris en charge dans WebSphere Application Server version 6.0.2 et ultérieure. Il n'est pas pris en charge sur la plateforme z/OS pour WebSphere Extended Deployment version 6.0.1.

Exécution client : l'exécution client est prise en charge sur les plateformes J2SE et J2EE avec un JDK de niveau 1.3.1 ou ultérieur incluant WebSphere Application Server version 5.0.2 ou ultérieure.

[Version 6.0.1 and later] Gestion des sessions

[Version 6.0.1 and later] Une implémentation de gestion des sessions HTTP distribuée et complète est mise à disposition et stocke les objets de session HTTP dans la structure ObjectGrid.

Installation simple

Il suffit de suivre quelques étapes simples pour installer et configurer ObjectGrid. Le procédure inclut la copie des fichiers JAR dans le chemin d'accès aux classes et la définition de quelques directives de configuration.

Modifications transactionnelles

Toutes les modifications sont apportées dans le contexte d'une transaction pour garantir la fiabilité de l'interface de programmation. La transaction peut être contrôlée de manière explicite dans l'application ou l'application peut utiliser le mode de programmation de validation automatique. Elles peuvent être répliquées dans un cluster ObjectGrid en mode asynchrone ou synchrone afin de permettre un accès évolutif tolérant les erreurs.

[Version 6.0.1 and later] La structure ObjectGrid est évolutive : vous pouvez passer d'une grille simple exécutée sur une machine virtuelle Java (JVM) unique à une grille impliquant un ou plusieurs clusters ObjectGrid de machines virtuelles Java. Ces serveurs permettent à un large éventail de clients pouvant utiliser ObjectGrid d'accéder au données via des API Map. Les clients ObjectGrid utilisent les API Map Java standard. Toutefois, le développeur d'applications n'a pas besoin de développer des API RMI (remote method invocation) et TCP/IP Java car le client ObjectGrid peut accéder aux autres serveurs ObjectGrid du réseau sur lesquels sont conservées les informations. Si la taille de votre ensemble de données est trop élevée pour une machine virtuelle Java (JVM) unique, vous pouvez utiliser la structure ObjectGrid pour partitionner les données.

[Version 6.0.1 and later] ObjectGrid ajoute également des fonctions haute disponibilité à votre solution applicative. Le partage d'objets repose sur un modèle de réplication dans lequel un serveur principal, un ou plusieurs serveurs de réplication et un ou plusieurs serveurs de secours cohabitent. Ce cluster de serveurs de réplication est appelé groupe de réplication. Si l'accès au groupe de réplication correspond à une opération d'écriture, la demande est acheminée au serveur principal. Si l'accès correspond à une opération de lecture, ou si la mappe est accessible en lecture seule, la demande peut être acheminée vers le serveur principal ou vers un serveur de réplication. Les serveurs de secours sont définis en tant que serveurs de réplication potentiels en cas de défaillance d'un serveur. Si un serveur principal est défaillant, l'un des serveurs de réplication devient le serveur principal afin de réduire la période d'indisponibilité. Vous pouvez configurer et étendre ce comportement selon vos besoins.

[Version 6.0.1 and later] Si vous préférez une approche de propagation d'objets plus simple, utilisez le modèle d'égal à égal qui propose une qualité de service inférieure et qui était également disponible dans Extended Deployment version 6.0. Avec la prise en charge des transactions distribuées, les homologues peuvent être informés des modifications par le biais d'un transport de messages. Le transport de messages est intégré si vous exécutez WebSphere Application Server version 6.0.2 ou ultérieure. Si vous n'exécutez pas WebSphere Application Server version 6.0.2 ou ultérieure, vous devez fournir un autre transport de message, tel que le fournisseur JMS (Java Message Service).

API compatibles de conteneur d'injection

Configurez ObjectGrid au moyen d'un simple fichier XML ou par programmation à l'aide d'API java. Celles-ci sont conçues pour fonctionner également dans des environnements où vous utilisez des structures basées sur l'injection pour configurer vos applications. Les API et les interfaces des objets ObjectGrid peuvent également être appelés par un conteneur IoC (Inversion of Control) et les références aux objets ObjectGrid clés peuvent alors être injectées dans l'application.

Architecture extensible

Vous pouvez étendre la plupart des éléments de la structure ObjectGrid en développant des plug-ins. Vous pouvez ajuster ObjectGrid pour autoriser une application à établir un compromis entre cohérence et performances. Le code personnalisé de plug-in peut également prendre en charge les comportements d'application spécifiques suivants : Vous pouvez implémenter chacun de ces comportements sans affecter l'utilisation des interfaces d'API de cache ObjectGrid de base. Grâce à cette transparence, les applications qui utilisent l'infrastructure de mise en cache peuvent modifier les magasins de données et le traitement des transactions sans affecter ces applications.

Utilisation d'ObjectGrid en tant qu'API principale ou mémoire cache de niveau secondaire

Les API ObjectGrid peuvent être utilisées directement par l'application en tant que mémoire cache secondaire ou mémoire cache d'écriture directe. En mode écriture directe, l'application connecte un objet de chargeur de sorte qu'ObjectGrid puisse appliquer les modifications et transmettre les données directement et de façon transparente à l'application. ObjectGrid peut également être utilisé comme mémoire cache de niveau secondaire pour les mappeurs relationnels d'objets standard, par écriture d'un adaptateur. Dans ce mode, la mémoire cache est invisible pour l'application car l'application utilise les API d'un mappeur relationnel d'objet en tant qu'API principale d'accès aux données.

Pour commencer à utiliser et à développer des applications ObjectGrid, voir Initiation à ObjectGrid.

Pour plus d'informations sur les API d'ObjectGrid, consultez le guide de programmation d'ObjectGrid. Voir Ressources ObjectGrid pour plus d'informations.




Related tasks
Initiation à ObjectGrid

Rubrique Concept    

Conditions d'utilisation | Commentaires Dernière mise à jour le : Mar 16, 2006 9:53:36 AM EST
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=?topic=/com.ibm.websphere.xd.doc/info/prodovr/cobgojbectgrid.html

© Copyright IBM 2005, 2006. All Rights Reserved.
Ce centre de documentation s'appuie sur la technologie Eclipse. (http://www.eclipse.org)