La figura muestra el formato lógico del conjunto de mensajes Video así como los objetos que lo forman . También puede leer una descripción de la figura aquí.
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:
Si desea ver más información, lea lo referente a modelos de mensajes 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 se basan en tipos complejos, a la vez que los recuadros no sombreados representan elementos que se basan en tipos simples. Como puede ver en la figura, 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 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 pueden especificarse 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.
Si desea ver más información, lea lo referente a objetos de modelos de mensajes en la documentación de WebSphere Message Broker.
El ejemplo de Alquiler de Vídeos también muestra la utilización de espacios de nombres en el modelo de mensaje, en el mensaje de entrada XML y en el ESQL que utiliza el flujo de mensajes para hacer referencia de las 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, indica 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 es necesario compartir, aunque existen situaciones en las que esto puede ayudar a compartirlos. Por ejemplo, distintos desarrolladores trabajando de forma independiente podrían crear objetos con el mismo nombre, pero con un significado de empresa distintos. 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 podría tener varios significados; podría indicar el nombre de un cliente o el nombre de un producto. Una forma de evitar el problema sería 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 más información, lea lo referente a espacios de nombres 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, al añadir un formato físico personalizado (CWF) a 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.
Si desea ver más información, lea lo referente a formatos físicos en la documentación de WebSphere Message Broker.
A continuación se 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. A continuación se muestra el aspecto que tendrá el mensaje de cliente de Vídeo en formato físico personalizado si se separaran los distintos campos en distintas líneas para una mejor 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 del siguiente modo:
<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>
A continuación se 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 primero que el campo IdGroup. Esto 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 a la figura de la estructura de mensajes anterior. 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.