Entrega Garantida para Serviços da Web B2B: Padrão de Uso Ponto a Ponto
Neste padrão, um fabricante vende seus produtos por meio de uma rede de revendedores afiliados. Esse fabricante iniciou um projeto piloto para aprimorar a integração de TI entre sua própria organização de varejo e meia dúzia dos maiores e mais importantes revendedores.
A Solução Técnica Existente
Historicamente, o "e-commerce" de relações comerciais entre empresas é conduzido utilizando-se o Electronic Data Interchange (EDI). O EDI é um conjunto de padrões para o conteúdo e a formatação de mensagens de relações comerciais entre empresas. Para obter exemplos sobre esses padrões e mensagens, consulteUnited Nations Directories for Electronic Data Interchange.
Se as identidades de parceiros de comunicação forem conhecidas e inalteradas, o uso de definições de mensagem de padrão de mercado não será estritamente necessário. Embora outros padrões com base em XML estejam disponíveis para a condução de e-commerce de relações comerciais entre empresas (como as especificações OASIS Electronic Business using eXtensible Markup Language (ebXML)), o fabricante decidiu investigar o uso das tecnologias de serviços da Web e está usando documentos WSDL a partir de uma variedade de fontes para definir as interfaces de serviço.
As interações entre o fabricante e seus revendedores para o projeto piloto inicial estão em duas categorias:
- Pedidos de informação. A interação é bidirecional, ou seja, uma mensagem de pedido é enviada solicitando algumas informações e uma mensagem de resposta é enviada na direção oposta contendo as informações do pedido. Um exemplo de um pedido de informações de um revendedor para o fabricante pode ser "getOrderStatus".
- Pedidos de atualização. Essas interações são unidirecionais, ou seja, o emissor de um pedido de atualização não depende de uma resposta para continuar com outro trabalho. Um exemplo de um pedido de atualização de um revendedor para um fabricante pode ser "placeOrder". Um exemplo de um pedido de atualização de um fabricante para um fornecedor pode ser "deliveryConfirmed".
O fabricante usa o WebSphere Application Server para implementar pedidos para informações usando SOAP por meio de HTTP e SOAP por meio de JMS. Os revendedores são livres para escolher sua própria tecnologia de implementação; eles não têm que utilizar o WebSphere Application Server.
O fabricante implementa pedidos de atualização de duas maneiras diferentes:
- Usando SOAP em HTTP. Nesse caso, o serviço é representado como uma interação de pedido e resposta que é considerada bem-sucedida quando o solicitante recebe uma resposta com sucesso. Os serviços têm que ser implementados para detectar e responder com sucesso os pedidos duplicados (isso é denominado operação idempotente), e o cliente tem que ser implementado para tentar novamente, se a comunicação for interrompida depois do envio do pedido, mas antes do recebimento da resposta.
- Para evitar as limitações acima, o fabricante também usa o SOAP sobre JMS para suporte a partir do WebSphere Application Server e do WebSphere MQ. Nesse caso, o pedido é representado como um serviço unidirecional, e as mensagens são entregues de maneira confiável. O fabricante utiliza o WebSphere MQ como Provedor JMS e torna essa solução disponível a todos os revendedores que também utilizam o WebSphere Application Server e o WebSphere MQ. Não é necessário que o revendedor e o fabricante estejam conectados para que a mensagem seja enviada.
As mensagens são transmitidas por uma Rede Privada Virtual para garantir a integridade e a confidencialidade de mensagens transmitidas entre os dois negócios e como parte do estabelecimento da identidade do emissor.
O Problema do Negócio
Embora o fabricante e seus fornecedores estejam satisfeitos com a implementação dos serviços de pedido de informação, há vários problemas no caso do pedido de atualização:
- Usando SOAP em HTTP:
- Para o fabricante, a implementação de serviços idempotentes é complicada e, portanto, mais dispendiosa para o desenvolvedor. Ela aumenta a probabilidade de erros de codificação, reduzindo a robustez da solução e a introdução de possibilidade de pedidos dispendiosos descartados ou duplicados.
- Para revendedores, a implementação da lógica de nova tentativa também é complexa, cada e propensa a erro.
- Para o fabricante e os revendedores, o requisito para ambos estarem disponíveis para chamar o serviço é um problema. Em particular, muitos revendedores não mantêm seus sistemas disponíveis sete dias por semana, visto que os fins de semana são o período ideal para fornecer atualizações de preço aos revendedores. Da mesma maneira, a impossibilidade de fazer pedidos quando a conectividade entre o fornecedor e o fabricante está indisponível é um problema de negócio real.
- Usando SOAP em JMS:
- Embora a exigência do uso do WebSphere Application Server e WebSphere MQ seja aceitável para o conjunto atual de revendedores, à medida que o projeto expande,pode haver outros parceiros que não queiram ou não consigam utilizar uma plataforma de software comum.
A Solução ao Usar WS-ReliableMessaging
Com o suporte do WS-ReliableMessaging no WebSphere Application Server, o fabricante pode substituir suas soluções de nova tentativa customizada existentes para o sistema de mensagens unidirecional confiável pelo sistema de mensagens unidirecional padrão SOAP em HTTP. A remoção da lógica de nova tentativa do aplicativo simplifica o código do aplicativo, permitindo o desenvolvimento de aplicativo de maneira mais simples e mais rápida.
Com o WS-ReliableMessaging, o fornecedor e o fabricante não precisam estar conectados para que a mensagem seja enviada.
O padrão WS-ReliableMessaging inclui confiabilidade ao sistema de mensagens SOAP em HTTP, reduzindo a necessidade de utilizar SOAP em JMS.
Como o WS-ReliableMessaging com SOAP em HTTP é um padrão interoperável, a rede de revendedores não precisa usar uma plataforma de software comum.