A maioria das organizações se deparam com um problema de manipular vários tipos de arquivos, de várias fontes (internas e externas à empresa). Lidar com todos estes dados, com vários formatos, de diferentes origens exige um grande esforço da equipe de TI:
Alguns estudos indicam que a implementação do acesso e manuseio de tipos de dados complexos, consomem até 70% do esforço de implementação de aplicações ou serviços
É muito tempo para qualquer projeto/implementação. Data Integration, Data Abstraction e Data Services são pontos básicos em um contexto de uma arquitetura SOA. Não apenas porque a preservação do legado é importante e um motivador importante para esta arquitetura mas, principalmente, porque é uma solução de arquitetura necessária quando temos uma realidade como a atual em que nossos sistemas precisam interoperar com mais e mais sistemas externos e internos.
E se esta solução for Open Source? Melhor ainda. Veja a seguir um pequeno resumo que eu fiz a partir da solução da XAware v.5.
1. Motivadores
- Algumas industrias (e.g. Telecom, Finanças) lidam com várias fontes de dados, de várias origens e precisam manipular, transformar e garantir que seus processos de negócios sejam corretamente “alimentados”
- Interoperação de forma “transparente” para o negócio, sistemas internos e sistemas de terceiros (parceiro, governo etc)
- Arquitetura aderente a SOA
2. Definição de Data Service Layer (DSL)/Data Service
De forma bem simples, Data Service Layer (DSL) ou simplesmente Data Service é uma camada que abstrai, para o Business Process, a fonte do dado e vice-versa. É uma solução de Arquitetura, um middleware, que isola as fontes de dados dos consumidores (Web Services, Business Process etc).
Acima vemos a integração de dados (Data Integration) sem e com DSL. Fonte: este excelente artigo de Mark Davydov no IBM DeveloperWorks website.
3. SOA sem DSL?
Claro, mas com vários riscos. Exemplo: “acoplar” os seus serviços diretamente nos bancos de dados do legado. Possíveis problemas:
- Altamente dependente do schema do banco; quem tem controle das mudanças? quem irá avisar os arquitetos das mudanças? como avaliar o impacto?
- Dependência da forma de conexão para recuperar os dados
- Bases de dados relacionais de típicos Sistemas de Informação não garantem que os dados estarão em um “estado lógico” que é esperado pelo seu Business Process. Não por “culpa” do banco ou do sistema mas, simplesmente, porque não é função destes participantes garantir a integridade lógica de uma informação para o processo de negócios
4. Vantagens
Aqui eu cito o documento que deu origem a este post. Um artigo da ZapThink.com, escrito por Jason Bloomberg (necessário cadastro, gratuito, para baixar o PDF completo). Vale a pena a leitura.
- The ability to remap existing physical schemas into virtual schemas that are better logical representations of the data for SOA. Thus, the developers who build Services simply refer to a logical data layer that will be bound to back-end physical data.
- The ability to combine many schemas into a common virtual schema, which allows avirtualization greatly simplifies the use of the data in the context of SOA since the SOA implementation leverages a single common schema multitude of very different databases and schemas to appear as one. This
- The ability to place schema volatility into a single configurable domain. As physical and logical semantics, and thus schemas change, the architect can adjust for those changes with a single configuration layer, providing better agility since changes to schemas don’t inherently mean redevelopment of the Services
5. XAware 5.x
É a solução open source citada no artigo acima que se propõe a realizar esta integração tão necessária em um ambiente SOA.
