Processamento de Documentos Ativos XML
Daniela Marques Pereira e Marcelo de Mattos Mayworm
[email protected], [email protected]
Resumo. O framework de integração de dados peer-to-peer AXML surgiu com
o desafio de permitir o desenvolvimento de aplicações baseados em dados
distribuídos e dinâmicos fornecidos através de documentos ativos XML,
documentos estes que possuem chamadas a serviços webs que fazem com que
o conteúdo destes documentos seja então variável e dinâmico. Este framework
pode ser útil para uma série de aplicações importantes e por isso este relatório
tem por objetivo realizar um estudo que visa fazer um estudo do mesmo,
procurando levantar suas características, funcionalidades, vantagens e
desvantagens. Além deste levantamento, serão descritos os testes realizados
com o framework e os resultados obtidos com os mesmo. Os testes tinham por
objetivo avaliar as características do framework descritas neste trabalho e
analisar seu desempenho e funcionalidade.
Introdução
Os arquivos XML se tornaram o formato padrão para troca de informações na
Internet, devido a seu formato simples e devido ao fato de trazerem consigo dados e
metadados. Com o surgimento dos WebServices ou Serviços Web, estes arquivos se
tornaram ainda mais importantes, uma vez que estes serviços utilizam este formato
como padrão para troca de informações.
Um Web Service, nada mais é do que um serviço publicado na Internet que permite
que duas aplicações troquem informações. Estes serviços são fortemente baseados em
XML e no protocolo HTTP, podendo ser utilizados de forma totalmente independente
de plataforma e linguagem de programação.
Estes serviços trouxeram para o ambiente da Internet novas perspectivas de
interação, além da já conhecida homem-máquina, possível através da navegação
através de browsers pelas páginas disponíveis em servidores web. Com os serviços
Web, foi possível automatizar as interações existentes na Web, favorecendo aplicações
de e-comerce, B2B entre outras. Eles na verdade são uma tentativa de construir uma
plataforma computacional distribuída para a Web.
O framework Active XML [1], procuroa fazer uso destas duas tecnologias de modo
a tirar proveito de ambas, criando o que eles chamaram de documentos ativos XML.
Documentos Ativos XML ou simplesmente documentos AXML, são documentos
XMLs convencionais, que podem ou não seguir um esquema, mas que possuem dados
ativos, isto é, dados que para serem materializados no documento XML necessitam
que serviços web sejam executados, retornando como resultado de execução os dados
a serem preenchidos. O conteúdo pode ser dinâmico, pois estas chamadas são
2
Daniela Marques Pereira e Marcelo de Mattos Mayworm
controladas e os resultados destas chamadas (conteúdo do arquivo) atualizados
conforme a freqüência determinada na chamada do serviço.
Esta funcionalidade pode ser muito importante para uma série de aplicações devido
ao seu conteúdo dinâmico. Um exemplo simples seria de um jornal que dentre algumas
informações contidas em um arquivo XML, poderia ter também a previsão do tempo
para a cidade do jornal, obtida através da chamada a um serviço Web específico que
fornece esta informação. Esta informação pode ser atualizada constantemente, e o
jornal pode fornecer sempre informações sobre a temperatura atualizadas.
Além da realização de chamadas a serviços web o framework AXML, também
permite disponibilizar serviços através de consultas realizadas sobre o repositório
XML existente, cujos arquivos também podem conter chamadas a serviços web.
O framework AXML é dito uma aplicação P2P [1], cujo objetivo é integrar
informações fornecidas por várias fontes autônomas e heterogêneas e também
executar consultas informalmente sobre estas informações. Por assumir esta
arquitetura P2P, não existe uma fonte central e qualquer peer pode assumir esta função
de integração. [2] No entanto existem algumas controvérsias com relação as
definições de P2P existentes e que serão tratadas neste relatório.
Através deste framework, não só tem-se uma distribuição das informações, como
também uma distribuição do processamento, uma vez, que chamadas a serviços locais
demanda processamento local e chamadas a serviços remotos, demandam
processamento da máquina que provê o serviço.
Como em todo ambiente P2P, as chamadas não são garantidas, pois basta o peer
que contem o serviço requisitado falhar que os dados não serão integrados. Este é um
problema presente em todo o ambiente P2P e que na maioria dos casos não garante a
resposta certa, mas a melhor resposta possível.
Neste relatório, procurar-se-á descrever a arquitetura do framework em questão,
seu funcionamento e configuração, e procurar-se-á realizar testes que explorem suas
funcionalidades e verifiquem seu comportamento e desempenho.
Arquitetura AXML
O framework Active XML ou AXML é considerado uma arquitetura peer-to-peer
de integração de dados, ou que pelo menos facilita a integração de dados, onde cada
site prove dados XML e/ou WebServices e pode também chamar outros peers que
contenham arquivos XML e que definem serviços AXML. Além da integração de
dados, o framework AXML visa facilitar a publicação de aplicações baseadas em
dados compartilhados e distribuídos.[2]
Através deste framework é possível configurar peers, chamados de peers AXML
que podem tanto possuir documentos ativos XML com chamadas a serviços web,
quanto fornecer serviços, baseados em consultas executadas sobre o repositório.
Documentos AXML
Os documentos AXML, nada mais são do que arquivos XML válidos (e por isso
podem fazer uso de todas as ferramentas XML existentes) onde alguns elementos (os
Processamento de Documentos Ativos XML
3
rotulados como sc) são interpretados como chamada de serviços. A presença destes
elementos o faz um documento intencional, uma vez que alguns dos dados são
fornecidos de forma explícita, enquanto para outros dados é dada uma definição (o
que significa pegar os dados somente quando forem necessários). Estes documentos
podem ser vistos como documentos dinâmicos, pois um mesmo serviço chamado duas
vezes pode trazer respostas diferentes e assim o mesmo documento em momentos
diferentes poderá conter informações diferentes.
Exemplo de uma chamada de serviço:
<axml:sc methodName="GetACM" valid="0" mode="replace"
serviceNameSpace="GetACM"
serviceURL="http://localhost:8080/ActiveXMLWeb/servlet/AxisServlet">
<axml:params/>
</axml:sc>
No exemplo acima, foi realizada uma chamada a um serviço chamado GetACM
publicado no mesmo peer de onde a chamada foi executada. Após a chamada o
conteúdo foi acrescentado ao documento:
<axml:sc methodName="GetACM" mode="replace" serviceNameSpace="GetACM"
serviceURL="http://localhost:8080/ActiveXMLWeb/servlet/AxisServlet"
valid="0">
<axml:params/>
</axml:sc>
<código axml:origin="8B67DE13-7F00-0001-018F-F4F671EE685E"
endPage="119"/>
Tanto em chamadas a serviços internos quanto em chamadas a serviços
internosexternos, o conteúdo resultante da chamada de serviço é adicionado ao
documento AXML.
Atributos de Chamadas de Serviços
O elemento responsável pelas chamadas aos serviços web, possui uma série de
parâmetros que auxiliam no modo e com que freqüência estas chamadas serão
executadas. [3]
Os parâmetros possíveis são:
Atributo
Tipo
Valor Default
Status
serviceURL
Qualquer URI
requerido
serviceNameSpace
Qualquer URI
requerido
methodName
Nome do Método
requerido
signature
anyURI
opcional
useWSDLDefinition booleano
false
opcional
4
Daniela Marques Pereira e Marcelo de Mattos Mayworm
id
Id
Gerado
name
string
opcional
frequency
string
opcional
callable
boolean
lastCalled
unsignedLong
gerado
followedBy
string
opcional
mode
doNesting
string
boolean
true
merge
false
opcional
opcional
ServiceURL
Especifica a URL do serviço web.
ServiceNameSpace
Este atributo especifica o nome a ser usado no elemento body da mensagem SOAP.
De forma mais simples é o nome URI do método.
MethodName
Define o nome da operação a ser chamada no serviço web.
Signature
Este atributo marca a URL do arquivo WSDL que define o serviço web.
UseWSDLDefinition
Este atributo especifica se o arquivo WSDL definido pela assinatura deve ser usado na
validação de tipos.
Id
Identifica unicamente uma chamada de serviço e não deve ser definida manualmente.
Name
Especifica o nome da chamada de serviço. Não possui nenhum significado e é
opcional.
Frequency
O momento no qual a chamada de um serviço deve ser ativada é controlado por um
atributo especial do elemento <sc>: frequency. A freqüência (frequency) pode ser
definida como um intervalo de tempo ou disparada por uma mudança no conteúdo do
documento. Uma chamada de serviço é tida como ”expired” quando de acordo com o
Processamento de Documentos Ativos XML
5
valor definido em frequency ela tiver que ser chamada novamente. Os valores
possíveis para este parâmetro são:
·
·
·
·
Once – indica que o serviço só será executado uma única vez, quando o
sistema for iniciado;
Lazy - a chamada do serviço só será chamada quando seus resultados
forem úteis para a execução de uma consulta X-OQL ou para a
instanciação de um parâmetro de uma chamada através de uma expressão
XPath.
On Date – Especifica exatamente quando um serviço será executado.
Exemplo: frequency="on 25/12/05 14:36"
Every X – Define de quantos em quantos milisegundos o serviço web será
chamado. Exemplo: frequency= “every 60000”.
Callable
Através deste atributo é possível configurar o serviço para ele não ser ativado por
um peer AXML, mesmo que ele possua uma configuração de freqüência adequada.
LastCalled
Este atributo é usado pelo peer AXML para monitorar a última vez que o serviço foi
chamado de modo a cumprir a freqüência sempre que o peer AXML for iniciado ou
recarregado após alguma modificação.
FollowedBy
Este atributo, permite encadear a execução de vários serviços web dentro de um
mesmo documento (um forma simples de workflow).
mode
Este atributo especifica o que fazer com o resultado obtido pela chamada de serviço
AXML e pode assumir dois valores:
·
·
merge – significa que os resultados serão adicionados logo após o
elemento <sc> e que os resultados anteriores serão mantidos.
replace – significa que os resultados anteriores serão substituídos
pelos resultados obtidos pela nova chamada ao serviço.
doNesting
Usado quando se deseja manter um rastro dos nós de texto inseridos no arquivo
AXML. Assim é possível pedir ao peer que aninhe os nós do tipo texto em um
elemento especial chamado text e o ligue ao AXML.
Exemplo de uma chamada de serviço web com vários parâmetros configurados:
<axml:sc xmlns:axml="http://www-rocq.inria.fr/verso/AXML"
6
Daniela Marques Pereira e Marcelo de Mattos Mayworm
serviceURL="http://api.google.com/search/beta2"
serviceNameSpace="urn:GoogleSearch"
methodName="doGoogleSearch"
signature="http://api.google.com/GoogleSearch.wsdl"
useWSDLDefinition="true"
id="038BD50A-C353-D490-0082-D603FA7A81AC"
name="GoogleSearch"
frequency="lazy"
lastCalled="1082395879693"
followedBy="//axml:sc[@serviceNameSpace='Crawler']"
...>
[snipped
Serviços AXML
O framework AXML permite não só usar serviços web já existentes como também
definir novos serviços sobre os arquivos XML existentes no repositório. A definição
de serviços web AXML se baseia em consultas XML parametrizadas expressas em
XQuery, estendida com updates. A especificação de serviços AXML permite, em
particular, a definição de serviços contínuos e de serviços com entrada e saídas
intencionais.
Peers AXML
Um peer AXML contém um módulo de armazenamento e um catálogo dos serviços
definidos neste peer. Cada peer possui também um modulo avaliador que é
responsável por ativar as chamadas definidas nos documentos AXML. No caso de
chamadas a serviços externos ao peer, estas chamadas são codificadas por um SOAP
Wrapper que as transmite ao provedor do serviço e eventualmente recebe os
resultados como uma mensagem SOAP.
Cada peer XML pode atuar tanto com cliente de serviços publicados em outros
peers ou de serviços web, quanto como servidor provendo serviços definidos através
de consultas sobre o repositório XML existente no mesmo.
Uma questão interessante a ser levantada é com relação a arquitetura deste
framework ser definida como peer-to-peer. Segundo [5], embora a definição exata de
peer-to-peer seja discutível, estes sistemas não possuem infra-estrutura centralizada,
dedicada, mas ao invés dependem da participação voluntária dos pares para contribuir
com recursos com os quais a infra-estrutura é construída. A participação nos sistemas
peer-to-peer é ad-hoc e dinâmica. Sob este aspecto, o framework AXML pode ser dito
peer-to-peer no sentido de que cada peer pode atuar tanto quanto cliente, quanto como
servidor e a formação da rede é aleatória e dinâmica e pode fazer uso dos serviços
publicados em sites distintos. No entanto isso nem sempre é verdade. Um peer pode
fazer chamadas aos serviços publicados em um único peer e se não houver replicação
destes serviços em outros peers e um redirecionamento de acesso caso este peer esteja
fora do ar, o sistema estará se comportando com um sistema cliente-servidor comum,
onde um peer fornece os serviços e outro os utiliza. Se este peer cair, o peer cliente,
ficará sem acesso ao serviço e não terá como atualizar o conteúdo do arquivo XML
que faz as chamadas.
Processamento de Documentos Ativos XML
7
Figura 1 - Arquitetura AXML
Configuração de um Peer AXML
O framework AXML é distribuído como uma aplicação Web, desenvolvida em java,
que deve rodar em um container servlet 2.3/ JSP 1.2 tal como o Tomcat. Assim, para
que uma estação possa ser configurada como um peer AXML, é preciso que ela tenha
instalado o Java Development Kit (versão 4.1 ou superior), não funciona somente com
o Java Runtime Enviroment e um servlet container como o Tomcat e fazer o deploy da
aplicação no container instalado.
Uma vez instalados todos os elementos necessários, é possível acessar a interface
web do framework AXML, através da qual é possível visualizar os documentos
publicados no repositório XML, edita-los, comandar chamadas de serviços presentes
nos documentos, visualizar e editar serviços definidos e executar consultas sobre o
repositório.
8
Daniela Marques Pereira e Marcelo de Mattos Mayworm
Figura 2 – Documentos Publicados
Figura 3 – Edição de Documentos
Processamento de Documentos Ativos XML
Figura 4 – Documento publicado com uma chamada de serviço
Figura 5 – Mesmo documento após a chamada de serviço
9
10
Daniela Marques Pereira e Marcelo de Mattos Mayworm
Figura 6 – Especificação de um serviço
Figura 7 – Execução do serviço definido na figura 6
Processamento de Documentos Ativos XML
11
Figura 8 - Espaço para a execução de consultas
Publicação de documentos AXML
Para publicar um arquivo no repositório, de modo que este possa ser utilizado em
consultas e estejam visíveis através da interface web, é preciso criar uma entrada para
o documento em um arquivo xml chamado docRepository.xml que representa o
repositório de documentos, da seguinte maneira:
<?xml version="1.0" ?>
<mxbase>
<forest name="HelloWorld">
<file href="hello.xml" />
<file href="world.xml" />
</forest>
</mxbase>
O elemento root é chamado de mxbase e os itens de seu repositório são
representados pelo elemento forest. O nome do atributo forest identifica a
floresta no repositório e no peer AXML. Este é o valor que deve ser utilizado para
identifica-la, como por exemplo, em uma consulta. Uma forest na verdade é um
documento lógico, que pode ser composto de vários arquivos XMLs físicos, descritos
através do elemento file e do atributo href.
Definição de serviços AXML
12
Daniela Marques Pereira e Marcelo de Mattos Mayworm
Um peer AXML também pode ser um repositório de serviços web AXML. Um serviço
é definido de forma declarativa e pode ser dos tipos:
• query,
• update,
continuous,
callback,
composed,
• xslt.
Os serviços, também definidos em arquivos XML, devem ser declarados em um
arquivo chamado svcRepository.xml, para que possam ser chamados e para que
possam ser visualizados pela interface web do framework.
Exemplo de um arquivo XML, contendo uma consulta:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<serviceDefinition type="query">
<parameters>
<param name="codigo" />
</parameters>
<definition>
<query>
<![CDATA[
select <article>p/title</>
from p in ACM//articles/article
where p/"endPage" = codigo;
]]>
</query>
</definition>
</serviceDefinition>
Declaração do serviço no arquivo XML svcRepository.xml:
<?xml version="1.0" ?>
<mxbase origURI="yaunos.inria.fr" lastId="0">
<forest name="GetACM2" replicationIndex="0">
<file name="" href="acm/servicos/GetACM2.xml" />
</forest>
</mxbase>
Testes
Uma vez feito um estudo sobre o framework ActiveXML, realizamos testes que
procuraram analisar suas características, através do que julgamos ser uma aplicação
onde estas características seriam úteis e favorecidas pela utilização do framework em
questão.
Com os testes, procurou-se analisar as características de distribuição deste
framework, ou seja, analisar como que as funcionalidades que permitem a distribuição
Processamento de Documentos Ativos XML
13
de dados e processamento se comportam. Dentre estas funcionalidades, procuramos
analisar como é possível fazer a publicação de novos serviços a partir de um
repositório XML existente, como fazer chamadas a serviços internos e externos a um
peer, como integrar seus resultados provenientes de chamadas a serviços distintos, e
como realizar consultas sobre documentos que possuem chamadas de serviços.
Para a realização dos testes utilizamos o repositório XML da ACM (ACM Record)
para que fosse possível definir serviços e realizar chamadas a estes serviços a partir de
documentos AXML.
Instalação e Configuração
Para a realização dos testes, utilizamos um PowerPC – Apple rodando MacOS e um
PC Athlon 3 GHZ com 512 MB de memória RAM, rodando Windows XP
Professional. As duas máquinas estava interligadas em rede e podiam ser acessadas
uma a partir da outra.
Em ambas as máquinas foi instalado o JBOSS 4.0 para onde foi feito o
deploy do framework, baixado a partir do repositório CVS do projeto
(cvs.forge.objectweb.org). Assim cada uma das máquinas foi configurada como um
peerXML. Para podermos ter acesso a interface do framework, bastava acessar o
seguinte
endereço
a
partir
do
browser:
http://localhost:8080/ActiveXMLWeb/jsp/index.jsp.
Para o desenvolvimento de novos serviços, configuração de arquivos e
publicação dos mesmos, utilizamos a ferramenta Eclipse, uma vez que o framework
foi todo desenvolvido em Java.
Testes Realizados
Os primeiros testes foram executados sobre um arquivo chamado 152.xml que foi
publicado como ACM no arquivo docRepository.xml e que continha os artigos
publicados no 15º volume dos proceedings da ACM.
Sobre este arquivo foi criado o seguinte serviço:
GETACM, que corresponde a consulta abaixo:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<serviceDefinition type="query">
<definition>
<query>
<![CDATA[
select <article> p/title</>
from p in ACM//articles/article
where p/initPage > 100;
]]>
</query>
</definition>
</serviceDefinition>
14
Daniela Marques Pereira e Marcelo de Mattos Mayworm
Para utilizar este serviço, foi criado um documento ativo XML, que fazia a
chamada ao serviço descrito acima. O documento foi registrado como servicoACM e
a chamada foi configurada da seguinte maneira:
<?xml version="1.0" encoding="UTF-8"?>
<vol axml:docName="servicoACM" xmlns:axml="http://wwwrocq.inria.fr/verso/AXML">
<axml:sc methodName="GetACM" valid="0" mode="immediate"
serviceNameSpace="GetACM"
serviceURL="http://localhost:8080/ActiveXMLWeb/servlet/AxisServlet">
<axml:params/>
</axml:sc>
</vol>
Sobre os resultados obtidos através da chamada de serviço declarada no
documento acima, foi criado um serviço chamado GETACM2, que corresponde a
consulta abaixo:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<serviceDefinition type="query">
<definition>
<query>
<![CDATA[
select p/article
from p in servicoACM//vol;
]]>
</query>
</definition>
</serviceDefinition>
Por fim criamos um outro documento ativo XML cadastrado como
servicoACM2 que possuía uma chamada ao serviço GETACM2.
<?xml version="1.0" encoding="UTF-8"?>
<vol axml:docName="servicoACM2" xmlns:axml="http://wwwrocq.inria.fr/verso/AXML">
<axml:sc methodName="GetACM2" valid="0" mode="immediate"
serviceNameSpace="GetACM2"
serviceURL="http://localhost:8080/ActiveXMLWeb/servlet/AxisServlet">
<axml:params/>
</axml:sc>
</vol>
Pelas configurações acima, esperávamos que ao executar a chamada de
serviço presente no documento ativo servicoACM2, a chamada de serviço declarada
no documento servicoACM fosse executada e por fim os dois documentos deveriam
conter os mesmos valores. No entanto isso não foi constatado.
Quando o documento servicoACM ainda não tinha o resultado da chamada de
serviço em seu conteúdo, a chamada de serviço presente no documento servicoACM2,
Processamento de Documentos Ativos XML
15
que executava uma querie sobre o primeiro, não retornava nada. Para que a chamada
funcionasse, era preciso primeiro executar a chamada presente no documento
servicoACM para que depois então a chamada ao serviço GetACM2, presente no
documento servicoACM2 pudesse trazer os resultados.
Outra questão analisada, é que com as configurações colocadas acima, se o
documento source, ou seja, o documento 152.xml (cadastrado como ACM) tivesse o
seu conteúdo trocado, as chamadas de serviço seguintes, executadas sobre este
arquivo não traziam nenhuma alteração, nem no arquivo servicoACM, nem no arquivo
servicoACM2. As alterações só foram percebidas quando o parâmetro mode era
setado como “replace”.
O atributo frequency funcionou normalmente atualizando automaticamente o
conteúdo da chamada do serviço dentro da freqüência determinada. Quando havia
uma chamada de serviço sobre este conteúdo, ao ser executada esta chamada trazia o
conteúdo atualizado também.
Um outro teste que foi realizado foi a chamada de serviço utilizando como
parâmetro o resultado trazido por outra chamada de serviço configurada dentro de um
mesmo documento. No entanto, para que a chamada de serviço que dependia do
parâmetro proveniente da outra chamada de serviço, só funcionava, quando a primeira
chamada já tinha sido executada e seu conteúdo materializado no documento XML.
Mesmo com a freqüência configurada como lazy, obtivemos os mesmos resultados.
Exemplo do teste descrito acima, após a execução das chamadas de serviço,
com a chamada ao serviço GetACM sendo executado primeiro para que a segunda
pudesse ser executada em seguida.
root
|
|___< vol>
| \___ {http://www-rocq.inria.fr/verso/AXML}docName (QName
axml:docName) = servicoACM2
|
|___< pagina>
|
|
|
|___ Service call
|
|
| \___serviceURL =
http://localhost:8080/ActiveXMLWeb/servlet/AxisServlet
|
|
| \___serviceNameSpace = GetACM
|
|
| \___methodName = GetACM
|
|
| \___frequency = lazy
|
|
| \___mode = replace
|
|
| \___id = 902F5F8B-7F00-0001-0002E879E0297599
|
|
|
|
|
|___Parameters
|
|
|
|___< codigo>
|
\___ {http://www-rocq.inria.fr/verso/AXML}origin
(QName axml:origin) = 902F5F8B-7F00-0001-0002-E879E0297599
|
\___ endPage = 119
|
|___< artigo>
16
Daniela Marques Pereira e Marcelo de Mattos Mayworm
|
|___ Service call
|
| \___serviceURL =
http://localhost:8080/ActiveXMLWeb/servlet/AxisServlet
|
| \___serviceNameSpace = GetACM2
|
| \___methodName = GetACM2
|
| \___frequency = lazy
|
| \___mode = replace
|
| \___id = 902F5F9A-7F00-0001-0002E8799ABCBDB7
|
|
|
|___Parameters
|
|
|
|___codigo
|
|
|
|___XPath : ../../
pagina/codigo/@endPage
|
|___< article>
| \___ {http://www-rocq.inria.fr/verso/AXML}origin
(QName axml:origin) = 902F5F9A-7F00-0001-0002-E8799ABCBDB7
|
|___< title>
| \___ articleCode = 152009
|
|___ Load balancing in a locally distributed D
B system
Com a utilização do forest, realizamos a execução de serviços
(ex.:GetACM) sobre um repositório lógico, ou seja, a execução do serviço é dada não
sobre um repositório físico XML, mas sobre vários arquivos físicos que são
endereçados por um nome lógico. A referência a esses arquivos não precisa ser local,
podendo ser uma URL e com isso conseguimos realizar, por exemplo, uma única
busca em um conjunto de arquivos XML. Esses arquivos podem ser distintos, ou seja,
conter uma estrutura (DTD ou esquema XML) diferente entre eles.
Como teste a virar subsidio para nossa aplicação, montamos um forest com
alguns dos arquivos do repositório ACMRecord, de forma a fornecer uma única
consulta capaz de retornar informações sobre as várias “proceedings” da ACMRecord.
A configuração do forest é realizada no arquivo docRepository.xml, ficando
da seguinte forma:
<forest name="ACM" replicationIndex="0">
<file name="" href="acm/242.xml" />
<file name="" href="acm/252.xml" />
<file
<file
<file
<file
name=""
name=""
name=""
name=""
href="acm/162.xml" />
href="acm/172.xml" />
href="acm/182.xml" />
href="acm/1922.xml" />
Processamento de Documentos Ativos XML
<file
<file
<file
<file
<file
<file
<file
<file
<file
<file
<file
<file
<file
<file
</forest>
name=""
name=""
name=""
name=""
name=""
name=""
name=""
name=""
name=""
name=""
name=""
name=""
name=""
name=""
href="acm/202.xml"
href="acm/212.xml"
href="acm/222.xml"
href="acm/232.xml"
href="acm/242.xml"
href="acm/262.xml"
href="acm/272.xml"
href="acm/282.xml"
href="acm/292.xml"
href="acm/302.xml"
href="acm/311.xml"
href="acm/312.xml"
href="acm/313.xml"
href="acm/314.xml"
17
/>
/>
/>
/>
/>
/>
/>
/>
/>
/>
/>
/>
/>
/>
Com essa criação do forest, podemos pensar em uma serie de serviços para
uma aplicação desenvolvida sobre o ACMRecord, como por exemplo:
·
·
·
Quais os artigos publicados em um determinado volume?
Todos os autores que já publicaram na ACM ou quais autores publicaram em
um determinado volume?.
Quais os artigos publicados em um determinado ano?
Uma querie executada sobre este repositório lógico foi a busca por autores
que publicaram artigos em um determinado ano, passado como parâmetro através da
tag param:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<serviceDefinition type="query">
<parameters>
<param name="ano" />
</parameters>
<definition>
<query>
<![CDATA[
select t//articles/article/title
from t in ACM
where t//"year"=ano;
]]>
</query>
</definition>
</serviceDefinition>
Enfim, temos uma série de buscas que podem ser realizadas de forma a tornar
a aplicação que utilizará o ACMRecord mais útil. Teremos uma base de dados XML
18
Daniela Marques Pereira e Marcelo de Mattos Mayworm
em torno de 900KB para realizarmos consultas e disponibilizarmos serviços. É
importante perceber como o uso do forest torna a base heterogenia (vários fontes xml)
apesar de estar em um mesmo “peer”.
Testes a serem Realizados
Os testes realizados até agora foram testes simples, visando explorar o funcionamento
e as características do framework AXML. A idéia agora, é produzirmos em cima de um
repositório XML, uma aplicação útil que faça proveito dos benefícios dos documentos
e serviços AXML. Pretendemos configurar dois ou mais peers servindo e consumindo
serviços definidos sobre os repositórios XML de cada peer. Procurar-se-á criar
serviços que façam uso de consultas encadeadas e aninhadas para que possamos
constatar a eficiência deste framework.
Conclusões
Dentre os testes realizados até agora, pudemos constatar que o framework AXML é
inovador em sua proposta, permitindo o desenvolvimento de aplicações baseadas em
dados dinâmicos e distribuídos e que é de fácil configuração.
No entanto sua utilização requer atenção e algumas funcionalidades ficaram a
desejar, como a chamada de serviços encadeados, onde as chamadas tiveram que ser
executadas manualmente para que as subseqüentes pudessem trazer os resultados.
Tivemos algumas dificuldades também com relação a chamadas a serviços
externos e a utilização de alguns parâmetros como o followedBy que não funcionou
como descrito na documentação do framework.
No mais o framework se comportou como o descrito e obteve resultados
satisfatórios até agora.
Referências
1.
Abiteboul, S., Benjelloun, O., Milo, T.: The Active XML Project: an
Overview.ACM (0YY).
2.
Abiteboul, S. et al: Active XML Primer.
3.
Abitebou, S. et al: Active XML: Peer-to-Peer Data and Web Services
Integration.
4.
Baumgarten, J.: Active XML User Guide
5.
Nicolaas Ruberg, Gabriela Ruberg1, Ioana Manolescu: Towards cost-based
optimization for data-intensive Web service computations
Processamento de Documentos Ativos XML
19
6.
Abiteboul, S. Et al: Construction and Maintenance of a Set Of Pages of
Interest (SPIN) using ActiveXML
7.
Abitebou, S. et al: Lazy Query Evaluation for Active XML.
8.
Stefan Saroiu, P. Krishna Gummadi and Steven D. Gribble: “A Measurement
Study of Peer-to-Peer File Sharing Systems” (2002).