La Enciclopedia Libre Universal en Español dispone de una lista de distribución pública, enciclo@listas.us.es

Java 2 Enterprise Edition

De la Enciclopedia Libre Universal en Español
Saltar a: navegación, buscar
Este artículo necesita ser wikificado
Este artículo debe wikificarse, según los convenios de edición y estilo de la «Enciclopedia Libre».
Edítelo para mejorar su formato.

J2EE son las siglas de Java 2 Enterprise Edition que es la edición empresarial del paquete Java creada y distribuida por Sun Microsystems. Comprende un conjunto de especificaciones y funcionalidades orientadas al desarrollo de aplicaciones empresariales. Debido a que J2EE no deja de ser un estándar, existen otros productos desarrollados a partir de la misma.

Algunas de sus funcionalidades más importantes son:

Conceptos de J2EE

Introducción

La plataforma Java 2, Enterprise Edition (J2EE) es fruto de la colaboración de SUN con los líderes del sector del software empresarial (IBM, Apple, Bea Systems, Oracle, Inprise, Hewlett-Packard, Novell, etc.) para definir una plataforma robusta y flexible orientada a cubrir las necesidades empresariales en e-business y business-to-business.

Las empresas necesitan constantemente extender su alcance, reducir sus costos, y bajar sus tiempos de respuesta para proporcionar un fácil acceso a sus clientes, empleados y proveedores. Generalmente, las aplicaciones que proporcionan estos servicios deben combinar Sistemas de Información de la Empresa (EISs) existentes o heredados, con nuevas funciones que entregan servicios a un gran espectro de usuarios.

Estos servicios necesitan cumplir con ciertos requisitos:

  1. Alta disponibilidad, de forma tal que el servicio pueda ser usado sin inconvenientes la gran mayoría del tiempo.
  2. Seguridad, para asegurar la privacidad de los usuarios y la integridad y confidencialidad de las transacciones y la información procesada.
  3. Escalabilidad, que garantice que los servicios seguirán operativos aunque el número de usuarios, de transacciones o el volumen de información sufran aumentos importantes.

En la mayoría de casos, estos servicios son diseñados como aplicaciones multi-tier. Un middle-tier se necesita para implementar un nuevo servicio, integrar las existentes EISs con las funciones del negocio y los datos del servicio nuevo. El servicio de middle-tier es el first-tier, dada la complejidad de la empresa y aprovecha las tecnologías maduras del web para eliminar rápidamente o reducir drásticamente la administración y el entrenamiento de los usuarios manteniendo los recursos existentes en la empresa.

La plataforma Java2, Edición Empresarial (J2EE) reduce el costo y complejidad de desarrollo estos servicios multi-tier, y da por resultado servicios que pueden ser creados rápidamente y fácilmente mejorados respondiendo a las presiones competitivas de la empresa.

J2EE cumple estos objetivos por definir una arquitectura normal que se entrega con los siguientes elementos:

  • J2EE BluePrint - Un modelo de aplicación estándar para desarrollo multi-tier, y servicios thin-client.
  • J2EE Platform - Una plataforma estándar para albergar las aplicaciones J2EE.
  • J2EE Compatiility Test Suite - Una colección de tests de compatibilidad para verificar que un producto J2EE cumple con el estándar de la plataforma J2EE.
  • J2EE Reference Implementation - Una aplicación de referencia para demostrar las capacidades de J2EE y proporcionar una definición operacional de la plataforma J2EE.


Antecedentes

Modelos de 2 niveles

La arquitectura que se debe adoptar para el desarrollo de un sistema depende del tipo de aplicación que se quiera implantar. Aplicaciones sencillas podrán ser desarrolladas siguiendo modelos simples. Para aplicaciones más complejas se necesitarán arquitecturas más robustas, flexibles, escalables y de fácil integración. La arquitectura llamada de 2 niveles describe la forma en que las aplicaciones pueden ser divididas siguiendo la arquitectura cliente/servidor. La arquitectura cliente/servidor es un modelo para el desarrollo de sistemas de información en el que las transacciones se dividen en procesos independientes que cooperan entre sí para intercambiar información, servicios o recursos. En este modelo las aplicaciones se dividen de forma que el servidor contiene la parte que debe ser compartida por varios usuarios y en el cliente permanece sólo lo particular de cada usuario. Soluciones de dos niveles son adecuadas para el desarrollo de aplicaciones simples, como por ejemplo para la visualización de páginas Web estáticas. Los principales problemas que presentan estos modelos es su incapacidad para adaptarse a entornos cambiantes y a los aumentos del volumen de usuarios o de datos. Además, estos modelos carecen de flexibilidad para el desarrollo de objetos reutilizables. Por tanto, cuando la complejidad de los sistemas aumenta, será necesario la utilización de modelos más complejos que permitan resolver los problemas que presentan las soluciones a 2 niveles.

J2EE: Modelo Multinivel

La arquitectura de varios niveles añade al modelo de 2 niveles nuevas capas que permiten resolver los problemas en cuanto a escalabilidad, adaptabilidad, integración y reutilización de objetos que presentaban los modelos de 2 niveles. El diseño de las aplicaciones de varios niveles puede encerrar una gran dificultad. Estas aplicaciones requieren la unificación de distintos recursos y capacidades, además del código y de los datos heredados. J2EE envuelve y engloba todos los recursos existentes necesarios para las aplicaciones de multinivel utilizando un modelo unificado y basado en componentes, que simplifica y minimiza la complejidad del desarrollo de este tipo de aplicaciones. Este documento proporciona algunos datos acerca de la especificación de la plataforma J2EE y describe ciertos requisitos que un producto J2EE debe reunir.

¿Qué es J2EE?

Es una plataforma que habilita soluciones para desarrollo, uso efectivo y manejo de multicapas en aplicaciones centralizadas en el servidor.

J2EE utiliza la plataforma Java 2 SE, para tender una completa, estable, segura, y rápida plataforma Java en el ámbito de la empresa. Permite ahorrar a la compañía, porque habilita una plataforma que reduce de manera significativa los costos y la complejidad de desarrollo de soluciones multicapas, resultando en servicios que pueden ser desarrollados rápidamente y ampliados fácilmente.


¿Qué tecnologías son incluidas en J2EE?

  • Enterprise JavaBeansTM
  • JavaServers PagesTM
  • Servlets Java Naming and Directory InterfaceTM (JNDI)
  • Java Transaction API (JTA)
  • CORBA
  • API de acceso a datos JDBCTM.


¿Quién necesita J2EE?

ISVs (Independient Software Vendors) necesitan J2EE porque les da un esquema para proveer de una solución completa para empresas en la plataforma Java. Los desarrolladores necesitan J2EE porque escribir aplicaciones distribuidas en empresas es muy duro, y ellos necesitan una solución de alta productividad que les permita enfocarse sólo en escribir la lógica y tener un completo rango de servicios en que confiar (enterprise-class), como objetos de transacciones distribuidas o middleware orientado a objetos, etc.


Apreciación global de la plataforma

Especificaciones J2EE

Java 2, Enterprise Edition, aprovecha muchas de las características de la plataforma Java, como la portabilidad "Write Once, Run Anywhere", el Application Program Interface (API) JDBC para el acceso a bases de datos, las tecnología CORBA para la interacción con los recursos existentes de la empresa y un modelo de seguridad que protege los datos incluso en la aplicaciones para Internet. Sobre esta base, Java 2 Enterprise Edition añade el soporte completo para componentes Enterprise Java Beans, el API Java Servlets y la tecnología JavaServer Pages. El estándar J2EE incluye todas las especificaciones y pruebas de conformidad que permiten la portabilidad de las aplicaciones a través de la amplia gama de sistemas empresariales compatibles con J2EE.

Arquitectura de J2EE

J2EE esta basado en la arquitectura del lado del servidor (Served-based). Este tipo de arquitectura concentra la mayoría de los procesos de la aplicación en el servidor o en un pedazo de este. Este tipo de arquitectura tiene dos ventajas críticas en comparación con los otros tipos, estos son:

  • Múltiples Clientes: Una arquitectura basada en el servidor requiere una clara separación entre la capa cliente (interfaz) y la capa servidor, en la cual se realizan los procesos de la aplicación. Esto permite que una simple aplicación soporte simultáneamente clientes con distintos tipos de interfaces, incluyendo poderosas interfaces (gráficas) para equipos corporativos, interfaces multimedia interactivas para usuarios con conexiones de alta velocidad, interfaces eficientes basadas en texto para usuarios con conexiones de baja velocidad, etc.
  • Operaciones robustas: Una arquitectura basada en el servidor so-porta escalabilidad, confiabilidad, disponibilidad y recuperabilidad. Aplicaciones basadas en el servidor pueden ser divididas y distribuidas en múltiples procesadores. Componentes de la aplicación pue-den ser replicados para dar soporte a caídas instantáneamente.

La plataforma de J2EE provee un conjunto de APIs de java y servicios necesarios para el soporte de aplicaciones para empresas. La plataforma completa puede ser implementada en un solo sistema, o la plataforma de servicios puede ser distribuida a través de varios sistemas, pero todas las APIs especificadas deben ser incluidas en alguna parte del sistema completo. A continuación podemos ver una ilustración de la arquitectura.


El ambiente de runtime de J2EE consta de las siguientes partes:

Application components:

Componentes de la aplicación. El modelo de programación de J2EE de-fine cuatro tipos de componentes de la aplicación que un producto J2EE debe soportar:

1. Clientes de la Aplicación, son programas creados en Java que son generalmente programas GUI, que ejecutan sobre una computadora de escritorio. La aplicación cliente ofrece a un usuario la experimenta similar al de las aplicaciones nativas, y tiene acceso a todo de los medios de la J2EE middle-tier.

2. Applet´s, son GUI component que generalmente procesan un pro-grama en un web browser, pero puedan procesar una variedad de otras aplicaciones o dispositivos que soportan el modelo de programación del applet. Las Applets pueden ser usadas para proporcionar una poderosa interfaz de usuario para las aplicaciones J2EE. (Simples páginas HTML se pueden usar también para proporcionar una interfaz de usuario más limitada para aplicaciones J2EE.)

3. Páginas Servlets y JSP generalmente procesan un programa en un servidor Web y responden a las peticiones HTTP de los clientes Web. Las páginas Servlets y JSP pueden ser utilizadas para que generen páginas HTML que son aplicación de interfaz de usuario. Pueden también usadas para generar XML u otro formato de datos que se consumen por otros componentes de la aplicación. Servlets, y pági-nas creadas con la tecnología JavaServer Pages, se refieren con-juntamente a menudo en ésta especificación como "Web components, componentes web." Las aplicaciones Web están compuestas de Web components y otros datos tal como las páginas HTML.

4. Enterprise JavaBeans (EJB) components, procesan en un ambiente controlado las transacciones soportadas. Enterprise beans general-mente contienen la lógica del negocio por una aplicación J2EE.

Estos componentes de la aplicación se pueden dividir en tres categorías:

1. Componentes que se despliegan, manejan, y se ejecutan sobre un servidor J2EE. Estos componentes incluyen JavaServer Pa-ges, Servlets, y Enterprise JavaBeans.

