SHORE Project Home Page
SHORE - A High-Performance, Scalable, Persistent Object Repository
Document Contents:
See Also:
The objective of the SHORE project is to design, implement, and
evaluate a persistent object system that will serve the needs of a wide
variety of target applications including hardware and software CAD
systems, persistent programming languages, geographic information
systems, satellite data repositories, and multi-media applications.
Shore expands on the basic capabilities of the widely-used
EXODUS
Storage Manager (developed at Wisconsin, funded by
ARPA ) in a number of
ways including support for typed objects, multiple programming
languages, a "Unix-like" hierarchical name space for named objects, and
a Unix-compatible interface to objects with a "text" field. This
interface is intended to ease the transition of applications from the
Unix file system environment to Shore as existing Unix tools such as vi
and cc will be able to store their data in Shore objects without
modification (basically a Unix file becomes either a single Shore
object or the text field of a more complex object).
SHORE is something of a hybrid system by nature, inheriting
characteristics both from object-oriented database systems and from
file systems. This section briefly describe the basic features of
SHORE. The paper,
Shoring Up Persistent Applications,
describes SHORE in much greater detail.
SHORE has three major goals:
- Scalability
- Support for hardware and language heterogeneity
- Support for existing, file-based applications
When the SHORE project began 3 years ago, these goals were unique
among the research and commercial OODBMS community. While the
ODMG effort
has also concentrated on providing some degree of support for language
heterogeneity (which, in turn, facilitates hardware heterogeneity),
SHORE remains distinguished by its focus on scalability and support
for applications that depend on the Unix file system for persistent
storage. Furthermore, since the SHORE data model (SDL) is basically
compatible with the ODMG data model (ODL),
we expect that much of the technology that we develop can eventually be
transferred to the commercial sector.
Scalable Architecture
SHORE's software architecture is unique is several ways.
First, SHORE uses a symmetric, peer-to-peer distributed
architecture. In SHORE, every participating processor runs a
SHORE server process whether or not the processor has SHORE data disks
attached. The software has been designed to be scalable;
it can run on a single processor, a network of workstations, or
a large parallel processor such as the Intel Paragon or IBM SP1/2.
This design is in contrast to the client-server architecture
used by EXODUS and all the OODBMS vendors. While a client-server
architecture is fine for a design environment such as is typically
used in software and hardware CAD efforts, it is not scalable.
The second unique feature of the SHORE architecture is its notion
of a ``value-added'' server. By structuring the software that runs
in the server with extensibility in mind, it is relatively simple for
users to build application-specific servers. For example, the
Paradise project
is already using the SHORE server to build a geographic information system for
NASA's
EOSDIS project.
We feel that these two unique pieces of technology will play a
important role in a variety of future research and commercial endeavors.
For example, the digital libraries of the future will almost certainly
depend on the availability of scalable, persistent object technology.
Such systems are going to store, retrieve, manipulate, and transmit
objects containing video and pictures as well as text. While
current OODBMS products could be used, these systems are oriented
toward dealing with gigabytes, and not terabytes, of data.
Customizability is equally important. The indexing, retrieval,
and query processing mechanisms needed for a digital library
are very different from those required for a geographic information
system.
Language and Hardware Heterogeneity
Objects in SHORE are typed. SHORE provides a single, language-neutral
type system that is used to define the types of all SHORE objects.
This type system is embodied in the SHORE Data Language (SDL),
which is the language in which SHORE object types are defined.
SDL enhances the OMG data model IDL with support for database
features such as bulk types (e.g., sets and lists) and persistence.
The provision of typed persistent objects simplifies the task of
supporting heterogeneous hardware environments and makes it feasible
to support access to persistent objects from multiple programming
languages, which is a key objective of the SHORE project.
As mentioned earlier, SDL is quite closely related to ODL,
the language-neutral object type definition language that was
recently proposed as a standard by the OODB vendor consortium ODMG.
In terms of its emphasis, however, ODMG has largely concentrated on
providing a standardized interface to existing C++ oriented OODBs.
Our focus is on support for inter-language object sharing within
a large name-space of objects.
Support for Existing, File-based Applications
A major goal of SHORE is to enable applications that currently
use untyped, byte-oriented files for their persistent data,
flattening and un-flattening their data each time it is accessed,
to stop doing so.
Such applications should be able to store their data as typed, structured
objects for more convenient, type-safe, intra- and inter-program data sharing.
Our ultimate hope is that SHORE will displace byte-oriented
file systems such as the Unix file system.
SHORE provides two major services from a file system standpoint. First,
to support object naming and space management in a world with many
persistent objects, SHORE provides a flexible, tree-structured,
Unix-like name-space in which all persistent objects are reachable,
either directly or indirectly. Doing so gives SHORE users
a familiar framework in which to register individual
persistent objects (termed "registered" objects), the roots of
large persistent data structures, or bulk sets of unnamed objects (termed
"anonymous" objects). The realization of this framework involves
several different kinds of SHORE file system objects, including
directories, pools (which are files containing anonymous objects),
symbolic links, and cross references.
SHORE provides two mechanisms to ease the transition of legacy Unix
applications such as compilers, editors, and CAD systems from
traditional byte-stream files to SHORE.
First, for applications that can be re-linked, SHORE provides a standard
Unix-compatible file system interface (e.g. open, close, read,
write, mkdir, chdir,.).
In order to make access to SHORE objects via Unix file system calls
possible, the definer of a SHORE object type can optionally designate one
variable-length byte string or character string attribute of the object as
being the object's "Unix data". Programs that attempt to read an object
through SHORE counterparts of the Unix file system calls
will only see this portion of the object. For legacy programs that
wish to do so without being re-linked, it is possible to NFS-mount a
SHORE file system and access the Unix data
contained in its objects directly. This makes it feasible for both
new and old applications to access the same set of objects.
While old applications can only access the "Unix data" component
of the object, new applications can define and access other, more
structured, attributes of the object.
Below is the latest time table for the release of SHORE.
These dates are approximate and subject to change.
If you have any questions, contact
shore_support@cs.wisc.edu.
Beta Release (0.9)
On May 3, 1995 we had our first beta release.
Beta Release (0.9.3)
The second Beta-rlease of Shore (version 0.9.3)
is now available (Sept 18, 1995).
It includes improved documentation, more complete
implementations of many SDL features, many bug fixes, and ports to
Solaris, HP-UX, Linux.
Version 1.0
The first general release is expected at the end of 1995.
There are two Shore-related mailing lists:
shore_support@cs.wisc.edu
and
shore_all@cs.wisc.edu
.
shore_support@cs.wisc.edu
This mailing list reaches the Shore development team.
It is for use
by Shore users to submit questions, comments, and bug reports to us.
You cannot subscribe to this mailing list.
shore_all@cs.wisc.edu
This is a mailing list for users of (and those interested in) SHORE.
This list is managed by the listproc software at the UW-Madison
CS department. It is currently unmoderated, but in the unlikely
event that it gets cluttered with junk mail we will moderate it.
mail messages. If you are interested in the list, but your mailbox is
already too cluttered, you can sign up for weekly digests. See below
for more information. More information about the list will be sent
when you subscribe.
Purpose of shore_all
- Notifying interested parties of new releases and other changes in the Shore ftp archive
- Requests for help from other users
By default, replies will be sent only to the sender, rather than being
posted to the entire list. If you want the entire list to see your
reply, just copy the reply to shore_all.
This list is an public mailing list. Thus, anyone may
subscribe to it. Only subscribers may post to the list. The existence
of this list is shown in the listing returned by listproc when
it processes a LISTS request. When you subscribe, your
subscription is "concealed" by default. That is, other subscribers
cannot obtain the membership list from the listproc system.
Subscribing to shore_all
To subscribe or to change your subscription, you must mail a special
message to: listproc@cs.wisc.edu.
- To subscribe, the content of the message should look like this:
subscribe shore_all
- To receive weekly digests (rather than individual messages), send
this along with your subscription (or send it in a separate
message):
set shore_all mail digest
- To un-subscribe, the content of the message should be:
unsubscribe shore_all
- To get help on the list processor, the content of the message
should be:
help
Last Modified:
Mon Mar 18 10:41:39 CST 1996
Nancy Hall
/ nhall@cs.wisc.edu.
Footnotes:
- ... compatibility with ODL
-
SHORE and ODMG concurrently decided to use the OMG data model
IDL as the starting point for their data models. Hence SDL and ODL
are very similar to one another. Once ODL stabilizes
we can convert SDL to be 100% compatible with ODL.