fbpx
Integrações, XML`s e NoSQL
Publicado em: quarta-feira, 16 de abr de 2014
Categorias: Arquitetura

Olá, tudo bom?

Nesse post gostaria de abordar uma solução que usei no iMusica e que pode também te ajudar com integrações baseadas em XML ou qualquer formato unquerable(neologismo). Antes de falar da solução, vou falar do problema. Nossas integrações no iMusica geralmente se dão por meio de troca de arquivos, contendo pacotes com mídia e metadados. Os metadados são armazenados em arquivos XML complexos. Independente do schema do XML usado, uns mais completos, outros mais enxutos, a quantidade de informação é colossal. O metadado do mercado fonográfico é muito extenso.

A dificuldade de manipulação desse conteúdo era gigantesco, pelos seguintes motivos:

  • Segmentação do storage
  • Necessidade de queries em arquivos
  • Acesso a grandes volumes de informação para obter dados pontuais

Toda essa complexidade fazia parte do dia-a-dia do meu time. Não que hoje ainda não faça, mas estamos trabalhando para minimizar isso. O metadado tem um destino, sempre, a manutenção de tabelas em um SGDB. Começamos a reestruturação dos serviços redesenhando os modelos de integração em uma base intermediária no SGDB, mas ao chegarmos próximos a 100 tabelas (e não havíamos mapeado sequer a metade do schema xsd) optei por abortar a ideia. Outro maluco já havia tentado fazer isso antes, e no final das contas, essa foi a terceira iniciativa, que assim como as outras, morreu! Pensei em bases XML, mas armazenar XML é extremamente insano, principalmente se comparado a formatos mais enxutos, como json. Busquei algumas bases XML, achei o Sedna e o eXist-db mas usar XQuery não foi algo motivador. Já que estava estudando sobre NoSQL tive a ideia de pesquisar sobre outras alternativas NoSQL e o resultado foi excelente.

Talvez você esteja perguntando sobre as vantagens de usar o MongoDB:

  • Queries complexas
  • Armazenamento (quase que infinito)
  • Schemaless (poupa muito trabalho)

Agora um desafio, salvar o XML, que diga-se de passagem, já vi chegar a 3mb no MongoDB.

A solução: Schemas e Geração de Código

  1. Usamos Xsd2Code para gerar as classes, em C# para mapeamento de todos as entidades e propriedades definidas no XSD. Gerou mais de 200 classes.
  2. Fazemos a leitura do XML com base em deserialização, e persistimos os mesmos objetos (classes geradas com Xsd2Code) no MongoDB.

Você poderia usar CouchBase, CouchDB, entre outras soluções, eu usei MongoDB.

Enfim, essa foi uma solução simples, e eficiente para o meu problema de integrações. Após a persistência no MongoDB, toda a minha infra que depende dos documentos, usa o MongoDB e nunca mais o XML original. Para integrações em formatos diferentes, fazemos parsers em XSLT para transformar do formato original para o formato utilizado na plataforma e assim a base de código para tratar esses documentos continua sendo a mesma.

Esses pensamentos ajudam muito a evitar segmentação em aplicações corporativas. O custo de manutenção é bem menor do que construir bases de código diferentes para realizar as mesmas coisas.

Esta não é a única solução nem cogito ser a melhor, mas foi a que me atendeu graciosamente! Espero que compartilhando contigo possa pelo menos abrir suas cabeça para ideias do tipo.

Um grande abraço e até mais!

O Cloud Native .NET é meu principal projeto.

Onde empenho energia para ajudar, acompanhar, direcionar Desenvolvedores, Líderes Técnicos e jovens Arquitetos na jornada Cloud Native.

Conduzo entregando a maior e mais completa stack de tecnologias do mercado.

Ao trabalhar com desenvolvedores experientes, eu consigo usar seu aprendizado com .NET, banco de dados, e arquitetura para encurtar a jornada.

Ao restringir à desenvolvedores .NET eu consigo usar do contexto de tecnologias e problemas do seu dia-a-dia, coisas que você conhece hoje, como WCF, WebForms, IIS e MVC, por exemplo, para mostrar a comparação entre o que você conhece e o que está sendo apresentado.

É assim que construímos fundamentos sólidos, digerindo a complexidade com didática, tornando o complexo, simples.

É assim que conseguimos tornar uma jornada densa, em um pacote de ~4 meses.

Eu não acredito que um desenvolvedor possa entender uma tecnologia sem compreender seus fundamentos. Ele no máximo consegue ser produtivo, mas isso não faz desse desenvolvedor um bom tomador de decisões técnicas.

É preciso entender os fundamentos para conseguir tomar boas decisões.

0 comentários

Enviar um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Luiz Carlos Faria

Mensagem do Autor

Espero que goste desse post. Não deixe de comentar e falar o que achou.

Se acha que esse post pode ajudar alguém que você conheça, compartilhe!

 

Lives

Fique de olho nas lives

Fique de olho nas lives no meu canal do Youtube, no Canal .NET e nos Grupos do Facebook e Instagram.

Aceleradores

Existem diversas formas de viabilizar o suporte ao teu projeto. Seja com os treinamentos, consultoria, mentorias em grupo.