Introdución al Servidor de Aplicaciones iPlanet

J2EE resuelve el problema del coste y la complejidad del desarrollo de servicios multi-capa que sean escalables, de alta disponibilidad, seguros y eficientes. Consigue esto proporcionando una arquitectura de est�ndard abierto a trav�s de la Plataforma J2EE y del modelo de Aplicaci�n J2EE. Esta plataforma permite a los desarrolladores enfocarse en la l�gica de negocio mientras que J2EE maneja los detalles de bajo nivel. Con J2EE, los servicios son f�cilmente mejorables y r�pidamente desarrollados, permitiendo a los negocios reaccionar r�pidamente ente los cambios competitivos.

J2EE es un entorno abierto para desarrollar y desplegar servicios multi-capca donde peque�as aplicaciones cliente invocan l�gica de negocio que se ejecuta en un servidor de aplicaciones como iPlanet Application Server. Comprende un conjunto de servicios, protocolos e interfaces de programaci�n. El lenguaje Java, la m�quina virtual Java y los componentes JavaBaens son la base de J2EE.

�Modelo Multi-Capa

En el gr�fico de arriba, el servlet recibe la solicitud, valida la entrada, llama al bean de sesi�n y llama a la JSP. La JSP fomatea el HTML y responde al cliente. El bean de sesi�n valida la solicitud, ejecuta el proceso y fuerza la transaci�n. Los beans de entidad manejan los datos.

En un modelo multi-capa, la primera capa es el cliente que normalmente es un navegador Web o una aplicaci�n Java solitaria. Este invoca a la l�gica del negocio de una o m�s capas medias que se est�n ejecutando sobre hardware dedicado, que a su vez acceden a los datos desde el Enterprise Information Service en la tercera capa.

Desarrollar un servicio multi-capa requiere aplicaciones cliente, l�gicas de negocio y de presentaci�n (las aplicaciones que obtienen, actualizan y presentan los datos) y c�digo de infraestrcutura. La infraestructura son componentes de bajo nivel del sistema que accede a varias bases de datos, recursos del sistema y proporcionan seguridad. Los detalles de la infraestructura son manejados por J2EE en iAS para que el desarrollador s�lo necesite desarrollar las l�gicas de negocio y presentaci�n.

En la capa media, la l�gica de negocio se implementa como componentes Enterprise Java Beans (EJB), mientras que la l�gica de presentaci�n se implementa como Java Server Pages (JSP) y Servlets. Los Servlets y las JSPs permiten la separaci�n del procesamiento de la solicitud de su l�gica de presentaci�n. La capa de presentaci�n del modelo permite f�cilmente acceder a las funciones de negocio de la capa media. La tecnolog�a JSP permite a los desarrolladores presentar p�ginas web creadas din�micanente. Los servlets permiten a los desarrolladores crear presentaciones din�micas para los usuarios completamente en lenguaje Java.

�Beneficios de J2EE

• J2EE proporciona soluciones Java entre todas las capas.
• Separaci�n de tareas en la plataforma multi-capa, separando la l�gica de negocio de los servicios del sistema y del interface de usuario, situando la l�gica de negocio en la capa media entre los dos.
• Conjunto de est�ndards abiertos� EJB, JSP, Servlets, JDBC, JNDI, RMI componen la plataforma J2EE.
• Portabilidad� El caracter�stica Java "Write Once, Run Anywhere"(WORA) [Escribe una vez, ejecuta en cualquier parte] est� en todas estas tecnolog�as. Esto significa que cualquier proveedor de terceras partes pueden escribir componentes especialmente dise�ados para iAS, reduciendo el coste del desarrollo.
• Escalabilidad� La escalabilidad es responsabilidad de iAS - la aplicaci�n no necesita c�digo para esto. El sistema de aplicaci�n Enterprise soporta alta escalabilidad usando una arquitectura de aplicaci�n distribuida multi-capa con componentes integrados.
• Componentes� La l�gica de presentaci�n, la l�gica de negocio, y la l�gia de acceso a datos est�n separadas en diferentes componentes y desplegada en varios servidores. Esto permite a una aplicaci�n aprovecharse del alto rendimiento de los sistemas multi-proceso y multi-capa.
• Las experiencias con el lenguaje y con los APIs peuden ayudarnos a tratar con otras �reas. Por ejemplo, la experiencia en escribir applets Java es similar a escribir un servlet. La experiencia de escribir un servlet es similar a escribir un EJB.
• El sellado de cajas, la recolecci�n de basura y el manejo autom�tico de excepciones reduce el problema de que un componente bloquee la operaci�n del servidor o de otro componente. Por ejemplo, los servlets nos permiten conectar c�digo de cliente en un servidor web como podr�a hacerlo un plug-in o una librer�a de extensi�n. Sin embargo, la diferencia est� en que los servlets tienen recolecci�n de basura y habilidades de manejo de excepciones, por eso un problema en un servlet no afecta a la operaci�n del servidor. Los EJBs funcionan de la misma manera y pueden desplegarse en una base de datos o en un servidor de aplicaciones.

