Atualmente, mais e mais pessoas se conscientizam da importância de se introduzir o workflow em suas soluções. Mas quando se chega realmente na implementação, o debate entre criar ou usar continua. Em seu novo comentário "Workflow engine? Building one... " Bernd Rucker faz o balanço do assunto, discutindo os diversos erros de conceitos entorno do mesmo.
De acordo com Bernd, as razões típicas para se criar um workflow engine “caseiro” incluem:
- Temos apenas necessidades simples, com um controle de estado muito simples. Um mecanismo de workflow é exagero.
- O mecanismo deveria ser parte da nossa aplicação.
- Nós avaliamos o “produto X” e ele simplesmente não nos atende.
Embora, num primeiro momento, estas pareçam ser preocupações válidas, raramente justificam o esforço os custos da implementação caseira.
Nós temos apenas necessidades simples e conseqüentemente, não se justifica o tempo e o esforço de se aprender uma nova tecnologia/implementação. Como resultado, várias implementações começam com uma simples tabela de dados, captando as instâncias dos processos e os estados que estão. Mas, e se agora for necessário suportar:
- Estados de wait, guardando as variáveis da instância?
- Timeouts?
- Escalabilidade?
- Gateways de decisões?
Bernd destaca que, baseado em sua experiência, embora o desenvolvimento algumas vezes comece simples, o conjunto de requisitos tendem a crescer com o tempo e no fim as empresas normalmente empacam na manutenção e suporte de sistemas de workflow completos.
O mecanismo deveria ser parte da nossa aplicação e como resultado não queremos somar um monte de dependências de hardware, software, integração e procedimentos de instalação adicionais (típicos em diversas soluções de mercado).
A sugestão de Bernd para este cenário é, considerar um mecanismo workflow Java leve, que pode ser facilmente incluído no seu produto. São exemplos, JBoss jBPM, Nova Bonita ou Enhydra Shark. Esta classe de engines inclui uma gama de opções de configuração que as tornam facilmente adaptáveis para requisitos de aplicações específicas.
Nós avaliamos, ele não serve é um dos argumentos mais complicados de se lidar. De acordo com Bernd, o problema aqui é que uma avaliação razoável requer tempo e esforço, mesmo para um mecanismo workflow open source e leve. Se o tempo necessário não for usado na avaliação, os resultados serão insuficientes. Quando é levado o tempo suficiente para se entender a tecnologia, raramente se concluirá que a ferramenta não provê as funcionalidades desejadas. Bernd diz que, por exemplo, nenhum de seus clientes acharam algo que não pudesse ser facilmente implementada usando jBPM. É necessário apenas se gastar algum tempo entendendo a tecnologia.
Bernd resume seu comentário da seguinte forma:
Por favor, não desenvolva! [É um empreendimento muito custoso]. A curva de aprendizado [para entender a ferramenta] quase sempre se paga!...[Uma vez que se compreende o uso] a vantagem do uso de um engine [se torna] auto-evidenciado.
Hoje é muito raro as pessoas construírem suas próprias bases de dados ou O/R mapper ou Application Server. Por que é freqüente que pessoas pensem que devem escrever seus próprios mecanismos de workflow? Ele se tornou uma mercadoria e é, praticamente sempre, mais financeiramente viável usar uma implementação existente do que planejar e construir a sua.