Introducción
Modelo Conceptual de JAXM
La siguiente figura presenta una relación conceptual entre JAXM y otros elementos
necesarios en la Mensajería B2B (Negocio a Negocio) basada en Web.
JAXM se ha pensado para ser un API de mensajería de peso ligero para el desarrollo de aplicaciones de mensajería de negocios
basada en XML. Estas aplicaciones aparecen sobre todo, aunque no exclusivamente, en el edge de las
organizaciones. El término edge está siendo utilizado para denotar un conjunto de aplicaciones que,
colectivamente, tratan con la producción y consumición de mensajes estándars de negocio. El requisito para procesar dichos
mensajes se está viendo incrementado por la creciende necesidad de las organizaciones, independientemente de su tamaño,
de intercambiar electrónicamente documentos de negocio. Una aplicación diseñada para consumir documentos específicos del
negocio en una forma acordada, y en respuesta, produce los documentos de negocio apropiados, es a lo que informalmente nos
referimos como un servicio de negocio. Dichos servicios, cuando se despliegan en un Contenedor Web típicamente se llaman
Servicios Web. La especificación formal de dichos servicios está fuera del alcance de este documento.
La figura anterior hace una distinción lógica entre la implementación del API JAXM, y un proveedor de JAXM. Este último es
responsable de la transmisión y recepción real de los mensajes SOAP. Una aplicación escrita para el
API JAXM es referida como un cliente JAXM.
Ámbito de JAXM
Los escenarios del intercambio de mensajes JAXM pueden ser síncronos o asíncronos en naturaleza pero siempre son documentos
céntricos. El intercambio de documentos XML entre los socios de negocios se asume que ocurre de un forma coreografiada.
Los casos de utilización asociados con JAXM se dividen en cinco categorías importantes y todas las implementaciones JAXM
deben utilizar estos estilos de interacción. Observamos que, por simplicidad, se está utilizando el término
Sender para referirnos colectivamente a un Cliente/Proveedor JAXM emparejado a un rol de
producción de mensaje. Similarmente, el término Receiver se refiere a un Cliente/Proveedor
acoplado en un papel de consumidor de mensajes.
En este escenario, se asume que el Sender envia un mensaje sin tener que esperar una respuesta.
Se requiere el Receiver para leer y procesar la petición y para generar una contestación apropiada a
la petición original. El intervalo del tiempo entre una petición y una contestación se puede medir en días. Las
implementaciones JAXM deben, por lo tanto, poder utilizar transacciones de larga duración.
La figura anterior representa un escenario en el cual la recepción de un mensaje de Reconocimiento denota la terminación
con éxito de una petición anterior. Observamos que JAXM no especifica cómo una aplicación debe correlacionar un mensaje
recibido con un mensaje de petición enviado previamente.
La figura de arriba refleja un escenario en el cual el Sender o no puede o no debe proceder hasta
que se reciba una respuesta a un mensaje anterior. La recepción de un mensaje de Ack
implica típicamente la terminación con éxito de una petición anterior.
Este escenario es una variación simple del caso anterior. El Sender espera un mensaje de contestación
a una petición anterior. La diferencia es este caso es que el mensaje de contestación normalmente sólo es de naturaleza
informativa.
Este último caso implica que el Sender no está esperando una respuesta a nivel de negocio
a una petición anterior.
JAXM sólo puede facilitar la automatización de porciones de la totalidad de un Proceso del Negocio. La aplicabilidad JAXM para
sistemas grandes de negocio, es por lo tanto una función de un modelo específico del Proceso de Negocio Completo a un
grupo particular de compañeros de negocio o industria vertical. Las formas en que se expresan los objetos de negocio en
XML no se tratan en esta especificación.
Interoperabilidad de JAXM
Una noción importante presentada en el modelo conceptual de mensajería de B2B, es que un cliente que
soporta JAXM debe ser capaz de interoperar con otra aplicación de negocio independientemente de si la aplicación está
implementada usando JAXM. Uno de los ingredientes dominantes que permiten la interoperabilidad basada en estándars es la
adopción de un modelo de empaquetado del transporte nutral y los acuerdos sobre la estructura de la cabecera del mensajes,
manifiestos, etc. Aunque JAXM se predispone pesadamente hacia el uso de estándares de la industria, los proveedores JAXM 0,92
se requiere que sólo utilicen SOAP1.1 y SOAP con Attachments. Además, los proveedores JAXM pueden
elegir soportar los protocolos de mensajería de la industria de un nivel más alto construidos sobre mensajería
SOAP. Un uso industrial específico de SOAP se refiere aquí como un
Profile perfil. Un Profile JAXM por lo tanto representa un uso estándar o
industrial de SOAP.
Los proveedores JAXM deben soportar el protocolo HTTP pero también también elegir otros
protocolos de red estándars como FTP y SMTP(IMAP, POP). Sin embargo, en todos los casos JAXM asume que los mensajes
SOAP están siendo transportados. Los proveedores JAXM, por lo tanto, debe implementar sus
uniones Transport de acuerdo con las especificaciones SOAP 1.1.
Los proveedores JAXM podrían elegir soportar varios transportes de red concurrentes. Lo clientes JAXM, por ejemplo
aplicaciones de negocio, deberían poder mantenerse aisladas de las especificidades e idiosincrasias del transporte de
red subyacente.
El Modelo de Paquete SOAP
La figura anterior representa el modelo conceptual de un mensaje JAXM completo. Este mensaje está alineado con la especificación
SOAP1.1 (w/attachment). JAXM proporciona a una forma estándar de producir y consumir mensajes SOAP con o si Attachments.
Las implementaciones JAXM deben soportar Attachments SOAP. Sin embargo, un cliente de JAXM podría
elegir opcionalmente crear y/o consumir Attachments SOAP basándose en los requisitos específicos de la
aplicación. Es responsabilidad del cliente JAXM reconocer la presencia de uno o más Artachments y procesarlos de una forma
específica de la aplicación. JAXM utiliza la versión 1.0a del marco de la activación de Java JAF para
soportar una forma flexible de manejar los attachments SOAP basados en los tipos MIME.
La implementaciones JAXM deben usar empaquetado basado MIME solo en los casos donde un cliente JAXM elija enviar datos
especificos de la aplicación como Attachments. La elección de modelos de empaquetado está por lo tanto implícita bajo el control
del desarrollador de aplicaciones.
El diagrama anterior SOAP1.1 con Attachments asume la presencia de uno o más attachments SOAP.
Donde no está presente un attachment específico SOAP de la aplicación (es decir, el desarrollador no especificó
ningún attachment), la envoltura externa MIME Multipart/Related del protocolo de comunicación (HTTP, SMTP...) es
redundante y una implementacion JAXM no debe producir una. La figura anterior muestra el modelo de empaquetado estándar SOAP1.1 sin
Attachments.
Tutoriales
