BT

Sucesso com SOA: modelo orientado a dependências e melhores práticas

por Mark Little , traduzido por Marcelo Cenerino em 02 Ago 2013 |

Durante o QCon San Francisco 2012, Ganesh Prasad discutiu sobre suas ideias a respeito de SOA; neste ano, expandiu algumas delas em um artigo sobre sua visão de SOA como um Modelo Orientado a Dependências ("Dependency Oriented Thinking").

SOA é a ciência de analisar e gerenciar dependências entre sistemas. "Gerenciar dependências" significa eliminar dependências desnecessárias e formalizar dependências legítimas para criar contratos de fácil compreensão.

Prasad elaborou o seguinte diagrama que ajuda a ilustrar essa ideia:



Ganesh afirma em seu artigo:

Na camada de negócios (Business layer) o foco em dependências nos força a racionalizar processos e a torná-los mais enxutos. Os processos de negócio precisam ser rastreáveis até a visão da organização (a visão utópica de onde se quer chegar), e até a missão (a estratégia para atingir a utopia da visão), e as atividades necessárias para executar suas estratégias (gestão de produtos, engenharia, marketing, vendas etc.) [...] Na camada de aplicações, tentamos agrupar as operações. Note que a camada de negócios já definiu o agrupamento de operações dentro dos processos. Na camada de aplicações precisamos agrupá-las mais estaticamente.

Quais operações trabalham em conjunto e deveriam ser agrupadas, e quais não? Trata-se de uma questão sobre dependências que precisa ser questionada nessa camada. A resposta, no entanto, será encontrada apenas na camada inferior, a camada de informações. A justificativa é que operações apenas são agrupadas se compartilharem um mesmo modelo de dados. Como se vê, existem dois grupos de modelos de dados: o interno e o externo. Os modelos de dados dentro de qualquer sistema são também conhecidos como "modelos de dados de domínio" e nunca são visíveis a outros sistemas. Em contraste, os modelos de dados externos a um sistema, conhecidos como "modelos de dados de interface", sempre são expostos e compartilhados com outros sistemas.

Recentemente, Ganesh teve a oportunidade de colocar essas ideias em prática em cenários reais. Para cada cenário com falhas, Ganesh sugere que o culpado pelas falhas seja rastreado até um ou mais princípios de dependências violados. Ele acredita que uma organização que segue essas regras acabará alcançando SOA. É claro, tivemos muitos outros exemplos ao longo dos anos em que SOA falhou ou teve sucesso, além de princípios e regras para tornar o uso de SOA bem-sucedido. Os princípios que Ganesh esboça podem ser classificados dentro das quatro camadas em que operam:

  • Camada de Negócios: (1) Rastreabilidade (Traceability) - Imponha governança, "garanta que tudo que é realizado faz sentido à visão da organização". (2) Minimalismo - Desafie pressuposições. (3) Visão de domínio (Domain Insight) - Entenda a natureza verdadeira do negócio, "reimagine o negócio a partir dos primeiros princípios".
  • Camada de Aplicações: (4) Coesão e acoplamento - "O que funciona em conjunto deve ficar no mesmo grupo, com ligações mínimas entre sistemas distintos". (5) Implementação vs. exposição - "Agrupe operações que compartilham um modelo de dados de domínio e lógica de negócio em produtos, e as que compartilham um modelo de dados de interface em serviços". (6) Variações e versões (Variants and Versions) - "Identifique múltiplas variações concorrentes de cada operação lógica e estabeleça meios para apoiar as mudanças em curso para suas lógicas e interfaces".
  • Camada de Informações (Dados): (7) Interno vs. Externo (Inside vs. Outside) - "Distinga o modelo de dados de interface, do modelo de dados de domínio". (8) Conteúdo vs. Contexto - "Separe os elementos de dados principais do modelo de dados de interface de seus elementos qualificadores". (9) Abstrato vs. Concreto - "Crie uma hierarquia de tipos de dados para os elementos de conteúdo e contexto".
  • Camada Tecnológica: (10) Agrupamento de dependências (Bundling Dependencies) - "Evite introduzir dependências recentes entre componentes não-relacionados ao implementar a lógica de negócio". (11) Associação tardia (Late Binding) - "Adie dependências inevitáveis até o último momento". (12) A ferramenta correta para o trabalho - "Implemente a lógica usando os mecanismos mais apropriados".

O que você acha desses princípios, e sobre o conceito de ver SOA como um modelo orientado a dependências? Esses princípios poderiam ter ajudado em algum projeto SOA em que você trabalhou? Consideraria utilizá-los hoje, ou modificá-los com base em suas próprias experiências?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT