JBoss SOA: Suporte Enterprise a BPEL

Já está disponivel para download, o mais novo projeto da JBoss como foco especial em BPEL. Trata-se do projeto RiftSaw. Ele se baseia num motor de runtime para executar processos BPEL compatíveis com a versão 2.0. Para controle e desenho de orquestrações, já está disponivel também um BPEL Designer, encontrado junto com o projeto JBoss Tools.

Seguem alguns screenshots de um exemplo que fiz para o evento Just Java, sobre um cenário de uma consulta de saldo para celulares de pré-pago. O projeto, foi integralmente feito usando tecnologias JBoss (JBoss AS 5.1 + BPEL Server + BPEL Designer + JBoss Web Services).

Em breve, todas estas tecnologias estarão presentes no JBoss SOA Platform e suporte enterprise a estas tecnologias estará disponivel. Assim que tiver um tempo livre, posto aqui o passo a passo de como criei este projeto. Mas quem conhece BPEL e um pouco de tecnologias JBoss, não terá dificuldades de criar um cenário nestas tecnologias.

JBoss Rocks ;-)

Orquestração de Serviços SOA com Soluções Abertas

Olá pessoal. Deixo disponível aqui o link da palestra que proferi semana passada no evento Just Java 2009, em conjunto com o Edgar Silva. Na ocasião, falamos bastante sobre orquestração de serviços focando na prática, citando alguns cases de cenários de orquestração usando BPEL e tecnologias de processos persistentes.

Orquestração de Serviços SOA com Soluções Abertas e Java

View more documents from Ricardo Ferreira.

Boa Leitura!

Architecture Journal (Ricardo Ferreira) Blog now in English

Hey folks! I'm glad to share with you some changes in the Architecture Journal Blog. Some posts made will be written in English idiom. I'm going to change this because for my happiness, there are many users of this blog outside of Brazil, and they constantly ask me for posts in English. I think that this will be good for all of us, since this approach will promote clarity of text comprehension, improvements on the quality of the explanations and of course, my posts will be available for users that don't understand Portuguese.

For the Brazilian's folks, questions can be made on Portuguese or English, and I'd like to thank you for all of them that supports, help and read my blog. It has been made specially for you ;-)

Best Regards,

jBPM 4.1: BPMN Designer na Web

Foi lançado pouco antes do inicio do JBoss World a mais nova versão do jBPM, a versão 4.1. Esta versão, além de apresentar melhoras significativas desde o lançamento oficial da versão 4.X, trouxe uma melhoría fantástica: um designer de processos que funciona 100% via web. Agora, usuários do jBPM podem modelar seus processos usando a notação BPMN (novidade já presente desde a versão 4.X) porém com uma ferramenta que necessita de instalação zero; apenas um browser é necessário para utilizar o designer.

Este designer web além de simples de instalar, é muito simples de usar. Quando baixei a ultima versão do jBPM, precisei configurar apenas o repositório do jBPM num banco de dados MySQL (poderia usar o padrão do HSQLDB) e executei um script Ant que faz o processo de instalação. Até mesmo o download do JBoss AS 5.0 ele faz sozinho.

Para manusear o desginer, basta iniciar o servidor de processos (O JBoss + jBPM Runtime) e acessar a seguinte URL: http://localhost:8080/jbpmeditor/p/explorer. Ao acessar a URL, você será encaminhado para o workspace de desenvolvimento, onde você pode criar pastas e processos, e estruturar sua base de conhecimento.

Este novo designer é baseado no projeto open-source Oryx, uma ferramenta de modelagem de processos que usa linguagens como BPMN, XForms e EPC para modelagem, e que provê cartuchos genéricos para geração de uma definição de processo específica. No caso do jBPM, foi criado um conjunto de plugins da ferramenta que fazem a geração do jPDL, linguagem de processos nativa do jBPM. Com isso, você pode criar processos numa linguagem agnóstica de fornecedor (BPMN) e gerar processos em diferentes linguagens específicas.

Pra quem lembra dos releases anteriores do jBPM, sabe que foram feitos esforços consideráveis na construção da PVM (Process Virtual Machine), mecanismo de runtime do jBPM para execução de processos orientados a grafos, onde a linguagem de processo nã o importava. Com a máquina de execução pronta (resultado do release 4.0), agora era hora de investir na ferramenta de authoring, e por isso, a versão 4.1 nos reserva este presente super interessante.

