Visión general técnica de Sun Java Enterprise System 2005Q4

Capítulo 2 Arquitecturas de las soluciones de Java Enterprise System

Este capítulo proporciona una visión general de los conceptos arquitectónicos en los que se basan las soluciones de Java Enterprise System (Java ES). El capítulo muestra cómo se utilizan los componentes de Java ES, tanto los componentes de los servicios del sistema como los componentes de calidad del servicio, para admitir las soluciones de empresa distribuidas.

Las arquitecturas de las soluciones de Java ES tienen dos aspectos: una arquitectura lógica y una arquitectura de implementación. La arquitectura lógica describe las interacciones entre los bloques de construcción lógica (los componentes de software) de una solución. La arquitectura de implementación establece la asignación existente entre la arquitectura lógica y un entorno informático físico. Los componentes de Java ES desempeñan papeles importantes tanto en la arquitectura lógica como en la de implementación.

Este capítulo describe un marco arquitectónico para diseñar arquitecturas de soluciones de Java ES, seguido por una arquitectura de solución de ejemplo basada en dicho marco arquitectónico.

En este capítulo se describen los siguientes temas:

Marco arquitectónico de Java Enterprise System

Los componentes de Java ES admiten la implementación de soluciones de software de fortaleza de empresa distribuidas.

Para obtener la funcionalidad solicitada en los niveles de rendimiento, disponibilidad, seguridad, escalabilidad y la facilidad de mantenimiento establecidos por los requisitos de la empresa, estas soluciones de software se deben diseñar de forma adecuada.

Hay una serie de dimensiones arquitectónicas implicadas en el diseño de soluciones de software de fortaleza de empresa distribuidas. Estas dimensiones representan perspectivas distintas desde las que se ven las interacciones de los distintos componentes de software utilizados para crear dichos sistemas. En concreto, el diseño de los sistemas distribuidos implica las siguientes tres dimensiones arquitectónicas:

Estas tres dimensiones de la arquitectura de la solución se muestran en la siguiente figura.

Figura 2–1 Dimensiones de la arquitectura de las soluciones de Java ES

Diagrama que muestra el marco tridimensional como capas lógicas, niveles de servicio de infraestructura y calidades de servicio.

Juntas, estas tres dimensiones representan un único marco que incorpora las relaciones entre los siguientes elementos de software: componentes de aplicación y componentes de infraestructura; todos ellos son necesarios para obtener las funciones de servicio y la calidad de servicio que se exigen a una solución de software.

Las siguientes secciones describen las tres dimensiones individualmente y, a continuación, figura una síntesis de las tres dimensiones en un marco unificado.

Dimensión 1: dependencias de los servicios de infraestructuras

Los componentes del software de interacción de las aplicaciones de empresa distribuidas requieren un conjunto subyacente de servicios de infraestructura que permitan a los componentes distribuidos comunicarse entre sí, coordinar su trabajo, implementar un acceso seguro, etc. Esta sección explica la función principal desarrollada por una serie de componentes de Java ES al proporcionar estos servicios de infraestructura.

Niveles de servicio de infraestructura

Al diseñar un sistema de software distribuido, con independencia de que conste principalmente de los componentes desarrollados de forma personalizada o de que incluya todos los componentes "de fábrica" de Java ES, debe incluir una serie de servicios de infraestructura. Estos servicios operan en varios niveles.

La dimensión de las dependencias de los servicios de infraestructura se muestra en la Figura 2–2. Los niveles que se muestran en esta figura son una vista ampliada de la capa de los servicios de infraestructura de la Figura 1–1.

La jerarquía de los servicios de la Figura 2–2 y las dependencias existentes entre ellos constituyen una importante dimensión de la arquitectura lógica de la solución. Estos servicios de infraestructura proporcionan las bases conceptuales para comprender la función de los componentes de los servicios del sistema de Java ES (consulte Componentes de los servicios del sistema).

En general, los servicios que se muestran en la Figura 2–2 se pueden clasificar en tres amplios grupos: servicios de plataforma de nivel inferior, servicios de aplicación de nivel superior y un grupo de servicios de nivel intermedio. Los respectivos nombres proceden de su ubicación entre los otros dos grupos.

