Virtual Enterprises and Federated Information Sharing

Hamideh Afsarmanesh, C6sar Garita, L.O. Hertzberger

University of Amsterdam, Computer Science Department, Kruislaan 403,

1098 SJ Amsterdam, The Netherlands
{hamideh, cesar, bob} @wins.uva.nl

Abstract. In general, a Virtual Enterprise (VE) is an interoperable network of

pre-existing enterprises with a common goal, where the enterprises can function
together as a single organization. With the objective of developing a reference
architecture and a support infrastructure for VEs, the Esprit project PRODNET
IP (Production Planning and Management in an Extended Enterprise) is
conceived. In the PRODNET architecture, the Distributed Information
Management System (DIMS) component supports the VE information
management requirements and provides a framework to exchange and
cooperatively manage data between VE-member enterprises, while preserving
the autonomy of individual enterprises. The DIMS design is based on an
object-oriented federated/distributed information management architecture,
specifically tailored for the VE paradigm. The focus of this paper is on
describing the design of the federated architecture of the DIMS component.

1 Introduction
Most business enterprises nowadays fred themselves in a very aggressive
environment set by the global competition and fast commercialization streams. To
ensure their survival under these hard conditions, enterprises must reevaluate and
optimize the way they do their business and probably change or adopt new systems,
tools, and methodologies in their internal information processing. Paradigms such as
Virtual Enterprises (VEs) represent a promising solution for those enterprises eager to
adapt to the current market trends, as well as an active area of research and
technological development [3 ], [6],[9], [ 12].
In spite of the lack of a common definition in the literature, a VE can be generally
defined as a network of enterprises that constitute a temporary alliance, in order to
share their costs, skills, and resources, in supporting certain activities. The PRODNET
II project focuses on the design and development of a VE platform to support the
basic important requirements of a number of Small and Medium size Enterprises
(SMEs) that may join efforts to form and function as a Virtual Enterprise.

i This research is partially supported by the ESPRIT project-22647, PRODNET

II of the European Commission, http://cupido.uninova.pt/-prodnet.
 375

The focus of this paper is basically on describing the general design and necessary
architecture and support environment for efficient information sharing among VE
nodes. Here, the issue of enterprise autonomy and different levels of access rights to
shared data are emphasized. It is clear that the degree of trust among enterprises is
limited, and that every enterprise needs to precisely defme the specific information
access rights and visibility levels for every other VE partner. As a result, the support
for the security of shared data and provision of different access rights to shared data
-based on other enterprise's role in the VE- are mandatory to be supported and
reinforced.
In the remaining sections of this paper, the PRODNET II system architecture and
the current design stage of its Distributed Information Management Subsystem
(DIMS) are described. In particular, Section 2 characterizes the main components of
the PRODNET II architecture. Section 3 describes the management of the shared
information in PRODNET II, supported by the DIMS, including the distributed
information analysis process and the current design of the DIMS integrated schema.
Section 4 focuses on the details of the DIMS federated approach, where the
import/export mechanisms and the query processing issues are addressed and
properly described. Finally, Section 5 contains the major conclusions about the work
presented in this paper.

2 The PRODNET II Supporting Platform for VEs

In previous publications a large number of functional and information-handling

requirements for VEs support have been identified [1], [4]. From this wide range of
functionalities, a selected set has been carefully specified for the design of the
PRODNET II reference architecture. In the PRODNET II architecture, every
enterprise in the network of potential VE-members is considered as a "node", where
each node may play the role of a material supplier, a producer, or a final consumer of
goods or services. Every PRODNET II node is composed of: an "Internal Module", a
"PRODNET Cooperation Layer (PCL)", and an "Advanced VE Coordination"
module, as depicted in Fig. 1 [2],[4].
The Internal Module (IM) of a node consists of the company's information
management systems, its internal decision making processes -namely its Production
Planning and Control systems (PPC), and other engineering systems necessary to
accomplish its local tasks. The Internal Module is extended with a Mapping Module
(MM), which supports all the interactions between the Internal Module of an
enterprise and its PCL.
The PCL supports the functionalities for inter-operation between a given node and
other nodes in the network. All the data sharing and exchange among different nodes
is handled through the PCL. The cooperation layer itself consists of several intemal
components as illustrated in Fig. 1, and described briefly below.
A PCL internal work:flow, specifying the desired cooperation behavior of each
enterprise, will be executed and controlled by its Local Coordination Module (LCM).
Thus, the LCM of an enterprise handles all Cooperation Events between this
 376

enterprise and other enterprises according to the specified rules defmed by this
enterprise.

Fig. 1. Description of the PRODNET II general architecture.

The STEP and EDI components primarily support the exchange of technical
product data and the commercial order-related data respectively. The Human
Interface module supports the enterprise's end-users interaction with the PCL. The
Configuration component determines the necessary elements and functionality of the
enterprise within every VE in which it is involved.
The PRODNET II Distributed Information Management System (DIMS)
cooperatively supports all VE information management requirements, and provides
an interoperability platform to exchange and cooperatively manage large amounts of
data between VE-members.
The Advanced Coordination Functionalities (ACFs) module provides some
additional functionalities to extend the scope of the PCL, including the advanced
coordination of VE-related activities, and supporting tools for logistics operations.
The Network Layer component supports the communication of this node with
other nodes in the VE. Two different communication protocols are deemed:
PRODNET Internal Communications Protocol (PICP), and the PRODNET External
Communications Protocol (PECP). The PICP supports all interactions between the
PCL and both the Internal Module and the Advanced VE Coordination module of the
enterprise. The PECP supports all interactions between a given PCL and all the other
nodes in the network. This protocol supports the exchange of security and
authenticity parameters among nodes.
 377

3 Management of Shared Information in P R O D N E T II

In this section we f'trst discuss the results of the analysis of the information which is
shared and exchanged among VE member nodes, and then we describe the high-level
PCL integrated schema that captures all the information needed to support the proper
PCL operation.

3.1 Analyzing the Shared and Exchanged Information

In general terms, the Virtual Enterprise domain constitutes a fractal-shaped network

of interrelated nodes with complex functional and information management
requirements. Analyzing the wide variety of shared and exchanged information
among VE member nodes, and achieving a comprehensive description and
classification of this information, are some of the difficult tasks tackled within
PRODNET II. We have followed a step-wise approach in this analysis that is
described below:
1. Definition and study of several distinct focus areas. First, we divided the study
domain into three focus areas that represent the main kinds of interactions and
exchange of information between different elements of the PRODNET II
architecture. The three focus areas consist of: a) the exchange of information
between the Internal Module and its cooperation layer PCL; b) the exchange of
information within the PCL needed by the PCL components in order to operate
properly and provide the expected functionality; c) the exchange of information
between every two nodes in the virtual enterprise.
2. Identification of the local, imported and exported information. As a first step
towards modeling this diverse information for every enterprise, we divided the
enterprise information into three categories of Self, Acquaintance, and Virtual
Enterprise information with corresponding intuitive meanings (the details of this
classification approach and their further division into private, restricted and public
information, are outside the scope of this paper). As a result of the performed
analysis, it was possible to determine: a) which part of the information is generated
and stored in this enterprise and thus becomes local (i.e. Self and some local part
o f ht e VirtualEnterprise information); b) which part of the information needs to be
accessed from the other nodes and thus needs to be imported from other enterprises
(i.e. Acquaintance and some other enterprises information related to the Virtual
Enterprise); c) which part of the local information needs to be shared with other
enterprises and thus needs to be exported to other enterprises (a part of the Self
information and some local part of the VirtualEnterprise information).
Sections 4.1 and 4.2 describe the federated architecture of the DIMS that handles
the local, import and export schemas for the enterprise, while supporting the expected
data location transparency for the user, distributed query processing, site autonomy,
access security, and reliability, among other requirements. However, every enterprise
needs to have access to both its local information and the information imported from
other enterprises, and thus the two parts of information need to be integrated into one
 378

coherent schema for the sake of enterprise's convenience of access and retrieval of
information. Then clearly, always a part of this integrated schema represents the local
schema (of which a part is also exported), and the other part represents the imported
schemas at the node.

3.2 General Schema Design for the PCL Information

Based on the initial analysis and identification of different variety of information, an

integrated object-oriented database schema for enterprise information has been
designed [2], as depicted in Fig. 2. The schema represents a uniform class hierarchy
and association relationships representing only the high-level categories of
information handle within the PCL. Since the design stage of the DIMS for
PRODNET II is still an on-going task, different parts of this schema are still being
extended as long as the other components of the PCL are being progressively defined.
This schema diagram is described in the style of the Object Modeling Technique
(OMT) notation [7].
The class def'mition representing the integrating point in this schema is the PCL (in
the middle of the schema). The PCL information is basically composed of three major
parts: local PCL components' information (on the left side of the diagram), VE-
related information (on the bottom right side of the schema diagram), and directory
information (at the lower right side of this schema diagram). The detailed description
of the schema components is beyond the scope of this paper, and only the relevant
information classes are described when necessary.

4 Design of the DIMS Federated Architecture

In order to support the information management requirements, and proper

interoperation among PCLs in different nodes, a federated database architecture is
designed for the DIMS module in PRODNET II [ 1], [4].
The federated architecture approach has proved to adequately facilitate and support
the sharing of information between enterprises, while providing the necessary
visibility levels to ensure their own autonomy and information privacy. The designed
federated architecture has its roots in the PEER federated database system, developed
at the University of Amsterdam [11]. A survey of other related work on federated
database system is described in [8]. Other approaches for distributed information
management in the context of VE support platforms can be found in other related
projects such as NIIIP [5] and VEGA [12].
In NIIIP, the information is uniformly modeled in an object-oriented framework.
A number of object-oriented local conceptual schemas are defined; one for every
individual VE member organization. However, the detailed specification of NIIIP
data management services is still under development and so far there is still little
information available.
 379

In VEGA, the Distributed Information System (DIS) is supported by a "CORBA

access to STEP" layer. Through the CORBA architecture the physical distribution of
the documents is handled. The DIS works on a single data model: the STEP data
model. The DIS is a distributed database and in comparison to the federated approach
chosen for PRODNET II, the concepts of export, import, and integrated schemas, and
the support for information security and hierarchy of information visibility and access
levels, are not directly addressed in this system architecture.
The remaining of this section focuses on the two main functions of the federated
DIMS system for PRODNET II: support of data exportation/importation, and the
distributed query processing.

