Session Chair

Doug Terry works at XEROX's Palo Alto Research Center (PARC) in the USA.

M. Radestock and S. Eisenbach
Imperial College, UK

Presented by Mathias Radestock

This presentation began with the following question: In implementing distributed systems, how can the applications programmer be supported? In distributed systems, components are distributed across the network. The system will be comprised of a communication part, computational part, configuration part and a coordination part. Traditionally these issues are muddled in the component development. Now configuration is separated from computation. This is helped by introducing binding languages. However coordination has not been adequately seperated out.

This research is investigating how configuration and coordination can be supported for the applications programmer. Middleware systems impose extra tasks on the implementer in terms of adaptation and openess requirements. Real systems require changes to be made dynamically. Middleware systems operate in heterogeneous environments. Also need to reuse components. Reuse is hindered by muddling the issues referred to above and should be at the source and object code level. Would also like to reuse executing code.

Support is needed for configuration and coordination as integral parts of an application. Mechanisms for abstraction and reuse of configuration and coordination logic. Can't make assumptions about these architectures. Traps a new model for coordination assumes that communication is the key for component based systems. This was illustrated in a diagram. In this model translation rules are installed. Configuration performs these transforms whereas coordination delays messages. Messages are intercepted by traps which can be installed and removed dynamically. Some pseudo code illustrating the mechanism was displayed: trap and untrap statements are used. Traps support a rich language for specification of message patterns based on an interoperable representation. An example showing how coordination can be achieved using traps was discussed using a diagram. Here traps are installed between a device and handler. Coordination using traps can also be achieved. A diagram and pesudo code illustrated the discussion. Coordination occurs transparently and components don't need to know about one another, nor do they need to know about the coordinators. Also, coordinators do not need to know about one another. A diagram showing how this might be implemented was shown.

There is a performance overhead for components that require coordination and configuration. Other components do not suffer this overhead. A pattern matching approach ensures messages are not intercepted unesessarily. A summary of the talk was then given.

Ian Utting commented that it appeared that no state shared between traps. How is this achieved when needed? Mathias replied that an algorithm is used which allows shared state to be achieved through the use of a shared component.

R. Balter, L. Bellissard, F. Boyer, M. Riveill and J.Y. Vion-Dury
INRIA, France

Presented by Daniel Hagimont

The objectives of OLAN were to provide an environment for construction of complex distributed applications. Architecture should support software components and their dependencies. Communication patterns involve management policies for components. Integration of legacy software is also an issue. Configuration process designer specifies architecture where ADL or CASE tools might be used. Computer Aided Deploymnet of the architecture through use of ADL scripts contains what is needed to launch the application. A diagram giving an overview of the OLAN environment was shown.

The remainder of the talk discussed architecture definition in the OCL language. This is defined at the level of the interface and the operations required. Implementation is via instances of primitive software components which may be in DCOM, Darwin or OCL. Components require interconnection with functional dependencies and communication protocols. This may by OCL Polylith, Conic or Darwin Wright or Unicom. Other interesting features include dynamic evolution of components: collection dynamic selection of components via associative naming. A further series of diagrams showing an example of an application fragment was shown.

Software integration to date allows wrapping of legacy sources through the use of a "computer assisted" methodology. A diagram showing the internal structure of a component was shown. This showed a comparison betwen the OLAN environment and a traditional Java environment. Configuration Services in OLAN support object deployment and execution contexts. A diagram showing an example from a mailer application was shown. Evaluation from the design point of view suggested OLAN was a nice tool to use. However some problems like the sharing of components was not solved. Management of the system was largely automated. Performence was poor through the use of Python. Furher perspectives for future developments were given.

A. Zarras and V. Issarny
IRISA, France

Presented by Apostolos Zarras

Why do we use transactions? To guarantee a system state. This is an abstract idea. Models can be built on top of existing systems infrastructure. The objective is to provide a framework that supports a transactional framework. An ADL was used to specify the properties, interfaces and integration rules together taken with selection procedures and composition procedures. A detailed discussion was then given of each of the elements of the architecture. Non functional properties were specified using temporal logic in the ACID language. Atomicity, consistency, isolation and durability were specified using predicates. Examples of the use of ACID predicates were then given. How far can this specification be taken? This is still a work in progress. A tool to specify refinement strucures was then defined. A composition procedure based on the notion of integration rules was then described, followed by an example based on CORBA. A C++ CORBA mapping is being implemented

Keith Duddy asked whether tools that generate C++ code exist. The reply was that we still need tools that support temporal logic. Matthew Faupel asked whether the set of transactional properties needed is so big that it needs this sort of complexity? Apostolos answered that there is evidence the proliferation of models suggests the need for temporal logic. A further question asked whether automation of the roll back mechanism been achieved so far? The answer was that is was desirable but, no, it hadn't yet been implemented.

Panel

Chair: Doug Terry
MR: Mathias Radestock
DH: Daniel Hagimont
AZ: Apostolos Zarras

Comment: I'm concerned about security in component resue.
AZ: At present three Ph.D. students are working on this. Some proposals on security have been made, based on combining existing security models.
MR: It's not really been a concern so far. The issue for component based programming research has been on the level of interconnection of components not meant to work together. More work is needed on interworking. Security is potentially really dangerous in this model but traps offer a potential security model.

David Myers: What problems do these solutions address in terms of component size number, etc?
MR: Addressing large numbers of components and reuse of components .
DH: In OLAN the emphasis is on providing a global view of applications for programming "in the large with large components" and there are communication and connection issues to be solved.
AZ: Agree with both the other speakers. The issue is to provide tools for the developer to ease his burden.

Kerry Raymond: How are objects and components distinguished and mapped?
AZ: This is achieved if CORBA is underlying mapping framework.
DH: Making the distinction is a programming language issue.
MR: Don't want to get into debate about what components are. It is something that does something.

Dean Thompson: How is correctness verified?
DE: Some verification has been done in the laboratory but I'm not able to speak about this.
AZ: At present we don't verify results.

Gordon Blair: Any comments on CORBA Beans or JAVA Beans?
DH: Main communication protocol is based on events. This differs from OLAN in that OLAN seperates events from links. This is deficient. I feel that only one communication protocol is being adopted.

Chair: How many people have used beans in room?
Answer: 4 people have used Beans in their programming
MMR: I donit think Java Beans are going to address interesting problems.
DH: I would like to use components but need to apply different management models. Enterprise Beans may solve the management issues.

Keith Duddy: In Seattle, CORBA component submissions are being considered. Results will be public at the end of the year. Extensions to IDL will be introduced.