The success of Object Request Brokers (ORBs3) in telecommunications essentially depends on their capacity to adapt them to the specifics of telecommunication systems, and in particular to the support of interactive multimedia services.
This implies that ORBs should be uniformly available across traditionally separate systems, ranging from low-end network equipments such as routers and cross-connects to high-end information processing intensive nodes such as those supporting network operation and management functions and operators' information systems.
Another strong requirement on telecommunication ORBs is their support of various binding and interaction models.
The term binding should be understood as both the process of associating or interconnecting different objects of a computing system according to a specific communication semantics, and as the end result of this process. Binding implies setting up an access path between objects, which in turn typically comprises locating objects, checking access rights and setting up appropriate data structures to enable communication between objects. Even in the standard client-server case, there is a wide variety of communication semantics that reflect different application requirements. For instance, servers may be persistent, replicated, or may use caches with various consistency policies to improve performance, availability, etc. Other forms of bindings include e.g.:
Lastly, telecommunication systems are typically open, real-time systems, and it is crucial that ORBs achieve real-time behaviour and performance.
By real-time systems, we understand in this paper systems whose users are allowed to specify timeliness and throughput quality of service (QoS) requirements and to obtain guarantees about the fulfillment of these requirements. The nature of guarantees provided may vary from best-effort (where the system provides no quantitative guarantee of how well or how often it will meet application QoS requirements) to deterministic (where the system guarantees that application requirements will be strictly met throughout the lifetime of the application).
An open real-time system is a system whose set of supported applications is not known before-hand and which may vary over time. The main consequence of this is that strong (i.e. stronger than best-effort) guarantees can be provided only via some form of run-time admission control. Providing timeliness and throughput guarantees in an open distributed real-time system is a formidable task: To the best of our knowledge, there is currently no comprehensive and systematic approach to the problems at hand. Even in the case of relatively simple communication facilities, such as a channel supporting communication between a pair of objects, deriving e.g. admission control tests for guaranteed end-to-end delay bounds involves recent advances in scheduling theory. Also, it seems unlikely that a single scheduling policy or even task model will be applicable in all cases and all application domains. For these reasons, a real-time ORB should, as a general principle of separation between policy and mechanism, refrain from embodying any particular resource management policy. Instead, a real-time ORB ought to be flexible enough to accommodate different such policies and should provide direct control of system resources such as processors, memory and communication to applications.
Architectures like CORBA or JAVA-RMI don't seem to be particularly adapted to telecommunications systems. A large part of these architectures remains largely monolithic and disallows adapting or extending the internal machinery short of resorting to proprietary extensions. In terms of computing and network resources, they offer very little control on how resources are allocated and multiplexed. As a result, it is not clear how to provide adaptations required to support multimedia and real-time applications or to scale down these architectures to fit resource-constrained devices such as portable phones or interactive TV set-top boxes.
The work pursued in the context of the ACTS ReTINA project [14] is to specify and implement a flexible ORB architecture whose machinery is exposed to the systems or application programmer.
The prime characteristic of this architecture is the ability to plug arbitrary forms of binding policies between objects beyond the implicit binding model for client-server interactions assumed by standard architectures like CORBA or RMI. This goal has been achieved by designing a minimal ORB kernel whose role is to provide a generic environment that arbitrary binding factories can use to create and manage specific bindings.
In this approach, a CORBA compliant ORB can be built as a particular ``personality'' (i.e. a set of APIs and language mappings), thus decoupling the specifics of the CORBA API from the personality-independent kernel interface. This is also true for a non-CORBA personality like Java-RMI.
The aim of this paper is to provide a clear description of the ORB kernel architecture, and to show how a CORBA ORB can be built on top of it. To illustrate this, we shall use the Jonathan Distributed Processing Environment (DPE), developed in Java at CNET, that implements the specifications of the ORB kernel and a CORBA personality.
The ReTINA architecture also features a communication framework allowing the modular construction of protocols (suited for RPC or stream styles of interactions), and the reuse of protocol components between binding implementations. This framework, implemented in Jonathan, is very similar to the x-kernel [12] framework, and the reader is referred to [2] for a more detailed description.
Lastly, the ReTINA architecture proposes a resource framework, featuring a number of abstractions to manage real-time resources, that provide direct control of system resources to applications. The resource framework has not been implemented in Jonathan since it requires an access to the underlying system-level resources, that current implementations of the Java virtual machine do not provide.
This paper is structured as follows: Section 2 describes the ORB kernel architecture, and how it is implemented in Jonathan; Section 3 describes in more details how a CORBA ORB may be built on top of the Jonathan kernel, and in particular how a binding factory able to create RTP multicast channels can be built in this context; finally, Section 4 concludes by providing more information about the current status of the Jonathan DPE, comparing with related works, and sketch future research.
In a standard Java method invocation like:
return_value = object.method(...);
at least three problems need to be addressed:
When restricted to a single virtual machine, solutions to these three problems are well known:
These solutions need to be extended when dealing with an invocation to a remote object, and it is the role of an ORB to provide such extensions. Since ORBs may operate over heterogeneous platforms and programming languages, there is a need for an abstract object model that can be mapped on specific platforms and languages: Jonathan (like CORBA) is based on the Reference Model of Open Distributed Processing (RM-ODP [7,8,9,10]). In the following, we shall use RM-ODP terminology to designate abstractions:
To address the interaction problem, RM-ODP introduces the notion of binding object. Two objects -say O1 and O2- may interact in two different ways: Either object O1 directly invokes an operation on O2, or it invokes the same operation on a binding object whose role is to transmit the invocation to O2 and to return a result if necessary (cf. Figure 1). In the first case, both objects must belong to the same addressing space (also named capsules); in the second case, the interacting objects may belong to distinct addressing spaces.
Binding objects are usually composite objects, distributed over several capsules. Binding objects encapsulate the full end-to-end computational binding between interacting objects, including communication resources, protocols, stubs, etc. In our model, bindings have a type, the type of a binding representing the protocols used, possible quality of service constraints, or any other kind of binding property. Note that binding objects can represent not only client-server bindings, but any kind of binding including e.g. those described in the introduction.
Bindings are constructed by special entities named binding factories. Binding factories have two main roles:
In its current version, the Jonathan DPE provides three binding factories of different types, two of which create client-server bindings (one uses the IIOP protocol, the second a simpler remote invocation protocol), and the third RTP multicast bindings.
To address the typing and referencing problem, RM-ODP introduces the notion of interface reference. An interface reference may be seen as a generalized Java object reference. Interface references are characterized by two elements:
Like Java references, interface references have a type, whose role is to allow the creation of safe bindings.
There is no universal type system, and different type systems (and type conformance rules) may be used for different bindings. In our model, type systems are related to personalities: a personality defines the type and binding type systems used by binding factories belonging to it5. For instance, CORBA is a personality: it defines types by the means of IDL declarations, and binding types by the means of profile ids. It is then possible to build various CORBA binding factories, using different protocols, that will use this type system: For instance, all the binding factories provided with Jonathan use the CORBA type system.
However, an interface reference may have to be manipulated in different personality contexts. We can imagine a capsule featuring two binding factories, the first building CORBA IIOP bindings, the second building RMI bindings, each of them having to manipulate the same interface reference. To make this possible, the interface reference associated type must be defined in a reference, personality-independent, type system. Each personality present in the capsule must provide ways to translate types from its own type system to the reference type system, and conversely (cf. Section 2.3). In our model, the reference type system is defined by the ORB kernel. The same holds for binding types: the ORB kernel defines a reference binding type system, and each personality has to define its own binding type system with the necessary translation functions.
An identifier is created by a binding factory before the interface reference is sent out of its originating capsule6, and may be used by another binding factory of the same type in a different capsule to unambiguously designate the referred interface.
An identifier is thus always associated to a given binding type. An interface reference may have identifiers of different types, corresponding to different ways to designate the target interface.
If we continue our comparison between interface references and Java object references, the equivalent of the identifier is the memory address contained in a Java reference. Interface references generalize this notion in the sense that several identifiers may be associated with one interface reference, and the process of resolving an identifier into an interface residing in a given address space may be much more complex than dereferencing a pointer.
Thus, the three problems stated above (distributed referencing, typing and access) are represented by different abstractions: Interface references for the referencing problem, personalities for the typing problem, and binding factories for the access problem. The next subsections illustrate these points in the case of Jonathan.
The first thing an RM-ODP compliant ORB has to define is its own way to map the notion of interface, in a specific implementation language.
When an object oriented language is used, an RM-ODP object is usually implemented by a collection of language level objects. Some of these language level objects correspond to access points to the corresponding (abstract) RM-ODP object and as such constitute implementations of its interfaces. One way to concrete the RM-ODP notions of object and interface is thus to see an RM-ODP object as a collection of language level objects, and an interface of this RM-ODP object as a given accessible element of the collection.
In CORBA+Java, or RMI, the objects implementing RM-ODP interfaces have a special type (org.omg.CORBA.Object for CORBA, java.rmi.RemoteInterface in RMI). Likewise, in Jonathan, an interface is represented by a Java object of type Interface:
package jonathan.kernel;
public interface Interface {}
A reference (in the Java sense) to an object of type Interface represents an interface reference.
According to the ODP and CORBA computational models [9,11], interfaces are passed by reference in invocations. As long as the interface reference remains in its original capsule, there is no need for extra information: Its type is defined by the actual Java type of the interface, and there is no need for specific identifiers. But as soon as an interface reference is sent out of its capsule, we need a way to associate more explicitly type information and identifiers with it. Since an interface reference may be associated with identifiers created by various binding factories, this way must be normalized to allow interoperability. To achieve this, we introduce the Surrogate type:
package jonathan.kernel;
public interface Surrogate extends Interface {
Type _type();
IfRef _ifRef();
}
The type information corresponds to the local type of the surrogate7.
The IfRef is the container for the identifiers of the designated interface and its type. IfRefs in Jonathan are structured as follows:
package jonathan.kernel;
public class IfRef {
Type type()...
Key key()...
BindingDataSet bindingDataSet()...
}
Structuring identifiers as �key, binding data� pairs allows a factorization across different binding factories of the same key for identifying a given interface. In the Jonathan DPE, the kernel maintains a hashtable associating keys and interfaces, that any binding factory can use. Note that this does not prevent different binding factories to use their own (equivalent of) keys (which should then be hidden in the binding data).
Both IfRefs and surrogates represent interface references, and it would have been possible (though not necessarily convenient) to have only one type for both. In fact, they are not used at the same level:
Each binding factory must be able to create a surrogate -i.e. a distribution-ready interface reference- for a given interface. The simplest form8 of this operation is the following (cf. Figure 2):
The export operation takes an interface as parameter and returns a surrogate for this interface. The IfRef of this surrogate contains binding data added by the invoked binding factory9.
The returned surrogate is of type LocalSurrogate: The specificity of local surrogates is to be equipped with a continuation pointing to the designated interface. This continuation signifies the relation between the IfRef held by the local surrogate and the represented interface.
One essential role of binding factories is to make sure that when an interface reference is sent as a parameter in a remote invocation, the invoked object will receive an interface reference that references the right interface.
The above condition may be decomposed into two simpler invariants that binding objects must maintain:
This means that either i is a surrogate -and its IfRef is used-, or it is not (it is simply of type Interface), and it must be exported to a binding factory, so that an IfRef representing it is created.
This interface reference is either a surrogate bearing the received IfRef11, or the interface reference represented by the IfRef (if it can be proved that it is local).
If these invariants are maintained, every non local surrogate s can be associated with a local surrogate l (possibly located in another capsule) bearing the same IfRef, and the interface represented by s is the continuation of l, or the interface designated by that continuation. Since nothing prevents surrogates from being explicitly exported to binding factories, the continuation of a local surrogate is indeed not necessarily the effective implementation of the designated interface, but may be one of its surrogates.
The above invariants ensure that every surrogate belongs to a reference chain (cf. Figure 3) uniquely identifying a given interface.
A reference chain is constituted by a sequence of interfaces
|
Each surrogate sj in the chain is such that either:
These two properties directly correspond to the two invariants mentioned above.
Several type systems may have to cohabit in the same capsule, and the ORB kernel has to define a reference representation of types (and binding types) that different personalities will have to translate into their own type system.
Jonathan defines a Type type:
package jonathan.kernel;
public class Type {
public Type(String str_type)...
public boolean is_a(Type type)...
public String to_string()...
...
}
Jonathan also defines a BindingType type.
package jonathan.kernel;
public class BindingType {
public BindingType(int id)...
public int encode()...
...
}
Binding factories are responsible for the creation and management of bindings of a given type. To create bindings (i.e. instantiate binding objects), they use the identifiers of the interfaces to bind, and in particular the binding data of the appropriate type: Binding factories implement binding functions, that can resolve such identifiers into effective access chains to the remote interfaces, thus enabling interaction.
When an IfRef is received in a capsule, and if it cannot be proved that the IfRef corresponds to an interface residing in the capsule, a surrogate must be created. This surrogate may be directly invocable, like in the classical implicit binding case in ORBs or distributed object systems: In this case, a communication channel is set up either at the creation of the surrogate, or at the first invocation.
This surrogate must know which binding factory to invoke to set up the communication channel, but there is no reason to impose that the binding factory used to create the current binding (used to perform the invocation) should also be able to bind the new surrogate: The received IfRef may not contain an appropriate identifier.
The task of finding the appropriate binding factory is devoted to the ORB kernel. The kernel maintains a table of the binding factories in the capsule that can be used to implicitly bind surrogates. As each of these binding factories is associated with a binding type, the kernel simply needs to know the types of the binding data present in an IfRef to find -if possible- a binding factory able to implicitly bind the corresponding surrogate.
In Jonathan, this is implemented by a method getInvocable that takes an IfRef and a type (represented as a string) as parameters, and returns a surrogate (cf. Figure 4):
This method is implemented both by the kernel and by the binding factories: When an IfRef is unmarshalled in a binding object, the binding object invokes the getInvocable method on the kernel, that will forward it to an appropriate binding factory, if any:
This discussion shows that our framework makes a clear distinction between stubs and surrogates:
If the kernel can't find any suitable binding factory to implicitly bind the surrogate, explicit binding must be used. Binding factories may define a bind operation that is used to explicitly create bindings. The form of this operation may be very different from one binding factory to another. In its general form, it takes as parameters a set of interfaces to bind and quality of service constraints that need to be guaranteed, and returns a control interface on the created binding object. Note that our framework does not constraint the possible binding scenarios, and that any one can thus be implemented (including third-party binding, cf. [3]).
Explicit binding is used by the Stream binding factory provided with the Jonathan DPE, to create multicast RTP channels (cf. Section 3.3).
Building a CORBA 2.0 ORB on top of the Jonathan kernel means providing:
The CORBA12 personality is implemented as a set of four packages containing the standard CORBA definitions. The only extensions of the CORBA standard can be found in the implementations of org.omg.CORBA.Object and org.omg.CORBA.ORB.
The CORBA personality needs not provide translation methods for binding types since binding types are represented by integers constants both in CORBA (``profile ids'') and Jonathan.
The Jonathan implementation provides a stub factory. In the ReTINA architecture, a stub factory is simply an object whose role is to instantiate stubs and skeletons. As it is a CORBA stub factory, it comes with an IDL compiler that generates code for stubs. An interesting property of the current Jonathan stub factory is that it is independent of the underlying protocols, and of the binding factories that may use it. That's how all three binding factories provided with Jonathan (see Section 3.2) can use the same stubs, even though they are based on different protocols. A simple smart stub mechanism is also provided.
Like in standard CORBA implementations, the generated stubs are CORBA Objects, and thus surrogates. The generated skeletons are also CORBA objects, and implement the LocalSurrogate interface. This way, the local surrogate abstraction may be introduced at no cost in the system: when an invocation is received from a remote capsule, there is no unnecessary indirection due to the existence of a local surrogate.
The resulting interface types hierarchy is depicted on Figure 5.
CORBA Object Adapters can be understood as server-side interfaces to binding factories. In particular, the create operation on the BOA is a specific form of export.
Jonathan doesn't provide a standard BOA interface, but three binding factories. As we have seen, binding factories are responsible for the creation and management of bindings, and rest on specific libraries (protocols, stub factories, personalities) to achieve this.
Jonathan provides five independent protocol packages built following the binding and communication framework sketched in the introduction: The protocols.tcpip package represents the TCP/IP protocol (it is built on top of the java.net package), the protocols.multicastip package lets the user open multicast channels, the protocols.rtp package is a limited implementation of the Real Time Protocol, protocols.giop provides an implementation of CORBA's GIOP protocol, and protocols.miop provides an implementation of a simpler invocation protocol.
In Jonathan 1.2, all three binding factories use the same personality and stub factory, but use different protocols.
The binding data used by the IIOP binding factory implement the BindingData interface, and extend the org.omg.IIOP.ProfileBody class: Consequently, they contain a host name, a port number, and a key (represented as an array of bytes encoding the IfRef key).
In this section, we shall describe with an example how the Stream binding factory provided in Jonathan works, and how it can be used.
The Stream binding factory creates ``abstract'' typed objects representing multicast RTP channels. These objects are abstract in the sense that no capsule contains a real implementation of such objects: they are only manifested to the users by surrogates containing a specific multicast address (cf. Figure 6).
The type of the channel is defined by the user thanks to an IDL declaration. For instance, the following declaration can be used:
The binding factory can create multicast channels of a given type, simply by providing the type, a class D IP address, and a standard UDP port number: The following invocation on StreamBF (the Stream binding factory), returns a surrogate of the multicast channel specified in the invocation:
// Java
DataChannel channel = (DataChannel)
StreamBF.getInvocable("DataChannel","224.10.0.0",(short)9000);
The IP address and the port number are stored as binding data in the returned surrogate's IfRef. This surrogate is implicitly bound: A producer can immediately emit data in the channel by invoking a method on the returned object:
// Java
channel.send(new byte[1024]);
At the first invocation on the surrogate, a binding object is created, whose role is to compose RTP packets with the data sent, and write them to the multicast channel. This is signified on Figure 6 by a binding object in the capsule of the producer. The dotted arrow between the binding object and the stream channel means that the binding object is also a surrogate.
Since the returned interface is a surrogate, it can be passed as argument in any CORBA invocation (even if another binding factory is used). For instance, it can be registered in a trader under the name "data_channel".
A consumer must be an implementation of the DataChannel interface. To receive data, a consumer must first retrieve a reference on a channel (e.g. by invoking the trader where the channel is registered), and then explicitly get bound to the channel. This is achieved by the bindConsumer method of StreamBF:
The get invocation on the trader returns a surrogate of the multicast channel. At this point, the situation is that of consumer B in Figure 6: there is a surrogate of the stream channel in the capsule. The bindConsumer invocation creates a binding object (represented in the capsule of consumer A) that reads RTP packets from the multicast socket, and recomposes the original message before forwarding it to a consumer.
ctl is a control interface of the binding between the channel and the consumer. It comprises a release() method that can be used to stop forwarding data from the channel to the consumer: the release method destroys the binding object created by bindConsumer.
We have described in this paper a highly flexible and modular DPE architecture organized around a very small binding-independent core. This architecture essentially introduces a distributed reference abstraction properly interfaced with that of binding. This separation enables the encapsulation of reference management and binding management in different objects: The ORB kernel for references, and various binding factories for bindings. It is thus possible to introduce in a modular fashion new bindings within an ORB based on this framework, while retaining interoperability. In the case of Java, the ORB kernel could in fact be completely integrated in the virtual machine: Surrogates are simply an extension of the notion of object reference; they could be implemented in a reflective Java virtual machine by modifying the implementation of object references, thus enabling a seamless integration of distribution in the language.
The current Java implementation of this DPE architecture -Jonathan- has confirmed that it is stable and generic enough to accommodate arbitrary types of binding and communications mechanisms, while remaining efficient:
Jonathan also scales very well, since we have been able to test a capsule running 100,000 server objects, the effect of the number of servers on an invocation duration being only related to swap overhead.
The last point on performance is that the modular organization of Jonathan makes it very easy to add specific protocols for real-time, or change the stub factory for a more specialized one. Our experience with Jonathan shows that the modular and flexible architecture we propose can be implemented at no cost in terms of performance.
Jonathan is available freely for non-commercial use. Interested readers can contact the authors to obtain a copy of the software (Java sources are included).
This work has been inspired in part by the Spring distributed system [5] and the SOR system [15]. Spring provides the notion of subcontract that allows application programmers to define new client-server communication mechanisms. SOR provides a flexible binding protocol which can be used to establish arbitrary client-server bindings. The framework proposed here generalizes these approaches to arbitrary types of interactions and in particular to multi-party multimedia communication schemas. It also generalizes more language-dependent ORB designs such as Network Objects [1] and Java-RMI [6]. Our architecture can also be seen as a weak form of the SSP chains framework [13]: in particular, the two reference chains invariants described in Section 2.2.3 are the first two invariants required for the proper integration of the garbage collection algorithm of [13]. SSP chains could be developed as a specific binding factory maintaining the remaining necessary invariants, thus enabling acyclic garbage collection.
Future work on Jonathan will focus on the areas of resource management and admission control in order to provide full support for end-to-end QoS. Reflexivity will be used as the major architectural principle to achieve this goal. Opening the virtual machine in a reflective way would in particular allow the implementation of the ReTINA resource framework in a very flexible and modular way: The ReTINA resource control framework provides applications with access to the system-level resources they require for their execution, and this access is the first step towards quality of service management.
1 A shorter version of this paper ([4] has been accepted to the Middleware'98 conference.
2 Work partially supported by ACTS project ReTINA AC048
3 The term ``ORB'' should be understood in a loose way throughout this article as a distributed object-oriented system, not necessarily a CORBA compliant platform.
4 In the following, we shall identify the type of the bindings created by a binding factory and the type of the binding factory itself.
5 plus a set of APIs and language mappings.
6 This is the first invariant that must be maintained by any ReTINA environment in order to maintain the integrity of the associations between identifiers and interfaces, cf. 2.2.3.
7 In Java (or C++), the type of an object reference is not necessarily the most refined type of the designated object, but must be a supertype of that object. Likewise, the type of a surrogate is not necessarily the most refined type of the interface it represents, but must be one of its supertypes.
8 More sophisticated export methods could manage e.g. offered quality of service descriptions, or more simply type information (it is the case of all binding factories in Jonathan 1.2). Java RMI only provides the simplest export form as the exportObject method of java.rmi.server.UnicastRemoteObject.
9 It may also contain other binding data, if the same interface has been previously exported by other binding factories.
10 The exact format of encoded IfRefs is protocol dependent: For instance, if IIOP is used, IfRefs are marshalled as Interoperable Object References (IORs).
11 If a surrogate bearing the same IfRef exists in the capsule, it can be used, otherwise a new surrogate must be created.
12 Jonathan only implements a subset of CORBA 2.0. It is not complete since CORBA features like the Any type or the Interface Repository are not implemented. However, the implemented subset is rich enough to implement non-trivial applications.