AN style="FONT-SIZE: 10pt; BACKGROUND: white; COLOR: red; FONT-FAMILY: Verdana; moz-background-clip: -moz-initial; moz-background-origin: -moz-initial; moz-background-inline-policy: -moz-initial">
PAN>
re eles.
Em que situação o tema é útil:
Todas as grandes corporações do mercado de sistemas de gerência de conteúdo estão envolvidas no desenvolvimento e disseminação da especificação. Sendo assim, o conhecimento da especificação permite ao desenvolvedor criar aplicativos capazes de se comunicar de maneira uniforme com todos estes sistemas que implementam a API.
Introdução a JCR:
A especificação JSR-170 define a API Java Content Repository (JCR), que traz o conceito de repositórios de conteúdo para as aplicações. Repositórios são uma nova abstração de modelo de persistência de dados que substitui a necessidade do uso de sistemas de arquivos e bancos de dados relacionais, disponibilizando um apanhado das melhores funcionalidades destes dois tipos de sistemas. Além disso, repositórios são extremamente flexíveis quanto à estruturação dos dados que controla, o que é uma abordagem bastante interessante para o desenvolvimento de aplicações voltadas a conteúdo.
Com o crescente número de sistemas de gerenciamento de conteúdo (CMS, sigla para Content Management System), surgiu a necessidade de padronização na forma de intercâmbio entre estes “silos” de dados. É esta necessidade que a JCR 1.0 (Java Content Repository, também referenciada como Content Repository API) tem por objetivo suprir.
Neste artigo serão apresentados os detalhes da especificação e sua utilização será exemplificada com uma aplicação web simples, que utiliza um repositório de conteúdo baseada no Apache Jackrabbit, a implementação de referência e de código aberto da especificação JSR-170.
A especificação
A Content Repository API é definida pela especificação JSR-170, cujo expert group é liderado por David Nuescheler, CIO da Day Software, empresa que desenvolve o software Day CRX, que implementa todas as camadas da especificação. Participam também do expert group importantes empresas do mercado de gerência de conteúdo, como IBM, BEA, Documentum e Oracle.
A necessidade de uma especificação para esta área surgiu quando observou-se a dificuldade na interoperabilidade entre os sistemas de gerenciamento de conteúdo existentes. Mesmo organizando os dados internamente de forma similar, essas instâncias de dados heterogêneas acrescentavam um novo nível de problemas no momento em que se desejava fazer uma substituição de algum desses sistemas, ou quando a tarefa era implementar uma aplicação que agregava dados provenientes de dois ou mais sistemas distintos.
O objetivo
O objetivo da especificação JSR-170 é prover uma interface de programação que seja ao mesmo tempo simples de usar para os programadores e de fácil implementação e adoção para os desenvolvedores de repositórios de conteúdo. Ao atingir estas metas, a especificação torna-se difundida entre os desenvolvedores e também um padrão de fato.
Com o propósito de ser fácil de implementar e adaptar a repositórios de conteúdo já existentes, a Java Content Repository API foi dividida em camadas. A especificação define também os níveis de conformidade para cada camada, podendo uma implementação JCR não dispor de funcionalidades de todas as camadas. Este conceito será mais bem compreendido após a análise de cada uma das camadas.
As camadas
A primeira camada da especificação define um repositório somente-leitura. Isto inclui funcionalidades de leitura do conteúdo, introspecção sobre a definição dos tipos, ou seja, a capacidade de identificar como está estruturado o conteúdo em questão, o suporte básico a namespaces, a capacidade de exportar o conteúdo para um arquivo XML, e a busca.
A segunda camada introduz os métodos para a escrita de conteúdo no repositório, a atribuição de tipos ao conteúdo, suporte avançado a namespaces e a importação de dados a partir de um arquivo XML.
Finalmente, a terceira camada define as funcionalidades opcionais que um repositório de conteúdo em conformidade com a especificação pode implementar. São eles o suporte a transações, controle de versão de conteúdo, observabilidade (capacidade de executar determinado código no evento de mudança de alguma propriedade do conteúdo), controle de acesso, travamento (“locking”, capacidade de bloquear determinado conteúdo para escrita) e suporte adicional a busca.
A presença de todas estas funcionalidades em um único mecanismo de persistência de dados faz do JCR uma alternativa bastante poderosa se comparada a outros mecanismos existentes. Por exemplo, não é incomum que uma aplicação Java precise persistir seus dados em um banco de dados relacional, onde as informações são armazenadas de forma tabular, e em um sistema de arquivos, onde é mais conveniente persistir dados binários e onde se pode organizar esta informação de forma hieráriquica (em diretórios e subdiretórios). Neste caso é possível substituir os dois mecanismos apenas por um repositório, onde há a liberdade de estruturação do conteúdo (os dados) de qualquer uma das formas. Outros recursos desses mecanismos de persistência também são cobertos pela especificação, como mostra a Figura 1.
Figura 1. Diagrama de funcionalidades disponíveis em sistemas de arquivos, bancos de dados e repositórios de conteúdo.
A organização do repositório
Um repositório é composto por um ou mais workspaces, onde cada workspace contém uma árvore de itens. Um item pode ser um nó ou uma propriedade. Cada nó pode ter zero ou mais itens filhos. Em um workspace existe um único nó raiz, o qual não tem pai. Todos os outros nós têm um pai. Propriedades têm um nó pai e não podem ter itens filhos, isto é, propriedades são nós-folha em um workspace. Um exemplo de workspace pode ser visto na Figura 2, e um diagrama exemplificando o relacionamento entre itens, nós e propriedades está na Figura 3.
...
