Blog do Eduardo Costa Meu blog pessoal

18Ago/112

Serviços, SOA e BPM

Agora que meu amigo Flávio vai para uma empresa que trabalha com BPM, dei uma introdução sobre o assunto que acho que outras pessoas podem se beneficiar. Vamos contar uma historinha.

Tudo começou com o desenvolvimento "clássico" de aplicações. O desenvolvedor ouve o que o cliente/usuário quer e transforma isso em programas. Esse modelo funcionou muito bem até que a quantidade de código tornou-se tão grande que inviabiliza continuar com um único sistema monolítico. Surgiram os "módulos" (cadastro de funcionários, clientes, contas a receber, etc).

Com um sistema modular, fica mais fácil a expansão e manutenção de cada módulo individualmente. O time de desenvolvimento continua recebendo as requisições do cliente/usuário, mas, dessa vez, cada parte interessada só precisa afetar seu próprio módulo. Tudo maravilhoso, até que as necessidades dos módulos começam a se interseccionar. "Contas a receber" depende do cadastro de clientes, "pagamento" depende dos funcionaŕios, etc. Surge o conceito de "serviço".

Ao invés do cadastro de cliente só existir no módulo de "clientes", ele pode existir como um "serviço de clientes", e os demais módulos usam esse serviço: o módulo de "clientes" alimenta esse serviço com novos clientes, enquanto "contas a receber" usa o mesmo serviço para alimentar sua própria base de contas com dados dos clientes devedores. "Serviço", segundo a Wikipedia, é um conjunto agregado de funcionalidades somado com uma política de acesso. Repare que um serviço não precisa ser um Web Service SOAP ou REST! O importante é agregar uma funcionalidade autocontida e controlar o acesso à informação (ou seja, nada de "SELECT"s direto na base). Até um "JAR" devidamente configurado ou um Servlet serviria.

Se você consegue encapsular as funcionalidades em serviços, por que não encapsular TODAS? Tudo poderia ser serviços ("Confirmação de Cliente", "Inclusão de Conta", "Aprovação de Acesso de Funcionário", etc), bastando uma interface bem fina, só para orquestrar e receber dados do usuário. Isso podemos chamar de uma arquitetura orientada a serviços. Ou seja, SOA. Com SOA, assumindo que todo o negócio do sistema está modularizado em serviços, toda nova funcionalidade fica simples de implementar: basicamente basta fazer uma nova orquestração para os diversos serviços já existentes. Novos serviços surgem com bem menos freqüencia - basicamente, surgem com as funcionalidades mais "inovadoras" (integração com o setor financeiro, uma nova empresa comprada, etc).

Daí, com vários serviços já prontos, o trabalho principal da equipe de desenvolvimento é receber as necessidades do cliente/usuário, modelar o negócio e orquestrar em SOA. Nesse nível, normalmente, a empresa já tem uma equipe de negócio especializada. O trabalho dessa equipe, então, fica meio estranho pensando de forma "clássica": a equipe de negócios recebe a requisição do cliente/usuário e repassa aos desenvolvedores. Qual a utilidade deles? Temos pauta para muita discussão, mas esse não é o foco. Em minha opinião pessoal, quando o trabalho deles é bem feito, tem muita utilidade.

O que aconteceria se a equipe de negócio, ao invés de rabiscar no "Word", rabiscasse a orquestração em um "meta-sistema"? Se fosse possível, nesse sistema, dizer que existe um formulário que deve enviar ao serviço de cadastro de clientes, obter a resposta, enviar ao serviço de "abrir ordem de serviço", aguardar confirmação do gestor por e-mail, etc, etc? Muito mais fácil que implementar a tela que chama dois serviços, envia e-mail, etc. Com isso, seria possível modelar o processo que rege um negócio. Oras, isso é o tal BPM (Business Process Management)! Com BPM, os desenvolvedores fazem os vários serviços, enquanto a equipe de negócio orquestra tudo.

Se é tão maravilhoso, por que parece não funcionar? Simples. Quem leu o que escrevi sobre "mercado versus inovação", pode ter imaginado: ainda não houve inovadores suficientes para que o mercado possa seguir. Logo, alguns erros básicos geralmente são cometidos:

  • Programadores não entendem BPM - é triste, mas muitos programadores "clássicos" acham errado que a equipe de negócio faça a modelagem com ferramentas visuais. Acham que é mais fácil fazer uma tela em Java com toda a lógica e pronto. Eu, particularmente, acho que seria muito mais fácil fazer vários serviços SOAP ou REST e testar ao máximo com testes unitários - sem precisar de enormes armengues para testar a interface (isso quando é possivel testar). Como o serviço só contém lógica e uma política de acesso (nesse caso, a interface SOAP/REST), basta testar a lógica que o "bind" com o Jersey ou similar é o menor dos problemas;
  • Ninguém entende SOA - todo mundo acha que basta fazer tudo com webservices que você tem SOA. Falácia gravemente obtusa. SOA pressupõe serviços, e não webservices. WS só é padrão de facto em SOA pelos seus benefícios de passar firewall, usar "protocolos normais" (HTTP, XML), etc. Nada impediria que um JAR fosse um serviço, ou qualquer outra tecnologia mais obscura (CORBA, CICS, etc). O truque do SOA não é o "S", mas sim o "A". A arquitetura dos serviços é o fundamental. Se você nem sabe o que colocar no serviço, já era - desista de usar SOA por enquanto;
  • Querer começar criando novos serviços. Ou seja: fazer as novas funcionalidades em "SOA" e esquecer o legado. Mais uma falácia. Detesto esse erro clássico de tentar fazer algo reaproveitável começando do zero. Como reaproveitar se nem aproveitou ainda? Que tal olhar aquele sistema legado monstruoso e ver o que ele faz ao negócio? "Puxa, preciso fazer a funcionalidade de prospecção de clientes igual ao legado". Opa! Traduza para "preciso reaproveitar a prospecção de clientes do legado". Olha o tal "reaproveitar" aí. Transforma em um serviço! Legado usa uma outra tecnologia? Integração também é uma palavra bonita! Provavelmente você já tem um jeito de acessar o legado usando sua tecnologia nova (já vi até Java conversar com CICS!), então, faz o Java virar o tal WebService, somente traduzindo os dados e solicitando ao módulo legado. Pronto! Um serviço totalmente reusável surgiu! Mais inteligente que tentar recriar do zero, copiando o que tem no legado - e bem mais rápido de fazer, também.

Resumindo, reparem na história que contei. SOA e BPM encaixaram como uma luva por causa do legado de aplicações. Eles deram a base para transformar o sistema monolítico em módulos, depois em serviços, depois orquestrar com SOA, por fim modelar com BPM. Se tentar começar com BPM ou SOA sem ter profundos conhecimentos do negócio, nem de prática real em SOA/BPM, é evidente que algo errado vai acontecer.