Orient
the light object server
Main
User Guide
Just
and Enterprise Editions - version 1.0
Copyrights 2000
– Orient Technologies
All rights
reserved
Last revision
on 26 April 2000.
Document Disclaimer
Information contained in a manual is subject to change
without notice. Please check the web site (see Download Information) to make
sure you have the most recent information.
Download Information
For download this document go to http://orient.freeservers.com and go to Orient ODBMS product, then select
the Documentation page
Trademarks and Service
Marks
·
Java is a
trademark of Sun Microsystems Inc.
·
Microsoft,
Windows, and Windows NT are either registered trademarks or trademarks of
Microsoft Corporation in the United States and/or other countries.
·
UNIX is a
registered trademark in the United States and other countries, licensed
exclusively through X/Open Company Limited.
All brand names and product names are trademarks or
registered trademarks of their respective companies.
Table of Contents
1
Introduction
Orient is
an ODBMS, namely an Object Data Base Management System.
An ODBMS is
quite different from a Relational DBMS (RDBMS) and Object Relational DBMS
(ORDBMS) because it can handle natively objects with no conversion between user
language and dbms.
The Orient
interface is compliant with the ODMG 3.0 worldwide standard (see http://www.odmg.org for more information).
The Orient
architecture is based on objects. Objects are the unit of exchange among client
and server components.
For this
reason Orient can be classified as an Object
Server. The typical architecture of other ODBMS products is page based,
thus they are called Page Server.
Page Server
Basilary in
the Page Server architecture the server component is just a “pages provider”
that loads data pages from the storage media and send it to the clients
applications that made the requests.
Thus the
server don’t know nor how many objects are in a page neither yours layout. All
the logic is on the client side: navigations, queries,
marshalling/unmarshalling happens only on the client side.
This
approach results in a less-loaded server process to support apparently more
clients concurrently than an Object Server.
Apparently
because in a page server queries are much expensive because the server sends
all data pages across the network to the clients that process the matches.
Generally
Page Servers lock the entire pages instead of objects resulting in conflicts
when multiple clients lock objects in the same page.
Object Server
The
architecture of Object Servers is more likely to the RDBMSs, because the server
component plays a more important rule. The server handle objects and not pages.
Thus the server can make queries and other operations directly on objects.
In this way
client queries run on the server side with low network traffic, resulting in
superior performance requesting less resources.
An Object
Server locks only the objects obtaining better concurrency.
Page Server vs
Object Server
Generally
an architecture is not better than others: it depends on the user application
scenario.
We believe
that an Object Server is more flexible than a Page Server and can result the
best choice for the major part of use cases.
2
Editions
Description
In the Just Edition the client and
server are one process. The user application links the Just dynamic library
obtaining a process that performs (without need of Dynamic Server component)
all operations of storage, retrieval, queries, etc.
Concurrent
access
The Just
Edition doesn’t support multiple accesses to the same database by more
processes. The only way to access concurrently at the same database is to build
a multi-threads application with the multi-thread version of Just library.
Scalability
The
interface of the Just Edition is the same of the Enterprise Edition. Thus if
your application needs to scale up, can migrate from the Just Edition to the
Enterprise Edition benefiting of distribution, load balancing and
fault-tolerance.
Components
Engine
The Just
Edition engine is a dynamic library that must be linked with the user
application. There are two version of the library:
·
Single-Threads Library: no thread-safe.
·
Multi-Threads Library: thread-safe and supports multiple
access to the same database from different and concurrent threads into the same
process.
SDKs
The Software
Development Kits of the Just Edition contains the development environment for
building application with the Just Edition engine.
Languages
supported:
·
C++ SDK
·
Java SDK planned
·
Delphi SDK planned
For more
information about programming interface see Programming
interface.
Description
The Enterprise Edition provides the fastest, most
scalable and most flexible architecture for the persistent object management.
In the
Enterprise Edition client and server are separate components that can be
distributed across the network.
The user
application links the client library of Orient that contains the interface to
the server engine.
Balanced
workload
In the
Enterprise Edition the workload is partitioned between client and server
component for the purpose of performance and scalability.
Many
operations on objects happen on the client side (as object creation, updating,
deleting) until a transaction is committed (pessimistic transaction approach). This
is possible because the client knows the database schema and layout of objects
(Reflection).
This
leaves the server unload of many operations that can run on the client
obtaining great scalability with many concurrent clients.
This
differs with the classic client-server architecture of many Relational DBMS
where the client is just a broker of messages between the user and the server
and each operation involves the server side.
Concurrent
access
The
Enterprise Edition supports multiple accesses to the same database from more
clients.
The
Dynamic Server handles the concurrency among clients preserving data with MROW
(Multiple Reader, One Writer) locks.
Components
The
Enterprise Edition is composed by components totally integrated for building
complex and mission-critical applications.
Dynamic
Server
The
architecture of Dynamic Server is multi-threads
for the maximum of performance and scalability. The Dynamic Server component
can support hundreds of clients distributed across the network with low resources.
Its architecture permits to scale up very well on SMP machines benefiting of
multiple cpus.
It’s
possible to build complex scenario with many Dynamic Servers replicated with a
true fault-tolerant and load-balanced access across the servers (see SuperAgent and Replicator).
SuperAgent
This
component permits to the client applications to abstract the physical location
of the Dynamic Server.
SuperAgent registers dynamically all Dynamic Servers across the network and
assigns to each client application "the best" Dynamic Server by an
algorithm.
The
SuperAgent can be mirrored with other SuperAgent components across the network
for a fault-tolerant architecture.
Replicator
The
Replicator component propagates all operations to all Dynamic Server
replicated, saving data in different sites around the network.
With
SuperAgent component client applications can transparently distribute requests
on multiple Dynamic Server replicated with a load-balanced algorithm (see SuperAgent).
SDKs
The
Software Development Kits of the Enterprise Edition contains the development
environment for building application with the Enterprise Edition engine.
Languages
supported:
·
C++ SDK
·
Java SDK planned
·
Delphi SDK planned
For more
information about programming interface see Programming
interface.
3
Programming interface
Now Orient
supports only the C++ language, but is planned the support of Java and Delphi
languages.
The Orient
interface is compliant with the ODMG 3.0 worldwide standard (see http://www.odmg.org for more information).
The Orient
interface permits to handle persistent objects easy because is totally
integrated to the programming language. Application objects are directly
visible by the ODBMS and they are manipulated transparently without conversion.
Orient
ODBMS provides a framework of classes for the database management.
For more
information about the C++ interface, please see the C++ Programming Guide.
Not
available yet.
Not
available yet.
4
Database
There are
two ways to define a database schema:
1.
With
the ODL Compiler tool that reads an
ASCII file containing the database schema in ODMG ODL language and generates
the database and application classes. For more information see Odlcomp tool.
2.
At
run-time using the Schema Manager
classes.
Once you
have defined the database schema your application had to open it before to
work.
To open a
database simply create e d_Database
object and call the open() method
with the name of database to open.
In the Just
Edition the name of the database is the path
of database in the local file system. By default application directory is
taken.
In the
Enterprise Edition you can specify (remote) server
address and database name. In this way Just library will open a connection
with the server until the database is closed.
The
Enterprise Edition supports location
transparency feature using SuperAgent
component. Client application had to specify just the name of database and
SuperAgent will search the best server that contains the database required.
Not
available yet.
5
Tools
Introdution
Odlcomp is
the ODL compiler to generate database schemas. Odlcomp reads the source file
containing database schema and generate the database and language structures.
Syntax
The odlcomp
syntax is: odlcomp <database_schema.odl>
<database_name>
Where:
<database_schema.odl> is an ASCII file that
defines database schema in the ODL language. If the ODL file is not present in
the current directory you had to specify the path too.
<database_name> is the name of
database. This parameter can specify the destination path of database files.
Note
The path of
database and its segments is stored inside the database.
If a relative
path is specified (i.e. ./database/business), then the application
executable must be resides forever in the directory.
Header
files are generated in the local directory where the odlcomp is called.
Language supports
Now odlcomp
supports only C++ language. It generates database and C++ classes definition.
Example
[NOTE: This example is taken from the demo
directory of the Orient distribution.]
C:\business> odlcomp C:\business\business.odl C:\business\database\business
This
example compiles the business.odl file contained in the C:\business
path generating header files in the local directory (C:\business) and business
database in C:\business\database path.
The user
writes the application code implementing the classes defined in the odl
file. Usually each class is defined in a header file <class>.h and
implemented in a source file <class>.cpp.
Thus the
user task is to implement the code of the classes generated by odlcomp (from
odl file).
The client
application will link the Orient libraries and will use the database
created by odlcomp.
