WS02 e Soluções para Open-Source SOA

WSO2 é um companhia baseada no Sri Lanka que desenvolve middleware open-source. Foi fundada a pouco mais de 2 anos atrás por Sanjiva Weerawarana, um ex-IBM que trabalhou (nos EUA) em vários projetos (Apache SOAP, a definição do WSDL, definição do BPEL etc) e decidiu desenvolver soluções abertas a partir deste país da Ásia. 

Entre outros produtos e frameworks a empresa desenvolve:

• Enterprise Service Bus: ESB "leve" baseado no Apache Synapse
  
• Web Services Application Server: Web services engine powered by Apache AXIS
• Mashup Server: plataforma baseada em Javascript que promete deploys rápidos de Web Services mashups

A lista completa de produtos está aqui.

A documentação do WSO2 ESB pode ser acessada neste Wiki que foi desenvolvido para a comunidade.

ESB: Mitos e Principais Funcionalidades

O Enterprise Service Bus (ESB) é (e será) um tema recorrente neste blog. Neste artigo, Dave Chappell, um dos criadores do conceito de ESB, trata de 10 mitos sobre o Enterprise Service Bus que precisam ser "desmascarados".

Não vou entrar em detalhes sobre cada um deles. Abaixo listo alguns deles:

• Mito #1: ESB não é um novo nome para o EAI (Enterprise Application Integration)
  
• Mito #4: ESB não é um pattern e muito menos um produto. ESB é um conceito que pode ser implementado de várias formas. Vide este post sobre a definição de ESB
• Mito #5: ESB "compete" com servidores JAVA EE. ESB é complementar e se integra (deve se integrar) a Java Application Servers.
• Mito #9: ESB serve apenas para "conectar" sistemas e não possui interface para implementar processos de negócio. Atualmente, qualquer ESB provê uma ferramenta/front-end para "desenhar" os fluxos dos processos. Não confundir com ferramentas de BPEL.

Entender qual o propósito da sua sua ferramenta de ESB é fundamental para "delegar" ao ESB as tarefas às quais ele foi projetado para implementar.

Novamente, da Wikipedia, temos as principais features do ESB:

1. it is an implementation of Service Oriented Architecture
2. it is usually operating system and programming language agnostic; it should work between Java and .Net applications, for example
3. it uses XML (eXtensible Markup Language) as the standard communication language.
4. it supports Web services standards
5. it supports messaging (synchronous, asynchronous, point-to-point, publish-subscribe)
6. it includes standards-based adapters (such as J2C/JCA) for supporting integration with legacy systems
7. it includes support for service orchestration & choreography
8. it includes intelligent, content-based routing services (itenerary routing)
9. it includes a standardized security model to authorize, authenticate, and audit use of the ESB
10. it includes transformation services (often via XSLT) between the format of the sending application and the receiving application, to facilitate the transformation of data formats and values
11. it includes validation against schemas for sending and receiving messages
12. it can uniformly apply business rules, enrichment of the message from other sources, splitting and combining of multiple messages, and the handling of exceptions
13. it can conditionally route or transform messages based on a non-centralized policy - meaning that no central rules engine needs to be present
14. it is monitored for various SLA (Service-Level Agreement) thresholds message latency and other characteristics described in a Service Level Agreement
15. it (often) facilitates "service classes," responding appropriately to higher and lower priority users
16. it supports queuing, holding messages if applications are temporarily unavailable
17. it is comprised of selectively deployed application adapters in a (geographically) distributed environment

O que é ESB?

Primeiro, ESB é o acrônimo de Enterprise Service Bus (Barramento de Serviços Corporativos, em uma tradução livre). É um componente fundamenta na arquitetura orientada a serviços (SOA) e, por este motivo, é importante conhecermos qual o propósito e qual seu papel no desenho de sua solução SOA.

Hoje, a pesquisa de "ESB Definition"no Google irá apresenta mais de 46,000 links. Apresento aqui apenas 05 (cinco) que, na minha opinião, dão a idéia correta do que seja um ESB.

