quarta-feira, 3 de novembro de 2010

Conhecendo o Ruby On Rails

Há mais ou menos uns 10 anos atrás, comecei a perceber o grande e repetitivo trabalho que tinha que fazer toda vez que eu tinha que iniciar o desenvolvimento de um sistema usando as linguagens PHP (Na época chamado de PHP FI) ou ASP.

Ter que criar scripts e tabelas no banco de dados sempre partindo do zero era uma coisa que tornava o trabalho demorado e sem graça, quase que puramente operacional. Foi quando recorri ao "The most powerful and useful guide to the Net" (aka: Altavista), procurando por algo que pudesse agilizar meu trabalho tornando-o mais produtivo e divertido. A busca foi frustrada pois o melhor que eu encontrei naquela época foi o Dreamweaver UltraDev, que simplesmente criava um código impossível de dar manutenção.

Passado todo esse tempo, eis que em 2010 posso dizer encontrei o que procurava naquela época. Depois de escutar vários amigos falando muito bem e usando, resolvi conhecer e praticar o Ruby on Rails.

O primeiro passo foi dado com a leitura do (excelente!) livro "Ruby on Rails - Desenvolvimento rápido e fácil de aplicações web" do Robrigo Urubatan (Editora Novatec).

Já nos primeiros capítulos não resisti e comecei a colocar a mão na massa, ou seja, instalei o Ruby on Rails e comecei a criar algumas aplicações a partir dos exemplos contidos no livro. A experiência não poderia ser melhor!!

Ruby on Rails, também chamado de RoR, é um framework de desenvolvimento de aplicações web baseado na linguagem Ruby e que utiliza o padrão arquitetural Model-View-Controller (MVC).

Uma característica muito interessante desse framework é a utilização nativa de web services REST como forma de comunicação entre o View e o Controller. Sendo assim, ao criar uma aplicação web com o Ruby On Rails você não só está criando a interface humana (HTML) do seu sistema mas também está disponibilizando toda a lógica da sua aplicação para acesso através de uma API REST, o que me interessou muito já que estou atuando como Arquiteto de Integração e participando da implantação de uma Arquitetura Orientada a Serviços (SOA).


Quer ver como é fácil desenvolver aplicações web com o Ruby on Rails?

Desde quando pensei em escrever esse post fiquei pensando o que faria para mostrar brevemente como o Rails funciona. Que exemplo utilizar? Devo, antes de tudo, mostrar como se instala o Ruby e o Rails? Será que o post não vai ficar chato e grande? Nada disso! Foi então que lembrei de um vídeo que me serviu como grande motivador para aprender o framework.

Trata-se de dois vídeos que explicam como trabalhar com formulários html aninhados. No vídeo, a aplicação que é construída permite a criação de Pesquisas (surveys), onde cada pesquisa pode conter várias perguntas, que por sua vez pode conter várias opções de resposta.

Mesmo se você não sabe nada de Ruby ou de Rails vale a pena assistir. Mas assista observando a (pouquíssima) quantidade de código que é escrita para criar a aplicação. Observe também o tempo que leva para fazer. E, principalmente, pense na quantidade de código que você teria que escrever e quanto tempo demoraria para você fazer o mesmo na linguagem de programação que você utiliza atualmente.

Aí vai o link desses dois vídeos que estou me referindo:


A propósito, o http://railscasts.com é uma ótima referência para aprender a como resolver uma série de problemas recorrentes que nos deparamos no dia a dia do desenvolvimento de aplicações web.

O que torna no Ruby on Rails tão simples?

Você já ouviu falar em "Convenção sobre Configuração"? Talvez tenha ouvido falar com o nome de "Codificação por convenção"? Não???????

Bem, o Rails é um framework que segue esse conceito. Na prática, o que tal conceito prega é que o desenvolvedor não precisa dizer, ou melhor, configurar, como o framework irá se comportar toda vez que for construir uma aplicação. Isso quer dizer que o framework assume determinadas premissas de funcionamento e que o desenvolvedor só terá algum trabalho se precisar alterar tais premissas (o que só acontece em casos muito específicos).

