Architecture for a reuseable object-oriented polymorphic middleware Thomas Q UINOT, Fabrice KORDON, Laurent PAUTET {quinot,pautet}@enst.fr École Nationale Supérieure des Télécommunications CS & Networks Department 46, rue Barrault F-75634 Paris CEDEX 13, France
Abstract Using a middleware when designing a new distributed application allows portability across numerous software and hardware architectures, but introduces a new layer of potential incompatibilities due to the existence of various middleware standards. This paper presents the architecture of D ROOPI (Distributed Reusable Object-Oriented Polymorphic Infrastructure). This project aims at defining and implementing a modular middleware emphasizing software reuse, customizability towards environment and application requirements, and transparent interoperability through the support of multiple middleware personalities. Some of these capabilities may be found in similar projects. Our objective is to bring all these properties in a single environment, enabling communication between various components using different middleware standards.
1 Introduction The emergence of distributed applications has raised the need for portability across numerous software and hardware architectures. A way to address this problem is to use a middleware when designing a new distributed application. However, this solution introduces a new layer of potential incompatibilities: various middleware standards have been defined, which use different com-
[email protected] Laboratoire d’Informatique de Paris 6/SRC Université Pierre-&-Marie-Curie 4, place Jussieu F-75252 Paris CEDEX 05, France
munication protocols. Examples of such standards include CORBA, the Ada 95 DSA (Distributed Systems Annex) and Java/RMI. These incompatibilities seriously impair the reusability of distributed application components, which remain isolated in a given environment. This interoperability problem may be solve case by case using specific gateways between two components. However, this approach does not promote reusability of middleware code, and thus fails to scale to applications in the large. Multi-personality middlewares have emerged from the observation that much of a middleware’s behaviour is independent of the personality it assumes. For example, the generic middleware components of the Jonathan project [5], can be customized for a given middleware strategy (CORBA or Java/RMI). Similarly, Quarterware [21, 20] can endorse several personalities and provides the core facilities of other existing middlewares: CORBA, Java/RMI and MPI (a middleware based on the message-passing distribution paradigm). To resolve the problem of interoperability, which is not addressed by the two listed projects, we propose to extend the concept of a generic middleware to support multiple personalities simultaneously, within a single executing middleware instance. This requires a very flexible and customizable design. Such a design has other beneficial effects on middleware properties. To ensure predictability of a real-time, highintegrity system, a programmer may want to restrict the computational model. For this reason, Ada 95 allows the
definition of profiles, which are proper subsets of Ada 95 guaranteeing time efficiency and determinism at compile time. Existing profiles do not address distribution issues, but they provide pertinent restrictions on language features that one can use to implement lightweight configurations of a given middleware. Our objective is to design and implement D ROOPI, a Distributed Reusable Object-Oriented Polymorphic Infrastructure. D ROOPI aims to build, using our experience as middleware implementors, a modular middleware design emphasizing software reuse, customizability towards environment and application requirements, and including the support of transparent interoperability through the support of multiple middleware personalities. This paper presents the D ROOPI architecture. Section 2 presents similar projects and sketches the main features we want to implement. Then, section 3 describes and justifies the architecture we have elaborated for D ROOPI before concluding remarks and a brief presentation of the ongoing implementation.
configurations. In collaboration with ACT, we developed GLADE, the only certified conforming implementation of DSA. GLADE is available under the same free license as GNAT. It has been designed for this particular compiler, but should be portable to any Ada 95 compilation environment with minimal efforts. Then, the OMG CORBA model becomes popular. This model has an outstanding interoperability architecture; it addresses the need for interoperability between software components developed using various languages on discrete machine architectures. Thanks to our previous experience in developing the GLADE middleware, we have developed AdaBroker, the unique free CORBA environment providing an Ada 95 mapping. This project provides a translator with a full Ada 95 ORB. This includes a Portable Object Adapter (giving application developers a tool-independent, finegrained control over the management of objects within a server) and all the basic OMG Common Object Services (COS) as well. Using a Java Virtual Machine (JVM) creates innovative possibilities for distribution (code migration, stubs down2 State of the art load). The JVM can also be easily programmed in Ada 95, 2.1 Implementation of platform-specific for example with the JGNAT compiler [1]. We thus also considered Sun’s Java/RMI (Remote middlewares Method Invocation). However, its approach to distribuThese past years, we have developed two middlewares im- tion is very classical and does not introduce new ideas beplementing two different distributed object-oriented mod- yond features already present in CORBA or DSA. Work els. Both middlewares are targeted to work with the is in progress within the OMG to integrate RMI as a programming language Ada 95. Ada 95 is the first subset of CORBA [14]. Furthermore, the RMI distribustandardized object-oriented language (ANSI/ISO/IEC- tion model exhibits severe shortcomings: although the in8652:1995). tent of the RMI specification is to provide distributionIt is also the first standardized language including dis- transparent remote invocation, Java language semantics tribution features. The Ada 95 Distributed Systems An- cannot be preserved correctly in a distributed context [2]. nex (DSA) provides an interesting approach to distribution: existing constructs for separation of interface and 2.2 Aspects of a generic middleware implementation are extended with distribution semantics; all existing properties of the language are preserved. From our experience as implementors of GLADE and A great effort was led by Ada Core Technologies (ACT) AdaBroker, we have identified common architectural to provide the Ada community with a free high-quality characteristics of the DSA and CORBA distribution platAda 95 compiler called GNAT. This compiler, which im- forms. Both fit in a much more general model encomplements the core Ada 95 language as well as all the op- passing many object-oriented distribution platforms. We tional annexes, belongs to the GCC family and shares its therefore endeavored to formally define a generic middleback end with C and C++ compilers. As other compilers ware architecture based on that model, with an emphasis from the GCC suite, GNAT supports many native and cross on the following essential features:
genericity The middleware shall factor out common TAO is a modular ORB whose design is based on the components that can be shared among different perpervasive use of patterns [18]. Patterns help to resonalities. Examples of such components include the duce the complexity and improve the maintainability management of environment resources such as conof the ORB. An ORB with a modular pattern-based trol threads and data transport endpoints. design such as TAO also proves to be more extensible and evolvable than a conventional ORB. patterns Aspects of common or personality-specific components that correspond to well-known design Quarterware adopts a CORBA-like model to offer a component-based middleware [20, 3]. This design patterns shall be identified, and their implementaallows specialization and optimization to fit requiretions shall reflect their affiliation to a generic design. ments of a particular application. Quarterware can endorse several personalities, which provide the core customizability The middleware shall enable users to facilities of other existing middlewares: CORBA, control and tailor its functionality according to Java/RMI and MPI. his specific purposes and application requirements. They will thus be able to control the resource usage GLADE comprises a configurable inter-task synchroas well as aspects of middleware operations (such as nization library that can transparently offer nothe choice of a particular communication protocol) operation placeholder implementations for synchroto fit their specific requirements. nization primitives when there is only one task in a partition [16]. Avoiding the use of language taskenvironment profiles Proper subsets of middleware ing primitives improves the predictability and realfunctionalities shall be defined to satisfy real-time time properties of the application [15] The runtime properties and exhibit predictable behaviours. For library’s memory footprint is also reduced. example, we plan to provide a minimal implementation with no use of non-deterministic tasking primi- CIAO is a code generation tool developed to let GLADE tives as identified by the Ravenscar profile for realand AdaBroker interoperate [17]. It allows services time, high-integrity systems [4]. A standard subdeveloped using Ada 95 DSA to be accessed by any set of CORBA for embedded systems has already CORBA-compliant client. This constitutes a first been defined with similar objectives: minimumstep towards full interoperability between DSA and CORBA [13]. CORBA. interoperability The middleware shall allow objects to interoperate regardless of whether they are implemented using the same distribution platform, or discrete ones. A server object created in a given platform shall thus be accessible by clients using any other platform.
2.3 Related projects The following projects exemplify the identified features: Jonathan is a distributed processing environment for the Java Virtual Machine which offers the possibility to integrate various types of bindings between objects in an application [5]. Jonathan supports a CORBA and a Java/RMI personality using a generic distribution kernel.
D ROOPI’s objective is to define and implement a middleware able to provide various personalities such as DSA, CORBA or RMI. We aim to integrate all the essential features listed in section 2.2. Unlike other middlewares that can be tailored to support various personalities (such as Jonathan or Quarterware), D ROOPI’s goal is to support multiple personalities within the same instance of a running middleware, so as to provide interoperability between object-oriented distributed applications.
3 Architecture of a generic middleware D ROOPI’s architecture is the result of a research process driven by the problem of interoperating different distribu-
tion platforms. The CIAO project showed that automatic 3.2 Recurring services in distributed generation of gateway components could address this isobject-oriented applications sue to a certain point. It also outlined that the offered integration was not as seamless as we would have expected. In this section, we present a generic description of the We thus decided to investigate appropriate mechanisms to functions that one can expect to find in a distributed OO platform; we thus provide an architectural model for such bridge the gap between existing middleware platforms. a platform, and we show how CORBA and DSA can be interpreted as instances of this model. This description captures the common structural and functional elements 3.1 Lessons learned from the CIAO project of distribution middlewares, in order to help structuring a generic middleware implementation supporting each of CIAO has successfully allowed the generation of gate- these elements under various appearances, or personaliways between distribution platforms. However, this ap- ties. In this paper we restrict ourselves to middlewares supproach has a number of drawbacks. Some are related to the current implementation, but others are essential to the porting the distributed object paradigm. Other distribution models, such as plain RPC or Message Passing, can approach. be implemented in terms of distributed object oriented Using a gateway to convert requests from one platprimitives. An abstract model of the distributed OO arform to the other means that all requests will have to go chitecture thus notionally encompasses those other archithrough a bottleneck. Depending on the size of the applitectures. cation, this may be a major drawback in terms of perforBasic services offered by distribution middlewares conmance. Reliability is also at stake, because the computing stitute an abstraction layer over Operating System comnode executing the gateway becomes a single point of failmunication facilities. This layer has to preserve the fundaure. Both issues may be addressed by establishing several mental properties of the OO model: addressing (embodygateways. This introduces another concern: consistence ing identity of objects), exchange of requests (transport, of the information used by all gateways to translate redata representation, request protocol, embodying method quests. It becomes difficult to ensure that translated object calls), and resource management (activation of objects, references designating the same DSA object seen through requests dispatching, embodying objects life cycle). different gateways are identical CORBA references, i. e. We now describe these functional areas in greater deto preserve object identity across gateways. tail: The CIAO approach also requires application developers to perform specific steps to make distributed (DSA) Addressing application open to CORBA clients. While most of this Definition Each object needs to be assigned an adprocess is automated, it requires a modification to the apdress (or reference). An address is an piece of plication to include the proxy units in one of its partitions. information which can be passed from node to Our current interoperability approach provides a more node, and denotes one particular object unamconvenient way to make objects defined within one envibiguously all over its existence. ronment available in another. Our objective is to enable Properties An address must be a global identifier users to define middleware personalities both at the “apfor an object. Addresses need to designate an plication level” and at the “ORB protocol level”. object unambiguously: they must be globally The application level is the interface between an appliunique. cation object (client or server) in a distributed system, and its host middleware. The “ORB protocol level” is the interface where our generic middleware communicates with other middleware using their specific communication protocols.
Rationale One of the fundamental properties of objects is identity. Addresses embody that property by allowing nodes to manipulate these object identities.
Example An open addressing scheme that satisfies these properties can be established using TSAP (Transport Service Access Point [7]) addresses from the underlying networking environment, associated with a locally unique identifier attributed by the middleware. This is the solution retained in CORBA. Other addressing schemes can be established, provided they satisfy those conditions. Using TSAP addresses has the advantage that no global mapping of identifiers to network addresses has to be maintained. Transport Definition A node must be able to establish a communication link to an object. This link is used to transmit requests for the execution of object methods. Properties Messages must be reliably delivered.
standardized. For instance, the middleware at the calling and receiving ends of the communication channel have to agree on the size and endianness of integers. Rationale System representation choices are a tradeoff between portability and cost of data conversion from machine representation to network representation (and back). Example It is necessary to find a balance between platform related representation (constraints) and application related representation (that can be optimized for a given environment). For example, a common data representation may be specified for all data types, while messages may still carry an endianness flag which indicates whether data items are stored low-order byte first or high-order byte first [12]. This provides a reasonably simple and compact representation of information, while alleviating the cost of “byte-swapping” operations. As these operations involve a significant portion of the critical path in request marshalling, this optimization is greatly beneficial to performance.
Rationale Invoking an object method in the objectoriented programming model consists in sending a message to the object [6]. Distribution fits nicely in this model: the corresponding message goes through a communication network. Protocol Example Existing message-passing libraries can be reused. This method has already been sucDefinition The middleware implements a protocol cessfully applied to reimplement the Java/RMI for the transmission of requests among inplatform over existing distributed processing listances of distribution runtimes. braries. [11] presents KaRMI, a drop-in reProperties The fundamental primitives of a displacement for Sun’s RMI, which features an tributed objects protocol are Request and Reabstraction for the message passing layer. This ply, which are used to implement remote invoabstraction can make use of TCP/IP sockets as cation of subprograms and methods. Abortion well as specialized message-passing hardware of pending requests can also be provided by in a parallel environment; KaRMI also has the protocol primitives. Further primitives may be ability to create bridge objects between differfound in particular platforms; these are used to ent technology domains on-the-fly. perform various high-level functions, and can be functionally understood as requests sent to Marshalling objects that are part of the platform implementation. Definition Request data must be translated into a representation suitable for transmission over a Example CORBA defines a Generic Inter-ORB network. Protocol for this purpose. Properties In order to build interoperable applications, this representation has to be previously
Activation
Definition The middleware has to activate and de- Naming activate the concrete entities implementing obDefinition The Naming service allows object referjects. When a request is received, it ensures ences to be associated with symbolic names, that the object reference is mapped onto an acand nodes to query the service for any refertual object implementation. The middleware ence associated with a name. may have to create an object implementation on-the-fly, or to retrieve an object state from Rationale This service lets applications determine persistent storage. the references of any object they need at runtime. It is essential when an application has to Properties Each request must be processed within adapt to environment modifications, to changes the correct context (including object state and in technology or to the evolution of user reidentity, history of preceding requests, etc.) quirements. They allow developers to avoid Example The Portable Object Adaptor of CORBA using hard-coded object references, and thus provides several policies on various issues (aumake the entire distributed application recontomatic activation, system or user id creation, figurable. thread creation per-request or per-object, ...) Example DSA has an implicit naming service: all nodes can invoke operations defined by units Dispatching categorized as Remote Call Interfaces. The runtime takes care of locating on which node Definition When a request reaches a node, it has the named unit resides. This service is also to be assigned onto an execution resource (a used to prevent multiple declarations of unique thread of control) for processing. The distrientities like RCI units or to check remote unit bution runtime has to find a suitable thread on versions. For these reasons, the naming service the node, or create one if necessary. has to be an internal entity of the GLADE comProperties The dispatching mechanism should not munication system. introduce dead locks. If possible, it should process requests fairly; request prioritization sup- Synchronization port may also be provided. Definition A synchronization service may be proRationale Several policies for deciding when to crevided to synchronize the operation of nodes exate a thread, and on which thread to dispatch a ecuting actions in parallel. given request, can be defined. The choice of a Rationale The operation of the concurrent, indeparticular threading policy is discussed in [19]. pendent processes that participate in a disExample GLADE implements a pool of dynamically tributed application must be coordinated; most created threads. Most incoming requests can notably, care must be taken that concurrent acthus be served immediately, while keeping the cess to shared resources occurs only in an ormemory and context switching footprint of the derly, consistent way. Distribution platforms runtime within limits [16]. may help addressing this issue by providing specialized concurrency support services, such The previously listed services are sufficient to provide as distributed mutual exclusion [10]. the core functionalities of a distribution middleware. They are built atop the operating system communication facili- Interface Repository ties and provide distributed object-oriented abstractions. However, applications often require support for more Definition An application may need to invoke opsophisticated functions related to distribution. These erations on objects whose interface was not functions include: known when the application was created. For
this invocation to be performed correctly, a description of the interface must be available. The purpose of Interface Repository Services is to propagate such information: they distribute service descriptions to interested nodes.
their own work, and no message is in transit in the communication network, it can be proven that no new computing work can happen [9]. In that case, global termination can be decided. The user can select for each partition a local or global termination policy [16].
Properties The abstractions manipulated by the Interface Repository service must reflect the platShared data form’s service model. A dynamic invocation mechanism is necessary Definition Nodes in a distributed application may to use the information provided by an interface want to share part of their data. A shared repository. This facility enables nodes to indata service provides shared storage transparvoke dynamically discovered methods. A dyently for the application developer: distributed namic invocation interface reifies the process shared data appears just as normal local data; of creating a remote method invocation request. the distribution runtime takes care of propagatAfter the request object is constructed, it can ing the effects of data access between nodes. be processed like any ordinary method invocation on a remote object; the receiving object Properties A shared storage service must provide cannot distinguish dynamically-constructed reall nodes with a consistent view of the shared quests from statically-created ones. variables. Several models of consistency can be defined. Example CORBA defines an Interface Repository ORB service and an associated Dynamic InvoRationale This service provides developers with a cation Interface. very straightforward way to define a set of globally available data. Termination Example DSA offers Shared Passive data: library Definition A distributed application consists of a set units containing only variables, which can be of computing nodes that cooperate to reach a accessed consistently from any node in a disgoal. If, at some point in time, all nodes agree tributed application. GLADE provides several that this goal has been reached, they may deshared data supports like file or DVSM [8]. cide to globally terminate processing and perform an orderly shutdown. A Termination service can be implemented to establish this deci- 3.3 Example sion. Let us suppose that we have a very simple object with a Properties Such a service must determine a consen- single method echo taking a string argument, and sendsus among participating nodes on whether to ing that string back to the caller. Invoking this method end the application. The Termination service involves the following steps: provides a support for applications to make this decision. Implementation of this service re- Addressing The caller determines a reference to the object. quires specific support from the ORB in addition to the low-level services listed above. Transport The caller-side ORB extracts a network adSpecifically, the implementation of the Termidress from the reference and creates a connection to nation service needs some way to inspect the the object’s ORB. state of the ORB’s internal threads of control. Example GLADE provides a global termination algorithm for DSA. If all nodes have terminated
Marshalling It converts the string passed to the method into a representation suitable for network transport,
Application components 11111111 00000000 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 Application personalities 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111
Middleware core decoupling application/protocol personalities 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 Protocol personalities 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111
{
Profiles (Ravenscar, minimumCORBA) Multiple platform support (JVM, native) Customizable runtime
Other middlewares
Figure 1: Overview of the DROOPI architecture for example a four-byte, little-endian integer containing the length of the string, followed by the string itself. Protocol It creates a Request message containing the name of the method, the object reference, and the marshalled argument, along with a unique request ID. It sends the message across the transport link to the callee ORB. The callee ORB receives the message. Activation The callee ORB looks up the object reference in its internal tables, and associates it with an implementation object.
protocol-level personalities through a generic ORB core layer. The application-layer personalities are the interfaces presented by the middleware to the application components using it: client and server objects. These personalities depend on code generated from user-provided service descriptions to map personality-specific requests sent by clients objects to server objects from a personalitydependent representation to a personality-independent one. This representation is then passed to an ORB protocol personality for transmission to the target object. It should be noted that our architecture does not impose any constraint on the protocol personality to be used for a given application personality; both layers are entirely decoupled. This allows the architecture to offer interoperability between distribution platforms as seen by application developers. This personality-independent, reified representation of method invocation requests is very similar to the Request object defined by the CORBA Dynamic Invocation Interface. It is also the key point in avoiding a combinatorial explosion when adding new personalities to the generic middleware. Adding a new set of application and protocol personalities only requires the development of:
an application personality library and code generator; a protocol personality library.
Adding a new personality is thus a task of constant Dispatching The callee ORB finds an idle thread within complexity; this could not be achieved with the gateway its available thread pool, and assigns the execution generation approach, where the complexity of supportof the request onto that thread. ing a new distribution platform would require the development of as many gateways as existing supported platMarshalling The callee ORB marshalls the echoed forms. string as above. Figure 1 summarizes the proposed architecture. The key-points we identified in 2.2 are addressed as follows: Protocol It creates a Reply message containing the request ID and the marshalled result string. The reply genericity This design captures the common behaviours is sent back to the caller. that are represented in various distribution platforms. The caller ORB unmasrshalls the result and returns These behaviours are implemented as commodity it to the calling routine. components providing services to other middleware modules. An typical example is the elaboration of a common generic representation for requests. 3.4 Architecture summary and rationale We propose to make use of a layered architecture that decouples application-level personalities from ORB
patterns We use generic, reusable modules extensively. When a well-known design pattern is encountered in
the design of D ROOPI, we reflect it the implementaTo implement services that make use of the generic tion by the use of Ada 95 facilities such as generic middleware, a code generator translating service deunits and abstract tagged types. scriptions to the middleware’s internal, personalityindependent representation is necessary. This phase of customizability Our architecture delineates abstract in- application development is currently addressed by ad-hoc terfaces between components, and allows several tools based on the GLADE and AdaBroker code generaconcrete implementations of these interfaces to al- tors. In the future, we will investigate new solutions to low compile-time and run-time customization of its provide generic code generation facilities, thus extending behaviour. This will also allow support of multiple the notion of a generic middleware to a complete generic platforms (native compiler, Java virtual machine). distributed application development tool suite. Like GLADE and AdaBroker, software developed environment profiles Multiple application profiles will within the D ROOPI project will be made available to the be supported through customization of key resource community as a free software product. management components, such as the memory allocation subsystem, or the task creation/destruction subsystem. This will allow the definition of an ORB References configuration compatible with the Ravenscar profile. [1] E. Briot. JGNAT: The GNAT Ada 95 environment for the A minimal subset of CORBA, minimumcORBA [13], JVM. In Ada France 1999, Sept. 1999. has been defined by the OMG to run in such “light” [2] G. Brose, K.-P. Löhr, and A. Spiegel. Java Does not Disenvironments. interoperability This architecture decouples the personalities presented to the local application and to other middlewares (and hence other computing nodes): objects created within one personality of the generic middleware become transparently available to any client that uses a distribution platform for which a corresponding protocol personality exists.
4 Conclusions and future works D ROOPI is a novel middleware that will allow interoperability of distributed object-oriented applications across distribution platforms. We have completed the first step of this project, which consists in the definition of a generic middleware architecture. This architecture integrates and extends several aspects of existing middlewares. The implementation of this design has started quickly, thanks to the re-use of several modules from previous projects. We have integrated from the very beginning of the project the port to the Java virtual machine by developing concurrently a native version and a JVM version of D ROOPI. We take also care of using a restrictive subset of Ada 95 to ensure the compatibility with common realtime environment profiles.
tribute. In TOOLS Pacific ’97, Nov. 1997. [3] R. H. Campbell, J. W. Coomes, A. Dave, N. Islam, Y. Li, W. S. Liao, S. Lim, T. Qian, D. K. Raila, E. Roush, A. Sane, M. Sefika, A. Singhai, and S. T. Tan. Customizable Object-Oriented Operating Systems. Submitted for Communications of the ACM Special Issue on Recent Developments in Operating Systems, Sept. 1996. [4] B. Dobbing and A. Burns. The Ravenscar tasking profile for high integrity real-time programs. In Proceedings of SigAda’98, Washington, DC, USA, Nov. 1998. [5] B. Dumant, F. Horn, F. Dang Tran, and J.-B. Stéfani. Jonathan: an Open Distributed Processing Environment in Java. In Proc. IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing (Middleware’98). Springer Verlag, Sept. 1998. [6] D. H. H. Ingalls. The Smalltalk-76 Programming System Design and Implementation. In Conference Record of the Fifth Annual ACM Symposium on Principles of Programming Languages, Tucson, Arizona, pages 9–16, Jan. 1978. [7] ISO. Information technology – Open Systems Interconnection – Basic Reference Model: The Basic Model. ISO, Feb. 1995. ISO/IEC 7498-1:1994. [8] K. Li and P. Hudak. Memory coherence in shared virtual memory systems. ACM Transactions on Computer Systems, 7(4):321–359, Nov. 1989. [9] F. Mattern. Algorithms for Distributed Termination Detection. Distributed Computing, 2(3):161–175, 1987. [10] M. Naimi, M. Tréhel, and A. Arnold. A Log(N) Distributed Mutual Exclusion Algorithm Based on the Path
[11]
[12]
[13] [14]
[15]
[16] [17]
[18]
[19]
[20]
[21]
Reversal. Journal of Parallel and Distributed Computing, 34(1):1–13, Apr. 1996. C. Nester, M. Philippsen, and B. Haumacher. A More Efficient RMI for Java. In ACM 1999 Java Grande Conference, pages 153–159. ACM, June 1999. Object Management Group. The Common Object Request Broker: Architecture and Specification, revision 2.2. Object Management Group, Feb. 1998. OMG Technical Document formal/98-07-01. Object Management Group. minimumCORBA. Object Management Group, Aug. 1998. OMG orbos/98-08-04. Object Management Group. Java Language to IDL Mapping. Object Management Group, Jan. 2000. OMG ptc/00-01-06. L. Pautet and S. Tardieu. GLADE: a Framework for Building Large Object-Oriented Real-Time Distributed Systems. In Proceedings of the 3rd IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC’00), Newport Beach, California, USA, June 2000. L. Pautet and S. Tardieu. GLADE User Guide. Ada Core Technologies, 2000. T. Quinot. CIAO: Opening the Ada 95 Distributed Systems Annex to CORBA Clients. In Ada France 1999, Sept. 1999. D. C. Schmidt and C. Cleeland. Applying Patterns to Develop Extensible ORB Middleware. IEEE Communications Magazine Special Issue on Design Patterns, 1998. D. C. Schmidt and S. Vinoski. Comparing Alternative Server Distributed Programming Techniques. SIGS C++ Report, 7(8), Oct. 1995. A. Singhai. QuarterWare: A middleware toolkit of software RISC components. PhD thesis, University of Illinois at Urbana-Champaign, 1999. A. Singhai, A. Sane, and R. H. Campbell. Quarterware for Middleware. In Proceedings of ICDCS’98. IEEE, May 1998.
