• TABLE OF CONTENTS
HIDE
 Title Page
 Main






Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: NCL : a common language for achieving rule-based interoperability among heterogeneous systems
CITATION PDF VIEWER THUMBNAILS PAGE IMAGE ZOOMABLE
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00095356/00001
 Material Information
Title: NCL : a common language for achieving rule-based interoperability among heterogeneous systems
Series Title: Department of Computer and Information Science and Engineering Technical Reports
Physical Description: Book
Language: English
Creator: Su, Stanley Y.W.
Lam, Herman
Yu, Tsae-Feng
Arroyo-Figueroa, Javier A.
Yang, Zhidong
Lee, Sooha
Publisher: Department of Computer and Information Science and Engineering, University of Florida
Place of Publication: Gainesville, Fla.
Copyright Date: 1995
 Notes
General Note: Final manuscript submitted to JIIS (Journal of Intelligent Information Systems) Special Issue on Intelligent Integration of Information
 Record Information
Bibliographic ID: UF00095356
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.

Downloads

This item has the following downloads:

1995195 ( PDF )


Table of Contents
    Title Page
        Title Page
    Main
        Page 1
        Page 2
        Page 3
        Page 4
        Page 5
        Page 6
        Page 7
        Page 8
        Page 9
        Page 10
        Page 11
        Page 12
        Page 13
        Page 14
        Page 15
        Page 16
        Page 17
        Page 18
        Page 19
        Page 20
        Page 21
        Page 22
        Page 23
        Page 24
        Page 25
        Page 26
        Page 27
        Page 28
Full Text






Final manuscript submitted to JIIS (Journal
of Intelligent Information Systems) Special
Issue on Intelligent Integration of Information









NCL: A Common Language for Achieving Rule-Based Interoperability among
Heterogeneous Systems *


Stanley Y. W. Su
Tsae-Feng Yu
Zhidong Yang


Herman Lam
Javier A. Arroyo-Figueroa
Sooha Lee


Database Systems Research & Development Center
University of Florida













NCL: A Common Language for Achieving Rule-Based Interoperability among
Heterogeneous Systems *


Stanley Y. W. Su Herman Lan
Tsae-Feng Yu Javier A. Arroyo-Figueroa
Zhidong Yang Sooha Lee

Database Systems Research & Development Center
University of Florida
Gainesville, FL 32611
-, ,,, ,- I. .11, 1,



Abstract


For achieving interoperability among heterogeneous computing systems, the Object Manage-
ment Group (OMG) has adapted the Common Object Request Broker Architecture (CORBA)
and the use of an Interface Definition Language (IDL) for specifying object properties and oper-
ations which encapsulate the data and programs of heterogeneous systems. This paper describes
a common language which is an enhancement of IDL to include: 1) the semantic richness of EX-
PRESS, an information modeling language adapted by the ISO/STEP community for achieving
product model and data exchange; and 2) the extensibility features and knowledge rule spec-
ification offered by the Object-oriented Semantic Association Model (Os.\\I ). This common
language, named the NIIIP Common Language (NCL), is a part of the R&D effort of a project
entitled the National Industrial Information Infrastructure Protocols (NIIIP). The design of
NCL is standards-based, incorporating the semantic features of the two standard languages,
IDL and EXPRESS, and conforming to their syntaxes as much as possible. It is an extensible
language which supports the addition of new class, constraint, and association types to the lan-
guage and its underlying object model in order to satisfy the diverse modeling needs of virtual
enterprises. The language also contains a high-level rule specification component. Rules in
NCL can be used for defining and enforcing integrity and security constraints, government or
enterprise policies and regulations, and other types of semantic constraints that are local or
global to heterogeneous systems. In this paper, we shall show how such a modeling language
and its supporting KBMS functions can be used to achieve rule-based interoperability in an
active heterogeneous system as an enhancement to OMG's CORBA.

This research is supported by the Advanced Research Project Agency under ARPA Order
No. B761-00 and managed by the United States Air Force under contract F33615-94-2-4447. This
is a part of the R&D effort of the NIIIP Consortium. The views and conclusions contained in this
paper are those of the authors and should not be interpreted necessarily representing the official
policies, either expressed or implied, of all the NIIIP Consortium members, the Advanced Research
Projects Agency, or the United States Government.


1 Introduction

In the past decade, the trend of computing has shifted from large centralized systems to distributed
systems. Some of these systems may consist of a large number of heterogeneous computing systems









interconnected through local, national or international networks. Data sharing and program in-
teroperability across distributed, heterogeneous computing platforms have become one of the most
challenging problems facing the computer science and engineering communities. In order to access
information which are generated, stored and managed by dissimilar information systems and to acti-
vate program services which are available in heterogeneous software systems, national/international
information infrastructure protocols need to be established. Two independent efforts on standards
are particularly relevant to the development of these protocols; namely, the efforts of the Ob-
ject Management Group (OMG) and the International Standard Organization's Committee on the
STandard for the Exchange of Product model data (ISO/STEP).

OMG is formed by a consortium of over 500 industrial companies which aims to define and de-
velop object-oriented technologies for achieving interoperability among dissimilar computing plat-
forms. It adapted a Common Object Request Broker Architecture (CORBA) [OMG 1991] for
achieving object interoperability. The interfaces of all objects of interest are specified in a com-
mon Interface Definition Language (IDL) [Acker 1993, OMG 1991]. An interface specification is
compiled to generate program skeletons and stubs for inclusion into the server programs and the
client programs, respectively. At run-time, a software or human client can make requests for object
services, which are dispatched to the proper servers in a heterogeneous network, thus achieving
client/server interoperability.

The ISO/STEP community, on the other hand, emphasizes the development of standards for
product modeling and product data exchange. One of its major efforts is the development of an
information modeling language named EXPRESS [ISO 1992]. EXPRESS provides a rich set of con-
straint specifications by using keywords, functions, procedures and constraint rules. It is a powerful
information modeling language. The language has been widely accepted and used by a number of
product design and manufacturing communities.

In spite of the individual success and acceptance of these two standards efforts, the result pro-
duced by each does not adequately solve the data sharing and program interoperability problems
found in a heterogeneous environment. For example, the underlying object model of OMG's IDL
is that of C++. While it may be adequate for achieving program interoperability (since the under-
lying data models of most of the existing 0-0 programming languages have the similar modeling
power as IDL), the semantics captured by IDL is not rich enough for modeling complex objects pro-
cessed by many existing application systems. When IDL is used as the common modeling language
to model and encapsulate the objects and object services of an existing application system (e.g., a
relational database application or a CAD application), much of the semantics of the objects cannot
be captured explicitly because IDL does not have the necessary modeling constructs for captur-
ing constraints by keywords and/or by integrity rules. Thus, much of the needed semantics have
to be embedded in the application code. Recognizing the limitations of the object model under-
lying most of the existing object-oriented DBMSs, the Object Data Management Group (ODMG
[Cattell 1995]) and others [e.g., [Florescu 1995]] have made some effort to extend the object model's
capabilities to capture some semantic constraints of data such as "key" and "inverse attribute" con-
straints. However, these extensions are still far from meeting the actual needs for modeling complex
manufacturing products.

On the other hand, although EXPRESS is semantically much richer than IDL and has an
object-oriented flavor, it is not an object-oriented information modeling language because it does
not support the encapsulation of behavioral properties of objects. Unlike methods found in an









object-oriented model, functions and procedures defined in EXPRESS are global properties in a
schema and are used in rules for constraint specifications. However, if we combine the behavioral
specification of IDL and the information modeling power of EXPRESS into a single well-integrated
object model and modeling language, then the resulting object model and language can be ideal
for modeling objects and object services in a network of heterogeneous computing systems. The
language can be designed to conform to the two standard languages (IDL and EXPRESS) seman-
tically and, as much as possible, syntactically. It will be easy to use; particularly for those who are
already familiar with the two standard languages. The design and development of such a language
can also serve as the glue that binds the two very active standard communities which have been
working more or less separately so far.

The limitations of the above two standard languages and the potential advantages of their in-
tegration have motivated our work on an extensible and semantically-rich object model and its
extensible modeling language. This R&D effort is a part of the project entitled the National In-
dustrial Information Infrastructure Protocols (NIIIP) supported by the Technology Reinvestment
Program (TRP) of the Advanced Research Project Agency (ARPA) [NIIIP 1995]. Our objective is
to develop a NIIIP Common Language (NCL) for modeling not only the data and program resources
of some existing (or legacy) systems which are contributed by the organizations that participate in
a virtual enterprise, but also the new organizational structure, workflow management, enterprise-
wide semantic constraints, integrity and security rules, mediation and negotiation procedures and
rules, object associations across systems, etc. The key features of NCL are as follows:

1. The design of NCL is standards-based, incorporating the features of the two standard
languages, IDL and EXPRESS, and conforming to them as much as possible. It follows the basic
principles of the CORBA architecture for interface definition, with the added semantic richness of
EXPRESS.