2. Componentes que se despliegan y manejan en un servidor J2EE, pero está cargado y se ejecuta en una máquina cliente. Estos componentes incluyen páginas HTML y applets incluidas en las páginas HTML.

3. Componentes cuyo despliegue y manejo no se definió completa-mente en esta especificación. Aplicaciones de los clientes caen en esta categoría. Futuras versiones de esta especificación pueden definir completamente el manejo de las aplicaciones del cliente.


Containers:

Los containers proporcionan el soporte para los componentes de la aplicación. Un container proporciona una vista del subyacente J2EE-APIs de los componentes de la aplicación. Interponer un container entre el componente de la aplicación y el servicio J2EE permite a los containers inyectar transparentemente servicios definidos por los componentes, tal como el manejo de la transacción, chequeos de seguridad,

Pooling de recursos

Y manejo de estados. Un producto típico J2EE proporcionará un container por cada componente de la aplicación del tipo: container de la aplicación cliente, applet container, containers del componente web, y containers del enterprise beans. Esta especificación requiere que estos containers proporcionan un am-biente Java Compatible, como se definió para la plataforma Java 2 Plataforma, Edición Normal, v1,3 especificación (J2SE). El applet container usaría el producto Java Plugin para proporcionar este ambiente, o proporcionaría él nativo. El uso de applet containers proporcionan sólo el JDK 1,1 APIs está fuera del alcance de esta especificación. Las herramientas de containers también en-tienden la estructura del archivo por empaquetamiento de los componentes de la aplicación. Los containers son implementados por un Product Provider J2EE.

La especificación define un juego de servicios estándar para cada producto J2EE. Se describen estos servicios estándar más abajo. El J2EE container proporcionan el APIs para acceder a estos servicios a lo componentes de aplicación. Esta especificación también describe maneras estándar de extender los servicios J2EE con conectores a otros sistemas de aplicación non-J2EE, tal como sistemas de mainframes y sistemas ERP. Subyacentemente los containers J2EE son el J2EE núcleo. Un J2EE Product Provider generalmente implementa el núcleo del servidor J2EE usan-do una transacción existente de la infraestructura en combinación con tecnolo-gía Java 2. El núcleo del cliente J2EE está generalmente montado sobre una plataforma Java 2 Edición estándar.

La Figura 2-1, ilustra la relación de estos componentes de la plataforma J2EE. Note que esta figura muestra las relaciones lógicas de los componentes; esto no significa o implica una división física de los componentes en separado de máquinas, procesadores, espacios de la dirección, o máquinas virtuales.


Drivers de manejo de recursos.

Un driver de manejo de recursos (driver) es un componente de software de nivel del sistema que lleva a cabo la conectividad de la red a un manejador de recursos externo. Un driver puede extender la funcionalidad de la plataforma J2EE por implementar un servicio estándar J2EE APIs (tal como un driver JDBC), o por definición, implementar un driver de manejo de recursos para un conector a una aplicación externa. Los drivers unen a la plataforma J2EE a través del proveedor de servicios de interfaces (J2EE SPI). Un driver que usa el J2EE SPIs para unir la plataforma J2EE tendrá la habilidad de trabajar con todos los productos J2EE.

Base de datos:

La plataforma J2EE incluye una base de datos, accesible por el JDBC API, para el almacenamiento de datos. El banco de datos es accesible desde los componentes web, Enterprise beans, y componentes de la aplicación del cliente. La base de datos no necesita ser accedida por los applets.

Servicios

El estándar J2EE incluye los siguientes servicios. Algunos de estos ser-vicios estándar son provistos en la actualidad por J2SE.

  • HTTP. El HTTP client-side API es definido por el java.net package. El HTTP server-side API es definido por el servlet y las interfaces JSP.
  • HTTPS. Usa el protocolo HTTP sobre el protocolo SSL y es soportado por el mismo cliente y servidor API como HTTP.
  • Java Transaction API (JTA). El Java Transaction API (JTA) consta de dos partes:

1. Una interfaz definida a nivel aplicación que es utilizada por el con-tainer y los componentes de la aplicación para delimitar una transac-ción 2. Una interfaz entre el manejador de la transacción y el manejador de recursos usado al nivel de J2EE SPI. (para un próximo lanzamiento).


RMI-IIOP

El subsistema RMI-IIOP se compone por APIs que permiten utilizar el ti-po de programación RMI-style que es independiente del protocolo interno, así como una aplicación de estos APIs que soporta ambos, el protocolo nativo J2SE RMI (JRMP) y el protocolo CORBA IIOP. Las aplicaciones J2EE pueden usar RMI-IIOP, con el soporte del protocolo IIOP, para acceder a los servicios CORBA que son compatibles con las restricciones de programación RMI (para detalles vea RMI-IIOP specifications). Como los servicios CORBA estarían ge-neralmente definidos por componentes que están por fuera de un producto J2EE, normalmente en un sistema legado (legacy system). Únicamente las aplicaciones clientes J2EE requieren de la habilidad para definir directamente sobre un servicio CORBA, utilizando las RMI-IIOP APIs. Generalmente se usa-rían objetos CORBA por llamadas cuando se acceda a otro objeto CORBA. Las aplicaciones J2EE se requieren usar el RMI-IIOP APIs J2EE aplicaciones (es-pecíficamente el método estrecho de [javax.rmi.PortableRemoteObject]) cuan-do accede.

Componentes JavaBeans

Como describe en la especificación EJB. Éste deja que Enterprise beans estén protocolarmente independientes. Además, los productos J2EE deben ser capaces de exportar Enterprise beans usando el protocolo IIOP, y acceder a los Enterprise beans usando este protocolo, como se especificó en el EJB 2,0. La habilidad usar el IIOP requiere que el protocolo habilite la interoperabilidad entre los productos J2EE, sin embargo un producto J2EE puede también usen otros protocolos.

