Session Chair

Peter Linington is Director/Professer of Computer Communication in the Computing Science department of the University of Kent at Canterbury, UK. He is a member of both their Information Systems and Networks and Distributed Systems research groups.

S. Gibson, S. Gorain, D. Povey and P. Clutterbuck
Queensland University of Technology, Australia

Presented by Simon Gibson

This presentation was to focus on work being done for a project called SecArch and a middleware prototype named Hector. Hector is written in Python and based on the RM-ODP framework, supporting distribution, interworking and portability. Object bindings are used to specify a set of roles and communication patterns. There are multi-party bindings in the system and complex interactions are possible. While the platform is coded in Python, which allows rapid prototyping among other things, the security API is supplied by the C based Generic Security Services API, or GSSAPI for brevity. These two elements are interfaced by a SWIG - Simplified Wrapper Interface Generator.

Simon commented that retro-fitting security is hard: it should be done when developing platforms, not afterwards. He noted that while several mentions of security had been made during the conference, no-one seemed to be doing much about them. Future work on the Hector system will see development moving towards CORBA with the goal of building a secure authentication environment.

One brief question from the floor asked why Hector used a separate secure endpoint class rather than replacing the current endpoint class. Simon replied that there was no particular reason, it was merely there for the purpose of a proof-of-concept exercise.

S. Crawley and K. Duddy
University of Queensland, Australia / Defence Science and Technology Organisation, Australia

Presented by Keith Duddy

This talk was designed to highlight CORBAs type safety mechanisms and their shortcomings. Each object supports one IDL interface, consisting of signatures of operations (methods) and which can subtype multiple interfaces. Each interface has a repository identifier which is stored in an Interface Repository, or IR. There is a problem with these repository identifiers since it is possible for two identical interface types to have different repository identifiers and, additionally, two identical repository identifiers can indicate different types.

CORBA has a problem with the assumptions is makes about interface repositories and the manner in which it handles typecodes. Typecodes can contain enough information to rebuild the IDL, but the specification allows the names of type members to be discarded. The CORBA specification is also flawed since the definition of equivalence is unimplementable.

Keith proposed unique repository identifiers (URIDs) as a solution to some of the aforementioned problems. Such would be globally and temporally unique, contain enough location data to find the interface reference that generated them. Many URIDs could identify one type, but each URID in itself would identify only a single type. The talk was concluded by saying that the current interface repository scheme needed to be changed and that new technology for federating interface references was needed.

F. Eliassen and S. Mehus
University of Tromso, Norway

Presented by Sindre Mehus

The type checking of interfaces is needed for safe and meaningful bindings. Stream interfaces which describe continuous, non-operational flows and which have timing constraints are useful and have been adopted by ODP, TINA-C and the OMG. There are several issues which require attention: compatibility and subtyping rules; a language for defining stream interfaces; system support for transparently binding stream endpoints; and the relevance of stream typing in multimedia databases. An example about a medical audio-visual conference was cited.

Sindre proposed a flow type model based on streams, flows, elements, attributes and sequencing expressions. A flow type specification is interpreted as a set of potential flow qualities and flow structures that can potentially be produced by a source, or be accepted by a sink. The compatibility of flows, and thus the ability to create bindings, is checked using a flow compatibility relationship. This can be formally defined based on set intersection. A Flow Interface Definition Language (FIDL), which resembles CORBA and ANSAware IDLs, is used to specify the characteristics of stream interfaces. A type checker determines whether the source and sink of the flow are conformant and can support the binding.

A few questions were raised. Firstly, is the synchronisation between streams part of the type checking system. If not, should it be for the reasons such as packet dropping? Sindre answered no, because it's not part of the interface. The next question asked what happened if the intersection between the flow specifications was empty? The reply was that communication was not possible, though a possible extension to the architecture could be the use of filters to transform flows until a satisfactory match could be achieved. The third and final question, which came from Joseph Sventek, asked whether elements such as PDF files, audio and video were really being put in the same flow or whether they were actually in multiple flows. Sindre admitted that his example to that end was perhaps chosen unwisely and that the intention was not to incorporate discrete types in streams.

Panel

Chair: Peter Linington
SG: Simon Gibson
KD: Keith Duddy
SM: Sindre Mehus

Kerry Raymond: Is the constraint you showed the maximal or minimal set? How does it fit with the intersection?
SM: It depends on the compatibility policy.

Question: You're assuming interface references are there and make things work. What about firewalls and, say, a server which is behind the firewall and acting with a proxy while the interface repository is not?
KD: It depends on the context of what you're doing. Object narrowing is a way of solving this. Ideally, the firewall should let read operations inspect the interface repository.

Question: What do you do if the original server isn't ready? Also, why do you not use globally unique identifers like Microsoft do?
KD: That's what we are doing. However, Microsoft can use a global registry for types which you want to avoid in a hetergeneous system. CORBA needs to be flexible to work in an internet context.

Joseph Sventek: In CORBA interface repositories are broken. Why not just junk them and do it right?
KD: We'd love to! There is a definition using MOF out there which would generate an interface reference for you. You need to always narrow object references. A lot of people here are talking about the deficiencies of CORBA. Where are you at OMG meetings? Where are your answers to RFP's? With your help we could change CORBA for the better.

Question: I went to an OMG meeting and made a point and it was noted! Should servers be able to directly tell you about their interface types?
KD: Definitely. But sending on the wire typecodes is controversial as people are concerned about bandwith. But we need structure member definitions in IDL.

Joseph Sventek: Speaking historically, I didn't want interface repositories and within the OMG I argued against them. But the other side won!
KD: But in OMG we always get both sides anyway! Why didn't we there!?

Comment: People are not just worried about bandwidth, but also about interoperability! You need structured typing.
KD: I absolutely agree with you. We need to do typecode caching too.