Alguns exemplos de tais premissas, ou melhor, convenções, são:

  • A comunicação entre a View e o Controller é feita por REST com os verbos HTTP: GET, POST, PUT e DELETE;
  • Alguns métodos de um Controller são mapeados automaticamente aos verbos HTTP: GET é mapeado ao método show, PUT ao método create, POST ao método edit e DELETE ao método destroy.
  • Toda View já possui uma saída HTML, para consumo humano, e uma XML para consumo por um programa (cliente do web service);
  • Não é necessário criar arquivos de Mapeamento Objeto-Relacional. Isso já está embutido em todo modelo;

Essa lista poderia ir longe. A importante mensagem que espero ter passdo com esse pequeno exemplo é: Poupa-se muito trabalho ao utilizar essa abordagem!

Saiba mais sobre Convenção sobre Configuração.

Quer aprender Ruby on Rails e não sabe por onde começar?

Começar aprendendo a linguagem Ruby é sempre uma boa, a final de contas não dá para aprender direito um framework de desenvolvimento sem saber a linguagem que ele utiliza.

Para aqueles que não dispõem se muito tempo e querem aprender Ruby e Rails colocando a mão na massa desde o início, adquira o livro que eu comentei no começo desse post. Mas atenção!!! Esse livro trata da versão 2 do Rails, que já está na versão 3.

Se o Inglês não for um problema e você quiser iniciar o aprendizado na recente versão mais recente, leia o livro "Agile Development with Ruby on Rails (3rd Edition)". Nele você construirá uma aplicação completa de e-commerce onde são abordadas situações reais que enfrentamos no dia a dia do desenvolvimento de aplicações web. Eu lí ambos e recomendo.

