OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XML Storage Architecture

[ Lists Home | Date Index | Thread Index ]
  • To: xml-dev@lists.xml.org
  • Subject: Re: [xml-dev] XML Storage Architecture
  • From: Farrukh Najmi <farrukh.najmi@sun.com>
  • Date: Sun, 14 Sep 2003 19:16:00 -0400
  • In-reply-to: <3F64043D.4090704@sun.com>
  • References: <3F64043D.4090704@sun.com>
  • User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

Jason Kohls wrote:

> We're looking at a content management system, which stores all of the 
> content/metadata in a single, 1 MB XML file on disk or as separate 
> records (for each parent element) in a two-field table in SQL, 
> out-of-the-box. Based on our rough content estimates, however, we can 
> see this file growing to over 100 MB easily.  The CMS provider says 
> that anything over 30 MB should use the SQL backend.
> The one thing that we do not like is the schema/data model (or lack 
> of) for the SQL storage option.  Coming from the relational camp, this 
> seems odd to us, and even on disk, hierarchically, it seems to make 
> more sense to break up this single XML file into smaller files (per 
> parent element) in a directory structure with an index.
> ...But then again, you guys are the experts :)
> Can anyone see any problems with this storage architecture from a 
> performance/stability/scalability standpoint?

Hi Jason,

You might consider using an ebXML Registry for your application. An 
ebXML Registry provides a standards based Content Management solution 
where a repository stores any type of content (including XML) and a 
registry stores standardized metadata
in an XML format. The registry provides classification of content using 
user defined taxonomies, association of content using user-defined 
associations. The registry is queryable using SQL-92 syntax as well as 
an XML filter query syntax. Automatic
content validation improve data quality, while automatic content 
cataloging improve data discovery.

A flexible content-based event notification capability allows clients to 
be notified when content of interest changes within the 
registry/repository. A loosely-coupled federation model allows different 
registry/repositories to cooperate with each other, share data and 
seamlessly inter-connect.

Security in an ebXML Registry provides authentication of clients based 
on digital signatures and authorization based upon flexible XACML Access 
Control Policies. Fine grained Role Based Access Control (RBAC) is fully 
supported via deployment specific roles and groups.

All of the ebXML Registry functionality is available over HTTP, SOAP or 
ebXML Messaging interface.

If you are interested in learning more then please join the ebxmlrr-tech 
mailing list at:


and post any questions on ebXML Registry there.  Thanks.


Related  Links:

[1] Project ebxmlrr: A Royalty Free Open Source Implementation of ebXML
Registry and JAXR (expecting major new release on Sep 15, 2003)

[2] http://www.freebxml.org

[3] ebXML Registry 2.1 Specifications (Approved OASIS Standard)

[4] ebXML Registry Technical Committee

[5] ebXML Registry V3 Specifications (interim TC approved version)

[6] ebxmlrr Presentations
Note: sxi format require free software from:



[7] ebXML Registry Presentations

Note: sxi format require free software from:


(detailed technical presentation)



[8] Java API for XML Registries



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS