Una guía para principiantes de Enterprise JavaBeans

Enterprise JavaBeans (EJB) ha generado mucho entusiasmo desde el anuncio de marzo de 1998 de la versión 1.0 de la especificación Enterprise JavaBeans. Empresas como Oracle, Borland, Tandem, Symantec, Sybase y Visigenic, entre muchas otras, han anunciado y / o entregado productos que cumplen con la especificación EJB. Este mes, analizaremos en profundidad qué es exactamente Enterprise JavaBeans. Repasaremos en qué se diferencia EJB del modelo de componentes JavaBeans original y discutiremos por qué EJB ha generado un interés tan enorme.

Pero primero, un aviso: este mes no veremos el código fuente ni los temas de procedimientos. Este artículo no es un tutorial; más bien es una descripción arquitectónica. EJB cubre una gran cantidad de territorio, y sin comprender primero los conceptos básicos involucrados, los fragmentos de código y los trucos de programación no tienen sentido. Si hay interés por parte de los lectores de JavaWorld , los artículos futuros pueden cubrir los detalles del uso de la API Enterprise JavaBeans para crear sus propios Enterprise JavaBeans.

Para comprender por qué EJB es tan atractivo para los desarrolladores, necesitamos algunos antecedentes históricos. Primero, veremos la historia de los sistemas cliente / servidor y el estado actual de las cosas. Luego, discutiremos las diversas partes de un sistema EJB: componentes EJB , que viven en un contenedor EJB que se ejecuta dentro de un servidor EJB , y objetos EJB, que el cliente usa como una especie de "control remoto" de los componentes EJB. . Repasaremos los dos tipos de EJB: sesión y objetos de entidad . También leerá sobre hogar y control remotointerfaces, que crean instancias de EJB y proporcionan acceso a los métodos de negocio de EJB, respectivamente. Al final del artículo, tendrá una idea de cómo se pueden construir servidores extensibles usando Enterprise JavaBeans. Pero primero, una mirada al pasado.

Historial cliente / servidor

Historia antigua

Al principio, estaba la computadora central. Y estuvo bien. (O tan bueno como se puso, de todos modos). El estado del arte en el procesamiento de información durante la década de 1960 consistió principalmente en máquinas grandes y costosas utilizadas por grandes organizaciones para respaldar sus operaciones comerciales diarias. Las minicomputadoras y el tiempo compartido en la década de 1970 aumentaron la accesibilidad de la potencia informática, pero la información y el procesamiento todavía estaban centralizados en máquinas individuales. Las primeras computadoras personales en la década de 1980 rápidamente abarrotaron el panorama corporativo con miles de pequeñas islas de información, todas produciendo incansablemente informes de calidad variable, perdiendo datos críticos cuando fallaban y volviéndose rápidamente inconsistentes entre sí.

Cliente / servidor al rescate

La arquitectura cliente / servidor es una de las soluciones más comunes al enigma de cómo manejar la necesidad tanto de un control de datos centralizado como de una amplia accesibilidad a los datos. En los sistemas cliente / servidor, la información se mantiene relativamente centralizada (o se particiona y / o se replica entre servidores distribuidos), lo que facilita el control y la coherencia de los datos, al mismo tiempo que proporciona acceso a los datos que los usuarios necesitan.

Los sistemas cliente-servidor ahora se componen comúnmente de varios números de niveles. El antiguo sistema estándar de mainframe o tiempo compartido, donde la interfaz de usuario se ejecuta en la misma computadora que la base de datos y las aplicaciones comerciales, se conoce como un solo nivel. Estos sistemas son relativamente fáciles de administrar y la consistencia de los datos es simple porque los datos se almacenan en un solo lugar. Desafortunadamente, los sistemas de un solo nivel tienen una escalabilidad limitada y son propensos a riesgos de disponibilidad (si una computadora falla, todo su negocio falla), particularmente si hay comunicación involucrada.

Los primeros sistemas cliente / servidor eran de dos niveles, donde la interfaz de usuario se ejecutaba en el cliente y la base de datos vivía en el servidor. Estos sistemas todavía son comunes. Un tipo de variedad de jardín de servidor de dos niveles realiza la mayor parte de la lógica empresarial en el cliente, actualizando los datos compartidos mediante el envío de secuencias de SQL al servidor. Esta es una solución flexible, ya que la conversación cliente / servidor se produce al nivel del idioma de la base de datos del servidor. En tal sistema, un cliente diseñado correctamente puede modificarse para reflejar nuevas reglas y condiciones comerciales sin modificar el servidor, siempre que el servidor tenga acceso al esquema de la base de datos (tablas, vistas, etc.) necesario para realizar las transacciones. El servidor en un sistema de dos niveles de este tipo se denomina servidor de base de datos, como se muestra a continuación.

Sin embargo, los servidores de bases de datos tienen algunas responsabilidades. A menudo, el SQL para una función comercial en particular (por ejemplo, agregar un artículo a un pedido) es idéntico, con la excepción de que los datos se actualizan o insertan, de una llamada a otra. Un servidor de base de datos termina analizando y volviendo a analizar SQL casi idéntico para cada función empresarial. Por ejemplo, es probable que todas las instrucciones SQL para agregar un artículo a un pedido sean muy similares, al igual que las instrucciones SQL para encontrar un cliente en la base de datos. El tiempo que lleva este análisis se dedicaría mejor a procesar datos. (Existen soluciones para este problema, incluidos los procedimientos almacenados y los cachés de análisis de SQL). Otro problema que surge es el control de versiones de los clientes y la base de datos al mismo tiempo: todas las máquinas deben apagarse para las actualizaciones,y los clientes o servidores que se retrasan en su versión de software normalmente no se pueden utilizar hasta que se actualizan.

Servidores de aplicaciones

Una arquitectura de servidor de aplicaciones (vea la siguiente imagen) es una alternativa popular a una arquitectura de servidor de base de datos porque resuelve algunos de los problemas que tienen los servidores de base de datos.

Un entorno de servidor de base de datos generalmente ejecuta métodos comerciales en el cliente y utiliza el servidor principalmente para la persistencia y el cumplimiento de la integridad de los datos. En un servidor de aplicaciones, los métodos comerciales se ejecutan en el servidor y el cliente solicita que el servidor ejecute estos métodos. En este escenario, el cliente y el servidor normalmente utilizarán un protocolo que representa una conversación a nivel de transacciones comerciales, en lugar de a nivel de tablas y filas. Estos servidores de aplicaciones a menudo funcionan mejor que sus contrapartes de bases de datos, pero aún sufren problemas de versiones.

Tanto los sistemas de aplicaciones como de bases de datos se pueden mejorar agregando niveles adicionales a la arquitectura. Los llamados sistemas de tres niveles colocan un componente intermedio entre el cliente y el servidor. Ha surgido toda una industria, el middleware, para abordar las responsabilidades de los sistemas de dos niveles. Un monitor de procesamiento de transacciones,un tipo de middleware, recibe flujos de solicitudes de muchos clientes y puede equilibrar la carga entre varios servidores, proporcionar conmutación por error cuando falla un servidor y administrar transacciones en nombre de un cliente. Otros tipos de middleware proporcionan traducción de protocolos de comunicaciones, consolidan solicitudes y respuestas entre clientes y múltiples servidores heterogéneos (esto es particularmente popular en el manejo de sistemas heredados en la reingeniería de procesos comerciales) y / o proporcionan medición de servicios e información de tráfico de red.

Los niveles múltiples brindan una flexibilidad e interoperabilidad que ha dado como resultado sistemas con más de estas tres capas de servicio. Por ejemplo, los sistemas de n niveles son generalizaciones de sistemas de tres niveles, cada capa de software proporciona un nivel de servicio diferente a las capas superiores e inferiores. La perspectiva de n niveles considera que la red es un conjunto de servicios distribuidos, en lugar de simplemente el medio para que un cliente acceda a un solo servidor.

A medida que los lenguajes y técnicas orientados a objetos se han puesto de moda, los sistemas cliente / servidor se han movido cada vez más hacia la orientación a objetos. CORBA (Common Object Request Broker Architecture) es una arquitectura que permite que los objetos dentro de las aplicaciones, incluso los objetos escritos en diferentes idiomas, se ejecuten en máquinas separadas, según las necesidades de una aplicación determinada. Las aplicaciones escritas hace años se pueden empaquetar como servicios CORBA e interoperar con nuevos sistemas. Enterprise JavaBeans, que está diseñado para ser compatible con CORBA, es otra entrada al anillo del servidor de aplicaciones orientado a objetos.

El propósito de este artículo no es proporcionar un tutorial sobre sistemas cliente / servidor, pero fue necesario proporcionar algunos antecedentes para definir el contexto. Ahora veamos lo que EJB tiene para ofrecer.

Enterprise JavaBeans y servidores de aplicaciones extensibles

Ahora que hemos analizado un poco la historia y entendemos qué son los servidores de aplicaciones, veamos Enterprise JavaBeans y veamos qué ofrece en ese contexto.

La idea básica detrás de Enterprise JavaBeans es proporcionar un marco para los componentes que pueden "conectarse" a un servidor, extendiendo así la funcionalidad de ese servidor. Enterprise JavaBeans es similar a los JavaBeans originales solo en que utiliza algunos conceptos similares. La tecnología EJB no se rige por la especificación de componentes JavaBeans, sino por la especificación Enterprise JavaBeans completamente diferente (y masiva) . (Consulte Recursos para obtener detalles sobre esta especificación). La especificación EJB llama a los diversos actores en el sistema cliente / servidor EJB, describe cómo EJB interopera con el cliente y con los sistemas existentes, detalla la compatibilidad de EJB con CORBA y define las responsabilidades para los diversos componentes del sistema.

Objetivos de Enterprise JavaBeans

La especificación EJB intenta cumplir varios objetivos a la vez:

  • EJB está diseñado para facilitar a los desarrolladores la creación de aplicaciones, liberándolas de los detalles del sistema de bajo nivel de la gestión de transacciones, subprocesos, equilibrio de carga, etc. Los desarrolladores de aplicaciones pueden concentrarse en la lógica empresarial y dejar los detalles de la gestión del procesamiento de datos al marco. Sin embargo, para aplicaciones especializadas, siempre es posible obtener "bajo el capó" y personalizar estos servicios de nivel inferior.

  • La especificación EJB define las estructuras principales del marco EJB y luego define específicamente los contratos entre ellas. Las responsabilidades del cliente, el servidor y los componentes individuales están claramente definidas. (Repasaremos cuáles son estas estructuras en un momento). Un desarrollador que crea un componente Enterprise JavaBean tiene un rol muy diferente al de alguien que crea un servidor compatible con EJB, y la especificación describe las responsabilidades de cada uno.

  • EJB pretende ser la forma estándar para que las aplicaciones cliente / servidor se construyan en el lenguaje Java. Así como los JavaBeans originales (o los componentes de Delphi, o lo que sea) de diferentes proveedores se pueden combinar para producir un cliente personalizado, los componentes del servidor EJB de diferentes proveedores se pueden combinar para producir un servidor personalizado. Los componentes de EJB, que son clases de Java, se ejecutarán por supuesto en cualquier servidor compatible con EJB sin volver a compilarlos. Este es un beneficio que las soluciones específicas de la plataforma no pueden ofrecer.

  • Por último, EJB es compatible y utiliza otras API de Java, puede interoperar con aplicaciones que no son de Java y es compatible con CORBA.

Cómo funciona un sistema cliente / servidor EJB

Para comprender cómo funciona un sistema cliente / servidor EJB, necesitamos comprender las partes básicas de un sistema EJB: el componente EJB, el contenedor EJB y el objeto EJB.

El componente Enterprise JavaBeans

Un Enterprise JavaBean es un componente, al igual que un JavaBean tradicional. Enterprise JavaBeans se ejecuta dentro de un contenedor EJB, que a su vez se ejecuta dentro de un servidor EJB. Cualquier servidor que pueda albergar un contenedor EJB y proporcionarle los servicios necesarios puede ser un servidor EJB. (Esto significa que muchos servidores existentes pueden extenderse para ser servidores EJB y, de hecho, muchos proveedores lo han logrado o han anunciado la intención de hacerlo).

Un componente EJB es el tipo de clase EJB que probablemente se considere un "Enterprise JavaBean". Es una clase de Java, escrita por un desarrollador de EJB, que implementa la lógica empresarial. Todas las demás clases del sistema EJB admiten el acceso del cliente o proporcionan servicios (como persistencia, etc.) a las clases de componentes de EJB.

El contenedor Enterprise JavaBeans

El contenedor EJB es donde "vive" el componente EJB. El contenedor EJB proporciona servicios tales como gestión de recursos y transacciones, control de versiones, escalabilidad, movilidad, persistencia y seguridad a los componentes EJB que contiene. Dado que el contenedor EJB maneja todas estas funciones, el desarrollador del componente EJB puede concentrarse en las reglas de negocio y dejar la manipulación de la base de datos y otros detalles tan finos al contenedor. Por ejemplo, si un solo componente EJB decide que la transacción actual debe ser abortada, simplemente le dice a su contenedor (de la manera definida por la Especificación EJB, y el contenedor es responsable de realizar todas las reversiones, o hacer lo que sea necesario para cancelar una Transacción en curso Normalmente, existen varias instancias de componentes EJB dentro de un único contenedor EJB.

El objeto EJB y la interfaz remota

Los programas cliente ejecutan métodos en EJB remotos mediante un objeto EJB. El objeto EJB implementa la "interfaz remota" del componente EJB en el servidor. La interfaz remota representa los métodos "comerciales" del componente EJB. La interfaz remota realiza el trabajo útil y real de un objeto EJB, como crear un formulario de pedido o remitir un paciente a un especialista. Analizaremos la interfaz remota con más detalle a continuación.