Um Modelo Flexvel para a Integrao de Dados

por Tim Ewald e Kimberly Wolk

Publicado em: 26 de outubro de 2006 Resumo: Na integrao de sistemas, h vrios desafios para arquitetos e desenvolvedores, e o setor vem se concentrando em XML, servios da Web e SOA para resolver o problema da integrao e em protocolos de comunicao particularmente no que diz respeito ao acrscimo de recursos avanados que oferecem suporte ao fluxo de mensagens em topologias de rede complexas. Entretanto, essa concentrao em protocolos de comunicao desviou o foco do problema da integrao de dados. Modelos flexveis para combinar dados em sistema diferentes so essenciais para uma integrao bem sucedida. Esses modelos so expressos em esquemas XML (XSD) nos sistemas baseados em servios da Web, e instncias do modelo so representadas como XML transmitido em mensagens no protocolo SOAP. No nosso trabalho sobre a arquitetura do MTPS (MSDN TechNet Publishing System), abordamos trs armadilhas. Iremos ver o que so essas armadilhas e nossas solues para elas, no contexto de um problema mais geral: a integrao das informaes do cliente. A integrao de sistemas apresenta uma ampla gama de desafios aos arquitetos e desenvolvedores. Nos ltimos anos, o setor enfocou o uso de XML, servios da Web e SOA (Arquitetura Orientada a Servios) para resolver problemas de integrao. Boa parte do trabalho feito nesse espao se concentrou nos protocolos de comunicao, particularment e no acrscimo de recursos avanados projetados para dar suporte s mensagens que fluem em topologias complexas de rede. Embora essa abordagem tenha, sem dvida, algum valor, todo esse trabalho com os protocolos de comunicao desviou o foco do problema da integrao dos dados. Dispor de modelos flexveis para combinar dados em sistemas diferentes essencial para um trabalho de integrao bem-sucedido. Em sistemas baseados em servios da Web, esses modelos so expressos em XSD. Instncias do modelo so representadas como XML que transmitido um sistema para outro em mensagens SOAP. Alguns sistemas mapeiam os dados XML em bancos de dados relacionais; alguns no fazem isso. Do ponto de vista da integrao, a estrutura desses modelos relacional de bancos de dados no importante. O importante o formato do modelo de dados XML definido no XSD. Existem tr s armadilhas nas quais os projetos de integrao de dados baseados em servios da Web costumam cair . Todas as trs esto relacionadas ao modo de definio dos esquemas XML. Enfrentamos as trs armadilhas em nosso trabalho na arquit etura do MSDN TechNet Publishing System, o sistema baseado em XML da prxima gerao, que a base do MSDN2. Analisaremos nossas solues no contexto da integrao de informaes do cliente.

Nesta pgina
O Problema Essencial da Integrao de Dados Excesso na Exigncia de Informaes Falta de uma Estratgia Eficiente de Verses Falta de Suporte para uma Extenso no Nvel do Sistema Diminuio dos Riscos Sobre os Autores

Recursos

O Problema Essencial da Integrao de Dados

Imagine que voc trabalha em uma empresa grande. Sua empresa tem vrios sistemas voltados para fora que so usados pelos clientes para realizar diversas tarefas. Por exemplo: um sistema oferece informaes personalizadas sobre os produtos para usurios registrados que declararam interesses especficos. Outros sist emas oferecem ferramentas de gerenciament o de associao para client es participantes do programa de parceiros. Um terceiro sistema rastreia clientes que se registraram para comparecer em futuros eventos. Infelizmente, todos os sistemas foram desenvolvidos separadamente. Um deles foi desenvolvido por uma empresa separada que a sua companhia adquiriu h um ano. Cada um desses sistemas armazena informaes sobre clientes em formatos e locais diferentes. Essa configurao um problema crtico para os negcios: no se tem uma viso unificada de um determinado cliente. Esse problema tem dois efeitos: primeiro, a experincia dos clientes prejudicada, por que a nica empresa com que eles fazem negcios os trata como pessoas diferentes quando usam sistemas diferent es. Por exemplo: um cliente que declarou o desejo de receber informaes por email sobre um determinado produt o sempre que ele fica disponvel tem que declarar interesse nesse produto pela segunda vez quando se registra para determinados debates em um futuro evento patrocinado pela empresa. A experincia dela seria mais convenient e se o sistema que a registrou para um evento futuro j tivesse conhecimento do seu interesse em um determinado produto. Em segundo lugar, a empr esa prejudicada por que no tem uma compreenso int egrada em relao aos clientes. Quantos client es que so membros de um programa de par ceiros tambm esto recebendo informaes por email sobre os produtos? Nos dois casos, a separao entre os sistemas com que o cliente trabalha esto limitando o nvel de qualidade da resposta da empr esa s necessidades dos clientes. No importa se essa situao ocorreu porque os sistemas foram projetados e desenvolvidos individualmente, sem considerar o contexto mais amplo onde operam ou porque grupos diferentes de sistemas integrados foram coletados por meio de fuses e aquisies. O problema continua: a empresa tem que integrar os sistemas para melhorar a experincia dos clientes e tambm o conheciment o a respeito de quem o cliente e qual a melhor forma de atend-lo. A abordagem mais comum para resolver esse problema exigir que todos os sistemas adotem um nico modelo cannico para um cliente. Um grupo de arquitetos se rene e projeta o format o nico da empresa para representar os dados do cliente em XML. O formato definido usando um esquema escrito em XSD. Para permitir que os sistemas compartilhem dados no novo formato, uma equipe central cria um novo armazenamento que d suporte a eles. A equipe do modelo de dados XSD e a equipe de armazenamento entregam a sua soluo para todas as equipes responsv eis por sistemas que, de alguma forma, interagem com os clientes e exige que elas o adotem. A mudana essencial ilustrada nas Figuras 1 e 2.

Figura 1. Trs armazenament os de dados separados, um por sistema.

Figura 2. Um nico formato e armazenamento de dados Cada sistema modificado para usar o armazenamento de dados da base por meio de sua interface de servios da Web. Os sistemas armazenam e recuperam informaes do cliente como um XML que se enquadra no esquema do cliente. Todos os sistemas compartilham a mesma instncia de servio, o mesmo modelo de dados XSD e as mesmas informaes XML. Essa soluo parece simples, elegante e boa, mas uma implementao ingnua normalmente falha por uma destas trs razes: excesso na exigncia de informaes, falta de uma estratgia eficiente de verses e falta de suporte para uma extenso no nvel do sistema.

Excesso na Exigncia de Informaes

A primeira possvel causa de falha o uso de um esquema e armazena mento que exigem informaes demais. Quando se cria um servio da Web simples para a integrao ponto a ponto, tende-se a pensar nos dados de que o servio em particular precisa. Define-se um contrato que exige o fornecimento de dados especficos. Quando um contrato gerado a partir do cdigo fonte, esses dados podem ocorrer de forma implcita. A maioria das ferramentas que mapeia a partir do cdigo fonte para um contrato de servio da Web trata os campos do tipo "valor simples" como elementos de dados obrigatrios, insistindo que o cliente os envie. Mesmo quando o contrato criado mo, ainda existe a tendncia de tratar todos os dados como obrigatrios. Assim que o servio determina (por meio de validao do esquema ou do cdigo) que alguns dados obrigatrios no esto presentes, ele rejeita a solicitao. O cliente obtm uma falha de servio. Essa abordagem para definio de contratos de servios Web rgida demais e leva a sistemas que so fortemente acoplados. Qualquer alterao nos requisitos do servio fora uma alterao no contrato e nos clientes que o consomem. Para tornar esse acoplamento mais livre, necessrio fazer uma distino entre a definio do formato dos dados que um servio espera e os requisitos atuais de processamento de um sistema. Mais concretamente, os formatos de dados definidos pelo contrato devem tratar tudo o que no seja dados de identidade como opcional. A implementao do seu servio deve impor requisitos de ocorrncia internamente em tempo de execuo (usando um esquema de validao dedicado no cdigo). Deve ser o mais "condescendente" possvel quando os dados no estiverem presentes em uma solicitao do cliente e "degradar com classe" (ou seja, no deixar de exibir as informaes quando h elementos faltando).

No exemplo das informaes do cliente, fcil pensar em casos nos quais alguns sistemas querem trabalhar com os clientes mas no tm informaes completas do cliente disposio. Por exemplo: o sistema que registra o int eresse de um cliente em um determinado produto pode coletar apenas o nome e o endereo de email preferencial do cliente. O sistema de registro de eventos, por sua vez, pode captar tambm as informaes de endereo e carto de crdito. Se um modelo comum de dados de cliente exigir que cada registro vlido do cliente inclua nome, endereo de email e informaes de carto de crdito, nenhum sistema poder adot-lo sem coletar mais dados que o necessrio ou fornecer dados falsos. Ao fazer com que todos os dados que no sejam a identidade (nmero da cdula de identidade, endereo de email etc.) sejam opcionais, a adoo de um modelo de dados se torna mais fcil, porque os sistemas podem simplesmente fornecer as informaes que tm. Ao fazer a separao entre o formato de dados e os requisitos de ocorrncia, voc facilita o gerenciament o da mudana na implementao de um servio nico. Isso tambm critico quando voc define um esquema XML comum para ser usado por vrios servios e clientes. Se houver um excesso de informaes obrigatrias, cada sistema que quiser usar o modelo de dados pode estar sem algumas informaes obrigatrias. Isso d a cada sistema a opo de no adotar o modelo compartilhado e armazenar ou fornecer dados falsos (freqentemente, o valor padro de um tipo simples de linguagem de programao). Qualquer uma dessas opes pode ser considerada uma falha. Voc ganha bastante flexibilidade quando os sistemas adotam este modelo que flexibiliza quase que completamente os requisitos de ocorrncia do esquema. Cada sistema pode contribuir com todos os dados que tiver sua disposio, o que facilita muito a adoo de um esquema XML comum. O preo a pagar que os sistemas dos quais recebemos dados devem ter o cuidado de se certificar de que estejam presentes os dados realment e necessrios. Se no estiverem presentes, eles devem reagir adequadamente, obtendo mais dados do usurio ou outro armazenamento, simplificando o comportamento ou - somente na pior hiptese - gerar uma falha. O que voc est fazendo, na verdade, desviar de algumas das restries que voc normalmente colocaria em um esquema XML do seu cdigo, onde seriam verificadas no tempo de execuo. Esse desvio permit e alterar essas restries sem revisar o esquema compartilhado.

Falta de uma Estratgia Eficiente de Verses

A segunda possvel causa de falha a falta de uma estratgia de verses. Independentemente do tempo e do esforo despendidos na definio antecipada de um esquema XML, o esquema ter que ser alterado com o passar do tempo. Se os esquemas, o armazenamento compartilhado que d suporte a eles e todos os sistemas que os usam, tiverem que mudar entre verses, o sucesso improvvel. Alguns sistemas tero que aguardar as alteraes necessrias, porque os outros sistemas no esto em condies de adotar uma reviso. Conseqentemente, alguns sistemas sero forados a fazer um trabalho extra e inesperado, j que os outros sistemas precisaro adotar um a nova verso. Essa abordagem injustificvel. Para resolver esse problema, necessrio adotar uma estratgia de verso que permita que o esquema e o armazenament o continuem funcionando, independentemente da velocidade com que os outros sistemas adotam suas revises. Essa soluo parece simples, e desde que voc tenha uma concepo correta em relao aos esquemas XML. Os sistemas que se integram usando um esquema XML comum o consideram como um contrato. O fato de diminuir a quantidade de dados obrigatrios, tornando os elementos opcionais, facilita a aceitao do contrato porque os sistemas esto se comprometendo a realizar menos. No caso da verso, tambm necessrio permitir que os sistemas faam mais, mas sem mudar o namespace do esquema. Na prtica, isso significa que um sistema sempre deve produzir dados XML com base na verso do esquema com o qual ele foi desenvolvido. Devem sempre consumir dados baseados na mesma verso com informaes adicionais. Essa definio uma variao da

lei de Postel: "Seja liberal naquilo que aceita, e conservador naquilo que envia". Pode-se dizer que essa idia est por trs de todas as tecnologias bem-sucedidas de sistemas distribudos e certamente, de todas as tecnologias de acoplamento livre. Se adotar essa abordagem, voc poder ampliar um esquema sem atualizar os clientes. No exemplo do cliente, uma atualizao do esquema e do armazenamento pode adicionar suporte a um elemento adicional opcional que capta o nome de solteira da me do usurio, para fins de segurana. Se os sistemas que funcionam com a verso antiga gerarem registros de clientes sem essa informao, no haver problema, j que o elemento opcional . Se eles enviarem esses registros a outros sistemas que exigem essas informaes, a solicitao poder falhar, mas no h problema nisso tambm. Se os novos sistemas enviarem dados do cliente aos sistemas antigos incluindo o nome de solteira da me, tambm no haver problema, porque eles esto projetados para ignorar isso. Felizmente, muitos kits de ferramentas para servios da Web fornecem suporte a esse recurso diretament e nos encaixes do marshalling dirigidos a esquemas. Certamente, os mapeadores de objetos XML do .NET (tanto o antigo XmlSerializer quanto o novo XmlFormatter/DataContract) processam dados extras sem problemas. Alguns kits de ferramentas para Java tambm fazem isso, assim como os frameworks que fornecem suporte s novas especificaes de JAX-WS 2.0 e JAXB 2.0. Tendo isso em mente, muito fcil adotar essa abordagem. O nico verdadeiro problema desse modelo que ele introduz definies mltiplas de um determinado esquema, cada uma representando uma verso diferente. Considerando-se um dado - por exemplo: um fragmento de XML captado de uma mensagem enviada pelo meio fsico - impossvel responder a pergunta: "Esse dado vlido?" S possvel responder a pergunta da validade em relao a uma verso especfica do esquema. A incapacidade de determinar com certeza se um determinado dado vlido um problema para a depurao e, talvez, tambm para a segurana. No caso dos modelos de dados descritos com um esquema XML, possvel responder uma pergunta diferente e mais interessante: "Esse dado suficientement e vlido?" Essa pergunta o que realmente importa para os sistemas, e voc pode respond-la usando as informaes de validade que a maioria dos validadores fornece, que um caminho razovel a seguir quando a validao do esquema obrigatria, e isso pode ser implementado com os atuais frameworks de validao do esquema.

Falta de Suporte para uma Extenso no Nvel do Sistema

A terceira possvel causa de falha a falta de suporte para extenses do esquema especficas para o sistema. A estratgia de verso baseada na idia de que a definio de um esquema muda com o tempo necessria para promover a adoo, mas no suficient e. Embora libere os sistemas da necessidade de adotar imediatament e a verso mais recente do esquema, no faz nada para ajudar os sistemas que esto aguardando atualizaes especficas do esquema. Os atrasos nas revises tambm podem deixar um esquema caro demais para o sistema. A soluo desse problema permitir que os sistemas que adotam o mesmo esquema o estendam com suas prprias informaes adicionais. As informaes de extenso podem ser armazenadas localment e em um armazenamento no nvel do sistema (consulte a Figura 3).

Figura 3. Uma combinao de armazenamentos (consulte as Figuras 1 e 2) Nesse caso, cada sistema modificado para gravar os dados no cliente no repositrio dedicado, usando o seu prprio modelo de dados, e no repositrio compartilhado, usando o esquema cannico. O sistema tambm modificado para ler dados do cliente a partir do armazenamento dedicado e tambm do compartilhado. Dependendo do que ele encontra, ele sabe se a empresa e o sistema j conhecem o cliente. A Tabela 1 resume as trs possibilidades. Registro no amazenamento compartilhado Registro no armazenamento do sistema No O cliente novo para a empresa. Coleta todos os dados comuns e especficos para o sistema. O cliente j conhecido pela empresa, mas novo Sim No para o sistema. Coleta dados especficos para o sistema. Sim Sim O cliente j conhecido pela empresa e pelo sistema. Significado

No

Tabela 1. Os trs casos possveis de dados de clientes O sistema pode usar essas informaes para decidir quantas informaes do cliente ele precisa armazenar. Se o cliente novo para a empresa, o sistema adiciona ao sistema cannico a maior quantidade possvel de informaes. Essas informaes ficam disponveis para outros sistemas que trabalham com clientes. O sistema tambm pode armazenar dados no armazenamento dedicado, para suprir as suas prprias necessidades. Esse modelo pode ser expandido ainda mais, para que os dados especficos do sistema sejam armazenados tambm no armazenamento compartilhado (consulte a Figura 4).

Figura 4. O mesmo armazenamento (consulte a Figura 3) com formatosde dados em um repositrio compartilhado. Essa soluo permite que os sistemas se integrem usando dados de extenso que esto alm do escopo do esquema cannico. Para funcionar corretament e, necessrio que o repositrios e os outros sistemas tenham visibilidade em relao aos dados de extenso. Em outras palavras, ele no pode ser opaco. A forma mais fcil de resolver esse problema fazer com que os prprios dados de extenso sejam XML. O sistema que fornece os dados define um esquema para os dados de extenso, para que os outros sistemas possam process-los de forma confivel. O armazenamento compartilhado faz um acompanhamento dos esquemas, para poder garantir que os dados de extenso sejam vlidos, mesmo que no precise saber explicitamente o que a extenso contm. No caso mais extremo, um determinado sistema pode optar por armazenar um registro inteiro do cliente em um formato especfico do sistema, como dados de extenso XML. Outros sistemas que entendem esse formato podem us-los. Os sistemas que no o entendem dependem da representao cannica. Quando os sistemas so independentes, cada um deles controla o seu prprio destino. Eles podem captar e armazenar quaisquer informaes necessrias, no formato e local que preferirem. A passagem para um nico esquema e repositrio em comum muda isso. Se a adoo de dados XML em comum restringir a liberdade do sistema visando proporcionar a funcionalidade necessria, voc estar condenado ao fracasso. O uso de uma combinao de dados de extenso tipo XML em um armazenamento compartilhado ou armazenamento no nv el do sistema aumenta a complexidade, porque voc tem que manter a sincronia dos dados. Porm, tambm proporciona uma grande flexibilidade. possvel alinhar sistemas em t orno de qualquer combinao de esquemas cannicos e esquemas alternativos que voc quiser. Voc pode ir mudando para o format o XML com o passar do tempo, mas ter sempre a flexibilidade de desviar desse formato para cumprir novos requisitos. Essa liberdade extra vale muito no incerto mundo de negcios. Outro benefcio sutil desse modelo o fato de permitir que a equipe que define o esquema em comum diminua a velocidade ao trabalhar nas revises. Os sistemas podem usar os dados de extenso para atender novos requisitos entre as revises. A equipe que trabalha no modelo cannico pode buscar essas informaes para contribuir no processo de reviso. Esse crculo de feedback ajuda a garantir que as mudanas de modelo sejam motivadas por requisitos reais do sistema.

Diminuio dos Riscos

Diversas organizaes esto trabalhando na integrao de sistemas usando os dados XML que so descritos por meio de esquemas XM L e trocados por meio de servios da Web. Nessa explanao, apresentamo trs causas comuns de falha nesses projetos de integrao centrados no dados: excesso na exigncia de informaes, falta de uma estratgia eficiente de verses e falta de suporte para extenses no nvel do sistema. Para diminuir esses riscos: Faa com que os elementos do esquema sejam opcionais e codifique os requisitos de ocorrncia especficos do sistema como parte da implementao do sistema. Crie sistemas que produzam dados de acordo com a sua verso do esquema compartilhado, mas consumam de forma que os sistemas possam adotar revises de esquema a velocidades diferentes, sem alterar o namespace do esquema. Permita que os sistemas estendam esquemas compartilhados com seus prprios dados para cumprir novos requisitos, sem depender das revises de modelo de dados. Todas essas solues se baseiam em uma idia central: integrar de forma bem-sucedida, sem sacrificar a agilidade de que os sistemas precisam, para acoplar o menos possvel e, ainda assim, cumprir a sua funo. Tudo isso funciona? A resposta sim. Essas t cnicas so fundamentais para o projeto do MSDN/TechNet Publishing System, que a base do MSDN2.

Sobre os Autores
Tim Ewald uma das principais arquitetas da Foliage Software Systems, que ajuda os clientes a projetar e criar aplicativos que vo desde TI empresarial at dispositivos mdicos. Antes de entrar para a Foliage, Tim trabalhou na Mindreef, um dos maiores fornecedores de ferramentas de diagnstico para servios da Web; antes disso, Tim foi lder dos gerentes de programa no MSDN, onde trabalhou com Kim W olk como co-arquiteta do MTPS, o mecanismo de publicao baseado em XML e servios da Web que a base do MSDN2. Tim palestrante e escritora de renome internacional. Kim Wolk gerente de desenvolvimento do MSDN e a fora que move o MTPS, o mecanismo de publicao baseado em XML e servios da Web que a base do MSDN2. Antes disso, ela atuou como co-arquiteta e principal desenvolvedora do MTPS. Antes de entrar para a MSDN, Kim atuou por muitos anos como consultora, tanto independent e quanto ligada Microsoft Consulting Services, onde trabalhou em uma ampla gama de sistemas empr esariais de misso crtica.