THE DESIGN AND IMPLEMENTATION OF OPEN ORB V2Gordon S. Blair, Geoff Coulson, Anders Andersen1, Lynne Blair, Michael Clarke, Fabio

Costa, Hector Duran-Limon, Tom Fitzpatrick, Lee Johnston, Rui Moreira2, NikosParlavantzas and Katia Saikoski

Distributed Multimedia Research Group,Department of Computing,

Lancaster University,Bailrigg, Lancaster,

LA1 4YR, U.K.Tel: +44 1524 65201

Fax: +44 1524 593608E-mail: reflection@comp.lancs.ac.uk

ABSTRACTMiddleware has emerged as an important architectural component in modern

distributed systems. However, it is now recognised that established middlewareplatforms such as CORBA and DCOM are not flexible enough to meet the needs ofthe emerging distributed applications, featuring for example access to multimediaservices and also support for mobile users. Rather, we argue that next generationmiddleware platforms should be i) more configurable, ii) dynamically reconfigurable,and iii) should support the longer term evolution of the design of the platform. Thispaper discusses the design of the Open ORB v2 middleware platform, whichaddresses these requirements through an approach based on reflection together withthe use of component technology. Important issues addressed in the paper include theuse of architectural constraints to maintain the integrity of reflective middlewareplatforms, together with studies of efficient implementation of such technology. Thecapabilities of the Open ORB platform are also demonstrated through a series ofapplication-level experiments.

1. INTRODUCTION

Middleware has emerged as an important architectural component in modern distributedsystems. The role of middleware is to offer a high-level, platform-independent programmingmodel to users (e.g. object-oriented or component-based) and to mask out problems ofdistribution. Examples of key middleware platforms include DCE, CORBA, DCOM, .NET,and the Java-based series of technologies (RMI, JINI, EJB). Traditionally, such platformshave been deployed (with considerable success) in application domains such as banking andfinance as a means of tackling problems of heterogeneity, and also supporting the integrationof legacy systems. However, more recently, middleware technologies have been applied in awider range of areas including safety critical systems, embedded systems, and real-timesystems. In addition, middleware is required to respond to emerging technical challenges asoffered for example by multimedia or mobile computing. It is now becoming apparenthowever that middleware technologies such as the ones listed above are not able to respondto such diversity or to such technical challenges. The main reason for this is the black-boxphilosophy of existing platforms. In particular, existing middleware platforms offer a fixedservice to their users, and it is not possible to view or alter the implementation of this service.Inevitably, the architecture of this platform then represents a compromise design featuring,

1 Also of the University of Tromsø, Norway.2 Also of UFP (Universidade Fernando Pessoa) and INESC-Porto.

2

for example, general-purpose protocols and associated management strategies. It is then notpossible to specialise platforms to meet the needs of more specific target domains.

Middleware designers are aware of this problem and have responded with a number ofinitiatives. Focussing on CORBA for example, the OMG have introduced a series of platformspecifications including real-time CORBA and Minimal CORBA. These are however specificsolutions to specific domains and are not a general solution to this problem. Modernmiddleware platforms also typically offer more flexibility through mechanisms such asinterceptors and configurable protocol stacks. These are important developments but, in ouropinion, they do not offer a complete solution to the problem. Rather, we believe that nextgeneration middleware platforms should have the following properties:

1. they should be configurable to meet the needs of a given application domain (e.g. toprovide a minimal configuration for embedded systems),

2. they should be dynamically reconfigurable to enable the platforms to respond tochanges in their environment (e.g. to respond to dramatic fluctuations in networkquality of service as experienced in mobile computing), and

3. they should support the evolution of the design of the platform as requirementschange over time (e.g. to respond to the need to support continuous mediainteractions).

Recently, a number of reflective middleware technologies have emerged in response tosuch requirements. Reflection is a technology that has previously been deployed successfullyin the design of programming languages and operating systems (amongst other areas). Thekey to the approach is to offer a meta-interface supporting the inspection and adaptation ofthe underlying virtual machine. In terms of middleware, this implies that the meta-interfaceshould support operations to discover the internal operation and structure of the middlewareplatform (e.g. protocols and management structures being deployed) and to make changes atrun-time. The design of such a meta-interface is central to studies of reflection: the interfaceshould be sufficiently general to permit unanticipated changes to the platform but should alsobe restricted to prevent the integrity of the system from being destroyed (we return to thiscrucial issue later in the paper).

This paper presents the design and implementation of Open ORB, a reflective middlewareplatform developed at Lancaster University. More specifically, the paper focuses on OpenORB v2, a significant re-design building on our experiences from the use of our firstimplementation of the platform (descriptions of this earlier version of the platform can befound in the literature [Blair98a, Costa98, Costa00a, Andersen00]). The paper presents abroad view of our work ranging from studies of reflective architecture, through studies ofefficient implementation, to a series of validation experiments for the technology.

The paper is structured as follows. Section 2 discusses the overall architecture of OpenORB, highlighting the complementary role of reflection and component technologies, andalso the use of a multi-model approach. Section 3 then presents some work on the efficientimplementation of Open ORB, using an extension to the COM component model (OpenCOM). Following this, section 4 describes a variety of application experiments intended tovalidate the architecture. These experiments demonstrate the capabilities of the architecturewith respect to each of the properties introduced above (configurability, dynamicreconfiguration and evolution). Related work in the area of reflective middleware is discussedin section 5, with some overall conclusions drawn in section 6.

3

2. THE OPEN ORB ARCHITECTURE

2.1. Overall Approach

The Open ORB architecture builds on two complementary technologies namelycomponents and reflection. Component technologies are gaining widespread acceptance inthe middleware community, as witnessed by the popularity of COM and JavaBeans, and alsothe imminent publication of the component-based CORBA v3 specification. For the purposesof this paper, we define a component to be “a unit of composition with contractuallyspecified interfaces and explicit context dependencies only” [Szyperski98]. In addition, acomponent “can be deployed independently and is subject to third-party composition”[Szyperski98]. The middleware technologies mentioned above adopt a component-basedprogramming model to enhance the configurability, reconfigurability and level of re-use inapplications. We extend this capability to the design of the middleware platform itself. Inparticular, an instance of Open ORB is a particular configuration of components, which canbe selected at build-time and reconfigured at run-time. For example, we can opt for a minimalconfiguration of components, perhaps offering only client-side capabilities, to run on a PDA.Similarly, we can replace a particular protocol component at run-time should networkconditions change significantly.

Note that our particular component model is heavily influenced by previous work on theSumo Project at Lancaster [Blair98b], and also by the Computational Model from RM-ODP(again see [Blair98b]). In particular, the component model is designed to support multimediaprogramming. The main features of our component model are: i) components are described interms of a set of required and provided interfaces, ii) interfaces for continuous mediainteraction are also supported, iii) explicit bindings can be created between compatibleinterfaces (the result being the creation of a binding component), and iv) components offer abuilt-in event notification facility.

Access to the underlying platform, and by implication the associated componentstructure, is provided by reflection. In particular, every application-level component offers ameta-interface providing access to an underlying meta-space which is in effect the supportenvironment for this component (cf the middleware platform). Crucially, meta-space is itselfcomposed of components. Such (meta-level) components also have a meta-interface, offeringaccess to their support environment. This approach is therefore recursive, leading to aninfinite tower of reflection. In order to overcome this, meta-components are instantiated ondemand; unless accessed, they exist in theory but not in practice.