Outra boa sugestão é seguir as dicas do Akita sobre como aprender Ruby on Rails. A propósito, o blog dele (http://akitaonrails.com/) é uma ótima maneira de manter-se antenado sobre o que rola na comunidade Rails aqui no Brasil.

Abraços e até a próxima!

quinta-feira, 16 de setembro de 2010

WS-BPEL e os cabeçalhos HTTP de resposta

Nos últimos dias realizamos alguns testes com o GlassFish ESB expondo processos BPEL através de WebServices SOAP de diferentes maneiras. Tais testes foram feitos com dois diferentes padrões de troca de mensagens (MEP - Message Exchange Patterns): Request Only (Também conhecido como InOnly) e Resquest-Response.

Para quem não sabe, o GlassFish ESB possui um componente JBI chamado BPEL Service Engine que é implementação do padrão WS-BPEL. Relembre o que é o padrão JBI.

O motivo de ter feito esses testes é porque no caso dos serviços assíncronos eu estava pensando que, para o cliente saber se a requisição foi aceita pelo provedor do serviço bastaria verificar se cabeçalho HTTP de resposta era o 200 OK. Acontece que não é bem assim que a coisa funciona. Segue abaixo as constatações...

Serviços Resquest Only (São os serviços que estou considerando como sendo Assíncronos)
  • O GlassFish ESB, mais especificamente o BPEL SEsempre (eu disse SEMPRE) retorna o status HTTP/1.1 202 Accepted
    • Esse código indica que "...a requisição do cliente não pode ou não será tratada em tempo real, sendo processada mais tarde. A requisição parece válida, mas pode causar problemas quando for processada. Essa é uma resposta adequada quando uma requisição ativar uma ação assíncrona.". Fonte:http://goo.gl/QEYZ
    • Nesse caso, o provedor do serviço não envia nenhum conteúdo no corpo da mensagem de resposta, ou seja, existe uma resposta mas ela é vazia no sentido que só existe o cabeçalho HTTP de resposta. Isso acontece dessa forma mesmo se o dentro da implementação do serviço (no nosso caso dentro de um BPEL) for gerada uma exception!!! Nesse caso temos que ter muita atenção ao tratamento de erros dentro do BPEL para não deixar a requisição "se perder". Por exemplo, eu forcei a geração de uma exception dentro do processo e, mesmo usando um Throw ou fazendo uma conta de 1/0, o serviço respondeu HTTP/1.1 202 Accepted. Sendo assim o Framework de tratamento de erro que estamos construindo e o seu correto uso tornam-se fundamentais.

Serviços Request-Response
  • O GlassFish ESB... 
    • Retorna o status HTTP/1.1 200 OK quando...
      • A requisição foi processada sem problemas. Esse código indica que... bem, esse tudo mundo sabe, né?!? A diferença para o código 202 Accepted é que nesse caso o serviço enviou um conteúdo no corpo da mensagem. O consumidor do serviço poderá decidir, por exemplo, se precisa realizar alguma outra ação.
    • Retorna o status HTTP/1.1 500 Internal Server Error quando...
      • Dentro do BPEL capturarmos alguma exception, fizermos o devido tratamento e respondermos para o cliente uma mensagem do tipo Fault no corpo da mensagem. Sendo assim, o provedor do serviço também envia algum conteúdo no corpo da mensagem.
O interessante disso tudo foi constatar a fidelidade do GlassFish ESB em relação aos cabeçalhos HTTP de resposta.

Acredito que essas informações possam nos ajudar a desenvolver serviços no GlassFish ESB de forma mais segura (no sentido de saber mais sobre o comportamento da ferramenta) e também implementar consumidores de serviços ainda mais refinados.

Abraços a todos e até o próximo post!

domingo, 25 de julho de 2010

Qual o futuro do GlassFish Open ESB e da sua implementação JBI?

Quando a Oracle anunciou a compra da Sun o assunto principal foi o que aconteceria com o MySQL já que o maior fornecedor de banco de dados comercial estava comprando a empresa que mantinha a maior distribuição de banco de dados open source. Entretanto a minha atenção, e certamente de vários profissionais que trabalham com SOA e integração de sistemas, voltou-se para o GlassFish ESB. Qual seria o futuro do GlassFish ESB e da sua implementação JBI?

Mesmo antes da aprovação da compra da Sun pela Oracle pela Comissão Européia, os mais pessimistas praticamente auto decretaram o fim não só do GlassFish ESB mas um genocídio onde o servidor de aplicação GlassFish e o a IDE NetBeans também estariam com os dias contados.

Passados mais de 6 meses desde a efetivação da compra, podemos considerar como incerto o futuro do GlassFish ESB?. De fato parece que nada concreto está definido por parte da Oracle. No que diz respeito à comunidade que desenvolvia o produto e as empresas que prestavam (e ainda prestam) suporte, as novidades já começam a surgir. O código-fonte do GlassFish ESB e a versão mais atual do OpenSSO estão disponívis em http://www.forgerock.com/. Além disso, está programado para os dias 4 e 5 de outubro de 2010 um encontro na Bélgica para discutir e definir os seguintes pontos em relação ao GlassFish ESB:
  • Definir um novo modelo de governança para a comunidade
  • Definir um novo processo de manutenção e evolução do código-fonte
  • Desenhar o Roadmap para as próximas versões do Open-ESB V2.x e do Fuji (considerada a versão 3)
  • Reorganização das documentações do projeto
O evento contará também com laboratórios, apresentação de casos de sucesso e painéis de discussão e utilização do GlassFish ESB. Temporariamente o site do evento está no endereço http://87.106.30.213:8081/ezpublish/index.php/eng mas em breve estará em definitivo no endereço http://openesb-community.org/.

Voltando ao assunto Oracle... na minha opinião o que acontecerá com o GlassFish ESB é que a Oracle irá portar o padrão JBI para o Oracle Service Bus permitindo que componentes JBI possam ser compostos na implementação SCA (Service Component Architecture). Essa "simples" ação ao menos preservaria o investimento daqueles que possuem utilizam o GlassFish ESB e desejarem migrar o stack Oracle.

Vamos aguardar cenas dos próximos capítulos esperando que boas notícias do passado em relação ao GlassFish ESB possam novamente ser manchete.

[]'s

segunda-feira, 12 de julho de 2010

Correlação de Mensagens utilizando BPEL

Na especificação BPEL correlação é uma funcionalidade importante que precisa ser entendida por aqueles que ou irão projetar processos complexos ou irão desenvolver aplicações que utilizarão tais processos. Isso porque a correlação de mensagens em BPEL (Business Processo Execution Language) é uma das funcionalidades que permitem a elaboração de cenários complexos onde diferentes "parceiros" (partners - consumidores ou provedores de serviços) estão envolvidos na execução de uma instância de processo.

O que é uma instância de processo?

Apenas para que fique claro o que é uma instância de um processo, vamos fazer uma breve analogia à linguagem Java. Quando escrevemos uma classe em um arquivo ".java" estamos codificando a sua definição ou declaração. Ao compilar e executar essa classe em uma máquina virtual Java teremos um objeto dessa classe, ou seja, uma instância da classe. (Logicamente que, dependendo da situação, podemos ter em execução mais de uma instância dessa classe). Sendo assim, podemos fazer a seguinte analogia:

  • Em tempo de projeto ou codificação: 
    • Uma classe Java equivale à definição de um processo;
  • Em tempo de execução: 
    •  A Java Virtual Machine (JVM) equivale a um motor (engine) BPEL;
    • Um objeto Java em uma JVM equivale a uma instância do processo em um engine BPEL.
Entendendo o problema de correlação.

Antes de começar a falar de BPEL (Business Processo Execution Language) e sobre correlação vamos começar entendendo o contexto em que utilizamos a palavra correlação. Segundo o dicionário Michaelis:

correlatar
cor.re.la.tar
(co+relatar) vtd 1 Estabelecer relação mútua. vpr 2 Entrar ou estar em correlação com.


Quando falamos em correlação no contexto de processos e de BPEL, estamos nos referindo a como relacionar diferentes instâncias de um processo aos seus devidos usuários, ou ainda, como correlacionar diferentes mensagens que são recebidas em momentos distintos e eventualmente por fontes distintas.

Vamos a um exemplo prático utilizando o seguinte processo fictício:

Esse processo possui 2 tarefas (ou atividades) que no caso foram chamadas de "1o processamento" e "2o processamento". A dinâmica do processo ocorre da seguinte forma:
  1. Toda vez que uma "Mensagem tipo X" chega ao engine BPEL uma nova instância do processo é criada; 
  2. A tarefa "1o processamento" é acionada de forma a consumir a mensagem;
  3. Como a tarefa "2o processamento" depende da chegada da "Mensagem tipo Y", o engine BPEL coloca instância do processo em pausa para aguardá-la
  4. Quando a "Mensagem tipo Y" chega, a instância do processo sai do estado de pausa e a tarefa "2o processamento" é executada;
  5. O processo termina e a instância é finalizada pelo engine BPEL.
Agora observe a figura abaixo onde há mais de uma instância do processo em pausa, cada uma aguardando a chegada da sua  segunda mensagem. A qual instância de processo o engine BPEL deverá enviar a próxima "Mensagem tipo Y" que chegar?



O que o engine BPEL precisa descobrir é qual instância de processo foi criada pela "Mensagem tipo X" que possui correlação com a "Mensagem tipo Y" que está chegando. Vamos ver como a especificação BPEL trata esse problema?

Como a correlação pode ser implementada?

Quem está acostumado a trabalhar com linguagens de programação web deve estar pensando que isso pode ser facilmente implementado usando sessões (sessions). Mas e se eu dissesse que a especificação BPEL não resolve essa questão utilizando sessões?

O que acontece é que um das principais observações feitas pelo grupo especificou o BPEL é que a maioria das mensagens trocadas entre partners e processos já carregam os dados requeridos para identificar unicamente a instância de um processo, ou seja, dados que tornam possível a correlação de mensagens enviadas em momentos diferente. Por esse motivo a especificação BPEL recomenda que a correlação seja implementada usando dados funcionais da mensagem, ou seja, dados existentes no conteúdo da mensagem. Voltando ao nosso exemplo, poderíamos considerar que a "Mensagem tipo X" seria um pedido de reserva de espaço para um anúncio em um jornal, enquanto que a "Mensagem tipo Y" equivaleria à confirmação da reserva. Nesse caso, as duas mensagens poderiam ser correlacionadas simplesmente por uma ID do anunciante ou por algum outra chave, seja ela simples ou composta, que permitisse identificar unicamente cada pedido.

O grande benefício que a maiorida dos engines BPEL proporcionam é o suporte oferecido por eles para a recuperação da correta instância de processo a partir da correlação de mensagens.

Quer mais detalhes sobre correlação? Sugiro como leitura a parte da especificação BPEL que trata a questão de correlação de mensagens. Em seguida vale conhecer melhor como as ferramentas que você tem disponível implementam essa parte da especificação.

Em um próximo post mostrarei como implementar a correlação de mensagens em um processo BPEL na ferramenta GlassFish ESB.

Até lá !

sexta-feira, 25 de junho de 2010

noSQL - Bancos de dados não convencionais

Há algum tempo vejo alguns amigos comentando casos de sucesso utilizando certos tipos de banco de dados não convencionais. Alguns desses bancos de dados não são baseados em SQL - por esse motivo costumam ser chamados de noSQL - e nem obedecem à Primeira Forma Normal. Tais casos de sucesso referem-se especificamente a um projeto da Apache chamado CouchDB.

Hoje me deparei com essa notícia "Nova classe de banco de dados emerge" no IT Web, o que mostra o aumento da popularidade de tais sistemas gerenciadores de banco de dados (SGBDs).

No caso do CouchDB, por exemplo, ele já possui nativamente uma API RESTful baseada em JSON para manipulação das bases de dados, além de funcionalidades de replicação e distribuição.

Trata-se de um paradigma bastante diferente dos bancos de dados que estamos acostumados a trabalhar, ou seja, sem utilizar SQL e sem complicados clientes e drivers. Para comprovar isso basta escolher a sua linguagem de programação nesses exemplos de utilização do CouchDB. São exemplos básicos mas que transmitem um pouco a idéia de funcionamento de um banco noSQL.

Já existe até encontros de usuários noSQL. No começo desse ano aconteceu um deles em São Paulo que abordou diferentes aspectos e implementações desse tipo de sistemas gerenciadores de banco de dados.

Vale acompanhar mais de perto a evolução dessa tendência tecnológica e especialmente os benefícios que tal paradigma pode trazer para aplicações da indústria de mídia.

Até a próxima!

domingo, 7 de fevereiro de 2010

JBI - "O barramento dentro do barramento"

Java Business Integration, ou simplesmente JBI, é um framework que define uma arquitetura de integração de componentes plugáveis e um modelo de troca de mensagens entre esses componentes. Nessa arquitetura, diferentes componentes podem ser conectados a um mediador de mensagens, e interoperar ou colaborar com os demais componentes do ambiente. O JBI é especificado pela JSR-208.
Existe uma maneira bem fácil de entender a arquitetura do JBI. Imagine um barramento de serviços (ESB) de uma Arquitetura Orientada a Serviços (SOA). Provavelmente você deve ter imaginado uma imagem parecida como a abaixo.

Figura 1 - Visão de uma arquitetura SOA com ESB

 Se esse não foi o caso, não tem problema. O que acontece é que a maioria dos desenhos que explicam um barramento de serviços possui um formato como esse, onde:
  • Camada 1: Trata-se dos serviços, ou seja, da exposição de funcionalidades e/ou regras de negócio de sistemas existentes;
  • Camada 2: Representa a interação dos serviços com o barramento para colaboração com os demais serviços ligados ao barramento. Quando falamos de web services, essa camada poderia ser, por exemplo, SOAP ou REST;
  • Camada 3: É o barramento de serviços ou ESB, que faz a mediação da comunicação entre os serviços.
Antes de fazer a analogia de SOA com a arquitetura JBI precisamos conhecer alguns integrantes de um ambiente JBI. São eles:
  • Binding Components (BC): São componentes que fazem a ligação do ambiente JBI com o mundo externo. Eles são as portas de entrada e saída para o ambiente JBI;
  • Service Engines (SE): São componentes do ambiente JBI que processam dados que chegam através dos Binding Components e, quase sempre, enviam uma resposta através do mesm ou ou de outro Binding Component;
  • Normalized Message Router (NMR): BCs e SEs se comunicam trocando mensagens padronizadas. Essa comunicação é mediada pelo NMR.
Provavelmente você já deve ter começado a encaixar os BCs, SEs e o NMR na figura que apresentamos acima. Vamos ver como ficaria isso?

Figura 2 - Visão de uma arquitetura JBI
 
Por questões didáticas mostramos os SEs na parte de cima da Camada 1 e os BCs na parte de baixo. A Camada 2 representa a forma de comunicação entre BCs e SEs através do NMR, que por sua vez está na Camada 3. Em linhas gerais, a dinâmica de funcionamento típico de um ambiente JBI segue o seguinte processo:
  1. Uma mensagem chega em um BC através de algum protocolo de comunicação (Ex: SOAP, REST, JMS, FTP, CIFS, SMTP etc);
  2. O próprio BC normaliza a mensagem, ou seja, padroniza a menssagem para que ela possa trafegar dentro do ambiente JBI e chegar até um SE ou outro BC;
  3. O BC envia a menssagem normalizada para o NMR;
  4. O NMR entrega a mensagem para um SE;
  5. O SE processa a mensagem e devolve a resposta para o NMR;
  6. O NMR envia a mensagem de volta ao BC original ou a outro BC.
  7. O BC que receber a mensagem desnormaliza e transforma a mensagem para o padrão de comeunicação implementado por el (Ex: SOAP, REST, JMS, FTP, CIFS, SMTP etc).
Essa é a visão estrutural de como um ambiente JBI funciona. Quando digo "ambiente JBI" refiro-me a qualquer servidor que implemente a especificação JBI. Alguns servidores que implementam são: Oracle Glassfish ESB (Open ESB), Apache Service Mix, Petals ESB etc.
Cada um desses produtos possui um conjunto de implementações de Binding Componentes e Service Engines. As figuras abaixo representam um resumo dos BCs e SEs implementados pelo Apache Service Mix e pelo Oracle GlassFish ESB. Inclusive percebe-se que foi a imagem do Service Mix que eu utilizei como exemplo para fazer a analogia com SOA :-)
Figura 3 - Alguns componentes do Apache Service Mix

