Papel do ESB dentro de uma arqutetura SOA

SOA é uma arquitetura onde é possível criar, padronizar, documentar funções genéricas únicas, utilizadas por diferentes aplicações em componentes reutilizáveis e com total interoperabilidade, de modo que possam ser compartilhados e acessados por diferentes dispositivos sob a forma de serviço, sem precisarem ser reescritos.

O papel do ESB dentro de uma arquitetura SOA é atuar como infra-estrutura para suportar os princípios de projeto SOA, virtualizando os serviços providos e tornando toda TI transparente para o negócio. Numa arquitetura SOA, o ESB fundamentalmente atua no papel de prover independência de linguagem, transparência de protocolo e localização, independência de formato de dados, independência de plataforma e um modelo de comunicação transparente para que seja possível atingir um baixo acoplamento entre os serviços componentes da arquitetura.

Segue abaixo um exemplo de um ESB:

O ESB também tem o papel de prover infra-estrutura para gerenciamento adequado da arquitetura em grande escala. Um ESB serve então como  infra-estrutura de uma arquitetura SOA, lidando com o roteamento, transformação e mediação entre produtores e fornecedores de serviços, sejam eles internos ou externos à organização.

É isto aí pessoal. Qualquer problema avisem.

Funcionalidades de um ESB

Um dos objetivos deste post é dar uma breve explicação sobre as principais funcionalidades de um ESB que são o roteamento a transformação e a mediação.

Os envolvidos numa comunicação através do ESB não precisam compartilhar o mesmo protocolo de comunicação ou formato de mensagem, pois fica a cargo do ESB realizar as transformações necessárias nas mensagens trocadas. Isto acontece através do serviço de transformação do ESB. Por exemplo, uma mensagem com 10 campos enviada através de SOAP pode ser recebida pela outra ponta como uma mensagem JMS com 4 campos removidos.

O serviço de mediação no ESB compreende todo o workflow de mensagens envolvido para realizar uma determinada "interação" entre os participantes. Os participantes não entram em contato um com o outro, e sim, toda comunicação é mediada pelo ESB. Mediações complexas podem também ser formada a partir do encadeamento de outras mediações. Por exemplo, qualquer mensagem enviada de um componente para outro requer a mediação do ESB.

O serviço de roteamento de um ESB oferece uma infra-estrutura de comunicação e localização comum que pode ser utilizada para conectar serviços sem que os desenvolvedores precisem realizar uma lógica de conectividade complexa. Por exemplo, uma requisição a um serviço é realizada ao ESB por um componente sem que este conheça a localização física do serviço desejado, nem mesmo por qual caminho a solicitação será trafegada até chegar ao seu destino.

Um produto de mercado ESB se chama Websphere Message Broker. Esta é uma solução IBM para implementar um EAI robusto baseado em mensagens e serve para conectividade entre aplicações, mediações entre fornecedores e clientes e criação de um barramento de serviços.

Entre as principais funcionalidades temos o roteamento, transporte e mediação, suporte a pilha WebServices, integração com transportes do WebSphere MQ e repositório de mensagens persistentes.

Entre os mecanismos e protocolos suportados temos JCA, WebServices, Mensagens MQ, TCP/IP, Hats. Pode através de algum destes protocolos comunicar com Mainframe CICs entre outros.

O produto também permite virtualizar o acesso aos serviços e os disponibilizar de forma simples o acesso a aplicações heterogêneas. Suporta também como transporte http e SOAP, suporte a aplicações de tempo real, envio de mensagens, entre outros,

A arquitetura de referência se baseia em 4 elementos centrais:

· A modelagem e a simulação de novos processos de negócio. A ferramenta chave é o Websphere Businnes Modeler. Este produto permite que se modele o processo de negócio e utilize os serviços disponibilizados nas camadas inferiores.

· Desenvolvimento de novos serviços e processos – As ferramentas chave são o Rational RAD e o Websphere Integration Developer.

· A execução de processos - A ferramenta chave é o WPS (Process Server). O WPS requer um ESB para operar (WESB ou ESMB).

· A monitoração de processos com o WebSphere Business Monitor.

É isto aí pessoal. Espero que esta introdução sobre ESB ajude quem está começando.

Considerações do texto: The Web Services Debate e .Net vs. J2EE