[ Local_Coordinatol~j~
haa_LCM
has_self_dir

ha~_STE~ ~_~ has_others..dtr

has_CM I I'CL
has..pcl_config f-'---'-- . 1
Iw 1

'LocalConfigarator
has_other.partner
hcL~jelf ~rtner has localinfo

has edllnfo

has_step_lnfo

Fig. 2. High-level integrated schema for the PCL of an enterpnse.

4.1 Data Exportation/Importation and Visibility Rights

Since different enterprises must have different visibility levels and access rights to
other nodes' information, every node in the federation must decide what part of the
information to make available to every other partner in a particular VE. Namely, the
level of visibility and access that other parmers have on the local PCL schema of a
given node must be clearly determined by that node. To accomplish this objective,
every node can preserve its autonomy and privacy by defining one detailed individual
view on its PCL local schema, for every other node with which it shares information.
The individual view defines the corresponding access fight of other nodes to this
node's local data. Furthermore, for every class defined in the local schema, the
 380

individual view determines which instances (i.e. horizontal class partitioning) and
which attributes (i.e. vertical class partitioning) of those instances will be made
available to the other node.
The concept of individual view definition on the local schema for every external
"user", is the basic idea. However, we have generalized the basic idea of an
individual view to the definition of a complete hierarchy of views. The hierarchy of
views allows the grouping and classification of common view characteristics,
facilitating in this way the task of individual view definitions. As an example, let us
assume that there are three different kinds of roles that a given node can play in a VE:
coordinator, supervisor (subordinated to coordinator but enabled to monitor certain
VE activities), and regular VE partner. At the first level of visibility, it is needed to
extract the data which corresponds to every given VE from the PCL local schema.
Namely, a horizontal partitioning of information needs to be done that chooses "all
information related to one VE". After this primary partitioning, a second level of
visibility is defined for every VE view, through a vertical partitioning that supports
the proper information "access rights for the individuals in different groups of users".
For instance, the VE coordinator will obviously have more access visibility to VE
partners' data than a simple regular VE partner, due to its inherent control,
monitoring, and possibly auditing responsibilities. Similarly, a supervisor in charge
of the proper accomplishment of a specific subtask inside a VE, will have more
access visibility to partners' information than other regular VE partners, but certainly
more limited than the VE coordinator. Furthermore, at the third level of visibility, the
definition of the view, even at the level of partners of the same VE, can still be
different for every particular partner, since a node needs to and may decide to
exchange different information with every other VE member. Clearly, if the
definition of more levels of visibility becomes necessary, the view hierarchy can be
extended and modified.
Please notice that the view definitions on the PCL schema, in fact represent the
export schemas derivation from that PCL's local schema in the federated database
architecture of the DIMS. Conversely, notice that there is no need to actually import
any schema structure from other nodes. No import schemas required due to the fact
that the base schema structure is the same for both the exported and imported at every
PCL, at the same time not all the information is available to every given node due to
the visibility levels detrmed by their view definitions.
In Fig. 2, the export views are encapsulated in the class Exp_View_Set, associated
with every other VE-partner (Other_Partner class) of this enterprise in a particular
VE.

4.2 General Design for Distributed/Federated Query Processing

In general, there are two kinds of queries that need to be handled. In the first place, a
query can be issued at this node against the integrated schema. This query in turn can
be a local query which can be answered without acquiring any information from other
nodes, or it can be a query to external nodes (distributed query) which involves the
 381

retrieving of information from one or a specific set of nodes. When a locally issued
query arrives to the DIMS, it must be determined if the query is a local query or a
distributed query. To make this distinction, the query must be parsed and analyzed in
search of for instance, specifications of partners' ID corresponding to OtherPartners.
The processing of a distributed query may involve the decomposition of the queries in
a set of subqueries which need to be sent to other nodes. For example, any query on
the Local_Info involving other partners, must be sent to the corresponding nodes,
where the query will be evaluated against the view definition (for this node) and the
results (if any) will be sent back.
The second kind of queries arriving to the DIMS represent the subqueries sent
from another DIMS in order to solve a query against its integrated schema. At the
receiving node, these queries can be seen as remote queries which need to be
evaluated against the corresponding export schema according to the requesting node.
The remote queries comply with a given format to facilitate the processing at the
target node. An initial query format is presented in Fig. 3. First of all, since there are
many different kinds of messages exchanged between enterprises' PCLs, there is a
msg_type field in every message that identifies if the message is actually a DIMS
query message. The second field is a unique identifier for the query, set by the
originator DIMS. The third and fourth fields correspond to the identifications of the
origin and the target nodes, respectively. The fifth field identifies the VE (if any) to
which the query is related and for which the information is requested. Finally, the last
field is reserved for the content of the query itself.

I I I I ece ver'd I I I
Fig. 3. Structure of an inter-PCL query message.

In summary, in all cases that a query is issued by a user or an application to the

DIMS (local queries against integrated schema), the federated query processor of the
DIMS involves the following steps:
1. Determine if the SQL query can be answered locally (local query)
2. If the query is a local query then
2.1. Evaluate the local query and prepare the result
3. If the query is a distributed query then
3.1. Identify the external nodes that must receive the query
3,2. Decompose the query into subquery messages involving only one partner
3.3. Send a PECP to every partner node with the corresponding subquery msg.
3,4. Wait for the results of the subqueries evaluation at the different nodes
3.5. Merge the partial results and prepare the f'mal result
4. Return the result

I I qu~ I ' nd~ I r~176 I r~ I

Fig. 4. Structure of an inter-PCL query-result message
 382

On the other hand, when a query arrives from another node, a number of steps
must be followed to convert the incoming remote query into a local query. As
described earlier, the PCL schema definition is the same in all nodes. Therefore, any
node can issue a query against the "imported" part of this schema. But clearly (from
previous descriptions), the access rights of every node to the data that it can import
from a second node are precisely specified in the export (individual) view defined for
the origin node in the target node. Therefore, the arriving query will be evaluated
against the corresponding view. However, before this query evaluation step, first the
specification of the query needs to be altered (rewritten) according to the particular
view definition. For example, the class names in the individual views will defmitely
be different than the actual class names (the views cannot have the same name as the
original table, because the table and view names must be unique). Since the actual
class names are the ones used by the incoming query, these names need to be replaced
by the names for the corresponding local view. After this, the query can be evaluated
locally, and all the visibility access constraints are preserved. When the result is
obtained, it must be returned to the sender of the query, using the node identification
that is contained in the PECP DIMS message.
More specifically and following the PCL schema and the view mechanism details
introduced earlier in this paper, the sequence of steps that must be followed to process
an external query includes:
1. Identify the VE(s) involved in the query
2. Identify the OtherPartner instance corresponding to the sender partner, which is
associated with the VE
3. Get the specific partner view associated with the partner
4. Rewrite the incoming query replacing the specified table names with the view
table names (defined in the partner view)
5. Evaluate the rewritten query (it is evaluated on the locally defmed views)
6. Find the results
7. Create a "query-result DIMS message" with the results
8. Embed the query result in a PECP message and send it back to the original node
The format of a DIMS query-result message is represented in Fig. 4. The target
node for the query places the corresponding query_id, places its ID as senderid,
places the ID of the sender node in the field receiverid, and appends to it the result
of the query. As mentioned before, these messages will also be embedded in PECP
messages (all PECP messages are properly encrypted and secured by the Network
Communication Layer Component of the PCL).

5 Conclusions

The paradigm of cooperative virtual organization represents a very broad research

area with a large growing potential. Federated databases have proved to provide
particularly attractive features for handling some open-issues in information
 383

management for the virtual organization domain. In this paper, special emphasis was
given to several of these federated information management issues in VEs, through a
description of the general design of the DIMS for the PRODNET II project.
The proposed DIMS approach properly supports the main information
management requirements identified in PRODNET II for the VE paradigm, such as
the cooperative information sharing and exchange, node autonomy, information
visibility and access rights for a wide variety of kinds of exchanged data among VE
nodes. In general, the presented DIMS design represents a federated architecture,
which has been specifically tailored to handle the complex interoperability and
functionality requirements set by the VE paradigm. One novel feature of the DIMS
approach presented in this paper is its unique architecture, in which the "PCL
schema" is shared in all nodes but the data is imported/exported according to proper
access privileges det'med in the hierarchy of export schemas for external nodes.

References

[1] Afsarmanesh, H; Camarinha, L. - Federated Information Management for Cooperative

Information - in proceedings of the 8th Int. Conf. on Database and Expert Systems
Applications (DEXA'97), September 97.
[2] Afsarmanesh, H; Garita, C; Hertzberger, L.O.; Santos, V. - Management of Distributed
Information in Virtual Enterprises : The PRODNET Approach - in proceedings of the Int.
Conf. on Concurrent Enterprising (ICE'97), October 97.
[3] Browne, J.; Sackett, P.J.; Wortmann, J.C (1994) - The system of manufacturing: A
prospective study, Report to the DG XII of the CEC.
[4] Camarinha, L; Afsarmanesh, H; Garita, C; Lima, C - Towards an Architecture for Virtual
Enterprises; The Second World Congress On Intelligent Manufacturing Processes &
Systems, Budapest, Hungary, June 1997.
[5] The NIIIP Reference Architecture, 1996, http://www, niiip.org.
[6] Rabeio, R.; Camarinha-Matos, L.M. - Towards agile scheduling in extended enterprise, in
Balanced Automation Systems II, L.M. Camarinha-Matos, H. Afsarmanesh (Eds.),
Chapman & Hall, June 1996.
[7] Rumbaugh, J. et al - Object-Oriented Modeling and Design, Prentice Hall, 1991.
[8] Sheth, A. et al. - Federated database systems for managing distributed, heterogeneous and
autonomous databases. ACM Computing Surveys, Vol. 22, No. 3, September 1990.
[9] Silberschatz, A. et al - Database Systems: Breaking Out the Box. SIGMOD Record, Vol.
26, No. 3, September 1997.
[10] Walton, J.; Whicker, L. - Virtual Enterprise: Myth & Reality, Journal of Control, October
96.
[11] Wiedijk, M.; Afsarmanesh, H.; Hertzberger, L.O. - Co-working and Management of
Federated Information-Clusters. 7th Int. Conf. on Database and Expert Systems (DEXA'96),
Lecture Notes in Computer Science 1134, pp 446-455. Springer Verlag, September 96.
[12] Zarli, A. et al - Integrating Emerging IT Paradigms for the Virtual Enterprise: Ghe VEGA
platform. In proceedings of the Int. Conf. on Concurrent Enterprising (ICE'97),
Nottingham, England, October 97.