Pra demonstrar o poder desta nova versão, vou mostrar um exemplo completo de como o jBPM funciona agora. Iremos construir um processo no designer web; fazer o deploy deste processo no servidor de processos; criar uma aplicação Java que inicia uma nova instância do processo; monitorar o estado e execução do processo usando a ferramenta de BAM (jbpm-console) e por último, iremos sinalizar a instância do processo para que o mesmo seja executado.

Criando um novo processo no designer web

A primeira coisa a ser feita, é criar uma pasta onde o processo será armazenado. Para isso, clique no botão "New" situado na barra de ferramentas superior e escolha a opção "Folder". Digite "jbpmPoc" na janela que se abre e clique no botão "OK". Será criado a pasta dentro do workspace. Clique duas vezes em cima da nova pasta para entrar nela. Feito isso, clique novamente no botão "New" e escolha a opção "jPDL". Será aberto um editor de processos, com um processo em branco.

Estando no editor de processos, vá até a paleta de elementos (Share Repository) e arraste um elemento do tipo "Start Event" até o diagrama central. Este elemento representa o inicio de um processo de negócio segundo a notação BPMN. Feito isso, clique no elemento "Start Event" que está no diagrama. Você irá perceber que opções visuais são mostradas no elemento quando você faz isso.

Estas opções são atalhos para que você crie o processo iterativamente. Quando você seleciona uma destas opções, o designer já cria o próximo exemplo, ligando o elemento criado com o elemento selecionado através de um "Sequence Flow". Usuários do Enterprise Architect deve se sentir familiarizados com este recurso. Clique no botão de atalho "Task" para que ele já crie uma tarefa no designer. Depois de criar a tarefa, clique na tarefa criada, e depois clique no botão de atalho cujo ícone é uma ferramenta. Esta opção faz com que você possa alterar o tipo do elemento. Altere para um "Wait".

Modele o processo até que ele esteja como mostrado abaixo. Iremos com base neste simples cenário, fazer o deployment do processo e executá-lo dentro do JBoss.

Vamos salvar este processo. Para isso, clique no botão "Save" situado na barra de ferramentas. Ele possui o ícone de um disquete. Será apresentado uma caixa de diálogo para definições do processo. Na caixa do nome do processo, entre com "atualizar-versao". Nas demais caixas, digite o que você quiser. Ao confirmar a criação do processo, você irá voltar para a janela de workspace, e vocẽ verá que o arquivo do processo fora criado com sucesso.

Fazendo o deploy do processo no servidor de processos

Para fazer o deploy deste processo no servidor de processos, você deverá criar um arquivo JAR contendo o arquivo atualizar-versao.jpdl.xml. Os arquivos criados pelo editor web são armazenados na pasta de instalação do jBPM, num diretório chamado "${signavio.repo.path}". Gere um arquivo JAR contendo o arquivo do processo, e dê o seguinte nome ao arquivo: atualizar-versao.bar. A estensão "BAR" é uma estensão que é monitorada pelo jBPM Server. Quando ele detecta este tipo de arquivo, ele sabe que se tratar do deploy de um novo processo de negócio, ou da atualização de um existente. Gerado o arquivo, copie-o para a pasta deploy do seu servidor de processos.

Para verificar se o processo foi implantado corretamente, você deve acessar o jBPM Console. Estando nele, vá até o menu "Runtime" e escolha a opção "Process Engine->Deployments". Na janela que se abre, deverá aparecer uma entrada contendo o seu arquivo de deployment, e logo abaixo nos detalhes, as informações sobre o processo de negócio.

Executando o processo e monitorando-o através do BAM

Vamos agora deixar as coisas ainda mais interessantes. Vamos criar um programa Java que conecta com o servidor de processos e solicita a criação de uma nova instância do processo de atualização de versão. Quando fizermos isso, iremos na verdade fazer com que o processo seja executado na máquina virtual do jBPM (PVM) e que o jBPM Console possa monitorar os estados e atividades de execução do mesmo. Para isso, clique um programa Java como mostrado na listagem abaixo:


