No "post" anterior eu comentei sobre a hierarquia de serviços envolvendo Serviços de Negócio e Serviços de Integração. Nesta estrutura, que é a essência de SOA, há outras categorias de serviços como Serviços Externos e Serviços Utilitários. Contudo, mais uma vez para a implementação de SOA na sua plenitude, é importante que o projeto atinja o nível de abstração dos Serviços de Negócio.
Este objetivo só poderá ser atingida através de um esforço corporativo que envolve, inexoravelmente, unidades de negócio. Desnecessário dizer que tal movimento não é simples tampouco barato. É muito comum projetos SOA serem conduzidos pelos departamentos de tecnologias das empresas onde não há visibilidade ampla e profunda dos requerimentos de negócio, processos, etc das unidades e linhas de negócio da empresa.
Por conta disso, projetos SOA usualmente transformam-se em projetos SOI ou "Service Oriented Integration". Apesar de semelhantes as siglas não têm muito em comum: enquanto SOA é uma arquitetura de serviços de negócio, SOI é sobre integração de sistemas. Este termo é normalmente usado para denotar projetos de integração de sistemas que usam os mesmos protocolos usados na implementação de SOA (por exemplo, Web Services e Enterprise Service Bus (ESB)). SOI cumpre um papel similar à infraestrutura EAI ("Enterprise Application Integration") que projetos no passado lançavam mão. A diferença é o uso de tecnologias mais "modernas".
Dentro da hierarquia de serviços, teríamos uma linha sutil que distinguiria os serviços de alto nível de abstração (pertencentes ao projeto SOA) dos serviços de baixo nível (de responsabilidade do projeto SOI). Abaixo uma figura ilustrativa:
Este objetivo só poderá ser atingida através de um esforço corporativo que envolve, inexoravelmente, unidades de negócio. Desnecessário dizer que tal movimento não é simples tampouco barato. É muito comum projetos SOA serem conduzidos pelos departamentos de tecnologias das empresas onde não há visibilidade ampla e profunda dos requerimentos de negócio, processos, etc das unidades e linhas de negócio da empresa.
Por conta disso, projetos SOA usualmente transformam-se em projetos SOI ou "Service Oriented Integration". Apesar de semelhantes as siglas não têm muito em comum: enquanto SOA é uma arquitetura de serviços de negócio, SOI é sobre integração de sistemas. Este termo é normalmente usado para denotar projetos de integração de sistemas que usam os mesmos protocolos usados na implementação de SOA (por exemplo, Web Services e Enterprise Service Bus (ESB)). SOI cumpre um papel similar à infraestrutura EAI ("Enterprise Application Integration") que projetos no passado lançavam mão. A diferença é o uso de tecnologias mais "modernas".
Dentro da hierarquia de serviços, teríamos uma linha sutil que distinguiria os serviços de alto nível de abstração (pertencentes ao projeto SOA) dos serviços de baixo nível (de responsabilidade do projeto SOI). Abaixo uma figura ilustrativa:
Várias fontes descrevem SOI em detalhes. Dentre elas destaco o livro "Service-Oriented Architecture - A Field Guide to Integrating XML and Web Services", primeiro de uma coleção importante de Thomas Erl e outros. Apesar de, durante a leitura, termos a impressão que SOA é implementável somente com a pilha de tecnologias Web Services, há referências que ressalvam que WS-* não são a única opção para isso.
O emprego das mesmas tecnologias para a implementação de ambos os projetos leva a mais uma confusão ou engano: projetos SOI são chamados de SOA. Entretanto, por outro lado, um projeto SOI pode ser considerado como um "entry point" para o projeto SOA que compreenderá outras diversas dimensões e requerimentos. Há várias vantagens para isso:
- Um projeto SOI é tipicamente conduzido pela equipe de TI da companhia posto que o envolvimento de analistas de negócio é muito improvável. As questões a serem resolvidas normalmente têm considerações puramente técnicas.
- O projeto SOI pode ser um "laboratório" importante para especialização sobre as tecnologias WS-*, ESB, etc. Afinal, em tese, essas mesmas tecnologias seriam usadas na implementação dos Serviços de Negócio.
- Liberdade de escolha de produtos: a infraestrutura usada para a implementação de Serviços de Integracão não é necessariamente a mesma usada para os Serviços de Negócio.
- A implementação dos Serviços de Integração pode ocorrer distintamente à dos Serviços de Negócio, diminuindo os riscos.
- As infraestruturas separadas permitem que o processo de evolução dos serviços seja altamente escalável.
Uma das principais diferenças entre os famosos ESBs e EAI é aquilo que David Chappell, Vice Presidente da Oracle para SOA, definiu no seu já classico "Enterprise Service Bus" de 2004, como "Distributed Integration" ou Integração Distribuída. O grande benefício dos ESBs é a capacidade de distribuir os seus requerimentos de integração. Instâncias isoladas de ESB são responsáveis por uma coleção específica de processos de integração. A figura acima mostra isso: o ESB de nível mais baixo de abstração é responsável por questões totalmente particulares de integração e distintas ao ESB de mais algo nível. Em termos de implantação os ESB podem ser (e normalmente são) de fornecedores diferentes e rodam em ambientes operacionais (Sistemas Operacionais, Hardware, etc) também específicos. Claro que, de acordo com a demanda, novas instâncias de ESB podem ser adicionadas em cada uma dessas camadas para novamente dividirmos responsabilidades de integração.
Como conclusão, a implementação de toda e qualquer demanda de integração em um único ESB, geralmente, não é um bom negócio. Em um ambiente crítico haverá um diversidade muito grande de classes de softwares e, para cada um deles, uma coleção de instâncias de ESBs. Uma aproximação como essa é antes de mais nada escalável e consequentemente apresenta menos riscos em todos os sentidos: desenvolvimento, gerenciamento, manutenção, produção, homologação, etc.
Nenhum comentário:
Postar um comentário