Pode existir SOA com REST?

Essa semana assisti a gravação de uma apresentação de um arquiteto da plataforma de comércio eletrônico da EBay (Sastry Malladi). A apresentação, realizada na QCon de 2010 (San Francisco, USA), fala sobre algumas formas de implementar serviços REST (RESTful services) numa arquitetura orientada a serviços (SOA) que normalmente contem serviços SOAP e os padrões WS-*.


A apresentação é mais uma demonstração prática de que serviços REST podem ser parte integrante de SOA. Na minha opinião poderíamos ir até mais longe. Isso porque eu arriscaria dizer que serviços REST devem ser sempre considerados pois nem sempre é necessário implementar os padrões WS-*.


Um ponto interessante na apresentação foi a utilização de JAXB para gerar representações em formatos JSON, coisa que por coincidência eu venho implementando juntamente com o Jersey. A flexibilidade oferecida pela dobradinha Jersey e JAXB é muito boa e me lembrou um pouco o Ruby on Rails. Pretendo em breve falar mais sobre o assunto aqui no blog.

Um ponto que a demonstração prática deixou a desejar foi mostrar com mais detalhes o uso dos XMLs de mapeamento. Fiquei com a impressão de que muito código deve ser construído e mantido para suportar as integrações, coisa que uma ferramenta de ESB ou EAI tiraria de letra.

A apresentação, sugerida pelo meu amigo e arquiteto de integração Carlos Alberto Filho, está no site da InfoQ em http://www.infoq.com/presentations/RESTful-SOA-in-the-Real-World

Adotando padrões SOA de maneira alternativa

Achei bastante interessante a maneira "alternativa" que essa ferramenta de repositório de serviços implementa certos padrões de SOA que lemos frequentemente na teoria:

• UDDI: http://goo.gl/oqWgJ
• Registro/Repositórios: http://goo.gl/GO9lP
• Testes de serviços: http://goo.gl/Idb6y

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:

