Sendo assim, me deparei com alguns conceitos que não consegui absorver de imediato, como Data Services e Service Data Objects.
Na realidade, entendi que os mesmos são para interoperabilidade de dados, mas na realidade, não entendi em que momento os mesmos serão utilizados.
Se alguém puder me explicar a utilização, vantagens e desvantagem ficarei muito grato.
Bom vamos lá, Data Services na verdade é um produto BEA criado sob o conceito de SDO - Service Data Objects. Entendido isso vamos ao cerne do seu problema.
Imagine que está criando um serviço de inclusão de pedidos na sua corporação e necessite inserir o pedido no seu software de CRM e ao mesmo tempo, disparar uma ordem de serviço que irá alimentar um terceiro sistema que lê uma determinada tabela num outro banco de dados.
Sua implementação terá que fazer uma chamada ao seu CRM e nesse cenário a aplicação CRM é antiquíssima e você só consegue fazer uma integração de baixo acoplamento, ou seja, acessando diretamente a base da mesma.
Está começando a entender ?
Você começa a ter que lidar Point-to-point amarrando sua implementação às estruturas de dados da companhia, seja ela DBMS, XML entre outras.
O conceito SDO serve como uma camada de abstração do seu modelo de persistência de informações, promovendo a “virtualização” dos dados da companhia. Logo essa camada conhece de fato quais são as fontes e os seus serviços irão fazer uso da mesma.
A implementação do seu serviço não precisará se preocupar onde se encontram as informações, basta você requisitar por exemplo - Quais pedidos do cliente x ? - SDO te traz uma estrutura baseada no modelo canônico - Canonical Data Model, contendo a informação que você solicitou e preparada para utilizar no seu serviço ou fluxo de processo, como um BPEL-BPM.
Os benefícios são muitos, mas o principal o desacoplamento da implementação do legado da companhia.
Na realidade produtos de outras empresas como IBM/JBoss tb implementam o conceito de SDO. A própria especificação de SDO foi escrita por um consórcio de empresas.
Esse modelo propõe integração por dados e não por processos/serviços (como SOA defende). Eu considero SDO/Data Services como uma segunda opção e só recomendável quando organizações não estão dispostas a abrir mão do legado no banco de dados.
[quote=Taz]Na realidade produtos de outras empresas como IBM/JBoss tb implementam o conceito de SDO. A própria especificação de SDO foi escrita por um consórcio de empresas.
Esse modelo propõe integração por dados e não por processos/serviços (como SOA defende). Eu considero SDO/Data Services como uma segunda opção e só recomendável quando organizações não estão dispostas a abrir mão do legado no banco de dados.
[/quote]
Não, esse modelo de SDO seria a disponibilização dos dados através de serviços. Entretanto é necessário muito critério, para não fazer uma macarronada de serviços ingerenciáveis.
Numa arquitetura SOA bem feita, eles não vão ser usados como opção de implementação e sim de forma “complementar”. Mesmo a companhia abrindo mão do seu legado, são milhares de aplicações num cenário enterprise, com diversas fontes de informação.
O que o SDO propõe é a “Virtualização” das fontes de informação, e então você constrói os seus serviços em cima dessa camada, sem se preocupar com a fisicalização de integração. À partir desse ponto, estará fazendo uso de um modelo canônico que permeia por todos os serviços da empresa e a camada de abstração à persistência que irá tratar de guardar ou requisitar as informações.
PS: Deixem isso na mente: “Complementar” não é escolha de um modelo vs outro.
Estou começando a entender a utilização da abstracção de dados, entretanto paira a dúvida:
Deve-se criar uma camada apenas para fornecer os SDOs para atender o SOA ?
Ou há alguma outro padrão mais indicado para essa conversão de dados ?
Obrigado.
[quote=mateusbrum]Estou começando a entender a utilização da abstracção de dados, entretanto paira a dúvida:
Deve-se criar uma camada apenas para fornecer os SDOs para atender o SOA ?
Ou há alguma outro padrão mais indicado para essa conversão de dados ?
Obrigado.[/quote]
Na verdade não é uma “conversão” de dados e sim um mapeador de fontes de informação. Quanto ao padrão na verdade os produtos se baseiam em SDO, mas cada um faz por si implementação de características que julgam ser essenciais ou trazem benefícios diretos às equipes.
Agora vai de você pesquisar, analisar, testar e escolher uma implementação.
Quanto à fornecer somente ao SOA, poderia começar por um processo de exposição dos seus dados num modelo canônico rico, para atender outras aplicações como BI, que fazem uso de diversas fontes de informação.
Ao invés do BI ir diretamente à fonte, você disponibilizaria o conteúdo através de um proxy ( ESB).
[quote=mateusbrum]Estou começando a entender a utilização da abstracção de dados, entretanto paira a dúvida:
Deve-se criar uma camada apenas para fornecer os SDOs para atender o SOA ?
Ou há alguma outro padrão mais indicado para essa conversão de dados ?
Obrigado.[/quote]
Nem sempre a exposição de serviços de acesso a dados é a melhor opção.
Se, por exemplo, vc possui informações de cliente em um cadastro único é bem mais simples expor o acesso a esses dados por uma interface de serviços comum (EJB, WS, Restful, etc…)
Por outro lado, se as informações sobre seus clientes estão na seguradora, na financeira, no banco, etc… e não é possível/viável um projeto que unifique as bases, Data Services podem ser uma boa resposta. No entanto, lembre-se que não adianta nada criar esses serviços e deixar que os legados continuem acessando diretamente as bases onde estão esses dados, da mesma maneira como faziam antes. É de responsabilidade do Data Service a sincronia dos dados entre as bases legadas, então os acessos só podem ser feitos por ele.
Kenobi, concordo que - de forma complementar - serviços focados em dados são necessários. No entanto, adotar uma abordagem SOA com EDA, pode contribuir muito nestes casos. Recentemente eu estava levantando algumas questões parecidas em blog de SOA (Dados e BI):
“SOA tem uma base sólida em Design by Contract (DbC) e Component Based Development (CBD).[…]”
"[…] Serviços encapsulam os dados de seu backend - essa é uma questão essencial. Caso um determinado cliente esteja utilizando dados obtidos por intermédio de um serviço para a “execução” de uma regra de negócio, provavelmente essa regra ficaria mais coesa no serviço, não no cliente, ou seja, o serviço deveria fornecer uma operação que encapsula a regra, retornando, por exemplo, um boolean, evitando desta forma que o cliente receba dados desnecessários.
Seguindo o mesmo princípio, um serviço não deve receber dados de outros serviços para cumprir uma regra de negócio. Normalmente, tudo o que recebem são seus próprios dados ou, no máximo, identificadores únicos de conceitos de outros serviços, evitando dados/objetos que não estejam coesos. […]"
“[…]Serviços encapsulam seus dados, por isso, sempre achei estranhas as abordagens de BI com SOA. BI consolida dados, para isso, consomem dados; serviços seguem o caminho oposto, escondem dados. Ainda temos questões de desempenho envolvidas pela característica distributiva dos serviços. No entanto, um interessante artigo da InfoQ, mostra que SOA com EDA pode, em muitos casos, substituir abordagens ETL para consolidar bases, com vantagens, para apoiar iniciativas de BI.[…]”
