Codemountain, Paulo Suzart's Blog

ESB? Até que ponto?

with one comment

Olá a todos. Desde que fiz a primeira fase da Certificação SOA Architect da BEA em 2008, não escrevi nada sobre SOA aqui no blog.
Infelizmente não vou começar falando do Paradigma de design Service-Orientation [01], tão pouco como ela se Encaixa em Service-Oriented Computing [01] até chegar em SOA de fato. Dois termos, alias, completamente desconhecidos por quem imagina que trabalha com SOA.

Não vai dar pra postar nada introdutório neste artigo, tão pouco tratar SOA por completo. Mas vou falar de um dos enganos mais comuns quando se trata de SOA dentre  muitos  que já presenciei, a saber:

“Um Webservice é um seviço”, “Ter um ESB é ter SOA”, “Ter Webservices é fazer SOA”, “ESB deve ser o responsável por fazer Service Orchestration“, “Meu sistema X ‘chama’ o BUS que ‘chama’ o sistema Y”. Bom, dá pra fazer uma lista vasta aqui, mas paremos por aqui.

E o engano que trato neste post é: “Todo e qualquer serviço deve ser exposto no barramento de serviço ESB”. Mas por quê? Existem alguns outros blogs que já falaram sobre quando usar ou não um ESB adotando uma abordagem diferente desta aqui.

Primeiro vamos ao Papa Thomas Erl [01] para a definição de ESB:

“An enterprise service bus represents an environment designed to foster sophisticated interconectivity between services. It estabilishes an intermediate layer of processing that can help overcome problems associated with reliability, scalability, and communications disparity“.

É um bonto de partida. Podemos agregar outras e outras definições e ter uma definição mais completa ou à contento.

Um pouco da minha humilde vivência em SOA concorda com isso e diz que o ESB é puramente um mediador e deve ser visto como um componente da infra estrutura de serviços de uma corporação, não como o “ambiente soa” (outro engano).  Um Service BUS deve prover algumas características como capacidade de roteamento de mensagem, transformação de mensagem, tradução de protocolos, virtualizaçao de serviço, balanceamento de carga, message throttling, dentre outros.

Mas aí o engano que diz que um webservice é um serviço aparece por aqui. E essa é uma das maiores falácias que a humanidade já conheceu, tal como 2+2 = 5.

Um serviço dentro do contexto SOA, segundo a Wikipedia é: “… the term service refers to a set of related software functionality, together with the policies that should control their usage.” [02]

Logo, um serviço é acessível por sua interface [03] que expõe sua implementação*, que por sua vez obedece a um contrato bem definido para o serviço (funcionalidade). O contrato é o descritor, comumente não técnico, das capabilidades [01]  de um serviço. Estas capacidades por sua vez foram derivadas de alguma necessidade do negócio, ou seja, um Serviço existe pois uma necessidade (requerimento funcional) corporativa existe. Vamos parar por aqui, não vamos chegar ao ponto de onde uma necessidade corporativa (Business Requirement) é derivada. Por tanto temos (de forma resumida, e me perdõem meus amigos conhecedores da ESEF pela simplicidade aqui) os seguintes elementos que compõe um serviço:

Agora que chegamos a um ponto onde sabemos o que é um serviço e (mais ou menos) de onde ele brotou, voltemos aos Requisitos Funcionais Corporativos, ou seja, funções desenpenhadas pela corporação.

Uma funcionalidade corporativa pode não ser justificável como um Serviço compartilhado, que embora obedeça a definição de um serviço (Acima), o seu uso deve ocorrer apenas no escopo de uma aplicação. Quando isso acontece, diz-se que um serviço X é pertencente ao escopo de Aplicação pois é acessível somente por esta. Frequentemente os demais escopos são: Aplicação, Inter-departamental, Empresarial e público. Escopo está diretamente ligado a que tipo de consumidor o serviço atende.

STOP! Aqui temos uma boa razão  para não expor um serviço na infraestrutura SOA corporativa da empresa: O serviço tem um escopo tão reduzido (De aplicação) que se restringe a atender uma única aplicação. (escrevi o post basicamente pra mostrar isso, outras razões para não expor um serviço em um ESB vem de bom senso e prática, além de depender do cenário em questão).

Seguindo a idéia de classificar um serviço quanto ao seu uso, temos uma segunda forma de classificação, comumente chamada de categorização, onde um serviço pertence a uma categoria, ou camada, dada sua capabilidade. Ou seja, serviços capazes de acessar uma função de um sistema legado e expor tal para o ambiente SOA (dentro de algum escopo acima) como ela é, é comumenta categorizado (ou reside na camada de) serviço de conectividade.

Tal categoria pertence a um conjunto mairo de categorias, ou camadas, que facilitam a abstração e auxiliam nas decisões de design. Outra camadas, não menos importante são:

  • Serviços de Dados – Requisitos Corporativos frequentemente tratam de entidades corporativas a exemplo de Cliente, Contrato, Endereço, etc. Serviços que provêem acesso unificado, bem como uma visão única entre os diversos formatos de diversas fontes em uma corporação, residem nesta camada.
  • Serviços de Negócio – São comumente subdivididos em serviços que executam atividades corporativas atômicas (ex: validar cartão de crédito) e serviços de granularidade mais espessa, também chamados de processos de negócio (ex: Processar pedido em e-commerces)
  • Serviços de Apresentação – São serviços que permitem a reutilização de uma interface com o usuário (ex: portlets e mash-ups.
  • Serviços utilitários – São serviços que não estão associados a um contexto específico dentro do negócio (ex: Serviços de Notificação).

De fato, dada uma combinação Categoria x Escopo, tem-se uma série de boas práticas aplicáveis aqui. E considerando um serviço de acesso a dados que atende exclusivamente a uma aplicação, não há a necessidade de mediação pelo ESB, ou ainda, não há necessidade de que este serviço resida na infraestrutura da companhia.

Numa abordagem simplista, temos a distribuição de camadas/categorias de serviços como exemplifiquei ano passado aqui [04]. Pra ficar mais coerente com este post e a minha modesta evolução em SOA no último ano, considere a camada vertical vermelha como a camada de serviços utilitários. Ah! Vamos imaginar uma última camada abaixo da camada de serviços de dados, de acesso ou conectividade.

O bom senso ajuda muito, mas ter noção de onde um serviço nasce, é tão importante quanto isso. Decidir cegamente se um serviço, e sua interface física (WSDL em caso de uso de webservices) deve residir no barramento de serviços é um equívoco. Definir nomes, tipos, escopos, quantidade e relacionamento entre serviços sem uma justificativa é algo que leva ao erro e uma frustração no programa SOA do cliente. E quando isso acontece, todos nós que acreditamos em SOA, pagamos por isso. Agindo assim, fazemos SOA perder credibilidade e estar fadado ao fracasso.

Toda essa história de Requisito Funcional, Serviços e seu componentes, Escopo, Camada de serviços vêm de uma metodologia, de uma engenharia de serviço. SOA também precisa de uma metodologia, e governança. Por favor, nada de empirismo😉

ESB faz parte da infraestrutura SOA e deve ser tratado como tal. E considerando as novas tendências e o uso de Composite Applications baseadas em SCA, teremos uma ajuda para colocarmos o ESB em seu devido lugar. Ou então SCA vai terminar de confundir mais algumas pessoas que imaginam fazer SOA.

*existem outras definições para os componentes de um serviço e como eles se relacionam.

Referências:

[01] SOA Design Patterns by Thomas Erl

[02] SOA in Practice: The Art of Distributed System Design (Theory in Practice) by Nicolai M. Josuttis

[03] Service (systems architecture) from Wikipedia

[04] Rasea e SOA – Parte I by Paulo Suzart

Written by paulosuzart

agosto 26, 2009 às 12:22 am

Publicado em soa

Uma resposta

Subscribe to comments with RSS.

  1. […] prima por serviços como meio de entregar funções corporativas. Relembre também do post “ESB? Até que ponto?“  e vai ver que falei sobre a divisão, ou melhor, categorização de serviços por camada. […]


Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: