Markus Christen
Junho 2009
Conteúdo
.gif)
Introdução
Curta introdução ao SOA
Introdução ao “Enterprise Service
Bus”
Serviços disponíveis no “BizTalk ESB
Toolkit 2.0”
Serviço de Resolução
Serviço de Tratamento de Exceções
Serviço de Transformação
Serviço de Roteamento Dinâmico
Serviço de Monitoramento
Considerações Finais
Artigos e Blogs relevantes sobre o
tema
Agradecimentos
Sobre o Autor
Introdução
Uma das
principais tendências na construção de uma Infraestrutura Orientada a Serviços
(Service Oriented Infrastructure, ou
SOI) é a implementação de um barramento corporativo de serviços (“ESB” ou Enterprise Service Bus). Na linha da
evolução das tecnologias, podemos considerar um barramento corporativo de
serviços como uma extensão da arquitetura de integração de aplicações, porém,
de forma desacoplada.
Ao longo
dos anos, a chegada da arquitetura orientada a serviços mudou os requisitos da
infraestrutura para integração de aplicações. De uma arquitetura altamente
acoplada, os sistemas iniciaram uma mudança em direção a uma arquitetura
desacoplada entre o consumidor e o provedor.
Desde o
começo das iniciativas da Arquitetura Orientada a Serviços (Service Oriented Architecture,
ou SOA) foram especificadas várias definições do papel e responsabilidades de
um barramento corporativo de serviços. Os motivos da criação de diferentes
abordagens é a existência de definições relacionadas à grande diversidade de
produtos disponíveis no mercado. Nesse contexto, vários fabricantes realizaram
propostas distintas para a solução de cenários diversos, definindo para cada
cenário quais as capacidades que devem ser oferecidas e como elas devem ser
implementadas.
Apesar
desta diversidade, podemos destacar cinco
funcionalidades comuns e essenciais no SOA que contribuem para que uma solução
corporativa possa registrar ou consumir serviços heterogêneos, baseados numa
arquitetura/infraestrutura padronizada. São eles:
- Serviço de Conectividade
- Serviço de Transformação
- Serviço de Roteamento Dinâmico
- Serviço de Tratamento de Exceções
- Serviço de Monitoramento
De fato, estes serviços compõem o conjunto de
capacidades básicas de um barramento corporativo de serviços, ou “Enterprise
Service Bus”.
O uso ou não de um barramento corporativo de serviços
também está incluído na discussão de qual seria a infraestrutura adequada para
um ambiente SOA. O mercado talvez esteja transmitindo a impressão ou a expectativa
que tanto o uso de um “ESB”
quanto o próprio uso do SOA/SOI é apropriado para qualquer tipo de sistema
distribuído. Porém, deve-se considerar que, embora o uso de serviços possa
oferecer um alto grau de reuso, desacoplamento e agilidade, eles também podem
ter um impacto negativo no desempenho da solução devido à latência, excesso de
comunicação ou outro problema advindo da estrutura e composição dos serviços de
uma solução. Desta forma, é importante avaliar a real necessidade e o impacto
da utilização de um “ESB” na
arquitetura de aplicações corporativas distribuídas. A questão não é se a
arquitetura SOA/SOI por si só está certa ou errada, mas sim se os processos de
negócio da sua empresa são adequados para serem implementados através desta
arquitetura. Reusabilidade versus desempenho, latência versus agilidade - estas
são algumas questões que precisam ser respondidas antes de colocar qualquer
serviço em um barramento corporativo. O barramento corporativo não pode ser considerado a “bala de prata” do novo
século para aplicações distribuídas. Mas pode ser uma infraestrutura eficiente
e de alta produtividade a ser utilizada no contexto correto.
O desempenho de um
barramento corporativo de serviços não é unicamente relacionado com a
arquitetura do barramento. Muitos fatores precisam ser considerados e para
evitar este desafio, é importante responder antes as seguintes questões:
- Qual o
grau de granularidade na composição dos serviços?
- Qual é a
latência máxima aceitável para os serviços?
- Qual é a
arquitetura da Segurança dos serviços?
- Qual é a
arquitetura que viabiliza o gerenciamento destes serviços?
- Qual é o
grau da distribuição dos serviços?
No SOA/SOI visamos
principalmente a composição de serviços, onde uma solução pode consumir
serviços locais ou distribuídos através de um barramento corporativo de
serviços. Neste contexto, a Microsoft oferece vários produtos que fornecem as
capacidades necessárias para criar uma infraestrutura orientada a serviços,
facilitando a publicação, a transformação de mensagens e a governança de
soluções corporativas.
Este artigo apresenta
o barramento corporativo de serviços sobre a plataforma Microsoft que hoje é
baseado no BizTalk Server 2009 em conjunto com o pacote de software aberto
chamado “BizTalk ESB Toolkit 2.0”
IMPORTANTE: Lembrando
que foi anunciado durante o TechEd 2009
a mudança do nome de “Enterprise Service Bus Guidance 2.0” para Microsoft BizTalk ESB Toolkit 2.0
.gif)
Início da página
Curta introdução ao
SOA
Encontrar uma definição exata sobre SOA é uma tarefa
difícil. Uma definição simples e orientada ao mundo real seria: “Um estilo de arquitetura onde
funcionalidades de aplicações de negócio existentes são disponibilizadas e
publicadas na forma de serviços heterogêneos compostos". A próxima
pergunta seria “o que é um serviço”: “Os
serviços são componentes de software que expõem funcionalidades de aplicações
numa arquitetura SOA, respeitando algumas características importantes”, que
são seguintes:
- Serviços são autônomos
- Serviços são orientados a
mensagens
- Serviços podem suportar
diferentes protocolos e mecanismos de transporte
- Serviços podem ser
publicados ou hospedados em diferentes tipos de hospedeiros distribuídos
Tendo como base esta definição, fica claro que uma infraestrutura
que facilite o desacoplamento através da troca de mensagens e a transformação
destas de acordo com cada aplicação destino é uma infraestrutura comum e
importante para a arquitetura corporativa da TI de uma empresa – e esta é a
missão do “Enterprise Service Bus”.
Introdução ao
“Enterprise Service Bus”
Neste contexto, nós podemos considerar que o “Enterprise Service Bus” é o
coração da infraestrutura orientada a serviços (SOI), pois ele oferece as
capacidades que permitem criar ambientes distribuídos desacoplados. Para ter um
ambiente efetivo de SOA corporativo você precisa de um “Backbone”, onde você pode invocar os serviços. Esta capacidade possibilita o consumo dos serviços
disponibilizados pelo “Enterprise
Service Bus”, incluindo várias tarefas consideradas essenciais,
sem necessidade de conhecer o contexto detalhado do provedor. As capacidades
consideradas essenciais para um barramento de serviço corporativo (ESB) são:
- Resolução de Descrições de Serviços
- Transformação de Mensagens
- Roteamento Dinâmico de Mensagens
(Serviço de conectividade)
- Tratamento de Exceções
- Monitoramento de Mensagens
No caso
da Microsoft, o “Enterprise
Service Bus” é hoje disponibilizado pela dupla BizTalk 2009 e o “BizTalk ESB Toolkit 2.0”. Enquanto o
BizTalk oferece a infraestrutura básica para a troca de mensagens, o “BizTalk ESB Toolkit 2.0” fornece um
conjunto variado de serviços em cima do BizTalk que o complementa para garantir
a lista completa de capacidades de um “Enterprise Service Bus”. Juntos eles proporcionam um barramento corporativo
de serviços flexível e genérico.
É
importante compreender que o pacote “BizTalk
ESB Toolkit 2.0” não é um produto por si só, mas sim uma oferta composta
por um conjunto de serviços, componentes e padrões que estendem os recursos
existentes do servidor BizTalk. Você pode encontrá-lo disponível no site
Codeplex da Microsoft (
www.codeplex.com/esb
).
Semelhante
ao servidor BizTalk, você não precisará usar todas as capacidades deste pacote.
Ao invés disso, você pode escolher os componentes e serviços que resolvem o seu
problema específico. Por exemplo, você poderá aplicar o serviço de
transformação caso deseje reutilizar mapas de clientes BizTalk ou usar o
serviço de exceções se você quiser uma maneira uniforme para publicar, capturar
e gerar relatórios sobre exceções geradas pelas aplicações.
Neste artigo, discutiremos
este conjunto e analisaremos os seus principais componentes do ponto de vista
conceitual.
Por fim, alertamos que nem todos os aspectos necessários de governança para um
“Enterprise Service Bus” são cobertos
pelo “BizTalk ESB Toolkit 2.0”.
Produtos de terceiros como, SOA Governance (
www.soa.com
) e AmberPoint (www.amberpoint.com)
podem ser relevantes para complementar uma arquitetura SOA/SOI.
Início da página
Serviços disponíveis
no “BizTalk ESB Toolkit 2.0”
No decorrer deste
artigo, vamos examinar alguns dos aspectos essenciais do “BizTalk ESB Toolkit 2.0”, que contém uma série de serviços para
usufruir das funcionalidades do BizTalk em uma camada mais abstrata e
reutilizável. Os serviços considerados mais relevantes são:
1. Resolução de Descrições de Serviços:
“Serviço de Resolução”
Usado para descobrir um ou mais serviços conforme cadastrado nos registros
disponibilizados em repositórios de serviços como o “Universal Description
Discovery Integration”, “SQL”, “Business Rule Engine”, “WS-MEX” ou registros
estáticos e retornar os metadados conhecidos sobre os serviços cadastrados.
Resumindo, podemos concluir que este serviço disponibiliza um conjunto de
serviços para uso no roteamento dinâmico - que é considerado como o principal
serviço de um barramento corporativo de serviços.
2. Tratamento de Exceções: “Serviço de
Tratamento de Exceções”
Provê um conjunto rico de capacidades para a gestão de exceções, incluindo
interfaces disponibilizadas como Web Services permitindo, por exemplo,
centralizar as exceções advindas de processos distintos em um banco de dados
centralizado. Ele oferece também a capacidade de tratamento de erros
automatizado, disparando processos de correção e monitoração com base nos tipos
de erros detectados.
3. Transformação de Mensagens: “Serviço de
Transformação”
Disponibiliza uma interface para executar transformações de uma mensagem de
entrada para um novo formato, baseado em mapas de transformações.
4. Roteamento Dinâmico de Mensagens: “Serviço
de Roteamento Dinâmico”
Responsável pelo serviço dinâmico de mensageria, aceitando mensagens de entrada
que contêm informações sobre as iterações que precisam ser executadas.
Os itinerários, então, são resolvidos com base nas informações contidas no
cabeçalho das mensagens, possibilitando que as mensagens sejam encaminhadas
através do barramento para uma série de provedores de serviços de uma forma
síncrona ou assíncrona.
5. Monitoramento de Mensagens: “Serviço de
Monitoramento”
Serviço que prove informações sobre o status dos hospedeiros e aplicativos.
Permite consultar o status das mensagens e das aplicações, construindo painéis
de controle com base nas informações fornecidas. Informações como métricas,
status e metadados das aplicações podem ser visualizados em tempo real.
Início da página
Serviço de Resolução
Para garantir o
desacoplamento dinâmico entre o provedor e o consumidor dos serviços, o
barramento precisa de uma nova capacidade que podemos chamar de “Catálogo ou
Registro”. Esta capacidade garante que o consumidor possa descobrir as
informações mais relevantes dos serviços.
O pacote “BizTalk ESB
Toolkit 2.0” vem com vários provedores de resolução: como o UDDI, WS-MEX, BRE,
XPATH e o uso de registros estáticos. A melhor solução a escolher será definida
de acordo com a aplicação.
O Serviço de Resolução
fornece uma interface web service para uso de aplicativos externos. Para consumir um serviço, você precisa
disponibilizar no seu código um “ResolverString”.
Este “ResolverString” define o tipo
de provedor e o nome do serviço do qual você quer resgatar informações. Baseado
neste cenário, o “ResolverString” vai
ser processado e irá retornar o
resultado para o consumidor com as descrições do serviço.
Exemplo de um “ResolverString” com UDDI 3.0:
- “UDDI3:\\serverUrl=http://localhost/uddi;serviceKey=uddi:esb:purchaseorder”
De modo geral, podemos
definir o seguinte cenário: o consumidor quer acessar um serviço de
cadastramento de usuários, mas ele não tem as informações necessárias para
estabelecer uma conexão direta. O
consumidor precisa mandar uma requisição para o serviço de resolução, que vai
retornar as informações disponíveis no catálogo de serviços. É importante
mencionar que este serviço não passa pela mensageira do servidor BizTalk
Server, mas pode ser usado diretamente como descrito ou dentro de um fluxo de
interações.
.jpg)
Figura 1 - Serviço de
Resolução
1. Processo encaminha a mensagem com a interação de resolução para o “Enterprise Service Bus”
2. O anexo da mensagem é
processado via o processo de resolução de serviços.
3. O “Enterprise Service Bus” entrega a mensagem para o serviço de
destino.
4. O “Enterprise Service Bus” recebe a mensagem de retorno do serviço
destino.
5. O “Enterprise Service Bus” retorna a mensagem para o consumidor do
serviço.
UDDI é um sistema de
catálogo com o objetivo principal de fornecer informações sobre os serviços e
que permite procurar serviços com base em uma variedade de critérios. Como o
UDDI foi inicialmente concebido como um catálogo público, as empresas podem
explorá-lo para recursos internos para categorizar e descrever seus serviços
empresariais disponíveis.
Importante: O UDDI na
plataforma Microsoft não e mais parte do Windows Server, sendo agora incluído
apenas no BizTalk Server 2009.
Início da página
Serviço de
Tratamento de Exceções
O pacote “BizTalk ESB
Toolkit 2.0” oferece várias capacidades de tratamento de exceções. O que vamos
tratar neste artigo é o serviço central de publicação de exceções com
processamento unificado. O serviço de exceções usa todas as capacidades de
tratamento de exceções do próprio Servidor BizTalk, tal como roteamento e
re-submissão. O serviço de exceções fornece uma interface web service para que
as aplicações possam estender o tratamento de erros de forma centralizada.
Vamos analisar um
exemplo de serviço básico. O consumidor manda uma requisição para o “Enterprise
Service Bus”. O “Enterprise Service Bus” analisa a requisição e manda a
mensagem para o provedor do serviço. Continuando o fluxo, o desenvolvedor pode
gerar exceções padronizadas para o pacote “BizTalk ESB Toolkit 2.0”, que são
arquivadas no banco de exceções.
.jpg)
Figura 2 -
Serviço Tratamento de Exceções
1. Processo encaminha a mensagem com o erro para o “Enterprise Service
Bus”
2. O “Enterprise Service Bus” inicia
o processo de tratamento de exceções
3. O “Enterprise Service Bus” inicia
o processamento de exceções baseado no tipo de erros
4. O “Enterprise Service Bus”
retorna a mensagem de status para o consumidor do serviço
Seria muito fácil
escrever vários capítulos exclusivamente sobre as capacidades e os benefícios
do Serviço de tratamento de exceções. Embora o serviço de tratamento de
exceções forneça funcionalidades valiosas, algumas das melhores qualidades
desta biblioteca estão no processamento interno de exceções do próprio BizTalk.
Apesar de não abrangermos estas funcionalidades, eu encorajo fortemente
acompanhar e estudar este serviço de forma mais profunda.
Início da página
Serviço de
Transformação
De modo geral, podemos
definir o seguinte cenário: uma mensagem de entrada precisa ser transformada em
uma mensagem nova baseado em um mapa de transformação. Este serviço pode ser
consumido em conjunto com o serviço de iterações para garantir a interoperabilidade
entre diferentes serviços.
O exemplo abaixo
mostra um mapa de transformação de uma mensagem do tipo “Material Scanner Output” para uma do tipo “MaterialBatchMaster”, que é um formato definido dentro do schema do destino com “Functoids” (funções aplicadas na
transformação de campos que ajudam na definição das transformações necessárias
como concatenações, somatórios ou scripts mais complexos). A criação de um novo
mapa de transformação é feita com o Visual Studio 2008 e as ferramentas de desenvolvimento
do BizTalk 2009. Os mapas de transformações são executados diretamente usando
os assemblies registrados no GAC (Global Assembly
Cache).
.jpg)
Figura 3 -
Mapa de Transformação
O processo de criação
de um mapa de transformação inclui tanto um projeto BizTalk no Visual Studio
com a definição do mapa de transformação quanto a distribuição do componente
resultante no GAC.
Um caso de uso
exemplar deste serviço seria:
.jpg)
Figura 4 -
Serviço de Transformação
1. O processo encaminha a mensagem com transformação para o “Enterprise Service Bus”
2. O “Enterprise Service Bus” entrega a mensagem para o serviço de
destino
3. O “Enterprise Service Bus” inicia a transformação baseado no mapa de
transformação associado no fluxo de serviços.
4. O “Enterprise Service Bus” retorna a mensagem transformada para o
consumidor do serviço
Os benefícios do
serviço de transformação são baseados na facilidade e simplicidade de uso. Como
no exemplo descrito acima, podemos criar transformações mais complexas, com
integração em diversos fluxos de iterações.
Início da página
Serviço de
Roteamento Dinâmico
Roteamento dinâmico
representa uma parte crítica do pacote “BizTalk ESB Toolkit 2.0”. Um itinerário
é um conjunto de instruções que define um fluxo de serviços que o barramento
deve executar para uma determinada mensagem. Esta capacidade é disponibilizada
através de um conjunto de serviços, “Pipelines”
e “Schemas” de metadados bem
definidos. Estes componentes funcionam em conjunto para manter a persistência e
controlam o progresso ao longo do fluxo a cada serviço. Uma vantagem do
mecanismo de itinerários é que eles são anexados no cabeçalho da mensagem e não
exige qualquer implantação de orquestrações do BizTalk (workflows definidos em
tempo de compilação no Visual Studio e executado pelo BizTalk). Portanto,
itinerários oferecem uma maneira de compor serviços desacoplados baseados em
artefatos existentes, eliminando o custo da construção, implantação e
manutenção de orquestrações acopladas.
Um aspecto novo
introduzido no pacote “BizTalk ESB Toolkit 2.0” é o Designer de itinerário
incluído no Visual Studio .NET 2008. Basta clicar o botão direito do mouse no
Visual Studio dentro de um projeto e adicionar um novo item de itinerário.
Estas composições de serviços (itinerários) podem ser armazenadas localmente em
um arquivo XML ou centralizados em um banco de dados central para o acesso
corporativo. Os itinerários são resolvidos no “Enterprise Service Bus” com
base nas informações contidas no cabeçalho das mensagens, que são encaminhadas
através do barramento para uma série de provedores de serviços de uma forma
síncrona ou assíncrona.
.jpg)
Figura 5 - Interação com um
serviço
Na figura 5 nós
podemos ver uma interação simples com um serviço. Seus passos são:
1. O “Enterprise Service Bus” recebe a mensagem via o componente de
entrada que suporta mensagens síncronas ou assíncronas.
2. O “Enterprise Service Bus” inicia
o processo de roteamento dinâmico.
3. O “Enterprise Service Bus”
retorna a mensagem via componente de entrega para o consumidor do serviço com
suporte para mensagens síncronas ou assíncronas.
.jpg)
Figura 6 - Interação com múltiplos serviços
Na figura 6 podemos
ver uma interação mais complexa com um conjunto de serviços. Seus passos são:
1. O “Enterprise Service Bus”
recebe a mensagem via o componente de entrada que suporta mensagens síncronas
ou assíncronas.
2. O “Enterprise Service Bus” inicia o processo de roteamento estático.
3. O “Enterprise Service Bus” redireciona a mensagens para o serviço de
destino, com suporte para mensagens síncronas ou assíncronas.
4. O “Enterprise Service Bus” recebe mensagens de retorno do serviço
destino e inicia o processo de transformação.
5. O “Enterprise Service Bus” retorna a mensagem transformada via
componente de entrega para o consumidor do serviço, com suporte para mensagens
síncronas ou assíncronas.
Baseado neste cenário
é possível descrever (Figura 7) um cenário completo onde a comunicação entre o
provedor e o consumidor é altamente desacoplada e nunca cria uma conexão direta
entre o consumidor e o provedor.
O caso de uso seria:
.jpg)
Figura 7 - Serviço de Roteamento Dinâmico
1. Processo encaminha a mensagem com o itinerário, predefinido no
repositório central, anexado para o “Enterprise
Service Bus”
2. O anexo da mensagem é processado
via o processo de roteamento dinâmico que inicia o fluxo de serviços definidos
3. O primeiro serviço definido é o
serviço de resolução de descrições. A mensagem de retorno e encaminhada para o
“Enterprise Service Bus”.
4. O “Enterprise Service Bus” entrega a mensagem para o serviço de
destino final
5. O “Enterprise Service Bus” recebe a mensagem de retorno para ser
retornada ao serviço iniciador da conversação
6. O “Enterprise Service Bus” inicia a transformação baseado no mapa de
transformação associado no fluxo de serviços.
7. O “Enterprise Service Bus” retorna a mensagem transformada para o
consumidor do serviço
Conforme já discutido
neste artigo, podemos considerar o serviço de roteamento dinâmico o coração do
“ESB”. Como no exemplo básico descrito acima, ele fornece os padrões e
“Patterns” de desacoplamento para criar um ambiente de “SOI”. Este serviço, em
conjunto com os outros, amplia o comportamento do BizTalk Server de um “Hub /
Spoke” para um “ESB”.
Início da página
Serviço de
Monitoramento
O serviço de
monitoramento expõe informações sobre os objetos e mensagens no servidor
BizTalk. O nome deste serviço no BizTalk é “ESB.BizTalkOperationsService”. Ele
expõe informações de métodos que retornam itens como uma lista de hospedeiros,
orquestrações, aplicações e o status de aplicação do BizTalk.
.jpg)
Figura 8 - Serviço de Monitoramento
1. O “Enterprise Service Bus”
recebe a mensagem via o componente de entrada que suporta mensagens síncronas
ou assíncronas.
2. O “Enterprise Service Bus” inicia o processo de monitoramento.
3. O “Enterprise Service Bus” retorna a mensagem via componente de
entrega para o consumidor do serviço com as informações solicitadas.
Exemplo de informações
disponíveis via este serviço:
- Lista de
aplicações e orquestrações BizTalk com seu status
- Lista de
portas BizTalk para enviar e receber mensagens
- Lista de
instâncias do BizTalk com seu status
- Lista com
status das mensagens de transferência
O grande benefício
deste serviço é disponibilizar um web service que revela detalhes de artefatos
e aplicativos do servidor BizTalk em tempo real. Ele pode ser usado na
construção de um painel de controle, com base nas informações fornecidas.
Início da página
Considerações
Finais
O pacote “BizTalk ESB
Toolkit 2.0” permite criar um ambiente mais desacoplado orientado ao serviço,
através de serviços, transformação, resolução dinâmica e processamento de
itinerários. Essas capacidades permitem um cenário de TI mais alinhado às
necessidades de negócio. A arquitetura
SOI/SOA necessita de uma infraestrutura de integração cada vez mais poderosa e
complexa, especialmente durante períodos de incertezas econômicas, que amplia o
impacto de uma TI mais ágil.
Este artigo foi apenas
uma introdução sobre o assunto. A partir de agora, fica a sugestão para que o
leitor acompanhe e estude essas tecnologias, experimentando e avaliando os
benefícios de um barramento corporativo de serviço no dia-a-dia.
Artigos e Blogs
relevantes sobre o tema
Algumas referências de
blogs e portais interessantes sobre o assunto são listadas abaixo, vale
conferir:
Brian Loesgen’s Blog
BizTalk
Microsoft MSDN
Peter Kelceys Blog
Agradecimentos
Obrigado ao Otávio
Coelho, Waldemir Cambuci e Luciano Palma pelos comentários e sugestões.
Sobre o Autor
Markus Christen
trabalha na Microsoft Brasil como
arquiteto de infraestrutura, com foco na comunidade local de arquitetos e
clientes corporativos.
Blog:
http://blogs.technet.com/markuschristen
Início da página