44

A integração BPMS e SOAComo o SOA se integra com BPMS?

Glauco dos Santos Reis

(glauco@portalbpm.com.br): é bacharel e mestrando em Ciências da Computação. Trabalha com Java desde 1996 e é especialista em orientação para objetos, utilizando linguagens OO há mais de 24 anos (C++ e Java). Tem as certificações SCJP 1.1 e 1.5, SCWCD 1.4, e é certificado em Websphere pela IBM. Atuou em dezenas de projetos Java, SOA e BPM, e tem mais de 160 artigos publicados em revistas do segmento de informática. É especialista em BPM e publicou um livro sobre a notação BPMN (www.glaucoreis.com.br). Também é mantenedor do site PortalBPM (www.portalbpm.com.br), que trata dos assuntos SOA, BPM, BPMS e CEP. Atuou na criação da arquitetura e implementação da primeira solução CEP do mercado nacional. Atua como consultor em projetos e implantação SOA e de soluções BPMS.

Atualmente existe um rico arsenal de ferramentas que favorecem o aumento de produtividade no desenvolvimento de sistemas, muitas delas sob a denominação de soluções SOA e/ou BPM. Quando são apresentadas ao negócio, quase sempre são aceitas e incorporadas como ferramentas corporativas, não partindo de uma decisão de TI, mas sim uma solução de negócio que a TI deve suportar. Isso faz com que os desenvolvedores precisem se adapatar a esta nova realidade, tendo que assimilar estas novas tecnologias e atender aos requisitos dos sistemas. Vamos explorar o que significa a mudança para este novo paradigma SOA/BPM nas empresas, e como esta subdivisão deve acontecer.

: : www.mundoj.com.br : :

uase todas as grandes empresas de software comercializam hoje no mercado soluções BPMS e SOA. Elas utilizam a ideia de aumento de produtividade baseada em gerado-

res de códigos, que acabou ficando popular no Brasil lá pela década de 80, com as ferramentas geradoras de código e posteriormente as soluções RAD. Infelizmente, naquela época, os avanços da OO, com-ponentização e paterns não eram tão populares e as soluções acabavam por gerar códigos ineficientes e de difícil manutenção. O processo de amadurecimento deste tipo de gerador de códigos fez com que hoje fosse possível a construção de aplicações de produtividade, e por isso a ideia retorna ao cenário atual. Na verdade, este tipo de solução costuma ser chamada de DSL (Domain specific Language), um termo bastante explorado por Martin Fowler. Uma DSL é uma linguagem para um domínio específico, mantendo características que aumentam imensa-mente a produtividade no nicho para o qual ela foi criada. Talvez a mais conhecida linguagem DSL seja o Cobol. Neste quesito, ferramen-tas programáticas como o Mathematica e Matlab também poderiam ser consideradas DSL. Muitas vezes engenheiros e matemáticos têm dificuldades na manipulação de linguagens de programação. O que as DSL fazem é trazer a programação para um linguajar mais próximo do domínio destes profissionais. Como este profissional normalmente sabe resolver o problema específico do domínio (calcular uma estrutu-ra de concreto, por exemplo), ele acaba solucionando o problema com uma linguagem DSL, sem o auxílio de um programador. Normalmente os programadores não dominam o conhecimento do negócio, e isto é tão verdade quanto mais profundo for o conhecimento do programa-dor na linguagem. Ou seja, é muito difícil encontrar um programador com profundos conhecimentos em Java e sua diversidade de APIs, e também com conhecimentos específicos sobre o mercado financeiro, de capitais, engenharia ou outro qualquer. O conhecimento específico vai sendo adquirido com o tempo de experiência no domínio em ques-

45

