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.