Figura 2–2 Dimensión 1: niveles de los servicios de infraestructuras

Diagrama que muestra los niveles de servicio de infraestructura distribuidos, desde los servicios de plataforma de sistema operativo de nivel inferior a los servicios de integración de nivel superior.

Los siguientes párrafos describen los distintos niveles de servicio de infraestructura y hacen referencia a artefactos de lenguaje de programación Java, cuando corresponde. Los niveles de servicio se describen desde el nivel inferior al superior, tal y como se muestra en la Figura 2–2:

Los niveles de servicio que se muestran en la Figura 2–2 reflejan una dependencia general entre los distintos servicios de infraestructura, desde los servicios del sistema operativo de nivel inferior hasta los servicios de aplicación de nivel superior y los servicios de integración. Cada servicio depende normalmente de servicios de niveles inferiores y respalda el funcionamiento de servicios superiores.

La Figura 2–2, sin embargo, no representa una distribución en capas estricta de los servicios de infraestructura. Los servicios de nivel superior pueden interactuar directamente con servicios de nivel inferior sin depender de niveles intermedios. Por ejemplo, algunos servicios de tiempo de ejecución pueden depender directamente de servicios de plataforma sin necesitar ninguno de los niveles de servicio intermedios. Además, otros niveles de servicio, como los de supervisión o administración, también podrían incluirse en esta ilustración conceptual.

Componentes de los servicios de infraestructura de Java Enterprise System

Los componentes de Java ES despliegan los niveles de los servicios de infraestructura distribuidos que se muestran en la Figura 2–2. La posición de los componentes de los servicios del sistema de Java ES en los diferentes niveles es la que se muestra en la Figura 2–3.

Figura 2–3 Componentes de los servicios del sistema de Java ES

Diagrama que muestra la ubicación de los componentes de los servicios del sistema de Java ES en los diferentes niveles de los servicios de infraestructura distribuida.


Nota –

Las plataformas de los sistemas operativos que se muestran en la Figura 2–3 no son una parte formal de Java Enterprise System; sin embargo, se incluyen para mostrar las plataformas de los sistemas operativos en las que se admite el uso de los componentes de Java ES.


Dependencias de los servicios de infraestructuras de Java Enterprise System

En general, los componentes de los servicios del sistema de Java ES que se muestran en la Figura 2–3 dependen de los componentes situados debajo de ellos en la infraestructura, a la vez que proporcionan respaldo a los componentes que están situados encima de ellos. Estas relaciones de dependencia y compatibilidad son un factor clave para diseñar las arquitecturas lógicas.

En la Tabla 2–1 se muestran las relaciones específicas entre los componentes de los servicios del sistema de Java ES, enumerados desde el nivel superior al inferior, tal y como se muestra en la Figura 2–3.

Tabla 2–1 Relaciones entre los componentes de los servicios del sistema de Java ES

Componente 

Depende de 

Respalda el funcionamiento de 

Portal Server 

Application Server o Web Server  

Access Manager 

Directory Server 

Si se configura para usar los canales de: Calendar Server Messaging Server Instant Messaging 

 

Messaging Server 

Directory Server 

Access Manager (para el inicio de sesión único) 

Calendar Server (para las notificaciones de correo electrónico) 

Portal Server (para el canal de mensajería) 

Instant Messaging 

Directory Server 

Access Manager (para el inicio de sesión único) 

Portal Server (para el canal de mensajería instantánea) 

Calendar Server 

Directory Server 

Messaging Server (para el servicio de notificación de correo electrónico) 

Access Manager (para el inicio de sesión único) 

Portal Server (para el canal de calendario) 

Access Manager 

Application Server o Web Server  

Directory Server 

Portal Server 

Si se configura para el inicio de sesión único: Calendar Server Messaging Server Instant Messaging 

Application Server 

Message Queue 

Directory Server (para los objetos administrados) 

Portal Server 

Access Manager 

Message Queue 

Directory Server (para los objetos administrados) 

Application Server 

Web Server  

Access Manager (para el control de acceso) 

Portal Server 

Access Manager 

Directory Server 

Ninguno 

Portal Server 

Calendar Server 

Messaging Server 

Instant Messaging 

Access Manager 

Service Registry  

