O Intermediário Implementa uma Interface de Serviço da Web Existente - Detalhe

Esta é uma visão geral de um cenário típico de ponta a ponta em que você tem um cliente de serviço da Web e deseja que o intermediário disponibilize alguma funcionalidade existente que não seja de serviço da Web para ele.

Um sistema baseado em C ou Cobol existente oferece alguma lógica de negócios que pode ser exposta de forma útil como um serviço da Web.

Como no exemplo anterior (O Intermediário Implementa um Novo Serviço da Web - Detalhe), existe algum mecanismo para que o intermediário chame operações no sistema existente (ex. o sistema expõe uma interface para o intermediário). Geralmente, o sistema existente seria ativado para o WebSphere MQ, significando que ele recebe mensagens do MQ contendo dados do aplicativo, despacha-as para a implementação subjacente e, em seguida, compacta os valores de retorno como uma resposta do MQ. As estruturas de dados fornecidas e retornadas por estas operações existentes estão definidas em um arquivo de cabeçalho C ou copybook COBOL.

No entanto, neste exemplo, também existe uma restrição de como deve ser o aspecto do serviço da Web, ou seja, já temos a definição WSDL para o cliente de serviços da Web.

Um cenário possível seria que um cliente de serviços da Web amplamente distribuído já forneça acesso a usuários a uma capacidade de negócios específica e a função do intermediário será oferecer a mesma interface para uma nova implementação, com base no sistema existente. Talvez o provedor de serviços da Web original ofereça uma qualidade de serviço diferente ou seja descontinuado por alguma razão.

Como anteriormente, o intermediário pode chamar a função do sistema existente utilizando o WebSphere MQ.

Para implementar o cenário:

  1. Importe as estruturas de dados da API existentes - por exemplo, utilizando o importador C. Se o WSDL de estilo de documento for utilizado, será necessário fazer o importador criar os elementos globais requeridos no modelo do intermediário. O WS-I (consulte http://www.ws-i.org/) recomenda que a carga útil do serviço da Web seja qualificada pelo espaço de nomes, portanto, o usuário deve especificar o espaço de nomes de destino na importação.

    Neste estágio, você tem um modelo de mensagem para os dados a serem utilizados ao chamar as operações existentes.

  2. Importe o arquivo WSDL existente para criar um modelo de mensagem apropriado para dos documentos da instância esperados (consulte Importando Estruturas de Dados). O fluxo analisará o pedido SOAP correspondente e precisará transformar em e a partir do formato de dados existente. É possível inspecionar as definições de mensagem importadas e utilizar os editores ESQL e/ou de Mapeamento para ajudar a criar o fluxo. Você não cria arquivos de categoria ou gera WSDL a partir do modelo do intermediário.
  3. A etapa de importação de WSDL resultará na inclusão automática do SOAP mxsds no conjunto de mensagens. Especificamente, isto inclui o envelope SOAP mxsd e - se necessária - a codificação SOAP mxsd.
  4. Implemente um fluxo de mensagens para receber o pedido de serviço da Web, ou seja, para agir como o provedor de serviços da Web. Os nós do nó de extremidade são HTTP ou MQ, dependendo do transporte utilizado pelo cliente. As propriedades do nó input são:
    • domínio: "MRM"
    • conjunto: o conjunto de mensagens que contém a definição de Envelope SOAP
    • tipo: "Envelope"
    • formato "XML1"
  5. Quando chamado pelo fluxo, o analisador cria uma árvore lógica que inclui o envelope SOAP conforme definido pelo SOAP mxsd pré-gravado. A análise continua automaticamente nos pontos de conexão no envelope SOAP (corpo e cabeçalho SOAP), tentando a correspondência com outras definições de mensagem no conjunto de mensagens. Aplique a validação no nó input, se necessário.

    Neste estágio, você tem uma árvore lógica, mas não sabe qual carga útil SOAP foi recebida. Você pode verificar o campo HTTP SOAPAction/action para determinar o provável conteúdo, mas isto funciona apenas para HTTP. (A utilização de SOAPAction não é recomendada pelo WS-I).

  6. Você pode fornecer mapeamento único das mensagens de carga útil permitidas para as mensagens requeridas do sistema existente. Por exemplo, uma única definição de mapeamento pode mapear mensagens message1a e message1b para o mesmo destino message2.
    Como alternativa, podem ser fornecidos mapeamentos separados para cada tipo de mensagem - ou para grupos de tipos de mensagem relacionados. Esta abordagem pode resultar em definições de mapeamento mais gerenciáveis e reutilizáveis. A desvantagem é que o usuário precisa determinar qual carga útil ele recebeu antes de aplicar o mapeamento. Isto pode ser feito no ESQL da seguinte forma:
     
     DECLARE SOAPENV NAMESPACE 'http://schemas.xmlsoap.org/soap/envelope/';
     SET contentType = FIELDNAME(InputBody.SOAPENV:Body.*[<]);
     IF (contentType = ‘foo’) ...
     
    ou utilizando uma referência de campo, por exemplo:
     
     DECLARE R REFERENCE TO InputRoot.MRM.SOAPENV:Body.*[<];
     IF (FIELDNAME(R) = “foo”) ...
     
    Quando o conteúdo é conhecido, o fluxo pode ser ramificado corretamente (ex. RouteToLabel) com cada ramificação tendo o Mapeamento específico de conteúdo e/ou de nós Compute. Para fluxos simples, toda a lógica pode ser mantida em um único nó Compute, se necessário.

    Agora chame o sistema existente (geralmente utilizando o WebSphere MQ), recupere qualquer resposta esperada e propague a resposta do serviço da Web. Isso é semelhante ao cenário anterior (O Intermediário Implementa um Novo Serviço da Web - Detalhe), exceto que o fluxo de dados também deve ser mapeado entre o formato de dados utilizado pelo cliente de serviço da Web e o formato utilizado pelo sistema existente ativado para WebSphere MQ. O designer do fluxo de dados deve considerar a possibilidade de que o aplicativo de negócios não envie a resposta esperada dentro de um período de tempo aceitável.

Conceitos relacionados
Serviços da Web, WSDL e Fluxos de Mensagens
O Intermediário Chama um Serviço da Web Existente
O Intermediário Implementa uma Nova Interface de Serviço da Web
O Intermediário Implementa uma Interface de Serviço da Web Existente
O Intermediário Implementa Interface Não do Serviço da Web para Novo Serviço da Web
Tarefas relacionadas
O Intermediário Implementa uma Interface de Serviço da Web Existente - Detalhe
O Intermediário Chama um Serviço da Web Existente - Detalhe
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback
Direitos Autorais IBM Corporation 1999, 2006 Última Atualização: 1 Sep 2006
ac34580_