El API JAXM

El término Infraestructura se usa para referirse a una funcionalidad específica de la aplicación requerida para soportar una implementacion JAXM.

. Cliente JAXM

El término cliente se usa aquí en forma de sinónimo de aplicación, es decir una colección de funciones del nivel de aplicación que normalmente se despliega en un contendor Web J2EE o un contenedor EJB J2EE. Un cliente JAXM es un consumidor de servicios ofrecidos por un proveedor. Los clientes JAXM deben ser capaces de consumir mensajes SOAP1.1 (w/attachments). Además, cuando se despliega un cliente JAXM en un contenedor Web J2EE el protocolo SOAP1.1 se debe limitar a HTTP. Sin embargo, la forma en que se comunican los clientes JAXM con los proveedores JAXM se considera un detalle privado de la implementación. No se requiere que un cliente JAXM esté localizado con su proveedor ni se requiere que esté en una máquina virtual diferente.

La relación entre los clientes JAXM es fundamentalmente uno-a-uno, es decir desde una perspectiva de modelo programático un cliente JAXM puede elegir desempeñar un papel de cliente o un papel de servidor. Además, dependiendo de un contexto específico o de coreografía de la mensajería, un cliente JAXM es libre de cambiar los papeles. A modo de ejemplo, una aplicación JAXM puede enviar una o más órdenes de compra a un servicio específico de consolidación de órdenes de compra y podría elegir esperar un acuse de recibo desde ese servicio. En caso de que los acuses de recibo no puedan llegar, el cliente puede elegir volver a enviar las órdenes de compra o alternativamente reenviar una petición explícita del Acuse de Recibo.

. Mensajes de Error

Las implementaciones JAXM deben adoptar un mejor esfuerzo estrategico para asegurar la validez de los mensajes producidos y enviados a las entidades de par. Los proveedores JAXM, al recibir un mensaje malformado, son responsables de producir un mensaje de error apropiado para a la entidad ofendida. La estructura y la dirección de los mensajes de error del inter-proveedor es específica del perfil. JAXM no hace una distinción entre los mensajes de error y cualquier otro mensaje específico del perfil. Dado que los proveedores están preocupados del Perfil, pueden elegir asociar una condición de error sobre un mensaje de error específico del perfil. Dichos mensajes, serían entregados a un cliente de punto final de la misma forma que se haría con cualquier otro mensaje. Es responsabilidad del cliente JAXM consumir estos mensajes y tomar una acción correctiva específica de la aplicación.

. Perfiles de Mensajería

Las implementaciones JAXM deben utilizar mensajes SOAP1.1 y SOAP con Attachments. Sin embargo, estas especificaciones proporcionan un modelo de empaquetado muy básico y no ofrecen ninguna estructura específica del esquema de dirección o estructura del mensaje para el enrutado de mensajes entre las entidades.

Un perfil representa un uso específico de una cabecera SOAP. JAXM no especifica qué contenido específico XML se debe poner en la cabecera, o en el cuerpo o los Attachments SOAP. La mayoría de los usos empresariales de la mensajería SOAP normalmente especificarán la información crítica con respecto a la identificación del remitente, del recipiente, del ID del mensaje, y de la correlación de la información. Este último es necesario para relacionar mensajes de respuesta a peticiones anteriores.

Las implementaciones JAXM pueden elegir soportar un número de perfiles estándares de mensajería industrial. Los perfiles se identifican por el nombre. Un nombre de perfil identifica únicamente un uso determinado de los cuerpos industrial/estandar de la mensajería SOAP. Un cliente JAXM debe utilizar el URI del esquema asociado con a un perfil dado como nombre de perfil.

Por ejemplo, el Profile para ebXML TR&P 1.0 podría identificarse con la siguiente URI: http://www.ebxml.org/project_teams/transport/messageHeader.xsd

Se requiere que los desarrolladores JAXM especifiquen, en tiempo de ejecución o en tiempo de despliegue, el nivel de información crítica del "sistema" necesaria para enrutar, entregar y correlacionar correctamente los mensajes. La forma en que esta información se asocia a un mensaje dado es específico del perfil. JAXM no hace ninguna asunción sobre donde se graba esta información, si está presente, dentro de un mensaje. Por lo tanto, debe existir un contrato explícito entre un cliente JAXM y su proveedor. El String Profile se utiliza para establecer este contrato en tiempo de ejecución. Para que las aplicaciones JAXM puedan intercambiar los mensajes de negocio con otras entidades, debe exisitr un acuerdo a-priori (para utilizar un perfil común). La forma en la que se pueden establecer dichos acuerdos está fuera del alcance de este documento.