• Nested Model Form - Part 1:
• Nesse vídeo, a aplicação de Pesquisa é criada;
• Nested Model Form - Part 2:
• E nesse, é adicionado suporte a Ajax.

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!

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 SE, sempre (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!

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

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á !

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!

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.

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.

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.

SOA Manifesto

Durante o 2nd SOA Symposium Conference, realizado no último final de semana, foi publicado o SOA Manifesto, um conjunto de princípios e intenções que deveriam fundamentar qualquer iniciativa de SOA.

Aqui vai uma tradução do manifesto, que pode ser encontrado na sua versão original em http://soa-manifesto.org/.

Orientação a serviços é um paradgma que modela o que fazemos. Arquitetura Orientada a Serviços (SOA) é o tipo de arquitetura resultante da aplicação da orientação a serviços. Aplicamos orientação a serviços para auxiliar organizações a entregarem valor de negócio de maneira consistente e sustentável, de forma cada vez mais ágil, com custos efetivos e em linha com as voláteis necessidades de negócio.

Priorizamos:

Valor de negócio em relação à estratégia técnica
Objetivos estratégicos em relação à benefícios específicos de/para o projeto
Interoperabilidade inerente em relação à integração customizada
Serviços compartilhados em relação à implementações específicas
Flexibilidade em relação à otimização
Refinamento evolutivo em relação à perfeição inicial

Apesar dos itens da direta terem seu valor, valorizamos mais os itens da esquerda.

O manifesto conta ainda com uma lista de princípios que podem servir como guia na adoção de SOA: http://soa-manifesto.org/principles.html.

IT BSC e a Arquitetura de TI

O Balanced Scorecard (BSC), criado por Robert Kaplan e David Norton na década de 90, é um framework para medição do desempenho corporativo. Criado a partir de uma pesquisa realizada em 12 empresas de grande experiência em medidas de desempenho coorporativo, o BSC permite que a alta gerência tenha uma visão ampla de diferentes aspectos do negócio possibilitando acompanhamento da sua dinâmica. A proposta é que sejam identificados objetivos e medidas em 4 perspectivas que visam responder algumas perguntas genéricas:

• Financeira: Como os acionistas vêem a empresa?
• Cliente: Como os clientes vêem a empresa?
• Processos Internos: Em que a empresa tem que ser excelente?
• Aprendizado e Crescimento: Onde e como a empresa pode inovar e gerar mais valor?

Para informações mais detalhadas do BSC sugiro o artigo da Harvard Business Review intitulado "The Balanced Scorecard - Measures that Drive Performance".

Quase uma década mais tarde, Kaplan e Norton identificaram a importância do relacionamento das medidas nas 4 perspectivas e das suas relações de causa e efeito como critério de sucesso para atingimento dos objetivos propostos pelo BSC. Foi então que eles criaram o chamado "Strategy Map" representado pela figura abaixo, que foi extraída do artigo original escrito por eles.

Tendo sido amplamente adotado na esfera de negócio, o BSC e o Mapa Estratégico passaram também a ser aplicados em TI, sendo que nos últimos anos começaram a surgir casos de sua aplicação.

Aplicadas em TI e batizadas de IT BSC (Information Technology Balanced Scorecard), as 4 perspectivas do BSC foram adaptadas e ficaram assim:

• Contribuição para o negócio: Como as gerências das áreas de negócio (clientes) vêem a área de TI?
• Orientação ao Cliente: Como os usuários vêem o departamento de TI?
• Excelência Operacional: O quanto eficiente e eficaz são os processos de TI?
• Orientação ao Futuro: O quanto TI está preparada para atender as necessidade futuras do negócio?

Dentre as lições aprendidas dos casos de aplicação do IT BSC está a importância do seu relacionamento com o BSC corporativo. 

É justamente esse relacionamento que na prática pode representar o tão falado "alinhamento de TI ao negócio". A final de contas, quando falamos desse "alinhamento", estamos nos referindo ao alinhamento dos objetivos das duas áreas.

Resumindo, o BSC é a ferramenta que além de promover esse alinhamento pode ser utilizada para definir, comunicar e acompanhar a execução das estratégias corporativa e de TI estando intimamente ligado ao dia-a-dia de trabalho de cada colaborador.

Mas o que isso tem a ver com Arquitetura de TI? 

Vamos olhar mais de perto um exemplo de IT BSC detalhando suas perspectivas:

Considerando que os principais processos da área de arquitetura de TI são:

• Construção da arquitetura atual (As-is);
• Construção da arquitetura futura (To-be);
• Análise de defasagem (Gap analysis); e
• Criação do mapa diretor (Roadmap), 

Temos que a evolução da arquitetura de TI pode ser medida pelo progresso de implementação do roadmap em direção à arquitetura futura. 

O roadmap, também chamado de plano de evolução, determina padrões técnicos e arquiteturais a serem seguidos. Tais padrões servem de base para a medição da aderência ao plano que é um dos objetivos da perspectiva Orientação ao Futuro em um IT BSC. Vale ressaltar ainda a importância de serem definidos marcos para auxiliar o acompanhamento e a medição do desempenho.

Erros comuns na adoção de SOA

Essa semana assisti um vídeo no Youtube sobre erros comuns na adoção de SOA. Trata-se de um apresentação do David Linthicun com o nome "5 coisas a serem evitadas ao adotar SOA". Além de dar dicas sobre caminhos a não serem seguidos, David Linthicun mostra, em alto nível, uma metodologia de adoção de SOA.

Os 5 erros apresentados são:

1) Usar as pessoas erradas ao compor o escritório de arquitetura ou o chamado SOA CoE (Center of Excelence);
2) Selecionar a tecnologia muito cedo. (Comece pelos requisitos!);
3) Não considerar o design de serviço;
4) Não ter o foco nas necessidades do negócio;
5) Não pensar a longo prazo e de maneira estratégica (Pense grande, inicie pequeno e evolua rápido).

Como não era de se esperar, vemos logo no primeiro erro a importância que deve ser dada às pessoas. A final de contas é difícil conseguir bons profissionais com um perfil generalista de atuação em todas as áreas da Arquitetura de TI (Processos/Negócio, Informação, Sistemas, Integração e Tecnológica) ou nem sempre a empresa tem condições de bancar um profissional com experiência na área. Essa mesma importância dada às pessoas é ressaltada no artigo do Gartner denominado "Horror Story Shows How Poor Governance Leads to Failure in SOA Initiatives", que diz:

"Terceirizar arquitetos ou não tê-los de maneira adequada, significa que a empresa não possuirá as competências necessárias para um projeto SOA."

Esse mesmo artigo do Gartner diz ainda:

"Crie um ICC (Integration Competence Center) ou um SOA CoE (SOA Center of Excelence) que inclua membros das áreas de negócio e desenvolva-o. Você precisará de um para se certificar que o projeto de adoção de SOA está no caminho certo."

Sobre o erro 2, selecionar a tecnologia muito cedo, o artigo do Gartner também está alinhado. O artigo diz que as pessoas tendem a associar SOA com tecnologia e que se um projeto SOA falha é devido a escolha da tecnologia errada. Entretanto várias projetos falham pela falta de importância dada à governança.

Em linhas gerais a metodologia sugerida pelo David Linthicun é composta dos seguintes passos:

1) Entenda os objetivos de negócio e defina critérios de sucesso;
2) Defina o domínio do problema;
3) Entenda todas as aplicações envolvidas;
4) Descubra e entenda todos os serviços no domínio do problema;
5) Descubra e entenda todos os processos no domínio do problema;
6) Identifique a necessidade de criar novos serviços;
7) Identifique a necessidade de criar novos processos;
8) Selecione as tecnologias e ferramentas a serem usadas.

O vídeo da apresentação pode ser encontrado em http://www.youtube.com/watch?v=0CbjUNzBV6I&feature=channel

Os slides estão aqui...

Curso Plataforma SOA Open Source

Quer fazer um curso gratuíto sobre plataforma SOA? A WSO2 está oferecendo um curso com oito módulos sobre suas ferramentas Open Source.

WSO2 é um conjunto de produtos SOA que além de open source são gratuítos. Há algum tempo venho estudando principalmente o Barramento de Serviços (ESB) denominado WSO2 ESB e em breve teremos alguns posts sobre ele aqui.

A plataforma WSO2 é composta dos seguintes produtos:

• Enterprise Service Bus: Uma implementação de um Barramento de Serviços (middleware);
• Registry: Uma ferramenta de governança com a função de armazenar, catalogar, indexar e gerenciar metadados de serviços;
  
• Identity Solution: Uma ferramenta de gerenciamento de identidade com funcionalidades de single sign-on e que pode ser integrada com o CardSpace e OpenID;
  
• Data Services: Uma ferramenta que permite expor como WebServices os dados existentes em banco de dados, arquivos texto (Ex: CSV), Servidores LDAP etc. Isso é feito implementando ainda alguns padrões WS-* ou através de REST;
  
• Business Process Server: É um motor (engine) BPM que executa processos através do padrão WS-BPEL (Antigo BPEL4WS). Essa ferramenta não inclui um diagramador de processos, ela é apenas um orquestrador de WebServices;
  
• Web Services Application Server: Um servidor web composto de uma série projetos do Apache onde são hospedados webservices implementados com o Axis2.
  
• Web Sevices Framework: Um framewor para desenvolvimento de Web Services e seus clientes para as linguagens C, PHP, Perl, Python, Ruby, Spring, C++ e Jython;
  
• Mashup Server: Uma ferramenta que permite compor e personalizar Web Services, Feeds, páginas web etc.

Nada mal, hein?!! Mas voltando ao papo do curso gratuíto, trata-se de uma ótima oprtunidade para entender melhor os conceitos por trás de SOA e conhecer essas ferramentas. Para isso, basta se cadastrar clicando na imagem abaixo.

Os cursos acontecem sempre às sextas-feira das 13:00 às 16:30 a partir de 18 de junho de 2009.

Artigos Publicados - Mestrado NCE

Esse post não tem muito a ver com Arquitetura de TI mas tem um motivo nobre.
Abaixo estão os links para os artigos escritos por mim que foram publicados em conferências internacionais:

• A Multicriteria Approach to the XP Release Plan that Maximizes Business Performance in Uncertain Environments - Proceedings of the 2008 IEEE Systems and Information Engineering Design Symposium (SIEDS), University of Virginia, USA, April, 2008.
• An Extreme Programming Release Plan That Maximizes Business Performance - (2008 International Conference on Enterprise Information SystemsICEIS), Barcelona, Spain, June, 2008;

Para acessar o segundo link será necessário fazer um cadastro no IEEE Xplorer. Se ainda assim você não conseguir visualizar o artigo, me envie um email que eu mando para você.

Arquitetura de TI

Vamos começar explicando as razões da existência desse blog recorrendo o método 5W2H.

What?

• Posts sobre temas relacionados à Arquitetura de TI.
  

Who?

• O pontapé inicial é por minha conta, tendo a contribuição de todos que se interessam e praticam o assunto.
  

When?

• Pelo menos 1 post meu por semana. Essa é a meta!
  

Why?

• Para trocar experiências, compartilhar e gerar conhecimento sobre Arquitetura de TI.
  
• Para sair da teoria e desmistificar assuntos relacionados a integração de sistemas tais como ESB (Enterprise Service Bus), SOA (Service Oriented Architecture), REST, WS-*, BPM (Business Process Management) etc.

Where?

• Exemplos práticos preferencialmente através do uso de ferramentas OpenSource e em ambiente Linux fazendo uso de padrões abertos.
  

How?

• Evitando assuntos que envolvam discussões filosóficas mas sendo fiel aos fundamentos.
  
• Desvendando na prática o dia-a-dia de quem trabalha com Arquitetura de TI, suas ferramentas, práticas, metodologias, gorvernança, métricas etc.
  

How much?

• Da teoría à prática, entrando no detalhe, no estilo "A vida como ela é".