Ninguno 

Componentes basados en Application Server 

Dimensión 2: capas lógicas

Los componentes de software que interactúan de las aplicaciones de empresa distribuidas se pueden visualizar como residentes en un número de capas lógicas. Estas capas representan la independencia física y lógica de los componentes de software basándose en la naturaleza de los servicios que proporcionan.

La dimensión de las capas lógicas de la arquitectura de la solución se muestra en la siguiente figura.

Figura 2–4 Dimensión 2: capas lógicas para aplicaciones de empresa distribuidas

Diagrama que muestra cuatro capas lógicas, de izquierda a derecha: capa de clientes, capa de presentación, capa de servicio de empresas y capa de datos.

En su mayor parte, las arquitecturas de capas lógicas representan la capa de aplicación empresarial distribuida de la Figura 1–1. Los componentes de los servicios del sistema de Java ES se describen en Niveles de servicio de infraestructura para proporcionar asistencia a los componentes de aplicaciones de todas las capas lógicas que se muestran en la Figura 2–4. Sin embargo, los conceptos de capas lógicas también se aplican a los componentes de los servicios del sistema que proporcionan servicios de nivel de aplicación, tales como Messaging Server y Calendar Server.

Descripción de capas lógicas

Esta sección proporciona breves descripciones de las cuatro capas lógicas que se muestran en la Figura 2–4. Las descripciones hacen referencia a componentes de aplicaciones desplegados usando el modelo del componente Java 2 Platform, Enterprise Edition (plataforma J2EETM). No obstante, otros modelos de componente distribuidos, como CORBA, también son compatibles con esta arquitectura.

Independencia lógica y física

La dimensión arquitectónica que se ilustra en la Figura 2–4 destaca la independencia lógica y física de los componentes, representada mediante 4 capas separadas. Estas capas representan la partición de la lógica de la aplicación en varios equipos en un entorno de red:

Arquitectura en capas aplicada a los componentes del sistema

Tal y como se muestra en la Figura 2–3, los componentes de los servicos de la infraestructura de Java ES proporcionan la infraestructura subyacente que permite utilizar soluciones de software distribuidas. Sin embargo, algunas de estas soluciones incluyen servicios de nivel de aplicaciones proporcionados directamente por los componentes de Java ES. Estas soluciones utilizan enfoques de diseño de capas lógicas.

Por ejemplo, los servicios de comunicación mediante correo electrónico proporcionados por Messaging Server se despliegan usando una serie de configuraciones diferenciadas desde el punto de vista lógico de Messaging Server. Estas diferentes configuraciones proporcionan conjuntos distintos de servicios. Al diseñar las soluciones de mensajería, estas configuraciones distintas se representan como componentes separados que están situados en distintas capas lógicas, como se muestra en la siguiente figura.

Figura 2–5 Messaging Server: ejemplo de arquitectura en capas

Diagrama que muestra componentes de Messaging Server distribuidos entre las cuatro capas lógicas.


Nota –

La Figura 2–5 no pretende reflejar una arquitectura lógica completa puesto que se han omitido algunos componentes de Java ES para simplificar la ilustración. Las líneas que conectan los componentes representan interacciones.


La separación lógica de las funciones de Messaging Server en distintas capas permite implementar las configuraciones lógicamente distintas de Messaging Server en varios equipos en un entorno físico. La separación física aporta flexibilidad a la hora de satisfacer los requisitos de calidad del servicio (consulte Dimensión 3: calidad del servicio). Por ejemplo, proporciona diversas soluciones de disponibilidad para distintas instancias y distintas implementaciones de seguridad para funciones de Messaging Server diferentes.

Dimensión 3: calidad del servicio

Las dos dimensiones arquitectónicas anteriores (dependencias de servicio de infraestructura y capas lógicas) hacen referencia en buena parte a los aspectos lógicos de la arquitectura, es decir, qué componentes son necesarios para interactuar de cierto modo con objeto de ofrecer los servicios a los usuarios finales. No obstante, una dimensión igualmente importante de cualquier solución implementada es la capacidad de ésta para cumplir los requisitos de calidad de servicio.

La dimensión de calidad del servicio de una arquitectura de solución destaca las funciones desempeñadas por los componentes de calidad de servicio de Java ES.