Execute este programa Java. Lembre-se que antes de executar você deve configurar um arquivo jndi.properties, já que você está tentando acessar o contexto JNDI do JBoss de outro JVM. Depois de executar o programa, acesse novamente o jBPM Console. Vá até o menu "Processes" e selecione a opção "Process Definitions->Definitions List". Será exibido a lista de processos existentes no servidor. Selecione o processo "atualizar-versao" e clique na aba "Process Instances". Você verá que irá ser listado uma entrada na lista de instâncias, correspondente a instância que foi criada a partir da execução do programa Java.

Ainda no jBPM Console, clique no botão "Diagram". Clicando neste botão habilita que você veja o desenho do processo, e principalmente, ele mostra visualmente a você em que etapa do processo ele atualmente se encontra.

Clicando no botão "Instance Data" é possível visualizar as variáveis que foram enviadas para o processo via o programa Java (ou qualquer outro componente):

Um programa Java que sinaliza a instância do processo

Para finalizarmos nosso exemplo, vamos criar outro programa Java que, irá conectar no servidor de processos novamente, só que ao invés de criar uma nova instância, vai acessar a instância existente e enviar um sinal (Token.signal() para os usuários de jBPM de longa data) fazendo com que o mesmo se movimente. A listagem abaixo mostra como este programa deve ser implementado:

Execute este programa Java. Depois disso, volte ao jBPM Console, e analise a figura que mostra a situação do processo. Agora, ele deverá estar assim:

Fechando com chave de ouro, existem no jBPM Console algumas surpresas relacionadas a métricas e KPI's. Vá até o menu "Reporting" e acesso o item "Available Reports->Processes". Selecione os vários relatórios existentes no menu superior da ferramenta. Estes relatórios são na verdade relatórios baseados em Birt, e por isso, significa que você pode alterá-los como bem quiser, assim como criar os seus próprios. Tendo isso em mente e conhecendo o poder da API do jBPM sobre eventos e listeners, você facimente cria uma solução robusta e personalizada de BAM onde métricas poderão ser visualizadas através de relatórios e gráficos com recursos visuais super poderosos.

Espero que este post tenha mostrado um pouco das capacidades do jBPM. As próximas versões prometem features cada vez melhores e a abordagem do designer baseado na web veio para ser um forte recurso da nossa solução para inicitativas do tipo BPM Colaborativo ou PaaS (Process as a Service). Imagine você podendo criar processos em colaboração com parceiros da sua empresa, ou até mesmo empresas de parceiros. Próximas edições do jBPM e do Guvnor prometem maior interoperabilidade entre estes projetos, fazendo com que o Guvnor possa ser o repositório de processos do jBPM, assim como ele já o faz para regras e demais artefatos do BRMS.

JBoss Rocks ;-)

JBoss SOA Platform: Soluções SOA com Produtividade!

"O JBoss é bom, mas dá muito trabalho mexer com ele." ... "O problema do JBoss é que você deve fazer tudo usando XML" ... "Gosto do JBoss ESB, mas ele não me trás produtividade" ... "O AquaLogic é melhor porque consigo construir soluções SOA visualmente" ...

Estas são algumas frases que infelizmente, ainda são ditas pelos usuários de JBoss. As soluções JBoss com o passar dos anos foram (e ainda são) referência no que tange a inovação tecnológica, alinhamento com especificações do JCP e para os desenvolvedores de longa data, uma plataforma simples e estável para aplicações críticas. Mas quando falamos de aspectos de desenvolvimento de soluções, estamos falando de utilizar ferramentas e tecnologias que nos ajudem a fazer as coisas mais rápido, com maior segurança e com maior produtividade.

Vamos refletir um pouco sobre isso. Produtividade está relacionado com diversos aspectos. Um deles, e IMO, o principal deles, é conhecer a tecnologia. Se você entende bem a tecnologia que você usa para construir soluções, você será produtivo, mesmo não usando ferramentas visuais. Pessoas não experimentadas na tecnologia JBoss (e JEE em geral) quando usam o JBoss para construir aplicações, têm a sensação de que as coisas são muito dificeis e complicadas, e que uma ferramenta bonita e visual iria ajudar muito as coisas. Se a frase "Ignorância é uma benção" for realmente verdade, então isso faria sentido.