2. NCL supports additional association types; i.e., different semantics properties can be at-
tached to different types of semantic associations between or among object classes so that, during
the processing of their object instances, the semantic properties of the association types can be
automatically enforced or maintained.

3. NCL contains a high-level rule specification component. Rules in NCL can be used for
defining integrity and security constraints, government or enterprise policies and regulations, and
other types of semantic constraints and interoperations that are local or global to heterogeneous
systems. It allows the specification of events which can automatically trigger the verification of
the states of distributed data and take alternative actions based on the result of the verification.
In our work, we use a rule language which is a part of NCL to define Event-Condition-Action-
AlternativeAction (ECAA) rules associated with object classes.

4. NCL is extensible. Additional semantic properties found in a heterogeneous environment
can be easily introduced into NCL and its object model as new constraint types, class types,
and/or association types. These extensions to NCL are automatically supported during execution,
causing no changes to the language compiler nor the supporting run-time system. In contrast, a
"non-extensible" object model and modeling language have a fixed number of modeling constructs.
The semantics of these constructs are generally fixed in a modeling language as "keywords" and is
"hardcoded" in the underlying system which supports the language. Any change or addition to the
set of modeling constructs will entail changes to the modeling language as well as the underlying









system which supports it. However, different virtual enterprises may have different modeling needs
for modeling the objects, object services, constraints and association types within their own envi-
ronments. New semantic properties in terms of new data, association, and constraint types often
need to be added to the modeling language so as to meet the changing modeling needs of these
virtual enterprises.

The approach taken in our work for achieving model extensibility is to use the object model
to model itself to produce a meta-model. Extending the object model to provide new modeling
constructs amounts to adding new object classes to the meta-model and using them to define the
semantics of new modeling constructs. The semantics of these new constructs are specified by a
number of "parameterized rules" which are automatically bound to those object classes that are
defined by these new modeling constructs. At run-time, the bound rules are ti b:.:. i.1 by the request
monitor and rule processing functions of a knowledge base management system, thus enforcing the
semantics of these new constructs.

The remainder of the paper is organized as follows. Section 2 gives an overall syntactic structure
of a schema defined in NCL which serves to explain the language's main features. Section 3 describes
how extensibility is achieved in NCL. The underlying kernel model of NCL is described. Then, an
example is used to illustrate how the kernel model, parameterized rules, and rule binding are used
to achieve model and language extensibility in NCL. Section 4 describes the implementation of
NCL in a distributed environment. In particular, we shall emphasize the use of NCL in OMG's
CORBA environment. We shall show how the rule-based approach to interoperability enhances the
capabilities of OMG's CORBA in making the Object Request Broker (ORB) "active". Section 5
gives a summary and a conclusion.


2 Description of NCL

NCL is an integration of the language features of IDL, EXPRESS and K.3. K.3 is the version 3
of an implemented knowledge base programming language developed at the University of Florida
[Shyy and Su 1991, Arroyo-Figueroa 1992]. NCL's underlying object model is the extensible ob-
ject model of K.3, which is founded on the concept of objects and object associations introduced
in the Object-oriented Semantic Association Model (OSAM* [Su 1',',]) and its algebra and calcu-
lus ([Su 1993a, Kamel 1994]). NCL uses 1) the method specification facility of IDL, 2) the type
and entity specifications and the keyword constraints of EXPRESS, and 3) the knowledge rule
specification, language extensibility features, and association type specifications of K.3. Instead of
presenting the detailed syntax and semantics of NCL, we shall describe the overall structure of the
language and use an example schema to illustrate the modeling capabilities of the language. We
shall assume that the reader is familiar with EXPRESS and IDL.

Overall Structure of an NCL Schema

(* SCHEMA declaration. *)

(* The SCHEMA class has an inclusion relationship with its component class
types *)
DEFINE SCHEMA schema_id;

END_DEFINE;











(* TYPE declaration *)
DEFINE TYPE type_id = underlying_type IN schema_id;
WHERE (* domain rule in TYPE *)
rule_label_l: expression;

METHODS:
EXCEPTION exception_id (var_l:type_l;..);

METHOD [ONEWAY] method_id
([INIOUTIINOUT] para_id:para_type; ...): return_type
[RAISES (exceptionid, ...)];

END_DEFINE;

(* ENTITY declaration *)
DEFINE ENTITY entity_id IN schema_id;
SUPERTYPE OF (supertypeexpression) (* supertype declaration *)
SUBTYPE OF (subtype list) (* subtype declaration *)
attr_id: [OPTIONAL] base_type [WHERE ([TOTAL]
[CARDINALITY([L1:U1]:[L2:U2])]) ];

DERIVE

INVERSE

UNIQUE

[WHERE (* domain rule in ENTITY *)
rule_label_l: rule_expression_l;

ASSOCIATIONS: (* Other association types *)
INTERACTION OF (attr_link_l:Entity_l;attr_link_2:Entity_2;...)
CARDINALITY
(attr_link_l:attr_link_2= [L1:U1]: [L2:U2];...);



METHODS: (* method declaration *)
EXCEPTION exception_id (var_l:type_l;..);

METHOD [ONEWAY] method_id
([INIOUTIINOUT] para_id:para_type; ...): return_type
[RAISES (exceptionid, ...)];



(* Local rule declaration *)
RULES:
RULE rule_id;










[TRIGGERED triggered_time trigger_operation, triggered_time
trigger_operation, .....]
[CONDITION condition_clause]
[ACTION
statement_list]
[OTHERWISE
statement_list]
END_RULE;

END_DEFINE;

(* Global RULE declaration *)
RULE rule_id;
[TRIGGERED triggered_time trigger_operation, triggered_time
trigger_operation...... ]
[CONDITION condition_clause]
[ACTION
statement_list]
[OTHERWISE
statement_list]
END_RULE;

(* Method implementation *)
METHOD [class_id::]method_id;
[LOCAL
local_var_declaration;
END_LOCAL;]
[statement_list]
END_METHOD;

The above structure gives the skeletal specifications of schema, type, entity, global rule, and
method implementation. The symbols and clauses enclosed in a pair of brackets [ ] can be optional
when other mandatory or optional symbols and clauses are present. The syntax of NCL resembles
that of EXPRESS. However, minor changes have been made to EXPRESS in order to introduce
the language extensibility feature and other added features of NCL.

NCL provides the constructs for defining schemas, data types and entity types. Their defini-
tions are enclosed by a pair of keywords DEFINE and END_DEFINE. In NCL, a schema is treated
as a first class object. The resources of different organizations participating in a virtual enterprise
can be defined by separate schemas and their interrelationships can be specified by associations
among these schema objects much the same way as the associations among data objects. We note
here that, in an EXPRESS schema, ENTITY and TYPE are treated as keywords since they are
fixed constructs of the EXPRESS's underlying data model. In NCL, however, ENTITY, TYPE,
SCHEMA, and any other new class types are treated as identifiers (i.e., a parameter of the keyword
DEFINE). The keyword DEFINE signals the compiler that the identifier following it should match
with a class type defined in the meta-model. Other class types can be added to the meta-model by
the knowledge base customizer who customizes the extensible object model to meet the modeling
needs of an application domain. Any identifier can be used as the name of a class type as long









as the name used in NCL is consistent with the name used in the meta-model in which the class
type is defined. Thus, by adding new class types into the meta-model, we can extend the modeling
capability of NCL, thus achieving NCL's class-type extensibility.

The definitions of TYPE and ENTITY are similar to those of EXPRESS except that their se-
mantic contents have been enriched. In the TYPE specification, the behavioral properties of a data
type are specified in terms of methods which have the same semantic contents as IDL's interface
specifications.

In the definition of an ENTITY, the SUPERTYPE/SUBTYPE specification is the same as
EXPRESS. The attribute specification and frequently-used constraints defined by keywords (e.g.,
UNIQUE, OPTIONAL, DERIVE, and INVERSE, which we shall call "keyword constraints"), are
the same as EXPRESS. Additional constraints, such as 1) TOTAL (i.e., the total participation
constraint which specifies that all the objects in the class from which the attribute draws its values
have to associate with some objects defined by the attribute), 2) CARDINALITY (i.e., cardinality
mappings between the class in which the attribute is defined and the class from which the attribute
draws its values), and 3) other user-defined constraints associated with the attribute, are specified
as identifiers which follow the keyword WHERE. We note here that all the keyword constraints
associated with attributes could have been treated as identifiers following the keyword WHERE
in NCL (just like TOTAL and CARDINALITY). However, they are left as fixed constraints (i.e.,
keywords) in NCL so as not to change the EXPRESS syntax too drastically. Only the extended
constraint types are specified after WHERE. Constraints which are applicable to the entire entity
class are also defined by identifiers following the keyword WHERE as shown in the line with the
comment (* domain rule in ENTITY *). All the keyword constraints used in the language must
match with the constraint types defined in a meta-class ConstraintType of the meta-model. In
that meta-class, a parameterized rules) is used to define the semantics of a keyword constraint
type. For example, the constraint type called TOTAL is defined by a parameterized rule which
specifies in a formal way that all the objects of the underlying domain of an attribute have to be
the attribute values of some entity instances. When a schema is compiled, the rules) is bound
to those attributes or object classes that use the constraint type. If a new constraint type and
its semantic specification in terms of parameterized rules have been added to the meta-model by
the knowledge base customizer, the constraint type can be used in a schema declaration without
having to change the NCL compiler. An example of using parameterized rules and a rule binding
mechanism to achieve this type of model and language extensibility will be given in Section 3.

