Um cenário concreto de arquitetura SOA.

Olá pessoal, tudo certo?

Mais um post de SOA, podemos? :)

Mas vamos ver um exemplo da vida real. Vamos pensar num cenário de contratação de funcionários. Que tal?

Nesse cenário, temos uma série de sistemas envolvidos. Quando um novo funcionário é contratado, você tem que fazer uma entrada no sistema de folha de pagamentos, depois no sistema de RH, para providenciar um crachá, por exemplo. Em seguida, um sistema de TI precisa ser alterado para liberar uma conta de usuário e assim por diante.

Ou seja, temos uma série de sistemas que precisam ser envolvidos, de sistemas legados a sistemas locais ou até hospedados fora da empresa.

E como pensar esse cenário numa arquitetura SOA?

Um ponto importante é pensar numa interface de serviços. É comum a gente falar de uma interface que expõe as funcionalidades associadas de cada sistema envolvido. Em seguida, note que os serviços expostos podem ser consumidos diretamente ou coordenados através de um workflow ou um grupo de processos. Na frente desse workflow temos uma série de aplicações que consomem essa arquitetura, de forma integrada. Para citar, podemos pensar em WCF - windows Communication Foundation, para essa integração programática ou implementações de ESB - Enterprise Service Bus, para um bus de integração com mais recursos. Vale conferir o site de ESB no Codeplex, no link https://www.codeplex.com/esb/ .

Num cenário envolvendo mainframe, por exemplo, podemos pensar em SOA encapsulando funcionalidades ou lógicas de negócio através de web services e consumindo esses serviços através de outras aplicações.

Num certo momento, um novo sistema ou serviço é adicionado ao cenário, sem impacto para toda a arquitetura. No exemplo de contratação de funcionários, podemos adicionar um sistema de controle do condomínio, para liberar uma garagem para o novo funcionário.

Assim, veja que existe um esforço para identificar quais funcionalidades e serviços podem ser implementados, assim como o tipo de coordenação que poder ser feita. Questões como latência, tempo de resposta de cada serviços, tipos de bindings de serviços (se TCPRemoting ou HTTPRemoting ou outros) são importantes.

Por isso, é comum dizer que SOA exige um entendimento de processos e negócios, durante a definição de sua arquitetura. SOA não é apenas um conjunto de Web Services publicados.

E você sabe, a partir de posts anteriores, que aplicações compostas podem ser o front-end dessa arquitetura de serviços. De volta ao nosso exemplo de contração de funcionários, uma aplicação composta poderia apresentar na mesma interface todos os serviços que integram essa experiência, facilitando o processo de contratação.

Num exemplo Microsoft, OBA - Office Business Application - é uma plataforma baseada em Office System que podem suportar a construção de aplicações compostas. A partir de um Excel, nosso usuário de RH poderia gerar uma planilha com os últimos números de contração de funcionários da empresa ou até mesmo o número de vezes que o novo funcionário deu entrada na garagem do condomínio.

Outros benefícios podem ser observados, como monitoração, segurança, federeção, versionamento, etc. Mas vale destacar que torna-se transparente para o usuário final a manipulação de diversos domínios de aplicação, de CRM e ERP's a serviços de sistemas legados ou serviços hospedados na Web, isto é, o MIX de aplicações cresce e a TI que conhecemos torna-se um ambiente capaz de fornecer todos os recursos para que nosso usuário componha suas necessidade de negócio.

Num caso como esse, ponto para uma arquitetura de SOA bem feita!

Por enquanto é só. Até o próximo post! :)

Waldemir.