�Componentes J2EE

El control de transaciones, el control del ciclo de vida, y los almacenes de recursos est�n construidos internamente en la plataforma J2EE y son proporcionados autom�ticamente a los componentes que soporta. Los desarrolladores de componentes y aplicaciones son libres de enfocarse sobre especifidades como la l�gica de negocio o los interfaces de usuario. El modelo de aplicaci�n J2EE encapsula las capas de funcionalidad en componentes de tipos espec�ficos. La l�gica de negocio est� encapsulada en componentes Enterprise JavaBeans (EJB). La interacci�n con los clientes pueden representerse a trav�s de:

• P�ginas web de HTML plano.
• Paginas web con Applets Java.
• El API Java Servlets.
• Tecnolog�a JavaServer Pages.
• Aplicaciones Java solitarias.

Los compoentes se comunican de forma transaparente usando varios est�ndards, incluyendo HTML, XML, HTTP, SSL, RMI, IIOP, y otros:

J2EE esta compuesto de diferentes componentes:

• Servlets� un reemplazo eficiente, independiente de la plataforma para los scripts CGI que responden a solicitudes de clientes.
• JavaServer Pages (JSP)� un tipo de script del lado del sevidor, que puede generar p�ginas web din�micamente.
• Enterprise JavaBeans (EJB)� control de sesi�n del lado del servidor, que encapsula la l�gica de negocios y abstracci�n para acceder a datos persistentes.
• Java Database Connectivity (JDBC)� un API que describe una librer�a est�ndard Java para acceder a fuentes de datos.
• Transaction Support� transaciones declarativas para componentes donde las transaciones pueden expandir componentes y procesos.
• Java Naming and Directory Interface (JNDI)� un interface abstracto para servicos de b�squeda de uniones de nombres y directorios.
• Remote Method Invocation (RM/IIOP)� una tecnolog�a que permite la comunicaci�n entre objetos distribuidos.
• CORBA Compatible� CORBA complementa Java proporcionando un marco de trabajo de objetos distribuidos, servicios para soportar ese marco de trabajo e interoperabilidad con otros lenguajes.

�Servlets

En J2EE, los servlets manejan la l�gica de presentaci�n de una aplicaci�n actuando como un despachador central para aplicaciones, procesando la entrada, llamando a componentes de la l�gica de negocio, accediendo a Enterprise JavaBeans, y formateando la p�gina de salida usando JSPs. Los servlets controlan el flujo de la aplicaci�n desde una interacci�n del usuario hasta la siguiente generando el contenido en respuesta a las solicitudes de un usuario.

Los Servlets se usan para manejar solicitudes y respuestas desde navegadores clientes. Los servlets con como los applets excepto en que se ejecutan en el servidor en vez de en el cliente.

�Java Server Pages

Las JavaServer Pages (JSPs) son el mecanismo de distribuci�n de la presentaci�n. Son p�ginas de navegador en HTML o XML. Opcionalmente pueden contener c�digo Java, lo que les permite realizar procesos complejos, salidas condicionales, y comunicarse con otros objetos de nuestra aplicaci�n. Las JSPs en iPlanet Application Server 6.0 est�n basadas en la especificaci�n JSP 1.1.

