Session Chair

Robert Cole is a manager working at the European research laboratories of Hewlett-Packard in Bristol, UK. Over the last few years he has been leading a team investigating test and measurement systems for networking technologies, especially ATM, and more recently for the Internet. Recent activities have included directory enabled networks and active networks. In the past Robert has researched and worked on distributed systems and networking. He was associated with the ANSA and ODP work for some time and before that an architect on the development of the Internet in the early 80s.

A. Geppert and D. Tombros
University of Zurich, Switzerland

Presented by Dimitrios Tombros

EVE is event engine of DBTG. Work flow management systems are high level middleware, distributed corporate environments and distinguish the build time environment from the run time environment. The build time environment includes a workflow specification language. Assume this language is available and it maps to workflow system architecture. Assume components can be plugged in. EVE provides event engine to coordiante events. These events relate to time in the real world and exceptions caused by incomplete specifications. Formal execution semantics workflow system execution. Other advantages of APEX were given.

A workflow modelling example was described using a diagram. Health insurance claim processing was examined. Distribution is implicit in the execution model. The model elements were described. The model is comprised of EOBs and PE's services and events. Active Process execution was then described. Each EOB is a component that represents a real world processing entity to the system.

Event based workflow system architecture. The event occurrence broker was described. Primitive event types can either be synchronous or asynchronous; request, confirm , reply, exeception types are allowed. These are site specific. Each site has a local clock these are synchronised to provide approximate global time. Composite events are allowed for system concurrency, xor seq are examples of composition operators.

EVE is a distributed multi-server system and provides an active communication environment. Reactive event-based workflow execution APEX is the EVE execution platform. It provides event based disributed workflow execution with workflow a system repository. SHORE persistent object manager is used with schema. Build time and run time information is provided. ECA rules area provided in EVE. Event, condition and action semantics were described. Prepare rule execution was described. An EVE system architecture was then illustrated in a diagram. Transport is via TCP/IP and EVE sits between the clients and the servers. Workflow execution was then decribed. Here each event is stored in the event history. Server synchronisation was then illustrated in a diagram. Outstanding open isuses that remain include how to optimise schema distribution across the servers

Simon McBride asked that several repositories are described - are these the same? Dimitrious replied that the run time repositories are distinct entities. Andrew Herbert questioned whether long latency between event firing caused problems? In reply, Dimitrios said that the system configuration defines the maximum latency so one is sure that events occur at right time.

M. Spiteri and J. Bates
University of Cambridge, UK

Presented by John Bates

What is this? A general purpose to store events is a good thing. Location and actions in real world, for example "presence in building and phone off hook" actions. A diagram showing application construction was shown. Can register interest in parameterised events such as "Person: John Bates, Location: Low Wood Hotel, time: *".

Storage of events is a good thing - why? Events allow distributed debugging. Logging for charging and fraud detection. Visualisation can be done by replaying past events: it can provide a memory aid or automated diary. How to do it? The approach is to store events in the same service, not elsewhere. Can't use database; too slow, Can't use file service; no structured data. Storage needs to be session oriented and support based: multiple concurrent real time events. Retrieval via ODMG compatible data model familiar to DB users with addition of special temporal operators to handle temporal event mining. A complex system example was shown in a diagram supporting automatic minuting, mobility and disconnected operation.

Classification of events allows retrieval on a class of intervals. This shows memory prothesis, which allows replay if someone gets disconnected and also allows visualisation of mobility. Example of federated system is the injection of real world events into a VRML world. Such a system would allow simulation of real world events combined with synthetic events, such as evacuation exercise with the addition of simulated explosions etc.

The event store architecture was then described with the aid of a diagram. Some query examples were then shown with the semantics of the query interface. This includes content, intervals, and attributes. Conclusions were then shown.

Nigel Davies asked if you can replay events because events are time stamped, does this allow resynchronisation? John answered that ordering is achieved by buffering, but this is orthoganal to event storage. Another member of the floor asked whether events from differrent sessions can be combined? The reply was in principle an interval is a sub session but it is not really done like that yet. Adrian Friday queried whether you have to explicitly say which repositories need to be consulted? John said everything was part of the same repository; different files but the same system. A fourth question asked whether distributed repositories cooperated? The answer was no, each member has its own repository. Another floor member asked if filtering by condition true, what stops user overwriting logs? John replied this can be done. A final question asked whether the language supportted types? The response was that there is a disparity between state based and events, this is still being thought about.

