home list archives users mailing list
 

Subject: Re[2]: Deploying unsupported XML DBMS within OGSA-DAI

Date view Thread view Subject view Author view Attachment view

From: Mike Jackson (michaelj@epcc.ed.ac.uk)
Date: Aug 30, 2006 16:49

Hi there,

On Wed, 30 Aug 2006, Artem Y. Pervin wrote:

> Thank you for answering my message.
> If you don't mind I would like to clarify couple of moments.
>
> MJ> With regards to XMLDB comformance we don't require one as far as I know,
> MJ> we just take whatever the database-specific drivers give us. If it is of
> MJ> use then our supported XML data resource, eXist, has a driver that has
> MJ> level 1 conformance.
> I wonder how OGSA-DAI user can work with XML data resource with
> anything different from level 1 conformance of XMLDB:API? As far
> as I can understand from XML:DB API specifications level 0 doesn't
> give much abilities to work with XML resource (no XPath, no XUpdate).

In that case this would restrict the XML activities a user could use with
the XML resource. Our XML activities use XMLDB for collection and resource
management, XPath, XUpdate and also XQuery. If a driver doesn't support
these then neither do we and an attempt to run an activity would fail.

> MJ> There are two ways you can go:
> In this situation I would like to choose the easiest (and the fastest)
> way. But for me it's not very clear what amount of work required for
> these particular cases. Could you, please, help me to estimate these
> ways?

This is up to you to identify. To me, for example, driver development
would seem to be the most complex, but for you, you state it could be
fairly easy.

> MJ> -1-Implementing an XMLDB driver for your database. You should then just be
> MJ> able to use your database with OGSA-DAI. You'd deploy an eXist data
> MJ> resource (currently the only type of XMLDB data resource we support)
> MJ> but just provide the connection URL for your database and the name of
> MJ> your driver class instead.
> It seems that creating XMLDB driver is fairly easy, though it
> requires to implementing several java-interfaces from XML:DB API. But the
> addressing issue is totally unclear for me. The database I`m working
> with doesn't have any URIs for addressing collection. And it doesn't
> have any special web-server (like Exist and Xindice both have). I`m
> not sure if it's really required by XML:DB API, I could find anything
> about it in specification.
>
> There is also an xmlrpc-server in Exist who is responsible (if I`m not
> mistaken) for processing queries to the collections. Could you,
> please, prompt to me is it necessary for my case to have such xmlrpc-server?

Sorry, the team has no experience of XML:DB driver development. We just
use the ones provided with the XML databases we've used (eXist and
Xindice). You could inspect the source code for these for hints.

> MJ> -2-Write a data resource accessor for your database - our user doc
> MJ> provides a tutorial with instructions on how to write a data resource
> MJ> accessor. A data resource accessor manages communications with your
> MJ> database through any means you wish. However, using this approach you'd
> MJ> also have to customise our XML activities to work with your data
> MJ> resource accessor - currently they work only with accessors that
> MJ> provide XMLDB connections.
> Yes, I`ve already tried myTemperatureSensor data resource accessor
> from tutorials and it works fine, though I`ve failed to use any
> activity with this resource (see test.log attached).

That's probably why it didn't work. You have slotted the temperature data
resource into OGSA-DAI but aren't pulling any data out. As the tutorial
explains you need to develop some activity that pulls the temperature out,
(the same way that, for example, JDBC data resources have activities that
pull the data from them).

With respect to randomSample not working - as stated in your log file - if
you don't pipe any data into it from another activity then it has nothing
to sample and will not work. See the activity doc for full details of how
to use this activity.

The zipArchive didn't work because you specified it wrong. There was a bug
in the user doc - data cannot be provided inline in a zipEntry. However
the following example works for me:

<?xml version="1.0" encoding="UTF-8"?>
<!-- (c) International Business Machines Corporation, 2002 - 2005.-->
<!-- (c) University of Edinburgh, 2002 - 2005.-->
<!-- See OGSA-DAI-Licence.txt for licencing information.-->

<perform
    xmlns="http://ogsadai.org.uk/namespaces/2005/10/types">
         <documentation/>

<dataStore name="bangles">
   <item>DebbiePetersen</item>
   <item>VickiPetersen</item>
   <item>SusannaHoffs</item>
   <item>MichaelSteele</item>
   <itemCursor name="banglesOutput"/>
</dataStore>

<zipArchive name="transform">
   <comment>
     This archive contains my data.
   </comment>
   <settings checksum="adler32" level="9"/>
   <zipEntry from="banglesOutput"/>
   <archivedOutput name="myArchivedOutput"/>
   <metadataOutput name="myMetadataOutput" />
</zipArchive>
</perform>

> Anyway can you, please, point what exactly XML activities should I
> customize in this scenario?

Any ones which provide the functionality you want - if you want to be able
to create, list and remove collections then modify
xmlCollectionManagement, if you want to run XPath queries then modify
xPath etc.

> MJ> For our information what type of XML database are you using?
> It's NXD DBMS. Name's Sedna.

OK thanks,

Cheers,

mike

Date view Thread view Subject view Author view Attachment view