Session Chair

Nigel Davies is a member of the Distributed Multimedia Research Group at Lancaster and his early research (including his Ph.D.) was in the area of distributed systems support for multimedia applications. His current research is focused on the area of mobile computing and the development of distributed systems support for adaptive applications. Nigel is the Programme Co-chair for the Middleware '98 conference.

J. Sventek
Hewlett Packard Labs

In this keynote address, Joseph indicated that he had spent the last 12 years on ANSA-related activities implementing Middleware. In the talk he was going to describe some of his experiences. One size never fits all and probably never fits anything very well. A huge implementation will not tend to work very well. For complex solutions we must keep an eye on what the developer is trying to achieve. A true solution will be very complex.

Think about the interaction between components: lots of quality and functional dimensions may be involved. A situation analysis shows that some things may be more important than others: these sould be prioritised. Some may be "don't care", some fixed early, some at compile time, and others configured at run time. In real systems, the earlier some things are fixed, the easier the system will be to deploy and build. Some things may never be fixed. Another key requirement is that customers do not want to be locked into a middleware solution - tomorrow they may need another choice.

The abstraction layer for a publish and subscribe implementation was then described. This included named channels, message definiton for each channel, publisher registration and withdrawel. A discussion of which publish/subscription implementation to use took place, including issues such as heartbeats and the delivery of call detail records (CDRs).

In a stock quote delivery application, a particular component may use several publish/subscribe channels with different reliability and ordering requirements. Compile time binding has advantages: minimisation of memory occupancy of the middleware support layer; elimination of run time configuration means "more likely to get it right". Systems may contain 10E+5 to 10E+6 active elements. Compile time bindings also has drawbacks, though: inflexible choice; change requires relink and reload dynamically. Dynamic loading can help alleviate the memory occupancy problem, but there is a need to handle more difficult run-time configuration issues. The longer you delay configuration choices, the less likely you are to get the configuration right.

Large application developers have been using mapping layers to support multiple OS's, ie: ISIS and it's decendents, ANSAWARE and ORBlite. A diagram showing the structure of ANSAWARE was shown. ANSAWARE provides several abstraction layers, including: a message passing service (unreliable datagram); single RPC protocol (REX with common marshalling); and threads (non preemptive threading package with mutual exclusion primitives). ORBlite also supports several abstraction layers: transport, threads and language mapping.

ORBlite simultaneously supports multiple language mappings and RPC protocols which are determined at link time. Two hereises were the introduced. The "use of abstraction layers causes performance degradation" is mitigated by the use of object oriented languages (and their polymorphism) for the implementation of the abstraction layer. Late binding of choices along a quality/functional dimensional is always prefered.

Conclusions that can be drawn are as follows. A middleware architect should solicit and understand what needs the customer has regarding customisation. A customisable solution should support binding choices as early in system implementation as possible. The ORB specification involved five mutually distrustful companies and represents a conservative view of the state of the art in 1991. The IDL is the most lasting part of the CORBA specification and can be used to define the interfaces to components without requiring that a CORBA substrate be used to animate your system.

Three brief questions were fielded by the floor. What did he think of objects by value? Joseph's reply was that objects by value make systems more difficult to implement in the same address space. Another queried why he was a fan of early binding? The answer: multicast implementation is more efficient if the binding decisions are made early. In a maintainable system the complexity introduced by late binding makes maintainance difficult. The third question asked what flexibility should be allowed? In reply, Joseph said let the user write IDL specs. If other flexibility is needed, it should be implemented in the compiler to minimise the likelihood of errors.

D. Donaldson, M. Faupel, R. Hayton, A. Herbert, N. Howarth, A. Kramer, I. MacMillan, D. Otway and S. Waterhouse
APM Limited, UK

Presented by Matthew Faupel

