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?

Avalie esse artigo

Relevância
Estilo/Redação

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
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.