Re: Fwd: Passing XML documents via the xmlKey

[Marcel Ruff <ruff at swand.lake.de>]

Hi Brett,

> >I sent this message yesterday, but never saw it posted from the xmlBlaster
> >list server.
> >
Yes, i had the same problem last week,
we need to have a look at our majordomo.

> >  I am working on a project that uses a JMS service to allow
> >client applications to publish and subscribe to XML documents.  We would
> >like to be able to select on the XML document itself using a simple XPath
> >expression, but JMS doesn't have this ability.
> >
> >From my initial investigation of xmlBlaster it looks like we would be able
> >to publish and subscribe to XML documents by packaging the document in the
> >MessageUnit.  For our purposes, the message key (i.e. xmlKey) would be the
> >data we were trying to publish and the content part of the message would be
> >null or nothing.  This purpose is different from the original design, but
> >does anyone know if this wouldn't work.
This is perfectly OK.
Usually if your are passing *huge* xml documents, you
would use the content and index it with some xmlKey meta data.
But passing everything in xmlKey is OK as well.
(This is related to the discussion of 'xml data' versus 'xml document').

The only drawback for the moment is that the xmlKey is not cached,
and you need enough RAM memory to handle everything.

Manuel Kron is currently working on a persistent DOM with caching
for xmlBlaster. This should solve this problem in the near future.

We have discussed to implement a mime based plugin for full text search
of the *content*.
For example
"text/plain" content search could be implemented with regex search,
"image/gif" could allow to query the header fields or image size etc.,
"text/xml" could allow a XPath query,
"application/x-java" could allow OQL.
Everybody could easily plug in his query handling for a mime type.


> >
> >Would there be any performance problems with implementing a solution using
> >these ideas?
It depends what your performance expectations are.

XML parsing is not too expensive, and it only happens on
a publish(). The xmlKey is from then on kept as a DOM in memory
allowing XPath queries.

If your xml messages don't change too often, it should not be a
performance
issue to send the whole document as xmlKey.
You can also think of sending only a link to the huge document,
and any message update only contains the patch to the previous
version (cvs or diff/patch style, the whole Linux Kernel source
is handled like this).

> >  Also, I haven't looked at the code, but how difficult would
> >it
> >be to add the capability of passing the "xmlKey" as an XML document rather
> >than just a string.  I assume that once the xmlBlaster server receives the
> >message it translates it into the appropriate XML document so that the XT
> >processor can perform the XPath query.
Yes this is right. 
But passing a DOM object hierarchy serialized over a socket
(CORBA/RMI/raw)
is probably slower than passing a string and parsing it server side.

Passing the DOM document would be possible if the client is a Java
application and the client runs in the same JVM as xmlBlaster.
In this case (no distributed client/server) you would probably not need
any MOM.
And xmlBlaster currently has no such native interface implemented.
If this makes sense for some real day cases,
we could think of design this feature into xmlBlaster.

Python, Perl etc. would always prefer to send a string i believe.
The same may be true when accessing xmlBlaster with xml-rpc, SOAP or
email.

regards,

Marcel



-- 
Marcel Ruff
ruff at swand.lake.de
http://www.lake.de/home/lake/swand/
http://www.xmlBlaster.org