A large amount of todays business data, exchanged on the internet, is in XML-format.
And naturally, there is a demanding need for a proper database-connectivity adapter,
for storing and retrieving mostly complex XML-encoded e-business-data and documents.
This is the reason for this research work.
In general, data is encoded with an encoding language and usually appears in conjunction with structural description.
The encoding language used here is XML and the language used for the structural descripiton is XML-Schema.
Therefore, in this context, XML-Schema is a meta-language for describing other languages(vocabularies).
The basic idea of the UF XML-relational database adapter (UFX-RDB) is an adjustable but multipurpose
persistency mechanism for XML data.
XML-data is based on specialized vocabularies (structural descriptions) given in XML-Schema.
The design of UFX-RDB is made to enable easy adaptility to various application-areas, application-scenarios
and application-projects.
XML-Schema's structural elements are conceptual similar to object-oriented typing.
Therefore the idea of reusing object-relational database technology suggests itself.
ANd this is the reason why conceptually UFX-RDB is an extension of the UFO-RDB adapter.
The UFX-RDataBase-adapter provides
a vendor-independent adapter for mapping structual information given in XML-Schema
first to object-relational structures given as UFORDB's object-relational schemas and from this
to pure relational structures given as relational db-schema of the underlying used DB-System.
While doing so the UFX-RDataBase-adapter stays fully independent from the used XML-Vocabulary.
Therefore it can be used for ANY KIND of XML-Schema based data.
ARCHITECTURE /
FEATURES
The UFX-RDB database adapter ist based on several basic ideas.
Reuse of reliable object-relational technology (UFO-RDB)
Fully independend from used XML-Vocabulary (= specific semantic data-model),
...
SOFTWARE
NOTE: The software-copy downloadable here is for noncommercial evaluation-use only.
By using the software contained in the distribution packages you agree
to a non-commercial evaluation-licence.
This non-commercial evaluation-licence grants everybody interested
the right to use this software but WITHOUT ANY WARRANTY "AS IS"
for non-commercial purpose only.
Any commercial use, redistribution or
bundling with other software is prohibited
without explicit permission.
The development of this software package is/will be continued and additional functionality will be added to widen application-areas and make it easier to use.
version
comment
0.1.02
next milestone, not yet public, in work, not released yet
0.1.01
more exact XML-Schema support
0.1.0
first public version
The UFXRDB-Protoype requires the UFORDB-Package to work properly
XML-Schema itself is defined in XML instead of using an own language as done in contrast with DocumentTypeDefinitions (DTD).
Therefore any XML-Schema always is a valid XML document with a cyclic-free tree-structure. The schema-for-schemas is specified in XML-Schema Specification Part1: Structures .
The development and introduction of XML-Schema was also caused by the poor data-typing- and data-encapsulation-capabilities of the predecessor: XML in conjunction with DTDs. The main improvements of XML-Schema over DTDs are:
- support for namespaces
- a rich set of primitive datatypes including all usual types and the additional possibility to specify the domain of types
- definition of complex elementtypes by composition of existing primitive and other complex types
- definition of new elementtypes on basis of existing ones (inheritance) with extension and restriction mechanisms
- explicit grouping mechanism for attributes and elements
Through the use of namespaces a XML-Schema can contain elements defined in other XML-Schemas or can contain different elements with identical names inside one XML-Schema if they exists in different namespaces. This way, using namespaces, supports rational reuse and data-encapsulation as known simmilar from object-oriented programming languages.
Any XML-Schema is constructed of up to twelve components/blocks that make up the the abstract data model of the schema. These twelve components/blocks can be split in three groups:
- Primary components: element and attribute declarations, simple type and complex type definitions
- Secondary components: attribute groups, identity constraints, model group definitions and notation declarations
- Helper components: cannot be named or independently accessed
The basic building blocks of any XML document are elements and it`s attributes. Therefore declarations of elements with attributes are also the basic components for XML-Schema. While gobal elements are declare within the outermoust schema-element of an XML-Schema local ones are declared inside a complex type or element group. The name and type of an element is specified in attributes. Therefore the basic function of an element declaration is the association of its name with a type. A simple example could look like :
Further there are possibilities to embed a complete XML-Schema into another by means of the include-directive, or embed parts of another XML-Schema by means of the import- or redefine-directives. The include-directive is used in the UFX-RDB adapter for the important task of importing an identity-structure XML-Schema.
Even if not all available constructs of the XML-Schema specification could be covered, it should be enough to comprehend the meaning of the following section(s).
JAXB
The JAXB specification standardize how to access and use a XML document (a file containing XML-tagged data) using the Java programming language, without considering any persistency requirements. But JAXB is aware of XML-Schema as the structural description language for the data contained in XML documents.
Moreover JAXB introduces a new API for reading, writing and manipulating of XML documents by means of the Java programming language while avoiding the tedious and error-prone use of the lowlevel SAX parser API or the somewhat higher-level DOM parse-tree API.
The Binding Framework
In general the JAXB specification maps the components of a XML document to in-memory objects instanciated from specifically created Java-classes. JAXB uses the expressions Unmarshalling, which means the process of reading a XML document and constructing a tree of content objects, Marshalling, which is the inverse of unmarshalling and Validation, which means the mechanism of verifying that all constraints expressed in the source schema hold for a given content tree.
But prior to execution of any un-/marshalling or validation by the JAXB binding framework, the framework needs to know how to do this for any XML-Schema. Therefore always a binding compiler must be used to "bind" a XML-Schema to a set of content Java language constructs (i.e. interfaces+classes). This binding is described by a JAXB binding language, enabling also additional customization of this mapping where required. The interconnection of the mentioned parts can be seen from picture 1 below.
picture 1 - JAXB roundtrip overview
The JAXB specification introduces two new java-packages containing application programming interfaces and classes representing the JAXB API. Implementations of the JAXB must fulfill these API interfaces.
The JAXBContext class provides the client's entry point to the JAXB API. It holds references to the XML/Java binding information necessary for managing it and contains methods for the creation of instances of the interfaces Marshaller, Unmarshaller and Validator.
The interfaces mentioned until now suggests how the content of an existing XML document can be filled into a properly created tree of Java object instances. But it does not suggest how the opposite direction works. In fact a Java-application can create an XML document in two ways using a JAXB implementation:
The first alternative is that the application itself creates a tree of Java objects by instanciation of the Java classes previously generated from the binding compiler for a XML-Schema and afterwards pass this object-tree (representing the document) to an implementation of the Marshaller interface.
The second, and for our purpose more important alternative, is the use of a factory mechanism. Each binding generated for a XML-Schema from the binding compiler contains a class ObjectFactory. This Factory class contains methods to generate objects for each of the schema-derived interfaces and classes. This means that any application can use a standardized mechanism using the constant ObjectFactory class instead of instanciating java objects itself from always different Java classes which are derived from the actually used XML-Schema for the actual application.
JAXB concepts for XML to Java mapping
The Java Architecture for XML Binding separates the conceptual mapping from implementations by the use of Java interfaces. The components of XML-Schema are mapped to Java interfaces making up the content-model. It's a matter of a JAXB implementation to provide/generate implementing classes fulfilling these interfaces. We will see that this is especially usefull for our aims to store data contained in the instanciated classes persistent.
Spoken simple, the output of a JAXB binding compilers run is a Java package representing the XML-Schema. The name of the package ist either derived directly from the XML namespace URI, or specified by a binding customization. The package is at least made up of a set of Java content interfaces, a set of Java element interfaces and an ObjectFactory class. While the content interfaces represent the content model(i.e. complex types) declare in the XML-Schema, the element interfaces represent the elements declared in the XML-Schema.
Simple types and attributes either of a type or an element when declare in a XML-Schema are mapped to Java properties (i.e. attributefields) in content or element interfaces. This is always done in conjunction with a set of access functions (i.e. setter/getter methods).
As specified also in [JAX02] several property models can be used to represent the different simple types possible in a XML-Schema.
All Java properties must have a base type, which may be a Java primitive type (e.g., int) or a reference type according to the XML-Schema built in types or a user derived type within the considered XML-Schema.
On the lowermost level JAXB specifies how the 45 XML-Schema built in data-types are mapped to primitive Java types. For example xsd:string is mapped to java.lang.String, xsd:integer is mapped to java.math.BigInteger, xsd:int is mapped to int, xsd.long is mapped to long ... see [JAX02] section 5.2.2 Atomic Datatypes.
RELATED MASTERTHESIS's AT UNIF
Student
Thema
Abu-Baker, Ashraf
Schemaevolution in XML-Datenbanken
Aigner, Stefan
OLAP - regelmäßige und automatisierte
Erstellung von multidimensionalen Informationsmatrizen mit zugehörender
Datenanalyse