# Presentation: 066144

## Introduction to Object Networks

- Overview:
- Architectural design: the *how* and the *what*
- Canonical example: EM calorimeter cluster finding
- Some Background to the Objet Network design
- Object Networks: an Overview
- Some basic assumptions of the design
- Architecture overview
- The Component Model

- Component model discussions at LBL

- 27 May 1999

## Architectural design: the how and the what

- The architectural question can be divided into the *how* and the *what*:
_**The **__***how***_:
- This is the various parts of the architectural infrastructure - what they are and how are they tied together.
- This explains how things are made possible, but does not describe in detail how this is used to achieve physics goals.
_**The **__***what***_:
- This describes what the offline software is to do.
- This exploits the *how* to accomplish the real physics goals.
- This talk is primarily aimed at describing an approach to the *how* and contains less on the *what*.

- Component model discussions at LBL

- 27 May 1999

## Canonical example: EM calorimeter cluster finding

- The EM calorimeter cluster finding which has been used in the offline software up to now can be decomposed into the following step:
- read in calorimeter digits
- fill a set of “dense” matrices
- each matrix corresponds to a region of uniform readout (x) granularity,    >1 region per sampling
- calibrate the energy matrices
- “compress” the set of matrices to a single matrix
- look for cluster seeds in compressed matrix with a sliding window
- build clusters from seeds using original set of dense matrices
- Some history:
- As a master’s thesis, Lassi Tuura cast this into an OO model and used it as a vehicle to develop his ideas on component technology

- Component model discussions at LBL

- 27 May 1999

## This “algorithm” can be viewed as an object flow diagram: 

- 27 May 1999

## This is known as a “referential object model”:
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

## Some background to the Object Networks design 

- The development of this work is based on the analysis of existing commercial component object models:
- Distributed object models, i.e. both
**CORBA** the Common Object Request Broker Architecture specified by the Object Management Group, and
**DCOM**, Microsoft’s Distributed Component Object Model
- Object models in analysis frameworks, e.g.
**AVS/Express** and **IRIS Explorer**
- The design of Object Networks is based to a large extent on the paradigm expressed in AVS/Express:
- Developers work interactively, dragging standard components to the desktop, connecting them up, editing their properties, and executing the network
- One can also add user code to components and shrink-wrap networks

- Component model discussions at LBL

- 27 May 1999

## Some background, cont. 

- The adoption of a particular commercial analysis tool was not considered feasible:
- IRIS Explorer
- Would limit the component granularity: each component runs in a separate process
- Only data is passed between modules, not objects
- AVS/Express
- Does have a fine-grained component model, but is considered too expensive to go on every physicist’s desktop.
- The direct use of CORBA or DCOM as the basis for all fined-grained components is not feasible either:
- programming interface is not simple
- performance considerations: no inlining in the same process space, and network costs limit the amount of distributed  processing possible.

- Component model discussions at LBL

- 27 May 1999

## Object Networks: an overview

- Object Networks is proposed as the framework for reconstruction and analysis software for both batch and interactive work.
- Defined to be an interconnected network of component objects.
- There are two families of component objects: *data objects* and *modules*.
*Data objects* are used only as *input/output*.
*Modules* are algorithmic type objects which contain:
*inputs*, *outputs*, and *methods*
*Methods* do the work of a module and can be connected to the *inputs/outputs*:
- connected to an *output*, a method would *produce* the corresponding data object
- connected to an *input*, a method would *execute* when the *input* changes
- When an *input* of one *module* is connected to the *output* of another,
- the *input* becomes an *observer*, and
- the *output* and the *input* refer to the same *data object*

- Component model discussions at LBL

- 27 May 1999

## Overview, cont.   

- The framework assures that methods execute as necessary
- takes care of execution scheduling logic and the networking infrastructure
- Developers and users concentrate on defining/choosing the right components and connecting the inputs to correct outputs
- can be done statically by programming or dynamically with an application builder
- The key is to decompose the problem space into modular and replaceable components
- the granularity can be at any level
- the network does not care what happens inside a component

- Component model discussions at LBL

- 27 May 1999

## Overview, cont.   

- A key part of the adaptability of the design is that it is not *intrusive*:
- A *module method* may perform any amount of computation invisible to the network, or
- A *module method* may contain its own *network context* which encapsulates all network messaging activity
- e.g. a method may create a context, modify an output, and release the context. When the context is released, the network activity is performed. This is how a single module method can stimulate the network activity from inside a loop.
- A *data object* may be any valid C++ type, including primitive types.
*Modules* differ only in that they must inherit from an abstract base class
- It should be easy to use well decomposed code in object networks, and
- Using object networks in other environments should be painless.

- Component model discussions at LBL

- 27 May 1999

## Overview, cont.   

