El API JAXM

La siguiente figura presenta una relacin conceptual entre JAXM y otros elementos necesarios en la Mensajera B2B (Negocio a Negocio) basada en Web.

JAXM se ha pensado para ser un API de mensajera de peso ligero para el desarrollo de aplicaciones de mensajera de negocios basada en XML. Estas aplicaciones aparecen sobre todo, aunque no exclusivamente, en el edge de las organizaciones. El trmino edge est siendo utilizado para denotar un conjunto de aplicaciones que, colectivamente, tratan con la produccin y consumicin de mensajes estndars de negocio. El requisito para procesar dichos mensajes se est viendo incrementado por la creciende necesidad de las organizaciones, independientemente de su tamao, de intercambiar electrnicamente documentos de negocio. Una aplicacin diseada para consumir documentos especficos 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 tpicamente se llaman Servicios Web. La especificacin formal de dichos servicios est fuera del alcance de este documento.

La figura anterior hace una distincin lgica entre la implementacin del API JAXM, y un proveedor de JAXM. Este ltimo es responsable de la transmisin y recepcin real de los mensajes SOAP. Una aplicacin escrita para el API JAXM es referida como un cliente JAXM.

.mbito de JAXM

Los escenarios del intercambio de mensajes JAXM pueden ser sncronos o asncronos en naturaleza pero siempre son documentos cntricos. El intercambio de documentos XML entre los socios de negocios se asume que ocurre de un forma coreografiada. Los casos de utilizacin asociados con JAXM se dividen en cinco categoras importantes y todas las implementaciones JAXM deben utilizar estos estilos de interaccin. Observamos que, por simplicidad, se est utilizando el trmino Sender para referirnos colectivamente a un Cliente/Proveedor JAXM emparejado a un rol de produccin de mensaje. Similarmente, el trmino 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 peticin y para generar una contestacin apropiada a la peticin original. El intervalo del tiempo entre una peticin y una contestacin se puede medir en das. Las implementaciones JAXM deben, por lo tanto, poder utilizar transacciones de larga duracin.

La figura anterior representa un escenario en el cual la recepcin de un mensaje de Reconocimiento denota la terminacin con xito de una peticin anterior. Observamos que JAXM no especifica cmo una aplicacin debe correlacionar un mensaje recibido con un mensaje de peticin 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 recepcin de un mensaje de Ack implica tpicamente la terminacin con xito de una peticin anterior.

Este escenario es una variacin simple del caso anterior. El Sender espera un mensaje de contestacin a una peticin anterior. La diferencia es este caso es que el mensaje de contestacin normalmente slo es de naturaleza informativa.

Este ltimo caso implica que el Sender no est esperando una respuesta a nivel de negocio a una peticin anterior.

JAXM slo puede facilitar la automatizacin de porciones de la totalidad de un Proceso del Negocio. La aplicabilidad JAXM para sistemas grandes de negocio, es por lo tanto una funcin de un modelo especfico del Proceso de Negocio Completo a un grupo particular de compaeros de negocio o industria vertical. Las formas en que se expresan los objetos de negocio en XML no se tratan en esta especificacin.

.Interoperabilidad de JAXM

Una nocin importante presentada en el modelo conceptual de mensajera de B2B, es que un cliente que soporta JAXM debe ser capaz de interoperar con otra aplicacin de negocio independientemente de si la aplicacin est implementada usando JAXM. Uno de los ingredientes dominantes que permiten la interoperabilidad basada en estndars es la adopcin 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 estndares de la industria, los proveedores JAXM 0,92 se requiere que slo utilicen SOAP1.1 y SOAP con Attachments. Adems, los proveedores JAXM pueden elegir soportar los protocolos de mensajera de la industria de un nivel ms alto construidos sobre mensajera SOAP. Un uso industrial especfico de SOAP se refiere aqu como un Profile perfil. Un Profile JAXM por lo tanto representa un uso estndar o industrial de SOAP.

Los proveedores JAXM deben soportar el protocolo HTTP pero tambin tambin elegir otros protocolos de red estndars como FTP y SMTP(IMAP, POP). Sin embargo, en todos los casos JAXM asume que los mensajes SOAP estn siendo transportados. Los proveedores JAXM, por lo tanto, debe implementar sus uniones Transport de acuerdo con las especificaciones SOAP 1.1.

Los proveedores JAXM podran elegir soportar varios transportes de red concurrentes. Lo clientes JAXM, por ejemplo aplicaciones de negocio, deberan 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 especificacin SOAP1.1 (w/attachment). JAXM proporciona a una forma estndar de producir y consumir mensajes SOAP con o si Attachments.

Las implementaciones JAXM deben soportar Attachments SOAP. Sin embargo, un cliente de JAXM podra elegir opcionalmente crear y/o consumir Attachments SOAP basndose en los requisitos especficos de la aplicacin. Es responsabilidad del cliente JAXM reconocer la presencia de uno o ms Artachments y procesarlos de una forma especfica de la aplicacin. JAXM utiliza la versin 1.0a del marco de la activacin 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 aplicacin como Attachments. La eleccin de modelos de empaquetado est por lo tanto implcita bajo el control del desarrollador de aplicaciones.

El diagrama anterior SOAP1.1 con Attachments asume la presencia de uno o ms attachments SOAP. Donde no est presente un attachment especfico SOAP de la aplicacin (es decir, el desarrollador no especific ningn attachment), la envoltura externa MIME Multipart/Related del protocolo de comunicacin (HTTP, SMTP...) es redundante y una implementacion JAXM no debe producir una. La figura anterior muestra el modelo de empaquetado estndar SOAP1.1 sin Attachments.

COMPARTE ESTE ARTÍCULO

ENVIAR A UN AMIGO
COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN GOOGLE +
ARTÍCULO ANTERIOR

SIGUIENTE ARTÍCULO

¡SÉ EL PRIMERO EN COMENTAR!
Conéctate o Regístrate para dejar tu comentario.