A modo de ejemplo, un perfil ebXML MS V1.0 especifica claramente cómo se debería rellenar una cabecera SOAP con la dirección necesaria, y la información de identificación del mensaje. Una aplicación JAXM, al usar dicho perfil, es responsable de construir una cabecera SOAP según las especificaciones asociadas a este perfil. Por lo tanto, todos los proveedores que utilicen el mismo perfil (identificado por un nombre de perfil) tendrán un entendimiento común de la estructura del mensaje y de la semántica del mensaje. Observa que los clientes JAXM pueden especificar nombres de perfil al crear objetos MessageFactory. Dichos objetos se pueden utilizar posteriormente para producir objetos específicos del Perfil del mensaje. Además, las implementaciones JAXM pueden elegir pre-rellenar un mensaje con la información crítica, por ejemplo, los campos TO y FROM de una forma específica del perfil.

Si una aplicación elige no especificar un perfil estándar, el proveedor JAXM debe usar un perfil por defecto específico de la aplicación. En tales casos, los desarrolladores JAXM no pueden estar seguros del nivel de interoperabilidad basado en estándares públicos. Es concebible que un proveedor dado pueda utilizar múltiples aplicaciones específicas, es decir, perfiles privados.

. Despliegue de JAXM

Los clientes JAXM podrían desplegarse en contenedores Serlvers 2.3 y/o Contenedores J2EE 1.3.

Los desarrolladores JAXM deben especificar dos informaciones claves necesarias como parte del proceso de despliegue en un Contenedor Servlet 2.3:

<!ELEMENT client-endpoint (#PCDATA)>
<!--
El client-endpoint identifica una dirección específica para un cliente JAXM. 
Las partes que deseen intercambiar mensaje deben tener un entendiemto mútuo
y tener en cuenta su direccion. El client-endpoint debe ser una URI.
-->
<!ELEMENT listener-url (#PCDATA)>
<!--
El elemento listener-url es la URL del MessageListener.
-->

Observa que la forma en que la información de configuración del cliente se comunica al proveedor es un detalle de implementación.

Además de la información de configuración JAXM mencionada arriba, se requiere que los clientes JAXM (si se despliega un cliente en un contenedor Servlet 2,3) especifiquen la información de despliegue para JAXMServlets. Los descriptores de despliegue para JAXMServlets se especificarán en una revisión futura de esta especificación.

. MessageListener

JAXM promueve una forma estándar de entregar mensajes asíncronamente a los clientes JAXM. En el caso de contenedores EJB J2EE, el interface MessageListener se podría implementar usando el "J2EE Message Driven Beans"(MDB). En el caso de contenedores Servlet, se requiere que los clientes JAXM extiendan el interface JAXMServlet e implementen el método onMessage(). Según lo mencionado previamente, el contrato del proveedor al cliente se basa en formatos de mensaje SOAP1.1 (w/attachments). Es decir, independientemente de donde se despliegue un cliente JAXM se usará un esquema estándar de envoltura de mensaje. Además, dando que el interface JAXMServlet extiende HTTPServlet, hay una clara asunción de que cuando un cliente JAXM se despliega en un contenedor Servlet el modelo de activación asíncrono es construido en SOAP1.1 (w/attachments) limitado a HTTP. Observa que en subsecuentes revisiones de esta especificación, y en interés de la portabilidad de clientes JAXM , podrían introducirse requisitos adicionales para poder definir las capacidades de JAXMServlet.

. Seguridad del Mensaje

JAXM no introduce ningún nuevo requisito de seguridad. Se asume que los mensajes tienen un requisito de transitoriedad así como de persistencia de confidencialidad. El soporte de las características de seguridad y las capacidades que aseguran la confidencalidad mientras los mensajes están en tránsito son un detalle de la implementación del proveedor JAXM. Cuando se elige el transporte HTTP, el soporte para los protocolos tales como SSL puede ser apropiado y adecuado. En el caso de las infraestructuras SMPT, los proveedores JAXM pueden elegir utilizar PGP y/o S/MIME.

JAXM no proporciona a ningún interface específico para las firmas digitales que expanden un mensaje entero. La asunción es que los desarrolladores JAXM tendrán acceso a las porciones del nivel de usuario de un mensaje - donde el nivel de usuario se define como las partes específicas de la aplicación de un mensaje. Observa que la firma o el cifrado de la cabecera SOAP de una forma que prevendría que el mensaje fuera interpretado y por lo tanto correctamente enrutado lanzará una excepción JAXM. Un desarrollador JAXM puede requerir una cierta aplicación específica y potencialmente no estándar, algoritmos de cifrado y/o funciones de seguridad, para ser aplicado a las porciones predefinidas de un mensaje. En tales circunstancias, los desarrolladores deben seleccionar un perfil apropiado conocido al proveedor JAXM.

Los desarroladores JAXM pueden elegir utilizar tecnologías de firmas digitales para firmar fragmentos del nivel de aplicación XML mientras que vean el ajuste. Según lo mencionado anteriormente, la aplicación de tecnología de firmas específica no debe interferir en el enrutamiento de los mensajes por la infraestructura JAXM.

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.