L'état du middleware d'application Java, partie 1

Le client / serveur est mort. C'est le buzz maintenant que les nouvelles technologies basées sur Internet sont en plein essor. Mais ces nouvelles technologies ne sont que l'évolution naturelle des approches précédentes, mises en œuvre avec des protocoles plus récents et plus ouverts et conçues pour offrir une plus grande évolutivité, une plus grande facilité de gestion et une plus grande diversité.

L'ampleur de cette évolution est stupéfiante. La plupart des principaux fournisseurs de clients / serveurs ont modernisé leurs produits et orientent désormais leurs investissements marketing vers des technologies à trois niveaux. Dans la plupart des cas, les nouveaux produits sont centrés sur Java et sur le protocole Internet. Par exemple, j'ai identifié au moins 46 produits middleware Java au dernier décompte. Il y a deux ans, il aurait été difficile de trouver la moitié de ce nombre.

Il s'agit du premier d'une série d'articles en deux parties consacrés à l'explication du middleware Java à usage général dans ses formes actuelles. Dans ce premier article, je vais examiner les fonctionnalités des produits actuels et expliquer pourquoi ces fonctionnalités sont importantes. Dans la deuxième partie, Anil Hemrajani examinera les Enterprise JavaBeans (EJB) et montrera comment la génération actuelle de produits middleware Java est liée et supporte cette norme de composant importante.

Contexte

Tout d'abord, définissons le middleware Java.Le terme englobe les serveurs d'applications tels que BEA WebLogic, les produits de messagerie tels que ActiveWorks d'Active Software et SpiritWAVE de Push Technologies, et les produits hybrides qui s'appuient sur un SGBD hérité et ajoutent des fonctionnalités d'exécution d'objets Java basées sur le serveur. J'aurais pu me concentrer sur un segment plus étroit, comme les serveurs d'applications, mais cela aurait été injuste pour les nombreux produits qui ne rentrent pas précisément dans cette catégorie, mais qui devraient néanmoins être envisagés pour les applications à plusieurs niveaux. De plus, même parmi les serveurs d'applications, il existe un large spectre, y compris ceux qui sont principalement des serveurs de servlet ainsi que ceux qui sont basés sur ORB ou OODB. Tracer une ligne entre tous ces produits s'avère de plus en plus difficile. La caractéristique unificatrice, cependant,est qu'ils tentent tous de résoudre le problème de déploiement d'applications à plusieurs niveaux en utilisant les technologies Java et Internet.

L'analyse de rentabilisation de l'utilisation de Java dans le middleware est convaincante; parmi les avantages offerts par le middleware Java sont les suivants:

  • La capacité d'Internet à interconnecter économiquement les bureaux et les organisations

  • La nécessité pour les organisations de coopérer en partageant des données et des processus métier

  • La volonté de consolider les services génériques et la gestion de ces services

  • Le désir de fournir une gestion centralisée des applications, y compris le démarrage, l'arrêt, la maintenance, la récupération, l'équilibrage de charge et la surveillance

  • Le désir d'utiliser des services et protocoles ouverts

  • La volonté de redéployer la logique métier à volonté et sans contrainte d'infrastructure; cela nécessite l'utilisation d'API et de protocoles ouverts, largement pris en charge par la plupart des produits d'infrastructure

  • La nécessité de prendre en charge les applications à architecture mixte coopérantes

  • Le désir de déplacer les décisions d'infrastructure de réseau et de service hors de l'espace applicatif, afin que les gestionnaires de système puissent prendre des décisions d'infrastructure sans être gênés par des applications qui dépendent de protocoles ou de fonctionnalités propriétaires

  • Le désir de réduire la diversité et le niveau de compétences du personnel des programmeurs nécessaires et de minimiser le besoin d'expertise avancée en création d'outils dans les projets

  • Le désir de tirer parti de l'expertise orientée objet en l'étendant au domaine du serveur - d'où les nouveaux produits serveur orientés objet et les ponts objet-relationnel

L'objectif du middleware est de centraliser l'infrastructure logicielle et son déploiement. Le client / serveur est issu d'une ère d'intégration au sein d'un seul département. Les organisations tentent désormais couramment une intégration au-delà des frontières départementales, même d'une organisation à une autre. Internet - qui séduit les entreprises par sa capacité à servir de réseau mondial permettant aux départements et aux partenaires de s'interconnecter efficacement et rapidement - a généré la demande pour cette intégration.

Java fournit une lingua franca pour interconnecter facilement les données et les applications au-delà des frontières organisationnelles: dans un environnement mondial distribué, dans lequel vous n'avez aucun contrôle sur les choix technologiques que vos partenaires peuvent faire, les entreprises intelligentes choisissent des normes ouvertes et neutres en termes de plate-forme. Les entreprises ne peuvent pas prévoir qui deviendra leurs clients, partenaires ou filiales dans deux ans, il n'est donc pas toujours possible de planifier une infrastructure commune avec ses partenaires. Dans cette situation incertaine, la meilleure décision peut être d'utiliser les technologies les plus universelles et adaptables possibles.

