Computer Science Technical Report Archive

USC Computer Science Technical Reports, no. 572 (1994)

(USC DC Other)

USC Computer Science Technical Reports, no. 572 (1994)

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content A Mec hanism and Exp erimen tal System for
F unctionBased Sharing in F ederated Databases
Doug F ang Joac him Hammer and Dennis McLeo d
Computer Science Departmen t
Univ ersit y of Southern California
Los Angeles CA USA
Abstract
A functionbased approac h and mec hanism to supp ort sharing among the com
p onen t database systems in a federation is describ ed In the con text of a func
tional ob jectbased database mo del a tec hnique to supp ort in tercomp onen t in
formation unit and b eha vior sharing is presen ted An exp erimen tal system that
implemen ts the functionbased sharing mec hanism is describ ed its underlying al
gorithms are outlined and its practical utilit y and eectiv eness are assessed This
w ork is couc hed in the framew ork of the RemoteExc hange researc h pro ject and
exp erimen tal system
Keyw ord Co des H Keyw ords Heterogeneous Databases
In tro duction
Ak ey c hallenge to supp orting the in terop eration of database systems is to pro vide fa
cilities for the sharing and exc hange of information units and units of b eha vior across
database system b oundaries T o pro vide a p ersp ectiveon in tercomp onen t information
sharing and exc hange in a federated database en vironmen t w e prop ose a functionbased
viewp oin t In the con text of the curren t RemoteExc hange researc h pro ject w eemplo y
a functional ob jectbased database mo del and dev elop a comprehensiv e mec hanism for
the transparen t sharing of instance ob jects t yp e ob jects and b eha vioral ob jects F ang
and McLeo d In this pap er w epro vide an o v erview of our underlying p ersp ectiv e on functionbased
sharing in federated database systems W e sp ecically presen tan o v erview of the p ossible
sharing patterns using examples from our exp erimen tal protot yp e system based on the
This researchw as supp orted in part b y NSF gran t IRI
Omega Ghandeharizadeh and Iris Fishman et al ob jectbased database
managemen t systems W e address the essen tial problems that are asso ciated with eac h
sharing situation and describ e our mec hanism to supp ort sharing as implem en ted in our
exp erimen tal protot yp e system
Related Researc h
A t the top lev el there are t w o distinct asp ects of functionbased sharing the lo ca
tion lo cal vs remote of the execution of functions and the lo cation of the actual
information units up on whic h functions op erate Researc h in the area of distributed pro
gramming languages has of course addressed issues of the remote execution of functions
whic hma y also b e termed op erations metho ds or b eha vioral ob jects Lisk o v Strom and Y emini The primary concern of this w ork is with the programming of
the functions themselv es eg language constructs comm unication primitiv es for sending
and receiving data etc The lo cation of data used b y these functions is directly co ded
in to the metho ds themselv es
W ork in the area of database systems on the other hand predominan tly fo cuses on the
manipulation of information units this is related to the second main asp ect of function
based sharing Researc h on ob jectorien ted database systems has approac hed the problem
of supp orting b eha vior in the database itself A tkinson Fishman et al
Kim et al Lecluse et al Maier et al When these systems are
extended to a distributed en vironmen t it is the lo cation of the p ersisten t data that
determines the lo cation of the remote execution of the functions Fishman et al
Kim et al Maier et al In the RemoteExc hange approac h functions are
implem en te d without explicit kno wledge of where they will b e executed or where the
data will reside
The F unctional Ob jectBased Con text
The conceptual database mo del considered in this researchdra ws up on the essen tials of
functional database mo dels suc h as those prop osed in Daplex Shipman Iris Fish
man et al and Omega Ghandeharizadeh Our functionally ob jectbased
mo del con tains features common to most seman tic Afsarmanesh and McLeo d Hull and King and ob jectorien ted database mo dels A tkinson suc has
GemStone Maier et al O Lecluse et al and Orion Kim et al In particular the mo del supp orts complex ob jects aggregation t yp e mem b ership clas
sication subt yp e to sup ert yp e relationships generalization inheritance of functions
attributes from sup ert yp e to subt yp es runtime binding of functions metho d o v erride
and userdenable functions metho ds
In our functionbased mo del functions are used to represen tin terob ject relationships
attributes queries deriv ed data and op erations metho ds Three t yp es of functions
can th us b e distinguished
Stor edF unctions A stored function records data as primitiv e facts in the database
Stored functions can b e up dated
Derive d functions A deriv ed function is dened b y a data manipulation language
DML expression The v alue of a deriv ed function cannot alw a ys b e up dated
directly Compute d functions A computed function sometimes termed a foreign function
is dened b y a pro cedure written in some programming language The v alue of a
computed function cannot b e directly up dated
F or the purp oses of this pap er deriv ed and computed functions are treated uniformly and will b e termed computed functions herein
F unctionBased Sharing
Let us assume the existence of a function F whic h can b e shared among comp onen ts
of a federation without loss of generalit yassume F tak es as input the argumen t a
The argumentt yp e can b e a literal ie In teger String or a userdened t yp e
suchas Researc hP ap ers for example Sharing tak es place on a comp onen tpairwise
basis meaning that F is exp orted b y a comp onen t C and imp orted b y a comp onen t C The imp orting comp onen t is called the lo c al datab ase while the exp orting comp onen tis
called the r emote datab ase There are sev eral w a ys comp onen ts Cand C can share the
service pro vided b y F dep ending up on the lo cation where F executes and up on where
its input argumen t a resides ie there are t w o degrees of freedom Atthislev el of
abstraction there are four distinct functionar gument com binations
lo cal function lo cal argumen t
lo cal function remote argumen t
remote function lo cal argumen t
remote function remote argumen t
Up on closer analysis w e can note that it is also necessary to dieren tiate b et w een
stored functions and computed functions A t this ner lev el of gran ularit yw ecan
no w distinguish b et w een a total of eigh t dieren t sharing scenarios
as presen ted in
Figure In this table of Figure Lo cal refers to the domain of the lo cal database
while Remote refers to the domain of the remote database Lo cal ob jects are those
that b elong to the lo cal database while remote ob jects b elong to the remote database
It is imp ortan t to note that a principal goal of our approac h is to pro vide a mec ha
nism for functionbased sharing that mak es the lo cation of a function and its argumen t
transparen t to the user The details of ho w this transparency can b e ac hiev ed are more
fully describ ed in Section but w e will briey highligh t the pro cess here In particular
w e note that the state of a remote ob ject ie its functional v alues alw a ys resides in
Since the argumen t can b e a complex unit of information this is not a limitati on m ultiple argumen ts
can b e handled byanob vious extension of our approac h
Wenowha v e three degrees of freedom
Stored Functions
Computed Functions
base case
argument
function
instance
level sharing
Local Remote
base case
Local
Remote
argument
function Local
Local
Remote
Remote
useful
undefined
related to
instance
level sharing
related to
useful
behavior
sharing
basis for
processing
done locally
local attribute
value for remote
object
processing
done remotely
processing
done remotely
processing
done locally
remote behavior
on local objects
local behavior on
remote objects
Figure Eigh t dieren t situations for functionbased sharing
the remote database but when the ob ject is imp orted to a lo cal database a surrogate
is created for it in the lo cal comp onen t The creation of suc h surrogates is necessary in
order to refer to remote ob jects using lo cal database system to ols without mo dication
F ang et al Since these surrogates are created lo cally the lo cal system is able
to in terpret and manipulate remote ob jects as usual for example when using them as
argumen ts in lo cal function calls Ho w ev er when retrieving the actual state of a remote
ob ject the use of surrogates alone is not sucien t Our approac h exploits the extensible
nature of our ob jectbased database mo del b y rewriting the functions encapsulating sur
rogate ob jects as computed functions These higherlev el computed functions serveas
place holders and retriev e the results of applying the function on the remote comp onen t
where the ob ject is actually stored
Giv en the ab o v e observ ations it is no w p ossible to consider eac h of the sharing sit
uations summarized in Figure W e rst fo cus on stored functions and then turn our
atten tion to computed functions
Sharing Stored F unctions
As a framew ork for analysis consider the a scenario of t w o collab orating researc hers
Researc herA and Researc herB main tain separate databases of journal and conference
publications Figure sp ecies the metadata conceptual sc hemas for t w o example
comp onen ts
Let Researc herA denote the lo cal comp onen t and Researc herB denote
the remote comp onen t
In order to k eep the signature of eac h function as short as p ossible w eha v e omitted the input
argumen t whenev er it is ob vious the result t yp e on the other hand is alw a ys explicitly sho wn
Conference
Journal-
Location():String
Issue#() : Integer
IEEE-Papers
Title(): String
Researcher-A’s Conceptual Schema
Publications
IEEE-Papers ACM-Papers
SIG(): String
Researcher-B’s Conceptual Schema
Research-Papers
Legend
Supertype
Membership
Instance
Papers
-
Author(): String
Remote
Papers
Title():String
Pub_Date():String
Remote Function
Text_Body():String
Title(): String
Pub_Date(): String
Text_Body(): String
Figure Tw o comp onen t databases
The four situations for the sharing of stored functions among comp onen ts can b e
analyzed as follo ws
L o c al function L o c al obje ct
This is what w e term the b ase c ase Both ob jects the stored function F and its
argumen t a reside in the lo cal comp onen t and can b e executed as usual without
an y additional mec hanisms
L o c al function R emote obje ct
In this case F is a lo cal stored function that is applied to remote argumen t aF or
example Researc herAs Author function can b e applied to the IEEEP ap ers
that ha v e b een imp orted from Researc herB As previously men tioned surrogates
are created in Researc herAs database for eac h remote ob ject These surrogates
are collected in a newly created subt yp e of Publications called IEEEP ap ers All lo cal functions for example the functions dened on Publications in Figure op erate normally on the surrogates ie the instances of IEEEP ap ers In the
case of lo cal functions that do not ha vecoun terparts in the remote comp onen t eg
Author new function v alues can b e created lo cally for eac h imp orted instance
As a result eac h imp orted ob ject also has lo cal state in Researc her As database and
can b e altered b y Researc herA without aecting the original ob ject in Researc her
Bs database The three functions T itl e Pub D ate and Text Body that
are sho wn next to Researc herAs IEEEP ap ers in Figure are actually remote
functions dened in Researc herBs sc hema these ha v e b een included in Researc her
As database for completeness Exact details of ho w these functions are created and
in v ok ed are presen ted in Section Pro vided that Researc herA has created new
v alues for Author for eac h of the imp orted IEEEP ap ers she migh t p ose the
follo wing OSQL query in this con text
select AuthorPAP ER S
for each IEEEPaper s PAPERS
R emote function L o c al obje ct
This situation is somewhat meaningless since stored functions only ha v e a mean
ing in the lo cal con text of the comp onentinwhic h they w ere initially created
F or example supp ose that Researc herA who do es not ha vethe Pub D ate func
tion dened in hisher sc hema w an ts to see the publication date of all hisher
ConferenceP ap ers Researc herA w ould rst need to create a new function
and then p opulate it with the appropriate v alues rather than b eing able to use
Researc herBs Pub Date function Ho w ev er when lo oking at this situation from
Researc herBs p oin t of view one can argue that this case is merely the mirror
image of the second case Lo cal function Remote ob ject Rather than exe
cuting Researc herBs function remotely in Researc herAs database one can in
tegrate Researc herAs ConferenceP ap ers in to Researc herBs sc hema create
a new subt yp e ConferenceP ap ersof Researc hP ap ers and p opulate it with
Researc herAs ConferenceP ap ers and execute the Pub Date function lo cally R emote function R emote obje ct
This case serv es as the basis for instanc e level sharing All remote ob jects of
in terest to a comp onen t sa y Researc herA m ust already b e imp orted in to the lo cal
database using surrogates Eac h time a remote ob ject is referenced the surrogate
p oin ts to the remote ob ject and the desired functional v alue is fetc hed using a
remote pro cedure call to the other comp onen t see Section In this situation
see Figure Researc herA migh t p ose the follo wing OSQL query against hisher
sc hema
select PubDate PA PER S
for each IEEEPape rs PAPERS
In order to nd the Pub Date of all remote IEEEP ap ers surrogates for eac h
of these pap ers are used to lo cate the remote pap ers F or eac h remote pap er the
publication date is determined using the remote Pub Date function and the result
of this function is returned to the lo cal database
Sharing Computed F unctions
In order to consider sharing for computed functions consider again the example of t w o
collab orating researc hers Figure sho ws the t w o example comp onen t databases as
b efore but with additional computed functions DviView a dvi format preview er
P ostView a p ostscript preview er The four situations for the sharing of computed
functions among comp onen ts can b e analyzed as follo ws
Title(): String
DviView(dvi) -> screen output
Researcher-A’s Extended Conceptual Schema
Publications
IEEE-Papers ACM-Papers
SIG(): String
Title(): String
Pub_Date(): String
PostView(postscript) -> screen output
Researcher-B’s Extended ConceptualSchema
Legend
Supertype
Membership
Instance
Research-Papers
Computed Function
Stored Function
Text_Body(): String
Body(): String
Conference
Journal- Loc():String
IEEE-Papers
Papers
-
Remote
Papers
Title():String
Pub_Date():String
Remote Function
Text_Body():String
Figure Tw o comp onen t databases with extended functionalit y
L o c al function L o c al obje ct
As in the case of stored functions this is the base case Computed function F as
w ell as its argumen t a resides in the lo cal comp onen t and the execution is lo cal
eg latexT ext Bo dy a L o c al function R emote obje ct
This situation can b e reduced to the base case describ ed in case F or example
if Researc herA w an ts to view one of Researc herBs pap ers she will run l atex on
the T ext B ody of the surrogate for that pap er sa y inst and apply D v iV iew to
the result eg DviViewlatexT ex t Bo dy inst R emote function L o c al obje ct
This is the rev erse of the previous case the function executes remotely and the in
put argumen t is supplied from the lo cal database F or example Researc herA ma y
desire to view p ostscript text but do es not ha v e a p ostscript preview er in hisher
o wn lo cal database In this case she will in v ok e Researc herBs P ostV iew func
tion remotely through a previously created handle in hisher o wn database and
supply it with a lo cal argumen t In eect the remote database is pro viding a
nonlo cal service
R emote function R emote obje ct
This situation is similar to the rst case Lo cal function Lo cal ob ject in that
b oth the state of the ob ject and execution of the function are in the same comp o
nen t F or example Researc herA views one of Researc herBs IEEEP ap ers using
Researc herBs original P ostV iew function Compared to the rst case Lo cal
function Lo cal ob ject where no sharing tak es place and execution o ccurs lo cally
in this case all the pro cessing is done on the remote site In order to in v ok e a re
mote computed function using remote argumen ts from within the lo cal comp onen t
surrogates for the remote ob jects m ust b e created lo cally These surrogates enable
the lo cal comp onen t to access the actual state of desired ob jects whic h reside with
the remote comp onen t This pro cedure is similar to instance lev el sharing see
Section where surrogates for shared instances are created lo cally in order to
pro vide access to the actual state of eac h instance in the remote comp onen t
In the examples ab o v e the functions b eing shared ha v e returned a literal t yp e eg
the Author function returns a String Ho w ev er functions with signatures in v olving
abstract userdened t yp es can also b e shared In this case b oth the input and output
argumentt yp es m ust b e dened lo cally if they are not their metadata m ust b e imp orted
b eforehand The lo cation of the result argumen t is determined b y the lo cation where the
function executes
Observ ations on the Practical Use of F unctionBased
Sharing
With the ab o v e analysis and framew ork in place it is no w p ossible to mak e some observ a
tions on the practical utilit y of the functionbased sharing capabilities supp orted b y our
mec hanism In the ab o v e analysis of functionbased sharing w e stressed the separation
of the lo cation where the function executes from the lo cation where the data resides
Ho w ev er from a users p ersp ectiv e this separation of function execution and argumen t
lo cation is completely transparen t
Our analysis of eigh t dieren t sharing patterns can b e reduced to t w o most in terest
ing cases executing an imp orted function on a lo cal argumen t and executing
a lo cal function on an imp orted shared argumen t The rst case in v olv es the reuse of
a previously dened function in a dieren ten vironmen t this ma ybe termedbeha vior
sharing or function level sharing The second case can b e describ ed as extending the
c haracteristics of a remote ob ject while at the same time resp ecting the autonom yof
the originating site That is the imp orter can customize the remote ob ject according
to his lo cal conceptual sc hema These lo cal attributes are managed en tirely b y the lo cal
comp onenta v oiding an y unnecessary mo dication to the originating remote comp o
nen t
In b oth cases ab o v e the user is not a w are of the en vironmentin whic h a shared func
tion executes and need not w orry ab out where the state of an imp orted ob ject actually
resides Instead comp onen ts are able to freely bro wse the metadata and functions that
ha v e b een made a v ailable ie exp orted b y others in the federation in order to select
the services that they w ould lik e to share
ie imp ort
Our discussion has in a sense assumed that there are no access restrictions in place that w ould
further complicate the sharing pro cess An in v estigation of access con trol and authorization in ob ject
based databases is the sub ject of a related researc h pro ject at USC
Exp erimen tal Protot yp e Implemen tation
An exp erimen tal implem en tation of our functionbased sharing mec hanism has b een de
signed and built using our RemoteExc hange testb ed consisting of a federation of Omega
and Iris database comp onen ts F ang and McLeo d In what follo ws w e describ e
the essen tial asp ects of this testb ed and examine critical implem en tation issues wefaced
in our exp erimen ts
Sharing in the Remote Exc hange T estb ed
In the curren t RemoteExc hange testb ed w eha v e implem en ted the seamless transpar
en t imp ortation of ob jects from remote databases In our functional ob jectbased mo del
ob jects can b e instances t yp es or functions The v arious functionbased sharing pat
terns describ ed ab o v e can b e examined in the con text of instance t yp e and function
lev el sharing
Conceptually in instance lev el sharing a remote instance ob ject is imp orted directly
in to a lo cal t yp e This remote instance b eha v es in the same manner as a lo cal instance
ob ject from the users p ersp ectiv e Ho w ev er the actual state of the remote instance
exists in the remote comp onen t database retriev al of an y state of the remote ob ject is
done b y accessing the remote database transparen tly Hence access to remote instance
ob jects corresp onds to the Remote function Remote ob ject situations describ ed ab o v e
A sp ecial case of the Remote function Remote ob ject situation arises when the
remote ob ject b elongs to a t yp e that is not presen t in the lo cal sc hema Up un til no w
weha v e assumed that all remote instance ob jects b elong to a t yp e that is also presen t
in the lo cal comp onen t Ho w ev er w ecan en vision a scenario in whic h a comp onen t
wishes to imp ort the services of a function op erating on a t yp e that do es not exist in
the lo cal sc hema F or example Researc herBisin terested in authors of Researc herAs
conference pap ers see Figure In this case the remote t yp e m ust rst b e imp orted
to the lo cal sc hema in order for our sharing mec hanism to w ork It is imp ortan t to note
that creating a new lo cal t yp e corresp onding to a remote t yp e requires some additional
w ork in the sense that there ma y b e problems with the v alue t yp es for new functions as
w ell as nding the prop er place for it in the existing t yp e hierarc h y This sp ecial case
in v olv es typ e level sharing whic hisin v estigated in more detail in F ang and McLeo d
The imp ortation of a remote function ob ject corresp onds to the sharing of b eha vior
function lev el sharing In tuitiv ely when an instance ob ject is imp orted only data is
b eing shared On the other hand imp orting a function giv es the imp orter access to
services not pro vided b y hisher lo cal system This corresp onds to the Remote function
Lo cal ob ject situations describ ed ab o v e
The principal remaining useful situation is the imp ortan t case of Lo cal function Remote ob ject Among other things it allo ws users to add additional state to remote
ob jects without mo dication of the exp orting database thereb y preserving the autonom y
of the exp orter This abilit y to create lo cal state for remote ob jects is ac hiev ed automat
Note that this do es not dep end up on whether the function is stored or computed
Title(): String
Text_Body():String
View()
Entity
Types
Types
Functions
User-
Types
System-
Show_Inst() : OID
Show_Sub() : OID
Name() : String
R-IEEE-
Research-Papers
IEEE-Papers ACM-Papers
Title(): String
View()
R_OID(): String
Host_Name():String
Db_Name(): String
Types
Surrogate-
Pub_Date(): String
Text_Body():String
Legend
Supertype
Membership
Remote
Papers
Figure Sharing instance ob jects
ically from the w ayw e implem en t instance lev el sharing and is analogous to simple lo cal
database access
Instance Lev el Sharing Implemen tati on
Our mec hanism for imp orting instance lev el ob jects follo ws three steps
Create lo cal surrogates for remote ob jects
Create computed functions for retrieving data from remote comp onen ts
Ov erwrite functions dened on surrogates to use or refer to the newly created
computed functions in step The lo cal surrogate serv es as a lo cal handle for accessing a remote instance By using
the surrogate dierences b et w een remote represen tations of ob jects eg ob ject iden ti
ers OIDs can b e mask ed out made transparen t Since the state of the remote ob ject
exists externally computed functions for accessing that state m ust b e created These
computed functions use the Remote Pro cedure Call RPC paradigm Birrell and Nel
son for accessing the remote comp onen t Finally in order to ha v e the surrogates
use the remote functions an y existing functions dened on the surrogate m ust b e o v er
ridden to use the RPC dened functions This is implem en ted b y dynamically binding
functions to ob jects
In terms of the collab orating researc hers w e can en vision a scenario where Researc her
Bw an ts to imp ort instances of another remote t yp e IEEEP ap ers in to hisher lo cal
sc hema using the ab o v e approac h This is depicted in Figure Surrogates are created
as instances of b oth a lo cal t yp e ie Researc herBs IEEEP ap ers and a remote t yp e
called RIEEEP ap ers in Figure The purp ose of the new surrogate t ypeisto o v erride
the lo cal functions that surrogates inherit from the lo cal t yp e to whic h they b elong By
additionally creating the surrogate as a mem b er of this surrogate t yp e the functions that
the surrogate instance originally inherited are o v erridden The t w o thin dotted arro ws
from RIEEEP ap ers R for remote and IEEEP ap ers to the surrogate instance
serv e to indicate that surrogate instances ie remote instances of IEEEP ap ers are
created as mem bers of both IEEEP ap ers and RIEEEP ap ersTh us these remote
instances inherit functions m ultiply from b oth RIEEEP ap ers and IEEEP ap ersan y
duplicately named function from the t wot yp es is o v erridden b y the function dened for
RIEEEP ap ers The functions dened on RIEEEP ap ers are computed functions
whic h mak e RPC requests to the remote comp onen t database and retrievethe v alues of
functions on remote instances
F unction Lev el Sharing Implemen tati on
As in instance lev el and t yp e lev el sharing metainformation con taining the lo cation
eg remote OID and remote comp onen t name of the remote function ob ject unit of
beha vior b eing imp orted m ust b e stored lo cally Ho w ev er b ycon trast with the case
for instance lev el sharing this metainformation is asso ciated directly with the func
tion b eing imp orted In instance lev el sharing the metainformation is indirectly k ept
for remote functions suchas Title and View via the surrogate instance ob ject see
Figure Th us in our implem en tation w e distinguish b et w een t w o kinds of remote
functions those implici tly dened through instance lev el imp ortation and those directly
imp orted through function lev el imp ortation Figure sho ws our mec hanism for in
corp orating metainformation for function lev el imp ortation W e exploit the fact that
metainformation is also represen ted using our functional ob jectbased mo del Imp orted
functions are created as instances of the t yp e RemoteF unctions and can th us store
and access the additional lo cation metainformation required to execute the imp orted
function
Figure depicts a sligh tly dieren t sharing pattern from Figure In this scenario
the View function is imp orted from some remote comp onen t In addition RIEEE
P ap ers no longer supplies a View function Hence b oth the remote and lo cal instances
of IEEEP ap ers use the same imp orted View function for displa ying researc h pap ers
This is eviden t in Figure b y the absence of the View function from the t yp e RIEEE
P ap ers and the addition of a new italicized View function dened on Researc h
P ap ers
In order to explain ho w the View function w orks w em ust rst explain ho w our
implem en tati on addresses the issue of sideeects By sideeect w e really mean t w o
things an y kind of implicit input other than the input argumen t that is necessary
to compute the result and an y mo dications to the state of the database where the
function executes other than to the input argumen t F or functions whose argumen ts are
literals this simply requires that the function b eing imp orted computes its result v alue
The italicized fon t is used to indicate that the View function is imp orted and no longer lo cal
Title(): String
Text_Body():String
View()
Entity
Types
Types
Functions
User-
Types
System-
Show_Inst() : OID
Show_Sub() : OID
Name() : String
R-IEEE-
Research-Papers
IEEE-Papers ACM-Papers
Title(): String
R_OID(): String
Host_Name():String
Db_Name(): String
Types
Surrogate-
Pub_Date(): String
Text_Body():String
Legend
Supertype
Membership
Remote
Papers
R-Functions
R_OID(): String
Host_Name():String
Db_Name(): String
View()
Figure Sharing function ob jects
solely based on its input argumen t without mo difying an y database state F unctions
whose input argumen t is nonliteral p ose additional diculties In this case the input
argumen t is the OID of an instance The problem then lies in determining what infor
mation a computed function accesses in order to compute its results Strictly applying
our denition of sideeects w ould restrict computed functions on nonliterals to solely
accessing and then manipulating the input OID But realistically a computed function
m ust b e able to access some state of the instance corresp onding to the OID when com
puting its result In our implem en tation w e tak e the p osition that the only state that a
computed function can access are those functions that serv e to encapsulate that ob ject
In other w ords the only state the computed function will p ossibly access are those func
tions that are dened on the t yp es of whic h the instance is a mem b er In the case of the
View computed function these functions are Title T ext Bo dy and Pub Date Ha ving determined what information a computed function on a nonliteral t yp e can
access a problem arises when trying to execute suc h a function remotely on a lo cal
ob ject The problem o ccurs when supplying lo cal argumen ts to a remote computed
function Although wekno w the computed function is limited to only accessing the
functions that encapsulate the instance w e do not kno w exactly whic h ones it do es need
Ev en if w e pass all the p ossible v alues the computed function can access the computed
function m ust b e written in sucha w a y as to retriev e these argumen ts from the remote
comp onen t and not the lo cal one This w ould b e undesirable and con trary to our goal
of relieving the computed function writer of needing to kno w where the data on whichit
op erates is lo cated
The b est approac h to this problem in our autonomous en vironmen t is to allo w com
puted function writers to dene functions without concern as to whether the function is
to b e exp orted Th us in our implem e n tation whenev er a remotely executing computed
function needs state from the lo cal comp onen t it p erforms a callbac k to the lo cal com
p onen t to retriev e that state F or the instance lev el sharing describ ed in Section the lo cal comp onen t simply runs as a clien t and mak es RPC requests to the exp orter
running as a serv er Ho w ev er for function lev el sharing when the callbac k mec hanism
is used the lo cal comp onen tm ust in addition run as a serv er to accept the callbac k
requests Computed functions can b e written using an y programming language that can
b e compiled to reen tran t ob ject co de This ob ject co de is then dynamically link ed in to
the database managemen t system k ernel when the computed function is accessed In our
protot yp e using the Omega database managemen t system a computed function accesses
the lo cal comp onen t through Ome ga eval whic hhas t w o parameters an argumen tand
the function that is to b e applied to the argumen t
Wecan no w consider ho w the callbackmec hanism w orks transparen tly and howit
allo ws a computed function to b e written uniformly without regard as to whether that
function is to b e exp orted Consider again the example using the View computed
function Supp ose that the imp orted View function retriev es the T ext Bo dy of an
instance sa y in latex format computes the dvi formatted v ersion and displa ys the
formatted v ersion through a dvi preview er sa y xdvi When the user of the lo cal com
p onentin v ok es the View function on a lo cal ob ject the View function is passed the
lo cal OID of a Researc hP ap ers instance The View on the remote serv er mak es a
call to Ome ga eval to retrievethe T ext Bo dy Ome ga eval recognizes that the OID
passed in as its argumen t is not lo cal and p erforms a callbac k to the serv er of the lo cal
comp onen t that in v ok ed the View function Since the lo cal serv er recognizes the OID
as a lo cal OID it p erforms the request and passes bac kthe T ext Bo dy to the remote
serv er whic h can than complete its computation and displa y the results on the lo cal
database monitor
Conclusions and F uture Directions
In this pap er w eha v e presen ted a functionbased approac h and mec hanism for sharing
in a federated database system An exp erimen tal implem en tati on of the functionbased
sharing mec hanism using the RemoteExc hange exp erimen tal testb ed w as examined In
our approac h w eha v e considered the imp ortance of decoupling the lo cation of p ersis
ten t data and the lo cation of the execution of metho ds that op erate on it T raditional
approac hes inextricably link the lo cation of the data and the execution of the op eration
An area of researc h that has not b een directly considered in this pap er in v olv es lo cal
comp onen t up dates of ob jects at a remote comp onen t Other researc h eorts sp ecically
address the issues in this area Breibart et al Ho w ev er our approac h allo ws the
lo cal comp onen t to create lo cal eg stored functions on remote ob jects This has the
o v erall b enet of allo wing the lo cal comp onen t to create lo cal state for remote ob jects
that completely conform to the lo cal systems mec hanism for up dates
The fo cus of our exp erimen tal protot yp e implem en tation has b een mainly on instance
lev el sharing and function lev el sharing W eha v e found these sharing patterns to b e v ery
natural and easy to use in our en vironmen t W e are curren tly further in v estigating
abstract complex ob ject sharing and are pro ceeding to more substan tially quan tify the
p erformance eciency of our mec hanisms
References
Afsarmanesh and McLeo d H Afsarmanesh and D McLeo d The DIS An Ex
tensible Ob jectOrien ted Information ManagementEn vironmen t A CM T r ansactions
on Oc e Information Systems Octob er A tkinson M A tkinson et al The Ob jectOrien ted Database System Manifesto
In Pr o c e e dings of the st Intl Conf on De ductive and Obje ctOriente d Datab ases Ky oto Japan Decem b er Birrell and Nelson A Birrell and B Nelson Implem e n ting Remote Pro cedure
Calls A CM T r ansactions on Computer Systems F ebruary Breibart et al Y Breibart A Silb ersc hatz and G Thompson Reliable T rans
action Managemen t in a Multidatabase System In Pr o c e e dings of the A CM SIGMOD
International Confer enc e on Management of Data pages A CM SIGMOD
Ma y F ang and McLeo d D F ang and D McLeo d AT estb ed and Mec hanism for
Ob jectBased Sharing in F ederated Database Systems T ec hnical Rep ort USCCS
Computer Science Departmen t Univ ersit y of Southern California Los Angeles
CA F ebruary F ang et al D F ang J Hammer D McLeo d and A Si RemoteExc hange An
ApproachtoCon trolled Sharing among Autonomous Heterogenous Database Systems
In Pr o c e e dings of the IEEE Spring Comp c onIEEE San F rancisco F ebruary Fishman et al D Fishman D Beec h H Cate E Cho w T Connors T Da vis
N Derrett C Ho c h W Ken t P Lyngbaek B Mah b o d M Neimat T Ry an and
M Shan Iris An Ob jectOrien ted Database Managemen t System A CM T r ansactions
on Oc e Information Systems Jan uary Ghandeharizadeh S Ghandeharizadeh et al Design and Implem en tation of
OMEGA Ob jectbased System T ec hnical Rep ort USCCS Computer Science De
partmen t Univ ersit y of Southern California Los Angeles CA Septem ber