In our design, meta-space is partitioned into a number of distinct meta-space models. Thisapproach was first advocated by the designers of AL-1/D [Okamura92]. The benefit of thisapproach is to simplify the interface offered by meta-space by maintaining a separation ofconcerns between different system aspects. This is particularly important in distributedsystems given the wide range of concerns that must be considered (in comparison to thedesign of a single programming language for example). The structure of meta-space iscaptured by figure 1 below.

4

Meta−level

Base−level

Address Space

(per address space)Resources meta−objectArchitecture

meta−objectInterface

meta−object meta−objectInterception

componentBase−levelcomponent

Base−level

Figure 1: The structure of meta-space.

We consider this structure in more detail below.

2.2. The Meta-Space Models

2.2.1. Supporting Structural ReflectionIn reflective systems, structural reflection is concerned with the content and structure of a

given component [Watanabe88]. In our architecture, this aspect of meta-space is representedby two distinct meta-models, namely the interface and architecture meta-models. The twometa-models represent a separation of concerns between the external view of a component(i.e. its set of interfaces), and the internal construction (i.e. its software architecture). Weintroduce each model in turn below.

The interface meta-model provides access to the external representation of a componentin terms of the set of provided and required interfaces. In particular, it is possible toenumerate all provided (or required) interfaces offered by a given component, or to discoverthe type signature associated with a given interface. This meta-model therefore provides acapability similar to introspection facilities in the Java reflection API, allowing a programmerto interact with a component discovered dynamically in the environment. Unlike the previousdesign [Blair98a], it is not possible to access the internal implementation of an interface (as aset of methods and attributes); nor is it possible, for example, to add methods to thisimplementation. Rather, we enforce the strict separation referred to above between interfaceand implementation, in keeping with this important principle of component-basedprogramming. Important benefits of this approach will emerge from the discussion below.

The architecture meta-model then provides access to the implementation of thecomponent as a software architecture, consisting of two key elements: a component graphand an associated set of architectural constraints (cf components frameworks as introducedin section 3.3 below). The concept of the component graph is central to this design, and isrepresented by a set of components (more specifically interfaces) connected together by localbindings, where a local binding represents a mapping between a required and providedinterface in a single address space. Distribution can be added into the model by introducing(distributed) binding components into the graph (cf connectors in the software architectureliterature). An extensible set of binding types can be supported offering interaction modelssuch as remote invocation, publish/ subscribe, continuous media flows, groupcommunication, etc. Normally this structure would be hidden from a user of a component.However, the architecture meta-model can be used to both discover and also make changes to

5

this structure at run-time.If unconstrained, this is a rather dangerous approach to advocate. Consequently, we

extend the software architecture to include a set of architectural constraints. The typemanagement system offers one level of constraints, i.e. a new component must be a validsubstitution of the old component (cf subtyping of the respective interfaces). This is howevernot enough; it is also important to take a more global view of the architecture in determiningvalidity of adaptations. For example, changing a compression component may require asimilar change to the peer decompression component. Similarly, it may be necessary topreserve a given architectural style over time such as pipes-and-filters. Our approach is torecord such constraints explicitly in the architecture and to ensure that adaptations preservethe architectural rules before committing the changes (cf atomic transactions). At designtime, we adopt a combination of UML, OCL and natural language to capture suchconstraints. At run-time, we are investigating two alternative approaches (see sections 3.3 and4.2):

1. An implicit approach whereby constraints are captured indirectly by the interfaceoffered by an architecture (i.e. only certain safe operations are permitted);

2. An explicit approach where constraints are encoded using an appropriate notation.In both approaches, a mapping can be defined from the design-time representation to the

run-time representation.Note that the approach described above is applied recursively in that components within a

