![Fechar [x]](http://dw1.s81c.com/i/c.gif){kind=small}
A modelagem de informações é uma vasta disciplina. Este artigo enfatiza a modelagem de informações no contexto de uma arquitetura orientada a serviços (SOA) e, mais especificamente, as forças motrizes do design de modelos de dados usados em especificações de interface.
A abordagem para a modelagem da interface aperfeiçoou-se ao longo do tempo, acompanhando a evolução da maneira de pensar sobre a integração de processos e do sistema. Quando o cenário de TI de uma organização era um conjunto de silos independentes e desconectados, as interfaces podiam ser desenvolvidas e gerenciadas como algo privado para um único aplicativo. A adoção de hubs de integração para implementar soluções de integração de aplicativo corporativo (EAI) aumentou a ênfase no uso de modelos canônicos, como uma língua franca, entre vários sistemas. Em seguida, com a SOA, houve a percepção da importância de separar a integração dos processos de negócios e criar serviços que pudessem ser usados em toda a organização no contexto de diversos processos, como mostrado na a Figura 1.
Figura 1. Com a SOA, a modelagem de dados atravessa as fronteiras das unidades de negócios
No entanto, assim como quaisquer outras iniciativas corporativas, muitos programas de SOA sofrem com o conflito entre restrições táticas e com ênfase no projeto e com os objetivos corporativos estratégicos. Qualquer pessoa com experiência no fornecimento de soluções saberá que não é possível desenvolver serviços corporativos reutilizáveis com base nos requisitos de um único projeto. Há metodologias de arquitetura estabelecidas, incluindo o The Open Group Architecture Framework (TOGAF) e o Service-oriented Modeling and Architecture (SOMA), que podem ser usados para identificar um portfólio de serviço corporativo; mas eles ficam em um nível de abstração necessário para atender às preocupações de planejamento corporativo e não chegam ao nível de detalhamento necessário para a implementação. A quantidade de análise necessária para obter uma especificação de serviço corporativo completa e abrangente iria contra a mesma agilidade de negócios permitida pela SOA.
Os modelos do segmento de mercado podem preencher essa diferença, fornecendo artefatos de análise e design que podem ser usadoscomo planos e normas para projetos SOA. Os corpos dos segmentos de mercado ou vendedores individuais, com o objetivo de combinar experiência e melhores práticas do segmento de mercado de forma útil para acelerar a entrega de soluções de negócios, criam esses artefatos. Os modelos do segmento de mercado se beneficiam da experiência de centenas de organizações e seus anos de desenvolvimento.
Exemplos de modelos bem-estabelecidos incluem os padrões do The IBM Banking Industry Models, ACORD e Origo, e a estrutura do TM Forum Information (SID) para Telco (consulte Resources).
Os modelos do segmento de mercado tendem a ser genéricos e extensíveis para satisfazer as necessidades de diversas organizações e são reutilizados nas diferentes funções de negócios de uma única empresa. Eles são um ajuste natural para modelar cargas úteis de interface em uma arquitetura orientada a serviços. Será, então, que ele fornecerá serviços corporativos reutilizáveis, expostos com modelos padronizados de dados?
A resposta não pode ignorar as duas restrições fundamentais da SOA a seguir:
- A reutilização cria dependências
Mesmo quando os consumidores de serviços têm um alto grau de dissociação do provedor, eles ainda dependem do fato de que o prestador deve estar lá para entender sua solicitação e processá-la dentro das restrições de um acordo de nível de serviço. O provedor também é intrinsecamente dependente dos consumidores: quanto mais os consumidores reutilizarem o serviço, mais interrupções uma mudança no provedor pode criar. Em resumo, o nível de reutilização que é realmente benéfico para uma organização depende da capacidade de gerenciar os desafios de controle que a acompanham.
Figura 2. O aumento da reutilização cria mais dependências na arquitetura
- Interfaces genéricas são difíceis de serem consumidas.
Quanto mais requisitos uma estrutura de dados é desenvolvida para satisfazer, mais a estrutura é obrigada a ser ampla e complexa. Considere o exemplo de um esquema XML usado para modelar uma "Conta" financeira. Para capturar a quantidade de informação necessária para abranger todos os cenários possíveis em que uma conta é usada, o esquema incluirá um elevado número de atributos e aproveitará outros tipos de dados normalizados ("Produto", "Parte", etc.) em uma estrutura em árvore estendida. Enquanto em um único cenário, por exemplo, em uma transferência de saldo, uma solicitação de serviço pode precisar de apenas um número muito pequeno de atributos básicos da Conta. Se a operação de serviço usar o modelo padrão genérico de objeto, o consumidor terá que lidar com uma estrutura de dados complexa e escassamente preenchida, conforme mostrado na A figura 3. Isso torna o contrato de serviço muito indefinido: o esquema que define os dados trocados em uma operação acaba sendo um contêiner genérico que não especifica a lista exata dos atributos necessários como entrada e retornados como saída.
Figura 3. Uma operação de serviço único pode exigir apenas alguns atributos de uma estrutura de dados "padrão"
Quanto mais os contratos de serviços forem genéricos e independentes do contexto, mais eles serão reutilizáveis, mas só até certo ponto. Quanto mais um contrato é genérico, mais difícil se torna entendê-lo e usá-lo; consequentemente, outras partes terão menos interesse em usá-lo novamente. A figura 4 expressa esse ponto de forma gráfica. Observação: Este diagrama serve para comunicar uma ideia; não se baseia em medidas quantitativas.
Figura 4. As interfaces que não são utilizáveisnão serão reutilizadas
Os modelos do segmento de mercado não são soluções simples de instalar, sua adoção requer uma customização efetiva e, acima de tudo, um modelo claro de controle. Uma das arquiteturas e decisões de controle fundamentais a serem feitas é o escopo de customização e reaproveitamento de tipos de dados. A definição "cliente" em uma interface de serviço será diferente em outros serviços ou será a mesma para todo o portfólio? A resposta a esse tipo de pergunta determina quem pode alterar as definições de dados e qual pode ser o ciclo de vida dessa mudança. O escopo da reutilização de tipos de dados deve ser uma decisão consciente; não há uma solução que seja adequada a todos os casos. No entanto, alguns padrões diferentes estão surgindo no campo.
Padrão 1: Um modelo de objeto por interface de serviço
O uso de um modelo de dados independente para cada interface de serviço, conforme mostrado na Figura 5,, assegura o nível mais elevado de dissociação entre os serviços. Como o proprietário do serviço está no controle completo da interface, o controle da interface é simplificado. No entanto, a falta de padronização entre as diversas interfaces gera custos adicionais ao longo do ciclo de vida do serviço. Em particular, o consumidor precisa compreender diferentes representações das mesmas entidades de negócios em diversos serviços e deve lidar com todas as transformações de dados relativos. No entanto, essa estratégia pode ser muito eficaz para as operações de serviço de alta granularidade que não trocam uma grande quantidade de dados com os consumidores.
Figura 5. No Padrão 1, toda interface de serviço expõe um modelo de objeto independente
Padrão 2: Um modelo de objeto por domínio de negócio
Com essa abordagem, os serviços são organizados em domínios; todos os domínios compartilham o mesmo modelo de objeto. Os limites de domínio são determinados por competências de negócios, por exemplo, "Planejamento de Vendas" ou "Cumprimento do Produto", e podem ser desenvolvidos usando técnicas de arquitetura de negócios, por exemplo, o Modelo de Negócios de Componente IBM, mostrado na A Figura 6.
Figura 6. O Modelo de Negócios de Componente IBM pode ser usado para definir domínios de serviço
Essa solução tenta encontrar um equilíbrio entre as diferentes forças discutidas aqui: tipos de dados são reutilizados em um conjunto de serviços que tende a ser naturalmente coeso, porque eles estão relacionados à mesma área de negócio (ou "domínio"), enquanto a estrutura de dados usada por serviço não relacionados pode evoluir de forma independente, conforme descrito pela figura 7.
Figura 7. Os diferentes domínios de serviço irão expor modelos de objetos diferentes
A desvantagem é que, assim que os domínios forem definidos, a alteração de seus limites pode ser cara. Além disso, pode haver áreas do portfólio de serviços nas quais é difícil identificar uma clara separação entre os domínios; pode ser necessário organizar os serviços de acordo com domínios técnicos (por exemplo, todos os serviços implementados pela plataforma A versus os implementados pela plataforma B). Isso não é o ideal, é um modelo de "TI centrada" que une as características do cenário de serviço para sua implementação técnica. No entanto, é útil ter um grau de pragmatismo; se o controle global do serviço for baseado estritamente na propriedade de plataformas de tecnologia, pode ser necessário usar os mesmos critérios para particionar seus domínios de serviço. Além disso, um claro antipadrão muito comum é a identificação de domínios com projetos de implementação. Isso é típico de organizações em que o escopo da reutilização de modelos de objeto não é uma decisão consciente de arquitetura corporativa, mas uma reflexão posterior deixada para projetos de entrega. Nesse contexto, os domínios surgem, evoluem, se sobrepõem e se entrelaçam de acordo com as decisões táticas. Todo modelo de objeto genérico alinhado aos negócios prometido por uma única iniciativa está fadado a se transformar em um modelo legado do qual o próximo projeto tentará ser dissociado.
Padrão 3: Um modelo de objeto único para toda a empresa
Muitas organizações olham para a SOA como uma forma de expor os ativos de TI como serviços alinhados aos negócios e baseados em padrões facilmente reutilizáveis em diferentes departamentos. Pode parecer natural, então, o uso de modelos do segmento de mercado para definir um conjunto único e comum de estruturas de dados compartilhados entre todas as interfaces de serviço corporativo (consulte a Figura 8). A quantidade de customização do modelo é reduzida a um mínimo e o seu gerenciamento é centralizado. Essa abordagem simplifica o design de modelos de dados no nível de arquitetura corporativa e promete maximizar a reutilização.
No entanto, ela torna os desafios descritos no início deste artigo particularmente relevantes. Por exemplo, a definição de contratos de serviços efetivos exigirá o aumento de restrições genéricas de tipo de dados com validação de contexto específico, conforme descrito na solicitação de patente de "Validação de Mensagem em uma Arquitetura Orientada a Serviços" (consulte Resources).
Figura 8. Todas as interfaces de serviço da empresa podem aproveitar um modelo de objeto comum
Esse padrão de controle é efetivo apenas em ambientes que tenham processos de controle muito fortes em vigor e que não tenham de lidar com uma alta taxa de mudança. Muitas organizações começam com essa estratégia, mas, em seguida, passam para a abordagem de domínio de serviço descrita no Padrão 2, quando experimentam os desafios envolvidos em seu gerenciamento.
Algumas boas práticas são válidas na maioria das vezes. Independentemente do controle que adotar, você sempre terá de gerenciar o fato de que o modelo de objeto será alterado e que a mesma informação poderá ter representações diferentes.
Esta seção lista algumas orientações principais:
-
Manter um dicionário corporativo de dados lógicos comum e mapear cada
modelo de objeto físico a ele.
O uso de um dicionário de dados comum remove a ambiguidade na definição de requisitos de negócios e permite a tradução entre representações de dados diferentes, conforme mostrado na Figura 9
Figura 9. A customização diferente de um modelo lógico comum pode ser necessária para satisfazer os diferentes requisitos
É importante reconhecer como essa padronização traz benefícios em seu próprio direito, sem a necessidade de usar o mesmo modelo de objeto físico em todos os lugares. O modelo lógico fornece um vocabulário básico que racionaliza o que a empresa entende por termos genéricos, como "política", "conta", "cliente" e "produto" em vários domínios de negócio diferentes. Isso terá benefícios muito além da TI. Da mesma forma, a iniciativa terá dificuldades em ter êxito se seus patrocinadores forem oriundos somente da comunidade de TI.
-
Dissociar o modelo de exposição de serviço do modelo de
implementação do serviço.
"Modelo de exposição" se refere ao modelo de objeto usado na definição de interfaces de serviço, enquanto o "modelo de implementação" é aquele usado na implementação do serviço (consulte a a figura 10).
Figura 10. Modelo de Exposição versus Modelo de Implementação
O primeiro modelo é público, enquanto o segundo deve ser mantido privado para que os consumidores permaneçam dissociados da implementação do serviço. Mesmo se os dois modelos parecerem idênticos a princípio, sua propriedade e seus ciclos de vida geralmente são diferentes. O modelo de implementação é de propriedade da equipe de prestação de serviços e, durante o desenvolvimento, passa por ciclos frequentes de mudança. No entanto, o proprietário do modelo de exposição de serviço geralmente controla um portfólio de serviços e aprova qualquer modificação somente após considerar o impacto em todo o portfólio e nos consumidores. As mudanças no modelo de exposição irão ocorrer, então, com menos frequência. Manter os dois modelos separados cria um "buffer" que lhes permitem evoluir em diferentes velocidades.
Pode-se argumentar que essa dissociação é uma sobrecarga desnecessária para os componentes cuja implementação não precisa compreender e manipular a maioria da carga útil exposta por sua interface. Esses componentes certamente existem, no entanto, na SOA, eles são normalmente elementos de barramento de serviço corporativo (ESB) e não devem ser referidos como "implementações de serviço" (Flurry e Clark exploram os detalhes dessa distinção em seu artigo "The Enterprise Service Bus, re-examined" (consulte Resources).
-
Criar especificações de interface que sejam completas e fáceis de
consumir.
A especificação de interface é a única coisa que você deseja que os consumidores saibam sobre o seu serviço.
Está fora do escopo deste artigo entrar em detalhes sobre o debate de interfaces fortemente tipificadas versus interfaces fracamente tipificadas. No entanto, convém apontar para o equívoco bastante comum de que uma mudança nos dados trocados por um serviço não afeta o consumidor, desde que a assinatura da interface não seja modificada. Por exemplo, vamos considerar uma técnica que é bastante utilizada em modelos do segmento de mercado: incluir listas de pares de valor da chave a uma carga útil de interface com o objetivo de minimizar o impacto de uma customização. Existem algumas circunstâncias em que isso é apropriado, mas, muitas vezes, é uma falsa economia, pois "esconde" detalhes que podem ser vitais para os consumidores de serviços. Quais são as informações contidas na lista? Algo foi incluído ou removido? O que são chaves? Como elas são escritas?
Quanto mais difícil for para o consumidor obter esses detalhes, mais caro será o acesso ao serviço. Por razões semelhantes, o uso de dados e construções de protocolo avançados, não usados habitualmente, deve ser evitado. Quanto mais fácil for a sua fala, maior a probabilidade de ser compreendido.
Este artigo destacou como os modelos do segmento de mercado podem ajudar os arquitetos na difícil tarefa de definir interfaces de serviço corporativo e refletiu sobre a necessidade de atingir um equilíbrio entre os princípios de design concorrentes, em particular, a "reutilização" e o "loose coupling". Aprendemos como o tipo de modelo de controle de SOA adotado por uma organização é, por si só, um importante elemento a ser considerado para um design de serviço efetivo.
Agradecimento especial a Kim Clark e Scott Glen por suas contribuições e comentários sobre este artigo.
Aprender
- The Open Group Architecture Framework (TOGAF): Saiba mais sobre
esta abordagem holística de alto nível para arquiteturas.
- Service-oriented modeling and architecture (developerWorks 2004):
Destaques da revisão da modelagem e arquitetura orientadas a serviço e das principais atividades
necessárias para sua análise e design.
- O IBM Information Framework para o segmento de mercado financeiro: Explore
este projeto para obter sucesso em solução de SOA e data warehousing.
- Building Service Oriented Banking Solution with IBM Banking Industry
Models: Leia este IBM Redpaper que fornece informações importantes de posicionamento
e orientação detalhada sobre conjunto de ferramentas.
- ACORD Standards Organization: Visite a página inicial.
- Anatomia do padrão ACORD TXLife XML (developerWorks, 2011):
Saiba mais sobre a estrutura de mensagens do ACORD TXLife, os desafios
enfrentados pelos implementadores, as ferramentas e técnicas para usá-lo
com sucesso.
- Padrões Origo: Saiba mais sobre esses padrões que são
desenvolvidos para atender aos requisitos de processos de negócios específicos,
apoiar uma série de produtos de investimentos, retirada e
proteção.
- TM
Forum Information Framework (SID): Leia mais sobre esta
definição acordada pelo segmento de mercado para as informações que
fluem pela empresa e entre prestadores de serviços e seus parceiros
de negócios.
- Modelo
de Negócios de Componente IBM: Encontre mais informações sobre esta
abordagem baseada em componentes para a mudança estratégica.
- O Enterprise Service Bus reexaminado (developerWorks 2011):
Examine o papel da arquitetura do barramento de serviço corporativo em uma
arquitetura orientada a serviços.
- Message Validation in a Service Oriented Architecture: Leia esta
solicitação de patente para compreender melhor a razão pela qual
a definição de contratos de serviços eficazes exigirá o aumento de restrições de tipo
de dados genéricos com validação de contexto específico.
- Segmentos de mercado no IBM developerWorks: Obtenha todos os recursos técnicos específicos do segmento de negócio mais recentes para desenvolvedores.
- DeveloperWorks no Twitter: entre hoje para seguir os tweets do developerWorks.
- Podcasts do developerWorks: Ouça entrevistas e discussões interessantes para desenvolvedores de software.
-
Demos on demand do developerWorks: Acompanhe demos que abrangem desde a instalação de produto e configuração para iniciantes até funcionalidade avançada para desenvolvedores experientes.
Obter produtos e tecnologias
-
Versões de avaliação de produto IBM: Faça o download ou explore as versões de teste online no IBM SOA Sandbox e entre em contato com as ferramentas de desenvolvimento de aplicativos e produtos de middleware do DB2®, Lotus®, Rational®, Tivoli®e WebSphere®.
Discutir
-
perfil do developerWorks: crie seu perfil hoje e configure uma lista de observação.
- A comunidade do developerWorks: Conecte-se a outros usuários do developerWorks enquanto explora os blogs, fóruns, grupos e wikis voltados para desenvolvedores.
Carlo Marcoli é Senior Architect no grupo IBM Business Performance Optimization. Ele é especialista em Solução e Arquitetura Empresarial para o setor de Serviços Financeiros. Tem muitos anos de experiência em estratégia, arquitetura e entrega de BPM e SOA; aperfeiçoou-se trabalhando com clientes na Europa e América do Norte.
