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.