Session Chair

Kerry Raymond is the Architecture Unit leader at the Distributed Systems Technology Centre (DSTC), Australia. She also heads the Architecture Model project which is responsible for establishing an overall framework and methodology for distributed systems. This work complements her involvement in the standardisation of the Reference Model for Open Distributed Processing. Kerry is also involved in the critical evaluation of distributed systems environments, e.g. OSF's Distributed Computing Environment (DCE).

B. Dumant, F. Horn, F. Tran and J. Stefani
France Telecom - CNET, France

Presented by Bruno Dumant

Jonathan is a proof-of-concept implementation for the collaborative ReTINA project which has been focussing on a telecommunications distributed processing environment (DPE). To adapt a DPE to support multimedia services it must be configurable to different sizes and types, support any binding/interaction model, multiple protocols, resource and scheduling control and openness through QoS and admission control. CORBA is too monolithic, client-server oriented and offers no user level resource control. The ReTINA project, on the other hand, defines an open, flexible architecture on top of which personalities, such as CORBA and RMI, can be built.

Bruno went on to describe the structure of Jonathan and it's support for a CORBA personality. Binding factories are used to build binding objects which are used to encapsulate message sending mechanisms. Interface references are used to designate interfaces, designation and access being kept independent, and define the type of the interface and a set of context-dependent identifiers unambiguously designating the target interface. The presentation closed with a mention of the work in progress on the project. This includes the introduction of resource management patterns, an RMI personality, QoS management and admission control, and a touch of reflection.

One small point of clarification was raised from the floor: how were bindings described and could a binding description language be defined to do this? Bruno answered that in Jonathan bindings were described by the binding factories but that, yes, it was possible to envisage some form of binding language.

G. S. Blair, G. Coulson, P. Robin and M. Papathomas
Lancaster University, UK

Presented by Gordon Blair

In opening his presentation, Gordon expressed concern that middleware products were losing sight of architecture, something which was considered in RM-ODP but had been largely ignored since. Commenting that his work was driven by the challenges of multimedia, mobility, real-time and embedded systems, Gordon proposed that reflection might provide the solution.

Reflection offers a principled approach to inspective and adaptation and reflective middleware has the potential to support mobility and multimedia. The architecture in use in the Adapt project features an RM-ODP object model, per object (interface) meta-spaces, a procedural rather than declarative approach to reflection, orthogonal meta-space models and groups. Middleware is complex and meta-space models are needed to simplify matters by separating concerns. Every architecture has 3 meta-models (encapsulation, composition and environment) although it appears a fourth may be also be emerging. Gordon added that explicit bindings are necessary for QoS management before closing by stating his goal as the realisation of a CORBA MOP (meta-object protocol).

John Ridgeway questioned what the emerging 4th meta space was. Gordon replied that of resources and resource management, eg: threads and memory.

R. Vanegas, J. A. Zinky, J. P. Loyall, R. E. Schantz and D. E. Bakken
BBN Technologies, USA

Presented by Rodrigo Vanegas

Wide area applications are still hard to build and maintain. Quality Objects (QuO) middleware organizes elements required for adaptable behaviour in a reusuable manner. QuO client connect to CORBA objects using functional and quality interfaces. Properties of the distributed execution environment are controlled and monitored by the QuO and application developers need only be concerned with the logical method call.

Components of the QuO system are contracts, delegates, and system conditions and the runtime environment is distributed and heterogeneous. Contracts use RSVP and affect the behaviour of delegates; external events can trigger contract re-evaluation and run transitions asynchronous to an invocation. The QuO framework is described by a Quality Description Language or QDL and the development process involves both application designers and QoS designers using advanced middleware. Rodrigo concluded by saying that QuO offers a framework for middleware with QoS support.

Morris Sloman asked whether it was possible to get inconsistencies when multiple contracts were set up for each delegate. Rodrigo said that there was only one contract per delegate and that to achieve multiple contracts multiple delegates could be stacked on top of each other. Another member of the floor commented that many objects can't be composed to have end-to-end behaviour and asked whether it was somehow possible to compose end-to-end contracts. The reply from Rodrigo was that he had looked at that and, yes, everything could be integrated into a single contract if it made sense. Otherwise contracts could be stacked at which point adaptation was piecemeal.

Panel

Chair: Kerry Raymond
BD: Bruno Dumant
GB: Gordon Blair
RV: Rodrigo Vanegas

Rodger Lea: We've worked with reflection for a number of years within operating systems and threw lots of it away due to performance penalties. What do you think of the impact reflection has on performance?
GB: Good question. We'll probably experience the same thing by starting with a rich set, then collapsing it to the necessary things. Other research groups are currently investigating efficient reflection.

Question: The language you describe, Rodrigo, is too complicated. Why don't you just describe everything as QoS attributes and values, then let the system map this for you?
RV: What part of the system would do this? The ORB wouldn't and you wouldn't want to do it in the application. Implementing it at other levels could introduce race condition problems.

Question: What about feasiblity, scheduling and available resources?
RV: That's not what we're really concerned with. We want to facilitate, but not enforce, QoS contracts and correctness.

Keith Duddy: Bruno, how do multiple personalities interwork, eg: DCOM, CORBA and RMI, and what do they support? Do you have to do interface translations?
BD: You have to develop interfaces which are understood by all your personalities. There is no real Java mechanism for this, but we intend to share references between personalities in the future.

Chair: What would you like to see happening in CORBA in the future?
RV: Pass!
GB: Explicit bindings. Well defined, standardised meta-interface to enable redefinition of the internals.
BD: Separating out the desired elements and the bare minimum in the specification. The architecture should be much more moderate than it is now.

Joseph Sventek: ORB implementation is slowed down by the dynamic interfaces, particularly for C++ implementations as C++ doesn't lend itself to interpretation. Do you actually need these facilities, or could they be thrown away?
GB: Yes and no. I think you need them, but we need to find a good way of building them to make it worthwhile.
BD: Dynamic requests may be useful for designers. I agree with Gordon on the engineering aspect.

Comment: If you take the component view we already have the answer - the stub compiler.

Question: Do you think that ORB vendors will make things reflective or not? Will they produce more open implementations?
GB: They should but they won't without pressure from the application developer community. That's starting to happen already - radical proposals are currently coming from application developers, not ORB engineers.