component graph may themselves have architecture, accessed via its architecture meta-model(i.e. at a meta-meta- level relative to the uppermost component. For example, a bindingcomponent within a graph may itself have a structure consisting of stubs and protocolcomponents. This recursion terminates with primitive components, which have no visibleunderlying structure, and whose internal implementation details are inaccessible to theprogrammer. Access at this level would inevitably depend on the language of implementation(e.g. a reflective language may enable access to methods), and hence this is deemed beyondthe scope of a (language-independent) middleware architecture.

Note also that with this approach interfaces are immutable, and represent irrevocablecontracts with their environment. In other words, it is not possible to change theimplementation behind an interface. Evolution is supported by the addition of newcomponents into an architecture supporting upgraded interfaces. Old clients can however stillrely on the previous interfaces to offer both functional and indeed their non-functionalguarantees. This also considerably simplifies the task of type management as discussed insection 2.3 below.

A further benefit of the new design is that strict controls can be placed on access rightsfor adaptation. More specifically, all classes of users can be given rights to access theinterface meta-model. In contrast, rights to the architecture meta-model can be tightlyconstrained so that only trusted third parties can modify the architecture of the system at run-time.

The interfaces (or meta-object protocols) for the interface and architecture meta-modelscan be found in appendix A.

2.2.2. Supporting Behavioural ReflectionBehavioural reflection is concerned with activity in the underlying system [Watanabe88].

More specifically, the design of Open ORB distinguishes between actions taking place in thesystem, and the resources required to support such activity. These two aspects are representedby the interception and resources meta-models respectively.

6

The interception meta-model is arguably the most straightforward in the Open ORBdesign, and is a simplified version of the environmental meta-model from the first version ofthe architecture. In keeping with a number of reflective middleware proposals, this meta-model enables the dynamic insertion of interceptors. Such interceptors are associated withinterfaces (more specifically, local bindings) and enable the insertion of pre- and post-behaviour. This applies equally to all styles of interface supported in Open ORB (operational,continuous media, etc). This mechanism is useful, for example, to dynamically introducemonitoring or accounting into a running system [Wegdam00]. Similarly, interceptors can beused to introduce additional non-functional behaviour, such as security checks or concurrencycontrol.

The resources meta-model in contrast is quite unique to the Open ORB design, offeringaccess to underlying resources and resource management [Duran-Limon00a]. We stronglybelieve that for many classes of application (including multimedia applications) it is just asimportant to be able to adapt resource usage and management policies as to evolve the basicstructure of the system, e.g. when now operating in a mobile environment.

The resources meta-model is based around the abstractions of resources and tasks3.Resources can be either primitive (e.g. raw memory or OS threads) or complex (e.g. buffersor user-level threads multiplexed on to kernel-level threads). They are created by resourcefactories and managed by resource managers, the latter typically building complex resourcesby adding value to, or combining, primitive resource instances. For example, a user levelscheduler is a resource manager that builds user level threads from OS threads. Tasks arethen the logical unit of activity in the system with the precise granularity varying fromconfiguration to configuration. For example, there could be a single task dealing with thearrival, filtering and presentation of an incoming video stream, or alternatively this could bedivided into a number of smaller tasks. Importantly, tasks can span component boundariesand are thus orthogonal to the structure of the system. Tasks are essentially the unit ofresource allocation, i.e. tasks have a pool of resources to support their execution.

There is a resources meta-model per address space, i.e. resources are associated with aparticular address space and all components within that address space share the same meta-model. The meta-model provides access to a set of components representing resourcemanagement. As with other meta-models, it is then possible to either inspect or adapt activityassociated with resources. For example, it is possible to insert monitors to capture statisticson the effectiveness of a thread scheduling policy and then possibly change this policy basedon the information collected. In programming terms, the resources meta-model is accessed asa graph structure that organises resources, tasks and managers into hierarchical structures.

As an extension to this work, we are currently experimenting with an enhancedarchitectural description language (ADL) called Xelha [Duran-Limon00b], building on thetask model described above. In common with many ADL’s, Xelha supports the specificationof software architectures in terms of components, their interfaces and connectors.Interestingly, the ADL also supports the overlaying of a task structure with associated qualityof service (QoS) requirements. The QoS requirements are then used to derive the underlyingresource allocation policies for tasks. Finally, the ADL also (optionally) supports theintroduction of dynamic QoS management structures in terms of monitoring and controllingcomponents. An example of the use of Xelha is given below (omitting dynamic QoSmanagement features):

Def connector <stream> AudioConnector_V1(string srcCapsule, string sinkCapsule):components:srcStub: SrcStub, srcCapsule

3 This aspect of the work is being developed along with our collaborators at France Telecom R&D. In particular, they

have contributed to the resource/ task model presented in this section.

7

sinkStub: SinkStub, sinkCapsuleconnectors:streamConn: StreamConnector(srcCapsule, sinkCapsule)interfaces:interaction:

IN: SrcStubIN, ( srcStub, IN )OUT: SinkStubOUT, ( sinkStub, OUT )

control:CTRL: StreamConnCTRL, (streamConn, CTRL)

composition graph:interfaces:

OUT: ( srcStub, OUT )streamConnIN: ( streamConn, IN )streamConnOUT: ( streamConn, OUT )IN: ( sinkStub, IN )

edges:( OUT, streamConnIN )( streamConnOUT, IN )

tasks:Def task transmitAu.marshall:switching points:

srcStub:CTRL:start [if taskx]

qos specifications:delay(srcStub:IN:read, streamConn:IN:put) = 5throughput(srcStub:OUT:put) = 64

Def task transmitAu includes transmitAu.marshall, transmitAu.unmarshall:importance: 5qos specifications:

delay(streamConn:IN:put, streamConn:OUT:put) = 10packet_loss(streamConn:IN:put, streamConn:OUT:put) = 5delay(srcStub:IN:read, sinkStub:OUT:write) = 20jitter(srcStub:IN:read, sinkStub:OUT:write) = 1

qos management structure: ...<not shown for simplicity>

This example is of a composite audio connector, consisting of source and sink stubsinterconnected by a stream connector. The early parts of this IDL are fairly traditional andhence we do not comment on them further. The task section however defines the taskstructure ad its associated QoS requirements (used to derive resource allocations as discussedabove. In this case, we can see the definition of tasks for marshalling the audio andtransmitting the audio. In the full version, there is also a task for unmarshalling the arrivingaudio packets, but this is omitted for brevity. The boundaries between tasks are defined bytask switching points, i.e. points where the system will switch to alternative pools ofresources, e.g. different set of threads.

Again, the meta-object protocols for behavioural reflection in Open ORB can be found inappendix A.

2.3. Extensions

Open ORB v2 contains two further enhancements to the previous version:1. An integrated approach to meta-information management. Meta-information

management in Open ORB v2 centres on the Open ORB type repository. This is anextension to the CORBA interface repository, but with additional features to supportour component model (e.g. stream interfaces, QoS annotations, media types, andprimitive and composite components and bindings). The kind of meta-informationmanaged by the type repository includes both the type and template aspects thatdescribe the elements of the component model. The repository therefore providessupport for type-checking and for the definition and instantiation of platformconfigurations. The model of the type repository (or more precisely its meta-model) isdefined in terms of the CORBA Meta-Object Facility (MOF), thus achieving a levelof integration between this intensional style of reflection (relating to the type system)and the more extensional styles already supported by Open ORB. The use of MOFtechnology also introduces the additional capability of being able to evolve the typesystem over time (although, to date we have not explored this aspect in any depth).We have also achieved a level of integration between meta-information in the typerepository and the typing and template information in the interface and architecturemeta-space models. This task is simplified considerably by the immutability of

8

interfaces in Open ORB. However, components and bindings can still change, e.g. byfeaturing a new interface or by adapting the internal architecture. This introduces theneed to manage type evolution. Essentially, the type repository becomes the source ofinformation on all stable (i.e. published) types (and templates) in the system, whereasthe structural meta-spaces become the source of the meta-information (type andtemplate) that describes the current (possibly evolved) structure of components.Eventually, such meta-information can also be turned into proper types and publishedin the repository for future use.

2. The incorporation of group services. Communication capabilities in the platformhave been extended to include configurable and reconfigurable group services throughthe provision of a group factory. Both open and closed group services are supported.The basic group factory supports a single method, i.e. createGroup, which takesan XML template as a parameter. This template defines the required softwarearchitecture of the group (as a component graph), one or more member types, andzero or more service types. A member type is essentially a template for futuremembers of a group, given by their interface type and a per-member configuration(e.g required protocol stacks, filters, etc). Service types are used in conjunction withopen groups and represent an externally visible view of the group. Crucially, the XMLtemplate is used to configure the group; for example, groups can be created with orwithout monitoring components in place. A group also features a default groupmanagement interface with the operations join, leave and getMembers. Thegroup service is also supported by a library of base components for IP multicast,reliable communication, ordering, collation, etc. The resultant group service can beaccessed using the various meta-models defined above. For example, the interfacemeta-model can be used to discover the external interfaces offered by a group.Similarly, the architecture meta-model can be used to adapt the implementation atrun-time (subject to the normal architectural constraints).

Further details of these important extensions can be found in [Costa00b] and [Saikoski00]respectively.

3. EFFICIENT IMPLEMENTATION

3.1. Overall Approach

The architecture described above has evolved through a series of prototypes written in thescripting language Python. Python was a natural choice for this prototyping work given theintrinsic support for rapid prototyping and also the underlying reflective capabilities of thelanguage. Nevertheless, given the interpreted nature of this language, it is not possible tofully investigate the performance characteristics of a reflective middleware platform.Consequently, we initiated a parallel activity to investigate the efficient implementation ofOpen ORB using C++. The stated goal of this work is to have a reflective middlewareplatform that (in standard configuration) performs at least as well as commercial ORBs butwith the additional benefits of reflective middleware. This is of course a worst case scenariofor the technology as reduced configurations should exhibit much better performance.

In more detail, the approach adopted is to define a base reflective component model,Open COM, as an extension to Microsoft’s COM architecture, and then to use this toimplement a component-based middleware platform (i.e. the middleware platform has itself acomponent-based architecture). We look at Open COM and the associated middlewareimplementation in turn below.

9

3.2. The Open COM Component Model

As mentioned above, Open COM is closely based on Microsoft’s COM but enhancedwith richer reflective facilities. Open COM relies only on the core of COM, i.e. providedinterfaces, the IUnknown interface and the basic language-independent binary-level standardthat enables components to be dynamically composed within a single address space; it avoidsdependencies on other features of COM such as distribution (via DCOM), persistence,security and transactions. Crucially, we do retain interoperability with other COMcomponents. Moreover, the binary-level nature of interconnections promises considerableperformance benefits over other component models such as JavaBeans.

One limitation of COM is that there are no mechanisms to make the connections betweencomponents explicit. If one component depends upon the interface of another (we term this arequired interface of the component) then it is accessed through a simple pointer variablewhose type and location are lost at compile time. This clearly makes it impossible to trackdependencies between components at run-time and consequently means that COMcomponents cannot be dynamically reconfigured. In our model, we define the receptacle datastructure as a first class run-time entity that maintains pointer and type information for aconnection between a component and a required interface. Connections are establishedexplicitly so that they are made known to the system. The component developer implementsan interface (IReceptacles) in order to allow the system to access the component'sreceptacles. Receptacles also contain other elements, e.g. locks, to allow the system toprevent invocations through a receptacle when a reconfiguration on the connection is takingplace.

Open COM then provides low level support for our meta-models as follows:1. The IMetaInterface interface provides meta-information relating to the interface

and receptacle types of a component (this interface can also be used to supportdynamic invocation of arbitrary methods as in Java core reflection);

2. The IMetaArchitecture interface provides access to the underlying graphstructure of components and their connections (assuming the component is notprimitive);

3. The IMetaInterception interface enables the dynamic attachment ordetachment of interceptors as defined above.

Note that this is only a subset of our reflective features defined above. For example, wedo not offer a resources meta-model at this level; rather we expect this to be constructedabove this level (in the Open ORB implementation). Similarly, we only offer a partialimplementation of the architecture meta-model; again, it is assumed that architecturalconstraints are introduced at a higher level.

10

Receptacles

Custom Service

MetaInterception

IUnknown

IMetaInterception IMetaInterception

An OpenCOM enabled componentIUnknown

Pointer variables

IMetaArchitecture2

OpenCOM

IUnknown

System Graph

Type Libraries

The OpenCOM component

MetaArchitecture

IUnknown

MetaInterface

IUnknown

IMetaArchitecture

Custom Interface

IOpenCOM

IMetaInterface2

IReceptacles

ILifeCycle

IMetaArchitecture

IMetaInterface

IMetaInterface

Figure 2: The architecture of Open COM.

The architecture of Open COM is summarised in figure 2 above.

3.3. The Middleware Architecture

The Open COM component model has been used to develop an implementation of theOpen ORB architecture. This platform can offer a CORBA-compliant interface, but is bothconfigurable and dynamically reconfigurable through the additional reflective features (forexample, the CORBA interface could be replaced by a SOAP interface). The platform alsoprovides support for multimedia, including streaming audio and video services. The design isheavily influenced by the GOPI platform, previously developed at Lancaster [Coulson98].

The implementation exploits the concept of component frameworks in its construction. Acomponent framework is defined as a collection of rules and contracts that govern theinteraction of a set of components [Szyperski98]. The main motivation for such componentframeworks is to constrain the design space and the scope for evolution. Moreover, theysimplify component development and assembly, enable lightweight components and increasethe understandability and maintainability of the system.

Component frameworks have often been used as a design time concept. We also adoptthis approach at run-time. In our approach, component frameworks define architectures(component graphs and constraints) for specific domains and provide (partial) support for ourarchitecture meta-model. In particular, our component frameworks are explicitly representedas components (called component framework representatives or CFRs), that are responsiblefor implementing the architecture meta-interfaces while enforcing the architecturalconstraints. This is achieved using the implicit approach to capturing constrains as defined insection 2.2.1). The middleware architecture is then decomposed into an extensible set ofspecialised and focused domains of concern, such as buffer management and bindingestablishment each based on a component framework /CFR.

More specifically, the middleware architecture is organised into three layers as shown infigure 3 (a more fine-grained view of the implementation is given in appendix B).

11

BT implementations

BindingLayer

CommsLayer

ResourceLayer

BindingCF

ProtocolCF

BufferMgt. CF

ThreadMgt. CF

MultimediaStreamingCF

Protocols

Filters

Buffer policies

TransportMgt. CF

SchedulersTransports

Figure 3: The component frameworks in Open ORB.

The binding layer contains the binding component framework that accepts a variety ofbinding type implementations (as discussed below). The communications layer then containsthe protocol component framework. Within this framework, a reconfiguration managermaintains information about the current protocol stack (organised as a component graph),which can then be adapted using the architecture meta-interface; the component frameworkwill ensure that the overall integrity of the protocol structure is maintained duringreconfiguration. This layer can be configured to include additional component frameworks,e.g. a multimedia streaming framework featuring a filter style. Currently, we are developing acomponent framework for multiparty communication protocols to support the group servicedescribed in section 2.3 above (the latter would appear as a specific binding type). At thelowest level, the resources layer has a number of component frameworks for buffer, transportand thread management. Again, adaptation can be tailored for the particular domain, e.g. thethread management component framework enables the dynamic installation of schedulercomponents and the migration of existing threads between schedulers.

The binding layer is arguably the most interesting feature of this architecture. In contrastto most existing middleware platforms, the Open ORB implementation supports anextensible set of binding types including remote method invocation, publish/ subscribe,message queuing, group communications and media streaming. Binding types aim to separatecommunication/ coordination aspects from computational aspects and hence simplifyapplications development. They also effectively implement software architecture connectors,thus bridging the gap to software architecture research.

The API offered by the binding component framework is based on a small number ofabstractions (iref, binder, resolver, generator, participant, etc) designed tocapture commonalities across diverse binding types. It does not attempt to specify a uniforminterface to all binding types (this is clearly infeasible) but rather it offers guidelines andgeneric interfaces which provide consistency for binding users and guidance for binding typeimplementers. The configuration of binding types can be configured statically and alsochanged at run-time by dynamic loading when an iref of a specific type arrives. More fine-grained changes to the binding type implementations can also be made using the reflectivefacilities of the component model. Further details of the binding component framework canbe found in a forthcoming paper [Coulson01].

Overall, the implementation of the platform consists of 6 component frameworks, around25 Open COM components and in total around 50,000 lines of C++ code (including supportfor audio and video streaming). A thorough investigation of performance is currently beingcarried out and will be reported in the above forthcoming paper [Coulson01]. Nevertheless,

12

early figures indicate that we will comfortably meet our target of outperforming commercialCORBA implementations. For example, the following figure provides an indication of therelative performance of the platform against Orbacus (one of the fastest commerciallyavailable ORBs) and GOPI (see figure 4).

0

500

1000

1500

2000

2500

3000

3500

4000

4500

1 32 64 256 1024 2048 4096 8192 16384

Bytes per RPC

OrbacusGOPIOpenORB

Figure 4: Performance measurements.

As can be seen GOPI performs best for invocations of up to 1024 bytes, then Orbacustakes over as the most efficient. The figures though for Open ORB are extremelyencouraging. For smaller invocations the performance of Open ORB and Orbacus arepractically identical, and it is only at larger invocation sizes that a (small) difference becomesapparent. This difference clearly comes from the underlying GOPI implementation strategies(also used in Open ORB) rather than any overhead of reflection. A comparison of Open ORBand GOPI also provides a first approximation of the overheads of reflection in Open ORB.This comes out at around a 10% difference between GOPI and Open ORB in terms ofthroughput of invocations. Again, we feel this is very encouraging for the Open ORB projectgiven the added capabilities of configurability and reconfigurability in Open ORB (which canboth be exploited to improve the performance from this baseline figure, e.g. by removingunnecessary components at run-time or introducing more specialist components for givennetwork conditions).

Note that tests were performed over the loopback interface on a Dell Precision 410workstation specified with a 550Mhz Intel Pentium III processor and 256Mb RAM. Thecompiler used was Microsoft's cl.exe with flags /MD /W3 /GX /FD /O2.

4. EVALUATION OF OPEN ORB

4.1. Experiments in Dynamic Reconfiguration

The first experiments with Open ORB focused on the use of reflection to supportdynamic reconfiguration. More specifically, we have experimented with adapting thestructure of continuous services in response fluctuations in the underlying network quality ofservice. This has been achieved by the development of a QoS management subsystem forOpen ORB offering both monitoring and controlling. In particular, QoS management isachieved by introducing management components into the component configuration

13

(accessed via the architecture meta-model). Different styles of management component areidentified in our architecture (see table 1).

MonitoringEvent Collector Observe behaviour of underlying functional

components and generate relevant QoS events.Monitor Collect QoS events and report abnormal behaviour to

interested parties.Control

Strategy Selectors Select an appropriate adaptation strategy (i.e. strategyactivator) based on feedback from monitors.

Strategy Activators Implement a particular strategy, e.g. by manipulatingcomponent graph.

Table 1. Styles of management component.

Event collectors and strategy activators are at the lowest level of this architecture,interfacing directly to the managed components, and using reflection to gain the requiredlevel of access to the underlying infrastructure (in terms of both introspection andadaptation). Monitors and strategy selectors in contrast are more abstract, and effectivelyrepresent the QoS management policy, e.g. to decide that the best course of action to be takenin response to increasing jitter in the network is to increase the buffer size of the receiver. Inour prototype system, the policies for monitoring and strategy selection are expressed astimed automata, which then map directly on to management components which then act astimed automata interpreters at run-time. They then interface to other components in thesystem using event notification, i.e. they register for events of interest, receive events, react tothem and then emit events to interested parties (cf reactive objects [Manna92]). This use oftimed automata also allows us to carry out formal analysis of the behaviour of the QoSmanagement subsystem in isolation, and also when composed with a model of the rest of thesystem [Blair01].

Two examples have been implemented using this approach, i.e. a QoS-managed audiostreaming application and a synchronisation protocol for stored video (both using the Python-based prototype). Experiments are also underway to extend this work to also allow thedynamic reconfiguration of resources and resource management policies, i.e. exploiting theresources meta-model as described above. Our experiences from this work so far have beenextremely positive. In particular, the experiments largely confirm our hypothesis thatreflection provides a principled approach to supporting adaptation in distributed systems(both in terms of the ability to monitor and also the ability to change the underlyingconfiguration). It is particularly heartening that QoS management can be introduceddynamically in our architecture, even if this has not been planned in advance. Furthermore,given the recursive nature of the architecture, it is also possible to monitor and adapt themanagement components, e.g. checking if a given policy is operating satisfactorily and, ifnot, changing the policy (effectively providing a level of meta-policy).

Further details of the QoS management architecture and associated experiments can befound in the literature [Blair00a]. A more general treatment of adaptation in Open ORB canalso be found in [Blair00b].

4.2. Other Ongoing Experiments

Work is now continuing on a series of experiments to more fully evaluate thearchitecture, as discussed below:

1. Configurability. To date, there has been very little work on exploiting the

14

configurability inherent in the Open ORB architecture (apart from the experimentswith the configuration of group services as reported in section 2.3 above). We arecurrently, however, investigating the use of Open ORB to configure middleware forminimal devices, such as the Palm Pilot. In addition, we are examining the use of thecomponent-based approach, together with the reflective facilities of Open ORB, tosupport the development of cooperative visualisation environments (in collaborationwith the Rutherford Appleton Labs) [Gallop00]. In both cases, the longer-term goalsare also to support dynamic reconfiguration, broadening our experience in this area.

2. Longer-term evolution. We are convinced that the Open ORB architecture alsoprovides interesting support for the longer-term evolution of software, i.e. asrequirements change over time. For example, the architecture meta-model capturesthe initial software architecture of the system in terms of components, connectors andarchitectural constraints. The designer can both access this software architecture, andthen use this information as the basis for making changes to the design. We arecurrently investigating this premise in two application domains, namely digitallibraries and banking. For example, in the digital library setting, we are consideringthe support offered by Open ORB for a series of evolutionary steps such asintroducing continuous media services, supporting mobile users, enhancing thescalability of the platform, etc. As part of this work, we are also re-implementing theOpen ORB architecture in Java. In this implementation, though, we are investigatingan explicit approach to representing architectural rules (see section 2.2.1). Thisapproach enables us to evolve the architecture itself, e.g. by modifying the constraintsover time.

The experiments described above will provide a relatively complete evaluation of thepotential of reflective middleware, in general, and Open ORB, in particular.

5. RELATED WORK

As mentioned earlier, there is growing interest in the use of reflection in distributedsystems. Pioneering work in this general area was carried out by McAffer [McAffer96], whodeveloped the CodA reflective, distributed object-oriented platform. This platform featuresextensive support for behavioural reflection through the reification of a number of facets ofcommunication (i.e. send, accept, queue, receive, protocol, execution and state). There is alsonow a growing corpus of work in the area of reflective middleware. For example, a series ofexperiments have been carried out at the University of Illinois at Urbana-Champaign. Forexample, they have experimented with the use of reflection to introduce more dynamicreconfigurability into the Tao middleware platform (dynamicTao) [Kon00]. This is achievedthrough the use of configurators that maintain dependencies between components andprovide a set of hooks for the attachment or detachment of components dynamically. Theyare also currently interested in configurability of platforms for mobile devices (the LegORBProject) [Roman01]. In associated work, they have also developed a task control model tosupport QoS management in their platforms [Li99]. In general, the approach at Illinois takes afairly course grained view of reflection, by supporting the customisation of key parts of theplatform.

Researchers at Trinity College Dublin have investigated the use of a reflective language,Iguana, to develop a more open and extensible middleware platform [Dowling00]. Theresultant platform can then be accessed and modified using the reflective facilities offered bythe language. Ongoing experiments are also investigating the use of reflection in thedevelopment of a minimal CORBA implementation [Dowling01]. Like our work, thisapproach is based on the use of reflection together with a component model. OpenCorba,developed by researchers at the Ecole des Mines de Nantes, is a further example of an open,

15

dynamically adaptable ORB that depends on a reflective language (NeoClasstalk)[Ledoux99]. Researchers at APM have developed an experimental middleware platformcalled FlexiNet [Hayton98], which allows the programmer to tailor the underlyingcommunications infrastructure by inserting/ removing layers. Their solution is, however,language-specific, i.e. applications must be written in Java. Other middleware platformsfeaturing aspects of reflection include QuO [Zinky01] and Tao [Wang01].

Our design has been influenced by a number of specific reflective languages and systems.As stated above, the concept of multi-models was derived from AL/1-D. The underlyingmodels of AL/1-D are however quite different; the language supports six models, namelyoperation, resource, statistics, migration, distributed environment and system [Okamura92].From this list, it can be seen that AL/1-D does however support a resources model. Thisresource model supports reification of scheduling and garbage collection of objects (but in arelatively limited way compared to our approach). In addition, our architecture meta-model issimilar to architectural reflection as proposed by Cazzola et al [Cazzola99]. In their approach,architectural reflection is decomposed into topological reflection, which involves themanipulation of structure (in terms of components and connectors), and strategical reflection,which involves the manipulation of behaviour (as a set of rules). In their work, they do notexplicitly address the issue of integrity of architectures, but rather leave this to the designer ofthe behavioural rules. Similarly, they do not consider other forms of reflection in their work.

Our use of component graphs is inspired by researchers at JAIST in Japan [Hokimoto96].In their system, adaptation is handled through the use of control scripts written in TCL.Although related to our proposals, the JAIST work does not provide access to the internaldetails of communication components. Furthermore, the work is not integrated into amiddleware platform. The designers of the VuSystem [Lindblad96] and Mash [McCanne97]advocate similar approaches. The same criticisms however also apply to their designs.Microsoft’s ActiveX software [Microsoft99] also uses component graphs. This software,however, does not address distribution of component graphs. In addition, the graph is notreconfigurable during the presentation of a media stream.

6. CONCLUSIONS

This paper has considered the design and implementation of Open ORB, an experimentalreflective middleware architecture intended to provide more configurability, reconfigurabilityand support for longer-term evolution. The approach is based on a marriage of componenttechnology and reflection. In particular, through reflection, the component-based approachpervades both the application level and indeed the implementation of the platform itself.Crucially, reflection allows this underlying structured to be accessed and indeed altereddynamically. In more detail, the platform has the following key features:

1. The use of an advanced component model with explicit support for multimediaprogramming, e.g. through continuous media interfaces and explicit binding;

2. The adoption of a multi-model approach to provide an important separation ofconcerns for programmers accessing the meta-level of the platform;

3. Support for structural reflection through introspection of component interfaces, andalso more general access to the underlying software architecture of the system (interms of component graphs and architectural constraints);

4. Support for behavioural reflection through the ability to attach interceptors tointerfaces, as well as the more novel provision of a resources meta-model.

Two implementations of the platform have been developed, the first using a prototypinglanguage to encourage experimentation with the overall architecture, and the second in C++

16

(together with a reflective extension to COM) to validate the performance of the approach. Inaddition, a series of applications have been developed focusing mainly on dynamicreconfigurability, but also now considering other capabilities of the platform. Crucially, thiswork has addressed two important concerns about reflective middleware platforms, i.e. thatsuch technologies carry a penalty overhead, and that reflective middleware platforms carryrisks in terms of the integrity of systems. Our experiences to date indicate that both theseconcerns can be overcome.

For the future, the most important work is now to reach international consensus firstly onthe need for reflective middleware technology and secondly on the interfaces to be offered bysuch platforms. This is important to support the emergence of a next generation ofmiddleware platforms that firstly are more configurable and reconfigurable, but which alsocan offer portability and interoperability for applications that choose to exploit such advancedfeatures.

ACKNOWLEDGEMENTS

The research described in this paper is partly funded by France Telecom R&D (CNETGrant 96-1B-239). Particular thanks are due to Jean-Bernard Stefani and his group at FranceTelecom for many useful discussions on reflection and distributed systems. The work is alsopartly funded by the EPSRC together with BT Labs through grant GR/M04242). In particular,we would like to acknowledge the contributions of the following people from BT: SteveRudkin, Alan Smith, Paul Evans, Kashaf Khan and Benjamin Bappu. The work onspecification and formal verification of QoS properties is also funded by EPSRC (ResearchGrant GR/L28890).