En las aplicaciones de iPlanet Application Server, usamos JSPs como p�ginas individuales que componen nuestra aplicaci�n. Podemos llamar a una JSP desde un servlet para manejar la salida de una interacci�n de usuario, o, como las JSPs tiene el mismo acceso al entorno de aplicaci�n que otros componentes de la aplicaci�n, podemos usar una JSP como un destino de una interacci�n.

Las JSPs se compilan en servlets, cuando son instaladas o cuando son llamadas por primera vez. Esto pone las JSPs a disposici�n del entorno de aplicaci�n como objetos est�ndards y les pemite ser llamadas desde un cliente usando una URL.

Podemos pensar en los Servlets y las JSPs como las caras opuestas de la misma moneda: cada una puede realizar las tareas del otro. Sin embargo, como las JSPs est�n escritas en ficheros HTML, con c�digo Java embebido, son la mejor elecci�n para las tareas de dibujo y presentaci�n. Los servlets son la mejor elecci�n como despachadores centrales para solicitudes de JavaServer Pages (JSPs) entrantes.

�Enterprise JavaBeans

Los Enterprise JavaBeans (EJBs) son aplicaciones. Si los servlets act�an como despachadores centrales para nuestra aplicaci�n y manejan la l�gica de presentaci�n. Los EJBs hacen el trabajo duro real con los datos de la aplicaci�n y regula el proceso pero sin proporcionar presentaci�n visible para el usuario. Los EJBs nos pemiten dividir la l�gica de negocio, la reglas, y los objetos en unidades discretas, modulaes y escalables. Cada EJB encapsula una o m�s tareas de la aplicaci�n o objetos de aplicaci�n, incluyendo estructuras de datos y m�todos que operan sobre ellas. T�picamente, los EJBs tambi�n toman par�metros y env�an valores de retorno. Los EJBs siempre funcionan dentro del contexto de un "contenedor", que sirve como un enlace entre los EJBs y los servidores que los hospedan. Como desarrollador de iPlanet Application Server, no necesitamos preocuparnos del contenedor de nuestros EJBs. El entorno software iPlanet Application Server proporciona el contenedor. Este contenedor proporciona todos los servicios est�ndards denotados en la especificaci�n EJB 1.1. Tambi�n proporciona servicios adicionales como control de fallos de beans de sesi�n con estado. De hecho, el contenedor puede manejar todos los accesos remotos, la seguridad, la concurrencia, el control de transaciones, y el acceso a bases de datos. Como los detalles de la implementaci�n real son parte del contenedor, y hay un est�ndard, preescibiendo un interface entre un contenedor y sus EJBs, el desarrollador de beans est� liberado de tener que conocer o manejar los detalles de implementaci�n espec�ficos de la plataforma. En su lugar, el desarrollador de beans enterprise puede crear EJBs gen�ricos, enfocados al a tarea para usarlos con cualquier producto de otros vendedores que soporten el est�ndard EJB.

�Beans de Sesi�n y de Entidad

Hay dos clases de EJBs: de entidad y de sesi�n. Cada uno de estos tipos de bean se usan de forma diferente en un servidor de aplicaciones. Un EJB puede ser un objeto que representa un servicio sin estado, u un objeto que representa una sesi�n con un cliente particular (y que mantiene autom�ticamente el estado entre m�ltiples llamadas a m�todos del cliente), o puede ser un objeto de entidad persistente posiblemente compartido entre varios clientes. Un bean de sesi�n implementa l�gica de negocio. Toda la funcionalidad de acceso remoto, seguridad, concurrencia, y transaciones la proporciona el contendor de EJBs. Un EJB de sesi�n es una fuente privada usada s�lo por el cliente que la crea.

�Beans de Entidad

Los beans de entidad normalmente representan datos persistentes. Estos datos est�n mantenidos directamente en una base de datos, o son accedidos a trav�s de aplicaciones finales como objetos. Un ejemplo simple de un bean de entidad ser�a uno que est� definido para representar una fila en una tabla de base de datos, y donde cada ejemplar del Bean representa una fila espec�fica. Un ejemplo m�s complejo ser�a un Bean de Entidad dise�ado para representar vistas complicadas de tablas unidas en una base de datos dode cada ejemplar del Bean representar�a los contenidos de una carta de compra de un cliente.