Calidades de servicio

A medida que los servicios de Internet y de comercio electrónico se han hecho más importantes para las operaciones de negocios, el rendimiento, la disponibilidad, la seguridad, la escalabilidad y la facilidad de mantenimiento de estos servicios se han convertido en un requisito fundamental de calidad de servicio para las arquitecturas de implementación de alto rendimiento y de gran escala.

Para diseñar una solución de software con éxito, se deberá determinar los requisitos de calidad de servicios relevantes y diseñar una arquitectura que satisfaga dichos requisitos. Se utiliza un número de importantes calidades de servicios para especificar los requisitos de calidad de servicio. Estas calidades de servicios se resumen en la siguiente tabla.

Tabla 2–2 Calidades de servicio que afectan a la arquitectura de solución

Calidades de servicio del sistema 

Descripción 

Rendimiento

La medición de la latencia y del tiempo de respuesta con relación a las condiciones de carga de usuarios.  

Disponibilidad

Medida de la frecuencia con que los usuarios finales acceden a los servicios y recursos de un sistema (el tiempo de actividad de un sistema).

Seguridad

Combinación compleja de factores que describe la integridad de un sistema y sus usuarios. La seguridad incluye la seguridad física de los sistemas, seguridad de red, seguridad de datos y aplicaciones (autenticación y autorización de usuarios), así como el transporte seguro de la información. 

Escalabilidad

La capacidad de agregar a lo largo del tiempo funciones a un sistema implementado. La escalabilidad normalmente implica agregar recursos al sistema, pero no debería requerir cambios en la arquitectura de implementación. 

Capacidad latente

La capacidad de un sistema para gestionar el uso de carga máxima inusual sin recursos adicionales. 

Capacidad de mantenimiento

La facilidad con que un sistema implementado puede mantenerse, incluidas tareas tales como la supervisión del sistema, la reparación de los problemas que surjan y la actualización de los componentes de hardware y software.  

La dimensión de calidad de servicio influye en gran medida en la arquitectura de despliegue de una solución: cómo se implementan en el entorno físico los componentes de la aplicación y componentes de infraestructura.

Las calidades del servicio que afectan a la arquitectura de implementación están estrechamente interrelacionadas. Los requisitos para una calidad de sistema afectan a menudo al diseño de otras calidades de servicio. Por ejemplo, unos mayores niveles de seguridad podrían afectar al rendimiento, que a su vez podría afectar a la disponibilidad. La integración de equipos adicionales para solucionar problemas de disponibilidad mediante la redundancia a menudo afecta a los costes de mantenimiento (facilidad de mantenimiento).

Al diseñar arquitecturas de implementación que satisfagan las necesidades y las limitaciones de negocios, es importante conocer el modo de interrelación de las calidades del servicio y las concesiones que se deben realizar.

Componentes de calidad del servicio de Java Enterprise System

Varios componentes de Java ES se utilizan principalmente para mejorar la calidad de los servicios proporcionados por los componentes de los servicios del sistema o por los componentes de aplicaciones distribuidas. A menudo, estos componentes de software se utilizan junto con los componentes de hardware como, por ejemplo, equilibradores de carga y servidores de seguridad.

Los componentes de calidad del servicio de Java ES, de los que se realiza una introducción en Componentes de calidad del servicio, se resumen a continuación:

La siguiente tabla muestra los componentes de calidad del servicio de Java ES más importantes desde una perspectiva arquitectónica con las calidades de sistema a las que más afectan.

Tabla 2–3 Componentes de calidad de servicio y calidades de sistema afectadas

Componente 

Calidades de sistema afectadas 

Communications Express

Seguridad

Escalabilidad 

Directory Proxy Server

Seguridad

Escalabilidad

almacén de sesión de alta disponibilidad 

Disponibilidad

Portal Server Secure Remote Access

Seguridad

Escalabilidad

Sun Cluster 

Disponibilidad

Escalabilidad

Web Proxy Server  

Seguridad Rendimiento Capacidad de mantenimiento

Software de Sun Cluster

El software de Sun Cluster proporciona servicios de alta disponibilidad y escalabilidad para los componentes de Java ES y para las aplicaciones a las que proporciona compatibilidad la infraestructura de Java ES.