Java vous permet de réduire le nombre de langages de programmation et de plates-formes que votre personnel doit comprendre. Pourquoi? Parce que Java est désormais déployé dans des contextes aussi divers que les navigateurs Internet, les procédures stockées dans les bases de données, les objets métier dans les produits middleware et les applications côté client.

À l'âge de trois ans, cependant, la technologie Java est encore quelque peu immature, et cela est vrai pour les produits abordés dans cet article. D'un autre côté, nous sommes peut-être maintenant à une époque où les produits n'atteignent jamais vraiment leur maturité, car les technologies sous-jacentes sur lesquelles ils sont basés changent si rapidement. En fait, j'ai trouvé des problèmes importants avec pratiquement tous les produits middleware que j'ai utilisés, y compris les produits supposés matures qui sont sur le marché depuis quelques années et qui ont récemment sorti de nouvelles fonctionnalités importantes. Le fait est qu'au moment où un fournisseur parvient à résoudre les problèmes, de nouvelles fonctionnalités ont été ajoutées. Le cycle d'ajout de nouvelles fonctionnalités est maintenant beaucoup plus court qu'il ne l'a jamais été, et les produits n'ont donc pas assez de temps pour devenir stables avant d'inclure le prochain ensemble de fonctionnalités majeur.Il se peut que nous devions nous habituer à cela, et apprendre les forces et les faiblesses des produits que nous choisissons est une partie importante de tout cycle de conception d'application et de prototype.

Objectifs du middleware

La norme de composant middleware EJB a été développée avec les objectifs suivants:

  • Pour assurer l'interopérabilité des composants. Les beans entreprise développés avec différents outils fonctionneront ensemble. De plus, les beans développés avec différents outils fonctionneront dans n'importe quel environnement EJB.

  • Fournir un modèle de programmation facile à utiliser tout en conservant l'accès aux API de bas niveau.

  • Pour résoudre les problèmes de cycle de vie, y compris le développement, le déploiement et l'exécution.

  • Pour assurer la compatibilité avec les plates-formes existantes, ce qui permet d'étendre les produits existants pour prendre en charge EJB.

  • Pour maintenir la compatibilité avec d'autres API Java.

  • Pour assurer l'interopérabilité entre les applications EJB et non-Java.

  • Pour être compatible avec CORBA.

L'objectif de la norme EJB est donc de créer une norme d'interopérabilité pour le middleware Java, empêchant les programmeurs d'avoir à faire face à de nombreux problèmes difficiles qui surviennent lors du développement d'applications distribuées. Cela permet aux développeurs de logiciels de se concentrer sur la logique métier au lieu d'écrire une infrastructure et des outils locaux sophistiqués. En conséquence, les entreprises peuvent consacrer la plupart de leurs ressources pédagogiques à la formation du personnel aux processus métier, ce qui est généralement ce qui est le plus rentable.

À la liste ci-dessus, j'ajoute les objectifs supplémentaires suivants pour le middleware Java de classe entreprise. Ces fonctionnalités du produit sont nécessaires à long terme pour exécuter et maintenir avec succès un environnement basé sur un middleware:

  • Il doit permettre l'interconnexion de plusieurs unités commerciales, entreprises et clients dans une infrastructure distribuée sans compromettre la sécurité ni introduire le chaos

  • Il devrait permettre des mécanismes de contrôle d'accès flexibles mais fiables pour garantir que les données des partenaires commerciaux ne sont accessibles que de la manière prévue et uniquement par les parties prévues.

  • Il devrait permettre aux administrateurs système de gérer un environnement informatique distribué contenant un grand nombre de composants de logique métier de manière uniforme, sans avoir à comprendre ou appliquer des procédures uniques à des composants particuliers.

  • il doit permettre aux administrateurs système de faire des sélections de composants d'infrastructure sans impact sur les applications, de régler et de mettre à l'échelle ces composants et de disposer d'un moyen uniforme et générique de mesurer les performances et les besoins en ressources de toutes les applications

  • Il doit permettre de déplacer les composants métier entre les clients et les serveurs sans affecter les architectures de l'un ou l'autre

  • Il devrait fournir un mécanisme de sécurité qui permet à des utilisateurs particuliers d'ajouter de nouveaux composants, sans avoir à donner à l'administrateur du serveur l'accès à tous les composants et sources de données (c'est une excellente opportunité pour une capacité à valeur ajoutée, car il est essentiel pour les applications extranet et de partenariat )

Composants et fonctionnalités des plates-formes middleware Java

