Sobre o Conjunto de Mensagens Vídeo

A figura mostra o formato lógico e os objetos que compõem as mensagens no conjunto de mensagens Vídeo . Você também pode ler uma descrição da figura aqui.

O modelo de mensagem da amostra Vídeo. Para ler uma descrição da figura, siga o link acima dela.

O conjunto de mensagens Vídeo é um componente do modelo de mensagem da 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, leia sobre Modelos 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 sombreadas representam elementos baseados em tipos complexos, enquanto que as caixas não sombreadas representam elementos baseados em tipos complexos. Como você pode ver na figura, 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 Vídeo, Endereço e Emprestado têm tipos complexos anônimos (local), enquanto que Nome tem um tipo complexo nomeado (global). Um tipo complexo nomeado pode ser utilizado em outro local, por exemplo, em outros esquemas, enquanto que um 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 inseridos 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, leia sobre Objetos do Modelo de Mensagem 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 fazer referência a partes de uma 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. Colocar Address e Borrowed em espaços de nomes separados significa que esses elementos poderiam ser facilmente utilizados para outras finalidades de negócios.

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á circunstâncias nas quais isso pode auxiliar o compartilhamento. Por exemplo, diferentes desenvolvedores trabalhando independentes uns dos outros poderiam criar objetos com o mesmo nome, mas com um significado comercial 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 poderia ter vários significados; poderia significar o nome de um cliente ou o nome de um produto. Uma maneira de evitar o problema seria criar objetos com nomes como CustomerName e ProductName, mas isso pode significar ter 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, leia sobre espaço de nomes 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, ao incluir um CWF (Custom Wire Format) em seus conjuntos de mensagens, você pode processar mensagens de entrada neste formato, construir mensagens de saída neste 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, leia sobre formatos físicos na documentação do WebSphere Message Broker.

A Mensagem de Entrada CWF

A mensagem de cliente Vídeo no formato físico CWF é mostrada abaixo (observe que você pode precisar rolar para a direita para ver toda a mensagem):

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

O formato de ligação personalizado não utiliza marcações. 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. Segue abaixo a aparência que a mensagem de cliente Vídeo teria no formato de ligação personalizado se os campos fossem separados em linhas diferentes 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 de cliente Vídeo é apresentada em XML da seguinte forma:

<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

A mensagem de cliente Vídeo no formato TDS é mostrada abaixo (os dados foram divididos em linhas separadas para legibilidade):

{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 utilizando marcações e delimitadores nas próprias mensagens. A mensagem CWF, contudo, não contém marcações nem delimitadores e, por isso, a opção precisa ser resolvida utilizando 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ó subseqüente 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 utilizado: P, D ou C. Na árvore de mensagens, esse campo vem antes do campo de opção IdGroup. Isso significa que o valor do campo ID pode ser analisado antes que haja 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 workbench, você pode explorar as propriedades dos elementos no modelo de mensagem Vídeo. O que você vê no workbench corresponde à figura da estrutura de mensagem acima. Por exemplo, para explorar o elemento Name:

  1. Alterne para a perspectiva Desenvolvimento de Aplicativos do Intermediário.
  2. Na visualização Navegador de Recurso, dê um clique duplo em Customer.mxsd.
  3. Na visualização Tópicos, clique em Tipos.
  4. No editor Message Definition, expanda o tipo denominado NameType.
  5. Clique em um dos elementos (Title, FirstName e LastName) exibidos abaixo de 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.

Ícone Página Principal   Voltar para Home da Amostra