The communication is not a regular client-server communication as system and .... interaction patterns in the dedicated library to modify the kind of control (e.g., ... attached to the same attribute, we have to deal with interaction rules merging.
Distributed Access Knowledge-Based System: Reified Interaction Service for Trace and Control Anne-Marie Déry1, Mireille Blay-Fornarino1, Sabine Moisan2, Borice Arcier1 & Léonard Mule1 1 I3S ESSI BP 145 06903 Sophia Antipolis Cedex France 2
INRIA BP93 06902 Sophia Antipolis Cedex France
Abstract: This paper explains our approach to help users graphically trace and control the behavior of distant objects in a knowledge-based system (KBS). This working context implies tackling several problems: numerous, varied and heterogeneous entities to distribute; dynamic and interactive communications; bi-directional control; user-friendly means of expression. Our approach is based on an architecture using an existing tool (DICO*) that allows connecting distant heterogeneous objects through an interaction mechanism. We also offer two kinds of dedicated and extensible libraries of trace and control interactions. We have tested this approach in a prototype proving the advantages of these two libraries as well as those of DICO* to distribute KBSs. Our reified interaction service accommodates adaptive multi-access to a KBS without modifying its code. , ,QWURGXFWLRQ
As of today, knowledge-based systems (KBS) often belong to highly distributed environments. A KBS usually comprises a knowledge base, an engine and some predefined graphic interfaces. When knowledge base users reside in various distant locations, remote execution and teamwork become necessary. Since the knowledge stored in the knowledge base and used during execution by the engine represents the main concern in KBS, distributed access to the knowledge base during execution is a key point we want to address. In our case, the knowledge base holds instances of objects; so execution of the KBS eventually results in adjusting some of the attribute values. In order to follow execution, users may either visualize these alterations i.e. trace KBS behavior or induce changes according to their own criteria i.e. control KBS behavior. So we have a bidirectional communication between system and users. Split between system (program control) and users (interactive control), execution is in fact directed by the knowledge base as it switches from system to users and vice versa. Moreover, users do not all want nor need to visualize the same information ; and if they did, their requests would not always be simultaneous. They might need to dynamically decide what to trace or what to control, depending on the application context. Several users may also want to trace or control the same attributes: multi-access must be managed reliably. Section II introduces our working context, the application domain and the problems we faced due to the specificity of the application: numerous and varied entities to distribute (attributes), dynamic and interactive communications, bi-directional control and need for user-friendly trace and control expressions to allow scientific use by non computer-scientists. Section II explains our proposed basic approach to connect heterogeneous objects, using reified interactions [1] and the corresponding tools we have developed in the form of extensible libraries based on an interactive service. We have put this approach into practice in an example of graphic interface for trace and control described in section IV. ,, 'RPDLQ$SSOLFDWLRQ3UREOHPV
This paragraph briefly reviews our working context. In order to help users graphically trace and control behavior of distant objects in a knowledge-based system we wondered how to connect these objects in the KBS to the corresponding graphic elements in a GUI, so that modifications in the KBS are reliably reflected in the GUI --1
and vice versa. The end-users, who are not computer scientists, dynamically decide on these connections not only according to the KBS evolution, but also according to their own perspective on the problem resolution. The KBS we are interested in are written in C++, based on a common framework, named Blocks [2]. Objects are therefore instances of C++ classes and may have attributes of various types (even another class). Attributes in Blocks are accessed during KBS execution throughout two predefined methods (respectively to set or to get the value of the attribute). In addition, Blocks also provides access to the range of possible values for an attribute. The distant GUI used to trace and control the KBS is written in Java, because it is a convenient, popular, Internet friendly language for graphic interfaces. The graphic interface offers different graphic facilities to follow the evolution of objects’ attributes. Depending on the type of the attribute, some graphics are more convenient than others, e.g. for a simple value (string or number) a text field with the value may be enough, while a combo box works better for a known range of values. Giving KBS users the possibility to remotely trace and control objects of the KBS via their attributes implies coping with different problems listed in the following paragraphs. These problems are inherent to the specificity of our context and increased by the remote access to the data. Accessibility of Attributes. Potentially, numerous entities of varied types can be remotely accessed in a KBS, namely all attributes of all objects. Accessing them is very simple at an abstract level (via the get-/setValue methods), but on a concrete basis, remotely accessing a value implies the client knowing its type. It so happens that, due to the various kinds of knowledge managed by a KBS, we have lots of different attribute types. Known basic types (e.g. integer) are managed by any platform (CORBA [3], RMI [4], DCOM) and do not necessitate additional processing, but such is not the case with specifically structured types as objects. It makes no sense to beforehand distribute all the attributes since only a small fraction of them will actually be accessed and predicting with certainty which will be chosen is rather difficult. So, in this kind of application, objects and attributes need to become remotely accessible dynamically. Naming. Users must be able to easily name the data they want to trace and control. In the KBS environment itself, unique naming is provided for objects and attributes (because an attribute name is unique in a class). How to provide the same naming features for a remote KBS and allow dynamic access to objects not distributed beforehand is the problem. Control of KBS Objects. Our approach not only offers tracing capacity but also controlling options. In order to do so we must provide a bi-directional communication between the system (KBS) and the users (via the GUI). The users may want to control the system to constrain an observed attribute, restricting for example its range of values. One may also want to momentarily modify a behavior, changing for example the access permissions of an attribute. So, KBS objects are dually controlled, their behavior is monitored to inform the GUI or adjusted from the GUI. The communication is not a regular client-server communication as system and GUI are both in turn client and server. Evolution. On the one hand, from a behavioral point of view, the dynamic nature of KBS requires to dynamically decide which attributes to control and which kind of control to apply according to the application evolution. For example, it might be important to temporarily trace the value of a specific attribute (say the speed of a car) and, when this value exceeds a given threshold, to forbid further modifying it. To that end, a user simultaneously requires visualizing the attribute during a specific step of the execution and restricting its value range; and later removing this restriction. On the other hand, depending on the evolution of the KBS and on the users needs, new kinds of controls may occur. For example, an user might wish to connect a statistic calculator to trace and control the evolution of attribute values. So, defining statically all the traces and controls required by the end-user is impossible: dynamic definitions are required. User adapted Expression of Control. As intended users are not computer scientists they must be given userfriendly means to first express and control what they want, then share the results with others. Merging of Controls and Collaboration among Users. Ensuring a consistent and reliable global behavior of interacting objects becomes crucial as soon as a system allows users to dynamically add new controlling interactions. For instance, if a user restricts the possible range of an attribute and also traces the evolution of the -2
value of the same attribute, both controls could safely be merged. But sometimes two controls cannot be merged. For example, if a user wants to set the lower limit of a car’s speed and later sets the upper limit of same car at a contradictory level, it makes no sense in the same execution context: no merging can take place. If we further accept that different users can simultaneously control the same KBS, the merging of their controls has to be clearly defined and users should have the visibility of all the control interactions attached to the attributes they want to control. Heterogeneity of Objects. The heterogeneity of the objects to control (in C++) and of their graphic representations (in Java) has to be addressed by the communication platform in an effortless way. This heterogeneity of programming languages is usual and necessary because visualization and control of KBS imply a light graphic client and Java is well adapted to this aspect, though it is not to the execution part. In conclusion, since KBS systems are usually not ready for distribution, rewriting them is difficult and errorprone. The problems addressed in this paragraph (multiplicity of objects and types, dynamic distribution, bidirectional control) are not directly answered by the traditional approaches based on CORBA (OMG), COM (Microsoft), etc. The following section introduces a more suitable environment which ultimately delegates the communication level to CORBA. ,,,
3URSRVHG6ROXWLRQ
We choose to manage the control and trace between KBS and the GUI with an existing tool, DICO*, that allows to connect distant heterogeneous objects by means of an interaction mechanism [1,5, 6]. This mechanism is based on two notions. At the class level interaction patterns describe all the possible connections among classes of the application and at the instance level reified interactions represent actual connections among instances. A DICO* interaction is expressed by rules (written in a specific language, called ISL). An ISL rule describes how the behavior of an object should change when it interacts with another one. In object-oriented languages, behaviors correspond to class methods. A rule modifies the code of a method. For example, an attribute connected to a graphic object for tracing purposes, must inform its graphic representative each time its value changes. The mechanism of DICO* allows adding and removing interactions at runtime. Moreover, this environment relieves the programmer from network technologies (delegated to CORBA). This section develops the features of DICO* that fulfill the requirements identified in the previous section. The first paragraph explains the concept of interaction The second one introduces the libraries developed for this application. The third one details DICO*. $ 8VHRI,QWHUDFWLRQV
To show how interactions are created and used in KBS, we will take as an example the connection between a float attribute and a graphic speedometer gauge. The interaction modifies the attribute’s behavior when it is set (setValue method). The method code is altered to produce the following behavior: if the value is over a given limit, it stores that value in a log object, else it assigns it to the attribute. In both cases the speedometer displays the new value. It happens in two steps managed by different actors. Firstly, during the definition of the KBS, the KBS designer defines a pattern of interaction between the classes Attribute, Speedometer and Log. PI : interaction pattern ConditionalTrace1(Attribute attribute, float limit, Speedometer sp, Log l) { attribute.setValue(floatval) -> if (val < limit)) then l.memorizes(val) else attribute.setValue(val) ; sp.update(val); endif; } Secondly, during execution of the KBS, the end-user may decide to use this pattern to connect the speed attribute of an instance of Car (say, MyCar) to an instance of Speedometer (say CarSpeedometer) using an Log object. The corresponding DICO* instruction is: instantiate(“ConditionalTrace1”,MyCar$speed,100, MyCarSpeedometer, SpeedLog) Please note that the same pattern of interaction can be used for a wide range of attributes in different objects (i.e. PI could be used for the speed of other cars, as well as for a bank account debit attribute, etc.). -3
The use of DICO* instructions is tedious for non computer scientists. That is why we offer programming support for these two steps, in the form of two libraries for trace and control interactions: one to help the KBS designer define patterns of interaction for a given KBS, and a second one to help the end-user exploits the patterns to connect objects at runtime. These libraries are detailed in the next paragraph. % 'HGLFDWHGDQG([WHQVLEOH,QWHUDFWLRQ/LEUDULHV
We introduce firstly the generic library used to control and trace any knowledge-based system, secondly an application library generated from it for a specific KBS, thirdly how to create interactions; lastly we touch upon interaction merging before concluding with a discussion. *HQHULF/LEUDU\
The KBS designers define interaction patterns for a given KBS to put at end-users’ disposal. For instance in our case, they chose basic graphic elements and interaction patterns adapted to the final GUI. In order to do so we provide a generic library containing a minimal set of generic interaction patterns (GIP). Each GIP is a template interaction pattern, parameterized by a value type. One GIP can generate different interaction patterns. This library then introduces a third level (generic interaction patterns) in addition to the two previous ones in DICO* (patterns & interactions). The relationships and the uses of these three levels are summarized in figure 1.
Generic Pattern of Interaction
KBS designer
generates Pattern of Interaction …
End-User
Trace(Attribute,GraphicObject )
Pattern of Interaction Trace1(Attribute,Gauge)
instance of Interaction
…
Interaction (Trace1,MyCar$speed, Gauge1)
Figure 1: The three levels of the interaction mechanism. Plain arrows show basic use while dotted arrows denote infrequent use.
In our case the GIPs concern the connections between attributes and graphic elements. The KBS designer selects some of them (examples are displayed in figure 2). The first generic interaction pattern in this figure is the basic one to visualize an attribute when its value is modified. This interaction changes the behavior of the setValue method: not only call the method but also update the display of the graphic object connected with the attribute. The generic interaction pattern GIP2 introduces a conditional and a concurrent reaction (denoted by //) to indicate an off-limits value. GIP3 adds a delegation to the conditional aspects of GIP2 i.e. the value of the attribute is set only for a substantial difference but otherwise is delegated to another object (a log storing intermediate values). This GIP is the template of the interaction pattern reviewed in paragraph A. Finally, GIP4 is an example of control on an attribute via a graphic element. When this graphic entity is updated, the new value is assigned to the attribute, and vice versa.
-4
GIP1 : generic interaction pattern trace (Attribute attribute, graphicObject g) { attribute.setValue(T val)-> attribute.setValue(val); g.update(val); } GIP2 : generic interaction pattern outOfBounds (Attribute attribute, T bound, GraphicObject g) { attribute.setValue(T val)-> attribute.setValue(val) // if (val > bound)) then g.paint(Red); endif }} GIP3 : generic interaction pattern ConditionalTrace (Attribute attribute, T limit, GraphicObject g, Log l) { attribute.setValue(T val)-> if (val < limit)) then l.memorize(val) else attribute.setValue(val); g.update(val);endif }} GIP4: generic interaction pattern traceAndControl (Attribute attribute, modifiableObject g) {attribute.setValue(T val)-> attribute.setValue(val); g.update(val), g.setValue(T val) -> g.setvalue(val)// attribute.setValue(val) } Figure 2: Examples of generic interaction patterns (using an ISL-like syntax).
The generic library is common to all KBS and application-independent. It only relies on Blocks accesses to attributes and on a graphic kernel of display elements (based on Java AWT) and associated entities (Log, Vector, Listeners). Its contents results from the analysis of common trace and control requirements of KBS users. This library however can be extended, e.g., KBS designers may also define new generic interaction patterns, should there be a need for different trace or control interactions. End-user dedicated libraries can be produced from this generic library. )URPD*HQHULFWRD'HGLFDWHG/LEUDU\
Once the GIPs have been selected, a dedicated library of interaction patterns can be generated, e.g. to link a given KBS to a GUI. For instance, to generate an interaction pattern tracing the value of a float attribute with a gauge and name it, the DICO* instruction is: generate(”trace”,”float”,”Gauge”,”trace1”). The first argument is the name of the generic interaction from which the pattern is generated (trace), the second one is the type of the traced attribute (float), the third one is the specialized graphic class used for visualization (Gauge) and the last one is the name of the pattern. In the same way, creating an interaction pattern to flash a signal (if e.g., an attribute exceeds a given limit – 130 in our example --), is done via the following instruction: generate(“outOfBounds”,”real”,130,”Light”,”outOfBounds1”), where Light is a subclass of GraphicObject. The existence of this instruction is hidden to the KBS designer, whose abstraction level is higher.. It generates interaction patterns, as shown in Figure 3.
interaction pattern trace1 (Attribute attribute, Gauge g) { attribute.setValue( val)-> attribute.setValue(val); g.update(val);} interaction pattern outOfBounds1(Attribute attribute, Light g) { attribute.setValue(val)-> attribute.setValue(val) // if (val > 130) then g.paint(Red); endif }} Figure 3 Example of ISL generated patterns )URP,QWHUDFWLRQ3DWWHUQVWR,QWHUDFWLRQV
The last step is the creation of interactions in order to design the end-users’ GUI. The DICO* instruction instantiate (“trace1”,MyCar$speed,myGauge) creates an interaction that connects the attribute speed of the object Mycar to the graphic element myGauge so that each time the value of the attribute is changed, the gauge is updated. In this way the KBS designer creates an initial GUI. The end-users will use it either as is or they can select other interaction patterns in the dedicated library to modify the kind of control (e.g., replace trace1 by OutofBounds1 to connect speed and myGauge). Moreover, they can even write new interaction patterns. -5
0HUJLQJ5XOHV
When several interactions are attached to the same attribute, we have to deal with interaction rules merging. Let us postulate the speed of MyCar is connected to both a speedometer and a light in order to signal speeding. To achieve a coherent behavior, the ISL rules must be merged, if possible (see discussion paragraph C.3). In this case the result at execution time is the same as if we have defined the following pattern: { attribute.setValue(val) -> attribute.setValue(val) ; g .update(val) // if (val > 130) then g.paint(red); endif } 'HGLFDWHGDQG([WHQVLEOH/LEUDULHV 'LVFXVVLRQV
The design of these two libraries answers some of the problems stated is section II. Evolution. According to the application domains, we have shown that a set of patterns of interactions can be defined in order to facilitate the expression of control. This set can dynamically be enriched with new patterns of interactions which can also be shared with other people. Expressiveness. Due to ISL declarativity any user can already use interaction mechanisms, all the more with the added notion of generic interaction pattern. The calls to all DICO* instructions are preprogrammed. But, since intended users are generally not familiar with computer science, ISL syntax might be improved upon to become closer to natural language. Collaboration among users. The above mentioned merging of ISL rules partially solves the problems inherent to the users collaboration by preserving a behavioral consistency in the set of interactions attached to the same attribute. However, this does not addresses coping with distributed reasoning engines and knowledge bases, as well as with several communicating KBS. Access permission to the information (for instance should all interaction patterns be accessible to all end-users?) must also be worked on. & ',&2 WR0DQDJH,QWHUDFWLRQVEHWZHHQ2EMHFWV
DICO* is an implementation of the interaction service which has been used in this application. ,QWHUDFWLRQ6HUYLFH
An interaction service [7] provides support to dynamically define interaction patterns and to modify the behavior of objects according to interaction patterns dynamically instantiated. Interaction patterns are defined outside the object classes using ISL language (described throughout examples in section III). The objects could be located on several sites and implemented with different programming languages. This service is based on a distributed architecture containing several components, the most important ones are: • The Interaction Server: the heart of the service external to applications. It deals with interaction patterns (definition, instantiation, etc.); • The Interacting Interface defines the minimal API of all the interacting objects. It defines operations to add or remove interactions and to display the current control resulting from interaction merging. ',&2 $UFKLWHFWXUH
DICO* is an implementation of an interaction service based on CORBA (using Orbacus[8]) to manage remote invocations and wrapping on interacting objects. These objects may be implemented in either C++ or Java. When connected objects are not remote, DICO* manages the distribution throughout “local servers”. Local servers are distributed objects that communicate with an adapted naming server (naming manager). The naming manager handles the naming service as a distributed service among local servers. Whenever a new object is created on a site, its logical name is registered in the corresponding local server and declared to the naming manager. The attributes do not require to be declared, even if they contain objects. Afterwards, the new object can be accessed remotely via its local server. The communication between two remote objects becomes possible without indirection to the naming manager because it updates each local server naming tables when necessary. Indeed, we have chosen to embed the “references” to the connected objects using local managers to translate strings as CORBA requests. -6
The software architecture used to support the KBS application is described in figure 4. Interaction Server
Naming Manager
Bus Corba
Register(LocalServer,LogicalName,LocalName)
addRule
Interactions : direct calls
Knowledge Base
Local Server
Local Server
GUI
Java
C++
Figure 4: DICO* Architecture, KBS example
In order to trap all message calls to interacting objects, we use meta-programming (OpenC++ [9] and Open-Java [10]) on each class of potentially interacting objects. A meta-object is plugged on each interacting object to manage its interactions; in particular it handles interaction merging. Thanks to meta-programming the KBS code needs not be modified but only reprocessed. The following table summarizes the role of each architecture component.
In order to Interaction Server
Naming Manager
Functionality
Allow dynamic definition of IPs handle IO
- Storing and accessing IPs - Binding IOs - Removing interactions on IOs - Getting interactions on IOs Distribute non remote objects using - Declaring a new IO naming - Refunding an IO from its logical name
Local Server
Remotely access local Objects - Invoking an operation on a local IO Remotely access non distributed - Calling an operation on a remote non distributed objects object
Meta Object
Control access to its IO and manage -Evaluating an invocation (evaluating interactions) its interactions - Adding or removing interaction rules
IO: Interacting Object (implements Interacting Interface) IP: Interaction Pattern 'LVFXVVLRQ',&2 RQ$UFKLWHFWXUH
Let us see now more precisely to which degree the problems stated in section II. are solved by this architecture. Accessibility. In order to manage dynamic invocations from the KBS towards the user interface, adding behaviors to take in charge the distributed accesses would dramatically increase the size of the KBS. Moreover, to prevent users or KBS to load --statically or dynamically-- as many stub classes as the potential entities to access, we decided to use a portal to access remote objects and attributes on each involved application. This is what local servers in DICO* do.
-7
Naming. The solution proposed by the naming manager (which relies on CORBA naming service [11]) and local servers of DICO* allowed us to reuse the local naming of the KBS platform: to each KBS is associated a local server that can retrieve an object or an attribute on the basis of its name. This solution does not imply extending the initial KBS naming feature. Similarly, we associate to each user application a local server to name objects interacting with a KBS object. Control and Evolution. DICO* automatically handles a part of the control expression because it allows expressing interactions between the GUI elements and the KBS objects. In fact, ISL interactions are n-ary and not directional. The notion of client-server communication is flexible with this mechanism. The possibility provided by the interaction server to dynamically add or remove interactions between graphic objects and class attributes is an answer to adapt the control to user needs. Merging of controls and collaboration among users Interaction servers and meta-objects take in charge the management of interaction merging. When an user tries to connect objects by instantiating an interaction pattern, this request can be refused if the new control is incompatible with the previous ones. An user can display the control interactions attached to an object. He can also display the instances of interaction patterns in which an object is involved. ,9
([DPSOH %XLOGLQJD*8,IRUWUDIILFVLPXODWLRQ
The reviewed architecture has been used to develop a prototype and use it to build an adaptive GUI to control a KBS simulating road traffic (Fig. 5). In this example, the KBS holds representations of vehicles (e.g., a class named Car) and of zones of various types (roads, car parks, sidewalks). The KBS reasoning directs their moves: for example, they are not allowed to drive everywhere, or only under given speed limits. The interaction libraries have been enriched with interaction patterns dedicated to this application. The prototype’s two parts are: on the right, the GUI dedicated to traffic simulation and on the left a system to build or modify the right one. The left part is divided into three frames: •
•
•
The KB Object Chooser frame lists the controlled KBS objects; it allows users to select an attribute to visualize or control with existing interaction patterns. The user can define a new interaction from existing interaction patterns or display all attribute attached interactions, and in this case, activate, remove or modify one of them. Only an active interaction is effective in the GUI. Figure 6 shows a zoom of this frame. The Interaction Maker frame allows visualizing interaction patterns and defining new ones from generic patterns or directly with ISL if the library does not suffice. We can see the definition of a speedControl interaction pattern, which sends a message if a car speeds upon entering a given zone. With the tab Instance, the user can visualize or delete existing interactions. The Graphic Object Library holds graphic elements pertinent to this application. To add a new interaction the user clicks the graphic objects he wants connected with the attribute selected in the Object Chooser. Adding new graphic types is also possible.
The right part corresponds to the Graphic User Interface. It is built by the KBS designer and used by end-users to visualize and control objects of interest. The car is represented by an icon which displays the position of the KBS car named my_car. The color of the icon changes to show a speeding car, as specified by the interaction chosen figure 6. The slider allows users to visualize or to control its speed. The end-user can either change the car speed by adjusting the slider cursor or the car position by dragging its icon. This is done dynamically during the reasoning and does not mean modifying the KBS code.
-8
Figure 5 : Trace and Control of a road traffic KBS
Figure 6: Choice of an interaction for speed attribute
The same prototype is used by KBS designers who designed the traffic simulation GUI and by end-users who either use this GUI as is or modify it (e.g., replace the progress bar by a text field or change the speed limit in the interaction).
-9
9 &RQFOXVLRQ
This paper describes a new approach that enables adaptive control and trace of a KBS at runtime. After highlighting the problems of the target application, we suggest a solution in terms of an implementation of an interaction service and two kinds of extensible and dedicated interaction libraries. The libraries allow the design of interfaces adapted to control and trace KBS, provided that a suitable graphic library is available. They hence respond to the requirements for the control and evolution of KBS objects and partially to a natural expression of control. The implementation of DICO* provides the means to support accessibility to attributes and transparent communications among heterogeneous objects. DICO* architecture takes also in charge the naming of objects. The mechanism of merging of ISL rules provides a partial answer to the problem of collaborative work. It remains to be validated when several users set different rules simultaneously on the same object. Currently, the cost of DICO* is only one indirection at execution time compared to using CORBA or RMI, but the development cost is far lower than with these approaches. Moreover, our approach does not necessitate code rewriting. In addition, this application led us to add a layer above basic ISL language (for generic interaction patterns in particular). This demonstrates the possibility of defining such layers for other application domains, while keeping a minimal ISL language kernel. The extension of ISL to generic patterns is also an important point of this work, to facilitate the addition of an application level to ISL. But ISL syntax still needs to evolve to a more user-friendly form. This experiment also allowed us to improve DICO* features (in particular for managing template classes). We have currently developed several implementations of the interaction service (based on EJBs[12], Smalltalk, etc.) which can then accommodate a wide range of software systems. This opportunity, added to the possible adaptation of the ISL language and of the libraries make us consider to apply our approach to produce customized environments adapted to varied applications domains. The prototype explained in the last paragraph proves the interests of the two libraries and the advantages of DICO* to distribute KBSs. Our reified interaction service accommodates adaptive multi-access to a KBS without modifying its code. The response time for long distance users has not been checked yet. On the long term we will investigate other aspects of the distribution of KBS such as composition of services [13, 14, 15] or the concept of groups [16]. Another long term perspective would be to standardize the interaction service similarly to what as been done for naming, events, etc. in CORBA [17].
REFERENCES 1. S. Ducasse, M. Fornarino, and A-M. Pinna. “A Reflective Model for First Class Relationships” In Proceedings of OOPSLA’95, pages 265--280, 1995. 2. S. Moisan. “Réutilisation et générateurs de systèmes à base de connaissances : le framework Blocks”, TSI, numéro spécial réutilisation, vol 20, n.4/2001, p. 529-553. 3. “The Common Object Request Broker : Architecture and Specifications”, Revision 2.1, Object Management Group, August 1997. 4. Java Remote Method Invocation Specification, Sun Microsystems, 1997 5. G. Agha and S. Frølund. “A Language Framework for Multi-Object Coordination” In Proc. of ECCOP ‘93, number 707 in LNCS, pages 347-360, July 1993. 6. S. Ducasse and T. Richner, «Executable Connectors: Towards Reusable Design Elements», Jan 16, 1997. ESEC’97 LNCS1301 7. L. Berger. “Compile Time and Runtime Reflection for Dynamic Evaluation of Messages: Application to Interactions between Remote Objects”, in OOPSLA’98 Workshop on Reflective Programming in C++ and Java. 8. Object Oriented Concepts, Inc «Orbacus for C++ 3.1.2», http://www.ooc.com 9. S. Chiba. “A Metaobject Protocol for C++” In the ACM Conference OOPSLA’95, pages 285-299, October 1995. 10. M. Tatsubori, S. Chiba, M-O. Killijian, K. Itano. “OpenJava: A Class-Based Macro System for Java”, LNCS 1826, Reflection and Software Engineering, Springer-Verlag, p.117-133, 2000
- 10
11. http://www.omg.org/technology/documents/formal/naming_service.htm 12. JOnAS: JavaTM Open Application Server: http://www.objectweb.org/JonAS/JonAShomepage.htm 13. L. Bussard «Towards a pragmatic composition model of CORBA services based on AspectJ». Position Paper in the workshop on the “Aspects & Dimensions of Concerns” of ECOOP 2000. 14. M. Aksit. ‘Constructing Reusable Components with Multiple Concerns Using Composition Filters, in Software Architectures and Component Technology: The State of the Art in Research and Practice,‘ M. Aksit (Ed.), Kluwer Academic Publishers, 2000 15. R. Pawlak, L. Duchien and G. Florin. “An automatic Aspect Weaver with a reflective Programming language” Springer LNCS 1616 p. 250, Meta-Level Architectures and Reflection, Reflection’99, July 1999. 16.
R. Guerraoui, P. Felber, B. Garbinato, K. Mazouni. OOPSLA’98, Vancouver, Canada
“System Support for Object Groups” In Proceedings of
17. CorbaServices: Common Object Services Specification, Revised Edition, July 1997, OMG Document format/97-09-01
- 11