In an entity class declaration, a number of methods and knowledge rules can be defined which
are used for processing the instances of the entity class. The method and exception specifications
are borrowed from IDL. However, the syntax has been changed to conform to the syntax of K.3.
The rule specification is borrowed from K.3. Different from the constraint rules of EXPRESS,
which are used for specifying inter-attribute constraints, rules in NCL are Event-Condition-Action-
AlternativeAction rules (or ECAA rules). An ECAA rule contains 1) an event (or Trigger) specifi-
cation, 2) a condition specification which may involve the verification of a complex pattern of object
interconnections in multiple object classes and/or a complex quantified expression that involve mul-
tiple attributes of different classes, 3) an action specification which specifies a list of system-defined
operations (i.e., retrieval and manipulation operations) and/or user-defined operations (i.e., meth-
ods) that should be processed if the condition is evaluated to True, and 4) an alternative action
specification whose operations are to be processed if the condition is evaluated to False.









The CAA parts of a rule can be til;--. .1 Before or Immediate-after the occurrence of a trig-
ger_operation specified in the event part of the rule or After a transaction is ready to commit.
A tilb-.-1. operation may in turn trigger other rules. The automatic enforcement of these rules
makes the underlying system active. It has been widely recognized that the concepts and tech-
niques of agents[Carver 1993, Finin 1993, Genesereth 1994, Lan 1992], mediators[Wiederhold 1992,
Wiederhold 1994, Wiederhold 1995] and negotiators[Lan 1993, Moehlman 1992] are very useful for
achieving information and program sharing in a complex, heterogeneous computing environment.
The rule specification mechanism of NCL is useful for implementing agents, mediators and negotia-
tors in a heterogeneous computing environment because their implementations can make use of the
active capability of monitoring events and automatically causing some intelligent behaviors to be
carried out. It should also be emphasized that the rule specification language of NCL is far more
powerful than the constraint rule of EXPRESS because the latter does not have the event/trigger
specification capability nor the specification of complex conditions which involve the processing of
the attributes and object instances of multiple classes. Although EXPRESS allows the inclusion
of functions and procedures in constraint specifications (e.g., f(x) = 2), they are not operations or
methods that can be activated based on the result of a condition evaluation.

The ASSOCIATION specification in the ENTITY declaration is borrowed from K.3. EXPRESS
has the "Generalization" association in the form of SUPERTYPE/SUBTYPE construct and the
"Aggregation" association in the form of attributes. However, different virtual enterprises may
have the need to model different types of objects and their inter-relationships. For example, it is
important to model a workflow in terms of control association types such as Sequential, Parallel,
Synchronization, Dataflow, etc. that connect the activities or processes in a workflow model. The
ASSOCIATION specification allows different association types to be defined in an entity class. In
this example, INTERACTION is treated by the compiler as an identifier which matches with the
definition of this association type in the meta-model. In addition to the Interaction Association,
other association types and their semantic properties can be defined by the knowledge base cus-
tomizer in the meta-model so that they can be used by the users of NCL. Similar to class types
and keyword constraint types, all association types are defined in the meta-model in terms of pa-
rameterized rules. These rules are converted into bound rules at the schema compilation time and
incorporated into the object classes that make use of the association types. At run-time, these
rules are used to enforce the semantics of the association types. This feature of association-type
extensibility allows any semantic relationships between or among object classes (thus, among their
instances) that are frequently used in an application to be defined as association types. Once de-
fined, the user can use these association types to relate object classes without having to repeatedly
specify their rules in all the classes that involve in these types of associations.

Global rules are those rules which are applicable to all objects. If some rules are only applicable
to the objects of some classes, they can be defined in a superclass of these classes and be inherited
by them. This is similar to the definition of common attributes and/or methods in the superclass
of a number of subclasses.

The method implementation provides the actual program code for implementing the corre-
sponding method specification. It can be coded in any programming language. In our work, we
use K.3 as a programming language for method implementations of NCL. Therefore, with the defi-
nition facilities shown in the above structural declaration and the programming language facilities
adopted from K.3, NCL can be considered as a full-fledged, high-level, extensible, object-oriented
programming language.










2.1 An Example Schema in NCL


We now give a simple example of a schema declaration.

DEFINE SCHEMA ManufSchema;
END_DEFINE;

DEFINE ENTITY Part IN ManufSchema
ABSTRACT SUPERTYPE OF ONEOF(Board,IntegratedCircuit,Resistor,Capacitor);
part_no : STRING(10);
description : Text;
avg_cost : Dollar;
qty_on_hand : INTEGER;
part_value : REAL;
no_of_pins : OPTIONAL INTEGER;
DERIVE
wire_connected: OPTIONAL INTEGER := no_of_pins;
INVERSE
used_in: SET OF Product FOR use_part;
WHERE
'1000000000' <= part_no <= '9999999999';
METHODS:
EXCEPTION PART_ERROR(ErrCode: INTEGER; Reason: STRING);
METHOD part_type(IN partno: STRING): VOID;
METHOD type(INOUT partno: STRING): STRING;
METHOD get_part(IN ap: valist) RAISES (PART_ERROR): VOID;
METHOD ONEWAY add_part(IN partno: STRING): VOID;

RULES:
RULE unique_part_no;
TRIGGERED AFTER create(, IMMEDIATE_AFTER update (partno)
CONDITION
EXIST x IN x:Part WHERE
x.part_no = this.part_no AND x != this
ACTION
"Unique constraint violated !!!!\n".display();
del ();
END_RULE;

RULE stock_and_use;
TRIGGERED AFTER create(), update(qty_on_hand,used_in)
CONDITION EXIST p IN THIS *> [usedin] p:Product I
{100 < qty_on_hand < 1000}
OTHERWISE
"RULE: Part::stock_and_use\n".display);
"*ERROR* If a part is used in some product, then the quantity
on hand should be between 100 and 1000".display();
abort();
END_RULE;









END_DEFINE;


DEFINE ENTITY Supply IN ManufSchema;
sup_date: Date;
quality: INTEGER;
ASSOCIATIONS:
INTERACTION OF (supplied_by: Supplier; item_id: Part)
CARDINALITY (supplied_by : item_id = [1:4] : [0:8]);
END_DEFINE;

In the above schema, the object class named ManufSchema is of the class type SCHEMA. Two
entity classes, Part and Supply, defined in ManufSchema, are shown above. Other classes (such
as Supplier) are not shown. The inclusion relationship between ManufSchema and its constituent
classes (e.g., Part and Supply) is specified by the keyword IN. Inside the body of an entity class
such as Part, the structural specification of SUPERTYPE/ SUBTYPE relationship, attribute dec-
larations, keyword constraints, and constraint rules are similar to those of EXPRESS.

In the example schema, two rules are specified. RULE unique_partmo is defined in ENTITY
Part to enforce the constraint that a part number must be unique. This rule is checked after cre-
ating or updating a Part object instance. The CONDITION part of the rule check to see if "this"
object just created or updated has a partno equal to any object instance in the class Part (repre-
sented as the range variable x). If a part number is not unique, the rule condition is violated. A
violation message is displayed and the object instance being processed is deleted. The second rule,
stock_and_use, is ti --j. i .1 after the creation of a Part instance or after an update of the attribute
qty_onhand or usedin. The condition part of the rule is a guarded expression which states if the
part is not used in a product, the rest of the rule is skipped. If it is used in a product, the second
expression following the symbol "I" is evaluated to make sure that the quantity on hand is within
the appropriate range. If it evaluates to True, no action is taken. Otherwise, an error message is
displayed and the operation is aborted. In its general form, a guarded expression can have many
subexpressions before the symbol "I". They are evaluated sequently. If any subexpression is false,
the rule is skipped. If they are all true, then the subexpression after "|" is evaluated. The result of
this evaluation determines the True or False of the entire guarded expression.

The entity class Supply illustrates another important modeling capability of NCL, i.e., the
specification of different types of associations a class can have with other classes. The keyword
ASSOCIATIONS marks the beginning of an association specification. Different types of semantic
associations that an object class has with other classes can be specified in a class definition. In
this example, Supply models an Interaction association (similar to the concept of relationship in
the Entity-Relationship model) between two constituent entity classes, Supplier and Part, which
are connected to Supply via the association links named supplied_by and itemid, respectively. The
cardinality constraint of the Interaction clause specifies that one supplier can supply at least 0 and
at most 8 parts, and one part can only be supplied by at least 1 and at most 4 suppliers. Other
constraints which are implicitly associated with the association type are 1) the referential constraint
and 2) the uniqueness and non-null properties associated with the attribute values of supplied_by
and itemid. We note here that this association type and the constraints associated with this type
are recognized in many data models but they are not supported by EXPRESS.