Al contrario que los Beans de sesi�n, los ejemplares de beans de entidad pueden ser accedidos simult�neamente por varios clientes. El contenedor es el responsable de sincronizar el estado del ejemplar usando transaciones. Esta delegaci�n de responsabiliades en el contenedor, significa que el desarrollador del bean no tiene que preocuparse sobre los accesos concurrentes a m�todos desde m�ltiples transaciones.

La persistencia de un Bean de entidad puede ser manejada por el propio bean, o por el contenedor del Bean, Cuando un Bean de Entidad maneja su propia persistenia, se llama persistencia manejada por el Bean. Cuando un bean delega esta funci�n al contendor, se llama persistencia manejada por el contenedor (CMP).

Persistencia Manejada por el Bean. El desarrollador del bean debe implementar directametne c�digo de persistencia (como llamadas JDBC) en los m�todos de la clase EJB, si el bean va a manejar sus propia persistencia. La posible inconveniencia de esta implementaci�n es la p�rdida de portabilidad, si se usa un interface propietario, y tambi�n puede existir el riesgo de atar el bean a una base de datos espec�fica.

Persistencia Manejada por el Contenedor (CMP). El proveedor de contenedor usa iPlanet Application Server Deployment Tool (iASDT) para generar el c�digo del bean para implementar el proceso de persistencia de contenedor. El contenedor controla, de forma transparente para el bean, el estado de persistencia. El desarrollador del bean no necesita implementar ning�n c�digo de acceso a datos en los m�todos del bean. Este m�todo no s�lo simplifica el desarrollo de la implementaci�n del bean, sino que lo hace totalmente portable, sin ataduras con ninguna base de datos.

Finalmente, se puede instalar cualquier n�mero de beans de entidad en un contenedor. El contenedor implementa un interface home por cada bean de entidad. Este interface permite a un cliente crear, buscar, y eliminar objetos entity. Un cliente puede buscar el interface home de un bean de entidad a trav�s de Java Naming and Directory Interface (JNDI).

�Modelo de Programaci�n de J2EE

iPlanet Application Server 6.0 cumple la especificaci�n de Java 2 Platform, Enterprise Edition versi�n 1.2 (J2EE 1.2) y est� basado en los est�ndards desarrollados por la comunidad Java, incluyendo servlets, JavaServer Pages, y Enterprise JavaBeans. El modelo de programaci�n de iPlanet Application Server 6.0 es s�lo para aplicaciones Java. Las aplicaciones C++ contin�an usando el modelo NAS 2.1.

iPlanet Application Server 6.0 es compatible hacia atr�s con aplicaciones NAS 2.1. Las aplicaciones NAS 2.1 se pueden ejecutar en iPlanet Application Server 6.0 sin ninguna modificaci�n del c�digo. Las aplicaciones NAS 4.0 son compatibles con la conversi�n al est�ndard J2EE y necesitan alguna conversi�n.

Al flujo de la aplicaci�n es similar entre el modelo iPlanet Application Server 6.0 y los modelos de las versiones anteriores 4.0 y 2.1. Toda interacci�n del usuario es manejada por uno (o m�s) componentes de aplicaci�n que procesan las entradas, realizan las funciones de la l�gica de negocios, interact�an con una base de datos, y proporcionan una p�gina de salida que responde a las entradas y configura la siguiente interacci�n con el usuario. El nuevo modelo de programaci�n describe tres capas de l�gica de aplicaci�n, cada una de las cuales est� representada por un conjunto de componentes o APIs.

