Geração automática de serviços
Versus implementar conectores da aplicação
A maioria de soluções de BPM são sistemas do workflow disfarçados, e como tais, eles não suportam integração com sistemas de retaguarda do escritório. As transações distribuídas e mensagens confiáveis são conceitos desconhecidos para tais ferramentas. Para tranqüilidade delas, a integração com aplicações corporativas vem sendo tratada o maior salto da história do software corporativo, a idéia que você necessita conectores feitos sob encomenda para integrar com aplicações da empresa tais como PeopleSoft ou SAP. Nos anos noventa, os fornecedores de EAI fizeram fortunas com conectores: você quer incorporar uma ordem de compra nesta versão de SAP R/3? Compre o conector X, por uns $25.000 por CPU. Você quer obter a lista dos empregados dessa versão de SAP R/3? Compre o conector Y, por outros $25.000 por CPU. Na realidade, pode-se escrever um conector genérico para todas as versões de SAP R/3, anteriores ao SAP R/3 3.1i, que expõe todos os 200.000 BAPIs, IDOCs e RFCs como serviços web service, no momento, para transações padrão e feitas sob encomenda, sem escrever uma única linha de código. O mesmo pode ser feitos para Oracle, PeopleSoft, Siebel, e a maioria de aplicações corporativas para aí a fora. Se for possível, BPM 2.0 faça um exame da vantagem, e a menos que você tenha algum prazer masoquista em conectores e APIs obsoletos, ninguém terá que escrever mais os conectores de costume conectores.
Mas, como BPM 2.0 se relaciona com a SOA? A menos que você esteja ainda vivendo no mundo centrado no workflow dos anos 90, você saberá que a BPEL é importante. O problema é que a BPEL compreende somente serviços web service, e somente um tipo muito restrito de serviço web service - WSDL. Está aqui a má notícia: se você necessitar orquestrar transações que não são expostas ainda como um web service, a BPEL não lhe ajudará. BEA sugeriu o suporte a Java com a especificação BPELJ, mas não sabem que alguns analistas de processos não gostam de escrever código de Java, se passar esta, agradeceremos. Agora a boa notícia: um bom produto de BPM 2.0 pode dar-lhe bons serviços web service para qualquer coisa do lado de fora.
De acordo com o modelo de BPM 2.0, as interfaces web services devem ser geradas sobre a no mesmo momento para todos os sistemas da aplicação ou do middleware que suportar algum formulário API. Mesmo os sistemas legados de mainframe podem ser expostos APIs com o uso de ferramentas baseadas em telas comuns. Um BPMS bom alavanca estas APIs e geram interfaces web services para ele. Além disso, o modelo BPM 2.0 indica também que tais relações devem ser oferecidas para transações de entrada e saída, significando que o BPMS pode invocar uma transação com um sistema de terceiros através de um serviço web service (inbound), quando um sistema de terceiros puder chamar um processo distribuído em um BPMS através de uma relação muito similar (outbound).
Isto responde a uma pergunta que nós obtemos toda à hora: .eu necessito da SOA para usar BPM?. A resposta é .sim. e .não.. Sim, você necessita SOA para usar BPM, porque é como o modelo da execução de BPEL foi projetado. Mas não, você não necessita ter Arquitetura Orientada a Serviços no lugar antes de poder usar BPM, porque a mera instalação de um bom BPMS permitirá SOA na maioria de o que você já tem, ou pelo menos deve. Se você escolher o BPMS certo, virá com um Barramento de Serviços Corporativos (ESB) e um Repositório de Serviços que converterá tudo na Arquitetura Orientada a Serviços que pretende usar. Ou seja, compre BPM 2.0 e você obterá SOA grátis. E se você for sortudo o bastante e escolha um BPMS de Código Aberto, e você não terá que mesmo pagar por ela. É isto é o bastante, ou que?