3 The Underlying Meta-Model of NCL


A meta-model is the result of using the modeling constructs of the object model to model itself. A
part of the meta-model for NCL is shown in Figure 1. The extensible meta-model for NCL begins
with a simple kernel which has similar structural and behavioral specification capabilities as the
object models of many object-oriented systems, including the object model of OMG's IDL. The
main difference is that knowledge rules and parameterized rules can be specified in object
classes to capture the different types of constraints, classes and associations and to implement the
extensibility features of NCL. Each object class (a meta-class or a user-defined class) is defined in
terms of the following properties and knowledge rules:

Structural properties: Attributes and various association types declared in a class specify
the associations between the class and other object classes. Simple (e.g., integer, real, string,
etc.) and ..--:i. --.l.. data types (e.g., set, bag, list, matrix, etc.) are used to define the
domains of attributes. Constraints on attributes and values are specified either by keywords
(i.e., more frequently used constraints) or knowledge rules.

Behavioral properties: Method specifications declared in an object class define the behav-
ioral properties of the class. Exceptions and raising of exception conditions available in IDL
are also included in the method specification section of a schema.

Knowledge Rules: User-defined constraints that are applicable to object instances of an
object class are defined by Event-Condition-Action-AlternativeAction (ECAA) rules, as ex-
plained before. The semantics of class types, constraint types and association types are
defined in meta-classes in terms of parameterized rules which will be explained in the next
subsection.

Starting from the kernel object model, new modeling constructs such as new class types, con-
straint types, and association types can be added into the extensible object model by adding new
meta-classes to define these new types. Thus, by extending the meta-model, we can extend the
modeling capabilities of the object model.

As shown in Figure 1, the kernel model is depicted by rectangles and circles and its extensions
by the shaded rectangles and circles. In the meta-model, the class Object models all objects in
the system. Two subclasses (connected by Generalization or G links) of Object are distinguished:
EClassObject and DClassObject. EClassObject models all the entity class objects (ENTITY in
EXPRESS) and DClassObject models all the domain class objects (TYPE in EXPRESS). Entity
class objects are objects of interest to an application world which can be physical objects, abstract
things, events, functions, processes, etc. An entity class object is assigned a unique identifier (OID).
Domain class objects are self-naming values (e.g., integer 2 or real 5.4) which form the data repre-
sentations of entity class objects or complex domain objects. For example, the entity class Part in
the previous section is defined by attributes partno, description, avg_cost, qty_onhand, etc. whose
underlying domains (i.e., TYPE) are String, Text, Dollar, and Integer, respectively.

As shown in the meta-model, classes, associations, methods, rules, and constraints are E-class
objects whose class types are defined by the meta-classes Class, Association, Method, Rule, and
Constraint, respectively. The meta-class Class has the following attributes and their underlying
domains: name: String, associations: Set of Association, methods: Set of Method, rules: Set of
Rule, and constraints: Set of Constraint. Every class in a knowledge base, including the meta-
class Class itself, is an instance of Class. There are three subclasses of Class: Entity, Domain and











Schema. Entity contains all the definitions of Entity classes as its instances. Domain contains all
the definitions of Domain classes as its instances, and Schema contains all the definitions of the
schemas of a knowledge base as its instances.





I A connector to other classes in the schema

SET represents set-valued attributes EClassObect DClassObect

G Al l
OID

associations SET1
Method Rule lass A Association A defingca Constracnt
A A G A G methods SET A G pe s A G
Method Class
sgnature ee m SET Rule Stnng

S Snn Stnng i Constraint nks Generalization
String SET
ParamRule

Aggregation
--Agrgmo definng_class

G A Interaction

AssocLink ***
a ModelExtl as e class Class
ModelExtension
Class DClassObject
prules SET_7 G lk-n-ae 0 Stnng

ParamRule constuent class Class

ClassType AssocType ConstraintType
constramti SET
A A A Constraints
base class base class base class


Class Association Constraint

Figure 1: Schema of the Meta-Model


A special type of Entity class is the ModelExtensionClass. Object instances in this class include
the definitions of the subclasses of the meta-classes Class, Association, and Constraint (i.e., new
modeling constructs added by the knowledge base customizer). In addition to all the properties
that are inherited from its superclasses Entity, Class, etc., the ModelExtensionClass also has a
set of parameterized rules. ModelExtensionClass is further subclassed into ClassType, AssocType,
and ConstraintType. For example, the definition of the meta-class Interaction is an instance in the
AssocType and the definition of the meta-class Unique is an instance of ConstraintType.


In the figure, the link label A stands for the Aggregation association which models the con-
cepts of Is-a-part-of, Is-described-by, and Is-a-component-of. All attributes of an entity class have
this association type. Generalization and Aggregation associations are the two built-in association
types in the kernel object model. All other association types (e.g., Interaction) are introduced by
means of the association-type extensibility. The definition of each new association type results in
an object instance stored in the meta-class AssocType (a subclass of ModelExtensionClass) along
with its corresponding parameterized rules. The parameterized rules define the semantics of the
association type.











The meta-class Association is defined by the attributes type: String, links: Set of AssocLink,
and defining_class: Class. Its subclasses store all the instances of different types of associations.
Thus, each association instance has a type name, a set of association links, and the name of its
defining class, i.e., the class in which the association type is used. The meta-class AssocLink is
defined by the attributes link_name: String, constituent_class: Class and constraints: Set of Con-
straint. AssocLink connects the defining class to a set of one or more constituent classes and can
have a set of constraints associated with it.

The meta-class Constraint and its subclasses (e.g., Unique) contains all the instances of keyword
constraints used in the schemas of a knowledge base. The definition of each new constraint type
is defined as a subclass of Constraint. After its compilation, an object instance corresponding to
its definition is established in the meta-class ConstraintType (a subclass of ModelExtensionClass)
to store its parameterized rules. The parameterized rules define the semantics of the constraint type.

Given the meta-classes of the kernel object model, a knowledge base customizer can further
extend the meta-model to include new class, association, and constraint types by subclassing the
meta-classes Class, Association, and Constraint, respectively. Modifications to the underlying ob-
ject model can also be made by changing the specifications of the meta-classes and their subclasses.
Note that the meta-model of NCL is the same as that of K.3 because, in its implementation (see
Section 4), NCL is translated to K.3 and its processing is supported by K.3's underlying system.
Since the compiler of NCL, the compiler of K.3, and the underlying system all make use of the
meta-model in their compilation and processing tasks, modifications made to the meta-model will
be reflected automatically in the languages and the underlying system, thus achieving both language
and system extensibilities.

3.1 Parameterized Rules and Rule Binding

We shall use a simple example to illustrate how keyword constraint, association, and class types
can be added to an extensible object model and its modeling language (i.e., NCL) by using param-
eterized rules and a rule binding mechanism. The operational semantics of the Unique constraint
type can be defined by the following parameterized rule in the meta-class Unique, a subclass of
Constraint (refer to Figure 1.):


DEFINE ENTITY Unique IN MetaModel
SUBTYPE OF (Constraint);

