Capas Lógicas de Aplicación
El servidor WebLogic implementa tecnologías de componentes y servicios J2EE. Las tecnologías de componentes J2EE incluyen servlets,
páginas JSP, y JavaBeans Enterprise. Los servicios J2EE incluyen el acceso a protocolos de red, a sistemas de base de datos, y a
sistemas estándares de mensajería. Para construir una aplicación de servidor WebLogic, debemos crear y ensamblar componentes,
usando los APIs de sevicio cuando sean necesarios. Los componentes se ejecutan en contenedor Web del servidor WebLogic o el
contenedor de EJB. Los contenedores proporcionan soporte para ciclo vital y los servicios definidos por las especificaciones J2EE de
modo que los componentes que construyamos no tengan que manejar los detalles subyacentes.
Los componentes Web proporcionan la lógica de presentación para las aplicaciones J2EE basadas en navegador. Los componentes
EJB encapsulan objetos y procesos del negocio. Las aplicaciones Web y los EJBs se construyen sobre servicios de aplicación de J2EE,
como JDBC, JMS (servicio de mensajería de Java), y JTA (API de Transaciones de Java).
La Figura 1-2 ilustra los contenedores de componentes y los servicios de aplicación de WebLogic Server.
La siguientes secciones explican la capa de presetnación, la lógica del negocio y los servicios de aplicación.
Capa Lógica de Presentación
La capa de presentación incluye una lógica de interface de usuario y de visualización de aplicaciones. La mayoría de las aplicaciones
J2EE utilizan un navegador web en la máquina del cliente porque es mucho más fácil que programas de cliente que se despliegan en
cada ordenador de usuario. En este caso, la lógica de la presentación es el contenedor Web del servidor WebLogic. Sin embargo, los
programas del cliente escritos en cualquier lenguaje de programación, sin embargo, deben contener la lógica para representar el HTML
o su propia lógica de la presentación.
Clientes de Navegador Web
Las aplicaciones basadas en Web construidas con tecnologías web estándar son fáciles de acceder, de mantener, y de portar. Los clientes
del navegador web son estándares para las aplicaciones de comercio electrónico. En aplicaciones basadas en Web, el interface de usuario
esrá representado por los documentos HTML, las páginas JavaServer (JSP), y los servlets. El navegador web contiene la lógica para
representar la página Web en el ordenador del usuario desde la descripción HTML.
Las JavaServer Pages (JSP) y los servlets están muy relacionados. Ambos producen el contenido dinámico de la Web ejecutando el código
Java en el servidor WebLogic cada vez que se les invoca. La diferencia entre ellos es que JSP está escrito con una versión extendida de
HTML, y los servlets se escriben con el lenguaje de programación Java.
JSP es conveniente para los diseñadores Web que conocen HTML y están acostumbrados al trabajo con un editor o diseñador de HTML.
Los Servlets, escritos enteramente en Java, están más pensados para los programadores Java que para los diseñadores Web.
Escribir un servlet requiere un cierto conocimiento del protocolo HTTP y de la programación de Java. Un servlet recibe la petición HTTP
en un objeto request y escribe el HTML (generalmente) en un objeto result.
Las páginas JSP se convierten en servlets antes de que se ejecuten en el servidor WebLogic, por eso en última instancia las páginas JSP
y los servlets son distintas representaciones de la misma cosa. Las páginas JSP se despliegan en el servidor WebLogic la misma forma que
se despliega una página HTML. El fichero .jsp se copia en un directorio servido por WebLogic Server.
Cuando un cliente solicita un fichero jsp, el servidor WebLogic controla si se ha compilado la página o si ha cambiado desde la última vez que
fie compilada. Si es necesario llama el compilador WebLogic JSP, que genera el código del servlet Java del fichero jsp, y entonces compila
el código Java a un fichero de clase Java.
Clientes No-Navegadores
Un programa cliente que no es un navegador web debe suminstrar su propio código para represetnar el interface de usuario. Los clientes
que no son navegadores generalmente contienen su propia presentación y lógica de la representación, dependiendo del servidor WebLogic
solamente para la lógica y el acceso al negocio o a los servicios backend. Esto los hace más difícil de desarrollar y de
desplegar y menos convenientes para las aplicaciones basadas en Internet de comercio electrónico que los clientes basados en navegador.
Los programas cliente escritos en Java pueden utilizar cualquier servicio del servidor WebLogic sobre Java RMI (Remote Method Invocatio).
RMI permite que un programa cliente opere sobre un objeto del servidor WebLogic la misma forma que operaría sobre un objeto local en el
cliente. Como RMI oculta los detalles de las llamadas a tavés de la red, el código del cliente J2EE y el código del lado del servidor son
muy similares.
Los programas Java pueden utilizar las clases Swing de Java para crear interfaces de usuario poderosas y portables. Aunque usando Java
podemos evitar problemas de portabilidad, no podemos utilizar los servicios del servidor WebLogic sobre RMI a menos que las clases del
servidor WebLogic estén instaladas en el cliente. Esto significa que lo clientes RMI de Java no son adecuados para el comercio electrónico.
Sin embargo, pueden usarse con eficacia en aplicaciones de empresariales en las cuales una red interna hace vieables la instalación y el
mantenimiento. Los programas cliente escritos en lenguajes distintos a Java y los programas clientes Java que no utilizan objetos del
servidor WebLogic sobre RMI pueden tener acceso al servidor WebLogic usando HTTP o RMI-IIOP.
HTTP es el protocolo estándar para la Web. Permite que un cliente haga diversos tipos de peticiones a un servidor y pase parámetros al
servidor. Un servlet en el servidor WebLogic puede examinar las peticiones del cliente, extraer los parámetros de la petición, y preparar
una respuesta para el cliente, usando cualquier servicio del servidor WebLogic. Por ejemplo, un servlet puede responder a un programa
cliente con un documento de negocio en XML. Así una aplicación puede utilizar servlets como gateways a otros
servicios del servidor WebLogic.
WebLogic RMI-IIOP permite que los programas compatibles con CORBA ejecuten Beans Enterprise del servidor WebLogic y clases RMI
como objetos CORBA. El servidor RMI de WebLogic y los compiladores de EJB pueden generar IDL (Interface Definition Language) para
las clases RMI y los Beans Enterprise. El IDL generado de esta manera se compila para crear los esqueletos para un ORB (Object
Request Broker) y los trozos para el programa cliente. El servidor WebLogic analiza peticiones entrantes IIOP y las envía al sistema de
ejecución RMI.
Capa de Lógica de Negocio
Los JavaBeans Enterprise son componentes d ela lógica de negocio para aplicaciones J2EE. El contenedor EJB de WebLogic Server
almacenca beans enterprise, proporcionan el control del ciclo de vida y servicios como el caheo, la persistenca, y el control de
transaciones. Aquí tenemos tres tipos de beans enterprise: beans de entidad, beans de sesión y beans dirigidos por mensajes. Las
siguientes secciones describen cada tipo en más detalle.
Beans de Entidad
Un bean de entidad representa un objeto que contiene datos, como un cliente, una cuenta, o un item de inventario. Los beans de entidad
contienen los valores de datos y los métodos que se pueden invocar sobre esos valores. Los valores se salvan en una base de datos
(que usa JDBC) o algún otro almacén de datos. Los beans de entidad pueden participar en transacciones que implican otros beans
enterprise y servicios transaccionales.
Los beans de entidad se asocian a menudo a objetos en bases de datos. Un bean de entidad puede representar una fila en un vector,
una sola columna en una fila, o un resultado completo del vector o de la consulta. Asociado con cada bean de entidad hay una clave
primaria única usada para encontrar, extraer, y grabar el bean.
Un bean de entidad puede emplear uno de los siguientes:
- Persistencia controlada por el bean. El bean contiene código para extraer y grabar valores persistentes.
- Persistencia controlada por el contenedor. El contenedor EJB carga y graba valores en nombre del bean.
Cuando se utiliza la persistencia controlada por el contenedor, el compilador WebLogic EJB puede generar clases de soporte de JDBC
para asociar un bean de entidad a una fila de una base de datos. Hay disponibles otros mecanismos de persistencia controlada por el
contenedor. Por ejemplo, TOPLink para BEAWebLogic Server, de "The Object People"
(http://www.objectpeople.com), proporciona persistencia para una
base de datos de objetos relacionales.
Los beans de entidad pueden ser compartidos por muchos clientes y aplicaciones. Un ejemplar de un bean de entidad se puede crear a
petición de cualquier cliente, pero no desaparece cuando ese cliente desconecta. Continúa viviendo mientras cualquier cliente lo esté
utilizando activamente. Cuando el bean ya no se usa, el contenedor EJB puede pasivizarlo: es decir, puede eliminar el ejemplar vivo del
servidor.
Beans de Sesión
Un bean de sesión es un ejemplar transitorio de EJB que sirve a un solo cliente. Los beans de sesión tienden a implementar lógica de
procedimiento; incorporan acciones en vez de datos. El contenedor EJB crea un bean de sesión en una petición del cliente. Entonces
mantiene el bean mientras el cliente mantiene su conexión al bean. Los beans de sesión no son persistentes, aunque pueden salvar
datos a un almacén persistente si lo necesitan.
Un bean de sesión puede ser con o sin estado. Los beans de sesión sin estado no mantienen ningún estado específico del cliente
entre llamadas y pueden ser utilizados por cualquier cliente. Pueden ser utilizados para proporcionar acceso a los servicios que no
dependen del contexto de una sesión, como enviar un documento a una impresora o extraer datos de sólo lectura en una aplicación.
Un bean de sesión con estado mantiene el estado en nombre de un cliente específico.
Los beans de sesión con estado pueden ser utilizados para manejar un proceso, como ensamblar una orden o encaminar un documento
con un flujo de proceso. Como pueden acumular y mantener el estado con interacciones múltiples con un cliente, los beans de sesión
son a menudo la introducción a los objetos de una aplicación. Como no son persistentes, los beans de sesión deben terminar su trabajo
en una sola sesión y utilizar JDBC, JMS, o beans de entidad para registrar el trabajo permanentemente.
Beans Dirigidos por Mensajes
Los beans dirigidos por Mensaje, introducidos en la especificación EJB 2,0, son los beans enterprise que manejan los mensajes
asíncronos recibidos de colas de mensaje JMS. JMS encamina mensajes a un bean dirigido por mensaje, que selecciona un ejemplar
de un almacen para procesar el mensaje.
Los beans dirigidos por Mensajes se manejan en el contenedor del servidor EJB de WebLogic. Como las aplicaciones dirigidas al usuario
no los llaman directamente, no pueden ser accedidas desdee una aplicación usando un EJB home. Sin embargo, una aplicación dirigida al
usuario si puede ejemplarizar un bean dirigidopor mensajes indirectamente, enviando un mensaje a la cola de bean JMS.
Servicios de la Capa de Aplicación
El servidor WebLogic proprociona los servicios fundamentales que permiten que los componentes se concentren en lógica del negocio
sin la preocupación por detalles de implementación de bajo nivel. Maneja el establecimiento de red, la autentificación, la autorización,
la persistencia, y el acceso a objetos remotos para EJBs y servlets. Los APIs Java estándar proporcionan acceso portable a otros
servicios que una aplicación puede utilizar, por ejemplo base de datos y servicios de mensajería.
Las aplicaciones cliente de tecnologías de comunicación en la red conectan con el servidor WebLogic usando protocolos de
establecimiento de una red estándar sobre TCP/IP. El servidor WebLogic escucha peticiones de conexión en una dirección de red que se
pueda especificar como parte de un identificador de recuros uniforme (URI). Un URI es una cadena estandardizada que especifica un
recurso en una red, incluyendo Internet. Contiene un especificador de protocolo llamado un esquema, la dirección de red del servidor,
el nombre del recurso deseado, y los parámetros opcionales. La URL que introducimos en un navegador web, por ejemplo,
http://www.bea.com/index.html, es el formato más familiar de URI.
Los clientes basados en Web se comunican con el servidor WebLogic usando el protocolo HTTP. Los clientes Java conectan usando
Java RMI, que permite que un cliente Java ejecute objetos en servidor WebLogic. Los clientes CORBA tienen acceso a objetos RMI desde
el servidor WebLogic usando RMI-IIOP, que le permite que ejecutar objetos del servidor WebLogic usando protocolos estándar de CORBA.
| Esquema |
Protocolo |
| HTTP |
HyperText Transfer Protocol. Utilizado por los navegadores Web y los programas compatibles HTTP. |
| HTTPS |
HyperText Transfer Protoco over Secure Layers (SSL). Utilizado por programas de navegadores Web y clientes
compatibles HTTPS. |
| T3 |
Protocolo T3 de WebLogic para las conexiones de Java-a-Java, que multiplexa JNDI, RMI, EJB, JDBC, y otros
servicios de WebLogic sobre una conexión de red. |
| T3S |
Protocolo T3S de WebLogic sobre sockets seguros (SSL). |
| IIOP |
Protocolo Internet de IIOP Inter-ORB, usado por los clientes de Java compatibles con CORBA para ejecutar objetos
WebLogic RMI sobre IIOP. Otros clientes de CORBA conectan con el servidor WebLogic con un CORBA que nombra contexto en vez
de un URI para las capas de la lógica de WebLogic Server. |
El esquema en un URI determina el protocolo para los intercambios de la red entre un cliente y el servidor WebLogic. Los protocolos de red
de la tabla 1-1.
Las secciones siguientes proporcionan más información sobre estos protocolos.
HTTP
HTTP, el protocolo estándar del World Wide Web, es un protocolo de petición-respuesta. Un cliente publica una petición que incluya ana URI.
La URI comienza con HTTP: / / y la dirección del servidor WebLogic, y el nombre de un recurso en el servidor WebLogic,
como una página html, un servlet, o una página JSP. Si se omite el nombre del recurso, el servidor WebLogic devuelve la página Web del valor
por defecto, generalmente index.html. La cabecera de una petición HTTP incluye un comando, generalmente
GET o POST. La petición puede incluir parámetros de datos y un mensaje de
contenido.
WebLogic de BEA WebLogic responde siempre a una petición HTTP ejecutando un servlet, que devuelve resultados al cliente. Un
servlet HTTP es una clase Java que puede tener acceso al contenido de una petición HTTP recibida sobre la red y devuelve al cliente
un resultado compatible HTTP.
El servidor WebLogic dirige una petición de una página HTML al servlet File interno. Este servlet busca el fichero HTML
en el directorio de documentos del sistema de ficheros del servidor WebLogic. Una petición para un servlet personalizado
ejecuta la clase Java correspondiente en el servidor WebLogic. Una petición de una página JSP hace que el servidor WebLogic
compile la página JSP en un servlet, si no se ha compilado ya, y después ejecuta el servlet, que devuelve los resultados al
cliente.
T3
T3 es un protocolo optimizado usado para transportar datos entre el servidor WebLogic y otros programas Java, incluyendo
clientes y otros servidores WebLogic. El servidor WebLogic no pierde l apista de cada máquina virtual Java (JVM) con que
conecta, y crea una sola conexión T3 para llevar todo el tráfico con una JVM.
Por ejemplo, si un cliente Java tiene acceso a un bean enterprise y a un almacen de conexiones JDBC en el servidor WebLogic,
se establece una sola conexión de red entre el servidor WebLogic y la JVM del cliente. Los servicios de EJB y de JDBC
pueden ser escritos como si tuvieran uso único de una conexión de red dedicada porque el protocolo T3 multiplexa
invisiblemente los paquetes en la sola conexión. T3 es un protocolo eficiente para las aplicaciones Java-a-Java porque
evita eventos innecesarios de conexión a red y utiliza pocos recursos del SO. El protocolo también tiene mejoras internas
que reducen al mínimo el tamaño de los paquetes.
RMI
RMI es el recurso estándar de Java para las aplicaciones distribuidas. RMI permite que un programa Java, llamado el servidor,
publique objetos Java que otro programa Java, llamado cliente, puede ejecutar. En la mayoría de las aplicaciones, el servidor
WebLogic es el servidor RMI y una aplicación cliente Java es el cliente. Pero los papeles pueden ser invertidos; RMI permite
que cualquier programa Java desempeñe el papel de servidor. La configuración RMI es similar a la configuración de CORBA.
Para crear un objeto remoto, un programador escribe un interface para una clase Java que defina los métodos que puede
ejecutar un cliente remoto. El compilador RMI del servidor WebLogic, rmic, procesa el interface,
produciendo clases Stubs RMI y esqueletos. La clase, los stubs, y los esqueletos remotos
están instalados en servidor WebLogic.
Un cliente Java busca un objeto remotro en servidor WebLogic usando JNDI (Java Naming and Directory Interface), que se
describe más adelante en esta sección. JNDI establece una conexión al servidor WebLogic, busca la clase remota , y devuelve
los stubs al cliente.
El cliente ejecuta un método del stub como si ejecutara el método directamente en
la clase remota. El método del stub prepara la llamada y la transmite sobre la red a la clase esqueleto en el servidor
WebLogic.
Sobre el servidor WebLogic, la clase esqueleto desempaqueta la petición y ejecuta el método sobre el objeto del lado del servidor.
Después empaqueta los resultados y los devuelve al stub en la lado del cliente. WebLogic EJB y varios otros servicios
disponibles para los clientes Java se construye en RMI. La mayoría de las aplicaciones deben utilizar EJB en vez de usar RMI
directamente, porque EJB proporciona una abstracción mejor para los objetos del negocio. Además, el envase del servidor
EJB de WebLogic proporciona a mejroas como almacenamiento en memoria inmediata, persistencia, y el control del ciclo vital
que no estén automáticamente disponibles para las clases remotas.
RMI-IIOP
La Invocación Remotra de Métodos sobre Inter-ORBProtocol Internet (RMI-IIOP) es un protocolo que permite que los
programas clientes CORBA ejecuten objetos de WebLogic RMI, incluyendo beans enterprise. RMI-IIOP se basa en dos
especificaciones del "Object Manegement Group" (http://www.omg.com):
- Mapeo Java-a-IDL.
- Objetos-por-valor.
La especificación Java-a-IDL define cómo un IDL se deriva de un interface Java. Los compiladores del servidor WebLogic para
RMI y EJB le dan la opción de producir IDL al compilar objetos RMI y EJB. Este IDL se puede compilar con un compilador de
IDL para producir los stubs requeridos por un cliente CORBA.
La especificación del objeto-por-valor define cómo los tipos de datos complejos se mapean entre Java y CORBA. Para utilizar
objeto-por-valor, un cliente CORBA debe utilizar un ORB (Object Request Broker) con soporte de CORBA 2.3. Sin un ORB
CORBA 2.3 los clientes CORBA sólo pueden utilizar tipos primitivos de datos Java.
SSL
El intercambio de datos con los protocolos HTTP y T3 se pueden encriptar con el SSL. Usando SSL asegura al cliente que ha
conectado con un servidor autentificado y que los datos transmitidos sobre la red son privados. SSL utiliza el cifrado con clave
pública, que requiere que compramos una ID de servidor, que es un certificado para nuestro servidor WebLogic, de una
"Certificate Authority" como VeriSign. Cuando un cliente conecta puerto SSL del servidor WebLogic, el servidor y
el cliente ejecutan un protocolo que incluya la autentificación de las ID del servidor y la negociación de los algoritmos y
de los parámetros de cifrado para la sesión. El servidor WebLogic también se puede configurar para requerir que el cliente
presente un certificado, un arreglo que se llama autentificación mutua.
Datos y Servicios de Acceso
El servidor WebLogic implementa tecnologías estándars J2EE para proporcionar servicos de datos y de acceso a las aplicaciones
y a los componentes. Estos servicios incluyen los siguientes APIs:
- Java Naming and Directory Interface (JNDI)
- Java Database Connectivity (JDBC)
- Java Transaction API (JTA)
Las secciones siguientes explican estos servicios más detalladamente.
JNDI
JNDI es un API estándar de Java que permite a las aplicaciones buscar un objeto por su nombre. El servidor WebLogic une
los objetos Java que sirve a un nombre en un árbol de nombres. Una aplicación puede buscar objetos, como objetos RMI,
JavaBeans Enterprise, colas JMS, y JDBC DataSources, obteniendo un contexto JNDI del servidor WebLogic y después
llamando el método de operaciones de búsqueda JNDI con el nombre del objeto. Las operaciones de búsqueda devuelven
una referencia al servidor de objetos WebLogic.
WebLogic JNDI soporta el balance de carga del cluster WebLogic. Todo servidor WebLogic en un cluster publica los objetos
que sirve en un árbol de nombres replicado en un amplio cluster. Una aplicación puede obtener un contexto inicial JNDI
del servidor fromany WebLogic en el cluster, realizar operaciones de búsqueda, y recibir una referencia del objeto desde
cualquier servidor del cluster WebLogic que sirve el objeto. Se utiliza un algoritmo de balance de carga configurable separar
la carga de trabajo entre los servidores del cluster.
JDBC
La conectividad de la base de datos JDBC Java (JDBC) proporciona acceso a los recursos backend
de base de datos. Las aplicaciones Java tienen acceso a JDBC usando un driver JDBC, que es un interface específico del
vendedor de la base de datos para un servidor de base de datos. Aunque cualquier aplicación Java puede cargar un driver
JDBC, conectar con la base de datos, y realizar operaciones de base de datos, el servidor WebLogic proporciona una
ventaja de rendimiento significativa ofreciendo almacenes de conexión JDBC.
Un almacen de conexiones JDBC es un grupo se conexiones JDBC con nombre manejadas a través del servidor WebLogic.
En el momento de arranque el servidor WebLogic abre conexiones JDBC y las agrega al almacen. Cuando una aplicación
requiere una conexión JDBC, consigue una conexión del almacen, la utiliza, y luego la devulve al almacen para su uso por
otras aplicaciones. Establecer una conexión con la base de datos es a menudo una operación que consume mucho tiempo,
y recrusos, un almacen de conexiones, que limita el número de operaciones de la conexión, mejora su funcionamiento.
Para registar un almacen de conexiones en el árbol de nombrado JNDIl, definimos un objeto DataSource
para él. Las aplicaciones clientes Java pueden entonces conseguir una conexión del almacen realizando operaciones de
búsqueda JNDI con el nombre del DataSource.
las clases de Java del lado del Servidor utilizan el driver de conexiones JDBC de WebLogic JDBC, que es un driver
genérico de JDBC que llama a través al driver específico del vendedr al driver JDBC. Este mecanismo hace el código de la
aplicación más portable, incluso si cambiamos la marca de la base de datos usada en la grada backend.
El driver JDBC del lado del cliente es el driver de WebLogic JDBC/RMI, que es un interface RMI al driver del alamacen.
Utilizamos este driver de la misma manera que utilizamos cualquier driver JDBC estándar. Cuando se utiliza el driver
JDBC/RMI, los programas Java pueden tener acceso a JDBC de una manera consistente con otros objetos
distribuidos en el servidor WebLogic, y pueden mantener las estructuras de datos de la base de datos en la capa media.
WebLogic EJB y WebLogic JMS tatan con conexiones de un almacen de conexiones JDBC para cargar y salvar objetos
persistentes. Usando EJB y JMS, podemos conseguir a menudo una abstracción más útil de la que podemos obtener usando
JDBC directamente en una aplicación. Por ejemplo, usar un bean enterprise para representar un objeto de datos permite
que cambiemmos el almacén subyacente más adelante sin la modificación del código JDBC. Si utilizamos mensajes
persistentes JMS en vez de operaciones de base de datos con JDBC, será más fácil adaptar la aplicación a un sistema de
mensajería de una tercera persona más adelante.
JTA
El API de transacción de Java (JTA) es el interface estándar para el manejo de transacciones en las aplicaciones Java.
Usando transacciones, podemos proteger la integridad de los datos en nuestras bases de datos y manejar el acceso a esos
datos por aplicaciones o ejemplares simultáneos de la aplicación. Una vez que una transacción comienza, todas las
operaciones transaccionales deben terminar con éxito o todas se deben deshacer.
El servidor WebLogic utiliza las transacciones que incluyen operaciones EJB, JMS, y JDBC. Las transacciones distribuidas,
coordinadas con dos fases, pueden espandir múltiples bases de datos que son accedidas con los drivers XA-compliant JDBC,
como BEA WebLogic jDriver para Oracle/XA.
La especificación EJB define transaciones controladas por el bean y por el contenedor. Cuando se desarrolla un bean con transaciones
controladas por el contenedor, el servidor WebLogic coordina la transacción automáticamente. Si se despliega un bean enterprise
con transacciones manejadas por el bean, el programador de EJB debe proporcionar un código de transacción.
El código de aplicación basado en los APIs JMS o JDBC puede iniciar una transacción, o participar en una transacción comenzada
anteriormente. Un solo contexto de transacción se asocia con el thread de ejecución de WebLogic Server, que ejecuta una
aplicación; todas las operaciones transaccionales realizadas en el thread participan en la transacción actual.
Tecnologías de Mensajería
Las tecnologías de mensajería J2EE proporcionan un APIs estándar que las aplicaciones del servidor WebLogic pueden utilizar
para comunicarse con una otra, así como con aplicaciones de servidores no-WebLogic. Los servicios de mensajería incluyen
los siguientes APIs:
- Java Message Service (JMS)
- JavaMail
Las secciones siguientes describen estos APIs con más detalle:
JMS
El servicio de mensajería JMS de Java (JMS) permite a las aplicaciones comunicarse unas con otra intercambiando mensajes.
Un mensaje es una petición, un informe, y/o un evento que contiene la información necesaria para coordinar la comunicación
entre diversas aplicaciones. Un mensaje proporciona un nivel de abstracción, permitiendo que separemos los detalles sobre
el sistema de destino del código de la aplicación.
WebLogic JMS implementa dos modelos de mensajería: punto-a-punto (PTP) y publish/subscribe (pub/sub). El modelo PTP
permite que cualquier número de remitentes envíe mensajes a una cola. Cada mensaje en la cola se entrega a un solo
programa de lectura. El modelo pub/sub permite que cualquier número de remitentes envíe mensajes a un Topic.
Cada mensaje en el Topic se envía a todos los programas de lectura con una suscripción al Topic. Los mensajes se pueden
entregar a los programas de lectura síncrona o asíncronamente.
Los mensajes JMS pueden ser persistentes o no-persistentes. Los mensajes persistentes se salvan en una base de datos y
no se pierden si se rearranca el servidor WebLogic. Los mensajes no-persistentes se pierden si se rearranca el servidor
WebLogic. Los mensajes persistentes enviados a un Topic pueden conservarse hasta que todos los suscriptores
interesados los hayan recibido.
JMS soporta varios tipos de mensaje que sonn útiles para diversos tipos de aplicaciones. El cuerpo de mensaje puede
contener los texto arbitrario, secuencias del bytes, tipos de datos primitivos de Java, parejas de nombre/valor,
objetos serializables Java, o contenido XML.
Javamail
El servidor JavaMail WebLogic incluye implementación de referencia del Sun JavaMail. JavaMail permite que una aplicación
cree mensajes de E-mail y los envíe a través de un servidor SMTP a la red.
Tutoriales
