Guerrilha SOA

Gravado em:

Muito bom. Parabéns ao Alexandre pela palestra e a toda a equipe da InfoQ Brasil publicação.

Trabalho com esse paradigma em algumas empresas grandes (com muito legado) e acompanho o trabalho de Jimm Webber, por isso gostaria de acrescentar mais um ponto: promover o alinhamento com o negócio (ou processo de negócio) seguindo alguns princípios SOA, por exemplo, encapsulando o domínio do serviço (legado ou não). Esses princípios não estão relacionados com tecnologia, mas com design.

Gosto deste artigo do Jim Webber: “But there is a more sensible way to SOA, which maintains loose coupling and drives high cohesion and the secret is this: build your services to implement business processes. Don’t let the data guys scream at you that you need an enterprise data model (you don’t) and don’t let the application portfolio guys demand that you buy everything and stitch it together later (you can’t, this only gets you Frankenstein systems).” Anemic Service Model , Jim Webber, Ph.D. Global Architecture Lead, ThoughtWorks.

Atualmente, muitas empresas sem uma abordagem SOA possuem iniciativas de reuso e integração isoladas, baseadas em iniciativas individuais. Funcionando em um delicado equilíbrio, os desenvolvedores reusam seus próprios serviços ou de uma pessoa em que confiam, ignorando todos os outros possíveis serviços existentes. Esse cenário de reuso limitado, possibilita que empresas complexas, com integrações espaguete, funcionem, pois existe um nível de controle até certo ponto gerenciável, mas abrindo mão da agilidade.

No entanto, se o reuso dos serviços legados for promovido em larga escala, 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áveis 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á obrigado a implementar algumas regras antes de usar. Neste exemplo, no mínimo, o serviço vai promover a redundância de regas de negócio para seus clientes.

Multiplique isso por 40 serviços e 200 sistemas, depois tente alterar um processo ou rega de negócio com agilidade... Se o negócio mudar, simplesmente será imprevisível o impacto em seus sistemas.

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 a redundância de regras. Portanto, os princípios SOA ajudam essencialmente no controle da complexidade, para lidar com limitações humanas como, por exemplo, memória.

Gustavo,

Concordo com o que você falou e em minha opinião para evitar esse impacto imprevisível, basta tratarmos as definições dos serviços a nível de estratégia de negócio.

Quando você quer oferecer um serviço para alguém, você deve deixar muito claro que serviço é esse e qual é o objetivo dele. Definir quão completo e robusto ele deve ser e também quão flexível. Definir um contrato a ser cumprido.

Apesar de que percebo que no mundo de SOA, muitos lerão o que escrevi acima e pensaram em termos técnicos, porém estou falando apenas em termos de negócio. A parte técnica deve ser escolhida e arquitetada de forma que atenda ao que foi definido acima com o menor esforço possível e com a maior simplicidade possível.

Felipe, esse é realmente um desafio constante: mostrar que SOA não é um monte de WS-*.

Concordo, contratos bem definidos (DbC) são fundamentais e simplicidade (usar a essência do negócio e não o simplismo) é o único caminho para organizar a TI e proporcionar respostas rápidas.

Vamos para guerrilha!

Gostei da forma como a palestra foi conduzida !!! NOTA 10