RULES:
PARAM_RULE unique;
BIND CLASSES @constraintdef class
TRIGGERED AFTER create(, IMMEDIATE_AFTER update (@link_name)
CONDITION
EXIST x IN x:@constraint_defclass WHERE
x.@link_name = this.@link_name AND x != this
ACTION
"Unique constraint violated !!!!\n".display();
del ();










END_PARAM_RULE;
END_DEFINE;

An instance is inserted in the meta-class Unique in Figure 1 each time the Unique constraint is
used in a class. The parameterized rule named unique is a general rule which is to be translated
into rules that are bound to those classes of a schema in which the keyword constraint Unique
is used (We shall call them the constraint defining classes). For that reason, it uses a parameter
name (@constraint _def_class) to refer to these classes. The event (or trigger condition) of the rule
is either after the transaction that creates an instance of a constraint defining class or immediately
after the update of an attribute denoted by the parameter name (@link_name). The condition part
of the rule is to verify the existence of an instance (denoted by the instance variable x) in the
constraint defining class where the link name of that instance is the same as that of the instance
being either created or updated (denoted by "this"). However, x should not be the same instance
as "this". If the condition is true, then the attribute value is not unique and the action taken is
to display a constraint violation message and to delete the instance being created or updated (i.e.,
"this" instance).

Now, let us assume that the Unique constraint is used in the definition of an entity class Part
as shown below:

DEFINE ENTITY Part IN ManufSchema
ABSTRACT SUPERTYPE OF ONEOF(Board,IntegratedCircuit,Resistor,Capacitor);
part_no : STRING(10);
description : Text;
avg_cost : Dollar;
qty_on_hand : INTEGER;
part_value : REAL;
no_of_pins : OPTIONAL INTEGER;
DERIVE
wire_connected: OPTIONAL INTEGER := no_of_pins;
INVERSE
used_in: SET OF Product FOR use_part;
UNIQUE
part_no;
WHERE
'1000000000' <= part_no <= '9999999999';
METHODS:
EXCEPTION PART_ERROR(ErrCode: INTEGER; Reason: STRING);
METHOD part_type(IN part_no: STRING): VOID;

END_DEFINE;

The difference between this definition of Part and the one defined in Section 2.1 is that, here,
the keyword UNIQUE is used to define the uniqueness constraint for the attribute partno. In the
example in Section 2.1, the uniqueness constraint is enforced by a rule (unique_partmo) explicitly
written by the schema designer. After translating the above NCL specification into that of K.3, the
compiler of K.3 will use the keyword UNIQUE in the definition of partno to find the meta-class
Unique for which the parameterized rule was defined and stored in the meta-class ConstraintType.









The parameterized rule is then converted into the following bound rule which is automatically
included as a rule for the Part class as if the schema designer has written the bound rule explicitly.

RULE unique_part_no;
TRIGGERED AFTER create(, IMMEDIATE_AFTER update (partno)
CONDITION
EXIST x IN x:part WHERE
x.part_no = this.partno and x != this
ACTION
"Unique constraint violated !!!!\n".display();
del ();
END_RULE;

Hence, in this extended model (and extended NCL), the keyword UNIQUE can be used each
time the uniqueness constraint is required for an attribute. There is no need to explicitly define
the same rule repeatedly. The same technique of using parameterized rules and rule binding can
be used to add other keyword constraint, association, and class types into the meta-model. The
meta-model can be tailored to meet the modeling needs of a real or virtual enterprise.

We note again that extensibility in the NCL language is achieved by parameterizing class names,
association names, and constraint names; i.e., treating them as identifiers instead of keywords in
the syntax of the language. During the compilation time, the meta-model is used to guide the
translation and rule binding tasks. Similarly, the underlying system makes use of the meta-model
to perform its tasks and its operations are "driven" by the meta-model. Any extension to the
meta-model will be recognized automatically by the compiler and the system.

In summary, the kernel object model of NCL is rather simple and general. Its constructs for
modeling the structural and the behavioral properties of object classes are the same as those of
OMG's IDL. The user-defined constraints are specified by ECAA rules. The semantics of keyword
constraint types, class types, and association types are defined by parameterized rules which are
translated into rules and are bound to appropriate object classes. Thus, all the added semantics in
NCL that are extensions to the kernel object model are translated into rules. This language design
and implementation strategy is important since NCL can be regarded as an extension of EXPRESS
for information modeling and, as we shall show in the following section, as an extension of IDL for
achieving rule-based interoperability in heterogeneous systems.


4 Implementation and Applications of NCL in a Virtual Enter-
prise Environment

In this section, we shall described the implementation of NCL and its applications. In Section 4.1
, we explain how NCL is implemented by a language mapping to a knowledge base programming
language K.3 and how an NCL schema, which models an application system, is translated into
executable code whose processing is supported by an object oriented knowledge base management
system (OSAM*.KBMS). In Section 4.2, the use of ECAA rules for defining the interrelation-
ships among virtual enterprise servers and product servers and for generating program bindings
to achieve rule-based interoperability in the CORBA environment is described. The concept of
rule-based interoperability and its implementation technique are elaborated by an example. The
implementation status is given in Section 4.3.











4.1 Implementation of NCL


Figure 2 illustrates the general procedure in the use and implementation of NCL. An NCL schema
can be typed in by a schema designer using a text editor. Alternatively, the schema designer can
use a set of graphical tools called XGTOOLS [Lam 1992], which was originally implemented for
OSAM*.KBMS [Su 1992, Su 1993b] and was modified to support NCL, to create an NCL schema.
Also, in cases where some existing schemas are available in some machine-processible form (e.g.,
in EXPRESS, IDL, etc.), the schema designer can make use of the EXPRESS and IDL translation
tools to import these existing schemas in their native form into NCL schemas which can then be
modified, extended and integrated by using the XGTOOLS. The NCL schema is then translated
into an equivalent schema in K.3 which is then compiled into either C++ code (in the case when
NCL is used as a programming language for application development) or C code and IDL specifi-
cations (in the case when NCL is used as an interface definition language). The generation of C++
code for the second case has not been carried out in the present implementation. The binding,
compilation, and execution of the run-time code are supported by the various KBMS components'
functions shown in Figure 2.


EXPRESS IDL
Source Source User User User
XGTOOLS
------ --------------- -------------- ------
NCL
Translation Translation Text raphical Query
G rapnical T loo
Tool Tool Editor Tools Too

NCL schema

7 OSAM* KBMSun-ti
NCL bild-ime --------------------- |----
NCL build-time
Translator KBMS Interface
K3
Schema Dynamic ExpressioRule Bder
Evaluator
K 3 Binder
and Compiler Query Processor Request Monitor
C++
IDL spec and c
Code for "enhanced Io Object Manager Rule Processor
bindings" C+
Compiler

--------- ----------------------------
I Storage Manage Y.t -t, -,


Executable run-time
code Knowledge
Base


Figure 2: NCL Implementation Based on OSAM*.KBMS


The process of translating an NCL schema into the corresponding C++ code is illustrated in
more detail in Figure 3. The other application of NCL for generating program bindings will be
described in Section 4.2.2. First, a translator is used to translate the NCL schema into its corre-
sponding K.3 representation. Then, a K.3 binder and compiler is used to generate .h files and C++
code that corresponds to the structural and semantic properties of the K.3 schema. During the
translation, as we have explained in Section 3, the semantics of keyword constraints, association
types and class types in K.3, which are stored in the corresponding meta-classes as parameterized
rules, are translated into bound rules by a rule binder. These rules are bound to the classes in









which the constraint, association and class types are used. The event/trigger specifications of these
bound rules are used by the K.3 compiler to generate a before-call (for a before-rule associated with
a method activation) and/or an after-call (for an immediate_after- or after-rule) to C++ methods
which implement the CAA parts of the rules. The C++ code produced by the K.3 compiler is then
compiled by a C++ compiler to generate the executable code which is linked with the components
of the KBMS. At run-time, the KBMS functions provide the query processing, rule processing
functions and persistence support to the program. Thus, NCL can be used as an object-oriented
information modeling language for modeling various types of resources of a virtual enterprise such
as people, organizational structure, hardware devices, tools, software components, data entities,
etc. which can be processed and stored in a knowledge base maintained by the KBMS. It can also
be used as a programming language for application system development.


OSAM*.KBMS NCL Compiler

.h files
NCL NCL K.3 K.3 ++ code with calls
schema Translator Binder eme Compiler to KBMS functions
schema e to KBMS functions
K.3 K.3
Schema schema



Attributes and Attributes and
Supertype/subtype Supertype/subtype .h files
Associations Associations
Other
Associations Types c++ code to monitor
Association Bound the execution of each
Keywordain Rules method and to trigger rules
Constraints e
User-defined
Rules c++ code to process
Method Method the rules
Specification Specification
c++ code to implement
each K.3 method
Method Method
Implementation Implementation
in K.3 in K.3

Figure 3: Translation of NCL Schema to C++ Code

As a side remark, a direct translation of NCL to C++ or other programming languages would
certainly be more efficient. The translation to K.3 as an intermediate step in our current imple-
mentation is done to take advantage of the implemented K.3 and its supporting OSAM*.KBMS.

In the above translation process, since the semantics of keyword constraints, association types
(other than the superclass-subclass association), and class types are all translated into bound
rules, an object class in an NCL schema has the following semantic contents: 1) attributes, 2)









superclass-subclass associations, 3) methods, 4) event/trigger information associated with rules,
and 5) methods for implementing the CAA parts of rules. We note that the first three parts
are equivalent to the semantic contents of an IDL specification. Parts 4 and 5 are used for the
enforcement of the rules. Thus, after translation, an NCL specification is in essence equivalent
to an IDL specification, plus rule specifications. This is an important translation technique. As
we shall explain in the next subsection, it enables us to implement NCL within the CORBA
environment to achieve rule-based interoperability.

4.2 Rule-based Interoperability in the CORBA Environment

A simplified version of the NIIIP system architecture is shown in Figure 4. The main goal of NI-
IIP is to provide an infrastructure to support the formation and operation of an industrial virtual
enterprise (VE). An industrial virtual enterprise is formed by a group of organizations to design,
manufacture, and distribute products. Member organizations possess data resources and program
services which are to be shared by other members of the virtual enterprise. In the NIIIP environ-
ment, these resources and services are provided by a set of servers, which are physically distributed,
but are interconnected through an Object Request Broker (ORB), as shown in Figure 4. The in-
terface to the services provided by each server is defined in NCL, resulting in a number of "local
-. 1,. i,.,-". Each local schema describes its services in terms of their data properties, associations,
keyword constraints, rules, and methods. A mediation specification language is being developed
to specify the structural and semantic differences among the attributes, objects and object classes
defined in these local schemas. The integration and mediation of the local schemas, together with
the additional semantics to capture the global virtual enterprise information, form a "mediated
global VE schema". This schema represents the knowledge base administrator's view of the virtual
enterprise. The users of a virtual enterprise may see parts of the knowledge base through some
view mechanism. Human and software clients can access services provided by servers through the
interfaces specified in the global schema. The accesses are controlled by a set of NIIIP VE servers
shown at the bottom of Figure 4. These VE servers are being implemented by the NIIIP consor-
tium members and the KBMS is one of these servers. The product servers represent all types of
legacy systems in an heterogeneous network. They are encapsulated as objects and their services
are defined in NCL just like the VE servers. All these servers are distributed and heterogeneous
servers which communicate with one another through the ORB.