X. Logean, F. Dietrich, H. Karamyan and S. Koppenhoefer
Ecole Polytechnique Federale de Lausanne, Switzerland

Presented by Xavier Logean

Problem being addresed is that of gaining confidence in the implementation of a telecommunications service. To check a given implementation is of industrial strength it uses middleware. Diagram showing how middleware achieves this. This is a methodology adopted by TINA, BELL, SwissCom and Alacatel and others. A framework for application development was shown. To date it has not been necessary to change the ORB. A diagram showing more about the detail of the observers role in the system was then shown. EBBA event based behavioural abstraction was then described in terms of the tuples used to define the generic events.

Implemented using the notion of interceptors standardised by OMG in CORBA 2.2 rev3.0. CORBA Orbix filters were then illustrated. Relations showing the ordering of events were then shown. A monitoring scenario was then shown in another diagram. The instrumentation added to the code introduces a delay so measurements on this have been made. The worst case intrusiveness has been measured. Properties have been added with an interface to allow them to be described in temporal logic. Further testing has been crried out in terms of a scenario shown in a further diagram. A prototype has been implemented in ORBIX. Screen dump of the prototype observer was shown. Shows interaction between different objects within the system. The system accomplishes monitoring of a CORBA middleware application with transparent monitoring. Properties are expressed based on requirements. Weaknesses presently include the centralisation of the observer. Scalabilty and the distribution of the observation mechanism are being worked on.

Keith Duddy queried that given many objects and many servers how are human readable notifications generated? Xavier replied that server assigns class names to objects.

Panel

Chair: Robert Cole
DT: Dimitiros Tombros
JB: John Bates
XL: Xavier Logean

Question: Problems of scalability?
DT: I gave the impression the system only runs on one local area network but it can be distributed. The events we handle are quite sparse so this is not a major problem.
JB: This is not about scaling events, systems are always about scalability, so can we plug event based systems together, but no gobal event store has been developed.

Question: What is it in your system that indicates that scalability is taken seriously? Event based system can be plugged in anywhere in a non event based system? There is no centralised service so it is scalable?
JB: Yes no centralised point in event-based systems.

Question: Inter-domain issues such as event taxonomy differences introduces consistency problems? Different views?
JB: Yes this happens. If you want global ordering then you need centralised resources. These can provide global timestamping.
DT: Speed was taken to be most important factor.

Comment: Could go further to say that a database system is not needed because append based system is adopted.

Question: Some events are state based so sparse, but what about heartbeat events, have you thought of coalescing these into representations of change of state?
DT: We are only interested in state change in workflow applications.
JB: Point of registration for filtering may allow state change selection, probably wouldn't log heartbeats as only state changes are really of interest.
XL: We are only really interested in state changes.

Question: How is naming of events handled?
XL: We differentiate events by names as only 20 event types allowed.

Question: What do you do about instances?
XL: The instance is what occurs.
JB: A class hierarchy for events is provided so when an event instance occurs this allows it to be retrieved.
DT: Primitve event types are site specific, this solves problem of unique identfication.

Question: Granularity of events can be a problem for storage so may miss key events particularly when logging log on events. Can you get to a granularity where this can be overcome?
JB: No real large scale storage of logging events so analysis may be a problem but will need specialised architecture.
XL: Main objective is testing so not too interested in recording of events. Not really working on it.

Morris Sloman: If testing complex system it's difficult for observer if there are many events.
Answer missed.

Closing Address

Gordon Blair, General Chair, made a short speech thanking everyone for their efforts in organising and running Middleware'98, in particular the Lancaster team wearing the Middleware'98 polo shirts. He also thanked delegates for attending. He then said he was about to sound like football manager after a team game because he couldn't mention individuals... but hadn't Barbara (Hickson) and Vicky (Ewan) done a good job! A presentation of flowers was then made to them.

Kerry Raymond, Programme Co-chair, took the floor on behalf of the steering committee. She went on to thank the reviewers, authors and the other Programme Co-chair, Nigel Davies, as above all Gordon Blair as General Chair. She said the committee had been impressed by the organisation of the conference and that there was no doubt in their minds that the revised conference title and format should continue. She added that IBM had offered to sponsor the next Middleware conference. Also, a South American venue was being investigated for the subsequent conference to that.