La catégorie de middleware Java qui connaît la croissance la plus rapide aujourd'hui est probablement celle des serveurs d'applications. Cependant, il est essentiel de réaliser la grande variété de serveurs d'applications (et d'autres types de produits middleware) qui existent. Les distinctions entre les catégories de produits middleware Java aujourd'hui ne sont pas représentées par une ligne mais par un vaste continuum middleware. Je vais maintenant discuter des fonctionnalités du middleware Java, sur la base de mes propres comparaisons de travail, qui englobent toutes les classes de produits middleware Java que je connais.

Modèles d'objets, de composants et de conteneurs

Les composants d'application doivent adhérer à un modèle de déploiement d'exécution, qui spécifie comment le composant communique avec son environnement; (éventuellement) comment il est installé, démarré, arrêté et appelé; et comment il accède aux services importants pour son environnement. Les modèles d'exécution et de conteneur de composants serveur centrés sur Java les plus courants incluent RMI, EJB, CORBA, DCOM, servlet, JSP (Java Server Pages) et les procédures stockées Java. En outre, les modèles de composants peuvent être exprimés dans une variété de langages sous-jacents, notamment Java, IDL, C ++ et bien d'autres.

Il y a chevauchement avec divers modèles de composants. Par exemple, RMI est un modèle de composant trivial avec des fonctionnalités très basiques pour l'activation et la localisation d'objets, et est principalement une norme d'appel à distance, tandis qu'EJB exploite RMI et spécifie RMI comme son modèle d'appel d'objet principal. EJB prend également en charge CORBA. En fait, aucun de ces modèles n'est exclusif et de nombreux serveurs d'applications Java prennent en charge la plupart ou la totalité des modèles ci-dessus.

De nombreux serveurs middleware Java exécutent plusieurs instances d'objet métier (que le monde CORBA appelle désormais serviteurs) au sein d'une même machine virtuelle Java (JVM). La sécurité de type du langage Java permet à un seul processus JVM de traiter les demandes de plusieurs clients et d'utiliser des structures de données de programme et des chargeurs de classe pour séparer les données client. Tant que les serviteurs n'emploient pas leurs propres méthodes natives, il n'est pas possible pour un serviteur de faire tomber d'autres serviteurs s'il plante (sauf s'il rencontre un bogue dans la JVM elle-même), ou d'accéder à des données privées pour d'autres classes. . Un serveur d'objets correctement conçu protégera ses objets privés et empêchera les objets errants d'accéder à ce qui appartient à d'autres objets.

Cependant, les données déclarées statiques dans une classe Java peuvent être partagées entre les clients au sein de la même JVM si les clients utilisent le même chargeur de classe, des règles doivent donc être définies pour déterminer quand une JVM distincte (ou l'équivalent d'une JVM distincte utilisant la mémoire) techniques de partitionnement) ou un chargeur de classe distinct est nécessaire pour donner à un client son propre espace de données statiques. De telles règles ont été spécifiées pour les applets, mais pas pour les autres environnements d'exécution. Le serveur Web Java de Sun utilise une seule JVM pour tous les servlets et un espace de nom de classe distinct pour les servlets avec une base de code différente. EJB contourne le problème en interdisant les données statiques non finales.

Les performances peuvent être améliorées si les objets sont désactivés ou passivés lorsqu'ils ne sont pas utilisés, ce qui libère des ressources telles que les connexions à la base de données. Pour cette raison, de nombreux serveurs passivent et réactivent les objets selon les besoins. De même, certains produits conservent les objets fréquemment créés dans un pool ou un cache dans un état initialisé et prêts pour une utilisation immédiate. Le conteneur d'objets doit gérer la passivation et la réactivation ainsi que les ressources mutualisées affectées par la passivation.

Compatibilité EJB (version)

Le modèle EJB est déjà universellement pris en charge. Presque tous les fournisseurs de middleware ont promis de le prendre en charge et beaucoup le font déjà. De plus, l'Object Management Group (OMG) a incorporé un mappage à EJB dans le cadre de la spécification de composant CORBA proposée . Il est difficile d'imaginer que même Microsoft, le seul et inébranlable, ne cédera pas et ne fournira pas de conteneurs EJB pour DCOM.

Bien que différents middlewares compatibles EJB puissent déployer et faire fonctionner les mêmes composants d'application (tant que ces composants n'utilisent que les fonctionnalités EJB standard requises), il existe encore de nombreuses variations entre les serveurs compatibles EJB. D'une part, la spécification EJB elle-même évolue. Une question importante lors de l'évaluation des produits middleware Java est donc la suivante: le serveur prend-il en charge la dernière version d'EJB ou ne prend-il en charge qu'une version antérieure? Une autre question clé est la suivante: le produit est-il centré sur EJB, ou le support EJB est-il inclus uniquement dans les fonctionnalités à valeur ajoutée du produit (et donc indisponible lorsque les services EJB ou API sont utilisés)? Et enfin: quelles fonctionnalités EJB optionnelles sont incluses (par exemple, les beans entité et la persistance gérée par le conteneur)?