The features of DIMMA were described and a diagram of the resource control framework was shown. This can be adapted to IPV6 through hooks in the implementation. A diagram showing the ODP concept of channel and their multiplexing in the context of DIMMA was shown. An additional abstraction layer was introduced with objects accessing a channel via a session. A diagram showing a vanilla ORB capsule was shown. This was followed by a diagram showing how the channel was resourced. Binding choices may be made either generically or on a protocol specific basis. Components were then discussed. All generic resources are allocated through alloctors and there is a generic threading framework. Policies are adopted. A diagram showing an example of configuration operation was shown, for both default and high performance QoS. This required adding the flow keyword to the IDL. Endpoint implementation was also described. In conclusion: the performance achieved was better than expected from an experimental platform. DIMMA is an ORB that supports real-time multimedia in a clean layered way.

A member of the floor asked what platform this was written on? The answer was written to POSIX interface but shipped on Solaris 2.5.

S. Lo and S. Pope
Olivetti & Oracle Research Laboratory, UK

Presented by Sai-Lai Lo

The presenter described OmniORB which is available available free of charge. OmniORB2 is CORBA2.0 compliant GIO 1.0 IIOP, has COS naming service, is fully multithreaded, implements type code and Any, DynAny (CORBA2.2) Single Source Tree. The ORB is a robust implementation, consists of 100,000 lines of code and runs on 12 platforms including Windows NT and 95 and arious flavours of Unix. A graph showing ORB bulk data throughput compared with TCP over ATM was shown and a diagram of the internal architecture of the ORB was presented.

A single protocol strategy was adopted, namely GIOP, as the native protocol for communications between OmniORB clients and servers. This avoids performance hits from multiplexing and reduces the number of layers. Unnecessary multiplexing is eliminated. Multithreaded runtime is designed to maximise concurrency and minimise unnecessary thread overhead. No thread switching is involved along the call chain as shown by a diagram. This involved "one call per connection" and "one thread per call". Alternative approaches involve serialisation bottlenecks in multiprocessor machines. A diagram showing dynamic call connection management was shown. The approach adopted avoids dynamic deadlock problems. Connections are closed after an idle period. Diagrams showing transport buffer management, and marshalling optimisations were shown. Large buffer allocation for marshalling is avoided in OmniORB, requiring 2 passes when GIOP 1 is used. GIOP 2 removes this overhead. Shared memory transport was also described.

Fast interconnect cards implementing FAT were shown. This wil permit fast connect between members of a cluster with low latency. Some issues of AAL5 transport design were described. A technical report on this transport mechanism is available from the ORL website. Future work was described as being on a scalable distributed computing platform and commercial applications in high end servers running CORBA applications.

Panel

Chair: Nigel Davies
JS: Joseph Sventek
MF: Matthew Faupel
SL: Sai-Lai Lo

David Myers: What applications will use OmniORB. If it's so good why not sell it commercially?
SLIt has applications bridging OmniORB and Oracle 7. The Active Badge system implemented with ANSAWARE but this is not maintained. These systems were ported easily to OmniORB. Commercial exploitation is being considered.

Question: Need more than just invocations for streams, what is the best way of proving flexibility programing interaction with IDL?
Answer missed

Question: Missed
Answer: Run time or link time may decide one is better than the other since IDL does not capture the notion of flows so you may need explcit binding. Do you use explicit QOS? Then it is most likely to be application dependent.

Question: Interworking betweeen ORBs is not working. Is anybody doing anything about it?
Use ORBS that do interwork: there are some notable offenders, but some do interwork.
An interoperability testing centre should be aodpted by users to demonstrate compliance.
Xopen is charged with developing a high cost a test suite; this is different from a testing centre.

Neil Mason: ITU have standard MMI for exchanges. Marconi have the only compliant implementation. So what is a standard worth if it's not adopted?
Commercial pressure will drive it.
A further point is how do you know what is compliant: this requires testing.

Question: OmniORB is multithreaded so does IOP specify concurrent execution?
If multiple invocations are going through a single connection then if in a single processing environment they can't guarantee concurrency. This only affects nested call backs.
There is a trade off of complexity in protocols with complexity elsewhere in the system.

Chair: Which is the fastest ORB?
Of those available now, OmniORB is the most likely candidate.