Capa de Programaci�n	Componente NAS 2.1	Componente NAS 4.0	Componente iAS 6.0	Descripci�n
L�gica de Presentaci�n.	AppLogic	Java servlet y est�ndards propietarios	Java servlet	Controla el interface de la aplicaci�n con el usuario procesando solicitudes, generando contenido de respuesta, formateando y entregando el contenido de vuelta al cliente. En 6.0, los servlets procesan las solicitudes entrantes y orquestran la respuesta. La l�gica de negocios es normalmente sacada fuera a EJBs, y la salida normalmente es delegada a JSPs.
Distribuci�n de presentaci�n (parte de la L�gica de Presentaci�n).	Plantilla HTML	JavaServer Page (JSP) y est�ndards propietarios	JavaServer Page (JSP)	Controla la apariencia de cada p�gina. Parte de la l�gica de presentaci�n, normalmente manejada por JavaServer Pages. Las JSPs son p�ginas HTML que contienen c�digo Java embebido, y a s� son mucho m�s vers�tiles y poderosas que las plantillas HTML de 2.1.
L�gica de Negocio	AppLogic	Enterprise JavaBeans (EJBs) y est�ndards propietarios.	Enterprise JavaBeans (EJBs)	Controla la l�gica del negocio. Los EJBs permiten que la l�gica de negocio sea persistente entre llamadas, normalmente mejorando el cach�, y est�n dise�ados para trabajar en conjunto con JDBC para transaciones con bases de datos.
L�gica de Acceso a Datos	DAE	JDBC y est�ndards propietarios	JDBC	Controla el almacenamiento y recuperaci�n de bases de datos. El API JDBC est� disponible para todos los componentes Java, como todos los dem�s APIs, aunque las transaciones de bases de datos normalmente son controladas por EJBs en el modelo 6.0.

�L�gica de Presentaci�n y Distribuci�n

La l�gica de presentaci�n describe el flujo de una aplicaci�n desde la perspectiva de cada interacci�n de usuario: procesa la solicitud, seguido por la generaci�n y entrega del contenido. El objetivo de la l�gica de presentaci�n es crear una respuest� l�gica a una solicitud, y pedir otra solicitud. El objetivo de la distribuci�n de presentaci�n es mostrar el contenido de esta respuesta en un formato predeterminado. Las funciones de una aplicaci�n como las sesiones de usuario, la seguridad y autentificaci�n de usuarios, la validaci�n de entrada tambi�n son manejadas por la l�gica de presentaci�n.

En breve, la l�gica de presentaci�n implica cualquier cosa relacionada con el interface de la aplicaci�n con el usuario.

En el modelo de programaci�n NAS 2.1, la l�gica de presentaci�n estaba controlada por un AppLogic, mientras que la distribuci�n era manejada por una plantilla HTML. En tiempo de ejecuci�n, el AppLogic proporcionaba la salida para rellenar la plantilla.

En el modelo de programaci�n de iAS 6.0, la l�gica de presentaci�n normalmente est� manejada por un servlet. La distribuci�n es manjeada por una JSP. Durante la ejecuci�n, el servlet usa una JSP para formatear el contenido generado por la l�gica de negocio.

Aqu� tenemos las dos principales alternativas a este modelo b�sico:

• Manejar toda la l�gica de presentaci�n y de distribuci�n para una interacci�n dada en una JSP. Esto puede ser una forma f�cil de controlar una interacci�n que no tiene l�gica de negocio y poco porceso desde la interacci�n anterior. Por ejemplo, la p�gina inicial de una aplicaci�n normalmente no requiere procesar nada.
• Manajear todoa la l�gica de presentaci�n y de distribuci�n en un servlet. Esto puede ser muy eficiente para interacciones que tienen muy poca distribuci�n. Por ejemplo, un simple informe de base de datos podr�a listar solo las filas recuperadas desde una consulta a la base de datos. No tiene sentido sobrecargar una llamada a una JSP cuando la p�gina se podr�a mostrar simplemente desde el servlet.

�L�gica de Negocios

La l�gica de negocio describe las actividades que implican las generaci�n de contenido espec�fico: almacenamiento y recuperaci�n de datos, y realizar c�lculos con los datos. El objetivo de la l�gica de negocios es realizar las actividades que generan o determinan las respuestas a preguntas poseidas por la l�gica de presentaci�n.

En breve, la l�gica de negocio implica el contenido proporcionado a y generado por la aplicaci�n.

En el modelo de programaci�n NAS 2.1, la l�gica de negocio estaba controlada por el mismo AppLogic que manejaba la l�gica de presentaci�n para una interacci�n de usuario dada.

