Muitas empresas sem uma abordagem SOA possuem iniciativas de reuso e integração, promovidas por talentos individuais. Funcionando em um delicado equilíbrio, em que os desenvolvedores reusam seus próprios serviços ou os de uma pessoa de sua confiança, ignorando todos os outros possíveis serviços existentes (internos ou externos).

Nesse cenário de reuso limitado, empresas complexas com integrações espaguete e redundância de regras de negócio conseguem sobreviver - pois existe um nível de controle até certo ponto gerenciável -, mas abrindo mão da agilidade (uma alteração do negócio pode demandar um esforço imprevisível).

Por outro lado,  promover o reuso indiscriminadamente usando ferramentais atuais sem observar alguns princípios SOA, esse equilíbrio pode ficar comprometido. O que inicialmente pode parecer um ganho, com o efeito acumulativo, deixará muito mais complexo o cenário.

Para exemplificar, vamos imaginar um serviço legado de lançamentos contábeis que não encapsula todas as regras de negócio necessárias para efetuar o lançamento (não segue princípios SOA). Desta forma, todos os clientes deste serviço serão obrigados a implementar algumas regras antes de usar. Neste exemplo o serviço vai, no mínimo, promover a redundância de regas de negócio e acoplamento exagerado para seus clientes.

Multiplique isso por 40 serviços e 200 sistemas, depois tente alterar um processo ou regra de negócio com agilidade… Se o negócio mudar, simplesmente será imprevisível o impacto em seus sistemas. Outro exemplo, se for comprado um pacote de mercado para o backoffice (por exemplo, contabilidade), todos os sistemas que automatizam o processo de negócio principal (que gera dinheiro) será alterado significativamente.

Em outras palavras, o reuso e a integração limitada (atualmente um cenário comum) também limita a propagação dos problemas gerados por serviços que não seguem certos princípios SOA – portanto não é interessante sair reutilizando. Mas como obter agilidade e lidar com o legado?

Não existem respostas fáceis, cada cenário é único. No entanto, para evitar esse problema e muitos outros, o serviço poderia ser encapsulado ou alterado para que atenda alguns princípios SOA, possibilitando que seja reutilizado por todos sem aumentar a complexidade e redundância das regras.

SOA deve simplificar a TI para obter agilidade, usando abstrações obtidas com a análise do negócio, o serviço. SOA não é necessariamente integração e reuso, mas lida diretamente com as limitações humanas, por exemplo, pouca memória e manter cenários complexos, usando abstrações. Abstração está intimamente relacionado com encapsulamento. Portanto, encapsular o legado com serviços bem projetados é essencial.

Atualização:

Encapsular legado significa: encontrar conceitos importantes no legado e criar serviços que encapsulem as regras destes conceitos. Não é apenas criar uma camada de serviços, também envolve, em alguns casos, alterações no legado (mudar regras de lugar, por exemplo: todas as regras de negócio coesas com o serviço - identificado analisando o negócio do legado - que estão em outras aplicações, devem ser retiradas e encapsuladas pelo serviço).

As referências clássicas são IBM Rational e Thomas Erl , no entanto, existem alguns autores que não são focados no tema que possuem um material importante, por exemplo:

Robert C. Martin
Founder, CEO, and president of Object Mentor Incorporated.

Jim Webber
Global Architecture Lead, ThoughtWorks

Martin Fowler
Author, speaker, consultant and general loud-mouth on software development

Existem muitas referências para projetar serviços no mercado, para navegar e obter resultados com essas abordagens é importante compreender a essência. Uma boa base geral ajuda muito, criei uma relação de livros para uma formação básica, mas não relacionados diretamente com SOA. Claro que não é uma lista definitiva, mas um começo interessante.

Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series)

Fundamentals of Object-Oriented Design in UML (Addison-Wesley Object Technology Series)

Business Component Factory : A Comprehensive Overview of Component-Based Development for the Enterprise (Hardcover)

UML Components: A Simple Process for Specifying Component-Based Software (Component Software Series)

Domain-Driven Design

Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series)

Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Signature Series)

Refactoring to Patterns (Addison-Wesley Signature Series)

O interesse e as contribuições relevantes do público presente foi um dos destaques do evento, e possibilitou um rico diálogo. O formato de talk show, com o uso de questões previamente elaboradas pelo grupo de interesse em BPM, incentivou a interação entre todos.

O painel foi formado por profissionais com forte atuação no mercado: Marcilio Oliveira, da Digital Assets, André Boaventura, da Oracle, e por mim, da CPM Braxis.

Gostaria de agradecer o convite e a troca de experiência.

Para ter acesso ao material de apoio e às atividades do grupo: GI_BPM_SucesuRJ

Vendedores de ferramentas ESB freqüentemente usam em suas apresentações uma figura clássica, que representa a complexidade de TI causando grande impacto visual. Em seguida, usando uma figura mais impressionante, mostram como ferramentas ESB podem organizar a casa, resolvendo todos os problemas.

No entanto, a verdadeira flexibilidade de SOA é obtida com serviços bem projetados, não com a adoção de ferramentas (muitos vendedores deixam essa impressão). Os serviços devem ser representativos para o negócio, seguindo certos princípios, como: low coupling, stable interface, entre outros.

Sem serviços bem projetados o cenário não muda muito: toda bagunça produzida no mundo corporativo, criando integrações espaguete, não some com a implantação de ESBs. Apenas fica escondida debaixo do tapete, ou seja, dentro do barramento, exigindo uma “lógica de conectividade” muito complexa.

Realidade de TI, nossa versão:

Aparente milagre de ferramentas ESB (onde está a bagunça?):

Olhando mais de perto, de acordo com Jim Webber, o que realmente acontece com ESB:

Aplicações sem serviços bem projetados misturam a lógica do fluxo do negócio (processo de negócio), lógica de conectividade e a lógica de domínio em abstrações pouco coesas; desta forma aumenta drasticamente o acoplamento e complexidade da integração, sendo comum a ocorrência de dependência circular.

Em outras palavras, mesmo com uma ferramenta ESB eliminando a integração ponto a ponto, na ausência de serviços projetados para apoiar processos de negócio (ou seja, sem SOA), ainda teríamos “integração espaguete”, só que agora escondida dentro de uma ferramenta, inviabilizando a flexibilidade prometida pela abordagem SOA.

Já trabalhei em empresas que utilizam o Broker e o que acontece é que a complexidade das integrações passa para dentro dessa ferramenta. Por um lado isso é bom porque o ESB / Broker passa a ser um ponto comum de comunicação, gera uma padronização e outros ganhos.

Mas se o que está dentro do ESB / Broker não estiver muito bem projetado, ficará quase impossível dar manutenção e suporte. Usar ESB assim é equivalente a pegar a integração espaguete e dar um nó no meio, este nó é o ESB. Para desatar o nó apenas serviços bem projetados.

Vídeo interessante relacionado com SOA sem ESB: Does My Bus Look Big in This?, Martin Fowler & Jim Webber, QCon London 2008. Um post também interessante relacionado: SOA, cuts the Gordian Knot — Not, Uncle Bob.

Apenas por curiosidade, desenhamos as figuras que ilustram o post utilizando Java e a API para desenho 3D Java Monkey Engine.

Espaguete.java

EspagueteComNo.java

Front de batalha:

“Aquele blog de SOA publicou um post meu. Este blog reúne consultores SOA com experiências distintas, atuando fortemente no mercado.

No post procurei conceituar SOA sobre a ótica do Serviço, contando com citações de autores como: Jim Webber, Uncle Bob e Thomas Erl.”

No post procurei conceituar SOA sobre a ótica do Serviço, contando com citações de autores como: Jim Webber, Uncle Bob e Thomas Erl.

“Fundamentally, DDD is the principle that we should be focusing on the deep issues of the domain our users are engaged in, that the best part of our minds should be devoted to understanding that domain, and collaborating with experts in that domain to wrestle it into a conceptual form that we can use to build powerful, flexible software.” - Eric Evans, infoq.