Fabio Costa, Hector Duran Limon and Katia Saikoski are funded by CNPq/ UFG (Brazil),UNAM (Mexico) and CAPES/ PUCRS (Brazil) respectively. Rui Moreira is also partiallyfunded by UFP (Universidade Fernando Pessoa).

We would also like to acknowledge the contributions of our partners on the CORBAngproject (next generation CORBA) at UniK, and the Universities of Oslo and Tromsø (all inNorway). Particular thanks to Frank Eliassen, Vera Goebel, Oyvind Hanssen and ThomasPlagemann.

REFERENCES

[Andersen00] Andersen, A., Eliassen, F., Blair, G.S., “A Reflective Component-BasedMiddleware with Quality of Service Management”, Proceedings of PROMS’2000(Protocols for Multimedia Systems), Cracow, Poland, 2000.

[Blair98a] Blair, G.S., Coulson, G., Robin, P., Papathomas, M., “An Architecture for NextGeneration Middleware”, Proc. IFIP International Conference on Distributed SystemsPlatforms and Open Distributed Processing (Middleware’98), Springer, 1998.

[Blair98b] Blair, G.S., Stefani, J.B., “Open Distributed Processing and Multimedia”,Addison-Wesley, 1998.

[Blair00a] Blair, G.S., Andersen, A., Blair, L., Coulson, G., Sánchez, D., “SupportingDynamic QoS Management Functions in a Reflective Middleware Platform”, IEEProceedings Software, Vol. 147, No. 1, pp 13-21, February 2000.