En el modelo de programaci�n iAS 6.0, la l�gica de negocio normalmente es manejada por uno o m�s Enterprise JavaBeans (EJBs), que controlan las transaciones con bases de datos y encapsulan los resultados. Los EJBs son componentes poderosos, reutilizables que potencian las aplicaciones con una gran flexibilidad, ya que los EJB pueden ser llamados o inspeccioandos desde cualquier otro objeto y pueden hacerse persistentes.

Una alternativa a este modelo es manejar la l�gica de negocios en la l�gica de presentaci�n (servlets y/o JSPs), de la misma forma en que lo hac�a AppLogics. Esto puede ser eficiente para peque�os eventos dirgidos a negocio como una petici�n de directorio espec�fica, pero esta aproximaci�n pierde la flexibilidad y el poder que traen los EJBs al modelo de programaci�n.

�Logica de Acceso a Datos

La l�gica de acceso a datos describe las transaciones con una base de datos o un servidor de directorio. El objeto de la l�gica de acceso a datos es proporcionar un interface entre una aplicaci�n y un conjunto de datos que le conciernen. El acceso a datos normalmente lo realiza la l�gica de negocios.

En breve, la l�gica de acceso a datos implica el almacenamiento o recuperacion del contenido recolectado o generado por la l�gica de negocio.

En el modelo de programaci�n NAS 2.1, la l�gica de acceso a datos estaba controlada por llamadas desde AppLogic usando APIs de varias clases e interfaces, incluyendo las clases DataSet, DBDataSet, y DBStoredProcedure y los interfaces ICallableStmt, IColumn, IDataConn, IDataConnSet, IHierQuery, IHierResultSet, IListDataSet, IPreparedQuery, IQuery, IResultSet, ITable, ITrans, y IValList.

En el modelo de programaci�n iAS 6.0, la l�gica de acceso a datos est� manejada por el conjunto de APIs est�ndards de JDBC. Los APIs anteriores se han quedado obsoletos en iAS 6.0.

�Clientes Ricos

Un Cliente Rico es un programa independiente Java que puede acceder directamente a los EJBs desplegados en iPlanet Application Server. Tradicionalmente, los clientes comunicaban con iPlanet Application Server a trav�s del camino web, es decir, hablando en HTTP a los componentes del servidor como JSPs y servlets que a su vez ten�an acceso a los EJBs dentro del contexto del servidor. La especificaci�n J2EE v1.2 tambi�n requiere que estos clientes independientes puedan hablar con iPlanet Application Server usando el est�ndard RMI-IIOP El cap�tulo 9 de la especificaci�n J2EE v1.2 tambi�n requiere que estos clientes independientes operen dentro del contexto de un Application Client Container (ACC) que aisle los envios espec�ficos del servidor, dejando que los clientes sean totalmente portables. A trav�s de esta infraestructura de clientes ricos, iPlanet Application Server permite a los clientes Java acceder directametne a EJBs dentro de iPlanet Application Server. Estos clientes podr�an operan dento de un ACC que se env�a con iPlanet Application Server seg�n requiere la especificaci�n J2EE ACC o m�s correctamente redirigir los accesos (caminos no ACC) de la forma en que los programadores Java la usan.

El diagrama de abajo es una representaci�n esquem�tica de la arquitectura iPlanet Application Server e ilustra las diferencias entre el cliente rico y los caminos web. Mientras que los clientes navegadores comunican con iPlanet Application Server usando HTTP a trav�s de un Servidor Web, los clientes ricos evitan este servidor Web y acceden directametne a clientes EJBs como RMI-IIOP. El control de fallos soportado tambi�n es proporcionado para beans de entidad en caso de un crash de Corba Executive Service (CXS).

El cliente rico es un programa de primera capa que ejecuta su propia M�quina Virtual Java (JVM), posiblemenete en una ACC. Desplegar el cliente rico requiere la especificaci�n de descriptores de despliegue usando XML.

�Persistencia Manejada por el Contenedor

Si queremos que el contenedor EJB maneje el almacenamiento de las variables del bean de entidad a un controlador de recursos subyacente, entonces se usa iPlanet Application Server Deployment Tool para configurar el contenedor EJB con selecciones de persistencia manejada por el contenedor (CMP).

