En este capítulo, se proporciona una descripción general de los conceptos arquitectónicos en los que se basan las soluciones de Java ES. En este capítulo, se muestra cómo se utilizan los componentes de servicios del sistema y los componentes de calidad del servicio para poder permitir el uso de soluciones de empresa distribuidas.
Las arquitecturas de las soluciones de Java ES tienen dos aspectos: una logical architecture (arquitectura lógica) y una deployment architecture (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.
También se describe una estructura arquitectónica para diseñar arquitecturas de soluciones de Java ES y se muestra una arquitectura de ejemplo basada en dicha estructura. Este capítulo contiene las siguientes secciones:
Los componentes de Java ES admiten la implementación de soluciones de software 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 relacionadas con el diseño de potentes soluciones empresariales. 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:
Dependencias de servicio de infraestructura. Esta dimensión se centra en la función que desempeñan los componentes de servicios del sistema en el uso de soluciones distribuidas (consulte Componentes de servicios del sistema).
Capas lógicas. Esta dimensión se centra en la independencia física y lógica de los componentes de soluciones con el fin de implementarlos en una red o en un entorno de Internet.
Calidad del servicio. Esta dimensión se centra en cómo se satisfacen los requisitos de calidad del servicio como, por ejemplo, la disponibilidad, la seguridad, la escalabilidad y la facilidad de mantenimiento, incluida la función que desempeñan los componentes de calidad del servicio (consulte Componentes de calidad del servicio).
Estas tres dimensiones de la arquitectura de la solución se muestran en la siguiente figura.
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.
Los componentes del software de interacción de las aplicaciones de empresa distribuidas requieren servicios de infraestructura subyacentes 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.
Al diseñar un sistema de software distribuido, con independencia de que esté formado principalmente por los componentes desarrollados de forma personalizada o por los componentes "de fábrica" de Java ES, éste 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 los principales motivos para los componentes de servicios del sistema de Java ES (consulte Componentes de servicios del sistema).
En general, los servicios mostrados en la siguiente figura se dividen 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.
Las siguientes descripciones de los diferentes niveles de servicio de infraestructura hacen referencia a los artefactos del lenguaje de programación de Java, según sea pertinente. La Figura 2–2 muestra los niveles en orden ascendente, de menor a mayor:
Plataforma de sistema operativo. Proporciona la compatibilidad básica para cualquier proceso que se ejecute en un equipo. El sistema operativo administra los dispositivos físicos, así como la memoria, los subprocesos y otros recursos necesarios para poder utilizar la Máquina virtual de Java (JVMTM).
Transporte de red. Proporciona la compatibilidad de red necesaria para las comunicaciones entre los componentes de aplicación distribuidos que se ejecutan en distintos equipos. Estos servicios son compatibles con protocolos como TCP y HTTP. Otros protocolos de comunicación de nivel superior (consulte el nivel de mensajería) dependen de estos servicios de transporte básicos.
Persistencia. Proporciona la compatibilidad necesaria para almacenar datos estáticos (información sobre el usuario, el directorio o la configuración) y datos de aplicación dinámica (información que se actualiza con frecuencia). También permite acceder a estos dos tipos de datos.
Mensajería. Proporciona compatibilidad con las comunicaciones tanto síncronas como asíncronas entre los componentes de la aplicación. La mensajería síncrona es el envío y la recepción de mensajes en tiempo real; incluye llamadas a métodos remotos (RMI) entre componentes de J2EE e interacciones de SOAP con servicios web. La mensajería asíncrona es la comunicación por la cual el envío de un mensaje no depende de la disponibilidad del consumidor para recibirlo inmediatamente. Las especificaciones de mensajería asíncrona, por ejemplo, Java Message Service (JMS) y ebXML, admiten la fiabilidad garantizada y otras semánticas de mensajería.
Tiempo de ejecución.Proporciona la compatibilidad necesaria para cualquier modelo de componente distribuido, como los modelos J2EE o CORBA. Además de la invocación de métodos remotos necesaria para componentes distribuidos y bien acoplados, los servicios de tiempo de ejecución incluyen administración de estado de componentes (ciclo de vida), administración de grupos de subprocesos, sincronización (bloqueo mutuo), servicios de persistencia, supervisión de transacciones distribuidas y gestión de excepciones distribuidas. En un entorno de J2EE, estos servicios de tiempo de ejecución los ofrecen los contenedores web, de EJB y beans controlados por mensajes en un servidor de aplicaciones o en un servidor web.
Seguridad y directiva. Proporciona compatibilidad con el acceso seguro a los recursos de la aplicación. Estos servicios incluyen compatibilidad con las directivas que controlan el acceso basado en roles o en grupos a los recursos distribuidos, así como las funciones de inicio de sesión único. El inicio de sesión único permite que la autenticación de un usuario en un servicio en un sistema distribuido se aplique automáticamente a otros servicios (componentes de J2EE, servicios de negocios y servicios web) del sistema.
Colaboración de usuarios. Proporciona servicios que desempeñan un papel importante al permitir la comunicación directa entre usuarios y la colaboración entre usuarios en entornos de Internet y empresariales. Son servicios de negocios de nivel de aplicación proporcionados normalmente por servidores independientes (como un servidor de correo electrónico o un servidor de calendario).
Integración. Proporciona los servicios que agregan servicios de negocios existentes. Ofrece una interfaz común para acceder a los servicios, como en un portal, o integrando los servicios mediante un motor de procesos que los coordina en el flujo de trabajo de producción. La integración también puede producirse como interacciones de negocio a negocio entre varias empresas.
Los niveles de servicio que se muestran en la Figura 2–2 reflejan una dependencia entre los servicios de infraestructura, desde los servicios del sistema operativo de nivel inferior hasta los servicios de aplicaciones 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.
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 servicios del sistema en los diferentes niveles se muestra en la siguiente figura.
Los cuadros sombreados de la figura hacen referencia a componentes no incluidos en Java ES. Los componentes de colaboración de usuarios no forman parte de Java ES, aunque se implementen a menudo junto con los componentes de Java ES y se utilicen en las arquitecturas de Java ES. Estos componentes forman parte de Sun Java Communications Suite y se hace referencia a ellos en este documento sólo con fines ilustrativos. Además, las plataformas de sistemas operativos no forman parte formalmente de Java ES, pero se incluyen para mostrar las plataformas en las que se pueden utilizar los componentes de Java ES.
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 siguiente tabla, se muestran las relaciones específicas entre los componentes de 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
Los componentes de software de las aplicaciones de empresa distribuidas que interactúan, 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 en función de 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.
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. Aunque los conceptos de las capas lógicas se aplican principalmente a las aplicaciones de empresa personalizadas, también se aplican a los servicios de colaboración proporcionados por los componentes de Sun Java Communications Suite y algunos servicios de portal.
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 los componentes de la aplicación implementados utilizando el modelo de componente de plataforma de J2EE. No obstante, otros modelos de componente distribuidos, como CORBA, también son compatibles con esta arquitectura.
Capa de cliente. La capa de cliente está formada por la lógica de la aplicación a la que el usuario final accede directamente mediante una interfaz de usuario. La lógica de la capa de cliente podría incluir clientes basados en navegadores, componentes de Java que se ejecuten en un equipo de escritorio o clientes móviles de JavaTM Platform, Micro Edition (plataforma J2METM) que se ejecuten en un dispositivo portátil.
Capa de presentación. La capa de presentación está formada por la lógica de aplicación, que prepara datos para su envío a la capa de cliente y procesa solicitudes desde la capa de cliente para su envío a la lógica de negocios del servidor. La lógica en la capa de presentación está formada normalmente por componentes de J2EE como, por ejemplo, Java Servlet o los componentes de JSP que preparan los datos para enviarlos en formato HTML o XML, o que reciben solicitudes para procesarlas. Esta capa también puede incluir un servicio de portal que proporcione acceso personalizado y seguro a los servicios de negocios en la capa de servicios de negocio.
Capa de servicios de negocios. La capa de servicios de negocio consiste en la lógica que realiza las funciones principales de la aplicación: procesamiento de datos, implementación de funciones de negocios, coordinación de varios usuarios y administración de recursos externos como, por ejemplo, bases de datos o sistemas heredados. Esta capa suele estar formada por componentes firmemente acoplados que se ajustan al modelo de componentes distribuidos de J2EE como, por ejemplo, los objetos Java, los componentes EJB o los beans conducidos mediante mensajes. Pueden montarse componentes de J2EE individuales para ofrecer servicios de negocios complejos, como, por ejemplo, un servicio de inventario o uno de cálculo de impuestos. Los componentes individuales y los ensamblados de servicios se pueden encapsular como servicios web que no estén firmemente acoplados en un modelo de arquitectura orientada a servicios, que se ajuste a los estándares de la interfaz SOAP (Simple Object Access Protocol). Los servicios de negocios también se pueden crear como servidores independientes como, por ejemplo, un servidor de mensajería o un servidor de calendario empresarial.
Capa de datos. La capa de datos está formada por los servicios que proporcionan los datos persistentes utilizados por la lógica de negocios. Los datos pueden ser datos de aplicaciones almacenados en un sistema de administración de bases de datos o pueden incluir información de recursos y directorios almacenada en un almacén de datos de protocolo ligero de acceso a directorios (LDAP). Los servicios de datos también pueden incluir alimentación de datos de orígenes externos o datos a los que se puede obtener acceso desde sistemas informáticos heredados.
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:
Independencia lógica. Las cuatro capas del modelo arquitectónico representan independencia lógica: puede modificar la lógica de la aplicación en una capa (por ejemplo, en la capa de servicio de negocios) independientemente de la lógica de las otras capas. Puede cambiar la implementación de la lógica de negocios sin tener que cambiar o actualizar la lógica de la capa de presentación o la de cliente. Esta independencia significa, por ejemplo, que puede introducir nuevos tipos de componentes de clientes sin tener que modificar los componentes de los servicios de negocios.
Independencia física. Las cuatro capas también representan independencia física: es posible implementar la lógica en capas distintas en varias plataformas de hardware (es decir, varias configuraciones de procesador, conjuntos de chips y sistemas operativos). Esta independencia permite ejecutar componentes de aplicación distribuida en los equipos que mejor se adapten a las necesidades informáticas individuales y a maximizar el ancho de banda de red.
La forma de asignar componentes de aplicación o componentes de infraestructura a un entorno de hardware (es decir, la arquitectura de implementación) depende de muchos factores, en función de la escala y la complejidad de la solución de software. Para implementaciones muy pequeñas, una arquitectura de implementación puede implicar sólo unos pocos equipos. Para las implementaciones a gran escala, la asignación de los componentes en un entorno de hardware puede tener en cuenta factores como la velocidad y potencia de los distintos equipos, la velocidad y el ancho de banda de los enlaces de la red, las consideraciones de seguridad y de servidores de seguridad y las estrategias de duplicación de componentes para obtener escalabilidad y una alta disponibilidad.
Tal y como se muestra en la Figura 2–3, los componentes de los servicios de infraestructura de Java ES proporcionan la infraestructura subyacente que permite utilizar soluciones de software distribuidas. Algunas de estas soluciones proporcionan servicios de nivel de aplicación proporcionados por los componentes de Sun Java Communications Suite y algunos 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 . Cada una de estas diferentes configuraciones proporciona un conjunto de servicios distinto. Al diseñar soluciones de mensajería, estas distintas configuraciones se representan como componentes independientes ubicados en diferentes capas lógicas, como se muestra en la siguiente figura en la que las líneas que conectan los componentes representan las interacciones.
La siguiente figura no se ha diseñado para que represente una arquitectura lógica completa. Se han omitido una serie de componentes de Java ES para simplificar la ilustración.
Los componentes de comunicaciones no forman parte de Java ES, aunque se implementen a menudo con los componentes de Java y se utilicen en las arquitecturas de Java ES. Estos componentes de comunicaciones forman parte de Sun Java Communications Suite y se hace referencia a ellos en este documento sólo con fines ilustrativos.
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.
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. Otra dimensión igualmente importante de cualquier solución implementada es la capacidad de ésta para cumplir los requisitos de calidad del 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.
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 del servicio para las arquitecturas de implementación de alto rendimiento y de gran escala.
Para diseñar una solución de software satisfactoria, debe determinar los requisitos de calidad del servicio pertinentes y diseñar una arquitectura que satisfaga dichos requisitos. Se utiliza una serie de importantes calidades del servicio para especificar los requisitos de calidad del 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 |
---|---|
La medición de la latencia y del tiempo de respuesta con relación a las condiciones de carga de usuarios. |
|
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). |
|
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. |
|
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. |
|
La capacidad de un sistema para gestionar el uso de carga máxima inusual sin recursos adicionales. |
|
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 del servicio influye en gran medida en la arquitectura de implementación 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.
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, los equilibradores de carga y los 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:
Componentes de disponibilidad. Proporcionan un tiempo de actividad casi continuo para una solución implementada.
Componentes de acceso. Proporcionan un acceso seguro a los servicios del sistema a través de Internet y, a menudo, también una función de enrutamiento.
Componentes de supervisión. Proporcionan información en tiempo real acerca de los componentes de Java ES.
La siguiente tabla muestra los componentes de calidad del servicio de Java ES más importantes desde una perspectiva arquitectónica, junto con las calidades del 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 |
---|---|
Almacén de sesión de alta disponibilidad |
Disponibilidad |
Monitoring Console |
Facilidad de mantenimiento |
Seguridad Escalabilidad |
|
Sun Cluster |
Disponibilidad Escalabilidad |
Sun Cluster Geographic Edition |
Disponibilidad Escalabilidad |
Web Proxy Server |
Seguridad Rendimiento Escalabilidad |
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 conmutación por error de los recursos que supervisa y utiliza la redundancia interna para proporcionar un acceso prácticamente continuo a estos recursos.
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.
Sun Cluster Geographic Edition proporciona una extensión del software de Sun Cluster. Esta aplicación protege las aplicaciones frente a interrupciones inesperadas mediante el uso de varios clústeres separados geográficamente y una infraestructura que repite los datos entre los clústeres.
Sun Cluster y Sun Cluster Geographic Edition sólo se admiten en el sistema operativo SolarisTM (SO Solaris).
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 una estructura 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. Cada una de las arquitecturas de soluciones deberá tomar todas ellas 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 al carácter central de Directory Server con respecto a estas dos dimensiones, los problemas de calidad del servicio (dimensión 3) son vitales para este componente de Java ES. Un fallo en Directory Server afectaría de forma significativa a un sistema empresarial, por lo que el diseño de alta disponibilidad de este componente es muy importante. Como Directory Server se utiliza para almacenar información de usuario y configuración confidencial, es también muy importante el diseño de la seguridad.
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.
En esta guía no se describen metodologías de diseño detalladas basadas en la estructura arquitectónica representada por Estructura arquitectónica de Java ES. Sin embargo, la estructura arquitectónica tridimensional destaca aspectos de diseño que se deben conocer al implementar soluciones de software basadas en Java Enterprise System.
Java ES 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 llevar a cabo ningún desarrollo, utilizando los componentes incluidos en Java ES. Sin embargo, es posible que otras soluciones requieran mayores esfuerzos de desarrollo, por lo que deberá desarrollar componentes de J2EE personalizados que proporcionen nuevos servicios de presentación o de negocios. Puede encapsular estos componentes personalizados como servicios web que cumplan los estándares de la interfaz SOAP. Gran cantidad de soluciones implican una combinación de estos dos planteamientos.
En esta sección, se proporciona un ejemplo que muestra la forma en que Java ES 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.
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
Requisito empresarial |
Descripción |
Servicios necesarios |
---|---|---|
Inicio de sesión único |
Acceso a recursos y servicios de negocios seguros basándose en una única identidad con un inicio de sesión único 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 |
Puntos de acceso personalizados basados en web para los servicios de comunicación como el correo electrónico y el 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.
En la siguiente figura, se muestra una arquitecta lógica para proporcionar los servicios de identidad, comunicación y portal identificados en la Tabla 2–4 mediante el uso de los componentes de Java ES y de Sun Java Communications Suite (Messaging Server, Calendar Server e Instant Messaging, entre otros). La arquitectura trata configuraciones distintas lógicamente de Messaging Server como componentes separados debido a los distintos servicios que cada una proporciona.
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. 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 Sun Java Enterprise System Deployment Planning Guide.
Al cambiar de la arquitectura lógica a la arquitectura de implementación, los requisitos de calidad del 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 la implementación de soluciones de Java ES, consulte la Sun Java Enterprise System Deployment Planning Guide.
En esta sección, se explican los términos técnicos clave empleados en este capítulo, con especial atención al uso de estos términos en el contexto de Java ES.
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 aplicación. Un componente de aplicación se ajusta normalmente a un modelo de componente distribuido (como CORBA o la plataforma J2EE). Estos componentes, juntos o por separado, pueden estar encapsulados como servicios web.
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 distributed enterprise application (aplicación empresarial distribuida), el diseño arquitectónico utiliza generalmente la logical architecture (arquitectura lógica) de la aplicación y la deployment architecture (arquitectura de implementación).
Un application component (componente de aplicaciones) o un ensamblado de componentes que realizan la lógica de negocios en nombre de varios clientes (y es, en consecuencia, un proceso con varios subprocesos). Un servicio de negocios también puede ser un conjunto de componentes distribuidos encapsulados como un web service (servicio web) o un servidor independiente.
Software que solicita servicios de software. Un cliente puede ser un servicio que solicita otro servicio o un componente de la GUI al que accede un usuario final.
Un diseño general que determina la asignación de una logical architecture (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 vínculos de red que se establecen entre ellos y otros dispositivos físicos necesarios para la compatibilidad del software.
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.
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.
Un servicio que responde a los protocolos de Internet estándares para funciones de accesibilidad, encapsulación de servicios y detección. Entre los estándares, se incluyen el protocolo de mensajería SOAP, la definición de la interfaz WSDL (Web Services Description Language) y el estándar de registro UDDI (Universal Description, Discovery and Integration).