El estado del middleware de aplicaciones Java, parte 1

El cliente / servidor está muerto. Ese es el rumor ahora que las nuevas tecnologías basadas en Internet están floreciendo. Pero esas nuevas tecnologías son simplemente la evolución natural de enfoques anteriores, implementadas con protocolos más nuevos y abiertos y diseñadas para proporcionar una mayor escalabilidad, capacidad de administración y diversidad.

La magnitud de esta evolución es asombrosa. La mayoría de los principales proveedores de clientes / servidores han modernizado sus productos y ahora destinan sus dólares de marketing a tecnologías de tres niveles. En la mayoría de los casos, los productos más nuevos están centrados en Java y en el protocolo de Internet. Por ejemplo, identifiqué al menos 46 productos de middleware Java en el último recuento. Hace dos años hubiera sido difícil llegar a la mitad de ese número.

Este es el primero de una serie de dos artículos dedicados a explicar el middleware Java de propósito general en su forma actual. En este primer artículo, examinaré las características de los productos actuales y explicaré por qué estas características son importantes. En la segunda parte, Anil Hemrajani examinará Enterprise JavaBeans (EJB) y mostrará cómo la generación actual de productos de middleware de Java se relaciona y admite este importante estándar de componentes.

Antecedentes

En primer lugar, definamos el middleware de Java.El término abarca servidores de aplicaciones como BEA WebLogic, productos de mensajería como ActiveWorks de Active Software y SpiritWAVE de Push Technologies, y productos híbridos que se basan en un legado de DBMS y agregan características de ejecución de objetos Java basadas en servidor. Podría haberme centrado en un segmento más estrecho, como los servidores de aplicaciones, pero eso habría sido injusto para los muchos productos que no encajan con precisión en esta categoría pero que, sin embargo, deberían considerarse para aplicaciones de varios niveles. Además, incluso entre los servidores de aplicaciones existe un amplio espectro, incluidos los que son principalmente servidores de servlets, así como los que están basados ​​en ORB o OODB. Trazar una línea entre todos estos productos resulta cada vez más difícil. La característica unificadora, sin embargo,es que todos intentan resolver el problema de implementación de aplicaciones de varios niveles utilizando tecnologías Java e Internet.

El caso de negocio para utilizar Java en middleware es convincente; Entre las ventajas que ofrece el middleware Java se encuentran las siguientes:

  • La capacidad de Internet para interconectar económicamente oficinas y organizaciones.

  • La necesidad de que las organizaciones cooperen compartiendo datos y procesos comerciales

  • El deseo de consolidar los servicios genéricos y la gestión de estos servicios

  • El deseo de proporcionar una gestión de aplicaciones centralizada, incluido el inicio, el apagado, el mantenimiento, la recuperación, el equilibrio de carga y la supervisión.

  • El deseo de utilizar servicios y protocolos abiertos.

  • El deseo de volver a implementar la lógica empresarial a voluntad y sin restricciones de infraestructura; Esto requiere el uso de protocolos y API abiertos, que son ampliamente compatibles con la mayoría de los productos de infraestructura.

  • La necesidad de admitir aplicaciones cooperantes de arquitectura mixta

  • El deseo de sacar las decisiones de infraestructura de red y servicios fuera del espacio de la aplicación, de modo que los administradores de sistemas puedan tomar decisiones de infraestructura sin verse obstaculizados por aplicaciones que dependen de protocolos o funciones patentados

  • El deseo de reducir la diversidad y el nivel de habilidades del personal del programador necesarios y minimizar la necesidad de experiencia avanzada en la construcción de herramientas dentro de los proyectos.

  • El deseo de aprovechar la experiencia orientada a objetos extendiéndola al ámbito del servidor, por lo tanto, productos de servidor orientados a objetos más nuevos y puentes de objeto a relacional.

El objetivo del middleware es centralizar la infraestructura de software y su implementación. Cliente / servidor se origina en una era de integración dentro de un solo departamento. Las organizaciones ahora suelen intentar la integración a través de los límites departamentales, incluso de una organización a otra. Internet, que atrae a las empresas con su capacidad para servir como una red global que permite a los departamentos y socios interconectarse de manera eficiente y rápida, ha generado la demanda de esta integración.

Java proporciona una lengua franca para interconectar fácilmente datos y aplicaciones a través de los límites de la organización: en un entorno global distribuido, en el que no tiene control sobre las elecciones tecnológicas que pueden tomar sus socios, las empresas inteligentes eligen estándares abiertos y de plataforma neutral. Las empresas no pueden anticipar quiénes se convertirán en sus clientes, socios o subsidiarias dentro de dos años, por lo que no siempre es posible planificar una infraestructura común con los socios. En esta situación incierta, la mejor decisión puede ser utilizar las tecnologías más universales y adaptables posibles.