17

[Blair00b] Blair, G.S., Blair, L., Issarny, V., Tuma, P., Zarras, A., “The Role of SoftwareArchitecture in Constraining Adaptation in Component-based Middleware Platforms”,Proceedings of the IFIP/ACM International Conference on Distributed Systems Platformsand Open Distributed Processing (Middleware’2000), IBM Palisades, New York, April2000.

[Blair01] Blair, L., Blair, G.S., “Specifying and Analysing Multimedia Systems”, In FormalMethods for Distributed Processing: An Object Oriented Approach, H. Bowman and J.Derrick (Eds), Cambridge University Press, In Press, 2001.

[Cazzola99] Cazzola, W., Savigni, W., Sosio, A., Tisato, F., “Rule-based StrategicReflection: Observing and Modifying Behaviour at the Architectural Level, Proc. 14th

IEEE International Conference on Automated Software Engineering (ASE’99) CocoaBeach, Florida, USA, October 1999.

[Costa98] Costa, F., Blair, G.S., Coulson, G., “Experiments with Reflective Middleware”,Proceedings of the ECOOP’98 Workshop on Reflective Object-Oriented Programmingand Systems, ECOOP’98 Workshop Reader, Springer-Verlag, 1998.

[Costa00a] Costa, F. Duran, H., Parlavantzas, N., Saikoski, K., Blair, G.S., Coulson, G., “TheRole of Reflective Middleware in Supporting the Engineering of Dynamic Applications”,In Reflection and Software Engineering, Cazzola, W., Stroud, R. and Tisato, F. (Eds),Springer-Verlag, LNCS Vol. 1826, pp 79-98, 2000.

[Costa00b] Costa, F., Blair, G.S., "Integrating Meta-Information Management and Reflectionin Middleware", Proceedings of the International Symposium on Distributed Objects andApplications (DOA'00), IEEE Press, Antwerp, September 2000.

[Coulson98] Coulson, G., "A Distributed Object Platform Infrastructure for MultimediaApplications", Computer Communications, Vol. 21, No. 9, pp 802-818, July 1998.

[Coulson01] Coulson, G., Blair, G.S., Clarke, M.W., Parlavantzas, N., “An EfficientComponent-based Middleware Platform”, In Preparation, 2001.

[Dowling00] Dowling, J., Schäfer, T., Cahill, V., Haraszti, P, Redmond, P., “UsingReflection to Support Dynamic Adaptation of System Software: A Case Study DrivenEvaluation”, In Reflection and Software Engineering, Cazzola, W., Stroud, R. and Tisato,F. (Eds), Springer-Verlag, LNCS Vol. 1826, 2000.

[Dowling01] Dowling, J., Cahill, V., “Building a Dynamically ReconfigurableminimumCORBA Platform with Components, Connectors and Language-Level Support”,Proceedings of the Workshop on Reflective Middleware (RM’2000), IBM Palisades,New York, USA, April 2000.

[Duran-Limon00a] Duran-Limon, H., Blair, G.S., “The Importance of Resource Managementin Engineering Distributed Objects”, Proc. 2nd International Workshop on EngineeringDistributed Objects (EDO’2000), California, USA, November 2000.

[Duran-Limon00b] Duran-Limon, H., Blair, G.S., “Specifying Real-time Behaviour inDistributed Software Architectures”, Proc. 3rd Australasian Workshop on Software andSystem Architectures, Sydney, Australia, November 2000.

[Gallop00] Gallop, J., Cooper, C, Johnson, I., Duce, D., Blair, G.S., Coulson, G., Fitzpatrick,T., “Structuring for Extensibility - Adapting the Past to Fit the Future”, Proceedings ofthe CSCW2000 Workshop on Component-Based Groupware (CBG’2000), Slagter, R.J.,ter Hofte, G.H., and Stiemerling, O. (Eds.), Philadelphia, USA, December 2000.

18

[Hayton98] Hayton, R., Herbert, A., Donaldson, D., “FlexiNet: A Flexible Component-oriented Middleware System”, Proc. 8th ACM SIGOPS European Workshop on Supportfor Composing Distributed Applications, Sintra, Portugal, September 1998.

[Hokimoto96] Hokimoto, A., Nakajima, T., “An Approach for Constructing MobileApplications using Service Proxies”, Proceedings of the 16th International Conference onDistributed Computing Systems (ICDCS’96), IEEE, May 1996.

[Kon00] Kon, F., Roman, M., Liu, P., Mao, J., Yamane, T., Magalhaes, L.C., Campbell,R.H., “Monitoring, Security and Dynamic Configuration with the dynamicTAOReflective ORB”, Proceedings of the IFIP/ACM International Conference on DistributedSystems Platforms and Open Distributed Processing (Middleware’2000), IBM Palisades,New York, April 2000.

[Ledoux99] Ledoux, T., “OpenCorba: A Reflective Open Broker”, Proc. Reflection’99,Saint-Malo, France, Springer-Verlag, LNCS, Vol. 1616, 1999.

[Li99] Li, B, Nahrstedt,K., “Dynamic Reconfiguration for Complex MultimediaApplications,Proceedings of the IEEE International Conference on MultimediaComputing and Systems (IEEE Multimedia Systems '99), Florence, Italy, June 7-11,1999.

[Lindblad96] Lindblad, C.J., Tennenhouse, D.L., “The VuSystem: A Programming Systemfor Computer-Intensive Multimedia”, IEEE Journal of Selected Areas inCommunications, Vol. 14, No. 7, pp 1298-1313, 1996.

[Manna92] Manna, Z., Pnueli, A., “The Temporal Logic of Reactive and ConcurrentSystems”, Springer-Verlag, New York, 1992.

[McAffer96] McAffer, J., “Meta-Level Architecture Support for Distributed Objects”, InProceedings of Reflection 96, G. Kiczales (ed), pp 39-62, San Francisco; Available fromDept of Information Science, Tokyo University, 1996.

[McCanne97] McCanne, S., Brewer, E., Katz, R., Rowe, L., Amir, E., Chawathe, Y.,Coopersmith, A., Mayer-Patel, K., Raman, S., Schuett, A., Simpson, D., Swan, A., Tung,T-K., Wu, D., “Towards a Common Infrastructure for Multimedia-NetworkingMiddleware”, Proc. 7th International Conference on Network and Operating SystemSupport for Digital Audio and Video (Nossdav’97), St Louis, Missouri, USA., May 1997.

[Microsoft99] Microsoft ActiveX Home Page:http://www.microsoft.com/com/tech/activex.asp.

[Okamura92] Okamura, H., Ishikawa, Y., Tokoro, M., “AL-1/D: A Distributed ProgrammingSystem with Multi-Model Reflection Framework”, Proceedings of the Workshop on NewModels for Software Architecture, November 1992.

[Roman01] Roman, M., Kon, F., Campbell, R.H., “Reflective Middleware: From the Desk toyour Hand”, DS Online, This Special Issue, 2001.

[Saikoski00] Saikoski, K., Coulson, G., Blair, G.S., “Configurable and Reconfigurable GroupServices in a Component Based Middleware Environment”, Proceedings of theInternational SRDS Workshop on Dependable System Middleware and GroupCommunications (DSMGC’2000), Nurnberg, Germany, October 2000.

[Szyperski98] Szyperski, C., “Component Software: Beyond Object-Oriented Programming”,Addison-Wesley, 1998.

19

[Wang01]Wang, N., Parameswaran, K., Schmidt, D.C., Kircher, M., “Towards a ReflectiveMiddleware Framework for QoS-Enabled CORBA Component Model Applications”, DSOnline, This Special Issue, 2001.

[Watanabe88] Watanabe, T., Yonezawa, A., “Reflection in an Object-Oriented ConcurrentLanguage”, In Proceedings of OOPSLA’88, Vol. 23 of ACM SIGPLAN Notices, pp 306-315, ACM Press, 1988; Also available as Chapter 3 of “Object-Oriented ConcurrentProgramming”, A. Yonezawa, M. Tokoro (eds), pp 45-70, MIT Press, 1987.

[Wegdam00] Wegdam, M., Plas, D.-J., van Halteren, A., Nieuwenhuis, B., “Using Reflectionin a Management Architecture for CORBA, Proceedings of the 11th IFIP/IEEE Intl.Workshop on Distributed Systems, Operations & Management (DSOM 2000), Austin,Texas, USA, December 2000.

[Zinky01] Zinky, J., Shapiro, R., Loyall, J., Anderson, K., Schantz, R., Pal, P., “The Use ofReflectivity in the QuO 3.0 Framework”, DS Online, This Special Issue, 2001.

20

APPENDIX A: THE DESIGN OF THE 4 META-MODELS

A.1 Structural Reflection

Architectural MOPOperation signature Description

Operations for introspectionObjectGraph get_obj_graph(); Returns the complete representation of the component graph that

describes the structure of the base-level configuration.IDSeq get_internal_components(); Returns a list with the identifiers of the components that

constitute the base-level configuration.BoundComponentSeq get_bound_components(in ID comp_id);

Returns a list with information (component id and interfacenames) of the all components bound to the one identified as theargument.

IDSeq get_internal_bindings(); Returns a list with the ids of all binding objects that are part ofthe base-level composition.

ArchStyle get_arch_style(); Returns the architecture style of a composite component.RuleSeq get_style_rules(); Returns the sequence of rules of the composite architecture.boolean check_rule_consistency(in Rule rule);

Checks if a given rule is conformant with the architecture stylerules in use by an architecture.

SymbioSeq get_symbiotic_constraints(); Gets the sequence of dependency constraints associated with thearchitecture, i.e. constraints between two or more components(such as if one is replaced another must also be replaced).

Operations for reconfigurationvoid local_bind(in ID interf_id_1,in ID interf_id_2);

Establish a local binding between the two identified interfaces.

void break_local_bind(in ID interf_id_1,in ID interf_id_2);

Break the local binding between the two interfaces.

void insert_component(in OpenORB::RepositoryId

new_comp_type,in Name new_comp_name,in InsertLocation location);

Create and insert a new component into the base-levelconfiguration, with the given name and in the specified location(given by zero or more interfaces to which the new componentshould be bound; if zero interfaces are given, the newcomponent is left unbound).

void remove_component(in ID comp_id,in LBindSeq rebind_mapping);

Delete the component from the configuration, re-binding theadjacent interfaces of neighbouring components, if appropriateand according to the given mapping of interfaces to be rebound.

void replace_component(in ID old_comp_id,in Name new_comp_name,in OpenORB::RepositoryId

new_comp_type);

Replace an existing component with a new component of thegiven type (the old component is deleted).

void expose_interf(in Name ext_interf_name,in ID interf_exposer_comp,in Name exposed_interf);

Map the interface of an internal component as a new interface ofthe composite component.

void init_arch_transaction(); Creates the boundary for a new set of modifications that will beintroduced in the configuration graph (starts the transaction).

void commit_arch_transaction(); Completes the transaction.void rollback_arch_transaction(); Rolls back the transaction.void set_arch_style(in ArchStyle style); Sets the architecture style which constraints the configuration.void add_rule(in Rule rule); Inserts a new rule in the style constraints.void remove_rule(in string rule); Removes a style rule from the style constraints.void change_rule(in string rule,in Rule new_rule)

Removes the specified rule and adds the new rule.

21

void set_symbiotic_constraint(in NameSeq comps,in Prop property);

Sets a dependency constraint for a given architecture.

Interface MOP (introspection only)

Operation signature DescriptionIDSeq get_interfaces(); Return the identifiers of all the interfaces supported by a

component.InterfStyle get_interf_style(in ID interf_id);

Return the style of the identified interface (i.e. eitheroperational, stream or signal).

AttrSeq get_attr_list(in ID interf_id);

Return a list with the names and types (typecodes) of allattributes in the identified interface.

NameSeq get_interaction_list(in ID interf_id);

Return a list with the names of all interactions (either operations,flows or signals) in the identified interface.

InteractionDescriptionGet_interaction_description(in ID interf_id,in Name interaction);

Return the full description of the named interaction (operation,flow or signal) of the identified interface.

any get_attribute_value(in ID interf_id,in Name attr_name);

Return the actual value of the named attribute in the currentinstance of the identified interface.

void set_attribute_value(in ID interf_id,in Name attr_name,in any new_attr_value);

Set the value of the named attribute in the current instance of theidentified interface.

void call_operation(in ID interf_id,in Name op_name,in ArgValueSeq args);

Enables a dynamic call to be made to an operation of theidentified interface. (Does not work for stream and signalinterfaces.)

Notes

1. The terms name and id in the above table denote components and interfacesrespectively. Names are non-qualified, meaning that they are only meaningful in thecontext where they are defined (e.g. an interface name in the context of the componentthat owns the interface), whereas ids are globally unique names given to such entities. Inaddition, when creating a new component (or interface) only its name is given; the id isgenerated automatically.

22

A.2. Behavioral Reflection

Interception MOPOperation signature DescriptionVoid add_pre_interceptor(In InterceptorDescr interceptor,In Name interceptor_name);

Add an interceptor to the base-level interface, in order to trapincoming messages and introduce additional behaviour to beexecuted before the interaction is actually processed.

Void add_post_interceptor(In InterceptorDescr interceptor,In Name interceptor_name);

Add an interceptor to the base-level interface, in order to trapincoming messages and introduce additional behaviour to beexecuted after the interaction is actually processed.

Void del_interceptor(In Name interceptor_name);

Remove the named interceptor from the base-level interface.

Resources MOPOperation signature Description

Operations on FactoryAbstractResource NewResource(in Size size,in Policy mgntPolicy,in Param schedParam);

Create an abstract resource of a given size and associates amanagement policy with it; scheduling parameters are passed incase of the creation of processing resources.

Operations on Schedulerint Suspend(in ResourceID abstResource_id);

Suspend an abstract processing resource.

int resume(in ResourceID abstResource_id);

Resume an abstract processing resource.

Operations on Abstract ResourceResources getLLRs(); Get lower level resources.

int setLLRs(in Resources llrs); Set lower level resources.

HigherLevelResources getHLRs(); Get higher level resources.

int setHigherLevelResources(in Resources hlrs);

Set higher level resources.

Manager getManager(); Get the manager of this resource.

int setManager(in Manager newMgr,in Param schedParam);

Set the manager of this resource.

Factory getFactory(); Get the factory of this resource.

int setFactory(in Factory fact); Set the factory of this resource.

23

APPENDIX B: DETAILED COMPONENT ARCHITECTURE OF OPEN ORB

1 ) Mu l t ipo in ter r eceptac le o f ty peI A S C P o l i c y . C u r r e n t l y t h r e eimplementations (ASCEDF, ASCDEF,ASCNATIVE).

2 ) Mu l t ipo in ter r eceptac le o f ty peI T P P r o t o c o l . C u r r e n t l y f o u rimp lemen tat ions (TPUDP, TPTCP,TPIPC, TPMIP).

3 ) Mu l t ipo in ter r eceptac le o f ty peI A S P P r o t o c o l . C u r r e n t l y f i v eimplementations (ASPLocal, ASPFrag,ASPShmem, ASPMin, ASPGIOP).

4 ) Mu l t ipo in ter r eceptac le o f ty peIBufPolicy. Currently two implementations(BufBuddy and BufMalloc)

5 ) Mu l t ipo in ter r eceptac le o f ty peI B i n d T e m p l a t e . C u r r e n t l y o n eimplementation (BindGOPI)

5

OSNet

IOSNetOSVP

IOSVP

OSTime

IOSTime

OS

IOS

IOSMem

Chan

IChan

Buf

IBuf

TPThreadio

ITPThreadio

TP

ASP

IASP

ASPProfile

IASPProfile

Brec

IBrec

OSIPC

IOSIPC

ITP

IRef

IIRef

IIOP

IIIOP

NSCust

INSCust

Bind

IBind

IMetaArchitectureIMetaInterception

IReceptaclesILifeCycle

IUnknown

Thread

IThread

1

3

OSMem

IMetaInterface

2

4