Developed at the

Polish-Japanese Institute of Information Technology

Chair of Software Engineering

SBA and SBQL home pages

© Copyright by ODRA team, © Copyright by PJIIT





ODRA – Object Database for Rapid Application development

Description and Programmer Manual




by Kazimierz Subieta


1. Introduction

Integrated applications build on top of existing data and service resources that are under control of various institutions tend to be very complex. The complexity is caused by many reasons that can be subdivided into the following four groups:

  • Distribution of data and services: various geographical locations, different servers. Access to them may require different communications protocols.
  • Heterogeneity of data and services: usually data and services have existed before the decision on building an integrated application is made. Hence they can reside on different hardware, work under different operating systems, are supported by different database management systems, can be designed according to different conceptual models and can use different representation formats. Heterogeneity concerns also diverse ontologies that are used for classification, description and discovering of data and services.
  • Redundancy of data and services: in many cases data and services stored at different servers contain a lot of redundancies, for instance, a citizen register and a social security register can contain the same citizen names. In some cases the redundancy (data replicas or mirrors) is consciously introduced as a method of increasing availability or as a method to improve security or stability of services.
  • Fragmentation of data and services: in many cases collections of data are stored in fragments on different servers, for instance, citizens data concerning particular sites are stored in local administration offices. Similarly, a service that can be on some abstraction level considered as a whole (e.g. a life event such as getting married) is fragmented into several particular services implemented on different servers.

The complexity of building integrated applications has direct impact on basic features of software development processes and on operational features of software products. This impact may concern the following features:

  • High development cost.
  • Unacceptably long development time.
  • Functionality of the software product, which can be too limited for the given business goals.
  • Quality of the software product.
  • Quality of services measured as a degree of user satisfaction.
  • Flexibility and maintainability of the final product. Low flexibility and maintainability can be dangerous because usually internal or external requirements to the software product and its operation are permanently changing.
  • Openness of the product to the development of new applications based on the previous conceptual frame.
  • Openness of the product to new data and service sites and to new kinds of end users.
  • Scalability of the product expressed in terms of volumes and diversity of data, number and diversity of services, number of concurrent users, etc.

Coping with the software complexity requires a systematic approach. It is commonly believed that the complexity can be reduced by the following basic software engineering principles:

  • Higher abstraction level of software design and manufacturing, isolating the application programmers and users from physical details of data and service access, data independence, i.e. the design and management of data independently from application programs.
  • Decomposition of the software processes and software itself into a hierarchy of isolated pieces that share only well defined interfaces.
  • Reuse and standardization. Reusable software parts can be considered as encapsulated units that can be used in many places without the necessity of understanding their complex interior. Standardization is the basis for software development culture allowing for easier communication between various groups of developers and for physical connection of software units that are manufactured independently.
  • Following natural human psychology and mentality. The psychology and mentality include a lot of factors that increase or decrease the software development potential, such as perception of the real world in terms of objects and their behavior, natural tendency to err and to act improperly, limited capacity of human memories, following previously acquired habits and customs, etc.
  • Lean tools and functionality: homogeneous (non-eclectic) software architecture, lack of redundancy of software development tools and lack of redundancy of the software functionality.

Due to the above issues and principles the development of integrated applications that have to work at the top of distributed, heterogeneous, redundant and fragmented resources must be subdivided into activities that are to be done in different time, by different developers teams and by different software development tools. Following CORBA [OMG], we distinguish three kinds of the activities:

  • Creating middleware. At this stage a development team creates the general data and service bus that can be used as a common infrastructure supporting data abstraction and function abstraction. Data and function abstraction means that the application programmers are to be isolated from many details concerning distribution, heterogeneity, redundancy and fragmentation of data and services. The programmers have to behave similarly as the entire data and service resources would reside on their local computers in the format and conceptual shape that is most suitable to their work. They have to works on an unified data and service model using unified and homogeneous programming tools.
  • Creating wrappers and importers of local resources. At this stage external resource, including legacy data and applications, are physically connected to the middleware. Wrappers provide non-intrusive adopting external resources to the data and service model assumed by the developed middleware. Wrappers and importers should accept the most popular data and service resources, including relational databases (supported by various RDBMS), web services, XML files, RDF resources, Topic Maps ontologies, and others.
  • Creating end user applications. After creating the middleware and wrappers and importers the application programmers can use front-end programming tools that allow them to make a complete application without considering details, store and data models, communication protocols, etc. to access external data and services resources. The tools can be used from popular programming languages such as Java.

The object-oriented database management system ODRA (Object Database for Rapid Application development) is developed and implemented as a part of the European EGov-Bus project (Advanced eGovernment Information Service Bus) by the Polish-Japanese Institute of Information Technology in Warsaw, Poland. ODRA is a homogeneous and consistent collection of various software tools, languages, technologies and methodologies that support the above three stages of the development of business and administrative applications. ODRA supports the development of a virtual repository, which supports transparent access to distributed, heterogeneous, redundant and fragmented resources. There are many forms of transparency, in particular location, concurrency, implementation, scaling, fragmentation, heterogeneity, replication, indexing and failure transparency. Due to transparency implemented on the middleware level some complex features of a distributed data/service environment need not be involved in the application code. A virtual repository user gets exactly the relevant data in the shape tailored to the particular use. Thus a virtual repository much amplifies the programmers’ productivity and greatly supports flexibility and maintainability of software products.

Because during the development of ODRA it was impossible to predict the kind of design, development and implementation problems that may arise during the development of various applications, ODRA has been designed as a generic software. It includes the core of an object-oriented database system that supports very powerful object-oriented database model similar to the UML (Unified Modelling Language) data model. For such a powerful datamodel a new query and programming language SBQL (Stack-Based Query Language) has been developed and implemented. SBQL has all the properties of object-oriented programming languages, it is algorithmically and pragmatically complete concerning all the retrieval and updating operations on an object-oriented database. SBQL supports all the programming abstractions that are assumed for this kind of languages, such as procedures, functions, types, classes, methods and transactions. Next abstractions, such as interfaces (specification of public class properties), exceptions, deductive capabilities, dynamic object roles, etc. are under development.

As follows from the above, applications based on ODRA can take into account the authonomy of local servers. Connecting them to the global application related e.g.  to support via Web life events or business events can be non-intrusive in the sense that no impact on (legal or organizational) responsibility of local servers can be assured. However, implementation of life events or business events support via Web may require special databases provided for keeping e.g. the state of the current citizen’s session or recording various auxiliary data related to a particular session. It is almost sure that such databases may require updating of their states. Therefore ODRA does not restrict access to external databases only for reading. All updates of external resources via the ODRA are possible, providing the administrator of a particular application and/or administrators of local servers grant proper privileges for an application and/or for a particular user.

 In contrast to popular object-oriented programming languages, such as Java, C++ and C#, SBQL introduces several new features that make the application development, programming and maintenance much easier. Among them we distinguish the following:

  • Dealing with (nested) collections, including persistent ones.
  • Unification of queries and programming language expressions. Queries can be used within imperative statements and as parameters of procedures, functions and methods.
  • Advanced query optimization methods.
  • Semi-strong static typing system and type checking.
  • Integration with procedures, functions and methods and with updatable object-oriented database views (that are the heart of virtual repositories).
  • Client-server and distributed architecture, with sessions and transactions.

ODRA includes the mechanism of updatable object-oriented views. The mechanism is just responsible for “virtualization” of the object store. Due to virtual views implemented on top of external data and service resources they change their current format to the format required by the middleware. Moreover, because the views can involve communication protocols, they are able to fuse fragmented and redundant resources into a non-fragmented and non-redundant whole. Virtual views can also be used as customization and administration facility that the system administrator can use to customize and restrict the available data and services to a particular application or a user.

Although the ODRA server can store, process and make available (persistent) objects in an own proprietary format (what is necessary for many purposes), the essence of the virtual repository management system (VRMS) implemented as a part of ODRA is the access to external resources, including legacy applications. VRMS ODRA by itself does not limit the kind of access: external resources can be queried and updated as well. VRMS ODRA supports several methods to access external resources.  Among them we list the following (to be extended):

  • A generic wrapper to relational databases. The currently supported RDBMS are: Axion, Cloudscape, DB2, DB2/AS400, Derby, Firebird, Hypersonic, Informix, InstantDB, Interbase, MS Access, MS SQL, MySQL, Oracle, Postgres, SapDB, Sybase and Weblogic. The wrapper transparently translates SBQL queries addressing an object-oriented database into SQL.
  • XML exporter and importer. The facility allows for importing XML files making from them ODRA objects; the facility supports typechecking through the import of an XSD file. Similarly, any information from the ODRA store can be exported as an XML file. (XML importer/exporter is also encapsulated as a separate tool XML2XML that allow for any transformation of XML files.)
  • A generic wrapper to web services. VRMS makes it possible to access any web service, including Enhanced Web Services.
  • A generic gateway to Java libraries. Any Java library can be integrated with VRMS through a generic facility based on Java reflection capabilities.
  • A wrapper to SDDS fast and scalable repositories. SDDS (implemented recently as SD SQL Server) is another software implemented within the eGov Bus project. The description is to be the subject of another document.
  • A wrapper to RDF repositories. VRMS makes it possible to access SWARD (implemented within the eGov Bus project), which is an RDF-oriented virtual interface to relational databases. The wrapper uses RDQL and SQL.  The description is to be the subject of another document.
  • Topic Maps and RDF importers are under development.

To complete the functionality of VRMS it is important how it can be used by application programmers for making eGovernment applications. There are several possibilities:

  • ODRA, plus SBQL, plus external resources present a self-contained application programming environment that make it possible to create fully fledged eGovernment applications in the client-server architecture, including dynamic Web pages created under JSP.
  • ODRA is available as a Java Application Programming Environment.
  • ODRA supports Java oriented JOBC (Java Object Base Connectivity), an interface analogous to JDBC, that makes it possible to access any ODRA resources via SBQL.
  • ODRA supports Web Services built on the top of its programming capabilities.
  • ODRA supports an API to the Adminstrative Process Generator, a software that is made under the eGov Bus project. The description is to be the subject of another document.
  • ODRA can accept Java libraries for the Qualified Signature software developed within the eGov Bus project. The description is to be the subject of another document.

All the software related to ODRA is a Java-based application and requires Sun™ JRE (Java Runtime Environment) to run. The current version uses the 1.6+ version of the JRE. In the following we present the features of ODRA, SBQL, updatable views and other facilities in detail.



Last modified: June 28, 2008