From our experience, RMI-based frameworks and in general all frameworks supplying distributed computation seem to have some troubles. We detected at least three problems related to their flexibility and applicability. Most of them lack in flexibility. Their main duty consists in providing a friendly environment suitable for simply realizing distributed computations. Unfortunately, interaction policies are hardwired in the framework. If it is not otherwise foreseen, it is a hard job to change, for example, how messages are marshaled|unmarshaled, or the dispatching algorithm which the framework adopts. Some frameworks provide some limited mechanism to redefine such details but their flexibility is limited from the possibility that the designer has foreseen. Distributed algorithms are imbued in the applicative code breaking the well-known software engineering requirement termed as separation of concerns. Some programming languages like Java mask remote interactions (i.e., remote method or procedure call) as local calls rendering their presence transparent to the programmer. However their management, -- i.e., tuning the needed environment to rightly carry out remote computations, and synchronizing involved objects -- is not so transparent and easily maskable to the programmer. Such a behavior hinders the distributed algorithms reuse. Object-oriented distributed programming is not distributed object-oriented programming. It is an hard job to write object-oriented distributed applications based on information managed by several separated entities. Algorithms originally designed as a whole, have to be scattered among several entities and no one of these entities directly knows the whole algorithm. This fact improves the complexity of the code that the programmer has to write because (s)he has to extend the original algorithm with statements for synchronizing and for putting in touch all the remote objects involved in the computation. Moreover the scattering of the algorithm among several objects contrasts with the object-oriented philosophy which states that data and algorithms managing them are encapsulated into the same entity, because each object can't have a global view of any data it manages, thus we could say that this approach lacks of global view. The lack of global view forces the programmer to strictly couple two or more distributed object. A reflective approach, as stated in [19], can be considered as the glue sticking together distributed and object-oriented programming and filling the gaps in their integration. Reflection improves flexibility, allows developers to provide their own solutions to communication problems, and keeps communication code separated from the application code, and completely encapsulated into the meta-level. Hence reflection could help to solve most of the troubles we detected. Reflection permits to expose implementation details of a systems, i.e., in our case allows to expose the interaction policies. It also permits to easily manipulate them. A reflective approach also permits to easily separate the interaction management from the applicative code. Using reflection and some syntactic sugar for masking the remote calls we can achieve a good separation of concerns also in distributed environments. Thanks to such considerations a lot of distributed reflective middleware have been developed. Their main goal consists both in overcoming the lacking of flexibility and in decoupling the interaction code from the applicative code. By the way, reflective distributed middlewares exhibit the same troubles detected in the distributed middlewares. They still fail in considering each remote invocation in terms of the entity involved in the communication (i.e., the client, the server, the message and so on) and not as a single entity. Hence the global view requirement is not achieved. This is due to the fact that most of the meta-models that have been presented so far and used to design the existing reflective middlewares are object-based models. In these models, every object is associated to a meta-object, which traps the messages sent to the object and implements the behavior of that invocation. Such a meta-models inherit the trouble of the lack of global view from the object-oriented methodology which encapsulates the computation orthogonally to the communication. Hence, these approaches are not appropriate to handle all the aspects of distributed computing. In particular adopting an object-based model to monitor distributed communications, the meta-programmer often has to duplicate the base-level communication graph into the meta-level augmenting the meta-program complexity. Thus, object-based approaches to reflection on communications move the well- known problem [47] of nonfunctional code intertwined to functional one from the base- to the meta-level. Simulating a base-level communication into the meta-level allows to perform meta-computations either related sending or receiving action, but not related to the whole communication or which involve information owned both by the sender and by the receiver without dirty tricks. This trouble goes under the name of global view lacking. Besides, object-based reflective approaches and their reflective middlewares based on them allow only to carry out global changes to the mechanisms responsible for message dispatching, neglecting the management of each single message. Hence they fail to differentiate the meta-behavior related to each single exchanged message. In order to apply a different meta-behavior to either each or group of exchanged messages the meta-programmer has to write the meta-program planning a specific meta-behavior for each kind of incoming message. Unfortunately, in this way the size of the meta-program grows to the detriment of its readability, and of its maintenance. Due to such a consideration, a crucial issue of opening a RMI-based framework consists in choosing a good meta-model which permits to go around the global view lacking, and to differentiate the meta-behavior for each exchanged message. From the problem analysis we have briefly presented we learned that in order to solve the drawbacks of the RMI-based framework we have to provide an open RMI mechanism, i.e., a reflective RMI mechanism, which exposes its details to be manipulated by the meta-program and allows the meta-program to manage each communication separately and as a single entity. The main goal of this work consists in designing such a mechanism using a reflective approach. To render the impact of reflection on object-oriented distributed framework effective, and to obtain a complete separation of concern, we need new models and frameworks especially designed for communication-oriented reflection, i.e., we need a reflective approach suitable for RMI-based communication which allows meta-programmer to enrich, manipulate and replace each remote method invocation and its semantics with a new one. That is, we need to encapsulate message exchanging into a single logical meta-object instead of scattering any relevant information related to it among several meta-objects and mimicking the real communication with one defined by the meta-programmer among such meta-objects as it is done using traditional approaches. To fulfill this commitment we designed a new model, called multi-channel reification model [5]. The multi-channel reification model is based on the idea of considering a method call as a message sent through a logical channel established among a set of objects requiring a service, and a set of objects providing such a service. This logical channel is reified into a logical object called multi-channel, which monitors message exchange and enriches the underlying communication semantics with new features used for the performed communication. Each multi- channel can be viewed as an interface established among the senders and the receivers of the messages. Each multi-channel is characterized by its behavior, termed kind, and the receivers, which it is connected to. multi-channel ≡ (kind, receiver¹, ⋯, receiverⁿ) Thanks to this multi-channel's characterization it is possible to connect several multi-channels to the same group of objects. In such a case, each multi-channel will be characterized by a different kind and will filter different patterns of messages. This model permits to design an open RMI-based mechanism which potentially overcomes the previously exposed problems. In this way, each communication channel is reified into a meta-entity. Such a meta-entity has a complete access to all details related to the communications it filters, i.e. the policies related to both the sender, and the receivers side, and, of course, the messages it filters. A channel realizes a close meta-system with respect to the communications. It encapsulates all base-level aspect related to the communication providing the global view feature. Of course, this model keeps all the properties covered by the other reflective models, such as transparency and separation of concerns. Hence the approach also guarantees to go around the problems already solved using reflection. Protocols and other realizative stuff are exposed to the meta-programmer manipulations, and the remote method invocation management is completely separated from the applicative code. Moreover through the kind mechanism we can differentiate the behavior which is applied to a specified pattern of messages. So a set of multi-channels (each one with a different kind) can be associated to the same communication channel. Each channel will operate to a different set of messages. In this way the channel's code is related to a unique behavior it indiscriminately has to apply to all the messages it filters. mChaRM [22] is a framework developed by the authors which opens the RMI mechanism supplied by Java. This framework supplies a development and run-time environment based on the multi-channel reification model. Multi-channels will be developed in Java, and the underlying mChaRM framework will dynamically realize the context switching and the causal connection link. A beta version of mChaRM, documentations and examples are available from: http://cazzola.di.unimi.it/mChaRM.html Such a system provided RMI-based programming environment. The supplied RMI mechanism is multi-cast (i.e., supplies a mechanism to remotely invoke a method of several servers), open (the RMI mechanism is fully customizable through reflection), and globally aware of its aspects. Some example of application are also provide.