tão, e normalmente quanto mais este conhecimento se destaca, mais longe da programação o profissional acaba por se posicionar. Ou seja, conhecimentos específicos são mais valorizados do que conhecimen-tos genéricos (se é que podemos considerar dominar uma linguagem de programação com a complexidade do Java como genérico). Mas o que eu quis dizer neste caso é que utilizar STRUTS é o mesmo em qualquer empresa. Os mecanismos são os mesmos, e um programador que souber programar bem em Struts o faz em qualquer ambiente. Já um profissional que conhece como funciona o mercado financeiro, por exemplo, é mais escasso (até pela limitação do número de empresas neste segmento) e acaba sendo mais valorizado. É neste sentido que se aplica o genérico. No caso dos DSL, é como que o oposto de uma linguagem de uso geral, como o Java e o C++, que mantém uma abran-gência grande, sem uma especialização em um domínio específico. Eles costumam resolver problemas específicos, como a modelagem e execu-ção de processos de negócios, no caso de uma solução BPMS. Podería-mos imaginar que Java seria um DSL, já que mais de 90% do mercado a utiliza para construção de aplicativos Web. Na verdade o que faz o Java ser popular para aplicativos Web não é a linguagem em si, mas sim a integração entre os servidores de aplicação e um framework de mais alto nível (as APIs de Servlets e JSP), que proporciona um conjunto de alta produtividade para este tipo de aplicação (muito maior ainda se considerarmos frameworks como Struts e JSF). Neste artigo, vamos mostrar como a implementação do SOA está atrelada ao uso de um BPMS e aos desafios que os programadores deverão enfrentar para se adequar a este novo paradigma.

O realinhamento rápido do negócio

Sobre o BPMN (Business Process Modeling Notation)

Existe uma premissa (um tanto quanto subjetiva), normalmente atri-buida às soluções BPMS, que é permitir algo chamado de realinhamen-to rápido do negócio, o que acontece quando temos um mercado com-petitivo, estratégias agressivas de vendas e de marketing que forçam a mudanças nos sistemas. Grandes lojas de varejo, por exemplo, estão constantemente competindo pelos mercados. Isto acontece na forma de promoções que alteram a forma de negociação durante um período muito curto de uma promoção, retornando logo após ao funcionamen-to normal, até que uma nova campanha seja aplicada. Metodologias tradicionais demandam grandes períodos de análise e redesenho, para alterações de durabilidade muito curtas. O retorno ao estado original também demanda um ciclo de desenvolvimento e testes que também demanda tempo. Os ciclos longos de desenvolvimento, proporciona-dos pelas metodologias tradicionais, como RUP, não se aplicam nestes casos, pois demoram a surtir efeito. A demora na geração de resultados fez surgir um conjunto de técnicas e metodologias mais recentes, como as metodologias ágeis e scrum, que prometem resultados mais rápidos sem perda na qualidade. Esta é uma premissa de uma solução BPMS, ou seja, gerar resultados rápidos em prazos mais curtos. Na verdade, a maneira como se atinge este objetivo é diferente nos dois casos. No caso das metodologias ágeis, se buscam formas de tornar os artefatos mais simples, ou aumentando a comunicação entre as pessoas. Por outro lado, a abordagem das soluções BPMS é criar representações gráficas que facilitam alterações, tornando o processo de criação e manutenção algo visual e, portanto, mais rápido. Na maioria das vezes, o que se tenta fazer é criar soluções nas quais muito pouco código precise ser criado, e a maioria das tarefas seja feita com o arrastar de imagens e conexões de linhas na tela.

evolução da tecnologia, já que ciclos de treinamento seriam necessá-rios para preparar os desenvolvedores a cada nova solução que fosse utilizada. O histórico também demonstrou que o uso de soluções proprietárias tendia a ser um problema, quando o fabricante da solu-ção evoluía sua arquitetura.