Mas descordo neste aspecto. Usar ferramentas bonitas e visuais apenas escondem detalhes que você deveria conhecer e o faz não explorar todo o poder da tecnologia. Já usei diversas soluções de JEE, SOA e BPM de diferentes fabricantes (além de JBoss) e em minha experiência, nenhuma delas, seja BEA, IBM, webMethods, Oracle ou TIBCO fugiu da situação: "Quando você precisa de algo mais audacioso e diferente, você precisa abrir a caixa e mecher no motor". Se você usa somente o trivial das ferramentas, você está usando somente as features que o fabricante quer que você use. Você é induzido a aplicar uma linha de raciocínio que lhe restringe possibilidades, que deixa você fechado quanto a personalização de soluções.

OK, mas o que têm isso a ver com JBoss? Bem, a mensagem a ser entendida é a seguinte: JBoss promove soluções que funcionam e que produzem valor. Pensamos primeiro em resolver os problemas do que resolver os problemas de uma forma elegante. Temos a ciência que, resolver problemas é um processo que envolve a exploração de possibilidades, a exaustão de características. Se focarmos somente na criação de soluções bonitas e "produtivas", não iremos atingir nosso principal objetivo: Fornecer tecnologias que resolvem problemas.

Por isso, em JBoss tudo é possível. Tudo é personalizável, tudo é adaptável. Mas, entendemos que depois dessa missão cumprida, temos também que fornecer soluções bonitas e agradáveis e que possibilitem a exploração do aspecto chave do JBoss: Resolver problemas. Como disse antes, já pude trabalhar com soluções de SOA de diferentes fabricantes, e sempre tive a necessidade (em todas elas) e abrir a caixa e adaptá-las para resolver problemas. E tendo isso em mente, tenho a impressão de que estas soluções são muito boas, porque elas são bonitas, mas você precisa abrir a caixa, você consegue fazê-lo para resolver problemas.

A cultura que ainda não é clara para a maioria das pessoas é que, assim com estas soluções de outros fabricantes, em JBoss, você também têm além de uma plataforma que resolve problemas, um ambiente robusto, produtivo e elegante para o desenvolvimento de soluções. Mas a parte mais infeliz disso tudo é que, JBoss hoje possui um legado de percepção ... a percepção de que ele é pé duro, feio e improdutivo. Poucas pessoas sabem que, em JBoss, temos soluções tão elegantes quanto, temos wizards, temos designers, temos modeladores, assim como nossos concorrentes. E por esta impressão que nossos clientes têm, é que a Red Hat faz nos últimos anos um trabalho árduo de mostrar que nossas soluções são competitivas no aspecto elegância e beleza, e não só, em tecnologia que resolve problemas.

Neste post, irei mostrar como criar uma solução SOA de integração relativamente complexa, usando para isso, nenhum código Java, nenhum código XML e nenhuma das técnicas do tipo "Copie para a pasta Deploy ..." para implantação da solução. Usaremos o JBoss SOA Platform, a versão enterprise do JBoss ESB + Drools + jBPM da Red Hat Middleware. A impressão ao final deste post é que você, usuário ou cliente de JBoss, veja o poder que nossa solução têm, e que você possa apreciar como podemos ser produtivos com JBoss, bastando para isso, conhecer os produtos certos ;-)

Conhecendo um pouco de JBoss Enteprise Middleware

Para criarmos nosso projeto, iremos usar o JBoss Developer Studio. O JBDS é na verdade uma suíte integrada da JBoss baseado no Eclipse que possui ferramentas para criação de diferentes soluções. JBoss separa suas soluções em verticais tecnológicas. Exemplos destas verticais são: JBoss Enterprise Platform (JBoss AS + Hibernate + Seam), JBoss Portal Platform (JBoss AS + Portal + Bridge), JBoss SOA Platform (JBoss AS + jBPM + ESB + Drools), JBoss BRMS (JBoss AS + Drools + Guvnor), JBoss Data Services Platform (JBoss AS + MetaMatrix + MetaMatrix Designer + MetaMatrix Server), JBoss Web Server (Tomcat + Apache HTTP Server), JBoss Communications Platform (JBoss AS + Mobicents), JBoss Operations Network (JOPR + Plugins).

Cada uma destas plataformas possui um fim muito bem definido, seja SOA, portal ou federação de dados. Para auxiliar o desenvolvimento de todas estas "verticais", temos o JBoss Developer Studio, uma suíte de desenvolvimento baseado no eclipse que fornece plugins e features interessantes para cada uma destas plataformas. Todas estas soluções são oferecidas nas comunidades JBoss.ORG gratuitamente. Entretanto, você também adquirir as mesmas soluções com um pouco mais de estabilidade, certificação e segurança jurídica através das subscrições. As subscrições são um modelo de negócio baseado em open source que a Red Hat utiliza para prover aos seus clientes coisas como:

• Suporte 24 x 7. Você não precisa mais procurar respostas no Google, ligue num 0800 da Red Hat, e conte com suporte em português dado por um técnico certificado.
  
• Suporte Legal: Se você cria soluções baseadas em Open Source, você pode usar a Red Hat como asseguradora legal da sua solução.
• Confiança. Com medo de que o framework seja descontinuado? A Red Hat garante 7 anos da solução datado do contrato de subscrição.
• Certificação. Releases baseados em subscrição possuem certificação de fabricantes de hardware e sistemas operacionais, dando maior garantia em seu deployment.
• TCO (Total Cost Ownership). O produto é seu, mesmo sem a subscrição. Red Hat não vende software, ela vende confiança e estabilidade. Se seu contrato expira depois de um ano, você continua usando o software, fazendo com que seu custo capital (CapEX) seja sempre menor.

Estas são algumas das várias características que a subscrição te dá. Mas não iremos falar nisso aqui em exastão, irei reservar este assunto para outro post. Seja o JBoss Developer Studio, ou o JBoss SOA Platform, ambos podem ser adquiridos via modelo de subscrição. Na sequência, irei mostrar como, usando o JBDS e o SOA Platform, construir uma solução SOA de forma simples e rápida. Dúvidas e interesse no modelo de subscrição, me consulte em particular no e-mail ricardo.ferreira@redhat.com.

Criando uma solução SOA no JBoss Developer Studio

Pense na seguinte solução: Imagine que você tenha que criar uma aplicação de integração que precise receber um arquivo XML contendo um pedido de compra. Este arquivo será posto num diretório que você deverá ficar monitorando continuamente. Quando o arquivo for posto no diretório, você deverá ler este arquivo, recuperar seu conteúdo, e exibi-lo no console da aplicação. Depois de exibir o conteúdo, você precisará copiar este arquivo para uma outra pasta (uma pasta de saída) e assim que copiar para outra pasta, colocar um sufixo no arquivo para informar que o arquivo fora processado.

Pensou no cenário? Imagine você implementando tudo isso em Java. Com certeza daria um pouco de trabalho, principalmente se você avaliar aspectos mais críticos como: Tamanho do arquivo pode estourar o JVM, cópia do arquivo com locks do sistema operacional, exibição correta do conteúdo considerando regras de encoding, etc. Iremos constrir tudo isso usando apenas o JBoss Developer Studio como ferramenta de desenvolvimento, e o JBoss SOA Platform como ESB de execução da solução. Irei considerar que você já têm ambos os produtos instalados no seu computador.

Primeiro, inicie seu SOA Platform por dentro do JBoss Developer Studio. Para isso, clique com o botão direito no servidor e selecione a opção "Start". Agora vá no menu "File->New->Other" e escolha a opção "ESB/ESB Project". Na caixa do nome do projeto, digite "jboss-soa-simples", e na caixa "Target Runtime" escolha "JBoss SOA Platform 4.3". Clique no botão "Finish".

Assim que você concluir a criação do projeto, será apresentado o editor visual do projeto de ESB. Através deste editor, você cria e configura tudo de uma solução de integração do SOA Platform.

Clique com o botão direito na opção "Providers" e escolha o item "New->JMS Provider". Iremos configurar um provider do tipo JMS que irá definir nosso canal de mensagens. Na caixa "Name" entre com "JBoss Messaging" e na caixa "Connection Factory" entre com "ConnectionFactory". Clique no botão "Next". Na caixa "Channel ID" entre com "jmsChannel". Clique no botão "Finish".

Navegue até o item "jmsChannel->Filter". Será aberto a edição dos detalhes do canal de mensagens. Na primeira caixa "Destination Name" entre com "queue/testQueue".

Clique com o botão direito novamente no item "Providers", escolha a opção "New->FS Provider". Iremos criar um provider do tipo File para que possamos monitorar o diretório que irá receber o arquivo XML do pedido de compra. Na caixa "Name" digite "File Provider". Clique no botão "Next". Na caixa "Channel ID" entre com "fsChannel". Clique no botão "Finish".

Navegue até o item "jmsChannel->Filter". Será aberto a edição dos detalhes do canal de mensagens. na caixa "Directory" entre com um diretório válido do seu computador. Na caixa "Input Suffix" entre com "pedidoCompra.xml". Na caixa "Post Delete" selecione a opção "false". Na caixa "Post Directory" entre com algum diretório válido do seu computador, diferente do diretório de entrada. Na caixa "Post Suffix" entre com ".OK".

Salve as configurações. Até agora, fizemos toda a configuração dos nossos providers que cuidarão do aspecto de receber a mensagem, e entregar a mensagem de saída. Agora, iremos passar para a parte do processamento da mensagem, ou seja, a parte referente ao pipeline de execução. Para isso, iremos configurar um serviço dentro do ESB. Clique com o botão direito do mouse na opção "Services" e escolha a opção "Add Service". Na caixa "Name" entre com "PedidoService". Na caixa "Category" entre com "Proxy Services". Na caixa "Description" entre com "Serviços de Processamento de Pedidos". Clique no botão "Finish".

Será criado duas opções abaixo do serviço: "Listeners" e "Actions". Clique com o botão direito no item "Listeners" e escolha a opção "New->JMS Listener". Na caixa "Name" entre com "jmsListener" e na caixa "Channel ID Ref" seleciona a opção "jmsChannel". Clique no botão "Finish". Clique novamente com o botão direito no item "Listeners" e escolha a opção "New->FS Listener". Na caixa "Name" entre com "fsListener" e na caixa "Channel ID Ref" selecione "fsChannel". Clique no botão "Finish".

Selecione o item "fsListener". Quando você fizer isso, será exibido o editor de propriedades deste listener. Na caixa "Is Gateway", selecione a opção "true". Na caixa "Schedule Frequency", entre com "5". Este é o tempo em segundos que o diretório ser monitorado.

Selecione o item "Actions". No editor de propriedades que se abre, selecione a opção "OneWay" na caixa "MEP". Clique com o botão direito no item "Actions" e escolha a opção "New->System Println". Na janela que se abre, entre com "printMsg" na caixa "Name" e "Pedido de Compra" na caixa "Message". Com estes passos, configuramos o que será feito quando a mensagem chegar no pipeline de execução do serviço dentro do ESB.

Salve as configurações. Nosso projeto está pronto. Agora precisamos implantar o novo módulo dentro do ESB e realizar os testes. Para fazer a implantação, clique com o botão direito no SOA Platform, e escolha a opção "Add and Remove Projects". Selecione o projeto "jboss-soa-simples" e clique no botão "Add" para adicioná-lo dentro do SOA Platform. Feito isso, clique no botão "Finish".

Depois que você implantar o novo módulo ESB dentro do SOA platform, você poderá ver que o módulo foi corretamente instalado analisando o log do servidor. Deverá aparecer um conjunto de logs com os da listagem abaixo.


Faça um teste. Crie um arquivo XML chamado "pedidoCompra.xml" com qualquer conteúdo (Como não iremos processar o XML, o conteúdo não importa neste exemplo) e copie este arquivo para o diretório de entrada que está sendo monitorado pelo SOA Platform. Após alguns segundos, o ESB vai reconhecer o arquivo, e a seguinte mensagem será mostrada no console do servidor:


E claro, depois que esse log for exibido, verifique o diretório de entrada, deverá estar vazio. Se você olhar no diretório de saída, você irá encontrar um arquivo chamado "pedidoCompra.xml.OK", indicando que o arquivo fora processado com sucesso.

Conclusão

Neste post, vimos que é possível construir soluções críticas de uma forma simples e produtiva, usando para isso as soluções JBoss Enterprise. Dado este post, gostaria de fomentar a seguinte pergunta:

Você ainda acha que JBoss é improdutivo?

Boas Soluções ;-)