La figura muestra el formato lógico y los objetos que componen los mensajes del conjunto de mensajes Video. Para obtener una descripción del diagrama, consulte el apartado Estructura del modelo de mensaje.
El conjunto de mensajes Video es un componente del modelo de mensaje del ejemplo Alquiler de vídeos. Desde le modelo de mensaje puede ver cómo crear un modelo de mensaje lógico y sus formatos físicos asociados. En el ejemplo Alquiler de Vídeos, el modelo de mensaje contiene datos de un cliente que alquila vídeos. Los datos contenidos en los mensajes incluyen:
Para obtener más información, consulte El modelo de mensaje en la documentación de WebSphere Message Broker.
Los elementos del modelo del mensaje se basan en tipos simples y complejos. Los recuadros sombreados representan los elementos que están basados en tipos complejos y los recuadros sin sombrear representan elementos que están basados en tipos simples. El modelo de mensaje contiene catorce elementos basados en tipos simples. Los tipos simples son tipos de datos, como una serie, un entero y un byte. Estos tipos simples son la base de los elementos no sombreados en la figura. A excepción del ID de elementos y la revista que son hijos directos del cliente, todos los elementos simples del modelo de mensaje son hijos de elementos complejos o de un grupo. Estos elementos complejos y el grupo son hijos del tipo complejo Customer. Un tipo complejo es una definición de estructura que se trata en realidad de una plantilla para los datos incluidos en el mismo. Estos tipo complejos forman la base de los elementos que aparecen sombreados en gris en la figura.
Los tipos complejos pueden ser con nombre o anónimos. En el modelo de mensaje Video, Address y Borrowed tienen los tipos complejos (locales) anónimos, mientras que Name tiene un tipo complejo (global) identificado. Un tipo complejo identificado puede utilizarse en cualquier otro lugar, por ejemplo en otros esquemas, mientras que un tipo complejo anónimo sólo puede utilizarse en la declaración que lo contiene. La utilización de tipos complejos identificados tienen algunas ventajas claras. Por ejemplo, con tipos complejos identificados se puede compartir más fácilmente información por toda la organización. Sin embargo, hay situaciones en las que es preferible utilizar tipos complejos anónimos como cuando un tipo complejo no debe utilizarse en ningún otro lugar.
El objeto denominado IdGroup se diferencia de otros elementos del mensaje en que es un grupo. IdGroup le ayuda a definir la forma cómo funcionan los elementos PassportNo, DrivingLicenseNo y CreditCardNo. Cuando un cliente abre una nueva cuenta en la tienda de vídeos, sólo es necesario un tipo de identificador para probar la identidad. Al crear un grupo y definir PassportNo, DrivingLicenseNo y CreditCardNo como miembros de dicho grupo, puede configurar el modelo de mensajes para así poder seleccionar sólo uno de los tres tipos de identificador. Es decir, los tres elementos se tratan como una opción dentro del tipo anterior. Si incluye los elementos directamente en un tipo, los tres elementos se pueden entrar a la vez.
Para demostrar distintas formas de construir un modelo de mensaje, el objeto denominado LastName se crea como un atributo en lugar de como un elemento. Si se crea un objeto como si fuera un atributo, afectará a la forma en que se construye el XML.
Para obtener más información, consulte Objetos de modelo de mensaje en la documentación de WebSphere Message Broker.
El ejemplo Alquiler de vídeos también muestra el uso de los espacios de nombres en el modelo de mensaje, en el mensaje de entrada XML y en el ESQL que el flujo de mensajes utiliza para hacer referencia a partes del mensaje. El ejemplo Alquiler de Vídeos tiene tres definiciones de mensajes. El archivo de definición de mensajes para la información de Customer no tiene un espacio de nombres de destino. Sin embargo, los archivos de definición de mensajes para la información de Address y Borrowed no tienen espacios de nombres de destino. Los archivos de definición de mensaje para Address y Borrowed se importan en el archivo de definición de mensajes para la información de Customer. Si Address y Borrowed se colocan en distintos espacios de nombres, significa que estos elementos pueden utilizarse fácilmente en cualquier otro lugar para otros fines comerciales.
Agrupar la información de forma lógica significa que, por ejemplo, los datos recopilados por el departamento de servicio al cliente de una empresa se pueden compartir entre otros departamentos, como el de facturación o ventas. No es necesario colocar en distintos espacios de nombres los objetos que se tienen que compartir, aunque existen situaciones en las que esto puede ayudar a compartirlos. Por ejemplo, distintos desarrolladores trabajando de forma independiente pueden crear objetos con el mismo nombre, pero con un significado de empresa distinto. Si los objetos se colocan en distintos espacios de nombres, los conjuntos de objetos pueden desarrollarse de forma independiente sin que haya conflictos de nombres.
Los espacios de nombres pueden ser útiles incluso cuando un grupo de desarrolladores está desarrollando objetos. Por ejemplo, un objeto denominado Name puede tener varios significados; puede indicar el nombre de un cliente o el nombre de un producto. Una forma de evitar este problema es crear objetos con nombres como CustomerName y ProductName, pero esto puede significar tener nombres demasiado largos. Una solución alternativa es colocar en un espacio de nombres todos los objetos relacionados con la información del cliente y, en otro, todos los objetos relacionados con productos. De esta forma puede dejar que el espacio de nombres al que pertenece un objeto determine su contexto.
Para obtener más información, consulte Espacios de nombres del modelo de mensaje en la documentación de WebSphere Message Broker.
WebSphere Message Broker tiene soporte para varios formatos físicos que le permitirán definir en detalle la representación física de los mensajes. Por ejemplo, añadiendo un Formato Físico Personalizado (CWF) en los conjuntos de mensajes, puede procesar mensajes de entrada en este formato, construir mensajes de salida en este formato y transformar mensajes de CWF a TDS o XML, o de TDS o de XML a CWF. Los mensajes de entrada para los tres formatos físicos se describen en las siguientes secciones.
Para obtener más información, consulte Formatos físicos del dominio MRM en la documentación de WebSphere Message Broker.
El ejemplo siguiente muestra el mensaje de cliente de Vídeo en el formato físico CWF (tenga en cuenta que es posible que tenga que desplazarse hacia la derecha para ver todo el mensaje):
Mr Fred Bloggs 12 Willow Avenue Salisbury CJ123456TT Fast Cars 2003-05-233.00Cut To The Chase 2003-05-233.751
El formato físico personalizado no utiliza códigos.
Por ejemplo, en el anterior mensaje, el primer campo (con el valor
Mr) tiene una longitud de 3, pero no hay ningún código para indicar que el campo finaliza.
El ejemplo siguiente es que el mensaje parece como cliente De vídeo en el Formato físico personalizado si los distintos campos están separados en distintas líneas para facilitar la lectura:
Mr Fred Bloggs 12 Willow Avenue Salisbury C J123456TT Fast Cars 2003-05-23 3.00 Cut To The Chase 2003-05-23 3.75 1
El mensaje de clientes de Vídeo se presenta en XML como se muestra en el ejemplo siguiente:
<Customer xmlns:addr="http://www.ibm.com/AddressDetails" xmlns:brw="http://www.ibm.com/BorrowedDetails">
<Name LastName="Bloggs">
<Title>Mr</Title>
<FirstName>Fred</FirstName>
</Name>
<addr:Address>
<HouseNo>13</HouseNo>
<Street>Oak Street</Street>
<Town>Southampton</Town>
</addr:Address> <ID>P</ID>
<PassportNo>J123456TT</PassportNo>
<brw:Borrowed>
<VideoTitle>Fast Cars</VideoTitle>
<DueDate>2003-05-23T01:00:00</DueDate>
<Cost>3.50</Cost>
</brw:Borrowed>
<brw:Borrowed>
<VideoTitle>Cut To The Chase</VideoTitle>
<DueDate>2003-05-23T01:00:00</DueDate>
<Cost>3.00</Cost>
</brw:Borrowed>
<Magazine>0</Magazine>
</Customer>
El ejemplo siguiente muestra el mensaje de clientes de Vídeo en el formato TDS (los datos se han subdividido en líneas distintas para que se puedan leer mejor):
{Name:[Title:Mr*FirstName:Fred*LastName:Bloggs] &Address:[HouseNo:12*Street:Willow Avenue*Town:Salisbury] &ID:P &PassportNo:J123456TT &Borrowed:[Fast Cars+2003-05-23+3.00] &Borrowed:[Cut To The Chase+2003-05-23+3.75] &Magazine:1}
El IdGroup de objeto del mensaje representa una elección de tipos de identificador para el cliente que alquila vídeos. El identificador puede ser un número de pasaporte, un número de permiso de conducir o un número de tarjeta de crédito. El número proporcionado en el mensaje de entrada está correlacionado con uno de tres campos (opciones) posibles: PassportNo, DrivingLicenseNo o CreditCardNo. Con los mensajes XML y TDS, la elección puede resolverse utilizando códigos y delimitadores en los mensajes propiamente dichos. No obstante, el mensaje CWF no contiene códigos ni delimitadores, por lo tanto, la opción debe resolverse utilizando ESQL y el valor del campo ID del mensaje. El campo ID contiene un sólo carácter que representa el tipo de identificador proporcionado por el cliente: P para PassportNo, D para DrivingLicenseNo o C para CreditCardNo.
Cuando un mensaje CWF que contiene una elección sin resolver lleva a un nodo de entrada, el analizador MRM desencadena un mensaje de aviso (que puede ver si rastrea el flujo de mensajes). El proceso del mensaje sigue, pero no puede completarse a menos que haya un nodo posterior que contenga código ESQL que resuelva la elección. El código ESQL de un nodo Compute proporciona una forma de hacer referencia al árbol lógico de mensaje creado como resultado del análisis inicial. Puesto que el mensaje de entrada estaba sin resolver, las referencias a este árbol se devuelven nulas.
Para decidir a qué campo (PassportNo, DrivingLicenseNo o CreditCardNo) se asigna el identificador, se utiliza un ID adicional llamado ID. El campo ID contiene un carácter para representar el tipo de identificador utilizado: P, D o C. En el árbol de mensaje, este campo aparece antes que el campo IdGroup, lo que significa que el valor del campo ID puede analizarse antes de intentar resolver la elección. Con el campo ID analizado, el valor puede utilizarse en sentencias ESQL para resolver la elección.
Para saber cómo funciona el manejo de elecciones, consulte Ejecutar el ejemplo Alquiler de Vídeos e intente realizar la tarea de rastreo opcional. Para saber cómo es el ESQL del ejemplo, consulte Crear el flujo de mensajes.
Después de importar los archivos de conjunto de mensajes en el área de trabajo, puede explorar las propiedades de los elementos del modelo de mensaje de Vídeo. Lo que aparece en el área de trabajo corresponde al diagrama anterior de la estructura de mensaje. Por ejemplo, para explorar el elemento Name:
Puede ver los demás elementos de forma parecida. Si desea ver información más detallada sobre la creación de la estructura del mensaje, consulte el apartado Crear el ejemplo de Alquiler de Vídeos.