SOA Journal

Nosso novo local de encontro - http://www.brenobarros.net

2010-06-28T18:56:00.000-07:00

Resolvi me profissionalizar e dedicar ainda mais na escrita dos meus pensamentos, opiniões, experimentos e trabalhos. E lógico, receber as opiniões de vocês.

Para isto, resolvi registrar um domínio. Agora, já a $$$ está saíndo do meu bolso, vou procurar achar mais tempo para dedicar ao meu novo site. Segue ele:

http://www.brenobarros.net

Vejo vocês por lá.

Um grande abraço a todos.

Framework Error Hospital do Oracle SOA Suite - Parte 1

2008-06-25T16:07:00.000-07:00

O Error Hospital consiste em padrão de projetos (Design Patterns) para prover tratamento de exceções com um serviço. Onde, para prover simplicidade e performance para os processos de negócios, os mesmos são projetados como assíncronos ou síncrono (“event short-lived”). Desta forma, quando uma exceção neste processos são lançadas, as mensagens são publicadas em um processo error hospital que então prover a gestão necessária, incluíndo intervenções humanas se necessário.

Com isto, é possível listar as instâncias dos processos BPEL que necessitam de uma intervenção humana para continuar seus fluxos em cenários onde:

As Transações distribuídas ficam em estados inconsistentes após todas as retentativas e rollbacks automatizados;

As Transações que deveriam sempre ser terminadas (assíncronas sem retorno via callback) não chegaram ao fim após todas as tentativas automatizadas;

As Transações distribuídas que ficam em estados inconsistentes após todas as retentativas e não tem rollbacks configurados.

O Framework Error Hospital está disponível a partir da versão 10.1.3.3 do Oracle SOA Suite, permitindo que definições de políticas de tratamento de erros em tempo de execução sejam definidas, tais como Remote Faults e Binding Faults.

Os Remote Faults ocorrem quando o serviço que o processo BPEL tenta invocar não pode ser localizado, por exemplo, no caso de uma falha de rede ou servidor. Assim, em caso de Remote Faults, o processo BPEL pode ser reiniciado. No caso dos Binding Faults, os mesmos indicam um desencontro entre prestador de serviços e consumidores. Neste caso, uma intervenção humana faz-se necessário. Veja o macro fluxo abaixo.

No próxima post deste tema, estaremos tratando a integração do Framework Error Hospital com o Oracle BAM para permitir o controle dessas instâncias em tempo real, provendo uma solução mais prá-ativa.

O BAM matou o BI?

2008-06-25T15:46:00.000-07:00

BAM: Business Activity Monitoring
BI: Business Intelligence

Essa é uma pergunta que escuto com bastante frequencia por alguma pessoas quando estamos falando sobre SOA, mais especificamente sobre BAM.

Não, as ferramentas de BAM não acabaram com as aplicações das ferramentas de BI. Na verdade, o BAM é uma tecnologia nova para monitoramento em tempo real dos indicadores de desempenho das empresas. O mesmo é voltado para tomada de ações imediatas a partir do acesso a informação. Já o BI, é voltado para tomadas de decisões futuras a partir de informações históricas.

Com a tecnologia BAM muitos fornecedores de soluções BI passaram a incluir em seus produtos alguns mecanismos de monitoração e tomadas de decisões em tempo real.

Da mesma forma, posso armazenar informações históricas na base de dados do BAM, porém sua perfornse e resposta não será tão boa, pois as ferramentas que hoje o implementam não estão preparadas para isto.

Porém, eu particularmente continuo enchergando os BAM e BI com uma fronteira bem distinta. Onde, o BI é focado em "O que aconteceu" e o BAM "O que está acontecendo". Você acha que acabou? Não, ainda o tem "O que aconteceria?", e esse é implementado por ferramentas CPM (Corporate Performance Management).

Devo usar BPEL ou ESB?

2008-06-25T15:43:00.000-07:00

A pergunta do título pode paracer estranha. Concordam? Mas, por incrível que pareça, muitos ainda se confrontam com essa dúvida em cenários onde os mesmos precisam implementar uma composição de serviços para atender a uma determinada situação.

Diante disto, eu decidi escrever neste post alguns aspectos que devem ser levados em consideração para sanar esta dúvida.

Bem, primeiramente nós sabemos e concordamos que ambos podem ser utilizados para a composição de serviços, inclusive podem ser utilizados em conjunto. Mas se eu tenho que decidi entre um e outro, qual devo usar?

Vamos então para alguns cenários:

1. Se o cenário alvo de implementação é focado apenas nos requisitos de conectividade, mensageria e roteamento, o ESB é a melhor opção. Entretanto, se o cenário é focado em atividades um pouco mais complexas tais como intervenções humanas (workflow) e orquestração para controlar como e quando os fluxos de dados vão sendo trocado entre sistema, o BPEL é a melhor opção.

2. Se o cenário é focado em processos de vida curta (short-lived) e baseado em armazenamento, transporte e simples transformação de mensagens, o ESB é a melhor opção. Porém, para processos de vida longa (long-lived) que podem ter que aguardar para se completar, além de necessidade de transformações de mensagens mais ricas e complexas, o BPEL volta a ser a melhor opção.

3. Se o cenário é direcionado para uma implementação de um processo cuja a natureza de virtualização (entede-se por transparência de localização) dos serviços seja necessária, fazendo com que o processo fique imutável caso ocorra alguma movimentação de serviços, o ESB é a melhor opção. Pois somente com BPEL, as URLs dos serviços estarão acopladas nos PartnerLinks do processo, e qualquer movimentação dos mesmos deve alterar o BPEL novamente. Assim, se nos cenário 1 e 2 o BPEL for a melhor opção e também se desejar a uma maior virtualização, utilize o BPEL para a composição de serviços com o ESB provendo essa virtualização.

Outro cenário que eu gostaria de descatar, que não recomendo a utilização BPEL, é para aquele onde o foco está em processos de migração de dados (e tem gente querendo ver o BPEL funcionando nestes processos), onde o volume de dados são muito grandes e uma boa performance é fundamental, eu sugiro a utilização de ferramentas especializadas tais como Oracle Data Integrator, Informatica Power Center, dentre outras, por garantirem estes requisitos além de fornecer melhor controle transacional, agendamentos, filtros, transformações específicas de um formato para outro, qualidade dos dados, dentre outros benefícios.

Porém, se mesmo assim você quer utilizar o BPEL, recomendo não buscar todos os dados a mesmos tempo e acionar o seu processo, sugiro você implementar um polling (listener service) que a medidas que os dados vão chegando ou vão sofrendo alguma alteração, os mesmo serão automaticamente migrados pelo processo. Além disso, sugiro compor o serviço de polling e o processo BPEL através do ESB.

Espero ter colaborado com alguma coisa. Qualquer dúvida ou sugestão estou a disposição.

Integrando CICS com Jbi4CICS Component

2007-08-28T10:03:00.000-07:00

Neste artigo, escrito por Amedeo Cannone e Stefano Rossini, é apresentado o componente Jbi4CICS em conjunto com um exemplo de integração que mostra como é o funcionamento por trás do ciclo de vida do JBI.

O componente Jbi4CICS é um JBI Binding Component Open Source que pode ser usado para conectar um ESB (Enterprise Service Bus) com um sistema CICS.

Boa leitura.

Qual a atomicidade e/ou granularidade dos meus serviços?

2007-08-13T19:36:00.000-07:00

Bem, esta é uma questão que toda vez eu sou questionado em minhas apresentações sobre SOA que tenho feito para alguns clientes, pela empresa onde eu atuo, pelo Brasil.

Além disto, esta é uma questão que se alastra desde os primórdios dos paradigmas de programação procedural, orientação a objetos, componentização, dentre outros.

Bom, para tentar responder a esta pergunta, antes de mais nada, vamos à alguns conceitos:

Atomicidade: Um serviço atômico, são serviços que desempenham uma tarefa ou ação específica.

Granularidade: Consiste na mensuração do tamanho, escala e nível de detalhes dos serviços. Onde serviços "gordos" são coarse-grained (baixa granularidade) e serviços "leves" são fine-grained (alta granularidade).

Para responder a esta questão, vamos considerar dois pontos.

Primeiro: Abordagem de Descobrimento dos Serviços

A atomicidade e/ou granularidade de um serviço pode depender da estratégia de descobrimento do mesmo. Ou seja, se nós fizermos uma abordagem "top-down", primeiro iremos identificar os nossos processos de negócios, onde cada atividade dos mesmos podem ser desmembradas em sub-processos e assim por diante, até que não seja mais possível desmembrá-los. E neste ponto, teremos nossos serviços.

Por outro lado, se nós adotarmos uma abordagem "bottom-up", nossos serviços vão sendo expostos através das funcionalidades candidatas dos sistemas legados existentes, onde a granularidade e a atomicidade destes serviços vão sendo refinadas até que os mesmos possam ser compostos (orquestrados) em processos de negócios.

Segundo: Características dos Serviços

Antes de percebermos as caracterísitcas dos serviços, primeiramente os serviços podem ser classificados da seguinte forma:

Serviços de Negócios (Business Level Services): Este serviços representam atividades/funções reais de negócios.
Serviços de Infra-Estrutura (Infrastructure Level Services): Estes serviços não contém regras de negócios, mas são necessários para suportar necessidades dos serviços de negócios.

Com isto, dependendo da classificação dos serviços, podemos identificar suas características e objetivos chaves que julgamos necessários para cada um dos serviços, tais como: reusabilidade, visibilidade, transacionabilidade, performance, dentre outras; Que devem serem levados em consideração em qualquer projeto de adoção SOA. Pois, um serviço pode ser atômico em virtude da reusabilidade, porém não atômico devido as dificuldade transacionais. Da mesmo forma, um serviço pode ser fine-grained em virtude da visibilidade, porém coarse-grained em razão da performance.

Portanto, segue abaixo uma tabela ou matriz, que talvez nos ajude a identificar melhor a atomicidade e/ou granularidade dos nossos serviços que estão projetados, dentro das características principais desejadas.

Obs: Na imagem acima, "Top-Down" e "Bottom-Up" indicam as abordagens explicitadas um pouco mais acima. Onde, "Top-Down" está mais direcionada aos processos de negócios e "Bottom-Up" às estratégias de migração.

Bom, como podemos perceber a definição da atomicidade e granularidade dos serviços que farão parte de um projeto de adoção SOA é uma tarefa bastante importante e delicada. Onde, a estratégia adotada para identenficação das mesmas, pode interferir no sucesso ou fracasso do projeto.

Espero ter ajudado um pouco na resposta desse grande dilema.

Em breve, voltaremos a postar novas experiências.

Intalio|BPMS

2007-07-20T11:09:00.000-07:00

Para quem ainda não conhece, o Intalio|BPMS consiste numa ferramenta de BPMS, que possui uma versão Community Edition (Eclipse IDE + Apache Gerônimo Application Server), projetada para Analistas de Processos ou Arquitetos e Desenvolvedores que não necessáriamente precisam ser experts em J2EE.

Seus diagramas de processos são baseados no BPMN (possuindo um BPMN Designer), onde os mesmos são automaticamentes tranformados para o formato BPEL no momento da implantação dos processos, inclui um BAM em real-time, controle de versão automatica dos processos implantados, dentre outras funcionalidades.

Existe no site no fornecedor um comparação do Intalio|BPMS com o JBoss jBPM bem interessante.

Assim, para quem ficou interessado, a Intalio fornece uma demonstração de suas funcionalidades. Para vê-la, clique aqui.

Em breve, estaremos relantando neste blog, alguns estudos de casos com o uso do Intalio|BPMS e outras ferramentas.

Até a próxima.

Quais os impactos de adoção de um BPMS?

2007-07-17T19:49:00.000-07:00

Antes de mais nada, o que é um BPMS?

Um BPMS (Business Process Management Systems/ Softwares) consiste em uma nova categoria de software que permite as corporações, modelar, simular, implantar e gerenciar os seus processos de negócios de forma clara, fácil e controlada e monitorada, sem uma forte dependência com TI.

Resumindo, o BPMS permite dar vida aos processos de negócios da corporação em um ambiente controlado e monitorável.

Quais os componentes/ferramentas principais de um BPMS?

Business Process Modeler: Ferramenta que possibilita aos analistas de negócios a modelarem os processos de negócio da corporação na forma de diagramas. Normalmente, estes diagramas seguem uma notação padronizada para representação de fluxos de processos, denominado BPMN (Business Process Modeling Notation), porém podem seguir notações proprietárias.
Executable Process Modeler: Ferramenta que possibilita a transformação do diagrama criado acima em uma linguagem entendível pelas engines de execução dos processos. Normalmente, a linguagem a ser gerada é o BPEL (Business Process Execution Language), que é uma linguagem de execução de processos com foco em Web Services.
Process Execution Engine: Componente que executa os processos implantados, gerados acima, gerenciando as informações pelos mesmos, produzidas.
Business Activity Monitoring (BAM): Componente que possibilita a gestão dos processos implantados, através de diversos relatórios estatísticos (dashboards).
User Portal: Interface que permite aos usuários envolvidos do processo, a participarem da execução do mesmo.
Administration Portal: Interface que possibilita o acompanhamento dos processos em execução, desde que tenha permissão de acesso aos mesmos, além de possibilitar implantações tanto de novos processos quanto de novas versões.

Assim, para considerar seus impactos, vamos considerar os seguintes cenários:

Cenário 1: Imaginem um dado processo de negócio que realiza a orquestração de um determinado conjunto de serviços. Imaginou? Ótimo. Agora, imagine que todos estes serviços já estejam implementados, seguindo é claro as recomendações WS-I* (especificações Web Services Interoperability).

Bem, já que todos os serviços estão implementados e nós apenas tenhamos que orquestrá-los em uma seqüência lógica para compor o processo de negócio alvo. O que temos que fazer? Fácil, devemos utilizar uma ferramenta BPMS, sem que não seja necessário a criação de nenhuma linha de código.

Cenário 2: Agora imaginem uma situação onde tenhamos que criar um processo de negócio que envolve a integração de diversas aplicações legadas. Além disto, e muito provavelmente, estas aplicações legadas foram implementadas por tecnologias distintas (Cobol, Java, Natural, .Net, dentre outras). Com isto, nós teremos a necessidade de utilizar conectores (ou adaptadores), que são responsáveis por prover a transformação de um protocolo por outro e vice-versa.

Bem, muitas soluções BPMS já provem diversos destes conectores para as principais tecnologias existentes. E caso tenhamos que desenvolver algum conector, os próprios BPMS ou geram códigos nativos da linguagem usada no sistema legado alvo, ou até mesmo, já geram estes conectores na forma de web services.

Então, podemos perceber, que se por um acaso precisarmos codificar algo, este esforço será reduzido drasticamente.

Cenário 3: Imaginem que para todos os processos de negócios analisados e modelados, nós tenhamos que mantê-los sempre documentados, para que os mesmos possam ser frequentemente analisados.

Bem, a grande maioria das soluções BPMS geram boa parte das documentações sobre os processos modelados e seus serviços utilizados. E caso haja alguma mudança nos mesmos, estas documentações podem ser geradas em tempo-real.

Cenário 4: Imaginem que em um processo de negócio definido, modelado e implantado em um ambiente em “produção”, um erro foi identificado. Percebemos também, que algumas instâncias destes processos estão atualmente em execução. Onde, precisamos fazer uma correção nos fluxos deste processo, sem que as instância que estão rodando parem bruscamente.

Bem, as soluções BPMS permitem as alterações destes fluxos, mantendo-se as instância em execução no modelo antigo, e novas instâncias já adequadas ao modelo novo. Tudo isso apenas com um controle de versão já provido pelos BPMS.

Bom, acima descrevi apenas quatro cenários que possibilitam e justificam alguns olhares às soluções BPMS para adoção pela sua corporação. Pois, como vimos acima, o uso de um BPMS tem impactos bastante positivos, possibilitando-nos escrever menos códigos, ter flexibilidade e rapidez em eventuais mudanças e confecção de documentações, além de possibilidades de simulação dos processos a serem implantados e monitoramento dos processos já em execução.

Em breve, estaremos escrevendo um artigo que demonstra mais claramente o funcionamento destes BPMS. Até lá.

Service-Oriented Migration and Reuse Technique (SMART)

2007-07-03T13:08:00.000-07:00