Un clúster es un conjunto de equipos que no están firmemente acoplados y que, en conjunto, ofrecen una vista de cliente única de los servicios, los recursos del sistema y los datos. Internamente, el clúster utiliza equipos redundantes, interconexiones, almacenamiento de datos e interfaces de red para ofrecer alta disponibilidad en datos y servicios basados en clúster.

El software de Sun Cluster supervisa continuamente el estado de los nodos miembros y de otros recursos del clúster. En caso de fallo, el software de Sun Cluster interviene para iniciar la recuperación de los fallos de los recursos que supervisa y utiliza, por tanto, la redundancia interna para proporcionar un acceso prácticamente continuo a estos recursos.

En la figura que aparece a continuación se representa un clúster de dos nodos que hace posible el uso de servicios de almacén de datos para Messaging Server y Calendar Server.

Figura 2–6 Diseño de disponibilidad usando nodos de Sun Cluster

Diagrama que muestra equipos redundantes, almacenes de datos e interconexiones en el diseño de disponibilidad de Sun Cluster.

Los paquetes de servicios de datos de Sun Cluster (a veces denominados "agentes de Sun Cluster") están disponibles para todos los componentes de los servicios del sistema Java ES. También puede escribir agentes para componentes de aplicaciones personalizados.

Dado el control que permite el software de Sun Cluster, también puede ofrecer servicios escalables. Aprovechando el sistema de archivos global del clúster y la capacidad de que haya varios nodos en un clúster para ejecutar servicios de aplicaciones e infraestructura, la creciente demanda de estos servicios puede equilibrarse en varias instancias simultáneas de los servicios. Por lo tanto, si se configura correctamente, el software de Sun Cluster puede proporcionar alta disponibilidad y escalabilidad en una aplicación de empresa distribuida.

Debido a la redundancia necesaria para poder usar los entornos de Sun Cluster, la inclusión de Sun Cluster en una solución aumenta sustancialmente el número de equipos y vínculos de red necesarios en el entorno físico.

A diferencia de los servicios proporcionados por otros componentes de Java ES, los servicios de disponibilidad de Sun Cluster son servicios "de igual a igual" distribuidos. Por lo tanto, el software de Sun Cluster debe instalarse en cada equipo de un clúster.

Síntesis de las tres dimensiones arquitectónicas

Cuando se visualizan juntas, las tres dimensiones arquitectónicas, que se muestran en la Figura 2–1 y que se describen en las secciones anteriores, proporcionan un marco para el diseño de soluciones de software distribuidas. Las tres dimensiones (dependencias de servicios de infraestructura, capas lógicas y calidad del servicio) destacan la función desempeñada por los componentes de Java ES en las arquitecturas de soluciones.

Cada dimensión representa una perspectiva arquitectónica diferente. Cualquier arquitectura de soluciones deberá tomarlas todas en cuenta. Por ejemplo, los componentes distribuidos en cada capa lógica de una arquitectura de soluciones (dimensión 2) deberán estar apoyados por los componentes de infraestructura adecuados (dimensión 1) y los componentes de calidad de servicio adecuados (dimensión 3).

Igualmente, cualquier componente de una arquitectura de soluciones desempeña distintas funciones con respecto a las distintas dimensiones arquitectónicas. Por ejemplo, Directory Server se puede considerar como un componente de servidores en la capa de datos (dimensión 2) y como un proveedor de servicios de persistencia (dimensión 1).

Debido a la centralidad de Directory Server con respecto a estas dos dimensiones, los asuntos de calidad del servicio (dimensión 3) son vitales para este componente de Java ES. Un fallo de Directory Server tendría una tremenda repercusión en un sistema de negocios, de forma que el diseño de alta disponibilidad para este componentes es fundamental; y debido a que Directory Server se utiliza para almacenar información de configuración o de usuario importante, el diseño de seguridad de este componente también es muy importante.

La interrelación de las tres dimensiones con respecto a los componentes de Java ES afecta al diseño de arquitecturas lógicas de soluciones y al diseño de arquitecturas de implementación de soluciones.

Queda fuera del ámbito de este manual la descripción detallada de las metodologías de diseño basadas en el marco arquitectónico que representa Marco arquitectónico de Java Enterprise System. Sin embargo, el marco arquitectónico tridimensional destaca aspectos de diseño que son importantes para comprender la implementación de soluciones de software basadas en Java Enterprise System.

Ejemplo de arquitectura de solución de Java Enterprise System

Java Enterprise System admite una amplia gama de soluciones de software.

Muchas soluciones se pueden diseñar e implementar con los valores de fábrica, sin que sea necesario hacer ningún desarrollo, utilizando los componentes incluidos en Java Enterprise System. Sin embargo, es posible que otras soluciones requieran mayores esfuerzos de desarrollo, por lo que deberá desarrollar componentes J2EE personalizados que proporcionen nuevos servicios de presentación o de negocios. Puede encapsular estos componentes personalizados como servicios web que cumplen con los estándares de interfaz de SOAP (Simple Object Access Protocol). Gran cantidad de soluciones implican una combinación de estos dos planteamientos.

Esta sección proporciona un ejemplo que muestra la forma en que Java Enterprise System admite el uso de una solución con los valores de fábrica elaborada a partir de los conceptos arquitectónicos de la sección anterior.

Escenario de comunicaciones de las empresas

Normalmente, las empresas tienen que fomentar la comunicación entre sus empleados, específicamente los servicios de calendario y de correo electrónico. Dichas empresas, encontrarán ventajoso que sus empleados tengan un acceso personalizado a sitios web internos y otros recursos basándose en la autenticación de la empresa y servicios de autorización. Además, estas empresas desean que se pueda realizar un seguimiento de la identidad de los empleados en todos los servicios de la empresa, de forma que un único inicio de sesión web permita acceder a todos los servicios.

Estos requisitos específicos de la empresa, que representan únicamente un conjunto de ejemplo de los requisitos de la empresa, se resumen en la siguiente tabla.

Tabla 2–4 Resumen de requisitos de negocio: escenario de comunicaciones

Requisitos de la empresa 

Descripción 

Servicios necesarios de Java ES 

Inicio de sesión único 

Acceso a recursos y servicios empresariales seguros basándose en una única identidad con un único inicio de sesión para el acceso web. 

Servicios de identidad 

Mensajería 

Calendario 

Mensajes de correo electrónico entre los empleados y con personas que no pertenecen a la empresa. 

Calendario electrónico del empleado y preparación de reuniones. 

Servicios de comunicación y colaboración 

Acceso al portal 

Un único punto de acceso personalizado basado en web para servicios de comunicación como correo electrónico y calendario, así como páginas web internas. 

Servicios de portal 

Además, una empresa tiene requisitos relativos al rendimiento, la disponibilidad, la seguridad de red y la escalabilidad del sistema de software que proporciona estos servicios.

Arquitectura lógica para el escenario de ejemplo

En la siguiente figura aparece una arquitectura lógica para proporcionar los servicios de identidad, comunicación y portal identificados en la Tabla 2–4 usando los componentes de Java ES. La arquitectura trata configuraciones distintas lógicamente de Messaging Server como componentes separados debido a los distintos servicios que cada una proporciona.

Figura 2–7 Arquitectura lógica para el escenario de comunicaciones de la empresa

Diagrama que muestra la arquitectura lógica del escenario de comunicaciones de la empresa de ejemplo.

Los componentes se colocan en una dimensión horizontal que representa las capas lógicas estándar y en una dimensión vertical que representa los niveles de servicio de infraestructura. Las interacciones entre los componentes dependen de sus funciones como servicios de infraestructura distribuidos (interacciones entre niveles de servicio de infraestructura) o de sus funciones en una arquitectura de aplicaciones de capas (interacciones dentro y entre capas lógicas).

En esta arquitectura, Access Manager, que accede a la información de usuario almacenada en Directory Server, actúa como árbitro de los servicios de autorización y autenticación de inicio de sesión único para Portal Server y en otros componentes basados en web en la capa de presentación. Los componentes de Messaging Server incluyen: un almacén de mensajes (Messaging Server-STR) en la capa de datos, que envía y recupera componentes en la capa de servicios de negocio; otro componente de acceso HTTP; y Communications Express en la capa de presentación.

La arquitectura lógica también muestra las dependencias de los servicios de infraestructura entre los distintos componentes de Java ES. Portal Server, por ejemplo, depende de Communications Express para sus canales de mensajería y calendario. También depende de Access Manager para los servicios de autenticación y autorización. Estos componentes, a su vez, dependen de Directory Server para obtener la información de usuario y los datos de configuración. Varios componentes requieren los servicios de contenedores web proporcionados por Web Server .

Para obtener más información acerca del diseño de soluciones lógicas de Java ES, consulte la Guía de planificación de la implementación de Sun Java Enterprise System 2005Q4.

Arquitectura de implementación para el escenario de ejemplo

Al cambiar de la arquitectura lógica a la arquitectura de implementación, los requisitos de calidad de servicio son vitales. Por ejemplo, las subredes protegidas y los servidores de seguridad se pueden utilizar para crear una barrera de seguridad a los datos de copia de seguridad. Los requisitos de disponibilidad y escalabilidad pueden satisfacerse para varios componentes implementándolos en varios equipos y utilizando equilibradores de carga para distribuir las solicitudes entre los componentes duplicados.

Sin embargo, cuando hay requisitos de disponibilidad más exigentes y se necesitan grandes cantidades de almacenamiento en disco, otras soluciones de disponibilidad son más adecuadas. Por ejemplo, Sun Cluster se puede utilizar para el almacén de Messaging Server y la replicación multimaestro se puede utilizar para Directory Server.

Para obtener más información acerca del diseño de implementaciones de soluciones de Java ES, consulte la Guía de planificación de la implementación de Sun Java Enterprise System 2005Q4.

Términos clave de este capítulo

Esta sección explica los términos técnicos clave utilizados en este capítulo. Se pone un interés especial en clarificar las relaciones entre estos términos y cómo se utilizan en el contexto de Java Enterprise System.

componente de aplicación

Un componente de software desarrollado de forma personalizada para alguna función informática específica que proporciona servicios de negocios a los usuarios finales o a otros componentes de aplicaciones. Un componente de aplicación se ajusta normalmente a un modelo de componente distribuido (como CORBA o la plataforma J2EETM). Estos componentes, juntos o por separado, pueden estar encapsulados como servicios web.

arquitectura

Un diseño que muestra los bloques de construcción físicos y lógicos de una aplicación distribuida (o algún otro sistema de software) y las relaciones entre ellos. En el caso de una aplicación de empresa distribuida, el diseño arquitectónico utiliza generalmente la arquitectura lógica de la aplicación y la arquitectura de implementación.

servicio de negocios

Un componente de aplicación o un ensamblado de componentes que realizan la lógica de negocio en nombre de varios clientes (y es, en consecuencia, un proceso con varios subprocesos). Un servicio de negocio también puede ser un ensamblado de componentes distribuidos encapsulados como un servicio web o puede ser un servidor independiente.

cliente

Software que solicita servicios de software. (Nota: no se trata de una persona; consulte usuario final.)Un cliente puede ser un servicio que solicita otro servicio o un componente de GUI al que obtiene acceso un usuario final.

arquitectura de implementación

Un diseño general que determina la asignación de una arquitectura lógica a un entorno informático físico. El entorno físico incluye los equipos de un entorno de intranet o Internet, los enlaces de red que se establecen entre ellos y otros dispositivos físicos necesarios para la compatibilidad del software.

arquitectura lógica

Un diseño que representa los bloques de construcción de una aplicación distribuida y las relaciones (o interfaces) existentes entre dichos bloques. La arquitectura lógica incluye los componentes de aplicación distribuidos y los componentes de los servicios de infraestructura necesarios para su compatibilidad.

servidor

Un proceso de software con varios subprocesos (a diferencia de un servidor de hardware) que proporciona un servicio distribuido o un conjunto coherente de servicios para los clientes que acceden al servicio mediante una interfaz externa.

servicio web

Un servicio que responde a los protocolos de Internet estándares para funciones de accesibilidad, encapsulación de servicios y detección. Los estándares incluyen el protocolo de mensajería SOAP (del inglés ), la definición de interfaz WSDL (del inglés ) y el estándar de registro UDDI (del inglés ).