A primeira definição, claro, vem da Wikipedia.

Um ESB geralmente provê uma camada de abstração acima de um sistema de mensageria corporativa, que permite aos arquitetos de integração explorar todas as possibilidades e benefícios deste messaging system sem a necessidade de escrever código.

Ao contrário da abordagem tradicional da Enterprise Application Integration (EAI), que utiliza a arquitetura monolítica de hub and spoke, os fundamentos do ESB são baseados na decomposição de processos de negócio executando de forma "harmoniosa".

ESB não implmenta service-oriented architecture (SOA) porém oferece as funcionalidades necessárias para implmentar esta arquitetura. ESB não é, necessariamente, baseada apenas em web-services.

David Chappell é simplemente o "guru" e um dos "inventores" do conceito de ESB. Ele é o autor do livro "Enterprise Service Bus" em 2004 (foto ao lado). Atualmente é o líder de SOA na Oracle. De acordo com ele,

Um ESB é "backbone altamente distribuido" no qual a arquitetura orientada a serviços (SOA) é contruida.

A definição de ESB inclui os seguintes pontos:

* Uma arquitetura de serviços distribuidos, que inclui um modelo de container leve para "armazenar" componentes de integração como serviços remotos
* Um backbone de mensageria corporativa que oferece entrega confiável de mensagens entre aplicações e serviços
* Transformação de dados (XML)
* Orquestração de serviços e roteamento inteligente de mensagens baseada em seu contexto
* Framework de segurança flexível
* Infraestrutura gerenciável que permite a configuração, deployment, monitoração e gerência dos serviços remotos.

IBM SOA Foundation - Architecture Overview, whiter paper. Este é um dos melhores papers sobre o básico de SOA.

O Barramento de Serviços Corporativos (ESB) é parte da arquitetura lógica de SOA. Sua presença na arquitetura deve ser transparente para os serviços de suas aplicações SOA. Entretanto, a existência de um ESB é fundamental para simplificar o esforço de "invocar" os serviços. Detalhes como localização e qual o caminho que a requisição de um serviço deve fazer na rede são de responsabilidade do ESB e não precisam mais fazer parte do código do serviço.

Eric Bruno, escreveu um excelente artigo sobre ESB. Já postei aqui no blog. Reproduzo abaixo a tradução livre do trecho em que ele define o ESB.

Um Enterprise Service Bus é um framework que possui várias funcionalidades: escolha e use. Por exemplo, você pode utilizar apenas parte das features e ignorar as demais que não fazem sentido para a solução proposta pela arquitetura que você projetou. De qualquer forma, um "bom ESB" deve ter, pelo menos, estas características:

• Ter um insfraestrutura de mensageria robusto e confiável
• Possibilitar desenvolvimento de sistemas baseados em em arquitetura orientada a serviços (parece óbvio, mas não é; pergunte aos seus fornecedores como o ESB deles permite este tipo de implementação)
• É fortemente baseado em XML
• Suporta padrões de Web Service (e.g. SOAP)
• É independente de plataforma (muito, muito, muito importante)
• Suporta transações e tem features de segurança
• E por fim, mas não menos importante, utiliza protocolos padrão e tem integração com "legados"

Cerveja ESB? Sim, ela existe. É uma cerveja tipo Ale da Redhook. Ganhou a medalha de ouro em 2006 no "North American Beers Award".

Não deixa de ser uma excelente "ferramenta" de integração, correto?

Cheers!

Uma boa definição de ESB

Este é um artigo muito didático sobre ESB. O artigo inicia com uma interessante visão dos desafios do software distribuido (vide figura acima).

O autor (Eric J. Bruno) enumera três grandes desafios quando se trata de software distribuido:

• O desafio da Complexidade (complexity)
  
• O desafio da Segurança (security)
  
• O desafio da Confiabilidade (reliability)

A solução? ESB. Segundo o autor, um ESB pode ser melhor descrito como tendo uma das seguintes características:

• Provides a reliable messaging infrastructure
• Enables SOA-based system development
• Is XML-based
• Supports web service standards (such as SOAP)
• Is platform independent
• Supports data transformation and routing services
• Enables service orchestration
• Supports transactions and security
• Integrates with existing standards, frameworks, and legacy systems

Vale a pena a leitura (21 pags).

O que há de errado na "ESB-oriented Architecture"?

No dia 12/Set/07, Bobby Woolf postou um controverso artigo no site DeveloperWorks (IBM). O título é "ESB-oriented architecture: The wrog approach to adopting SOA". Li o artigo assim que ele foi publicado e não tinha visto nada de "controverso" no seu texto. Voltei 1 semana depois no mesmo artigo e verifiquei que o autor havia inserido uma nota no cabeçalho do texto informando que alguns tinham interpretado de forma errada as suas conclusões.

Segue as minhas impressões do texto do Mr. Woolf:

1. O ESB, por si só, não traz nenhum valor para o negócio. ESB é "meio"e não o "fim" para SOA (aliás, Service-oriented Architecture, na minha opinião, é um "caminho" não um objetivo)
2. Ele está correto em sugerir fortemente para não utilizarmos a estratégia de "construir o barramento de serviços corporativos e esperar as aplicações SOA aparecendo em torno do mesmo". Tenha sempre uma estratégia para sua arquitetura SOA alinhada com o negócio, a arquitetura SOA não vai surgir apenas como uma necessidade de TI
   
3. A estratégia correta é: "implemente apenas e se necessário, apenas quando houver a necessidade do negócio, e não porque você está prevendo que alguém irá precisar desta implementação". Eu considero esta uma das regras de ouro da arquitetura SOA

Se você já tem um ESB na sua corporação, saiba que você já deu um grande passo em direção ao mundo SOA. Contudo, não caia na tentação de contruir uma "EOA" (ESB -oriented Architecture)!

Leia o artigo (3,5 paginas) e tire suas conclusões.

MULE ESB: A Case Study

Eugene Ciurana (from Walmart.com) wrote this article that you can find at TheServerSide.com. The subject is ESB, more specifically MULE ESB. Version 1.3.3 is "fresh from the oven" with 27 issues/functionalities implemented since 1.3.2.

Eugene's text starts with a simple question: "Why are ESB needed?". After this there is an interesting comparation between the ESBs from TIBCO (Matrix BusinessWork), SUN (openESB), Progress Software (Sonic ESB), IBM (WebSphere ESB) and, of course, Mule ESB (open-source, MuleSource Inc.).

He points out some advantages of Mule ESB:

* Active open-source community and commercial support available
* State of the art implementation and ability to run under Java 5/6
* Number of relevant features out of the box
* Response time from vendors within 48 hours (average time for the winners was 2 hours)
* Ease of installation and deployment
* Ease of configuration and expansion
* “Codeless” integration with legacy, third-party, and commercial products
* Ability to drop in/pull out without incurring in lock-in or ancillary product dependencies
* Low total cost of ownership

And how Mule ESB enables two or more applications to communicate? Mule implements elegant protocols and standards based on well-defined patterns. Applications communicate with one another by implementing these patterns with a set of predefined components (see figure below):

Eugene continues:
"... - Applications interface with Mule over a transport.
- A transport carries service objects between components (some of the current documentation refers to service objects as “UMOs” or universal message objects; that term is deprecated now).
- The transport is any mechanism for exchanging data between two points
- Mule doesn’t implement or mandate use of particular transports. It offers instead a number of transport providers and the integration engineers or developers get to choose the appropriate one for a given application.
- A transport provider implements a message receiver or dispatcher, a connector that implements a protocol like JMS, TCP, etc., and an optional transformer.
- The transformer may be use to convert service objects from one format to another (XML to native Java, for example).
- Mule routes inbound and outbound data between transports through the service object component, which is responsible for managing component events to and from the component, and for managing pooled resources. ..."

Good reading!