SMOs (Service Message Objects) são SDOs (Service Data Objects) aprimorados. O SMO fornece uma camada de abstração para processamento e manipulação de mensagens trocadas entre serviços.
Todas essas informações são acessadas como DataObjects SDO, e existe uma declaração de esquema que especifica a estrutura geral do SMO. O esquema é gerado pelo WebSphere Integration Developer.
Todos os SMOs possuem a mesma estrutura básica. A estrutura consiste em um objeto de dados de raiz chamado ServiceMessageObject, que contém outros objetos de dados representando os dados do cabeçalho, corpo e contexto. O corpo do SMO contém a carga útil da mensagem. Os cabeçalhos contêm informações originadas de uma ligação de importação ou exportação específica. Por exemplo, uma Ligação JMS.
O SMO oferece uma interface para acessar e modificar os cabeçalhos e as cargas úteis das mensagens. Ele pode representar o conteúdo lógico de muitos tipos diferentes de mensagem.
O WebSphere Process Server opera em mensagens que estão a caminho entre nós de extremidade de interação. Dentro do WebSphere Process Server, os fluxos de mediação processam mensagens como SMOs.
Para fornecer roteamento dinâmico, os terminais de interação podem ser consultados através do WSRR (Websphere Service Registry and Repository): o resultado da consulta do WSRR é armazenado no SMO.
O WebSphere Process Server cria objetos SMO, que ficam então disponíveis para os fluxos de mediação.
Ao criar fluxos de mediação, o WebSphere Integration Developer especifica o tipo de corpo da mensagem para cada terminal (entrada, saída ou falha) e, opcionalmente, o tipo de informações de contexto. O WebSphere Process Server utiliza estas informações para converter as mensagens em objetos SMO do tipo especificado.
O elemento control contém os campos Encoding, CodedCharSetId e Format que descrevem o corpo da mensagem. Se a mensagem do WebSphere MQ contiver algum cabeçalho de mensagem (por exemplo, MQRFH2), os campos Encoding, CodedCharSetId e Format que descrevem o cabeçalho serão transportados para o elemento header.
O elemento header contém os campos Encoding, CodedCharSetId e Format que descrevem o cabeçalho. O campo Format, em particular, deve ser configurado corretamente (por exemplo, MQHRF2 para um cabeçalho MQRFH2); e os campos CodedCharSetId e Encoding são importantes para dados obscuros. Quando são apresentadas como uma mensagem do WebSphere MQ, essas informações de formato são gravadas no cabeçalho MQ anterior (ou no MQMD se não houver cabeçalho anterior).
O elemento header também contém subelementos (rfh e rfh2) para cada um dos cabeçalhos modelados; um subelemento (opaque) para cabeçalhos MQ padrão não-modelados; e um subelemento (value) para cabeçalhos MQ fornecidos pelo usuário. Precisamente um desses quatro elementos deve ser configurado: seria um erro ter mais de um deles configurados em qualquer elemento de cabeçalho. O subelemento value armazena a estrutura utilizada pela ligação de dados do cabeçalho fornecido pelo usuário; os outros três elementos (rfh, rfh2 e opaque) são descritos nas seções seguintes.
Um cabeçalho RFH do WebSphere MQ contém uma cadeia de pares nome-valor, em que cada nome e cada valor é simplesmente uma cadeia de texto. Isso é representado, no SMO, como um elemento de propriedade repetido, contendo um elemento de nome e de valor.
Um cabeçalho RFH2 do WebSphere MQ contém zero ou mais pastas, cada uma contendo uma seqüência de propriedades e grupos. Uma propriedade tem um nome, um tipo opcional e um valor (todos representados como string). Um grupo tem um nome e contém uma seqüência de propriedades e grupos. A representação SMO de um cabeçalho RFH2 também contém um elemento NameValueCCSID, que determina o CCSID utilizado para codificar as pastas na mensagem do WebSphere MQ.
O elemento opaque representa qualquer cabeçalho do WebSphere MQ de estrutura padrão. Os campos comuns a todos esses cabeçalhos (StrucId, Version e Flags) são representados como elementos. Existe também um elemento data que contém a parte não-modelada do cabeçalho como dados hexBinary. Quando se utiliza o elemento opaque, normalmente é importante manter os valores Encoding e CodedCharSetId corretos com o cabeçalho para evitar a distorção dos dados.
Os campos de cabeçalho do WebSphere MQ são definidos utilizando o mesmo conjunto de tipos utilizado pelo WebSphere MQ em si. Os campos MQLONG são representados como int; campos MQBYTEnn como dados hexBinary limitados a nn no comprimento; e os campos MQCHARnn como dados string limitados a nn caracteres de comprimento.
(c) Copyright IBM Corporation 2005, 2006.
Este centro de informações é desenvolvido em tecnologia Eclipse (http://www.eclipse.org)