JavaIDL

JavaIDL permite que los componentes de la aplicación J2EE invoquen a objetos externos CORBA utilizando el protocolo IIOP. Estos objetos CORBA se escriben en cualquier lenguaje y generalmente residen fuera del producto J2EE. Las aplicaciones J2EE pueden utilizar JavaIDL para actuar como clien-tes de los servicios CORBA, pero sólo a las aplicaciones cliente J2EE se les permite acceder a JavaIDL directamente a los servicios CORBA presentes.

JDBC

El JDBC API es el API para conectividad con sistemas de bases de datos relaciónales. El JDBC API tiene dos partes: una aplicación de nivel interfaz usada por los componentes de la aplicación para acceder a la base de datos, y un proovedor del servicio para conectar un driver JDBC a la plataforma J2EE.

Java Message Service(JMS)

El Java Message Service es un API estándar por mensajes confiable que soporta messaging de punto-a-punto así como el modelo de publish-subscribe. Esta especificación requiere un proveedor JMS que implementa ambos, messaging de punto-a-punto así como mensajes publish-subscribe.

Java Naming and Directory Interface (JNDI).

El JNDI API es el API estándar para acceder y nominar directorios. El JNDI API tiene dos partes: una interfaz de nivel de aplicación usada por los componentes de la aplicación para acceder al servicio de nombres y directorio y un servicio del proveedor del servicio para enlazar al proveedor de servicios de nombres y directorios.

JavaMail

Muchas aplicaciones Internet requieren la inteligencia para enviar notificaciones por e-mail, así la plataforma J2EE incluye el JavaMail API junto con un servicio JavaMail que permite a un componente de la aplicación enviar un e-mail. La JavaMail API tiene dos partes: una interfaz de nivel de la aplicación utilizada por los componentes de la interfaz para enviar correo, y un proveedor del servicio utilizado a nivel del J2EE SPI.

JavaBeans Activation Framework (JAF)

La JavaMail API utiliza la JAF API, a tal punto que la incluya también.

Java API for XML Parsing (JAXP)

JAXP proporciona soporte a la industria para el estándar SAX y DOM APIs for parsing XML documents.

J2EE Connector Architecture.

La arquitectura del Conector es un J2EE SPI que permite a los adaptadores de recurso que soportan acceso a los sistemas de información de la empresa, conectarse a cualquier producto J2EE. La arquitectura del conector define un conjunto estándar fijo de contratos a nivel del sistema entre un servidor J2EE y un adaptador del recurso. El contrato estándar incluye:

- Un contrato para el manejo de la conexión permite un que un servidor J2EE agrupe conexiones a un EIS subyacente y permite a los componentes de la aplicación conectarse a un EIS. Éste encamina a un ambiente escalable a la aplicación que puede soportar un gran número de clientes que requieren acceso a sistemas EIS.

- Un contrato de manejador de transacciones entre el manejador de la transacción y EIS que soporta el acceso a los recursos EIS. Éste contrato permite un servidor J2EE usar un manejador de transacción para manejar las transacciones a través de múltiples manejadores de recursos. Este contrato también soporta las transacciones que se manejan interiormente a un manejador de recursos EIS sin la necesidad de involucrar a un manejador de transacción externo.

- Un contrato de seguridad que habilita el acceso seguro a un EIS. Este contrato proporciona soporte por un ambiente de aplicación seguro, que reduce las amenazas sobre el EIS y protege los recursos y la información manejado por el EIS.

Java Authentication y Authorization Service (JAAS)

JAAS habilita servicios para autenticar y refuerzan el control de acceso de usuarios. Él implementa una versión del estándar Pluggable Authentication Module (PAM), y extiende el control de acceso de la plataforma Java 2 en una forma compatible para soportar autorización basada en usuario. Muchas de las APIs describen acerca de cómo proporcionar interoperabilidad con los componentes, ésa no es una parte de la plataforma J2EE, tal como un web externo o servicios CORBA. La figura 2-2 ilustra los medios de interoperabilidad de la plataforma J2EE. (Las direcciones de las flechas indican las relaciones client/server de los componentes.)


Requisitos del Producto

Esta especificación no requiere que un producto J2EE sea implementado por un solo programa, por un servidor, o por una máquina aislada. En general, esta especificación no describe la separación de los servicios o funciones entre las máquinas, servidores, procesos, etc. Un producto J2EE debe poder desplegar los componentes de aplicación que se ejecutan con la semántica descripta en esta especificación.

Un producto J2EE muy simple, se puede proporcionar como un máquina virtual Java, de tal manera que soporte applets, componentes del web, y Enterprise beans simultáneamente en un container, y que cada aplicación cliente tenga su propio container.

Es muy poco probable que un producto J2EE soporte applets en uno de los browsers populares, clientes de la aplicación con su propia máquina virtual Java, y proporcionará un servidor solo que apoya ambos componentes del web y Enterprise beans.

Un extremo alto J2EE producto raja los componentes del servidor en servidores múltiples, cada uno del que puede ser distribuido y carga-equilibrado por una colección de máquinas. La especificación no prescribe o evita cualquier de estas configuraciones.


Extensiones del Producto

Esta especificación describe un mínimo conjunto de medios que todo producto J2EE debe proporcionar. Muchos productos J2EE proporcionarán medios más allá del mínimo requerido por la especificación. Esta especificación incluye sólo unos pocos términos sobre las extensiones que debe proporcionar un producto. En particular incluye las mismas restricciones como J2SE sobre extensiones APIs sobre Java. Un producto J2EE no agregaría clases al lenguaje de programación Java, y no agregaría métodos o por otra parte altera las firmas del especificación de clases. Sin embargo, muchas otras extensiones son posibles.

Un producto J2EE proporcionaría:

  • APIs Java adicionales, u otro paquete opcional Java, u otro paquete llamado apropiadamente.
  • Incluiría soporte para protocolos adicionales protocolos o servicios no especificados aquí.
  • Soportaría aplicaciones escritas en otros lenguajes y soportaría conectividad a otras plataformas o aplicaciones.


Por supuesto, la portabilidad de las aplicaciones, no harán uso de cualquier extensión de la plataforma. Las aplicaciones que no hagan uso de las facilidades no requeridas por la especificación no serán portables. Dependiendo de la facilidad utilizada, la pérdida de portabilidad podría ser menor o quizás significante. El documento “Designing Applicatons with the Java 2 Platform, Enterprise Edition”, ayudará a los diseñadores a construir aplicaciones portátiles, y contendrá los consejos necesarios de cómo mejor manejar el uso de la codificación no-portátil cuando el uso de tales medios sea necesario.

En suma, se espera que los productos J2EE varíen ampliamente, y de hecho compite, en varios aspectos de calidad de servicio. Diferentes productos proporcionarán diferentes niveles de ejecución, escalabilidad, robustez, disponibilidad, seguridad, etc. En algunos casos la especificación describe el mínimo necesario a nivel de servicio. Futuras versiones de la especificación dejarían que a las aplicaciones describen sus requerimientos en estas áreas.


Roles de la Plataforma

Esta sección describe los roles de la plataforma J2EE. Aunque se consideran típicos estos roles, una organización podría ligeramente utilizar roles diferentes para nivelar el desarrollo de la aplicación real de esa organización y el desarrollo del flujo de trabajo. Algunos subconjuntos de los roles se definen en los documentos EJB, JSP, y Servlet en características técnicas estos roles.


J2EE Producto Provider

Un proveedor de productos J2EE, generalmente un vendedor de sistemas operativos, sistemas de base de datos, vendedor de servidores de aplicación, o de servicios de servidor de web, implementa un producto J2EE proporcionado los containers y APIs, del componente y otras características definidas en la especificación. Un proveedor de productos J2EE debe proporcionar las J2EE APIs a los componentes de la aplicación a través de los containers. Un proveedor de productos frecuentemente basa su aplicación en una infraestructura existente. . El proveedor del producto deberá proporcionar también un mapa de los componentes de la aplicación para los protocolos de red. Un producto J2EE es libre de llevar a cabo las interfaces que no son especificadas por éste especificación de forma de adaptarse a la aplicación.

El proveedor debe proporcionar las herramientas de manejo y ejecución de la aplicación y herramientas del manejo. La forma de estas herramientas no es prescrita en esta especificación. Componentes del proveedor de la Aplicación.

Hay múltiples roles para el proveedor, incluso diseñar documentos HTML, manuales del programador, diseñadores de Enterprise beans, etc. Estos roles usan herramientas para producir aplicaciones y componentes J2EE.

Ensamblador de la Aplicación

El Ensamblador de la Aplicación toma un juego de componentes desarrollado por el proveedor de los componentes de la aplicación y los congrega en un completa entrega de la aplicación J2EE en la forma que la empresa lo archiva, archivo (.EAR). El ensamblador generalmente usará herramientas GUI proporcionadas por proveedor de la plataforma o del la herramienta. El Ensamblador de la Aplicación es responsable de proporcionar instrucciones de ensamble que describan las dependencias externas de la aplicación tal que el lanzador de la aplicación deba resolver en el proceso de despliegue.

Deployer

El Deployer, un experto en un ambiente específico, es responsable por desplegar o lanzar las aplicaciones del web y los componentes Enterprise JavaBeans en ese ambiente. El Deployer usa herramientas suministradas por el proveedor para ejecutar el despliegue. El proceso del despliegue es generalmente un proceso de tres fases:

1. Instalación: movimientos de los medios de comunicación del servidor, generan el container adicional específico y las interfaces que habilitan a los containers manejar los componentes de la aplicación, e instala los componentes de la aplicación y las clases adicionales e interfaces en los containers J2EE. 2. Configuración: Resuelve las dependencias externas declaradas por el componente de la aplicación y continua él ensamblando de la aplicación. Por ejemplo, el Deployer es responsable de mapear los roles de la seguridad definidas por la ensamblador de la aplicación para el grupo de usuarios y cuentas que existen en el ambiente operacional en el que se despliegan los componentes de la aplicación. 3. Ejecución: poner en marcha la aplicación recientemente instalada y configurada. En algunos casos, un Deployer calificado personalizaría la lógica de los componentes de la aplicación en tiempo de despliegue por usar herramientas proporcionadas con el producto J2EE para escribir codificación relativamente simple que compromete los métodos de los Enterprise beans, o personalizar la apariencia de una página JSP, por ejemplo. El resultado del Deployer serán aplicaciones web, Enterprise beans, applets, y clientes de la aplicación que se han personalizado por el ambiente operacional y se despliegan en un container específico.


Administrador del Sistema

El administrador del sistema es responsable por la configuración y administración de la informática en la empresa y la infraestructura del gestión de las redes. El administrador del sistema también es responsable de vigilar el bienestar de las aplicaciones. El administrador del Sistema generalmente usa herramientas de supervisión y herramientas del manejo proporcionadas por el producto J2EE para lograr estas tareas.

Herramienta provistas

Las herramientas que el proveedor proporciona se usaron para el desarrollo y empaquetamiento de componentes de la aplicación. Se anticipa una variedad de herramientas, correspondientes a muchos tipos de componentes de la aplicación soportados por la plataforma J2EE. Herramientas independientes dela plataforma se pueden usar en las todas las fases del desarrollo. Herramientas dependientes de la plataforma son utilizadas por despliegue, manejo, y monitoreo de las aplicaciones.

Contratos de la Plataforma

Esta sección describe los contratos de la plataforma J2EE que se deben cumplir por el proveedor del producto.

J2EE API

El J2EE API define el contrato entre los componentes J2EE de la aplicación y la plataforma J2EE. El contrato especifica ambas interfaces, el runtime y despliegue. El proveedor debe implementar las J2EE APIs de cierta forma que soporte la semántica y las políticas descritas en la especificación. El componente de la aplicación que el proveedor proporcione debe ser conforme a estas APIs y políticas.

J2EE SPI

El J2EE SPI define el contrato entre la plataforma J2EE y los proveedores de servicio que se conectan a un producto J2EE. El conector de la APIs, define las interfaces del proveedor de servicio para integrar los adaptadores del recurso con un servidor de aplicación. Estos componentes del adaptador del recurso se llaman conectores. El proveedor del producto debe implementar el J2EE SPIs en cierta forma que soporte la semántica y las políticas descritas en la especificación. Un proveedor de servicio y proveedor de componentes (por ejemplo, un Conector Provider) debe proporcionar componentes que conformen a estos SPIs y políticas.

Protocolos de la Red

Esta especificación define el mapeo de los componentes de la aplicación a protocolos de red estándar. El mapeo permite que el cliente acceda a los componentes de la aplicación de sistemas que no han instalado productos específicos J2EE. Se requiere que el proveedor del producto J2EE publique los componentes de la aplicación instalados sobre los protocolos estándar. Esta especificación define el mapeo de servlets y JSP compaginan al protocolo HTTP y HTTPS, y el mapeo de EJB a IIOP.

Deployment Descriptors

Son utilizados para comunicar las necesidades de los componentes de la aplicación al Deployer. El Deployment Descriptor es un contrato entre el proveedor del componente de la aplicación o el ensamblador y el Deployer. El componente de la aplicación es requerido para especificar el ensamblador de la aplicación y requisitos de recursos externos, requisitos de seguridad, parámetros de ambiente, etc. El producto J2EE requiere que se requiere proporcione una herramienta de despliegue que interpreta el J2EE descriptors y deja que el Deployer mapear el componente de la aplicación, los requisitos y las capacidades de un producto J2EE específico J2EE.

Preguntas frecuentes

¿Se relaciona J2EE con la tecnología Enterprise JavaBeans? Enterprise JavaBeans es la base de J2EE. EJB provee la arquitectura escalable para ejecutar lógica de empresa en un ambiente de computación distribuido. Simplifica el trabajo del desarrollador para empresas combinando la arquitectura de componentes EJB con otras tecnologías para empresas para un desarrollo de calce perfecto y manejo efectivo de las aplicaciones serverside.

¿Será J2EE ubicable como programa de fuente comunitaria (community source)? Sí. Cuando Java 2 SDK. Enterprise Edition sea lanzado, podrá ser encontrado bajo el programa Sun's Community Source Licensing.

¿Qué son los esquemas J2EE? Los esquemas J2EE (J2EE Blueprints) son las mejores filosofías de prácticas para el diseño y construcción de aplicaciones basadas en J2EE. Estas guías de diseño proveen dos cosas. Primero, proveen la filosofía de construir aplicaciones en filas o hileras en la plataforma Java 2. Segundo, provee un conjunto de patrones de diseño para diseñar estas aplicaciones, también como un conjunto de recetas de cómo construir las aplicaciones.

¿Es XML soportado en J2EE? XML es esencialmente un componente en la plataforma J2EE. J2EE provee un marco de trabajo para el intercambio de datos business-to-business usando XML. Exactamente, el marco de trabajo JavaServer Pages puede ser usado para generar y consumir XML entre servidores o entre servidores y clientes. En adición. EJB usa XML para describir sus propiedades de manejo eficiente, dada la portabilidad de los datos en adición con la portabilidad de su código.

¿Hay test de compatibilidad? Sí. Una completa suite para testeo de compatibilidad será ubicable cuando la implementación de referencia se venda, Esta suite testeará entre tecnología JavaBeans, servlets y tecnología JavaServer Pages.

J2EE Server Core El J2EE Server Core es un ambiente application server que provee recursos y servicios de administración de transacciones. El J2EE server core incluye una implementación de la máquina virtual Java 2 estándar Edition y el Java Development Kit (J2SE), soporta las APIs de J2EE, y provee contenedores de componentes para Applets, Servlets, JavaServer Pages y componentes EJB.

J2EE Service APIs La plataforma J2EE define una serie de servicios estándares que deben ser soportados por esta plataforma, estos servicios incluyen HTTP, JTA, RMI/IIOP, Java IDL, JDBC, JNDI, JavaMail, y APIs JAF.

El modelo de aplicación J2EE divide las aplicaciones empresariales en tres partes fundamentales: componentes, contenedores y conectores. Las componentes son el foco donde se centran los desarrolladores de aplicaciones, los vendedores de sistemas implementan contenedores y conectores para ocultar la complejidad y promover la portabilidad. Los contenedores interceden entre los clientes y las componentes, proporcionando servicios transparentemente a ambos. Los conectores se ubican debajo de la plataforma de J2EE.Los conectores promueven flexibilidad permitiendo una variedad de implementaciones de servicios Componentes J2EE soporta una cantidad extensa de componentes. Las componentes son partes de las aplicaciones previamente desarrolladas, las cuales pueden ser ensambladas con otras aplicaciones. Las componentes no son aplicaciones por sí solas. Estas se ejecutan en otros ambientes de aplicaciones llamados Containers (Contenedores). Un contenedor provee un contexto de aplicación para una o más componentes, además provee administración y servicios de control para las componentes. En términos prácticos, un contenedor provee un proceso del sistema operativo o un thread en donde se ejecuta la componente.

Como ya se mencionó anteriormente, la arquitectura de J2EE soporta tres tipos de componentes:

1. Applets. Son una componente de interfaz de usuario móvil. Estos pueden ser transportados a través de Internet y ejecutarse en un Navegador o en otro contenedor de applet. Los Applets requieren un contenedor que soporte J2SE, el modelo de programación de Applets y JNDI. 2. Servlets y JavaServer Pages. Son componentes en el servidor que forman un puente entre múltiples clientes y el entorno final de la aplicación. Los Servlets y JSP, generalmente se ejecutan en un servidor Web, el cual maneja los pedidos de servicios de HTTP. Los Servlets y JSP procesan los pedidos y luego procesan los resultados los cuales pueden ser visualizados por el cliente (normalmente en HTML o XML).Servlets y JSP requieren un contenedor que soporte J2SE, Servlet, JSP, JNDI, JTA, JavaMail, JAF, RMI/IIOP y APIs de JDBC. 3. Enterprise JavaBeans. Son una componente en el servidor que implementa servicios finales de la aplicación. EJB se ejecuta en un application server. Un contenedor EJB debe soportar J2SE, EJB, JNDI, JTA, Java-Mail, JAF, RMI/IIOP y APIs de JDBC.


Base de Datos

Una aplicación J2EE debe incluir una base de datos para el almacenamiento persistente de los datos de la empresa. Las aplicaciones y sistemas acceden a la base de datos utilizando el API JDBC. Otros tipos de bases de datos persistentes son permitidos, siempre que soporten el modelo relacional.

Desarrollando aplicaciones J2EE

Los desarrolladores de aplicaciones J2EE escriben componente s de aplicación. Un componente de aplicación es un modulo que contendor al que se le pueden adicionar interfaces con otros components de aplicación. Estos componentes incluyen, aplicaciones cliente, applets, servlets, y Java ServerPagesTM; sobre server-side Enterprise JavaBeans. Los componentes de aplicación son almacenados en archivos del tipo Java Archive (JAR) o Web Archive (WAR), ensamblados sobre una completa aplicación J2EE, y entregada como Enterprise Archive (EAR). El modelo de aplicación de J2EE es muy flexible. Está misma aplicación, por ejemplo, puede ser ensamblada para ser utilizada en un applet o en una página HTML con código Java ServerPages.

Actualizaciones

Las características actualizadas incluyen el soporte de nuevas plataformas para el Entorno Operativo Solaris, Windows NT, Linux y Windows 2000. También se incorporan mejoras en Application Deploytool, un interfaz gráfico de usuario que facilita el desarrollo y la creación de prototipos. Con Application Deploytool, el diseño interactivo de aplicaciones facilita y acelera el desarrollo con la tecnología J2EE. La tecnología J2EE v 1.2.1 es totalmente compatible con las versiones anteriores del SDK de Java2, Enterprise Edition. Puede descargar gratuitamente los ejecutables de la tecnología J2EE v 1.2.1 en: [1]

Glosario de Términos

applet

Un componente que se ejecuta generalmente en un Web browser, pero puede ser ejecutado en una variedad de otras aplicaciones o dispositivos que soporten el modelo de programación del applet.

applet container

Un contenedor que incluye soporte para el applet programming model.

componente

Unidad de software aplicativo soportado por un contenedor. Se puede configurar a los componentes en el momento del despliegue. Los cuatros tipos de componentes definidos por la plataforma J2EE son: enterprise beans, componentes Web, applets y clientes de aplicación.

Contrato (contract)

El contrato entre un componente y su contenedor. Incluye: gestión del ciclo de vida del componente, una interfaz de contexto que usa la instancia para obtener información y servicios diversos de su contenedor y una lista de servicios que cada contenedor debe proveer para sus componentes,


Conector (connector)

Un mecanismo de extensión estándar para contenedores que proveen conectividad a sistemas de información corporativos (EIS). Un conector es específico de un EIS y consiste de un adaptador de recursos y herramientas de desarrollo de aplicaciones para la conectividad EIS. El adaptador de recursos es enchufado a un contenedor mediante su soporte para los contratos de nivel de sistema definidos en la arquitectura de conector.

Contenedor (container)

Una entidad que provee servicios de gestión de ciclo de vida, seguridad, despliegue, nombres y servicios de tiempo de ejecución a los componentes. Cada tipo de contenedor (EJB, Web, JSP, servlet, applet y cliente de aplicación) también provee servicios específicos para cada componente.

Corba

Corba es el acrónimo de Common Object Request Broker Arquitecture. Es una especificación, abierta y no dependiente de ninguna empresa, para una arquitectura e infraestructura orientada a que las aplicaciones informáticas puedan trabajar juntas a través de las redes de comunicaciones. Los programas basados en Corba pueden interactuar unos con otros, independientemente de la compañía que los haya creado, del ordenador y sistema operativo sobre el que corran, del tipo de red y del lenguaje de programación en que hayan sido escritos.

EAR file

Un archivo JAR que contiene una aplicación J2EE.

EJB JAR file

Un archivo JAR que contiene un módulo EJB.

Enterprise JavaBeansTM (EJBTM)

Enterprise JavaBeans es la arquitectura de componentes de la parte de servidor para la plataforma J2EE. EJB posibilita el desarrollo rápido y simplificado de aplicaciones Java distribuidas, transaccionales y seguras.

e-commerce

Referido a aplicaciones que permiten transacciones e interacciones entre la compañía y el consumidor sobre Internet. También llamadas aplicaciones Business-To-Consumer (B2C)

e-business

Referido a aplicaciones que permiten transacciones e interacciones entre la compañía y sus proveedores sobre Internet. También llamadas aplicaciones Business-To-Business (B2B).

e-enterprise

Referido a aplicaciones que permiten la gestión no sólo de clientes y proveedores a través de Internet, sino también todos los procesos internos de la compañía, incluyendo funciones de backoffice y transacciones con partners externos.

HTML

Hypertext Markup Language. Un lenguaje de marcas para los documentos con hipervínculos de Internet. HTML permite embeber imágenes, sonidos, corrientes de vídeo, campos de formulario, referencias a otros objetos con URLs y formateo de texto básico.

HTTP

Hypertext Transfer Protocol. El protocol de Internet usado para la comunicación entre clientes y servidores. Los mensajes HTTP consisten de solicitudes del client al servidor y respuestas del servidor al cliente.

Java Server Pages

La tecnología Java Server Pages (JSP) permite a los diseñadores y desarrolladores de sitios web crear rápidamente y mantener de manera sencilla las páginas web dinámicas, ricas en información sobre las que se basan los sistemas de negocio. Como parte de la familia Java, la tecnología JSP posibilita el desarrollo de aplicaciones basadas en web que son independientes de la plataforma usada. La tecnología JSP separa la interface de usuario de la generación de contenidos, permitiendo a los diseñadores cambiar el formato de la página sin alterar el contenido dinámico subyacente.

JDBC

La tecnología JDBC (Java DataBase Connectivity) es una interfaz de programación de aplicaciones (API) que permite acceder, desde el lenguaje de programación Java, a virtualmente cualquier fuente de datos tabulados. Proporciona conectividad cruzada DBMS a un amplio rango de bases de datos SQL, así como otras fuentes de datos tabulados, como hojas de cálculo o simples ficheros.

J2EE

JavaTM 2, Enterprise Edition.

J2SE

JavaTM 2, Standard Edition.

Aplicación J2EE

Cualquier unidad desplegable de funcionalidad J2EE. Puede ser un único módulo o un grupo de módulos empaquetado en un fichero .ear con un descriptor de despliegue de aplicación J2EE. Las aplicaciones J2EE se diseñan típicamente para ser distribuidas a través de múltiples capas de procesamiento.

JAR

JAR Java ARchive

Formato de fichero independiente de la plataforma que permite que muchos ficheros sean agregados en un solo archivo.


JMS

Java Message Service. Una API para usar sistemas de mensajería corporativa como IBM MQ Series, TIBCO Rendezvous, etc.

Componente JavaBeans Una clase de Java que se puede manipular en una herramienta de construcción visual y compuesta en varias aplicaciones. Un componente JavaBeans se debe adherir a ciertas convenciones de propiedades e interfaces de eventos.

JSP

JavaServer Pages. An

Una tecnología Web extensible que usa datos de plantillas, elementos personalizados, lenguajes de scripting y objetos Java del servidor para devolver contenido dinámico a un cliente.

Típicamente los datos de plantillas son elementos HTML o XML y en muchos casos el cliente es un navegador Web.


RMI

Remote Method Invocation. Una tecnología que permite que un objeto ejecutado en una máquina virtual de Java invoque métodos de un objeto ejecutado en otra máquina virtual de Java.

RMI-IIOP

Una versión de RMI que usa el protocolo CORBA IIOP. Provee interoperabilidad con objetos CORBA implementados en cualquier lenguaje si todas las interfaces remotas se definen originalmente como interfaces RMI.

Roles

La función que realiza una persona en las fases de desarrollo y despliegue de una aplicación desarrollada usando tecnología J2RR. Los roles son: proveedor de Componente de Aplicación, ensamblador de Aplicación, desplegador, proveedor de producto J2EE, proveedor de contenedor EJB, proveedor de servidor EJB, proveedor de contenedor Web, proveedor de servidor Web, proveedor de harramienta y administrador de sistema.


SSL

Secure Socket Layer. Un protocolo de seguridad que ofrece privacidad sobre la Internet. El protocolo permite que las aplicaciones cliente-servidor se comuniquen evitando la escucha o manipulación no autorizadas. Los servidores siempre son autentificados y los clientes lo son de manera opcional.

SQL

Structured Query Language. El lenguaje estandarizado de bases de datos relacionales para definir objetos de la base de datos y manipular datos.

Transacción

Una unidad de trabajo autónoma que modifica datos. Una transacción agrupa una o más sentencias de programa, todas las cuales se completan o deshacen (roll back) su efecto simultáneamente. Las transacciones permiten que múltiples usuarios accedan a los mismos datos en forma concurrente.

Fichero WAR

Un fichero JAR que contiene un módulo Web.

Componente Web (web component)

Un componente que provee servicios como respuesta a solicitudes; es o un servlet o una página JSP.

Contenedor Web (Web container)

Un contenedor que implementa el contrato de componente Web de la arquitectura J2EE. Dicho contrato especifica un entorno de tiempo de ejecución para componentes Web que incluye seguridad, concurrencia, gestión del ciclo de vida, transacción, despliegue, reglas de nombre y otros servicios. Un contenedor que provee los mismos servicios que un contenedor JSP y la vista federada de las APIs de la plataforma J2EE. Un contenedor Web es provisto por un servidor Web o un servidor J2EE.

XML

eXtensible Markup Language. Un lenguaje de marcas que permite definir los tags (markup) necesarios para definir los datos y los textos en un documento XML.

Referencias

Artículos relacionados


Otras fuentes de información

Notas