Uma vez que a aceleração na geração de resultados é conseguida através de algum artefato normalmente visual, houve um estudo no sentido de produzir e amadurecer algum padrão que fosse qualificado para a representação de processos de negócios, e que ainda fosse padronizada entre os fabricantes. Embora possamos utilizar diagramas de atividades para representação de fluxos de negócios, se mostrou necessária a cria-ção de um artefato específico e mais adequado para a representação de todo tipo de situação, que é a notação BPMN. Esta notação pode ser vista como um superset dos elementos gráficos existentes em um dia-grama de atividades da UML, e este provavelmente foi utilizado como base para sua criação. Infelizmente, embora a representação visual das soluções BPMS sejam hoje relativamente padronizadas (quase todos migraram ou estão migrando para o BPMN), o formato de armaze-namento ainda não é. É verdade que hoje se trabalha na especificação BPMN 2.0, cujo principal diferencial é a criação de um padrão univer-sal de armazenamento. Todos os fabricantes deverão suportá-la quando estiver consolidada. Isto vai favorecer a migração de aplicativos entre as soluções BPMS. O problema não é tão simples, já que este não é o único artefato necessário para descrever completamente um desenho de processo que se pretende executar.

Por exemplo, pode-se armazenar o desenho em alguma variação de XML, sendo a mais famosa e utilizada o BPEL. O BPEL é uma lin-guagem DSL, já que permite a orquestração de serviços em um nível mais alto de programação, e poderia ser desenhado por especialistas com conhecimentos mais próximos ao negócio. Entretanto, como é um padrão formal para execução, têm regras rígidas sua criação, e muitas das representações que poderiam ser modeladas em BPMN não têm a contrapartida em BPEL. Ou seja, ou se utiliza o set completo BPMN e um formato para armazenamento proprietário, ou a opção é armazenar em BPEL, que é apropriado para execução, mas limita as variações do desenho a ser criado. Este é um dos desafios que se tenta superar neste momento. A solução da IBM utiliza uma extensão do BPEL (BPEL-4People) que agrega o elemento humano como parte do desenho. No caso do Oracle BPM, por exemplo, o padrão utilizado foi o XPDL (veja figura 1). Este é um padrão que permite um leque de representações muito mais amplo, mas a um custo mais alto. O XPDL representa os elementos visuais e sua dimensão na tela de forma padronizada, mas permite que outros elementos sejam agregados, extendendo-se a notação com particularidades que o set padrão não contempla. Foi exatamente o que a Oracle fez. Agregou outros elementos que fazem com que a execução do fluxo fosse possível no seu contexto. Com isto, outras ferramentas de desenho que conseguem visualizar a notação XPDL têm difuldades em ler e escrever um arquivo para a solução da Oracle. O programador deve desenhar os fluxos na ferramenta que o próprio fabricante disponibiliza.

Nas versões mais antigas das soluções BPMS, cada fabricante optou por criar uma notação para o desenho que tivesse adequação com a implementação da própria ferramenta, gerando ferramentas de desenho específicas por produto. Isso repercutiu negativamente na

Figura 1. Desenho de processos no OBPM.

De uma forma mais clara, o BPMN é apenas uma representação gráfica, e permite uma riqueza no desenho que não é acompanhada pelo BPEL ou qualquer formato de execução atualmente conhecido. O BPEL, por

46

Como as soluções BPMS resolvem estas questões

Como isto se encaixa com SOA?

Se as soluções BPMS são o nicho de trabalho dos profissionais mais próximos ao negócio, o SOA por outro lado é onde as atividades de programação acabam acontecendo (embora existam também soluções SOA que tornam o desenvolvimento de serviços puramente visual). Cada uma das atividades de um desenho BPMN irá acionar um ou mais serviços e estes, por sua vez, talvez sejam codificados em Java. Na verdade, como a interface entre o desenho e os códigos acaba sendo um XML, os serviços podem ser criados em qualquer linguagem de programação que se deseje. E ainda há um desacoplamento entre a camada de serviços e a orquestração dos serviços em si. Desta forma, a TI pode se encarregar da criação de serviços, que normalmente se procura que sejam o mais genérico possível, enquanto que o negócio orquestra a chamada destes serviços gerando produtos que são mais ágeis na criação e refatoramento. Bom, na prática, tanto o SOA quanto as soluções BPMS parecem se aproximar da orquestração. Normalmen-te orquestrações de mais alto nível (aquelas que envolvem usuários no processo) acontecem nas camadas BPMS, entretanto serviços mais complexos podem ser criados pela chamada em sequência de outros serviços. Este mecanismo normalmente acaba recebendo o nome de coreografia, e cria alguns transtornos entre a TI e a camada de negó-cios. Isto porque se reduz a visibilidade do negócio. Uma alteração em uma coreografia pode fazer com que um processo publicado apresente problemas, embora nada tenha se alterado em termos de desenho, ao menos o desenho que o negócio visualiza. Isto tudo na teoria é muito interessante, e provavelmente estamos próximos de conseguir estes efeitos com a atual evolução das ferramentas. A questão é como contor-nar os problemas das soluções atuais, de forma a continuar mantendo a agilidade na criação. Na verdade, as soluções BPMS atuais não obrigam a adoção de SOA para sua implantação. Mas se uma empresa estiver madura em relação ao uso do SOA, a implantação acaba se tornando mais simples. O mesmo pode-se dizer em relação ao SOA. A implan-tação do SOA não precisa visar a utilização de uma solução BPMS para orquestração. Mas é uma preparação natural para sua implementação.

Como as soluções BPMS resolvem estas questões

outro lado, é um formato apropriado e com rigidez necessária para execução, mas tem estruturas definidas e que não permitem muita variação. Já o XPDL é mais abrangente e permite a representação de todo o BPMN, mas sua definição agrega extensões que torna difícil a leitura por várias soluções, já que cada fabricante implementa estas extensões de uma forma diferente, além de não ser apropriado para execução (embora a Oracle tenha implementado esta característica neste formato).

Como dito no caso do Oracle BPM, a escolha foi pelo XPDL enquanto que o IBM utiliza o BPEL4WS. Na verdade, o problema da notação e representação do fluxo de processos é apenas um dos problemas que devemos enfrentar quando pretendemos ter uma solução que execute como um programa. O BPMN apenas representa a sequência de passos para execução de um processo. Um programa ou processo para ser executável ainda precisa de telas, informações, acessos a serviços re-motos, regras de negócio etc. Aqui realmente não existe consenso entre os fabricantes. Cada fabricante acabou adotando uma abordagem para suprir o BPMN com um conjunto de artefatos auxiliares que represen-tam cada um destes aspectos citados.

A IBM tem uma visão mais voltada para isolamento entre o perfil cria-dor de códigos e o perfil orquestrador. As ferramentas utilizadas pelo desenvolvedor de serviços são programáticas e não escondem parti-cularidades da linguagem de programação (Java, claro). A ferramenta para orquestração dos serviços, ainda está dividida em dois perfis, sendo um para desenho puro e outro mais próximo da execução, com elementos específicos do BPEL. O ponto positivo desta abordagem é uma divisão de papéis mais clara, que tem como ponto negativo uma estrutura de TI maior, com papéis específicos para cada atividade. Já no caso da Oracle (estamos falando do OBPM, já que frequentemente os fabricantes têm mais de uma solução BPMS adquirida ao longo do tempo) ao menos na versão atual, se tentou criar um ambiente de mais alto nível que tivesse a representação tanto do fluxo em BPMN quanto elementos visuais que tornassem possível a criação de telas e objetos de informação. Isto tornou a ferramenta trivial na utilização, mas que obriga grandes esforços por parte dos programadores, quando se deseja características mais avançadas no sistema. Como a ferramenta de dese-nho é única e simplificada, certas atividades que deveriam ser simples, como a criação de uma página JSP customizada ou a depuração de um fluxo de processos acabam sendo bastante difíceis.

Este conjunto de arquivos e/ou códigos criados são exportados para uma plataforma de execução (um motor que faz efetivamente a exe-cução dos fluxos). Neste processo de publicação, muito dos elementos representados em XML são convertidos para classes Java (que ficam escondidas e não podem ser alteradas) para facilitar a execução do de-senho. Esta característica torna este tipo de produto muito interessante. Como a publicação é feita em um formato intermediário, o servidor tem a liberdade de criar versões distintas da execução (as classes podem ter nomes diferentes). E ainda várias versões podem estar em execução de forma concorrente. Isto seria complicado de implementar, e prin-cipalmente gerenciar em Java para Web, pois implicaria a existência de classes diferentes. Este tipo de implementação é contemplada em orientação para objetos através de patterns como State, Decorator, Proxy etc., mas demandam maior análise, e o código que irá receber o pattern precisa ser identificado e preparado para recebê-lo. Na maioria das vezes, não se tem esta visibilidade, e qualquer código é candidato a se modificar com o tempo.

Embora seja uma vantagem, provavelmente esta é uma das fontes de reclamações por parte dos programadores java, pois se tem acesso apenas aos códigos intermediários, e não aos códigos finais. Normal-

: : www.mundoj.com.br : :

mente as ferramentas de depuração neste tipo de implementação são limitadas. É difícil colocar break points ou mesmo saber por que o código não está executando corretamente. Com frequência o progra-mador é obrigado a compreender os códigos gerados pela solução, e até mesmo desassemblando-os para poder depurar efetivamente. As soluções BPMS fazem com que o processo de criação seja algo limitado, reduzido ao arrastar de componentes sobre um desenhador visual. O processo criativo de sistemas orientados para Objeto, com definição de padrões e códigos reaproveitáveis desaparecem sob uma implemen-tação visual, o que de certa forma proporciona também a velocidade de prototipação desejada (isto pode ser discutível). Mas anteriormente utilizamos o discurso de que a linguagem DSL permite que usuários de outras áreas se tornassem programadores. Isto infelizmente parece não estar acontecendo com as soluções BPMS.

Linguagens como o VBA (Visual Basic for Applications), que foi origi-nalmente criada para que os usuários comuns de planilhas tivessem um poder programático à sua disposição, na realidade acabaram crian-do novos nichos de programadores (que o usuário final contrata para fazer os códigos). O mesmo parece acontecer com os desenhadores de fluxos das soluções BPMS. Normalmente um programador vindo do mercado Java acaba trabalhando em conjunto com um especialista em modelagem, e a atividade de programação, que no Java seria algo rico, acaba por ser algo limitado a um desenhador visual com regras fixas. Por outro lado, qualquer solicitação que saia do domínio de atuação da ferramenta acaba por ser imensamente complicado de se implementar utilizando a solução BPMS, sendo muitas vezes mais complicado do que seria se o sistema fosse totalmente em Java, causando grandes esforços de programação para proporcionar contornos que a solução não possue nativamente.

47

Quem toma a decisão?

Uma questão não tão óbvia, é que se a TI implementa serviços reuti-lizáveis e genéricos, como as decisões ao longo do processamento são tomadas? Afirmamos que o desenho do processo deveria ser o mais genérico possível, e preferencialmente com poucos elementos progra-máticos. Bom, aqui temos algumas possibilidades.

Algumas soluções procuram reduzir ao mínimo a geração de códigos do lado BPMS, e entre as soluções que fazem isto estão principalmente aquelas que utilizam BPEL (as decisões são mais simples, basicamente aquelas proporcionadas pelos XMLSchemas). A maior parte das deci-sões acontece do lado serviço, ou melhor, dentro da implementação do serviço, que fica sob controle da TI. Isto pode ser uma desvantagem, já que nas regras do TI a história tem mostrado que a agilidade é menor na tomada de decisão (também pode ser discutível). Como se pretende agilidade, quanto maior for o controle estas regras também não ficam visíveis no desenho de processos, que é o artefato que o negócio con-sulta. Como a decisão fica implementada como parte dos serviços, os ciclos de desenvolvimento acabam se tornando mais demorados. A vantagem desta abordagem é uma clara divisão entre papéis.

Mas existem também soluções que levam a capacidade de geração de códigos para o mundo BPMS, que é o caso do Oracle BPM. Nele foi incorporado um engine de scripts que permite a criação de códigos atrelados ao desenho do processo (figura 2). Estes scripts permitem ma-nipular dados retornados pelos serviços e efetuar tomadas de decisão, inclusive alterando dados e reenviando às camadas de serviços. Como principal vantagem está a praticidade e maior controle da decisão nas camadas de negócios. Por outro lado, exigem um conhecimento maior de programação, o que deveria estar distante do negócio. Uma desvan-tagem desta abordagem é que os desenhos de processos e os serviços acabam ficando mais acoplados, ou seja, alterações nas informações retornadas pelos serviços podem exigir refatoramento dos desenhos de processos. Atualmente a Oracle trabalha na nova versão de sua suite que deve estar disponível em alguns meses. Uma das linhas que parece ser seguida é cada vez mais desacoplar a camada de serviços da camada de orquestração, até mesmo desaparecendo com este recurso de scripts da próxima geração, permanecendo apenas como legado.

Figura 2. Como o OBPM atrela códigos ao desenho de processos.

SOA é atrelado ao negócio ou à TI ?

ou mesmo influência nestas áreas de negócios, para não funcionar como uma “fábrica indiscriminada de serviços sob demanda”. Este certamente seria o pior cenário existente, retirando a inteligência da área que tradicionalmente têm tomado as decisões em informática. Da mesma forma, as soluções BPMS deveriam estar 100% sob domínio do negócio, mas isto também não deve acontecer porque as soluções BPMS necessitam das áreas de TI para execução. Existe todo um controle de versionamento, instalação de novas versões, e mais uma série de ativi-dades que a TI já está habituada a lidar no dia-a-dia. A melhor forma de implementar uma campanha de marketing, por exemplo, precisa do aval da TI para se tornar assertiva. Creio que o desenho mais realista de que tenho conhecimento é aquele em que SOA vai aumentando sua influência quanto mais próximo está da TI (figura 3), enquanto o BPM tem mais influência quanto mais próximo está do negócio.

Na verdade a influência (ou relevância) do SOA se reduz quando caminhamos para as áreas de negócio e a influência das soluções BPMS diminuem quando caminhamos para as áreas de TI. Nunca nenhuma das duas é completamente independente da outra.

Bem, e qual é o modelo que resolve a maior parte dos problemas? Certamente esta resposta ainda não existe hoje, e as ferramentas vão amadurecendo a cada nova abordagem que se tenta implementar.

Figura 3. Relacionamento entre SOA e BPM em uma corporação.

Considerações finais

Como seria de se esperar, os processos evolutivos das linguagens de programação estão fazendo com que cada vez menos programação seja necessária. Inicialmente, os programas eram criados em Assembly. Com o advento das linguagens descritivas, de mais alto nível, como Cobol, Fortran e ADA, os programadores aprenderam linguagens de mais alto nível. Isto não tornou os sistemas mais simples de serem co-dificados. Na verdade as regras ficaram mais complicadas. Nem as APIs e frameworks de mais alto nível tornaram as atividades mais simples ou demandando menor quantidade de programadores. Mas cada vez mais a linguagem Java será utilizada como infraestrutura de criação dos produtos, e menos codificação de sistemas. Na maioria das situações, teremos que lidar com editores gráficos que irão abstrair a implemen-tação na maioria dos casos. Continuar insistindo nos modelos atuais de implementação seria o mesmo que implementar uma folha de pagamentos hoje em assembly (totalmente inviável). O plugin WTP do eclipse, por exemplo, permite uma grande parte das atividades de codi-ficação de um aplicativo Web com pouco acesso aos códigos. Soluções específicas dos fabricantes aumentam ainda mais este patamar. Entre-tanto, quando uma destas soluções inevitavelmente falhar, as pessoas que tiverem conhecimento profundo das bases de funcionamento do

http://www.oracle.com/us/technologies/bpm/index.html

http://www-01.ibm.com/software/br/websphere/info/bpm/

http://www.bpmn.org/

http://www-01.ibm.com/software/solutions/soa/

ReferênciasBem, esta é uma discussão que normalmente gera polêmica. Parece-me que se seguirmos a linha de pensamento deste artigo, SOA está muito relacionado à TI. Mas como a abordagem do SOA proporciona uma criação de serviços mais genéricos, e que atendam a várias demandas de várias das áreas de negócios, a TI precisaria de algum conhecimento