A listagem completa dos componentes implementados pelo Service Mix está |aqui|.
Figura 4 - Alguns componentes do Oracle GlassFish ESB
 
A listagem completa dos componentes implementados pelo GlassFish ESB está |aqui|.
Na prática o que podemos fazer em um ambiente JBI?

Como o JBI é baseado em troca de mensagens através do NMR, existem alguns padrões de trocas de mensagens (Message Exchange Patterns) definidos na especificação, tais como In-Only, In-Out, Robust In-Only, In Optional Out etc [1][2]. Não entrarei nesse nível de detalhe aqui nesse post. Por outro lado, vamos a alguns casos de uso práticos desses padrões:
  • Configurar um JMS BC para escutar uma fila JMS e, ao chegar uma mensagem, redirecionar o seu conteúdo para um web service implementado usando SOAP através do SOAP BC ou HTTP BC;
  • Orquestrar diferentes serviços disponibilizados como SOAP (SOAP BC ou HTTP BC) ou EJB (EJB SE);
  • Expor como um web service a view de um banco de dados, ou seja, implementar um Data Services;
  • Monitorar uma pasta de rede através de CIFS (File BC) ou FTP BC e, ao chegar um arquivo, processar seu conteúdo de forma a inserí-lo em um banco de dados através de JDBC;
Certamente você seria capaz de fazer tudo isso usando sua linguagem de programação predileta e com a ajuda de algumas bibliotecas e frameworks. O grande benefício do uso de um JBI é que você consegue fazer isso tudo de maneira muito fácil, rápida e sem escrever praticamente nenhuma linha de código. Isso porque ao invés de programar você apenas configura os componentes para funcionarem da forma desejada e colaborarem para, em conjunto, atinginrem os requisitos e objetivos desejados.
Enfim, são várias as possibilidades de integrações que  podem ser implementadas. Tudo depende da necessidade, das implementações de BCs e SEs disponíveis no ambiente que você escolher e também, por que não dizer, da sua criatividade.
Finalmente, qual o motivo desse post ter o título "O barramento dentro do barramento"?

Isso deve-se ao fato da possibilidade de uso do JBI como um ESB. Como o JBI possui um "barramento" interno, que é o NMR, ao usar o JBI como um ESB teremos "um barramento (NMR) dentro do barramento (ESB)". Na prática, o que faríamos seria:
  1. Conectar serviços ao barramento (ESB) através do BC apropriado, ou seja, de acordo com o protocolo falado pelo serviço;
  2. Escolher o SE apropriado para processar a requisição de um serviço (Ex: rotear, log, transformar mensagem etc); e
  3. Devolver uma resposta, se necessário, através do BC original ou de um outro BC, caso o protocolo de resposta seja diferente do protocolo da requisição original.