The KBMS provides two sets of services in a NIIIP heterogeneous network system: run-time
services and build-time services to the other VE servers. The run-time services include 1) querying
service for accessing the meta information (e.g., the mediated global schema), the common data
shared by VE servers, and data of interest to some specific VE servers which want to make use of the
services of the KBMS, 2) rule service for processing ECAA rules defined and stored in the KBMS,
and 3) persistent service for storing and managing object instances. The build-time services include
1) the processing and storage of the mediated global VE schema, and 2) the generation of program
bindings for achieving rule-based interoperability based on the keyword constraints, associations,
and ECAA rules defined in the classes of the global schema. Descriptions for all these services are
out of the scope of this paper. For more details about KBMS and its services, the reader is referred
to an invited paper [Su 1995]. We shall focus on the build-time service for achieving rule-based
interoperability in the remaining part of this paper.

In the conventional CORBA environment, the interfaces for all object services are defined in
IDL and are translated into program language bindings (e.g., C or C++) for use by client and










Product Servers


Client Server Server Server



ORB

ji i if i


Session Workflow Mediator KBMS Agent


NIIIP VE Servers

Figure 4: Simplified NIIIP Architecture


server programs. IDL's underlying data model is that of C++. The data model has very limited
modeling power. When it is used as a common modeling language to model the complex objects
and their behaviors found in many application domains such as in product design and manufac-
turing applications, much of the semantic properties are lost. They can only be recovered in a
client's program which receives the data returned by a server. Furthermore, the interoperability
provided by CORBA is "ii. i11....1-1.. .1". It provides a basic mechanism for heterogeneous servers
to make remote method calls. The interoperations among servers are embedded in program code
which implement the methods.

In the NIIIP environment, the interfaces are defined in NCL which, after the translation process
described in the preceding section, are essentially IDL specifications plus ECAA rules. These rules
capture various types of semantic properties and the control relationships among object services.
Thus, in the generation of language bindings, the IDL specifications and ECAA rules can be used to
generate "enhanced" header and skeleton files in such a way that requests for object services (i.e.,
method calls) at run-time would automatically trigger the processing of these rules to enforce the
semantic constraints and to achieve the interoperations among clients and servers. In order to make
use of rules, some mechanisms for monitoring the activation of methods (request monitoring) and
for triggering the processing of methods that implement the CAA parts of rules (rule processing)
are needed. In the remainder of this section, we shall describe our approach for implementing the
request monitoring and rule processing functions in the CORBA environment.

4.2.1 Approaches to Request Monitoring and Rule Processing

We shall consider the following two approaches: interpretive-centralized approach and compiled-
distributed approach:

ECAA rules defined in the object classes of an NCL schema are stored as meta-data in the
KBMS. In an interpretive-centralized approach, when a service request is issued through the
ORB to activate a remote method, a centralized Request Monitor (a VE server or a component
of a VE server) can be used to trap that request at run-time and to make a call to the KBMS to
access those rules which need to be ti l.-. .1 by that service request. A centralized Rule Processor









can be used to interpret these rules, again at run-time, to verify the rule conditions and to carry
out the actions specified by the rules.

In a compiled-distributed approach, rules associated with method calls are compiled into
methods which, when executed, enforce the constraints of the rules. If there are before-, im-
mediate_after- and after-rules associated with a method call (i.e., the event), the compiler will
automatically generate additional method calls and insert them before, immediate_after, and after
the end of the transaction of the method call. These additional calls are calls to the methods which
implement the CAA parts of these rules. Thus, the original method is expanded to include the
additional before-, after-, and/or immediate-after method calls. In this manner, the method speci-
fications of all object classes are modified and expanded at the compilation time based on the rules
defined in these classes. In this approach, the request monitoring and rule processing functions
of the interpretive-centralized approach are distributed among different servers which contain the
methods that trigger rules.

The compiled approach has an advantage over the interpretive approach in term of efficiency.
This is because that run-time accesses to the KBMS and the run-time interpretation of rules, which
are time-consuming, can be avoided. However, in the compiled approach, a modification of a rule
or an addition or deletion of a rule will require the recompilation of those methods affected by
the rule and the re-generation of the code to perform the request monitoring and rule processing
functions. We believe that there are merits in combining the interpretive-centralized approach with
the compiled-distributed approach. Rules which are not likely to change can be precompiled and
their request monitoring and rule processing functions be distributed to different clients and servers
using the implementation technique to be described in the following subsection. Rules which are
likely to change or rules which are added to the heterogeneous network system at run-time can
be stored in the KBMS and be interpreted by an interpretive rule processor. Thus, the KBMS
can provide both build-time and run-time request monitoring and rule processing services. In our
current implementation of KBMS, only the compiled-distributed approach is supported.


4.2.2 NCL to Programming Language Bindings

Recall that Figure 2 shows the general process of translating an NCL schema into either the cor-
responding C++ code in the case of application development or IDL specifications plus C code
in the case of generating program bindings for system interoperability. Figure 5 illustrates the
compiled-distributed approach of generating program bindings in a CORBA environment. An
NCL specification is first translated into the corresponding K.3 specification which defines the se-
mantic properties of classes in terms of attributes and superclass-subclass associations, bound rules,
method specifications, and method implementations. Next, a K.3 compiler is used to translate the
K.3 specification into C code which contains expanded method calls for implementing the request
monitoring and rule processing functions as described in Section 4.2.1. Additionally, IDL speci-
fications for the attributes and the NCL methods are also generated. The reason for generating
the IDL specifications is that these methods which provide services for clients may be physically
distributed in different servers. The IDL specifications provide the means for achieving interoper-
ability through the ORB.

The final step is to generate the C programming language bindings for the NCL methods and
insert the generated C code into the skeletons. The bindings are generated by the IDL compiler










when the IDL specifications are compiled. Each server site has the bindings and the implementa-
tions of its services in its native programming language. A client wanting to use a service will access
that service by using the corresponding binding in the programming language of the client. The
interoperability is provided by the ORB. Note that the bindings reflect the interface of the original
NCL method. However, the implementation of the method consists of the C code to implement the
function of that method, plus the C code to enforce the before-, after-, and immediately-after rules
associated with that method. At run-time, an activation of a method will automatically trigger
the execution of the methods which implement the CAA parts of rules, which may in turn trigger
the method implementation of other rules. It is this enhancement (i.e., the automatic processing of
distributed request monitoring and rule processing functions) which makes the ORB "active" and
provides the rule-based interoperability within the CORBA environment. We shall elaborate
on this concept and technique by an example.

C code to implement
NIIIP NCL Compiler Stubs for the methods
IDL specification clients insert
for methods -
NCL NCL Translator Kernel NIIIP K 3 fr m DLe Skeletons for
Nschema and K 3 Binder s3 Compiler Compiler servers insert
sc3ema C code C code to implement
request monitoring and
rule processing


NCL: IDL + Rules:

Attributes and Attributes and
Supertype/subtype Supertype/subtype filess
Associations Associations
Other
Association Types C code to monitor
Keyword Constraints Bound the execution of each
User-defined Rules Rules method(request monitoring)
Mediation Spec.
C code to implement
methods which enforce
Method Method each rule (rule processing)
Specification Specification--- IDL
Specification .h for client program s
for each n.h for server program -sert
method ".C skeleton for inse
[Optional] - -------- - - - server program insert

SMethod Method C code to implement
Implementation Implementation ) each method
in K.3 in K.3
---------------------------

Figure 5: NCL Schema to C++ code in NIIIP



4.2.3 An Example of Rule-Based Interoperability

Figure 6 illustrates the compilation of a method (A_M1) with its associated before- and immediate-
after rules (R1 and R2) into the compiled code for distributed request monitoring and rule process-
ing. Figure 7 illustrates the execution flow showing how a service request for A_M1 by a client is











monitored to trigger the processing of the appropriate rules.



IDL Specification
sn | NIIIP NCL I I pl C Bindings
class in kernel Compiler C Bindings
NCL form
C Code


Class EXAMPLE in Server A:
attributes ID


method specifications: A
A_M 1 -------- "
A M2
A M2
A M3
A M4


Rules: A
C
Rule R1= Before A M1 F
IF exist X AND (*Y,!Z) TI
THEN call C M1 E
ELSE call A M2
Rule R2= After A M1 A
IF getv() > 0 C
THEN call A M3 IF
ELSE call B Ml TI


