Alguma alternativa viável ao WCF e WSDL para endpoints de integração?

Question

Meu empregador é um fornecedor de software para um mercado específico. Nossos clientes integram nosso sistema a outras pessoas usando serviços da Web. Usamos a tecnologia Microsoft e nossos serviços da Web são implementados no ASP.NET e WCF.

Chegou a hora de revisar nosso conjunto atual de serviços e criar padrões da empresa para futuras integrações. Estou lendo "Padrões de integração corporativa" e também tenho procurado um pouco no NServiceBus e no Mass Transit. Isso pode simplificar questões como versão contratual e testes de unidade, mas parecem ser mais úteis para fornecer um barramento de serviço interno, não para expor serviços a clientes externos.

Nossos clientes estão em muitas plataformas diferentes e exigem que nossos serviços sejam compatíveis com padrões. Isso pode significar coisas diferentes para pessoas diferentes, mas acho que é seguro supor que elas desejam acessar os serviços da Web descritos com o WSDL.

Nesse cenário, o WCF é o caminho a seguir?

Answer 1

O WCF é de longe a pilha mais compatível com os padrões da plataforma Microsoft. O bom é que é muito flexível para diferentes clientes "fora da caixa" e, se há coisas que causam tristeza, a maioria deles pode ser alterada por meio de comportamentos personalizados sem muitos problemas.

Answer 2

Uma alternativa que eu normalmente recomendo é a integração sobre AMQP entre seus corretores de mensagem. Isso foi que você pode usar o paradigma de push em vez da pesquisa (que é muito poderosa e escalável em comparação)!

Você configurou seu próprio corretor, como o RabbitMQ, localmente. Então você deixaria seu parceiro de integração configurar um. (Fácil: Basta baixá -lo).

Se seu parceiro estiver integrando do mesmo data center, você seria salvo para assumir poucos divisão de rede - o que significa que você poderia Compartilhe o corretor. Por outro lado, se você estiver em redes diferentes, pode configurar o corretor dentro Modo da Federação. (Corre rabbitmq-plugins enable rabbitmq_federation e ponto para o outro corretor)

Agora você pode usar o EG Masstransit:

ServiceBusFactory.New(sbc =>
{
    sbc.UseRabbitMqRouting();
    sbc.ReceiveFrom("rabbitmq://rabbitmq.mydomain.local/myvhost/myapplication");
    // sbc.Subscribe( s => s ... );
});

, como você faria quando não estiver fazendo nenhuma integração.

Se você olhar para http: //rabbitmq.mydomain.local: 55672/ Agora você encontrará a interface de administração para o RabbitMQ. O MassTransit cria uma troca para cada tipo de mensagem (enviar uma mensagem para essa bolsa irá abanar todos os assinantes), no qual você pode colocar as regras de autorização.

As regras de autorização podem estar na forma de regex por usuário ou podem ser integradas ao LDAP. Consulte a documentação para isso.

Você também precisaria do SSL no caso de estar analisando o WAN e não tem um túnel IPSec - essa documentação está aqui: http://www.rabbitmq.com/ssl.html E você habilita É assim.

É isso! Apreciar!

Post Scriptum: Se você está se sentindo atualizado para uma aventura que o ajudará a gerenciar toda a sua infraestrutura como um efeito colateral, pode dar uma olhada fantoche. O Puppet é um gerente de provisionista e configuração de servidores; Nesse caso, você estaria interessado em configurar o SSL com o Puppet. Primeiro, encomende um certificado de subdomínio de curinga para o seu domínio e depois use esse cert para assinar outros certificados: você pode delegar isso - consulte o Guia do RabbitMQ, onde afirma "agora podemos gerar a chave e os certificados que nossa autoridade de certificado de teste usará . " - Gere uma solicitação de assinatura de certificado para o certificado em vez de criar uma nova autoridade - e deixe o RMQ use -o para SSL - será válido para a Internet.