Um pensamento interessante que encontrei num artigo do bpminstitute.org foi o seguinte:

"The absence of an ESB is the most readily identifiable sign of a BPMS that is not really layered on SOA."

Concordo que a existência de um ESB é um elemento fundamental para realizar uma arquitectura service-oriented. Por isso, também achei interessante esta opinião de que não podemos realizar um BPMS sem haver um ESB. É como se os ESB estivessem "no meio" do caminho, entre SOA e BPM.

De facto, depois de identificarmos os candidatos a serviços e procedermos à sua implementação de acordo com as boas práticas, ficamos com um conjunto mais ou menos alargado de entry points que temos que gerir individualmente.

E na verdade, enquanto temos meia dúzia de serviços, tudo vai bem sem ESB. O pior é quando começamos a ter dezenas ou até centenas de serviços para gerir: cada um deles vai ter necessidades de autenticação e autorização dos seus clientes, registo de pedidos e respostas efectuadas, protecção de pedidos mal-formados, cache para aumentar a sua disponibilidade e escalabilidade, etc.

É aqui que entram os ESB. Em vez de haverem clientes a invocar serviços directamente, existe uma espécie de "hub" ao qual podemos ligar para enviar e receber mensagens dos serviços. Este mecanismo simples, que na sua essência de broker promove a autonomia dos serviços, permite centralizar todas as funcionalidades descritas que eram da responsabilidade de cada serviço e afigura-se decisivo para obtermos a desejada redução drástica do tempo e complexidade do desenvolvimento, de cada vez que necessitamos de um novo serviço.

Aqui chegados, dir-se-ia que realizámos a arquitectura service-oriented. Mas não é assim.

Ao contrário do autor do artigo, não considero que SOA seja "IT-driven". A arquitectura service-oriented não começa, não acaba e não se traduz num projecto eminentemente técnico. Com um ESB que gere as interacções entre os serviços, temos uma ferramenta poderosa em que podemos basear o negócio de uma organização. Mas de que serve tamanho poder se estiver numa forma que não é directamente utilizável pelas pessoas que detêm a visão estratégica do negócio e que conhecem os seus processos e interacções?

Considero que o factor primordial num projecto SOA deve ser a participação. As arquitecturas service-oriented não são exclusivas do staff de IT. Pelo contrário, são os decisores de negócio quem devem dar a primeira e última palavra em SOA: no início, para nos dizer onde está o valor do negócio e que serviços é prioritário disponibilizar para assegurar esse valor; durante, para acompanharem todo o processo SOA, de modo a sentirem que se identificam com o projecto, que a sua visão é considerada e que a estratégia de desenvolvimento de baseia naquilo que consideram ser importante; e por fim, para procederem à avaliação da visão estratégica que formularam, por forma a aperfeiçoarem o que foi alcançado e se sentirem motivados em iniciar mais um ciclo do processo, com novos objectivos, mais ambiciosos, mais estruturados e com um espírito de equipa e pertença ainda maior, em suma.

A possibilidade de criar e alterar os processos de negócio de uma forma simples é há muito tempo uma ambição dos gestores. Mas só nos últimos anos começaram a proliferar algumas tentativas de dar uma forma estruturada e standardizar estas abordagens. Uma das linguagens mais importantes nesta área, o BPEL (ou BPEL4WS, como se prefira) tem assumido uma visibilidade crescente. Usando uma ferramenta visual geradora de BPEL, podemos facilmente criar novos serviços a partir da composição de outros serviços já existentes.

Cada processo desenvolvido com BPEL é ele próprio um serviço como qualquer outro, possuindo o seu próprio WSDL. Modelando os processos de negócio fundamentais de uma organização, podemos de seguida criar mais processos, de mais alto nível, porque vão usar os processos criados em BPEL como se fossem serviços individuais. E assim sucessivamente, como se fosse uma vista "em fractal" dos serviços, que no limite serão sempre encapsulados por mais serviços.

Em síntese, penso que a modelação dos processos de negócio é um objectivo natural das arquitecturas service-oriented, e não algo que vem à parte, como se fosse opcional. Mas concordo sem reservas que os ESB são uma peça fundamental sem a qual não realizamos nem uma coisa, nem a outra.