O Service-Oriented Migration and Reuse Technique (SMART) foi desenvolvido pela Software Engineering Institute (SEI), para acessorar organizações à analisar seus sistemas legados, com o objetivo de levantar suas capacidades para utilização na forma de serviços, dentro do paradigma Service-Oriented Architecture (SOA).

O SMART visa levantar um grande volume de informações sobre os componentes legados, alvos para a SOA, e potenciais serviços que necessitarão serem produzidos, dentro de uma estratégia de migração. Além disso, o SMART produz outros artefatos que serão insumos para que a organização decida ou não pela migração dos sistemas legados para a SOA.

Em breve, voltaremos a comentar sobre este método com mais detalhes.

Para maiores informações, segue o link para o documento que descreve o SMART, retirado do site da SEI.

Entendendo o JBI

2007-07-03T07:35:00.000-07:00

Mas o que é o Java Business Integration (JBI)?

JBI consiste em uma especificação que define uma arquitetura e comportamentos para hospedagem de componentes plugáveis, onde a comunicação entre estes componentes se fará através do uso de WSDL (Web Services Description Language) 2.0.

O principal objetivo do JBI é permitir que possamos utilizar componentes plugáveis, provendo todas as funções necessárias para uma solução de integração, sem sermos dependentes de um fornecedor específico. Ou seja, os componentes poderão ser facilmente portáveis entre quaisquer implementações do JBI.

O JBI também é conhecido como um "container of containers".

Imaginando um cenário para aplicação do JBI por arquitetos/desenvolvedores Java EE, seria mais ou menos assim: Os EJBs implementados, poderiam ser compostos dentro de processos de negócios, mais precisamente em Stateful Business Processes, através da linguagem BPEL, permitindo com isto, a orquestração do componentes de negócios (EJBs) sem a necessidade de implementação "hard-code" em classes Java destes processos de negócios. Conseguindo com isto, uma maior flexibilidade e interoperabilidade na utilização e otimização destes processos.

O JBI possui dois componentes principais: Os "Service Engines" e os "Binding Components".

Os "Service Engines" são responsáveis por prover lógicas de negócios e/ou serviços de tranformações de mensagens entre outro componentes, além de consumirem serviços (é claro). Já os "Binding Components" provêem serviços externos ao ambiente JBI, tal como atuando como um Adapter entre protocolos de comunicações diferentes, entre os serviços externos e o ambiente JBI.

É interessante destacar que a distinção entre os "Service Engines" e os "Binding Components" é apenas de caráter arquitetural, separando as lógicas de negócios das lógicas de comunicação com intuito de reduzir a complexidade de entendimento, implementação e flexibilidade.

Mas como funciona as interações entre os componentes dentro do ambiente JBI?

Estas interações funcionam da seguinte forma:

Dentro do ambiente JBI, existe um BPEL Engine, que é um "Service Engine", responsável pela hospedagem e execução dos processos de negócios no formato BPEL (é claro).

É lógico que estes processos não saberão quais protocolos os clientes irão utilizar para acioná-los. Com isto, faz-se necessário a utilização de "Binding Components" que irão converter estes protocolos heterogênios em uma forma normalizada, ou seja, uma mensagem XML em conformidade com um dado WSDL, adicionar nesta mensagem normalizada, meta-dados tais como: segurança, transação, dentre outras. E a partir daí, repassar para o ambiente JBI.

Logo após, o ambiente JBI determinará qual componente, ou melhor "Service Engine", poderá atuar como um serviço qua atenda à requisição, que neste caso é o próprio BPEL Engine. Assim, a mensagem normalizada será repassada para BPEL Engine, para que o mesmo possa instanciar o processo de negócio requisitado pelo cliente.

Vale destacar que, se o processo instanciado precisar de algum tipo de serviço complementar (tal como alguma transformação), o JBI irá determinar qual componente proverá este serviço, e redirecionará a requisição para o mesmo (no caso de transformação, XSLT engine, por exemplo), que responderá de volta para o BPEL Engine.

Obs1: O BPEL Engine é um consumidor e provedor de serviços, porém ele trabalha apenas com mensagens normalizadas.

Obs2: A escolha de quais componentes atuarão como um dado serviço, é feita através de componentes inteligentes (smart components), configurados para fazer estas escolhas. Inclusive, podem ser customizados.