A utilização de Web Services permite a comunicação e a interoperabilidade entre várias diferentes linguagens de programação. Sua utilização requer a cooperação entre as facções JEE e .NET. A tecnologia ainda não é madura o suficiente, mas basicamente é um servidor que escuta e responde SOAP, geralmente utilizando http. Na prática Web Services suporta WSDL para descrever suas interfaces, e podem também ser ouvidas em um registro UDDI.

A utilização de Web Services permite uma comunicação fácil entre várias plataformas de desenvolvimento, o que coloca fogo na discussão sobre qual plataforma de desenvolvimento é melhor. Particularmente nos artigos a comparação se concentra nas plataformas .NET e J2EE.

Uma vez que Web Services não é uma tecnologia que depende nem de J2EE e nem de .NET, é somente baseado em SOAP, XML e outros tecnologias independentes, a decisão de utilizar uma das duas tecnologias é somente uma questão de em que ambiente de desenvolvimento será realizado o deploy dos Web Services.

Segundo os defensores do J2EE a plataforma é mais madura, mais robusta, mais flexível e mais testada. Cerca de 55 a 70% dos deploys dos Web Services foram feitos utilizando a plataforma J2EE. Além disto, possui suporte de uma vasta quantidade de vendedores tais como SAP, IBM, BEA, Oracle, entre outros. Também segundo os defensores da tecnologia J2EE a plataforma é portável ou seja, possui a facilidade de ser escrita em algum lugar e poder rodar em qualquer lugar.

Segundo os defensores do .NET, esta plataforma é mais simples, mais barato para executar o deploy, mais barato de executar manutenção, possui melhor performance e custo de solução menor. Segundo também os defensores da tecnologia são necessárias menos linhas de código, o que aumenta a rapidez de desenvolvimento.

Web Services é realmente uma tecnologia que tende a ser muito importante para o desenvolvimento de aplicações no futuro e há espaço no mercado para o convívio tanto de aplicações J2EE quanto de aplicações .NET. Cabe a empresa a escolha da tecnologia que mais se aplica ao projeto a ser desenvolvido.

É isto aí pessoal. Qualquer problema me avisem.

Modelagem de processo de negócios com BizAgi

Olá pessoal,

Uma ferramenta que achei bem interessante para a modelagem de processo de negócios é a BizAgi Process Modeler. A ferramenta é bem simples de usar e possui bastante funcionalidades. Um exemplo de utilização se encontra em http://www.bizagi.com/eng/downloads/BPMNbyExample.pdf?token=1.4.1.0.

Para exemplificar a utilização da ferramenta resolvi modelar o processo de aprovação de posts do portal do arquiteto. Segue abaixo o modelo:

Com a ferramenta é possível modelar processos, subprocessos e é bem simples de se realizar a modelagem. Uma breve explicação sobre a ferramenta pode ser encontrado em http://www.baixaki.com.br/download/bizagi-process-modeler.htm.

É isto aí pessoal. Espero que ajude quem quer modelar os processos de negócio.

Considerações sobre o desenvolvimento com JSF

Olá pessoal,

Neste post de hoje quis falar um pouco sobre o que estou achando do desenvolvimento com JSF. Para o desenvolvimento com JSF estamos utilizando a distribuição RichFaces com Facelets. A meu ver o desenvolvimento ficou bem produtivo e bem orientado mesmo a componentes.

Criamos componentes para quase tudo com Facelets o que tornou a implementação ainda mais simples. Um exemplo de componente criado com Facelets é mostrado aqui. A utilização de ajax com o a4j (componente do RichFaces) é simples, elegante e torna a usabilidade das páginas muito legal.

Uma grande reclamação é sobre a curva de aprendizagem, mas particularmente não achei o fim do mundo. O que mais achei difícil no começo é decidir sobre quais componentes utilizar em dadas situações, uma vez que existem vários componentes, mas uma vez utilizado é bem tranquilo.

O modelo orientado a eventos tem facilitado muito a minha vida e abre um leque maior de opções sobre como desenvolver novas funcionalidades. A quantidade de componentes prontos do RichFaces também me facinou e um exemplo de utilização pode ser visto aqui. Na minha opnião JSF tornou realmente o desenvolvimento mais simples e tende a se tornar mesmo um padrão da industria.

É isto aí pessoal. Qualquer problema me avisem...