Doorn, L. van

Homburg, P.

Steen, M. van

van Steen, M.

van Doorn, L.

VU Research Portal

VU Research PortalTowards object-based wide area distributed systemsvan Steen, M.; Homburg, P.; van Doorn, L.published inProc. Fourth Int'l Workshop on Object Orientation in Operating Systems, IEEE, Lund, Sweden, August 19951995document versionPublisher's PDF, also known as Version of recordLink to publication in VU Research Portalcitation for published version (APA)van Steen, M., Homburg, P., & van Doorn, L. (1995). Towards object-based wide area distributed systems. InProc. Fourth Int'l Workshop on Object Orientation in Operating Systems, IEEE, Lund, Sweden, August 1995 (pp.224-227)General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.            • Users may download and print one copy of any publication from the public portal for the purpose of private study or research.            • You may not further distribute the material or use it for any profit-making activity or commercial gain            • You may freely distribute the URL identifying the publication in the public portal ?Take down policyIf you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediatelyand investigate your claim.E-mail address:vuresearchportal.ub@vu.nlDownload date: 27. May. 2021Towards Object-based Wide Area Distributed SystemsMaarten van Steen, Philip Homburg, Leendert van DoornAndrew S. Tanenbaum, Wiebren de JongeVrije Universiteit, AmsterdamAbstractIn order to facilitate the construction of wide area dis-tributed systems, it is necessary that we adopt a modelthat simplifies application development. In this positionpaper we advocate an object-based approach. Our ap-proach allows for flexibility because many of the techni-cal details of distribution, such as communication pro-tocols, consistency rules, etc. can be hidden behind theobjects’ interfaces. In addition, we allow distributed ob-jects to offer alternative implementations for an inter-face. A client may choose the most suitable implemen-tation. We discuss the use of distributed objects as themeans to this end, and compare our approach to exist-ing ones.1 IntroductionWide area distributed applications pose varyingdemands on the underlying operating systems, of-ten making the development of the application it-self a difficult task. For example, development ofdistributed applications often requires the follow-ing:Support for expressing communication at asufficiently high level of abstraction.Efficient implementations of different com-munication models and operating system ser-vices, dependent on their usage by differentkinds of applications.Support for execution and communication ina heterogeneous environment.Flexibility with respect to reconfiguring asystem during its execution.Support for security.These demands sometimes conflict. For example,it may be difficult to attain efficiency for commu-nication at a sufficiently high level of abstractionwithout taking (application-dependent) communi-cation structures into account. Likewise, hav-ing support for different communication modelswithin a single framework may provide flexibility,but it may simply be too heavy weight for a spe-cific domain.To alleviate such problems, we feel that aframework should provide support for:An integrated approach for developingapplication-specific components, and de-veloping more general components thathandle, for example, state distribution andcommunication.Flexibility with respect to how componentsare implemented, particularly where imple-mentations depend on the external factorssuch as operating systems or underlying com-munication network.We advocate an object-based approach fortwo reasons. First, the concept of an object pro-vides a natural way of separating functionalityfrom implementation. This separation is neededbecause wide area applications require that com-ponents can be distributed across different under-lying systems. Having different systems, in turn,implies that we should be able to provide differentimplementations for components that are function-ally the same.The second reason is that objects naturallyencapsulate state with permissible operations. Theimportant issue is that this provides modularitywith regards to instances, and not just with respectto their description. In other words, encapsula-tion leads to a natural way of protecting and hid-ing information in an individual component. Theonly way that this information can be accessedis through that component’s interface to the out-side world. In view of the necessity for differentimplementations of functionally equivalent com-ponents, shielding implementations behind inter-faces on a per-component basis, is essential.The combination of separating functionalityfrom implementation, and protecting and hidinginformation into a single component, allows forthe integration and flexibility mentioned above. Inparticular, we have adopted a model in which a dis-tributed object may offer several alternative imple-mentations for an interface. A client selects themost suitable implementation based, among otherthings, on its present environment. In wide areadistributed computing, it is this type of flexibilitywe think is important. We return to this issue be-low.What functionality should the environmentoffer? It is here that we feel that many object-based models restrict developers in several ways.First, many offer functionality that is not well-suited for the development of wide area distributedapplications. Second, the functionality is offeredat a relatively high level of abstraction, which maymake it difficult to implement efficiently. Third,many do not support developers to adapt these im-plementations to their own needs. In our approach,we do not restrict developers in these ways, but in-stead provide the flexibility that is needed. We re-turn to this in Section 4.2 The global modelIn the model we propose, an object is an entitywith:A collection of values, referred to as the stateof the object.A collection of methods by which the state ofthe object can be inspected and modified.A collection of interfaces, each interfacepointing to a subset of the methods. An invo-cation of a method can occur only via an in-terface.Each object has a globally unique and location-independent object identifier. Different, and mu-tually independent naming services can be used toattach user-oriented names to objects. Objects areshared by either using a global naming service, orby exporting their identifier to other name services.We do not support inheritance as we feel thatalternatives exist that are more flexible for struc-turing applications. In our model, we instead al-low an object to have multiple interfaces. In thisway, a developer can extend or adapt an object byadding new method implementations and an inter-face comprising those methods, without affectingclients that already use the object. We take the ap-proach that constructing an object should focus ondesigning its interfaces. Interfaces determine thefunctionality of an object, which in turn can be im-plemented in different ways as explained above.In our model, interface design and implementationis independent of any programming language. Ob-jects, and users of objects can be written in any lan-guage.Structuring is further supported by makinga distinction between non-decomposable objects,called primitive objects, and composite objects.A composite object aggregates one or more (com-posite or primitive) objects into a single object. Tothis aim, an interface of a composite object maypoint to methods from different objects in the com-position. From the outside, however, a compositeobject is indistinguishable from a primitive object.Objects are passive: their methods are in-voked by threads which are the active entities inour model. Threads and objects are orthogonal.This means that threads exist independently of ob-jects, and that objects have no predefined proper-ties regarding concurrency. Instead, any of suchproperties should form part of an interface speci-fication.In the following section we pay attention tohow objects are organized in our model.3 Object organizationAn object may have its interfaces and state dis-tributed across multiple address spaces. Such adistribution is realized through local objects. Alocal object has its state, methods, and interfacesin a single address space. A distributed objectis a collection of local objects that may reside indifferent address spaces. The local objects of adistributed object communicate with each other inorder to maintain and present a consistent viewon the overall state. By properly encapsulatingthis communication, a distributed object appearson the outside as an ordinary object with all com-munication hidden from its clients.Basic organization. Communication is imple-mented through communication objects. In itssimplest form, a communication object is built asa non decomposable object encapsulating an exist-ing message-passing facility such as local RPC, anEthernet device driver, or TCP/IP. More advancedfacilities, such as general multicasting and sharedmemory mechanisms, are encapsulated in objectsthat make use of these simpler objects.State partitioning and replication is handledthrough separate objects that make use of (simple)communication objects. For example, replicationcan be supported by adding an object to each lo-cal object that multicasts state changes to the lo-cal objects at other locations, possibly using hard-ware multicast, if available. Similarly, a separateobject may be responsible to forward operationson the distributed object’s state when that state ismaintained by a remote local object. A state con-sistency protocol may be implemented in a sep-arate object that interacts with objects handlingstate partitioning and replication.Figure 1: The general organization of a dis-tributed object in a client’s address space.This approach leads to the general organiza-tion shown in Figure 1. Three different kinds ofcomponents are distinguished. The local compo-nent consists of objects that implement the basicfunctionality made available through methods atthe interface. The communication component im-plements a protocol stack needed for informationexchange with other parts of the distributed ob-ject. The control component, finally, takes careof argument marshaling and controls invocation ofmethod implementations.Our approach differs from most others in thata distributed object may offer different implemen-tations for its interfaces. For example, an interfacemay be implemented by having a replica of theobject’s state placed in the client’s address space.This would then be combined with method im-plementations and an implementation of a specificprotocol stack to keep the overall state consistent.Alternatively, a client may possibly also have thechoice for selecting an RPC-based implementationof that interface. In that case, the local compo-nent of Figure 1 would be obsolete, and only theimplementation of a basic communication objectwould be necessary. It is up to the client to selectthe “best” possible implementation, as is discussedbelow.We do not assume that objects handling com-munication, partitioning, replication, and consis-tency, are necessarily provided beforehand. Inother words, our model allows an application de-veloper to construct such objects if so required.This also means that if it is necessary or conve-nient to place certain objects into kernel space, orlikewise, if objects such as device drivers are to beplaced in user space, we do not prevent a user fromdoing so. As explained in [6] this does require spe-cial certification support.Binding. In order for a client to invoke a methodof a distributed object, it is necessary that localobjects are installed and initialized in the client’saddress space. These local objects implement theinterface(s) of the distributed object as requestedby the client. This binding process, which is de-scribed in more detail in [2], consists of four steps.Name resolution. The client provides a namethat identifies the object. This name is thenresolved to the object’s unique identifier.Peer group resolution. The distributed objectmay offer different ways to implement theinterface requested by the client. Each im-plementation requires communication with apeer group: a collection of local objects thatare part of the distributed object and which re-side in other address spaces. In this step, ex-actly which peer groups supporting the inter-face’s implementation, together with its asso-ciated communication protocol, is resolved.Peer group selection. From the set of peergroups, the one that is most suitable for im-plementing the interface at the client’s side, isselected.Implementation selection. Finally, the ob-jects that take care of the actual communica-tion, and which implement the interface(s) ofthe distributed object at the client’s side, areselected, installed, and initialized. By includ-ing a separate selection step for object imple-mentations, possible heterogeneity of the un-derlying system is completed shielded for theclient.The binding process is entirely done during run-time. There is no need for configuration of com-ponents at the client’s side beforehand. The devel-opment of distributed naming service that scalesto wide area networks is a subject of ongoing re-search.Structuring. Composition of distributed objectsis presently limited to a single address space. Toexplain, assume that two local objects of differ-ent distributed objects reside in the same addressspace. In that case, we can aggregate these two lo-cal objects into a composition by providing an in-terface consisting of entries that point to methodsfrom either local object. Consequently, to a clientresiding in that address space, the composed dis-tributed object appears as a normal object. Com-position of distributed objects in general is a alsosubject of ongoing research.4 Discussion and related workOur model has a strong focus on encapsulating andhiding implementations, and provides flexibilitywith respect to how interfaces are implemented.This contrasts the approach followed by others.For example, objects in CORBA are based onthe existence of a runtime system, called an ob-ject request broker [5]. This request broker is aug-mented with object adapters that provide the basicmeans for invoking methods of (remote) objects.The implementation of the broker and its adaptersis not part of any object. And because they offeronly limited communication facilities, it becomesdifficult to construct, for example, groups of repli-cated objects. Making the runtime system open toadaptations by developers would have avoided thisproblem.Fragmented objects [3] follow an approachquite similar to that of ours, except that the run-time selection of a peer group and its associatedcommunication protocol is not supported. Instead,the actual selection criteria have to be providedby an implementor beforehand. In our case, welet a client follow its own selection strategy, con-strained, of course, by what the distributed objectoffers.The approach followed in Spring [4] is alsomore or less in line with ours. Flexibility with re-spect to implementations is obtained through so-called subcontracts [1], which can be perceivedas commonly agreed protocol stacks between twocommunicating local objects. However, subcon-tracts are not structured as objects in the way weenvisage. Instead, they appear as indivisible units.A notable difference with other approaches isthat the architecture we have outlined in this pa-per, is aimed towards support for wide area appli-cations.References[1] G. Hamilton, M. Powell, and J. Mitchell.“Subcontract: A Flexible Base for Dis-tributed Programming”. In Proceedings 14thSymposium on Operating Systems Principles,Asheville, North Carolina, December 1993.ACM.[2] P. Homburg, L. van Doorn, M. van Steen,A. Tanenbaum, and W. de Jonge. “An ObjectModel for Flexible Distributed Systems”. InProceedings 1st Annual ASCI Conference, pp.69–78, Heijen, The Netherlands, May 1995.[3] M. Makpangou, Y. Gourhant, J.-P. Le Narzul,and M. Shapiro. “Structuring Distributed Ap-plications as Fragmented Objects”. TechnicalReport 1404, INRIA, January 1991.[4] J. Mitchell et al. “An Overview of the SpringSystem”. In Proceedings Compcon Spring1994. IEEE, February 1994.[5] Object Management Group. “The Com-mon Object Request Broker: Architecture andSpecification, version 1.2”. Technical Report93.12.43, OMG, December 1993.[6] L. van Doorn, P. Homburg, and A.S. Tanen-baum. “Paramecium: An Extensible Object-based Kernel”. In Proceedings Hot Topics onOperating Systems V, Orca’s Island, Washing-ton, May 1995. IEEE.