domingo, 17 de janeiro de 2010

Java EE 6 e GlassFish v3 no Sun Tech Days 2009-2010

Em meados de dezembro estive em São Paulo participando do Sun Tech Days 2009-2010. Escrevi um post para o Beta - Blog (da equipe) de Tecnologia do Jornal O Globo. O post foi comentado no site da Sun.

segunda-feira, 11 de janeiro de 2010

Open source ESB

Ao acender das luzes de 2010 foi lançada a nova versão do GlassFish Open ESB, um barramento corporativo de serviços que é a ferramenta principal de uma SOA, que implementa o JBI (JSR-208) e é suportado pela Sun.

Nessa nova versão, além de algumas correções de bugs, o GlassFish ESB v.2.2 teve mais 3 componentes JBI promovidos para o status Released, o que significa que eles passam a ter suporte comercial da Sun uma vez que passaram pelo processo de teste e QA (Quality Assurance). São eles:

  • Email Binding Component: Um Binding Component que suporta a configuração e conexão a servidores de email permitindo o envio e o recebimento de mensagens;
  • REST Binding Component: Um Binding Component que fornece conectividade de e para o barramento através de RESTful webservices, ou seja, agora sistemas externos poderão invocar usando REST as aplicações compostas hospedadas no GlassFish ESB assim como tais aplicações poderão acessar web services REST;
  • POJO Service Engine: Um Service Engine que permite a definição da lógica de negócio usando Java no estilo Plain Old Java Objects de forma simples e flexível.

