Monday, February 04, 2008

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

No comments: