Content uploaded by Patrice Poyet
Author content
All content in this area was uploaded by Patrice Poyet on Oct 14, 2017
Content may be subject to copyright.
21
PerDiS:
AN
INFRASTRUCTURE
FOR
COOPERATIVE
ENGINEERING
IN
VIRTUAL
ENTERPRISE
INTRODUCTION
Fadi
SandaklY*·
I
Joao
Garcia
**,
Paulo
Ferreira
**
and
Patrice
Poyef
*
**
CSTB
,
France.
INESC
,
Portugal
In
this
paper,
we
propose
a
new
approach
to
build
a
Virtual
Enterprise
software
infrastructure
that
offers
persistence,
concurrent
access,
coherence
and
security
on
a
distributed-shared
data
store
based
on
distributed-shared
memory
paradigm.
Software infrastructure still one
of
the major difficulties for concurrent engineering
development especially in large scale projects where participants are geographically
dispersed and belonging to different organizations. To build such infrastructure,
traditional approaches based on remote object invocation like Corba, DCOM and
Java RMI present different limitations when applications manipulate a big amount
of
data. Among these limitations we can cite three major ones: Performance,
security and difficulties to port legacy applications. Remote object invocation on a
WAN or LAN penalizes data sharing between the organizations
of
a virtual
enterprise (VE). On the other hand they lack in offering a homogenous security
model dermed on data and reflecting the complex security relations between partners
of
a VE. Finally, in most
of
the time, porting existing legacy applications to
cooperate in a VE implies their complete re-engineering in order to get descent
performance, to make them working in a concurrent way and to integrate security
constraints.
•
CSTB,
290
route
des
Lucioles,
BP209,
06904
Sophia
An
BP
209,
06904
Sophia-Antipolis,
France,
Tel.:
+33-4-
93
9S
78
06,
fax:
+33-4-
93
9S
67
33,
e-mail:
sandakly@csth.fr
The original version of this chapter was revised: The copyright line was incorrect. This has been
corrected. The Erratum to this chapter is available at DOI:
© IFIP International Federation for Information Processing 1999
L. M. Camarinha-Matos et al. (eds.), Infrastructures for Virtual Enterprises
10.1007/978-0-387-35577-1_37
320
Infrastructures for Virtual Enterprises
In this paper,
we
propose a new approach
to
build
VE
software infrastructure.
This approach
is
based on a platform
of
persistent, distributed and shared memory
called PerDiS. In PerDiS, memory
is
shared between all applications, even located
at different sites or running at different times. This shared memory represents the
shared store
of
a
VE.
Coherent caching
of
data improves performance and
availability.
It
also ensures that applications have a consistent view
of
data, and free
developers from manually managing object location. Using shared memory
paradigm facilitates application porting on the top
of
PerDiS. No need to change the
data structure to make it persistent and/or distributed. To allow concurrent access,
the PerDiS platform provides transactions and locking mechanisms for connected
operations and Check-outiCheck-in mechanism for disconnected ones. Locking and
transactions can be handled transparently by PerDiS. For security, PerDiS
implements a TaskIRole model to manage security attributes and access rights to
data. Communication between distant machines can be secured by encrypting
messages. Security is defined on data and users independently from applications.
Finally, PerDiS manages objects (instances
of
C++ classes for instance)
as
well
as
documents (text files) in the same way.
Different applications have been ported to PerDiS to validate its concepts and to
compare it to traditional approaches. One
of
them
is
a distributed version
of
the
Standard Data Access Interface (SDAI)
of
STEP ISO/I0303 for Product Data
Representation and Exchange.
We
will show performance comparison results
between PerDiS and Corba.
COOPERATIVE
ENGINEERING
IN
VIRTUAL
ENTERPRISE
Today, the global open and fast-changed market push companies to react more
and more quickly to adapt and modify their products. Suppliers
as
well
as
contractors corresponding to different companies, have to be tightly involved in the
design and production cycles. The Cooperative Engineering (CE) techniques have
been generalized giving a new form
of
Collaborative
Work
employed at companies'
level instead
of
persons' level. The term Virtual Enterprise (VE) refers to this kind
of
companies consortium.
We
can define a
VE
as
a temporary alliance
of
independent organizations that come together
to
quickly exploit a product
manufacturing opportunity. They have to develop a working environment to manage
all or part
of
their different resources toward the attainment
of
their common goal.
Obviously, common information definition and sharing is the key problem
of
the
VE. Actually, partners
of
a VE usually have different business rules and information
infrastructure. Being part
of
a
VE
means that a company have to adapt
its
information system (or part
of
it) to the
VE
common information infrastructure in
order to share and exchange project data with other partners.
The main issues
of
such infrastructure are its scalability, its evolution and its
easiness
to
be used and adapted. For scalability, the architecture
of
a
VE
infrastructure has to be independent
of
the number
of
partners, the projects they
work on and the type and the quantity
of
data they manipulate. Furthermore, due to
the fast evolution
of
Information Technologies (IT), this architecture has to be open
and easy to evolve. At the same time it has to be simple
to
use in order to reduce the
PerDiS:
An Infrastructure for
VE
321
cost
of
adapting
the
IT
infrastructure of
each
partner
to
it.
The
main
challenges of
developing
this
kind
of
infrastructure
are:
(/) Definition
of
a
common
data
model
representing
the
information
to
be
exchanged
and
shared
between
partners,
(2)
Definition
of
a
common
sharing software infrastructure that
can
insure:
data
storage,
data integrity,
and
data
security,
(3)
Adapting
the
existing
IT
of
each
partner that
has
to
be
involved
in
the
VB
to
work
with
the
common
data
model
and
the
common
sharing software
infrastructure.
Among
the
significant research efforts in
this
domain
we
can
cite
the
NIIIP
project (NIIIP,
1996)
that
aims
to
develop
open
industry software protocols that will
make it possible for manufacturers and their suppliers
to
effectively interoperate
as
if they
were
part
of
the
same
enterprise.
NIIIP
bases
its
architecture
on
emerging
standards (formal
and
de
facto)
like
STEP
ISO-10303
(Fowler,
1995)
for
data
modeling
and
Corba
(OMG,
1997)
(Mowbray,
1996)
as
a
middleware
for
interoperation
of
different
applications.
Influenced
by
the
OMG
and
Corba
formalism,
NIIIP
views
VE
activity
as
a set
of
Services
offered by partners
with
interfaces
defmed
with
IDL
language
and
laid
on
Corba
standard
services
(OMG,
1998)
like
Naming,
Persistence,
Security,
Transaction,
etc.
While
ISO
STEP
seems
to
offer
a
modeling
language
and
methodology
as
well
as
data
models
that
are
largely
accepted
and
used
in
different
manufacturing
sectors
(Aerospace, Building & Construction, Electronics ...
),
the
Corba
approach
presents,
from
the practical point
of
view,
some
difficulties
to
build
VE
software
infrastructure.
Those
difficulties
can
be
summarized
as
follows:
• Currently,
few
of
the
commercial
object request
brokers
(ORB)
implements
together
all
services
needed
for
a real
VB
like
security, transaction, concurrency
control
and
persistence.
• Corba
is
based
on
remote
method
invocation.
With
this
approach,
objects
used
by
an
application
reside
in
a
remote
host
and
can
only
be
used
via their
functional
interface.
This
is
a disadvantage
when
objects
are
frequently
accessed
because
an
important
amount
of
processing
time
is
wasted
in
communications.
This
increases
considerably a
non-useful
network
traffic.
•
Most
of
the
Corba services
like
concurrency
access,
persistence
and
security
are
defined at the
level
of
objects.
This
means
that
important
problems
like
data
concurrent
access,
security
and
data distribution
(which
is
a major
issue
in
the
application
performance
because
of
the
remote
method
invocation
mechanism)
have
to
be
solved
in
early
phases
of
the
conception
of
an
application.
•
VE
infrastructure
has
to
integrate existing applications of different
partners.
Those
applications
have
to
access
common
data
stores
and
thus
have
to
be
interfaced using Corba
mechanisms,
which
require
a
deep
modification
in
their
data structure
(the
inheritance
graph
has
to
be
changed
to
access
some
Corba
services)
and
sometime
a
new
code
restructuring
to
offer their processing
as
service.
PERDIS
PerDiS
platform
has
been developed
to
overcome
main
limitations
of
traditional
approaches (based
on
remote
invocation)
in
term
of
performance,
security
322
Infrastructures
for
Virtual
Enterprises
mechanisms
and
easiness
of
use.
The
use
of shared-distributed
memory
paradigm
as
a
base
of
PerOiS
implementation
increases
notably
performance
comparing
to
remote
invocation
approach.
Furthermore,
it
facilitates
porting
of
existing
application
without
major
modifications.
On
the
other
hand,
transactions
can
be
transparent to
applications.
PerOiS
offers
a
default
behavior
where
locking
data
is
done
implicitly
depending
on
application
access
mode
to
each
peace
of
data
on
the
store.
For
security,
PerDiS
defines
security
attributes
on
the
data
store
making
them
independent
from
different
applications.
All
these
aspects
will
be
detailed
in
the
rest
of
this
section
to
show
how
they
offer
coherent
data
sharing,
persistence
and
security
and
how
they
reduce
time
and
programming
effort
when
porting
applications
on
top
of
Per
Architedure
,'---
-----
---"
AppliClllion
API
L---'7'r"-...J
:
I
I
BeTl
------------,
macldne
A
I
I
I
I
I
I
I
I
I
I
I
...-----
.....
:
I
I
I
Bdllk
I
...
_----------,
macldneB
,----
----------
-----
-----
-,
AppllCllllon
API
Userl...e9e1
Ubraty
AppllCltion
API
ParDI!
o.mon
_______
________
_
IIlIICldneC
Figure
1:
PerDiS
Architecture
A
PerOiS
system
(Shapiro
et
al.,
1997)
consists
of
machines
running
two
kinds
of
processes:
application
processes
and
a
single
PerDiS
daemon
(PO).
Applications
use
PerOiS
through
an
API,
connecting
the
application
with
the
PerOiS
user
level
library
(PULL).
A
PULL
communicates
with
its
corresponding
PO
locally,
and
POs
communicate
with
each
other
over
the
network.
The
PULL
deals
with
application-
level
memory
mapping,
data
transformations
and
management
of
objects,
locks
and
transactions.
When
the
application,
through
the
API
and
the
PULL,
needs
locks
or
reads
or
writes
data,
it
makes
requests
to
the
local
PO,
which
deals
with
caching,
issuing
locks
and
data,
storage,
transactions,
security
and
communication
with
remote
machines.
A
typical
configuration
is
shown
in
Figure
1.
Note
that
application
processes
are
optional.
In
fact,
the
PerDiS
architecture
is
a
symmetrical
client-server
architecture
in
which
each
node
behaves
both
as
a client
(requesting
data)
and
as
a
server
(providing
data).
A
machine
with
just a
PO
running
behaves
as
a
pure
server.
Objects and clusters
Objects
in
PerOiS
are
sequences
of
bytes
representing
some
data
structure.
They
are
not
limited
to
e.g.
C++
objects.
An
application
programmer
allocates
objects
in
a
cluster,
which
is
a
physical
grouping
of
logical
related
objects.
In
contrast
with
PerDiS:
An
Infrastructure
for
VE
323
current technology
like
Corba
(OMG,
1997),
clusters
are
the
user-visible unit
of
naming,
storage
and
security,
allowing
efficient
and
large-scale data sharing
applications.
In
fact,
a cluster
combines
the
properties
of
a
heap
(programs
allocate
data
in
it)
and
of
a
file
(it
has
a
name
and
attributes,
and
its
contents
are
persistent).
Programmers
use
URLs
(Bemers-Lee
et
0/.,
1994)
to
refer
to
clusters,
e.g.
pds:llperdis.esprit.ec.org/clusters/floor
1.
pis:llJlIItdI
5.IIsprltec.0lJldustenic I
pis:H5CII".1
nrla.frAilu'obJects
Figure
2:
Clusters,
objects
and
remote
references
An object
in
some
cluster
may
refer,
using
normal
pointers, to
some
other object
in
the
same
cluster or
in
another
one,
even
when
the
current
machine
does
not
actually hold
the
pointed-to
object.
While
navigating through
an
object structure,
an
application
may
implicitly
access
a previously
"unknown"
cluster.
For
instance,
Figure 2
shows
two
clusters located
at
two
different
machines.
Starting
from
the
entry
point start
in
the
leftmost cluster,
one
can
navigate
through the objects
e.g.
start->a->b->print
().
implicitly
accessing
the
remote
cluster.
The
same
function could
have
been
called
by
first
opening
the
remote
cluster
and
then calling
first->print
().
Persistence
Persistence
in
PerDiS
is
based
on
persistence
by
reachability
(PBR)
(Atkinson
et
0/.,1983):
an
object
is
persistent
if
and
only
if
it
is
transitively reachable
from
a
persistent
root.
A persistent root
is
a
distinguished,
named
reference
which
is
persistence
by
default.
To
illustrate
PBR,
reconsider
Figure
2.
All
objects
are
reachable
from
the roots start
and
first,
and
thus
they
are
persistent.
If
the pointer
first->c
would
be
set to NULL, objects X
and
Y
would
no
longer
be
reachable,
and
would
automatically
be
deleted.
Destroying the root objects start andfirst would
delete
all
objects
in
both clusters.
The
PBR
model
has
two
main
advantages:
it
makes
persistence transparent
and
frees
programmers
from
memory
management.
Persistence
is
transparent
since
it
is
deduced
from
the reachability
property.
It
frees
the
programmer
from
memory
management
because
programmers
only
allocate
memory;
deallocation
is
performed
by
the system
if
necessary.
This
prevents dangling pointers
and
memory
leakage.
When
porting existing
code,
only
allocation operator
has
to
be
modified
to
allocate
persistent
memory.
No
need
to
modify
data structure
to
make
it
persistent.
Caching and replication
324 Infrastructures for
Virtual
Enterprises
Data distribution in PerDiS
is
based on lazy replication and cooperative caching.
Lazy replication means that the system only makes copies
of
data when an
application accesses it. Cooperative caching means that caches
of
different PDs
interact to fetch the data an application accesses. Replication and caching avoid the
remote access bottleneck because all data access
is
local.
In
addition, since replicas
are kept in several cooperative caches, data requests are spread over several nodes
preventing data access bottlenecks. A potential drawback
of
this approach
is
false
sharing. False sharing occurs when two applications access different data items that
happen to be stored in the same unit
of
locking. Each application has to wait until
the other has unlocked the data before it can access it, even though there
is
no real
sharing. We cope with this by using small locking granularities, which may even
vary over time.
Transactions
PerDiS supports several transaction models: both optimistic and pessimistic
transactions, explicit data locking and page faulting. Furthermore, the PerDiS model
allows for non-serializable views
of
data (private copies) and for reconciliation
transactions. The broad range
of
these transactional facilities
is
motivated by the
application domain
of
cooperative engineering, where interactive applications may
issue long transactions which are unlikely to involve write conflicts but which due to
their length and complexity users do not want to avoid aborting at all costs.
Transactions using implicit locking automatically lock data accessed by the
application. When an application reads data, it will be protected by a read lock.
When an application modifies data it will be protected by a write lock. Modifying
data that
is
already protected by a read lock causes an upgrade
of
the lock from read
to
write.
Implicit locking is mainly provided to make porting existing applications to
PerDiS easy. However, it reduces concurrency and increases the risk
of
dead locks.
Therefore, when developing new applications, explicit locking
is
preferred. Explicit
locking transactions do not use automatic locking, but rely on explicit object intent
requests, using functions like
try_lock
() ,
lock
( ) ,
and
unlock
( ) .
An optimistic transaction defers the locking
of
data to commit time.
If
it then
turns out that some objects have been modified, the optimistic transaction aborts. On
the other hand, pessimistic transactions take locks before they access data.
Serializable intent modes ensure that different transactions don't interfere, even
if
their execution
is
interleaved. A long lasting serializable transaction may block other
transactions and this may not be acceptable for some applications. Therefore non-
serializable intent modes, e.g. based on versions
of
data, are also supported.
All these functionalities are further extended in PerDiS through its two-level
architecture. In PerDiS, there
is
a distinction between local area (LAN) and wide
area (WAN) networks. For each LAN there
is
a node responsible for interacting with
PerDiS servers on remote networks. This site, called a gateway, holds a file cache
and provides any files from machines outside the LAN to local area PerDiS
applications. Each PerDiS server manages a multi-version store where a sequence
of
versions is kept for each file
as
they are submitted for commit by PerDiS
applications. Executing transactions on a WAN using PerDiS does not require that
PerDiS:
An
Infrastructure
for
VE
325
all
servers
involved
are
synchronized.
PerDiS
uses
a
transactional
algorithm
derived
of
MVGV
(Agrawal,
1987)
that
synchronizes
only
involved
servers
at
commit
time.
Furthermore,
this
algorithm
allows
the
file
cache
to
give
coherent
views
of
data
to
applications
without
having
any
knowledge
of
transactions.
Security
Protecting data
in
YEs
is
important
for
two
reasons.
First,
data
often
represents
a
large
amount
of
money
due
to
labor
intensive
tasks.
Losing
data
means
losing
money.
Second,
data
often
represents
knowledge
and
provides
companies
with
a
competitive
edge.
Due
to
the
nature
of a
VE,
partners
cooperating
in
one
project
may
be
competing
in
another.
Therefore,
PerDiS
provides
security
means
(Coulouris
et
al.,
1997)
to
protect
data
in
a
collaborative
environment.
Security
in
PerDiS
consists
of
two
parts:
data
access
control
and
secure
communication.
Data
access
is
controlled
by
groupware-oriented
access
rights
based
on
users'
tasks
and
roles.
This
means
that
one
can
specify
access
rights
for
a
user
having
a
specific
role
in
a
specific
task.
Access
rights
can
be
assigned
on
a
cluster
basis
to
reduce
management
overheads.
Secure
communication
uses
public
key
schemes
for
signed
data
access
requests,
shared
keys
for
encryption
and
a
combination
of
the
two
for
authentication
of
the
originators
of
messages.
DISTRIBUTING STEP
SDAI
The
international
Standard
for
the
Exchange
of
Product
Model
Data
(STEP)
provides
a
basis
for
communicating
product
information
at
all
stages
in
the
product
life
cycle.
The
key
word
of
data
exchange
in
STEP
is
Data
Model
Sharing.
STEP
defines
tools
like
EXPRESS
language
(ISO
10303-11,
1994)
to
develop
data
models
that
can
be
used
in
different
applications
allowing
interoperability
and
common
data
structures
for
data
sharing.
EXPRESS
is
an
OO-like
language
providing
mechanisms
to
model
constraints
on
data
like
Global
Rules
and
the
Uniqueness
of
object
values.
STEP
provides
also
a
defmition
for
data
exchange
(ISO
10303-21,
1994)
which
is
an
ASCII
format
that
can
be
used
to
exchange
data
defined
with
EXPRESS.
Finally,
for
data
storage
and
access,
STEP
specifies
an
application
programming
interface
(API)
called
SDAI
(ISO
10303-22,
1996)
for
STEP
Data
Access
Interface
that
defines
the
way
applications
can
store
and
retrieve
instances
in
databases.
So
applications
sharing
the
same
data
model
can
share
databases.
SDAI
does
not
deal
with
concu"ent
access
of
data
or
with
distribution
of
databases.
Data
security
is
not
defined
in
the
SDAI
neither.
To
open
the
PerDiS
platform
to
the
ISO
STEP
and
to
allow
its
integration
in
the
Building
&
Construction
domain,
we
ported
an
implementation
of
the
Standard
Data
Access
Interface
(SDAI)
on
top
of
it.
This
work
consisted
on
extending
the
SDAI
definition
to
deal
with
data
distribution,
ownership
and
security
problems
to
allow
the
development
of
STEP
concurrent
applications.
In
the
rest
of
this
section
we
introduce
the
SDAI,
then
we
discuss
the
issues
of
developing
a
distributed
SDAI
using
PerDiS.
Architecture of
SDAI
326 Infrastructures for
Virtual
Enterprises
The SDAI is defined in four different schemas written in EXPRESS (see Figure 3):
Application
Pro.'1;l1lm
SDAI
hnplementation
RW
I
RW
R\I
RO
I
SDAI
Session Data I
SDAI
Population Organisation Data
I
S[
AI
Dictionary Data I I Application Data
Repository
Figure
3:
SDAI Architecture
Repository X Repository Y
Figure
4:
SDAI Storage Structure
• The SDAI Dictionary Schema:
It
includes defmitions
of
entities needed to
represent a meta-model
of
an EXPRESS schema.
• The SDAI Session Schema:
It
includes the definition
of
entities needed to store
the current state
of
a SDAI session started by an application. Information stored
are mainly the list
of
repositories opened by the application and their access
mode, current transactions, events and errors.
• The SDAI Population Schema: It defines the organization structure
of
a SDAI
population. A SDAI population is the set
of
instances stored in SDAI
repositories. Three main entities to store instances are defmed in this schema
(see Figure 4):
(1)
SDAI
Model:
is a grouping mechanism consisting
of
a set
of
related entity instances based upon one schema,
(2)
Schema
Instance:
is
a
logical collection
of
SDAI Models based upon one schema. A schema instance
is used as a domain over which references between entity instances (in different
PerDiS:
An
Infrastructure/or
VE
327
models) are supported,
(3)
Entity
Extent:
it groups all instances
of
an EXPRESS
entity data type that exists in a SOAI Model.
• The SOAI
Parameter
Data
Schema: This schema describes in an abstract
terms the various types
of
instances that are passed and manipulated through the
API. It provides defmitions for EXPRESS
simple
types,
EXPRESS entity
instance, EXPRESS entity attribute
value,
aggregations
and
iterators,
etc.
Those schemas are independent
of
any implementation language. The SOAI
language bindings (SOAI Implementations) are specified for computing languages
like
C,
C++, Java and IDL.
Porting SDAI on PerDiS Platform
We discuss in this section the main issues
of
developing a persistent distributed
version
of
a SOAI which allows concurrent data access. Some
of
our design
decisions have been influenced by one
of
our principal goals in PerDiS which is the
fast porting
of
existing applications that were neither developed to work in a
concurrent environment nor
in
a transactional way. To
do
this
we
preserved
as
far
as
it was possible the SOAI API described
in
(ISO 10303-23, 1997) by introducing
implicit concurrent and transactional behavior based on some
of
PerDiS features.
However, we extended the SOAI with a specific distribution and concurrence API
that can be used by new applications.
Persistence
In the SOAI, application data can be either persistent or not. A specific interface is
defined to create and manipulate persistent instances by their unique identifiers
(PID). Unique identifiers are persistent labels attached to persistent application
instances. An identifier
is
unique within the repository containing the SOAI model
that contains its application instance. This approach
is
adapted to traditional
database persistence implementation. PerDiS is based on Persistent Shared
Memory
where no difference exists between persistent and volatile object manipulation. No
need to use unique identifiers to access persistent objects; this is made through
normal pointer navigation. Furthermore,
we
assume from our application domain
that lifetime
of
objects created by an application
is
longer then
its
execution duration
(objects are used by other applications and users). For those reasons
we
decided
to
make all application instances created during a SOAI session persistent. However,
applications can explicitly delete objects from persistent stores. At the same time the
persistence by reachability mechanism takes care
of
removing unused objects
created by applications.
SDAI Storage
Structure
In a SOAI implementation, application instances are stored
in
a logical structure.
These structures will lay on the PerDiS persistent distributed store (POS). The main
object collector in the SOAI is the
Model.
From the application point
of
view, a
model is a set
of
related instances. Another important collector is the
Repository.
A
repository is a collection
of
models. Those two objects are part
of
the application
328
Infrastructures
for
Virtual
Enterprises
data organization and have to be persistent.
Schema
Instances
are also logical
collectors that contain several models related to the same schema. As shown in
Figure 5, all these objects are mapped to PerDiS clusters that are a logical collection
of
application objects.
Distribution Granularity
In the PerDiS approach, the distribution granularity as seen by the application is a
cluster. Physical distribution is hidden and the PerDiS platform can manage this
granularity automatically
or
semi-automatically to optimize performance. From the
SDAI point
of
view, the smallest collector structure
is
the model. Implementing
SDAI models with clusters give applications fine-grain distribution granularity. This
granularity is adjustable because models can contain any number and kind
of
application instances. Inside a cluster, instances can be grouped using entity extent
objects.
ScbemaJ
Model
Scbema
Instancel
Figure
5:
Persistent distributed SDAI implementation in PerdiS. Boxes represent
PerDiS clusters
Concurrent data access
There is no concurrent access specification in the current definition
of
the SDAI.
The main issue
of
concurrent access is the data coherence. Locking mechanisms are
used by applications to ensure the validity
of
data. The notion
of
locking has been
added to our SDAI implementation in two different ways:
PerDiS:
An
Infrastructure
for
VE
329
I.
Implicitly
by
using
the
implicit
locking
mechanism
offered
by
PerDiS
each
time
a
persistent
data
is
accessed
in
a
read
or
a
write
mode.
Implicit
locking
allows
the
porting
ofapplications
(with
low
concurrency)
without
modifications.
2.
Explicitly
by
extending
the
SOAI
API
to
offer
locking
primitives
on
application
instances.
This
allows
the
development
of
new
applications.
Three
different
locking
modes
are
defined:
read-only,
read-write
and
no-guarantee.
The
last
mode
allows
an
application
to
access
data
in
read
mode
without
blocking
applications
that
need
to
modify
this
data.
Transactions
Once
an
SOAI
session
is
started,
application
can
manipulate
instances
in
stores
in
transactional
manner:
the
application
starts
a
transaction,
defmes
the
access
mode
(read-write
or
read-only),
and
then
access
data,
and
finally
it
can
commit
the
transaction
or
abort
it.
We
extend
this
behavior
by
adding
the
no-guarantee
access
mode.
By
default,
transactions
are
mapped
to
PerDiS
pessimistic
transactions.
The
standard
API
is
extended
to
support
the
optimistic
transactions.
EXPERIMENTS
Beside
the
complete
SOAI
layer
ported
on
top
PerOiS,
several
applications
have
been
developed
or
ported
to
PerDiS
to
manage
different
aspects
of
VB
and
to
test
the
performance
of
the
platform.
In
this
section
we
present
two
applications,
the
first
is
a
mapping
program
that
translate
architectural
data
from
the
ISO
AP225
format
to
the
VRML
format.
This
program
has
been
also
ported
on
top
of a
Corba
broker
(Orbix)
and
performance
has
been
compared
to
PerDiS.
The
second
application
is
a
document
management
application
that
allows
to
manage
sets
of
files
distributed
over
several
servers
and
to
access
them
transactionally.
This
application
shows
the
use
of
PerDiS
in
transactional
disconnected
operations
with
different
kind
of
data.
AP225
to
VRML
Mapping Application
ISO
AP225
is
a
standard
format
for
representing
building
elements
and
their
geometry;
it
is
supported
by
a
number
of
CAD
tools.
The
application
presented
here
reads
this
format
and
translates
it
into
VRML
(Virtual
Reality
Modeling
Language),
to
allow
a
virtual
visit to a
building
project
through
a
VRML
navigator.
We
compare
the
original,
stand-alone
version,
with
a
Corba
and
a
PerDiS
version.
The
stand-alone
version
has
two
modules.
The
read
module
parses
the
SPF
file,
and
instantiates
the
corresponding
objects
in
memory.
The
mapping
module
traverses
the
object
graph
to
generate
a
VRML
view,
according
to
object
geometry
(polygons)
and
semantics.
The
object
graph
contains
a
hierarchy
of
high-level
objects
representing
projects,
buildings,
storeys
and
staircases.
A
storey
contains
rooms,
walls,
openings
and
floors;
these
are
represented
by
low-level
geometric
objects
such
as
polyloops,
polygons
and
points.
In
the
Corba
port,
the
read
module
is
located
in
a
server
which
then
retains
the
graph
in
memory.
The
mapping
module
is
a
client
that
accesses
objects
remotely
at
330 Infrastructures for Virtual Enterprises
the server. To reduce the porting effort, only five classes were enabled for remote
access: four geometric classes (Point, ListOfPoints, PolyLoop, and
ListOfPolyLoops), and one (Ap225SptFile) allowing the client to load the SPF file
and to get the list
of
polyloops to map. The port took two days. The code to access
objects in the mapping module had to be completely rewritten.
In the PerDiS port, the read module runs as a transaction in one process and
stores the graph in a cluster. The mapping module runs in another process and opens
that cluster. The port took only one day; we used the method outlined in Section
5.2.
with no modification
of
the application architecture. The PerDiS version has the
advantage that the object graph is persistent, and it is not necessary to re-parse SPF
files each time. The VRML views generated are identical to the original ones.
The stand-alone version
is
approximately 4,000 lines
of
C++,
in
about 100
classes and
20
files. In the Corba version, only 5
of
the classes were made remotely
accessible, but
500
lines needed to be changed. In the PerDiS version, only 100 lines
were changed. All classes were accessible.
Table 1 compares the three versions (Std-Alone for the original stand-alone
application, PerDiS version and Corba version) for various test sets and two
different configurations:
• the
On
1 machine column represents:
(1)
the PerDiS version where the
application access data stored on the same machine,
(2)
the Corba version
where server and the client run on the same machine.
• The
On
2 machines column represents:
(1)
the PerDiS version where the
application access data stored on a different machine,
(2)
the Corba version
where server and the client run on two different machines.
Compared to a remote-object system, even a mature industrial product such as
Orbix, the PerDiS approach yields much better performance.
SPF
Files
Execution
Time
(s)
File
Size
N°
of
N°
of
Std-Alone
On
1
Machine
On
2
Machines
InKb
SPFObjects
Polyloops
PerDiS
Corba
PerDiS
Corba
293
5200
530
0.03
1.62
54.52
2.08
59.00
633
12080
1024
0.06
4.04
115.60
4.27
123.82
725
12930
1212
0.Q7
4.04
146.95
5.73
181-96
2031
40780
4091
0.16
13.90
843.94
271.50
1452.11
Table
1:
Execution time comparison between the 3 implementation
of
the AP225-
VRML mapping application: Stand-Alone version, PerDiS version (on 1 and 2
machines) and Corba version (on 1 and 2 machines)
SPFFiles
Memory
Occupation
Kb)
File
Size
N°
of
N°
of Std-
PerDiS
Corba
(Kb)
SPF
Objects
Polyloops
Alone
In
Memory
Persistent
293
5200
530
2269
2073
710
26671
633
12080
1024
2874
2401
1469
51054
725
12930
1212
3087
2504
1759
59185
Table
2:
Memory occupation comparison
Table 2 shows the memory consumption comparison. This consumption in the
PerDiS version
is
almost identical to the stand-alone one, whereas the Corba version
PerDiS:
An Infrastructure for
VE
331
consumes
an
order
of
magnitude
more
memory,
for
reasons
that
we
have
not
yet had
time
to
elucidate.
This
experience
confirms
our
intuition that
the
persistent
distributed
store
paradigm
performs
better (in both
time
and
space) than
an
industry-standard remote-invocation
system,
for
data
sets
and
algorithms
that
are
typical
of
distributed
VB
applications.
It
also
confirmS
that porting existing
code
to
PerDiS
is
straightforward
and
provides
the
benefits
of
sharing,
distribution
and
persistence with very little
effort.
Project
Manager
Application
The
second application
we
present
in
this
paper
is
a
document
management
application called
the
Project
Manager.
This
application
aims
at
allowing
applications
not
programmed
for
PerDiS
to
manage
sets
of
files
distributed
over
several servers
and
to
access
them
transactionally.
Sets
of
conventional
files
(text
files,
spreadsheets,
CAD
files
...
)
which
are
related
and
needed
as
a
group
in
order
to
perform
an
activity
can
be
put
into
a
common
project.
The
project
manager
is
coupled with a browser
and
any
file
at
a
PerDiS
site,
which
is
made
visible
by
the
local
WWW
server,
can
be
added
to
a
project.
The
coherence
of
the
view
provided
over these
sets
of
files
is
guaranteed
by
the
application.
When
a project
is
created
and
files
are
inserted
into
it,
these
files
are
included
in
the
PerDiS
system
and
therefore
from
that
moment
on
their
coherence,
distribution, persistence
and
concurrency control
are
ensured
by
PerDiS.
Every
time
a
user
wants
to
change
a
project's
files,
he
(she) starts
the
project
manager
and
checks
out the
files
to
a
location
of
his
choice
(local directory, portable
computer,
and
floppy
disk
...
).
The
project
manager
can
then
be
terminated
and
only
has
to
be
started
again
when
the
user
wishes
to
check
in
the
project's
files.
Meanwhile,
any
external application
can
be
used
to
view
or
modify
the
files.
When
the
files
are
checked-in,
a transaction
is
committed
which
guarantees
the
ACID properties
of
the
sequence
of
changes
made
by
the external
application.
CONCLUSION
Today,
the
major difficulty to build a
Virtual
Enterprise
consortium
is
the
lack
of
a
software
infrastructure that
can
integrate persistence, distribution, concurrency
control, coherence
and
security.
In
addition,
there
is
a clear need
for
an
efficient
interface that
allows
a
fast
porting
of
existing applications
to
reduce
the
development effort
needed
to
insure
the
interoperability
of
different tools
from
different partners.
In
this
paper
we
presented
PerDiS,
a
new
approach
to
develop
VE
software infrastructures
using
a persistent distributed
store
which
is
based
on
lazy
replication
and
a global
cooperative
coherent
caching.
This
approach reduces
the
performance
problem by avoiding
the
remote
access
techniques
used
by traditional
distribution
approaches,
i.e.
based
on
RPC.
Furthermore,
PerDiS
includes
features
such
as
implicit locking
and
optimistic
and
pessimistic transactions
to
allow
a
simple
and
fast
porting
of
applications that
were
not
developed
to
work
in
a transactional
and
concurrent
environment.
332 Infrastructures for
Virtual
Enterprises
Another major difficulty
ofVE
is
the definition
of
common data models. For this
purpose, we propose the standardization efforts as a solution. In fact, STEP
techniques and methodologies start to be widely accepted in different manufacturing
sectors. To open the PerDiS platform to a wide range
of
application domains we
implemented a distributed version
of
the Standard Data Access Interface (SDAI) to
develop concurrent STEP tools. More details about PerDiS concepts,
implementation, performance and applications can be found
in
(Ferreira
et
al.,
98).
Acknowledgments
We would like to think all partners
of
the PerDiS Esprit project 22533. Members
of
PerDiS consortium are (in alphabetical order): CSTB (France), IEZ (Germany),
INESC (portugal), INRIA (France) and QMW (Great Britain).
REFERENCES
1.
Agrawal
Divyakant, Bernstein Arthur
J.,
Gupta
Pankaj,
Sengupta
Soumitra.
Distributed optimistic
concurrency
control
with
reduced
rollback.
Distributed
Computing.
Springer-Verlag,
1987.
2.
Atkinson
M.P.,
Bailey
PJ.,
Chisholm
KJ., Cockshott
P.W.
and
Morrison
R.
An
approach
to
persistent
programming.
In
The
Computer
Journal,
26(4):
360-365,
1983.
3.
Berners-Lee
T.,
Masinter
L.,
McCahill
M.
(eds.),
Uniform
Resource
Locaters.
Dec.
1994,
RFC
1738.
4.
Coulouris
G.,
Dollimore
J.
and
Roberts
M.
Security
Services
Design.
PerDiS
deliverable
PDS-R-97-
008.
URL
http://www.perdis.esprit.ec.orgldeliverablesidocsff.D.I.I/ Aff.D.I.I-Ahtml,
1997.
5.
Ferreira
P.,
Shapiro
M.,
Blondel
x.,
Fambon
0., Garcia
J.,
Kloosterman
S.,
Richer
N.,
Roberts
M.,
Sandakly
F.,
Coulouris
G.,
Dollimore
J.,
Guedes
P.,
Hagimont
D.
and
Krakoviak
S.
PerDiS:
Design,
Implementation
and
Use
of
a PERsistent Distributed
Store.
Research
Report
N°
3525,
Oct
98.
INRIA,
France.
URL
http://www-sor.inria.fr/publiIPDIUPDS_rr3525.html.
6.
Fohn
S.
M.,
Greef
A,
Young
R.
E.
and
O'Grady
P.
Concurrent
Engineering.
In
Lecture
Notes
in
Computer
Science,
volume
973,
1995.
7.
Fowler
J.
STEP
for
data
management,
Exchange
and
Sharing.
Great
Britain:
Technology
Appraisals,
1995.
ISBN
1-871802-36-9.
8.
ISO
10303-11.
Industrial
automation
system
and
integration-Product data representation
and
exchange- Part
11.
Description
methods:
The
EXPRESS
language
reference
manual.
1994.
9.
ISO
10303-21.
Industrial
automation
system
and
integration-Product data representation
and
exchange- Part
21.
Implementation
methods:
Clear
Text
Encoding
of
the
Exchange
Structure.
10.
ISO
10303-22.
Industrial
automation
system
and
integration-Product data representation
and
exchange- Part
22.
Implementation
methods:
Standard
Data
Access
Interface specification.
1996.
11.
ISO
10303-225.
Industrial
automation
system
and
integration-Product data representation
and
exchange- Part
225.
Application
Protocol:
Building
Elements
Using
Explicit
Shape
Representation,
1996
12.
ISO
10303-23.
Industrial
automation
system
and
integration-Product data representation
and
exchange- Part
23.
C++
programming
language
binding
to
the
standard data
access
interface.
ISO
TCI84/SC4IWGll
N004.
Jan.
1997.
13.
ISO
14772-1.
The
Virtual
Reality
Modeling
Language,
1997.
14.
Mowbray
T.
J.,
Zahavi
R.
The
Essential
CORBA
-
System
Integration
Using
Distributed
Objects.
1996.
John
Wiley
and
Sons.
15.
Object
Management
Group.
Corba
Services
Specification.
URL
http://www.omg.orglcorbaisectranl.html,
December
1998.
16.
Object
Management
Group.
The
Common
Object Request Broker Architecture
and
Specification
(CORBA)
Revision
2.1.
September
97.
URL
http://www.omg.orglcorbalcorbaiiop.htm.
17.
Shapiro
M.
et
aI.,
The
PerDiS
Architecture,
PerDiS
deliverable
PDS-R-97-002,
URL
http://www.perdis.esprit.ec.orgldeliverables/docs/architecture,
1997.
18.
Solution
for
MES-Adaptable
Replicable
Technology
(SMART
project).
URL
http://smart.npo.org.
19.
The
National Industrial Information Infrastructure
Protocols
(NIIIP)
Consortium.
The
NIIIP
Reference
Architecture (Revision
6).
URL
http://www.niiip.orglpublic-forumlNTR96-
o
IINTR96-0
I-HTML-PS/niplongd.html.