Hull and King R Hull and R King Seman tic Database Mo deling Surv eyAp plications and Researc h Issues A CM Computing Surveys Septem ber

Kim et al W Kim J Banerjee H T Chou J F Garza and D W o elk Com
p osite Ob ject Supp ort in an Ob jectOrien ted Database System In Pr o c e e dings of the
Confer enceon Obje ctOriente dPr o gr amming Systems L anguages and Applic ations pages
Kim et al W Kim J Garza N Ballou and D W oelk Arc hitecture of the
ORION NextGeneration Database System IEEE T r ansactions on Know le dge Data
Engine ering Marc h Lecluse et al C Lecluse P Ric hard and F V elez O
an Ob jectOrien ted Data
Mo del In Pr o c e e dings of the A CM SIGMOD International Confer enc e on Management
of Data Chicago Ill June A CM SIGMOD
Lisk o v B Lisk o v Distributed Programming in Argus Communic ations of the
A CM Maier et al D Maier J Stein A Otis and A Purdy Dev elopmen t of an Ob ject
Orien ted DBMS In Pr o c e e dings of the Confer enc e on Obje ctOriente dPr o gr amming
Systems L anguages and Applic ations pages A CM Shipman D Shipman The F unctional Data Mo del and the Data Language
D APLEX A CM T r ansactions on Datab ase Systems Marc h Strom and Y emini R Strom and S Y emini The NIL Distributed Systems Pro
gramming Language A Status Rep ort A CM Sigplan Notic es Ma y

