Sobre o Conjunto de Mensagens da Amostra Aluguel de Vídeo

A figura mostra o formato lógico e os objetos que compõem mensagens no conjunto de mensagens Vídeo. Para obter uma descrição do diagrama, consulte Estrutura do modelo de mensagem.

O modelo de mensagem da amostra Vídeo. Para obter uma descrição da figura, siga o link de Estrutura do modelo de mensagem.

O conjunto de mensagens Vídeo é um componente do modelo de mensagem de amostra Aluguel de Vídeo. A partir do modelo de mensagem, você pode ver como é possível construir um modelo de mensagem lógico e seus formatos físicos associados. Na amostra Aluguel de Vídeo, o modelo de mensagem contém dados de um cliente que está alugando vídeos. Os dados contidos nas mensagens incluem:

Para obter informações adicionais, consulte O Modelo de Mensagem na documentação do WebSphere Message Broker.

Elementos do Modelo de Mensagem

Os elementos do modelo de mensagem são baseados em tipos complexos e simples. As caixas escurecidas representam os elementos que estão baseados em tipos complexos, e as caixas mais claras representam elementos que estão baseados em tipos simples. O modelo de mensagem contém catorze elementos baseados em tipos simples. Os tipos simples são tipos de dados, tais como, cadeias, inteiro e byte. Esses tipos simples são a base dos elementos não-sombreados da figura. Exceto pelos elementos ID e Magazine, que são filhos diretos de Customer, todos os elementos simples no modelo de mensagem são filhos de elementos complexos ou de um grupo. Esses elementos complexos e o grupo são filhos do tipo complexo Customer. Um tipo complexo é uma definição de estrutura, que é efetivamente um gabarito para os dados nele contidos. Estes tipos complexos são a base dos elementos que são sombreados em tom de cinza na figura.

Os tipos complexos podem ser nomeados ou anônimos. No modelo de mensagem Video, Address e Borrowed há tipos complexos anônimos (local), mas Name possui um tipo complexo com nome (global). Um tipo complexo denominado pode ser usado também, por exemplo, em outros esquemas, ao passo que o tipo complexo anônimo pode ser utilizado somente na declaração que o contém. Utilizar tipos complexos nomeados tem algumas vantagens claras. Utilizando tipos complexos nomeados, você pode, por exemplo, compartilhar informações mais facilmente em sua organização. No entanto, há circunstâncias nas quais pode ser preferível utilizar tipos complexos anônimos, como quando um tipo complexo não deve ser reutilizado em outro lugar.

O objeto denominado IdGroup é diferente dos outros elementos na mensagem, já que é um grupo. O IdGroup ajuda a definir a maneira como os elementos PassportNo, DrivingLicenseNo e CreditCardNo se comportam. Quando um cliente abre uma nova conta na locadora de vídeos, somente um tipo de identificador é necessário para provar a identidade. Ao criar um grupo e definir PassportNo, DrivingLicenseNo e CreditCardNo como membros do grupo, é possível configurar o modelo de mensagem para que você possa escolher somente um dos três tipos de identificador. Ou seja, os três elementos são tratados como uma escolha dentro do tipo acima. Se você incluir os elementos diretamente em um tipo, todos os três elementos podem ser digitados ao mesmo tempo.

Para demonstrar diferentes maneiras de construção de um modelo de mensagem, o objeto chamado LastName é criado como um atributo em vez de como um elemento. Criar um objeto como um atributo afeta a maneira como o XML é construído.

Para obter informações adicionais, consulte Objetos do Modelo de Mensagens na documentação do WebSphere Message Broker.

Espaços de Tabelas

A amostra Aluguel de Vídeo também demonstra a utilização de espaços de nomes no modelo de mensagem, na mensagem de entrada XML, e no ESQL utilizado pelo fluxo de mensagens para referenciar partes da mensagem. A amostra Aluguel de Vídeo possui três definições de mensagem. O arquivo de definição de mensagem para as informações de Cliente não tem um espaço de nomes de destino. Os arquivos de definição de mensagem para as informações de Endereço e Emprestado, contudo, têm espaços de nomes de destino. Os arquivos de definição de mensagem para Address e Borrowed são importados para o arquivo de definição de mensagem, para as informações de Customer. Colocando Address e Borrowed em espaços de nomes separados significa que esses elementos podem ser usados facilmente em qualquer lugar para outros fins.

Agrupar informações de forma lógica significa que os dados coletados pelo, por exemplo, departamento de serviço ao consumidor de uma empresa possam, então, ser facilmente compartilhados por outros departamentos, como faturamento ou vendas. Não é necessário colocar objetos que precisam ser compartilhados em espaços de nomes diferentes, mas há ocasiões em que isso pode ajudar no compartilhamento. Por exemplo, desenvolvedores diferentes que trabalham de maneira independente uns dos outros podem criar objetos com o mesmo nome, mas com um tipo de negócios diferente. Colocando os objetos em diferentes espaços de nomes, os conjuntos de objetos podem ser desenvolvidos independentes sem conflitos de nomes.

Os espaços de nomes podem ser úteis mesmo quando os objetos estão sendo desenvolvidos por um grupo de desenvolvedores. Por exemplo, um objeto chamado Name pode ter vários significados; pode significar o nome de um cliente, ou o nome de um produto. Uma forma de evitar o problema é criar objetos com nomes como CustomerName e ProductName, mas esse formato pode resultar em nomes excessivamente longos. Uma solução alternativa é colocar todos os objetos relativos a informações do cliente em um espaço de nome e todos os objetos relativos a produtos em outro. Dessa forma, você pode permitir que o espaço de nomes, ao qual um objeto pertence determinar seu contexto.

Para obter informações adicionais, consulte Espaços de Nomes no Modelo de Mensagem na documentação do WebSphere Message Broker.

Formatos Físicos

O WebSphere Message Broker suporta vários formatos físicos que permitem definir detalhadamente a representação física de suas mensagens. Por exemplo, incluir um Custom Wire Format (CWF) em seus conjuntos de mensagens, é possível processar mensagens de entrada nesse formato, construir mensagens de saída nesse formato e transformar mensagens de CWF para TDS ou XML ou de TDS ou XML para CWF. As mensagens de entrada para os três formatos físicos são descritas nas seguintes seções.

Para obter informações adicionais, consulte Formatos Físicos no Domínio MRM na documentação do WebSphere Message Broker.

A Mensagem de Entrada CWF

O exemplo a seguir mostra a mensagem do cliente de Vídeo no formato físico CWF (observe que você pode precisar rolar para a direita para ver a mensagem inteira):

Mr Fred                Bloggs              12  Willow Avenue       Salisbury           CJ123456TT          Fast Cars           2003-05-233.00Cut To The Chase    2003-05-233.751

O Custom Wire Format não usa tags. Por exemplo, na mensagem acima, o primeiro campo (com o valor Mr) tem um comprimento de 3, mas não existe marcação para indicar onde o campo termina. O exemplo a seguir mostra a aparência da mensagem do cliente de Vídeo em Custom Wire Format se os diferentes campos forem separados em diferentes linhas para facilitar a leitura:

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

A Mensagem de Entrada XML

A mensagem do cliente Vídeo é renderizada em XML conforme mostrado no exemplo a seguir:

<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 Mensagem de Entrada TDS

O exemplo seguir mostra a mensagem do cliente de Vídeo no formato TDS (os dados são divididos em linhas separadas para melhorar a capacidade de leitura):

{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}

Tratamento de Opção Não Resolvida

O objeto IdGroup na mensagem representa uma escolha de tipos de identificadores para o cliente que está retirando vídeos. O identificador pode ser um número de passaporte, um número de carteira de motorista ou um número de cartão de crédito. O número fornecido na mensagem de entrada é mapeado para um entre três campos (opções) possíveis: PassportNo, DrivingLicenseNo ou CreditCardNo. Com mensagens XML e TDS, a opção pode ser resolvida usando marcações e delimitadores nas próprias mensagens. No entanto, a mensagem CWF não contém as tags ou delimitadores, portanto, a opção deve ser resolvida usando ESQL e o valor do campo ID na mensagem. O campo ID contém um único caractere representando o tipo de identificador fornecido pelo cliente: P para PassportNo, D para DrivingLicenseNo ou C para CreditCardNo.

Quando uma mensagem CWF contendo uma opção não resolvida chega a um nó de entrada, o analisador MRM aciona uma mensagem de aviso (que você pode visualizar se rastrear o fluxo de mensagens). O processamento da mensagem continua, mas não pode ser concluído a menos que exista um nó subsequente contendo código ESQL que resolva a opção. O código ESQL em um nó Compute fornece uma maneira de se referir à árvore de mensagens lógica que foi construída como resultado da análise inicial. Como a mensagem de entrada não foi resolvida, as referências à árvore retornam null.

Para decidir a qual campo (PassportNo, DrivingLicenseNo ou CreditCardNo) o número do identificador é atribuído, um campo adicional denominado ID é utilizado. O campo ID contém um caractere para representar o tipo de Identificador usado: P, D, ou C. Na árvore de mensagens, esse campo vem antes do campo de opção IdGroup, o que significa que o valor do campo ID pode ser analisado antes de haver uma tentativa de resolver a opção. Com o campo ID analisado, o valor pode então ser utilizado em instruções ESQL para resolver a opção.

Para ver como funciona a manipulação de opções, consulte Executando a Amostra Aluguel de Vídeo e tente a tarefa opcional de rastreio. Para descobrir com que se parece o ESQL para a amostra, consulte Criando o Fluxo de Mensagens.

Explorando Propriedades dos Elementos

Depois de ter importado os arquivos do conjunto de mensagens para o ambiente de trabalho, você pode explorar as propriedades dos elementos no modelo de mensagem Vídeo. O que você pode ver no ambiente de trabalho corresponde ao diagrama anterior da estrutura da mensagem. Por exemplo, para explorar o elemento Name:

  1. Na visualização Desenvolvimento do Intermediário, dê um clique duplo em Customer.mxsd.
  2. Na visualização Tópicos, clique em Tipos.
  3. No editor Message Definition, expanda o tipo denominado NameType.
  4. Clique em um dos elementos, (Title, FirstName, ou LastName) exibidos sob NameType. Para exibir as propriedades desses elementos, clique na guia Propriedades e clique em itens na árvore Hierarquia de Propriedades para ver suas definições atuais.

É possível visualizar os outros elementos de maneira similar. Para obter informações mais detalhadas sobre como a estrutura da mensagem é construída, consulte Construindo a Amostra Aluguel de Vídeo.

Voltar para Home da Amostra