Java en castellano. Introdución al Servidor de Aplicaciones iPlanet java jsp

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.