Enterprise Integration–Uma introdução aos Sistemas distribuídos e o Microsoft Integration

Enterprise Integration & SOA

EICAPAEm Enterprise Integration, consideramos sistemas distribuídos uma aplicação que está disponível em múltiplos nós. Na visão do Microsoft Integration, chamamos isto de Connected System (Sistemas Conectados). Hoje a visão de Integração da Microsoft é proporcionar conectividade corporativa de qualquer lugar, para qualquer dispositivo.

Neste post vamos olhar a visão da Microsoft sobre sistemas distribuídos e tecnologias de integração do início aos dias atuais.


 

Uma introdução aos Sistemas Distribuídos

Observe a imagem abaixo:

IMG01

Temos uma aplicação distribuída em 3 máquinas. Cada máquina executa parte da lógica. Sendo assim cada máquina trabalha em conjunto para executar a funcionalidade geral dos negócios.

Isso implica que essas máquinas devem se comunicar umas com as outras, trafegando informações, utilizando algum protocolo de rede.

IMG02

Esta é a essência dos sistemas distribuídos: Uma aplicação implementada em várias máquinas com ênfase nos protocolos de comunicação, muitas vezes se utilizando de inúmeras estruturas de comunicação.

 

Sistemas Distribuídos e o Microsoft Integration

A primeira forma de se construir sistemas distribuídos nas tecnologias Microsoft foi em 1993 com o DCOM e COM+ que focaram nas transações distribuídas. O DCOM [Distributed Component Object Model] e o COM+ [Component Object Model plus] foram utilizados para a criação de componentes, em uma forma independente de linguagem de programação para se implementar objetos de tal forma que eles possam ser utilizados em ambientes diferentes ao qual foram criados, mesmo entre diferentes máquinas e arquiteturas.

Alguns anos passados e houve o lançamento do .NET 1.0, o que não descontinuou o modelo COM. O que ocorreu de fato foi que a Microsoft os encapsulou em um wrapper lhe dando o nome de Enterprise Services.

Outra tecnologia focada na integração foi o .NET Remoting, que é semelhante ao DCOM, sendo orientado a componentes, porém utilizando RPC para comunicação remota em código gerenciado, onde os componentes são executados em um ambiente CLR. Como resultado o .NET Remoting se tornou muito mais simples e altamente extensível.

O próximo grande nome desta lista é o MSMQ (Microsoft Message Queuing). Ao contrário dos modelos anteriores focados em componentes ou RPC, o MSMQ é focado puramente em mensagens. Sendo assim ele permite a comunicação entre dois nós de um sistema de forma confiável e assíncrona. Mesmo assim ainda temos como dependência o fato de que você terá que ter a infra-estrutura MSMQ instalada em cada máquina que irá participar desse estilo de comunicação.

SpaghettiEstes foram os principais frameworks de integração no passado. Todos focados em comunicação, porém com características distintas. Em uma aplicação é possível vários modelos de comunicação, porém isso gera um problema. Cada um destes modelos citados possui um estilo de implementação único, o que vai gerar muito mais trabalho e necessidade de conhecimentos específicos, sem falar nas aplicações não gerenciáveis ​​devido ao famoso dilema da "integração spaghetti". Outro problema é que no caso dos frameworks citados, ficamos restringidos ao ambiente Windows, o que no cenário atual os tornaria inviáveis.

 

Estilos de Integração

Integração é a chave para aplicações B2B (business-to-business) e cenários de arquitetura orientada a serviços (SOA). Aplicações, funções e serviços precisam trocar dados, a fim de participar de processos de negócios.

Como já vimos, nos primeiros dias, a integração era feita basicamente através da criação de conexões peer-to-peer entre as aplicações utilizando banco de dados compartilhado ou troca de arquivos de importação/exportação de propriedades. Porém com o tempo foram desenvolvidos alguns estilos arquiteturais para integração de sistemas. Neste post vou tratar apenas dos cenários clássicos, e em um post futuro quero abordar sobre o futuro do Integration junto a Cloud Computing. Por enquanto vamos ao que interessa:

 