iPlanet Application Server implementa CMP con:

• Soporte del modelo CMP de la especificaci�n J2EE v 1.2.
• Soporte de m�ltiples almacenes conectables y persistencia controlada por un per b�sico del bean.
• Proporciona al usuario una herramienta de despliegue (iASDT) para realizar mapeos de objetos relacionales (O/R) y crear el descriptror de despliegue separado en fichero XML.
• Soporte para Opciones de negociaci�n B y C.
• Soporte para m�todos buscadores personalizados sofisticados.
• Controladores de persistencia enchufables.

Los Controladores de persistencia enchufables permiten al usuario seleccionar las pol�ticas de persistencia durante el despliegue de un bean. Este marco de trabajo flexible permite a un cliente usar un controlador de persistencia de terceras partes en tiempo de despliegue. Las clases Factory para controladores de persistencia pueden seleccionarse en el fichero XML del descriptor de despliegue del bean. Las clases especificadas en estos campos ser�n usadas por el contenedor para creear cero o un controlador de persistencia para un bean.

iPlanet Application Server tambi�n soporta el mapeo de capa media Object to Relational (OR). CocoBase, de Thought, Inc., proporciona un respositorio din�mico basado en la herramietna de mapeo Object to Relational que entrega CMP y persistencia controlada por el Bean.

�RMI-IIOP

RMI sobre IIOP combina las mejores caracter�sticas de RMI con las mejores de CORBA. Al igual que RMI, RMI sobre IIOP acelera el desarrollo de aplicaciones distribuidas permitiendo a los desarrolladores trabajar completamente en lenguaje Java. Cuando se usa RMI sobre IIOP para producir aplicaciones distribuidas basadas en tecnolog�a Java, no hay que aprender un Interface Definition Language (IDL) o un inteface separado. Al igual que RMI, RMI sobre IIOP proporciona flexibilidad permitiendo a los desarrolladores que pasen cualquier objeto Java serializable (objeto por valor) entre componentes de la aplicaci�n. Al igual que CORBA, RMI sobre IIOP est� basado en est�ndards abiertos definidos con la participaci�n de cientos de vendedores y usuarios del Object Management Group. Al igual que CORBA, RMI sobre IIOP usa IIOP como su protocolo de comunicaci�n. IIOP facilita las aplicaciones legales y la integraci�n de plataformas permintiendo que los componentes de la aplicaci�n escritos en C++, Smalltalk, y otros lenguajes soporados por CORBA se comuniquen con componentes que se ejecutan en la plataforma Java.

�Usar JDBC para Acceder a Bases de Datos

En iAS, los Enterprise JavaBeans (EJBs) soportan accesos a bases de datos principalmente a trav�s del API JDBC. iPlanet Application Server soporta todo el API JDBC 2.0 incluyendo las hojas de resultados mejoradas, actualizaciones por bloques, transaciones distribuidas, conjuntos de filas, y soporte JNDI para bloques de nombres de bases de datos.

Como esta secci�n asume que est�mos familizarizados con JDBC 2.0, tambi�n describe los problemas de implementaci�n espec�ficos que podr�an tener las ramificaciones de programaci�n. Por ejemplo la especificaci�n, no deja claro qu� constituye los recursos JDBC. En la especificaci�n, algunas sentencias JDBC�como los m�todos de la clase Connection que cierran las conexiones con la base de datos�liberan recursos sin especificar exactamente qu� recursos son.

�Introducci�n a JDBC

JDBC es un conjunto de clases y m�todos Java qe nos permiten embeber llamadas a bases de datos en nuestras aplicaciones de servidor. Esto es todo lo que necesitamos saber para empezar a usar JDBC en nuestras aplicaciones de servidor.

M�s espec�ficamente, JDBC es un conjunto de interfaces que todo vendedor de servidores, como iPlanet, debe implementar de acuerdo a las especificaciones JDBC. iPlanet Application Server porporciona un driver JDBC del tipo 2 que soporta una gran variedad de bases de datos finales. Este driver procesa las sentencias JDBC de nuestras aplicaciones y enruta los argumentos SQL que contienen hacia nuestros motores de bases de datos.