Java le permite reducir la cantidad de lenguajes de programación y plataformas que su personal debe comprender. ¿Por qué? Porque Java ahora se implementa en contextos tan diversos como navegadores de Internet, procedimientos almacenados dentro de bases de datos, objetos comerciales dentro de productos de middleware y aplicaciones del lado del cliente.

Sin embargo, a la edad de tres años, la tecnología Java todavía es algo inmadura, y esto es cierto para los productos que se analizan en este artículo. Por otro lado, ahora podemos estar en una era en la que los productos nunca alcanzan la madurez realmente, porque las tecnologías subyacentes en las que se basan cambian muy rápidamente. De hecho, he encontrado problemas importantes con prácticamente todos los productos de middleware que he usado, incluidos los productos supuestamente maduros que han estado en el mercado durante algunos años y que recientemente han presentado nuevas funciones importantes. El punto es que, cuando un proveedor logra solucionar los problemas, se han agregado nuevas funciones. El ciclo para agregar nuevas funciones es ahora mucho más corto que nunca, por lo que los productos no tienen tiempo suficiente para estabilizarse antes de incluir el siguiente conjunto de funciones principales.Esto puede ser algo a lo que tengamos que acostumbrarnos, y conocer las fortalezas y debilidades de los productos que elegimos es una parte importante de cualquier ciclo de diseño y prototipo de aplicación.

Objetivos para middleware

El estándar de componentes de middleware EJB se desarrolló con los siguientes objetivos:

  • Proporcionar interoperabilidad de componentes. Los beans empresariales desarrollados con diferentes herramientas funcionarán juntos. Además, los beans desarrollados con diferentes herramientas se ejecutarán en cualquier entorno EJB.

  • Proporcionar un modelo de programación fácil de usar mientras se mantiene el acceso a las API de bajo nivel.

  • Para abordar los problemas del ciclo de vida, incluidos el desarrollo, la implementación y el tiempo de ejecución.

  • Proporcionar compatibilidad con plataformas existentes, lo que permite ampliar los productos existentes para brindar soporte para EJB.

  • Para mantener la compatibilidad con otras API de Java.

  • Proporcionar interoperabilidad entre aplicaciones EJB y no Java.

  • Ser compatible con CORBA.

Por lo tanto, el enfoque del estándar EJB es crear un estándar de interoperabilidad para middleware Java, protegiendo a los programadores de tener que lidiar con muchos de los problemas difíciles que surgen al desarrollar aplicaciones distribuidas. Esto permite que los desarrolladores de software se concentren en la lógica empresarial en lugar de crear una infraestructura y herramientas sofisticadas propias. Como resultado, las empresas pueden dedicar la mayor parte de sus recursos educativos a capacitar al personal en procesos comerciales, que generalmente es lo que proporciona la mayor recompensa.

A la lista anterior, agrego los siguientes objetivos adicionales para middleware Java de clase empresarial. Estas características del producto son necesarias a largo plazo para ejecutar y mantener con éxito un entorno basado en middleware:

  • Debe acomodar la interconexión de múltiples unidades de negocios, empresas y clientes en una infraestructura distribuida sin comprometer la seguridad o introducir caos.

  • Debe permitir mecanismos de control de acceso flexibles pero confiables para asegurar que se acceda a los datos de los socios comerciales solo en las formas previstas, y solo por las partes previstas

  • Debería permitir que los administradores de sistemas gestionen un entorno informático distribuido que contenga una gran cantidad de componentes de lógica empresarial de forma uniforme, sin tener que comprender o aplicar procedimientos únicos a componentes particulares.

  • Debe permitir a los administradores del sistema realizar selecciones de componentes de infraestructura sin afectar las aplicaciones, y ajustar y escalar esos componentes y tener un medio uniforme y genérico de medir el rendimiento y las necesidades de recursos de todas las aplicaciones.

  • Debería permitir que los componentes comerciales se reubiquen entre clientes y servidores sin afectar las arquitecturas de ninguno de los dos.

  • Debe proporcionar un mecanismo de seguridad que permita a los usuarios particulares agregar nuevos componentes, sin tener que darle al administrador del servidor acceso a todos los componentes y fuentes de datos (esta es una gran oportunidad para la capacidad de valor agregado, ya que es fundamental para las aplicaciones de extranet y asociaciones )

Componentes y características de las plataformas de middleware de Java

La categoría de middleware Java de más rápido crecimiento en la actualidad son probablemente los servidores de aplicaciones. Sin embargo, es esencial darse cuenta de la amplia variedad de servidores de aplicaciones (y otros tipos de productos de middleware) que existen. Las distinciones entre las categorías de productos de middleware de Java en la actualidad no están representadas por una línea, sino por un vasto continuo de middleware. Ahora discutiré las características del middleware de Java, basándome en mis propias comparaciones de trabajo, que abarcan todas las clases de productos de middleware de Java que conozco.

Modelos de objetos, componentes y contenedores

Los componentes de la aplicación deben adherirse a algún modelo de implementación en tiempo de ejecución, que especifica cómo se comunica el componente con su entorno; (posiblemente) cómo se instala, inicia, detiene y llama; y cómo accede a servicios importantes para su entorno. Los modelos populares de contenedor y tiempo de ejecución de componentes de servidor centrados en Java incluyen RMI, EJB, CORBA, DCOM, servlet, JSP (páginas de servidor Java) y procedimientos almacenados de Java. Además, los modelos de componentes se pueden expresar en una variedad de lenguajes subyacentes, incluidos Java, IDL, C ++ y muchos otros.

Hay superposición con varios modelos de componentes. Por ejemplo, RMI es un modelo de componente trivial con instalaciones muy básicas para la activación y ubicación de objetos, y es principalmente un estándar de invocación remota, mientras que EJB aprovecha RMI y especifica RMI como su modelo de invocación de objetos principal. EJB también es compatible con CORBA. De hecho, ninguno de estos modelos es exclusivo y muchos servidores de aplicaciones Java admiten la mayoría o todos los modelos anteriores.

Muchos servidores de middleware Java ejecutan múltiples instancias de objetos comerciales (que el mundo CORBA ahora llama servidores) dentro de una sola máquina virtual Java (JVM). La seguridad de tipos del lenguaje Java permite que un solo proceso de JVM atienda las solicitudes de varios clientes y utilice estructuras de datos de programa y cargadores de clases para mantener separados los datos del cliente. Siempre que los servidores no empleen sus propios métodos nativos, no es posible que un servidor derribe a otros servidores si falla (a menos que encuentre un error en la propia JVM), o acceder a datos que son privados para otras clases . Un servidor de objetos correctamente diseñado protegerá sus objetos privados y evitará que los objetos errantes accedan a lo que pertenece a otros objetos.

Sin embargo, los datos declarados estáticos en una clase Java se pueden compartir entre clientes dentro de la misma JVM si los clientes usan el mismo cargador de clases, por lo que es necesario definir reglas para dictar cuándo una JVM separada (o el equivalente de una JVM separada usando memoria) técnicas de particionamiento) o un cargador de clases separado para dar al cliente su propio espacio de datos estáticos. Estas reglas se han especificado para los subprogramas, pero no para otros entornos de ejecución. El servidor web Java de Sun utiliza una única JVM para todos los servlets y un espacio de nombre de clase separado para los servlets con una base de código diferente. EJB elude el problema prohibiendo los datos estáticos no finales.

El rendimiento se puede aumentar si los objetos se desactivan o pasivan cuando no están en uso, liberando recursos como las conexiones a la base de datos. Por esta razón, muchos servidores pasivan y reactivan objetos según corresponda. De manera similar, algunos productos mantienen los objetos creados con frecuencia en un grupo o caché en un estado inicializado y listos para su uso inmediato. El contenedor de objetos debe gestionar la pasivación y reactivación, así como los recursos agrupados afectados por la pasivación.

Compatibilidad con EJB (versión)

El modelo EJB ya está recibiendo soporte universal. Casi todos los proveedores de middleware se han comprometido a admitirlo y muchos ya lo hacen. Además, el Object Management Group (OMG) ha incorporado un mapeo a EJB como parte de la especificación de componente CORBA propuesta . Es difícil imaginar que incluso Microsoft, el único y firme que se resiste, finalmente no cederá y proporcionará contenedores EJB para DCOM.

Si bien diferentes middleware compatibles con EJB pueden implementar y operar los mismos componentes de la aplicación (siempre que esos componentes usen solo las características estándar de EJB requeridas), todavía hay una gran variación entre los servidores compatibles con EJB. Por un lado, la especificación EJB en sí está evolucionando. Por lo tanto, una pregunta importante al evaluar los productos de middleware de Java es: ¿El servidor admite la última versión de EJB o solo admite una versión anterior? Otra pregunta clave es: ¿El producto está centrado en EJB o el soporte de EJB se incluye solo en las características de valor agregado del producto (y por lo tanto no está disponible cuando se utilizan los servicios de EJB o las API)? Y finalmente: ¿Qué características opcionales de EJB se incluyen (por ejemplo, beans de entidad y persistencia administrada por contenedor)?