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

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

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.

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.

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.

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 é".