Recentemente tive a oportunidade de apresentar um webinar pela iProcess sobre “A orquestração como instrumento para integrar sistemas”, que apresentou conceitos de SOA, BPEL e orquestração de webservices, além de apresentar uma breve introdução sobre como desenvolver projetos de integração utilizando orquestração.

Você pode rever o webinar no canal do Youtube da iProcess ou nos links abaixo:

Ao final do webinar recebemos algumas perguntas dos nossos participantes. Procurei resumir abaixo em principais idéias, levando em consideração que alguns assuntos são amplos e seria impossível esgotar o argumento nas respostas. Deixo aos leitores completarem com seus comentários e percepções.

1) Quais são as principais vantagens da utilização de BPEL em relação ao desenvolvimento de um serviço orquestrador, escrito em Java por exemplo?

Entendo, com essa pergunta, que estamos falando da utilização de um produto que implementa o SOA/BPEL. Vou pegar como exemplo o Oracle SOA Suite 11g, que inclusive foi desenvolvido em Java.

Falemos, então, de vantagens e desvantagens da utilização desse tipo de produto.

VANTAGENS

•  a principal vantagem é poder contar com uma infraestrutura de middleware pronta (estilo caixa-preta) que possibilita o rápido desenvolvimento de soluções complexas, além de incluir o controle de instâncias de curta e longa duração, a disponibilização de adaptadores para conexão direta a diferentes serviços (banco de dados, AQ, MQ, JMS, arquivos, webservices, etc), monitoramento do ambiente, ferramentas de configuração, etc;
• a possibilidade de implementar rapidamente processos de negócio bem definidos;
• no caso do Oracle SOA Suite, é possível utilizar toda a infraestrutura disponibilizada pela suite, que inclui, além do BPEL, componentes de business rules, tarefas humanas (human task), mediator e BPM.

DESVANTAGENS

• quando trabalhamos em projetos que exigem alta-disponibilidade, grandes quantidades de operações por minuto, cloud-computing, grande quantidade de serviços, entre outros desafios, o middleware deixa de ser uma caixa-preta e passa a ser uma caixa-cinza, exigindo do time de arquitetura, desenvolvimento, infraestrutura e suporte um conhecimento profundo do produto, o que nem sempre é fácil;
• o custo do produto costuma ser alto;
• o middleware é um produto que inclui muitas camadas (sistema operacional, máquina virtual [Java, por exemplo], banco de dados, conexões diversas, além de utilização de memória, disco, processador, temperatura). Em ambientes de produção tudo isso deve ser controlado. Nem sempre é fácil identificar rapidamente quando um problema ocorre, exigindo novamente grande conhecimento do produto.

2) Quando vai ser feita a implantação de uma orquestração, espera-se que já esteja implementada uma arquitetura orientada a serviço?

Não necessariamente. Como foi comentado durante a apresentação, uma boa orquestração prevê a descrição do processo de negócio que será orquestrado e todos os pontos de orquestração bem definidos.

Porém já tivemos casos de orquestração que utilizavam somente troca de arquivos, conexões a banco de dados e filas e acesso direto a API’s de outros sistemas utilizados pela empresa, sem que existisse, de fato, uma arquitetura orientada a serviço na empresa.

É certo, porém, que os projetos que podem contar com esse pré-requisito acabam utilizando melhor todos os recursos que a orquestração dispõe, desde o controle das instâncias, erros e execuções até o completo monitoramento do ambiente como um todo.

3) É comum construir orquestração de serviços e “expor” essa orquestração dentro de um ESB?

Já atuei em projetos que nem sequer utilizavam ESB e outros que expunham sempre um serviço no ESB. Na minha visão isso depende da arquitetura que será utilizada no projeto.

4) Gostaria que o Eduardo comentasse mais sobre os papéis dos projetos e a interação entre eles.

Durante a apresentação utilizamos a imagem abaixo:

Falando um pouco sobre a função de cada um desses papéis:

• Arquiteto de integração: ele será responsável por desenhar toda a solução técnica da integração e definir quais serão os padrões utilizados. É papel do arquiteto, também, desenhar os diagramas de componentização das integrações.
• Analista de processo: irá trabalhar junto aos usuários de negócio na definição dos processos que serão orquestrados e na definição da estrutura de dados.
• Desenvolvedores e técnicos de infraestrutura que farão o desenvolvimento das integrações propriamente ditas.

Nos projetos nos quais trabalhei a figura do arquiteto foi essencial. Ele deve ter clara a visão do todo e entender realmente o problema, definindo quais recursos de TI serão utilizados na integração. Além dele, o analista de processo tem um papel fundamental na compreensão e na documentação dos processos que serão automatizados e orquestrados, cabendo aos desenvolvedores uma boa implementação e aos técnicos de infraestrutura a garantia de que o middleware estará bem configurado para suportar a solução.