# Presentation: 017596

## Understanding(?)Object Networks

- P. Calafiura
- L.Vacavant(next talk)

- Component model discussions at LBL

- 27 May 1999

## Introduction to Object Networks(highlights from R.D. Schaffer talk)

- Overview:
- Architectural design: the *how* and the *what*
- Canonical example: EM calorimeter cluster finding
- Some Background to the Object Network design
- Object Networks: an Overview
- Some basic assumptions of the design
- Architecture overview
- The Component Model
- RD talk URL http://arc.nersc.gov/control

- Component model discussions at LBL

- 27 May 1999

## Slide 3

- 27 May 1999

## 
A Module may hold an object and make it visible as output to other Modules 
The other Modules may observe one of these objects via their input
The observers of an object are notified whenever the object has changed

- A **Module** may hold an **object** and make it visible as *output* to other Modules
- The other **Modules** may *observe* one of these **objects** via their *input*
- The *observers* of an **object** are notified whenever the **object** has changed

- 27 May 1999

## Design features 

- Data and algorithms should be separated
- The framework assures that methods execute as necessary
- takes care of execution scheduling logic and the networking infrastructure
- Perhaps the most important point of this design is that of *reducing information flow*
- What this means is that, within reasonable limits(?), each stage should clearly specify its “interface” as a minimal set of parameters.
- This is to be contrasted with the design where all data, transient and persistent, is hung onto one large hierarchical structure,
- Data Objects stable, algorithms change all the time
- Use dynamic linking
- Interacting mainly  via a GUI

- Component model discussions at LBL

- 27 May 1999

## The Component Model   

-  Any valid C++ type may be a component: i.e. both intrinsic and user-defined types
- No assumption about the structure of behavior of a component is made by the network infrastructure:
- traits describe components and provide facets which serve as handles to components, e.g. for transient, persistent, or CORBA implementations.

- Component model discussions at LBL

- 27 May 1999

## We (generally) liked

-  Design based on components implementing well-defined interfaces and the extensive use of notification
- maximize re-usability
- Separation between data and algorithms
- not traditional OO, but we are used to it

- Component model discussions at LBL

- 27 May 1999

## We are worried about...

- Self-executing networks
- Lack of experience with complex networks
- largest example 12 components
- Are the end-users going to like it?
- Not many users right now
- Can we control them?
- Need predictable, repeatable execution

- Component model discussions at LBL

- 27 May 1999

## We are worried about...(2)

- No “Event” (manager)
- increased complexity of transient/persistent mapping
- ownership of DataObjects (collections!)?
- Pure Data-Flow based control
- how to broadcast an “error” or “reset” condition to each component?

- Component model discussions at LBL

- 27 May 1999

## The backdoor...

- HitFinder

- TrackFinder

- T0Refiner

- HistoHits

- Hits

- Tracks

- Vector<Hit*> myHits

- Tracks

- Hits

- myHits[j] = newT0;

- Also Hits has changed!!!

- Hits

- Hits

- Component model discussions at LBL

- 27 May 1999