- Perhaps the most important point of this design is that of *reducing information flow* and thereby weakening the coupling between the calculation stages.
- What this means is that, within reasonable limits, each stage should clearly specify and use only those parameters that it is directly interested in - nothing more and nothing less.
- This is to be contrasted with the design where all data, transient and persistent, is hung onto one large hierarchical structure,
- which is no different than the common FORTRAN practice of communicating everything via COMMON blocks.

- Component model discussions at LBL

- 27 May 1999

## Some basic assumptions of the design   

*Data and algorithms should be separated*.
- Similar to the model-view-controller paradigm: model knows nothing about the presentation - it is the view that accesses the model and decides how to present it.
*Data object definitions change rarely, but algorithms change all the time*.
- It is important to localize in the code the parts which undergo frequent modification.
- Most likely algorithmic components will be developed by separate groups, and so the connections, or data objects, should be stable.
*Operating systems to be used support dynamic linking.*
*There is going to be a high-level graphical user interface.*
- Working with a GUI and scripting language should make it easy to describe dependencies and discuss about designs.

- Component model discussions at LBL

- 27 May 1999

## Architecture Overview   

- The object network constituents are:
- one or more registries
- a component loader
- component objects: data objects and modules
- connections
- execution domains, and
- an execution scheduler
**Registries** - contain info about component objects to be used in the network.
**Component loader** - locates components and binds them upon demand.
- Uses registries and shared by all networks.

- Component model discussions at LBL

- 27 May 1999

## Architecture Overview, cont.   

**Data objects** - component objects whose behavior is irrelevant to the network. Parameters (see below) connect to data objects.
- One specifies the inheritance relations so that parameters may also connect to derived classes.
**Modules** - component objects with behavior *known* to the network.
- They consist of *parameters* and *methods*.
- A module may be a *shrink-wrapped network* - exposing only some of the internally used parameters and methods.
**Parameters** - handles which refer to component objects, e.g. inputs/outputs.
- Can have *reference* or *value* semantics, i.e. “point to” or “maintain the storage for”.

- Component model discussions at LBL

- 27 May 1999

## Architecture Overview, cont.   

**Methods** - objects which is connected to the actual “*method*” to be executed.
- A method is an observer waiting for *state-change* in input parameter(s) in order to be *triggered.*
- Once triggered, a method creates an *action* which is given to a *context* and queued. The *scheduler* determines when a method will be executed.
- A method may use a parameter to output a component.
**Connections** - these link parameters to other parameters, e.g. inputs to outputs.
- When crossing execution domains, they must provide a communication mechanism between objects in the different domains.

- Component model discussions at LBL

- 27 May 1999

## Architecture Overview, cont.   

**Execution domain** - unit of parallel execution.
- Methods execute sequentially within a single domain.
**Network or execution context** - encapsulates all network activity.
- When a context ends, it is guaranteed that all operations requested within the context have been executed.
- A context manages the actions from the network activity - when a method is triggered, it sends an action (event) to a queue in a context.
- A context guides the execution logic and hides the existence of the network.
**Network or execution scheduler** - this manages the contexts, scheduling the actions to be executed.
- This also manages all execution domains.

- 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

## The Component Model, cont.   

- Components that inherit from the **Module** class are the active objects that the network knows about.
- An important point is that data objects may be *fixed*:
- this means that code from data objects may be imbedded inside clients, i.e. method in-lining
- this forces clients to evolve in lock-step with *fixed data objects*
**Component implementation:**
- All components are implemented as dynamically loaded libraries
- Each *component*, and each component *version* are uniquely identified
- This requires some extra-user defined information in the form of macros.
-  guaranteed that all operations requested within the context have been executed.

- Component model discussions at LBL

- 27 May 1999

## The Component Model, cont.   

**Network execution:**
- All network activity is wrapped inside a network context.
- Various activities generate *actions* (events), e.g. a change to an observed data object.
- Actions are queued in a context.
- When a context ends, i.e. destroyed, it *flushes* its queue. This continues until no new actions are created.
- Multiple contexts may be embedded inside each other to form a stack, which helps to structure the execution.

- Component model discussions at LBL

- 27 May 1999

## The Component Model, cont.   

**Parameters:**
- These are the single most complex class in the system.
- They are responsible for hiding the details of manipulating user-defined components, and to create notifications when they change.
- This is done with knowing little about the components
- Parameters look like pointers to components:
- both operator* and operator-> are defined
- Parameters keep track of the different *semantic modes* of a component: *by value*, *by reference*, or *by pointer*
- typically outputs hold components by value and inputs hold components by reference
- Parameters also perform the notification for observed objects (sends actions)
- This is done when reassigning an output connection, or one may also explicit open and close a connection.

- Component model discussions at LBL

- 27 May 1999

## A typical class declaration, for example, for the EventLoader would look like:

- One declares publicly the inputs and outputs.
- Methods remain private. One declares a “Method” object m_loader, and a C++ method load(). The method object is connected to the actual load method in the constructor.
- Assignment, e.g.
-   out_model = in_model;
- will send notification to the network context.

- 27 May 1999