“…SOA, when it is used well, provides us a very useful way of isolating the domain.” - Eric Evans, infoq.

Artigo interessante: Domain-Driven Design

[ Temos neste blog uma taxonomia de referencia, facilitando a exploração de conceitos, pois existem muitas abordagens conflitantes no mercado. ]

Os serviços básicos de negócio (parecidos com “serviços corporativos” para Erl), por exemplo, encapsulam um domínio, expondo funcionalidades básicas e mais atômicas do negócio (regras de negócio), são coesos e pouco acoplados, normalmente representam um conceito principal do negócio. (Em corporações complexas, dificilmente teremos total controle de duplicação de regras, mas podemos usar algumas abordagens, por exemplo, serviços compostos, para encapsular essas redundâncias.)

Algumas abordagens do livro de Eric Evans podem ajudar na organização desses serviços básicos negócio, por exemplo, distillation na parte de Strategic Design (apenas os serviços importantes para o negócio serão publicados, os serviços essenciais). “Distillation is the process of separating the substances composing a mixture. The purpose of distillation is to extract a particular substance from the mixture. During the distillation process, some byproducts may be obtained, and they can also be of interest. ”, Eric Evans. Strategic Distillation.

Essas abordagens se destinam, na maioria das vezes, a superar limitações humanas, como gerenciar complexidade. Não são incomuns empresas com várias equipes (ou consultorias) desenvolvendo sistemas para automatizar partes diferentes do mesmo subprocesso de negócio.

….

Serviços, em muitos casos, são construídos utilizando objetos. O domínio é “instanciado” também usando objetos (por exemplo, POJOS), objetos devem garantir seu estado consistente (Page Jones) e muitos devem ser persistidos. Neste ponto, começam as dificuldades técnicas, por isso usamos AOP (por exemplo, Spring Framework), EJB 3.0, hibernate; possibilitando focar esforços no domínio (camada de negócio). Algumas abordagens e experiências com uma aplicação JPA e Spring estarão em um próximo post.

A criação de níveis de orquestração, por exemplo, exige um projeto mais elaborado. Serviços compostos proporcionam baixo acoplamento, funcionam como uma camada de indireção para outros serviços, substituindo trocas de mensagens diretas (projeto mais simples) por orquestrações (projeto mais elaborado).

Soluções com SOA se destinam, na maioria das vezes, a superar limitações humanas, como lidar com grande quantidade de sistemas com regras compartilhadas e processos complexos freqüentemente alterados. Para lidar com tal complexidade, no caso de SOA, a principal abstração é o serviço de processo de negócio. Serviços orientam a arquitetura e fornecem um vocabulário comum entre TI e as áreas de negócio.

Além da relevância para o negócio, é necessário considerar o equilíbrio entre processos, ferramentas e pessoas. Na prática, não é fácil conciliar interesses de projetos de desenvolvimento de software - que possuem pressão de prazos, custos e objetivos imediatos - com os interesses mais corporativos e estratégicos. Corrida de cem metros ou maratona? Por isso, só e viável a abordagem SOA se for possível o mínimo de governança, com políticas de propriedade de serviços e de incentivos.

Grandes corporações encontram desafios em coordenar e gerenciar várias equipes simultâneas, e algumas vezes desenvolvendo partes diferentes do mesmo sistema. Isto resulta na necessidade de uma forma fácil de planejar, divulgar e reaproveitar processos de governança e práticas mais ágeis, algumas ferramentas podem ajudar como, por exemplo, o Team Concert.

Já no caso de ferramentas, ESBs são interessantes, mas não obrigatórias para SOA, sendo os processos e os métodos mais importantes. Contudo, ferramentas que podem apoiar a governança SOA como, por exemplo, EPF, DAM e JAZZ, devem ser seriamente consideradas.

Finalmente, uma equipe madura, treinamentos e consultoria são essenciais.