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.