Além disso, enquanto a versão 2.1 do GlassFish ESB vinha com o NetBeans 6.5, a nova versão é disponibilizada com o NetBeans 6.7.1.

Outra novidade é que a Sun criou 2 pacotes adicionais: Sun GlassFish ESB Health Care Pack e o Sun GlassFish ESB Platinum Pack. O que são eles?

Sun GlassFish ESB Health Care Pack: Um pacote que implementa facilidades para o uso de certos padrões de sistemas da área médica, como por exemplo o HL7 e o PIX/PDQ.

Sun GlassFish ESB Platinum Pack: Trata-se de um pacote que extende as funcionalidades do pacote padrão possuindo componentes adicionais tais como:
  • Worklist Manager Service Engine: Um Service Engine que permite a definição de processos human-centric que objetivam a automação de tarefas manuais e a implementação de workflows;
  • IEP Service Engine: Um Service Engine que implementa funcionaliade de Complex Event Processing (CEP) e Event Stream Processing (ESP).
  • COBOL Copybook Encoder: Um codificador baseado em campos de tamanho fixo que possibilita a definição e teste de COBOL Copybook encoders com suporte para runtime;
  • BPEL Monitor: Tratase de uma ferramenta de monitoração em tempo real dos processos implementados usando o BPEL Service Engine
  • Event Management Console: Trata-se de uma ferramenta de monitoramento e emissão de alertas sobre eventos ocorridos em aplicações hospedadas no GlassFish ESB.
Mas nem tudo são flores nesse lançamento. Tão logo a novidade foi anunciada, a comunidade do Open ESB começou a questionar o fato do código-fonte das novas versões do Worklist Manager e do IEP não terem sido disponibilizados. Especulações a parte, o fato é que isso pegou de surpresa alguns membros da comunidade que estavam participando do desenvolvimento uma vez que o repositório de fontes não teria sido devidamente atualizado com a nova versão e eles ficam sem saber o que fazer com o que estava no seu Sandbox. A discussão segue no Forum dos usários do Open ESB.