IMG06

Em relação a história, temos um primeiro estilo arquitetural chamada Point to point, posteriormente conhecida como "Integração Spaghetti". Neste caso, para cada tipo de comunicação entre sistemas existe um tipo dedicado de conexão. Este tipo de padrão não faz uso de padronizações, seja de formatos, mensagens ou dados. O nome Spagehetti é uma referência ao desenho que estas arquiteturas formam.

 

IMG07

O segundo estilo arquitetural é o chamado Integration Broker. Este estilo faz uso de um componente EAI (Enterprise Application Integration), para a padronização da conexão entre os sistemas. Isso é possível dado o uso de adaptadores, schemas de mensagens, formatos específicos de dados fora os padrões de subscrição e publicação de mensagens.

 

IMG08

O terceiro estilo "clássico" é o Enterprise Service Bus (ESB), ou barramento corporativo de serviços. Neste modelo o desacoplamento é ainda maior já que temos a possibilidade de uma composição dinâmica de serviços, enquanto no EAI temos links estáticos entre os clientes e os provedores. Isso é possível dados um conjunto de patterns de roteamento e composição de mensagens, tratamentos de exceções e resolução de chamadas.

 

Microsoft Integration e a convergência aos serviços

O cenário de desenvolvimento atual exige cada vez mais da liberdade advinda da interoperabilidade. Dado o número de plataformas, linguagens e dispositivos, não é mais aceitável implementações presas a dependências de ambiente.

Considere o cenário descrito na imagem abaixo:

IMG03

Temos uma aplicação que está distribuída em 3 nós, cada um deles executando uma diferente plataforma e linguagem. O maior desafio neste cenário de integração é a interoperabilidade.

Agora, como faço para conseguir conectar estes diferentes nós se eles não se entendem? Utilizar as estruturas de comunicação conhecidas e citadas anteriormente não resolvem nosso caso, já que, para isso seria necessário que todas as máquinas dos nós fossem Windows. Este problema foi resolvido com a utilização dos serviços.

IMG05

Você pode entender um serviço apenas como uma funcionalidade exposta ao mundo exterior através de mensagens. Com isso é possível implementar serviços para cada um dos nós e expor as funcionalidades de cada um dos serviços para os demais sistemas conectados.

Agora, a forma de realizar esta interoperabilidade é por implementação de mensagens, utilizando protocolos e formatos de mensagem padrão. Por exemplo, uma das escolhas mais comuns de transporte é o HTTP, por causa de sua onipresença difundida em todo na web hoje. As principais plataformas já suportam os protocolos de comunicação, a fim de que seja possível a comunicação entre os serviços.

Falando em serviço, hoje temos duas principais abordagens ou filosofias de desing: SOAP (Simple Object Access Protocol) e REST (Representational State Transfer). A primeira com todas as suas especificações WS-* e a segunda focada na interoperabilidade, e que é fundamentalmente diferente do modelo SOAP.

 

Conclusão

Este post é uma introdução ao assunto da integração. Fundamental aos arquitetos e desenvolvedores que precisam lidar com cenários enterprise, SOA ou que simplesmente querem aprender sobre as possiblidades de cenários existentes hoje. No próximo post estarei falando das tecnologias envolvidas na construção do chamado Microsoft Integration. O nome do post será: Enterprise Integration–Tecnologias e serviços do Microsoft Integration.

 

Referências

Component Object Model

Message Queuing (MSMQ)

WCF - Windows Communication Foundation

ASP.NET Web API

 

Bons estudos e até a próxima pessoal  ;)


Author's profile picture

Vitor is a computer scientist who is passionate about creating software that will positively change the world we live in.

MVP Azure - Cloud Architect - Data science enthusiast


8 minutes to read