Linked assets

Computer Science Technical Report Archive

Conceptually similar

PDF

USC Computer Science Technical Reports, no. 574 (1994)

PDF

USC Computer Science Technical Reports, no. 575 (1994)

PDF

USC Computer Science Technical Reports, no. 833 (2004)

PDF

USC Computer Science Technical Reports, no. 721 (2000)

PDF

USC Computer Science Technical Reports, no. 879 (2006)

PDF

USC Computer Science Technical Reports, no. 849 (2005)

PDF

USC Computer Science Technical Reports, no. 589 (1994)

PDF

USC Computer Science Technical Reports, no. 644 (1997)

PDF

USC Computer Science Technical Reports, no. 587 (1994)

PDF

USC Computer Science Technical Reports, no. 852 (2005)

PDF

USC Computer Science Technical Reports, no. 763 (2002)

PDF

USC Computer Science Technical Reports, no. 578 (1994)

PDF

USC Computer Science Technical Reports, no. 747 (2001)

PDF

USC Computer Science Technical Reports, no. 598 (1994)

PDF

USC Computer Science Technical Reports, no. 593 (1994)

PDF

USC Computer Science Technical Reports, no. 794 (2003)

PDF

USC Computer Science Technical Reports, no. 843 (2005)

PDF

USC Computer Science Technical Reports, no. 591 (1994)

PDF

USC Computer Science Technical Reports, no. 769 (2002)

PDF

USC Computer Science Technical Reports, no. 679 (1998)

Description

D. Fang, J. Hammer, and D. McLeod. "A mechanism and experimental system for function-based sharing in federated database systems." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 572 (1994).

Asset Metadata

Creator Fang, D. (author), Hammer, J. (author), McLeod, D. (author)

Core Title USC Computer Science Technical Reports, no. 572 (1994)

Alternative Title A mechanism and experimental system for function-based sharing in federated database systems (title)

Publisher Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA (publisher)

Tag OAI-PMH Harvest

Format 15 pages (extent), technical reports (aat)

Language English

Unique identifier UC16269478

Identifier 94-572 A Mechanism and Experimental System for Function-Based Sharing in Federated Database Systems (filename)

Legacy Identifier usc-cstr-94-572

Format 15 pages (extent),technical reports (aat)

Rights Department of Computer Science (University of Southern California) and the author(s).

Internet Media Type application/pdf

Source 20180426-rozan-cstechreports-shoaf (batch), Computer Science Technical Report Archive (collection), University of Southern California. Department of Computer Science. Technical Reports (series)

Access Conditions The author(s) retain rights to their work according to U.S. copyright law. Electronic access is being provided by the USC Libraries, but does not grant the reader permission to use the work if the desired use is covered by copyright. It is the author, as rights holder, who must provide use permission if such use is covered by copyright.

Repository Name USC Viterbi School of Engineering Department of Computer Science

Repository Location Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089

Repository Email csdept@usc.edu

Inherited Values

Title Computer Science Technical Report Archive

Description Archive of computer science technical reports published by the USC Department of Computer Science from 1991 - 2017.

Coverage Temporal 1991/2017

Repository Email csdept@usc.edu

Repository Name USC Viterbi School of Engineering Department of Computer Science

Repository Location Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089

Publisher Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA (publisher)