IDL compile C bin
)L forA Ml (stub
)LorM *~~^--`------ (stub:

Ml: C implementation for the C ske
surrogate A M1
/* Request monitor for A M */
{ call AMR1 insert code
call A Mlp (original A_M1)
call AMR2 }


MR1: {/* Rule processing for R1 */
code for implementation of insert code
exist X AND (*Y,!Z)
TEN call A M1
LSE call AM2} insert c


dings
) for client


leton for A M1
s f s


ode


insert code
MR2: {/* Rule processing for R2 */ inset
code for implementation of
get() > 0 C code
TEN call A M3 to implement
LSE call BM1} the original AM1
(renamed to AMlp)


Figure 6: Compilation of an NCL method A_M1 and its associated rules



4.2.3.1 Compilation Phase In Figure 6, the definition of a class (named EXAMPLE in Server
A) in NCL is given which includes the specification of four methods (A_M1, A -.I-' A_M3 and
A_M4), and the specification of two rules (R1 and R2). As described in Section 2, NCL rules are
Event-Condition-Action-AlternativeAction (ECAA) rules in which the triggering event can be the
execution of any method. The actual NCL syntax for the two rules shown in Figure 6 are as follows:


RULE Ri;
TRIGGERED BEFORE A_M1()
CONDITION EXISTS x IN x:X
ACTION
C_Mi;
OTHERWISE
A_M2();
END_RULE;


AND (*Y, !Z)


RULE R2;
TRIGGERED IMMEDIATE_AFTER A_Mi()
CONDITION getv() > 0
ACTION









A_M3();
OTHERWISE
B_M1();
END_RULE;

Rule R1 specifies that before method A_M1 is executed, the condition EXISTS x IN x:X AND
(*Y, !Z) should be checked. This condition is an object pattern specification expressed in an object-
oriented query language OQL [Alashqur 1'i,] It verifies if there exists an X object instance which
is associated with some object instance of Y (* is the association operator) but is not associated
with any object instance of Z (! is the non-association operator). If the condition evaluates to
True, then method C_M1 is called to perform some action. Otherwise, method A-_.2-' is called
instead. Also, R2 specifies that immediately after method A_M1 is executed, condition get_v() > 0
is checked. If the condition evaluates to True, then method A_M3 is called to perform some action.
Otherwise, method B_M1 is called.

During the compilation of the class EXAMPLE by the NIIIP K.3 compiler, a C method is
generated for each rule. For rule R1, the C code in method A_MR1 will call the KBMS's Query
Processor to evaluate the condition EXISTS x IN x:X AND (*Y, !Z), and call method C_M1 or
A _. -2 based on the result of the evaluation. Similarly, for rule R2, a C method A_MR2 is generated.

For each method in the class, an equivalent IDL specification is generated. For example, an
IDL specification is generated for A_M1. Furthermore, a new implementation of A_M1 (i.e., a
surrogate A_M1 in C code) is generated. The new implementation consists of three method calls.
First, a call to method A_MR1 is made to process rule R1 (i.e., a before-rule for A_M1). Then, a
call is made to the original implementation of the method A_M1, which is renamed as A_Mlp, to
perform the requested service. Finally, a call is made to method A_MR2 to process rule R2 (i.e.,
an immediate-after rule for A_M1).

In the final step of the compilation process, the IDL compiler is used to generate the C bindings
for all the methods which have been specified in IDL, including method A_M1. After the bindings
have been generated, the corresponding C implementation code for the surrogate A_M1, A_MR1,
A_Mlp (the original A_M1) and A_MR2 can be inserted into the skeleton of A_M1.


4.2.3.2 Execution Phase Figure 7 illustrates the execution flow showing how a service request
for A_M1 by a client is monitored to trigger the processing of the appropriate rules. A client makes
a service request by using the programming language binding (i.e., an IDL stub) generated by the
IDL compiler for a particular method. When the request is made, the ORB would dispatch that
request to the appropriate server to invoke the corresponding method. In the case of the method
A_M4 (see Figure 7), there is no associated rules defined for it. Thus, the code which implements
A_M4 is executed directly and no additional overhead is incurred.

When a request for A_M1 is made, the ORB again dispatches that request to the appropriate
server to invoke the implementation of A_M1 (Step (1) shown in Figure 7). However, in this case
the original code for A_M1 is not invoked directly. Instead, the generated implementation (i.e., the
surrogate A_M1 generated by the NIIIP K.3 compiler) is executed. First, the method A_MR1 is
invoked (Step (2)). The execution of A_MR1 involves the checking of the condition. This requires
a remote call to the Query Processing service in the KBMS to verify the condition, as illustrated in











Step (3) of Figure 7. Let us assume the condition evaluates to True. In this case, the action part
of the rule is executed and a called to C_M1() is made remotely through the ORB (Step (4)). Note
that each call to another method may trigger other rules, which will be handled by the request
monitoring and rule processing code distributed among the corresponding methods.


SERVER A

- .- A MR1 /* code to implement CAA part of
_3 the before rule *
-4 I --- if exist (KBMS QP(
AM44 ( context X AND (*Y IZ)
onginal AM4 retneve X)) /* condition part *
code rno I Then Call C Ml(),/* actionpart*/ -
associated rules} -
Direct method call Else Call AM2(), /* otherwise part */}
-- Tnggered method call
- -- A Mlp { onginal AM() code}

CLIENT ,' ,- -
1 -A MR2 {/* code to implement CAApart of
Call A M4,( A M1 ( the after-rule */
Call A MR1(), -f (get v(> 0) /* condition part *
Call M1), Call AMlp(), -- -_- Then Call AM3(), /* action part */
} R Else Call BM1() ,/* otherwise part */}







KBMSQP {/* This is the code for B Ml1 ( code to implement C M1 { code to implement
the Query Processor of B Ml, may trigger C M1, may trigger
the KBMS other rules ) other rules)



SERVER B SERVER C

KBMS

Figure 7: Execution Scenario


After AMR1 has been executed to process the before-rule Rl, a call to the original AM1 (i.e.,
A_Mlp) is made to execute the code which implements the actual service requested by the client
(Step (5)). After the original AM1 has been executed, a called to AMR2 is made to process the
immediate-after-rule associated with method A_M1. In our example, we assume the checking of
the condition get_v() > 0 is done locally and returns a False. Thus, the otherwise part of R2 should
be processed and a call to BM1 is made.


The above example shows that knowledge rules, which capture all kinds of semantic information
such as security and integrity constraints, expert knowledge, agent behaviors, business constraints,
policies, etc. as well as rules which implement keyword constraints, association types, and class
types (some of which are available in EXPRESS), can be used in conjunction with CORBA/IDL to
achieve rule-based interoperability in a distributed and heterogeneous environment. Furthermore,
the interoperations among VE servers and product servers can also be defined by ECAA rules
(e.g., the activation of a method in the Session server triggers a method in the Workflow server, a
request for data to be made to a legacy relational system triggers a security agent (Agent server)
to verify the access right, etc.). The specification of the interrelationship among servers by a
high-level, declarative rule specification language has the following advantage over the conventional
method-based interoperability of CORBA in which the interoperations among clients and servers









are embedded in program code. First, it is easier for the knowledge base designers and system
implementers to read the rules to understand their interoperations than to read program code
which implement their interoperations. Second, if the interrelationship of clients and servers are
modified or if VE and/or product servers are added (e.g., a new organization joins the virtual
enterprise) or removed (e.g., an organization leaves a virtual enterprise), a modification of rules
to capture the new relationships will be much easier than recoding the programs that implement
their interoperations. The former case requires only the recompilation of the specifications of the
affected classes which model the servers and clients.

4.3 Current Implementation Status

At the time of writing this paper, an NCL-to-K.3 compiler and an EXPRESS-to-NCL compiler
have been implemented. They are being tested and refined. The compiler of K.3, which generates
C++ code for application system development, and IDL specifications and C code for program
bindings, has been implemented and demonstrated. We have used the IBM's implementation of
ORB (i.e., SOM/DSOM [Acker 1993]) to verify the rule-based interoperability concept presented in
this paper. The run-time and build-time supports provided by the OSAM*.KBMS are being tested
in the NIIIP environment in which several VE servers interoperate. The IDL-NCL translator is yet
to be implemented. The modification of XGTOOLS for supporting NCL constructs is in progress.


5 Summary and Conclusion

In this paper, we have stressed the importance of having an object model and language which
is standard-based, extensible, and semantically-rich for modeling the data, software and other
resources of a large, real or virtual enterprise and for achieving rule-based interoperability among
heterogeneous systems. First, we have presented an extensible language, NCL, which combines the
features of EXPRESS, IDL and our own K.3 languages. We then described how model, language,
and system extensibilities are achieved. A kernel model, which is similar to the underlying object
model of IDL, but with additional knowledge rule and parameterized rule specification facilities,
can be extended to capture the semantics of keyword constraints, association types, class types, and
user-defined constraints. The resulting object model and language can more adequately model the
complex structural and behavioral properties, constraints and associations found in product data,
thus offering value-added features to the standard EXPRESS. We then discussed two approaches of
implementing the service request monitoring and rule processing functions of NCL and presented
the compiled and distributed approach to implement them. We have shown that, by using the
rule specification facilities and the corresponding rule processing facilities (rule binder and rule
processor), object classes defined in a semantically-rich object model like NCL can be translated
into rules and IDL specifications. Thus, the implementation of NCL in a distributed environment
can take advantage of the OMG's CORBA/IDL to achieve the rule-based interoperability among
heterogeneous systems. The implementation technique will also make a heterogeneous network
system active since events can be automatically monitored and intelligent behaviors associated
with objects can be automatically triggered. The rule-based interoperability and active feature are
added values to OMG/CORBA.


References

[Acker 1993] L. Acker, et al., "SOMobjects Development Toolkit Users Guide", IBM,









Version 2.0, June 1993.


[Alashqur 1'-'I]



[Arroyo-Figueroa 1992]



[Carver 1993]




[Cattell 1995]


[Finin 1993]






[Florescu 1995]


[Genesereth 1994]


[ISO 1992]



[Kamel 1994]


[Lam 1992]



[Lan 1992]




[Lan 1993]


A. Alashqur, S. Y. W. Su and H. Lam, "OQL- A Query Language for Ma-
nipulating Object-oriented Databases," in Proc. of 15th Int. Conf. Very
Large Databases, Amsterdam, Netherlands, pp. 433-442, August 1',i'

J. A. Arroyo-Figueroa, "The Design and Implementation of K.1: A Third
Generation Database Programming Language," Master's Thesis, Depart-
ment of Electrical Engineering, University of Florida, August 1992.

N. Carver, V. Lesser and Q. Long, "Resolving Global Inconsistency in
Distributed Sensor Interpretation: Modeling Agent Interpretations in
DRESUN," T.,. i10f Annual Workshop on Distributed A, I', ',1 Intelli-
gence, 1993.

R. G. G. Cattell et al., "The Object Database Standard ODMG 93.
Morgan Kaufmann," 1993.

T. Finin, J. Weber, G. Wiederhold, M. Genesereth, R. Fritzson, D.
McKay, J. McGuire, P. Pelavin, S. Shapiro, and C. Beck. "Specification
of the KQML Agent-Communication Language," Enterprise Integration
Technologies, Palo Alto, CA, Technical Report EIT TR 92-04, updated
July 1993.

D. Florescu, L. Raschid and P. Valduriez. "Query Reformulation in Mul-
tidatabase Systems using Semantic Knowledge," Paper Draft, 1995.

M. R. Genesereth and S. P. Ketchpel, "Software Agents," Communica-
tions of the AC I1 Vol 37, No. 7, pp. 49-53, July 1994.

Subcommittee 4 of ISO Technical Committee 184, "Product Data Rep-
resentation and Exchange Part 11: The EXPRESS Language Reference
Manual," ISO Document, ISO DIS 10303-11, August 1992.

N. Kamel, P. Wu, and S. Y. W. Su, "A Pattern-Based Object Calculus,"
International Journal on Very Large Data Bases, Boxwood Press, Vol. 3,
No. 1, pp. 53-76, Jan. 1994.

H. Lam, S. Y. W. Su, et al., "GTOOLS: An Active GUI Toolset for
an Object-oriented KBMS," International Journal of Computer System
Science and E,',.i ',. Vol.7,No.2,pp. 69- ",. April 1992.

S. Lander and V. Lesser, "Customizing Distributed Search Among Agents
with Heterogeneous Knowledge," in Proceedings of the First International
Conference on I, [,r, .i ',i, and Knowledge I,,, i,. ,,I Baltimore, MD,
November 1992.

S. Lander and V. Lesser, "Understanding the Role of Negotiation in Dis-
tributed Search Among Heterogeneous Agents," In Proceedings of the In-
ternational Joint Conference on A, I 'i, "1 Intelligence, August/September
1993.









[Moehlman 1992]




[NIIIP 1995]


[OMG 1991]



[Shyy and Su 1991]



[Su 1-1i,]




[Su 1992]




[Su 1993a]



[Su 1993b]


[Su 1995]


[Wiederhold 1992]


[Wiederhold 1994]


[Wiederhold 1995]


T. Moehlman, V. Lesser and B. Buteau, "Decentralized Negotiation: An
Approach to the Distributed Planning Problem," Group Decision and Ne-
gotiation 1:2, K. Sycara (ed.), pp. 161-192. Norwell MA: Kluwer Academic
Publishers, 1992.

NIIIP Consortium, "NIIIP Reference Architecture: Concepts and Guide-
lines," NIIIP Publication NTR95-01, Jan 1, 1995.

OMG Committee, "The Common Object Request Broker: Architecture
and Specification," OMG Document, Revision 1.1, No. 91.12.1, December
1991.

Y. M. Shyy and S. Y. W. Su, "K: High-level Knowledge Base Program-
ming Language for Advanced Database Applications," AC I[ SI(C I[OD
I,,1i Conf. on if. .i. i, I / of Data, pp. 338-347, 1991.

S. Y. W. Su, V. Krishnamurthy and H. Lam, "An Object Oriented Se-
mantic Association Model (OSAM*)," AI in Industrial Engineering and
_1,,1,;, 1,1,,1, ', ., Theoretical Issues and Applications, American Institute
of Industrial Engineering, 1',i'

S. Y. W. Su and H. Lam, "An Object-oriented Knowledge Base Man-
agement System for Supporting Advanced Applications," Proc. of the 4th
I,I Hong Kong Computer Society Database Workshop, pp. 3-22, Decem-
ber 12-13, 1992.

S. Y. W. Su, M. Guo and H. Lam, "Association Algebra: A Mathematical
Foundation for Object-Oriented Databases," Transactions on Knowledge
and Data E,,.i', ',-i IEEE, Vol. 5, No. 5, Oct. 1993, pp. 775-7',1

S. Y. W. Su and H. Lam, et al., "OSAM*.KBMS: An Object-Oriented
Knowledge-Base Management System for Supporting Advanced Applica-
tions," Proc. of the 1'' ,' AC I1 SI(C I[OD I,, i' Conf. on 1 i ... i,. I,, ,I of
Data, pp. 540-541, 1993.

S. Y. W. Su, H. Lam, et. al., "An Extensible Knowledge Base Management
System for Supporting Rule-based Interoperability among Heterogeneous
Systems," invited paper, Conference on If, -" I,- I',, and Knowledge Man-
agement(CIKM), Baltimore, MD, November 28 December 2, 1995.

G. Wiederhold, "Mediators in the Architecture of Future Information
Systems," in IEEE Computer, March 1992, pages 38-49.

G. Wiederhold, "Interoperation, Mediation, and Ontologies," presented
at the FGCS/ICOT Workshop in Tokyo, 13 Dec. 1994.

G. Wiederhold and M. Genesereth, "The Basis for Mediation," Proc.
COOPIb '1 ; Conference,Vienna Austria, May 1995.









BIOGRAPHICAL SKETCH


Stanley Y. W. Su received his M.S. and Ph.D. degrees in Computer Science from the University
of Wisconsin, Madison, in 1965 and 1'ii,, respectively. He is a professor of the Computer and
Information Sciences and Engineering Department and of the Electrical and Computer Engineer-
ing Department, and is the Director of the Database Systems Research and Development Center,
University of Florida. He is currently serving as Program Chairman of the International Conference
on Data Engineering (ICDE '96). He serves as an editor of the International Journal on Computer
Languages and Information Sciences journal. He is the author of Database Computers: Principles,
Architectures and Techniques, published by McGraw Hill, January 1''"- and has published over
125 technical papers. He is also a member of the VLDB Endowment Board of Trustees, Treasurer
of the Executive Committee of the VLDB Endowment, and an Editor-in-Chief for the International
Journal on Very Large Data Bases.

Herman Lam received his B.S.E.E. from Georgia Tech in 1972; he received his M.E. and Ph.D.
degrees in Electrical Engineering from the University of Florida in 1974 and 1979, respectively. He
is an associate professor of the Electrical and Computer Engineering Department at the University
of Florida. He has been active in the research and development activities at the Database Systems
Research and Development Center for over fourteen years. His research interests are in the ar-
eas of object-oriented computing, distributed databases, and computer architecture for support of
database management. He is co- author of the textbook, Fundamentals of Computer Engineering,
published by John Wiley & Sons.

Tsae-Feng Yu is currently a Ph.D. student in the Database Systems Research and Development
Center, Computer and Information Sciences and Engineering Department, University of Florida,
Gainesville, FL.

Javier A. Arroyo-Figueroa is currently a Ph.D. student in the Database Systems Research and
Development Center, Computer and Information Sciences and Engineering Department, University
of Florida, Gainesville, FL.

Zhidong Yang is currently a Ph.D. student in the Database Systems Research and Development
Center, Computer and Information Sciences and Engineering Department, University of Florida,
Gainesville, FL.

Sooha Park Lee is currently a masters student in the Database Systems Research and Devel-
opment Center, Computer and Information Sciences and Engineering Department, University of
Florida, Gainesville, FL.




University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs