Exemple d'architecture de solution Java ES

Java ES prend en charge une large gamme de solutions logicielles. De nombreuses solutions peuvent être conçues et déployées en version standard, sans développement supplémentaire, en utilisant les composants fournis avec Java ES. D'autres solutions peuvent exiger des efforts de développement considérables, nécessitant le développement de composants J2EE personnalisés afin de fournir de nouveaux services d'entreprise ou de présentation. Vous pouvez encapsuler ces composants personnalisés sous la forme de services Web conformes aux normes d'interface SOAP. La plupart de ces solutions impliquent une combinaison de ces deux approches.

Cette section fournit un exemple illustrant la prise en charge par Java ES d'une solution standard, bâtie autour des concepts d'architecture décrits dans la section précédente.

Scénario de communication d'entreprise

Généralement, les entreprises ont besoin de prendre en charge la communication entre leurs employés, en particulier les services de courrier et de calendrier. Ces entreprises pensent qu'il est avantageux pour leurs employés d'avoir un accès personnalisé aux sites Web internes et aux autres ressources basées sur les services d'autorisation et d'authentification de l'entreprise. De plus, ces entreprises souhaitent que l'identité des employés soit suivie dans tous les services de l'entreprise afin qu'une connexion Web unique permette d'accéder à ces services.

Ces exigences d'entreprise spécifiques, qui ne constituent qu'un exemple parmi d'autres, sont résumées dans le tableau ci-dessous.

Tableau 2–4 Récapitulatif des besoins d'entreprise : scénario de communications

Exigence de l'entreprise	Description	Services requis
Connexion unique	Accès aux ressources d'entreprise sécurisées et aux services basés sur une identité unique avec une connexion unique pour l'accès Web	Services d'identité
Messagerie  Calendrier	Messagerie électronique assurant la communication entre les employés et le monde extérieur  Dispositions électroniques des employés concernant le calendrier et les réunions	Services de communication et de collaboration
Accès au portail	Points d'accès Web uniques et personnalisés aux services de communication, tels que la messagerie électronique, le calendrier et les pages Web internes	Services de portail

En outre, toute entreprise doit faire face à des exigences de performances, de disponibilité, de sécurité réseau et d'évolutivité du système logiciel qui fournit ces services.

Architecture logique de l'exemple de scénario

La figure suivante présente une architecture logique pour la fourniture de services de portail, de communication et d'identité identifiés dans le Tableau 2–4 à l'aide de composants Java ES. L'architecture traite les configurations logiques spécifiques de Messaging Server comme composants séparés du fait des services distincts fournis par chacun d'entre eux.

Figure 2–6 Architecture logique d'un scénario de communication d'entreprise

Les composants placés dans une dimension horizontale représentent les niveaux logiques standard et ceux placés dans une dimension verticale représentent les niveaux de services d'infrastructure. Les interactions entre les composants dépendent de leurs fonctions en tant que services d'infrastructure distribués (interactions entre les niveaux de services d'infrastructure) ou de leurs rôles au sein d'une architecture d'application à plusieurs niveaux (interactions au sein des niveaux logiques et entre ceux-ci).

Dans cette architecture, Access Manager, en accédant aux informations utilisateur stockées dans Directory Server, régit l'autorisation et l'authentification de connexion unique pour Portal Server et les autre composants Web du niveau présentation. Les composants de Messaging Server incluent une mémoire de (Messaging Server -STR) au niveau données, l'envoi et la réception des composants au niveau services d'entreprise et un composant d'accès HTTP et Communications Express au niveau présentation.

L'architecture logique présente également les dépendances de services d'infrastructure entre les divers composants Java ES. Portal Server, par exemple, dépend de Communications Express pour ses canaux de messagerie et de calendrier et d'Access Manager pour les services d'authentification et d'autorisation. Ces composants dépendent, à leur tour, de Directory Server en ce qui concerne les informations utilisateur et les données de configuration. Certains composants nécessitent des services de conteneur Web fournis par Web Server.

Pour plus d'informations sur la conception logique d'une solution Java ES, reportez-vous au Sun Java Enterprise System Deployment Planning Guide.

Architecture de déploiement de l'exemple de scénario

Du fait du passage de l'architecture logique à une architecture de déploiement, les exigences de qualité de service deviennent essentielles. Par exemple, les pare-feux et les sous-éseaux protégés peuvent être utilisés pour créer une barrière de sécurité pour les données d'arrière-plan. Les exigences de disponibilité et d'évolutivité peuvent être satisfaites pour la plupart des composants en les déployant sur plusieurs ordinateurs et en utilisant des équilibreurs de charge pour distribuer les requêtes parmi les composants répliqués.

Toutefois, lorsque des exigences de disponibilité plus contraignantes s'appliquent et lorsqu'une grande quantité de stockage sur disque est impliquée, d'autres solutions de disponibilité sont plus appropriées. Par exemple, Sun Cluster peut être utilisé pour le stockage de Messaging Server et la réplication multimaître peut être utilisée pour Directory Server.

Pour plus d'informations sur la conception du déploiement d'une solution Java ES, reportez-vous au Sun Java Enterprise System Deployment Planning Guide.