English

Towards object-based wide area distributed systems

DSpace at VU

Towards Object-based Wide Area Distributed Systems
Maarten van Steen, Philip Homburg, Leendert van Doorn
Andrew S. Tanenbaum, Wiebren de Jonge
Vrije Universiteit, Amsterdam
Abstract
In order to facilitate the construction of wide area dis-
tributed systems, it is necessary that we adopt a model
that simplifies application development. In this position
paper we advocate an object-based approach. Our ap-
proach allows for flexibility because many of the techni-
cal details of distribution, such as communication pro-
tocols, consistency rules, etc. can be hidden behind the
objects’ interfaces. In addition, we allow distributed ob-
jects to offer alternative implementations for an inter-
face. A client may choose the most suitable implemen-
tation. We discuss the use of distributed objects as the
means to this end, and compare our approach to exist-
ing ones.
1 Introduction
Wide area distributed applications pose varying
demands on the underlying operating systems, of-
ten making the development of the application it-
self a difficult task. For example, development of
distributed applications often requires the follow-
ing:
Support for expressing communication at a
sufficiently high level of abstraction.
Efficient implementations of different com-
munication models and operating system ser-
vices, dependent on their usage by different
kinds of applications.
Support for execution and communication in
a heterogeneous environment.
Flexibility with respect to reconfiguring a
system during its execution.
Support for security.
These demands sometimes conflict. For example,
it may be difficult to attain efficiency for commu-
nication at a sufficiently high level of abstraction
without taking (application-dependent) communi-
cation structures into account. Likewise, hav-
ing support for different communication models
within a single framework may provide flexibility,
but it may simply be too heavy weight for a spe-
cific domain.
To alleviate such problems, we feel that a
framework should provide support for:
An integrated approach for developing
application-specific components, and de-
veloping more general components that
handle, for example, state distribution and
communication.
Flexibility with respect to how components
are implemented, particularly where imple-
mentations depend on the external factors
such as operating systems or underlying com-
munication network.
We advocate an object-based approach for
two reasons. First, the concept of an object pro-
vides a natural way of separating functionality
from implementation. This separation is needed
because wide area applications require that com-
ponents can be distributed across different under-
lying systems. Having different systems, in turn,
implies that we should be able to provide different
implementations for components that are function-
ally the same.
The second reason is that objects naturally
encapsulate state with permissible operations. The
important issue is that this provides modularity
with regards to instances, and not just with respect
to their description. In other words, encapsula-
tion leads to a natural way of protecting and hid-
ing information in an individual component. The
only way that this information can be accessed
is through that component’s interface to the out-
side world. In view of the necessity for different
implementations of functionally equivalent com-
ponents, shielding implementations behind inter-
faces on a per-component basis, is essential.
The combination of separating functionality
from implementation, and protecting and hiding
information into a single component, allows for
the integration and flexibility mentioned above. In
particular, we have adopted a model in which a dis-
tributed object may offer several alternative imple-
mentations for an interface. A client selects the
most suitable implementation based, among other
things, on its present environment. In wide area
distributed computing, it is this type of flexibility
we think is important. We return to this issue be-
low.
What functionality should the environment
offer? It is here that we feel that many object-
based models restrict developers in several ways.
First, many offer functionality that is not well-
suited for the development of wide area distributed
applications. Second, the functionality is offered
at a relatively high level of abstraction, which may
make it difficult to implement efficiently. Third,
many do not support developers to adapt these im-
plementations to their own needs. In our approach,
we do not restrict developers in these ways, but in-
stead provide the flexibility that is needed. We re-
turn to this in Section 4.
2 The global model
In the model we propose, an object is an entity
with:
A collection of values, referred to as the state
of the object.
A collection of methods by which the state of
the object can be inspected and modified.
A collection of interfaces, each interface
pointing to a subset of the methods. An invo-
cation of a method can occur only via an in-
terface.
Each object has a globally unique and location-
independent object identifier. Different, and mu-
tually independent naming services can be used to
attach user-oriented names to objects. Objects are
shared by either using a global naming service, or
by exporting their identifier to other name services.
We do not support inheritance as we feel that
alternatives exist that are more flexible for struc-
turing applications. In our model, we instead al-
low an object to have multiple interfaces. In this
way, a developer can extend or adapt an object by
adding new method implementations and an inter-
face comprising those methods, without affecting
clients that already use the object. We take the ap-
proach that constructing an object should focus on
designing its interfaces. Interfaces determine the
functionality of an object, which in turn can be im-
plemented in different ways as explained above.
In our model, interface design and implementation
is independent of any programming language. Ob-
jects, and users of objects can be written in any lan-
guage.
Structuring is further supported by making
a distinction between non-decomposable objects,
called primitive objects, and composite objects.
A composite object aggregates one or more (com-
posite or primitive) objects into a single object. To
this aim, an interface of a composite object may
point to methods from different objects in the com-
position. From the outside, however, a composite
object is indistinguishable from a primitive object.
Objects are passive: their methods are in-
voked by threads which are the active entities in
our model. Threads and objects are orthogonal.
This means that threads exist independently of ob-
jects, and that objects have no predefined proper-
ties regarding concurrency. Instead, any of such
properties should form part of an interface speci-
fication.
In the following section we pay attention to
how objects are organized in our model.
3 Object organization
An object may have its interfaces and state dis-
tributed across multiple address spaces. Such a
distribution is realized through local objects. A
local object has its state, methods, and interfaces
in a single address space. A distributed object
is a collection of local objects that may reside in
different address spaces. The local objects of a
distributed object communicate with each other in
order to maintain and present a consistent view
on the overall state. By properly encapsulating
this communication, a distributed object appears
on the outside as an ordinary object with all com-
munication hidden from its clients.
Basic organization. Communication is imple-
mented through communication objects. In its
simplest form, a communication object is built as
a non decomposable object encapsulating an exist-
ing message-passing facility such as local RPC, an
Ethernet device driver, or TCP/IP. More advanced
facilities, such as general multicasting and shared
memory mechanisms, are encapsulated in objects
that make use of these simpler objects.
State partitioning and replication is handled
through separate objects that make use of (simple)
communication objects. For example, replication
can be supported by adding an object to each lo-
cal object that multicasts state changes to the lo-
cal objects at other locations, possibly using hard-
ware multicast, if available. Similarly, a separate
object may be responsible to forward operations
on the distributed object’s state when that state is
maintained by a remote local object. A state con-
sistency protocol may be implemented in a sep-
arate object that interacts with objects handling
state partitioning and replication.
Figure 1: The general organization of a dis-
tributed object in a client’s address space.
This approach leads to the general organiza-
tion shown in Figure 1. Three different kinds of
components are distinguished. The local compo-
nent consists of objects that implement the basic
functionality made available through methods at
the interface. The communication component im-
plements a protocol stack needed for information
exchange with other parts of the distributed ob-
ject. The control component, finally, takes care
of argument marshaling and controls invocation of
method implementations.
Our approach differs from most others in that
a distributed object may offer different implemen-
tations for its interfaces. For example, an interface
may be implemented by having a replica of the
object’s state placed in the client’s address space.
This would then be combined with method im-
plementations and an implementation of a specific
protocol stack to keep the overall state consistent.
Alternatively, a client may possibly also have the
choice for selecting an RPC-based implementation
of that interface. In that case, the local compo-
nent of Figure 1 would be obsolete, and only the
implementation of a basic communication object
would be necessary. It is up to the client to select
the “best” possible implementation, as is discussed
below.
We do not assume that objects handling com-
munication, partitioning, replication, and consis-
tency, are necessarily provided beforehand. In
other words, our model allows an application de-
veloper to construct such objects if so required.
This also means that if it is necessary or conve-
nient to place certain objects into kernel space, or
likewise, if objects such as device drivers are to be
placed in user space, we do not prevent a user from
doing so. As explained in [6] this does require spe-
cial certification support.
Binding. In order for a client to invoke a method
of a distributed object, it is necessary that local
objects are installed and initialized in the client’s
address space. These local objects implement the
interface(s) of the distributed object as requested
by the client. This binding process, which is de-
scribed in more detail in [2], consists of four steps.
Name resolution. The client provides a name
that identifies the object. This name is then
resolved to the object’s unique identifier.
Peer group resolution. The distributed object
may offer different ways to implement the
interface requested by the client. Each im-
plementation requires communication with a
peer group: a collection of local objects that
are part of the distributed object and which re-
side in other address spaces. In this step, ex-
actly which peer groups supporting the inter-
face’s implementation, together with its asso-
ciated communication protocol, is resolved.
Peer group selection. From the set of peer
groups, the one that is most suitable for im-
plementing the interface at the client’s side, is
selected.
Implementation selection. Finally, the ob-
jects that take care of the actual communica-
tion, and which implement the interface(s) of
the distributed object at the client’s side, are
selected, installed, and initialized. By includ-
ing a separate selection step for object imple-
mentations, possible heterogeneity of the un-
derlying system is completed shielded for the
client.
The binding process is entirely done during run-
time. There is no need for configuration of com-
ponents at the client’s side beforehand. The devel-
opment of distributed naming service that scales
to wide area networks is a subject of ongoing re-
search.
Structuring. Composition of distributed objects
is presently limited to a single address space. To
explain, assume that two local objects of differ-
ent distributed objects reside in the same address
space. In that case, we can aggregate these two lo-
cal objects into a composition by providing an in-
terface consisting of entries that point to methods
from either local object. Consequently, to a client
residing in that address space, the composed dis-
tributed object appears as a normal object. Com-
position of distributed objects in general is a also
subject of ongoing research.
4 Discussion and related work
Our model has a strong focus on encapsulating and
hiding implementations, and provides flexibility
with respect to how interfaces are implemented.
This contrasts the approach followed by others.
For example, objects in CORBA are based on
the existence of a runtime system, called an ob-
ject request broker [5]. This request broker is aug-
mented with object adapters that provide the basic
means for invoking methods of (remote) objects.
The implementation of the broker and its adapters
is not part of any object. And because they offer
only limited communication facilities, it becomes
difficult to construct, for example, groups of repli-
cated objects. Making the runtime system open to
adaptations by developers would have avoided this
problem.
Fragmented objects [3] follow an approach
quite similar to that of ours, except that the run-
time selection of a peer group and its associated
communication protocol is not supported. Instead,
the actual selection criteria have to be provided
by an implementor beforehand. In our case, we
let a client follow its own selection strategy, con-
strained, of course, by what the distributed object
offers.
The approach followed in Spring [4] is also
more or less in line with ours. Flexibility with re-
spect to implementations is obtained through so-
called subcontracts [1], which can be perceived
as commonly agreed protocol stacks between two
communicating local objects. However, subcon-
tracts are not structured as objects in the way we
envisage. Instead, they appear as indivisible units.
A notable difference with other approaches is
that the architecture we have outlined in this pa-
per, is aimed towards support for wide area appli-
cations.
References
[1] G. Hamilton, M. Powell, and J. Mitchell.
“Subcontract: A Flexible Base for Dis-
tributed Programming”. In Proceedings 14th
Symposium on Operating Systems Principles,
Asheville, North Carolina, December 1993.
ACM.
[2] P. Homburg, L. van Doorn, M. van Steen,
A. Tanenbaum, and W. de Jonge. “An Object
Model for Flexible Distributed Systems”. In
Proceedings 1st Annual ASCI Conference, pp.
69–78, Heijen, The Netherlands, May 1995.
[3] M. Makpangou, Y. Gourhant, J.-P. Le Narzul,
and M. Shapiro. “Structuring Distributed Ap-
plications as Fragmented Objects”. Technical
Report 1404, INRIA, January 1991.
[4] J. Mitchell et al. “An Overview of the Spring
System”. In Proceedings Compcon Spring
1994. IEEE, February 1994.
[5] Object Management Group. “The Com-
mon Object Request Broker: Architecture and
Specification, version 1.2”. Technical Report
93.12.43, OMG, December 1993.
[6] L. van Doorn, P. Homburg, and A.S. Tanen-
baum. “Paramecium: An Extensible Object-
based Kernel”. In Proceedings Hot Topics on
Operating Systems V, Orca’s Island, Washing-
ton, May 1995. IEEE.


http://dare.ubvu.vu.nl/bitstream/handle/1871/12864/iwooos.95.pdf?sequence=1&isAllowed=y

Towards object-based wide area distributed systems

Abstract

Similar works

Full text

Available Versions

VU Research Portal

DSpace at VU