Communication-Oriented Reflection: a Way to Open Up the RMI Mechanism / W. Cazzola ; Supervisor: F. Tisato; Advisor: Shigeru Chiba. ex-DIPARTIMENTO DI SCIENZE DELL'INFORMAZIONE, 2001 Feb. 12. ciclo, Anno Accademico 2000/2001.

Communication-Oriented Reflection: a Way to Open Up the RMI Mechanism

W. Cazzola
2001

Abstract

From our experience, RMI-based frameworks and in general all frameworks supplying distributed computation seem to have some troubles. We detected at least three problems related to their flexibility and applicability. Most of them lack in flexibility. Their main duty consists in providing a friendly environment suitable for simply realizing distributed computations. Unfortunately, interaction policies are hardwired in the framework. If it is not otherwise foreseen, it is a hard job to change, for example, how messages are marshaled|unmarshaled, or the dispatching algorithm which the framework adopts. Some frameworks provide some limited mechanism to redefine such details but their flexibility is limited from the possibility that the designer has foreseen. Distributed algorithms are imbued in the applicative code breaking the well-known software engineering requirement termed as separation of concerns. Some programming languages like Java mask remote interactions (i.e., remote method or procedure call) as local calls rendering their presence transparent to the programmer. However their management, -- i.e., tuning the needed environment to rightly carry out remote computations, and synchronizing involved objects -- is not so transparent and easily maskable to the programmer. Such a behavior hinders the distributed algorithms reuse. Object-oriented distributed programming is not distributed object-oriented programming. It is an hard job to write object-oriented distributed applications based on information managed by several separated entities. Algorithms originally designed as a whole, have to be scattered among several entities and no one of these entities directly knows the whole algorithm. This fact improves the complexity of the code that the programmer has to write because (s)he has to extend the original algorithm with statements for synchronizing and for putting in touch all the remote objects involved in the computation. Moreover the scattering of the algorithm among several objects contrasts with the object-oriented philosophy which states that data and algorithms managing them are encapsulated into the same entity, because each object can't have a global view of any data it manages, thus we could say that this approach lacks of global view. The lack of global view forces the programmer to strictly couple two or more distributed object. A reflective approach, as stated in [19], can be considered as the glue sticking together distributed and object-oriented programming and filling the gaps in their integration. Reflection improves flexibility, allows developers to provide their own solutions to communication problems, and keeps communication code separated from the application code, and completely encapsulated into the meta-level. Hence reflection could help to solve most of the troubles we detected. Reflection permits to expose implementation details of a systems, i.e., in our case allows to expose the interaction policies. It also permits to easily manipulate them. A reflective approach also permits to easily separate the interaction management from the applicative code. Using reflection and some syntactic sugar for masking the remote calls we can achieve a good separation of concerns also in distributed environments. Thanks to such considerations a lot of distributed reflective middleware have been developed. Their main goal consists both in overcoming the lacking of flexibility and in decoupling the interaction code from the applicative code. By the way, reflective distributed middlewares exhibit the same troubles detected in the distributed middlewares. They still fail in considering each remote invocation in terms of the entity involved in the communication (i.e., the client, the server, the message and so on) and not as a single entity. Hence the global view requirement is not achieved. This is due to the fact that most of the meta-models that have been presented so far and used to design the existing reflective middlewares are object-based models. In these models, every object is associated to a meta-object, which traps the messages sent to the object and implements the behavior of that invocation. Such a meta-models inherit the trouble of the lack of global view from the object-oriented methodology which encapsulates the computation orthogonally to the communication. Hence, these approaches are not appropriate to handle all the aspects of distributed computing. In particular adopting an object-based model to monitor distributed communications, the meta-programmer often has to duplicate the base-level communication graph into the meta-level augmenting the meta-program complexity. Thus, object-based approaches to reflection on communications move the well- known problem [47] of nonfunctional code intertwined to functional one from the base- to the meta-level. Simulating a base-level communication into the meta-level allows to perform meta-computations either related sending or receiving action, but not related to the whole communication or which involve information owned both by the sender and by the receiver without dirty tricks. This trouble goes under the name of global view lacking. Besides, object-based reflective approaches and their reflective middlewares based on them allow only to carry out global changes to the mechanisms responsible for message dispatching, neglecting the management of each single message. Hence they fail to differentiate the meta-behavior related to each single exchanged message. In order to apply a different meta-behavior to either each or group of exchanged messages the meta-programmer has to write the meta-program planning a specific meta-behavior for each kind of incoming message. Unfortunately, in this way the size of the meta-program grows to the detriment of its readability, and of its maintenance. Due to such a consideration, a crucial issue of opening a RMI-based framework consists in choosing a good meta-model which permits to go around the global view lacking, and to differentiate the meta-behavior for each exchanged message. From the problem analysis we have briefly presented we learned that in order to solve the drawbacks of the RMI-based framework we have to provide an open RMI mechanism, i.e., a reflective RMI mechanism, which exposes its details to be manipulated by the meta-program and allows the meta-program to manage each communication separately and as a single entity. The main goal of this work consists in designing such a mechanism using a reflective approach. To render the impact of reflection on object-oriented distributed framework effective, and to obtain a complete separation of concern, we need new models and frameworks especially designed for communication-oriented reflection, i.e., we need a reflective approach suitable for RMI-based communication which allows meta-programmer to enrich, manipulate and replace each remote method invocation and its semantics with a new one. That is, we need to encapsulate message exchanging into a single logical meta-object instead of scattering any relevant information related to it among several meta-objects and mimicking the real communication with one defined by the meta-programmer among such meta-objects as it is done using traditional approaches. To fulfill this commitment we designed a new model, called multi-channel reification model [5]. The multi-channel reification model is based on the idea of considering a method call as a message sent through a logical channel established among a set of objects requiring a service, and a set of objects providing such a service. This logical channel is reified into a logical object called multi-channel, which monitors message exchange and enriches the underlying communication semantics with new features used for the performed communication. Each multi- channel can be viewed as an interface established among the senders and the receivers of the messages. Each multi-channel is characterized by its behavior, termed kind, and the receivers, which it is connected to. multi-channel ≡ (kind, receiver¹, ⋯, receiverⁿ) Thanks to this multi-channel's characterization it is possible to connect several multi-channels to the same group of objects. In such a case, each multi-channel will be characterized by a different kind and will filter different patterns of messages. This model permits to design an open RMI-based mechanism which potentially overcomes the previously exposed problems. In this way, each communication channel is reified into a meta-entity. Such a meta-entity has a complete access to all details related to the communications it filters, i.e. the policies related to both the sender, and the receivers side, and, of course, the messages it filters. A channel realizes a close meta-system with respect to the communications. It encapsulates all base-level aspect related to the communication providing the global view feature. Of course, this model keeps all the properties covered by the other reflective models, such as transparency and separation of concerns. Hence the approach also guarantees to go around the problems already solved using reflection. Protocols and other realizative stuff are exposed to the meta-programmer manipulations, and the remote method invocation management is completely separated from the applicative code. Moreover through the kind mechanism we can differentiate the behavior which is applied to a specified pattern of messages. So a set of multi-channels (each one with a different kind) can be associated to the same communication channel. Each channel will operate to a different set of messages. In this way the channel's code is related to a unique behavior it indiscriminately has to apply to all the messages it filters. mChaRM [22] is a framework developed by the authors which opens the RMI mechanism supplied by Java. This framework supplies a development and run-time environment based on the multi-channel reification model. Multi-channels will be developed in Java, and the underlying mChaRM framework will dynamically realize the context switching and the causal connection link. A beta version of mChaRM, documentations and examples are available from: http://cazzola.di.unimi.it/mChaRM.html Such a system provided RMI-based programming environment. The supplied RMI mechanism is multi-cast (i.e., supplies a mechanism to remotely invoke a method of several servers), open (the RMI mechanism is fully customizable through reflection), and globally aware of its aspects. Some example of application are also provide.
feb-2001
Settore INF/01 - Informatica
Doctoral Thesis
Communication-Oriented Reflection: a Way to Open Up the RMI Mechanism / W. Cazzola ; Supervisor: F. Tisato; Advisor: Shigeru Chiba. ex-DIPARTIMENTO DI SCIENZE DELL'INFORMAZIONE, 2001 Feb. 12. ciclo, Anno Accademico 2000/2001.
File in questo prodotto:
Non ci sono file associati a questo prodotto.
Pubblicazioni consigliate

I documenti in IRIS sono protetti da copyright e tutti i diritti sono riservati, salvo diversa indicazione.

Utilizza questo identificativo per citare o creare un link a questo documento: https://hdl.handle.net/2434/193431
Citazioni
  • ???jsp.display-item.citation.pmc??? ND
  • Scopus ND
  • ???jsp.display-item.citation.isi??? ND
social impact