Acesso a Dados com Service DataObjects, versões de API 1.0 e 2.01

A estrutura do SDO (Service Data Objects) é um mecanismo de acesso a dados centrado em dados, desconectado e integrado ao XML que fornece um conjunto de resultados independente da origem.

  • O SDO é centrado em dados porque ele elimina a necessidade de aplicativos clientes de trabalhar com formatos especiais de dados, como as representações de objeto da API do EJB (Enterprise JavaBeans). Em vez disso, os clientes trabalham com gráficos facilmente transversáveis de DataObjects.
  • O SDO está desconectado, pois o resultado recuperado é independente de qualquer conexão ou transação de data store de backend.
  • SDO é integrado ao XML de forma a fornecer serviços para converter com facilidade os dados recuperados para e a partir do formato XML.
Colocado de forma simples, o SDO é uma estrutura para desenvolvimento de aplicativos de dados que inclui uma arquitetura e API. O SDO faz o seguinte:
  • Simplifica o modelo de programação de dados Java™ Platform, Enterprise Edition (Java EE).
  • Dados abstratos em uma service-oriented architecture (SOA).
  • Unifica desenvolvimento de aplicativos de dados.
  • Suporta e integra XML.
  • Incorpora padrões de Java EE e melhores práticas.

A estrutura do Service Data Objects fornece uma estrutura unificada para desenvolvimento de aplicativos de dados. Com SDO, não é necessário estar familiarizado com uma API de tecnologia específica para acessar e utilizar dados. Você precisa conhecer apenas uma API, a API SDO, que permite trabalhar com dados a partir de diversas origens de dados, incluindo bancos de dados relacionais, componentes EJB de entidade, páginas XML, serviços da Web, o Java Connector Architecture, JavaServer Pages e mais.

Ao contrário de alguns outros modelos de integração de dados, o SDO não pára na abstração de dados. A estrutura do SDO também incorpora um bom número de padrões Java e boas práticas, tornando fácil incorporar a arquitetura comprovada e designs nos seus aplicativos. Por exemplo, a maioria dos aplicativos da Web hoje não (e nem podem) se conectar com 100% dos sistemas backend de tempo, portanto, o SDO suporta um modelo de programação desconectado. Da mesma forma, vários aplicativos tendem a ser notadamente complexos, abrangendo muitas camadas de problemas. Como os dados serão armazenados? Enviados? Apresentados a usuários em uma estrutura GUI? O modelo de programação do SDO prescreve padrões de uso que permitem uma separação clara de cada um desses problemas.

Componentes do SDO

Uma visão geral arquitetural do SDO descreve cada um dos componentes que compõem a estrutura e explica como eles trabalham em conjunto. Os três primeiros componentes listados são os recursos "conceituais" de SDO: eles não possuem uma interface correspondente no API.

Clientes SDO

Os clientes SDO utilizam a estrutura do SDO para trabalhar com dados. Em vez de utilizar as estruturas e as APIs específicas de tecnologia, eles utilizam a API e o modelo de programação do SDO. Os clientes SDO trabalham em DataObjects de SDO e não precisam saber como os dados com que estão trabalhando são persistidos ou serializados.

Data Mediator Services
Os DMS (Data Mediators Services) são responsáveis por criar um DataGraph de origens de dados e atualizar origens de dados com base em alterações feitas em um DataGraph. (Um DataGraph é um objeto de envelope que contém objetos de dados de serviço.)

O DMS fornece o mecanismo para mover dados entre um cliente e uma origem de dados. Ele é criado com metadados específicos de backend. Os metadados definem a estrutura do DataGraph produzida pelo DMS bem como a consulta a ser utilizada no backend. Ao solicitar o DMS para produzir um DataGraph, ele consulta o backend de destino e transforma o conjunto de resultados nativo no formato de DataGraph. Uma vez retornado o DataGraph, o DMS não possui mais nenhuma referência, tornando-o sem estado em relação ao DataGraph. Quando é solicitado ao DMS para liberar modificações de um DataGraph existente para o backend, ele extrai as alterações feitas a partir do estado original do DataGraph e libera essas alterações para o backend. Um DMS geralmente emprega alguma forma de estratégia de controle de coincidência otimista para detectar as colisões de atualizações.

O WebSphere Application Server oferece funcionalidade para dois Serviços de Mediador de Dados separados. Se você precisar apenas recuperar dados de uma origem de dados relacionais e retornar um DataGraph, o uso do Java Database Data Mediator Service é uma boa opção. No entanto, se tiver lógica de negócios, provavelmente desejará uma renderização OO (Object Oriented) dos dados em beans de entidade. Alguém poderia considerar os SDO como uma renderização de dados do objeto semelhante aos beans de entidade. Mas os beans de entidade possuem ferramentas de mapeamento OR (Object-Relational) melhores e o gerenciador de contêiner e de persistência EJB dos beans de entidade oferecem políticas de armazenamento em cache mais sofisticadas. Então, sua melhor opção é o EJB Data Mediator Service. O mediador EJB pode funcionar com esses caches. Além disso, o modelo de programação do bean de entidade é um modelo de armazenamento de único nível. Você pode navegar de entidade para entidade e o gerenciador de contêiner e de persistência pré-busca ou busca dados sem muita intensidade, conforme necessário. Na atualização, o programador confirma a transação e o contêiner e o gerenciador de persistência realizam o trabalho de rastrear beans atualizados e gravá-los de volta no armazém de dados e no cache de memória.

Origens de Dados
As origens de dados não estão restritas às origens de dados de backend (por exemplo, bancos de dados de persistência). Uma origem de dados contém dados em seu próprio formato. No caso da API do SDO 1.0, somente o DMS acessa origens de dados; os aplicativos SDO, não. Os aplicativos trabalham apenas com DataGraphs do SDO 1.0.
Cada um dos componentes a seguir corresponde a uma interface Java no modelo de programação SDO.
DataObjects

Como componentes fundamentais de SDO, os DataObjects fornecem uma visualização comum dos dados estruturados para clientes SDO. Os DataObjects podem manter vários atributos diferentes de qualquer tipo serializável (como cadeia ou inteiro); DataObjects mais complexos também podem conter DataObjects mais simples. O DataObjects retêm seus dados em propriedades.

Os DataObjects do SDO versão 1.0 estão sempre vinculados e contidos nos DataGraphs. A interface do DataObject da versão 1.0 fornece métodos simples de criação e de exclusão (createDataObject() com várias assinaturas e delete()), e métodos refletivos para obter seus tipos (instância, classe, nome propriedades e espaço de nomes). Uma interface também suporta tipos de objeto estáticos que você cria de geradores de código externos. Consulte o artigo "Tipos de objeto de dinâmicos e estáticos para o JDBC DMS" para obter mais informações.

DataGraphs

Um DataGraph é um resultado estruturado, retornado em resposta a um pedido de serviço. O DMS transforma os resultados da consulta do backend nativo em DataGraph, que é independente do data store de backend original. Isso torna o DataGraph facilmente transferível entre origens de dados diferentes. O DataGraph é composto de nós interconectados, cada qual sendo um SDO DataObject. Ele é independente de conexões e transações da origem de dados original. O DataGraph monitora as alterações feitas nele a partir de sua origem original. Esse histórico de alterações pode ser utilizado pelo DMS para refletir as alterações de volta à origem de dados original. Os DataGraphs podem ser facilmente convertidos de e para documentos XML, permitindo que sejam transferidos entre camadas em uma arquitetura de sistema com multicamadas. Um DataGraph pode ser acessado de modo breadth-first ou depth-first e fornece um cache de dados desconectado que pode ser serializado para os serviços da Web.

O DataGraph retornado pelo mediador pode conter DataObjects dinâmicos ou estáticos gerados. O uso de classes geradas fornece interfaces de tipos seguros para a programação mais fácil e melhor desempenho de tempo de execução. As classes geradas de EMF devem ser consistentes em nome e tipo com o esquema que deve ser criado para DataObjects dinâmicos, exceto que os atributos e referências adicionais podem ser definidos. Apenas os atributos e referências especificados na consulta são preenchidos com dados. Os atributos e referências restantes não são definidos.

Resumo de Alterações

Os DataGraphs contêm os resumos de alteração do SDO 1.0 e são usados para representar as alterações feitas a um DataGraph retornado pelo DMS. Inicialmente eles estão vazios (quando o DataGraph é retornado para um cliente) e são preenchidos conforme o DataGraph é modificado. Os resumos de alterações são utilizados pelo DMS no tempo de atualização de backend para aplicar as alterações de volta à origem de dados. Eles ativam o DMS para atualizar as origens de dados com eficiência e incrementalmente fornecendo listas das propriedades alteradas (juntamente com seus valores antigos) e os DataObjects criados e excluídos no DataGraph. As informações serão incluídas no resumo de alterações de um DataGraph apenas quando o registro do resumo das alterações estiver ativado. Os resumos de alterações fornecem métodos para o DMS ativar e desativar o log.

Nota: O resumo de alteração do SDO 1.0 não é uma API cliente; ele é usado somente pelo DMS.
Propriedades, Tipos e Sequências

Os DataObjects mantêm seu conteúdo em uma série de propriedades. Cada propriedade tem um tipo, que é um tipo de atributo como um tipo primitivo (por exemplo, int) ou um tipo de dados comumente utilizado (por exemplo, Data) ou, se uma referência, o tipo de um outro DataObject. Cada DataObject fornece métodos de acesso de leitura e gravação (getters e setters) para suas propriedades. Várias versões sobrecarregadas desses acessadores são fornecidas, permitindo que as propriedades sejam acessadas, transmitindo o nome da propriedade (Cadeia), o número (int) ou o próprio metaobject da propriedade. O acessador da Cadeia também suporta uma sintaxe como XPath para acessar propriedades. Por exemplo, é possível chamar get("department[number=123]") em uma empresa DataObject para obter seu primeiro departamento cujo número é 123. As sequências são mais avançadas. Elas permitem que a ordem seja preservada por meio de listas heterogêneas de pares de valor-propriedade.

Para Obter Informações Adicionais Introdutórias

Para uma boa introdução ao SDO 1.0 que também inclui um pequeno aplicativo de amostra, consulte o documento "Introdução ao Serviço DataObjects" do IBM® developerWorks.

Nota: Para entender por completo o serviço de mediador de dados do EJB, é necessário um bom conhecimento do modelo de programação do EJB. Para obter mais informações, consulte os artigos "Visão geral da tarefa: usando enterprise beans em aplicativos" e "Objetos de Dados de Serviço: Recursos para aprendizado."

Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cdat_datsdo
Nome do arquivo: cdat_datsdo.html