Architectural Styles of HEP experiments

Summary and Conclusions of Architecture Session

1. Introduction (Convenor - John Harvey)

The goals of this session were to raise awareness of the importance of software architecture in building large software systems, and to exchange opinions on what constitutes a good architecture. There are several important reasons for stressing the importance of software architecture. An architecture-centric approach tends to result in software systems that can be made to be more adaptable to changing requirements and is strongly recommended by the most commonly used software processes in the industry. In addition the architecture provides a blueprint to aid communication between developers and therefore can considerable ease the task of migrating to OO. Frameworks are real code that implement the architecture and guarantee that it is respected. To be successful frameworks must solve most of the standard computing tasks, they must do a lot for you, and also they must provide a clear, easy-to-understand interface for the end-user developers. A study group was convened and met 8 times during the summer to discuss these issues. These discussions generated much of the material that has been used to prepare this session.

2. Architectural Styles of HEP experiments (Rapporteur RD Schaffer)

Definition Architecture addresses the organisation of software, the structural elements and their behaviour. The basic terminology and vocabulary were defined, explaining terms such as toolkits, frameworks, interfaces, components, and design patterns. Following the literature, RD gave a categorisation of systems (user-, data- or computation- centric) and of architectural styles (call-and-return style, data flow style, data centred repository and interacting processes). To identify style, the organisation of data and the interaction of control and data must be specified. Any system is a mix of styles.

Bibliography A useful bibliography was compiled by the Architecture Study Group and is maintained on its web page : (URL : http://lhcb.cern.ch/computing/SWarchWG/html/Default.htm ). It contains references giving an introduction to Architecture and on classification of styles, on frameworks and on physical design. The Unified Software Development Process (Booch, Rumbaugh, Jacobsen) is a useful standard to follow. It is use-case driven, architecture-centric, iterative and incremental.

Foundation Libraries Many open questions on existing packages e.g. more linear algebra (Blitz++ or SL++), GEANT4 units or Fermilab's SIUnits package? There are still missing pieces such as error logging and exception handling.

Frameworks and toolkits Choices to be made on basic design criteria. For example GAUDI identifies data objects and algorithm objects, maintains transient and persistent representations of data, is datastore-centred, encapsulates user code in specific places, specifies model for component interfaces. Alternative approaches were shown; AC++ (BABAR, CDF), CARF (CMS), Object Networks (ATLAS), data abstraction and data centred repository (ALICE)

Persistency A major issue is coupling to persistency mechanism - choice has implications for migration to new technologies, performance etc. Two architectural models are in evidence, one with, and one without, a transient event store. BaBar, CDF, D0, LHCb are with, CMS, ALICE are without.

Application meta information This gives run time knowledge about classes. In ROOT this is the key component of the architecture

User Interface This should not dominate architecture. Where should knowledge about the UI be?, Should UI be detachable?

Physical design : It is very important to be able to decompose large systems into smaller manageable components. Issues are the compile-time and link time costs, dependencies between packages. System architects should take responsibility for physical design (see Lakos, Martin)

Abstract interfaces : Use factory and strategy patterns, dynamic loading, component technology (e.g. CORBA and DCOM)

3. Discussion

There were a number of direct questions and comments to the rapporteur's talk :

Quarrie – Distinguishing transient and persistent representations gives many practical advantages e.g. allows refit track after adding removing point, policing access to data.

Brun - thinks it is fundamentally wrong and unnecessary to separate them.

Knobloch – Are all approaches of experiments different? Is there room to do something together? Wormser asked what are the reasons behind different choices? This was followed up later - see below.

Palazzi – C++ gives encapsulation but not meta information. Is OO paradigm taking us in the wrong direction?

Brun believes Java can be a good direction for meta information, but is only 5% of needs. Scripting is fundamental to access interface of objects. The scripting language should match the language used for the object model.

Tuura – noted that architecture transcends technology i.e. is not a language issue.

Newman, White – commented that the architecture did not seem to address interface to wider world and distributed nature of processing. What about resource management, migration of program to another location? What if a resource is not available? These issues must be addressed.

A number of propositions were put by the convenor to stimulate more general discussion:

Technical Forum : It was proposed to continue the ad-hoc study group as a technical forum, to continue to circulate ideas and learn from each others experience i.e. successes AND failures.

Architects : It was proposed that every software production unit should have an architect to take highest level responsibility for the structure, quality, reliability, maintainability etc. of the software. By unit mean each experiment's software system as well as common software projects such as GEANT4. Architects should participate in the technical forum.

Architectural Guidelines : It was proposed that guidelines should be produced for architects to follow. Examples of guidelines could be that components should be orthogonal i.e. use of a particular histogramming component should not imply use of a particular visualisation component. Others could include an interface model, guidelines on packaging etc. These would be one deliverable from the technical forum.

Design Patterns Experience should be documented to provide a lasting record and to make information more widely available. For example documenting design patterns that have worked in the past (e.g. in CDF, D0, CLEO etc), and those that didn’t work, would help everyone. It implies some work. Could be a theme for session at CHEP.

Java - Assess impact of Java. Make realistic prototypes, building on work of existing projects such as JAS and WIRED. Study problems of mixing languages. Prepare for an HEP-wide Java library.

Comments on Technical Forum

Stickland commented that different solutions are due to local intellectual efforts. This is the right time to explore different architectures. But this is reasonable only if there is a good feedback mechanism to the whole community. He is very much in favour of this technical forum. It probably needs to be a bigger group, but not too big.

Palazzi Technical forum is interesting but architects are special (Prima donnas) They don’t need to share thoughts. They want to be the best. That’s how people learn.

Mato Yes architects will have different visions. By analogy, I want to buy different pieces at the supermarket. There is a big advantage if the architecture can be based on pieces that can be easily found.

Quarrie had read the GAUDI document. One thing he liked is that it identifies services as abstractions and believes that these are areas where we should be able to collaborate. For example for the histogramming service we should be able to agree on at least an abstract interface. He would like to see collaboration on these services.

Comments on Java

Brun commented on timescales. To build applications we need an infrastructure. Language needs stability, typically 10 years before it can be used in production. For Java we need 5 more years. The framework is the next layer and this takes 5-6 years. Applications will take another 3-5 years.

Ronan claimed that we are far behind the industry and that Java is getting to be a mature and widely used language. JAS is already being used for analysis and for online applications. We don’t have to wait another 5 years.

Palazzi for architecture we need a language-independent conceptual tool.

Delfino At Padova we were expressing concepts in non-understandable ways. Disturbed by the statement that maybe we need a HEP-wide Java library. We also need to have independence from the language. If we express what we need in a particular language we are lost.

Newman It is important to have a vision of what you are building. Once you know it, you can design it. However we have never seen a distributed analysis system!

Califiura noted that separating data from algorithms can be a big advantage for solving problems to do with mixing languages.

Brun It was a big step to go from Fortran to C++. It is not so big to go to Java.

Carminati what about users? Users do follow; ALICE users use C++. We need to migrate users. We choose an implementation (in this case C++) and cannot turn round later and tell them to use Java.

4. Conclusions

The conclusions as they appeared to the convenor were as follows :

We have started to define a common vocabulary for discussing architectural issues. There has been progress in expressing our ideas and communicating them to each other.
Several examples exist of architectures and their implementations and it is evident that different approaches have been tried. We are still at the experimental stage in which different design choices need to be explored and then assessed.
Existing architectures are still limited in scope and important issues, such as dealing with remote access of data samples from the central repository, have still to be addressed.
It was stressed that architecture is independent of the language used to describe it. However Java is coming and we should prepare for it. We need to take practical steps to assess its impact basing ourselves on work already done in projects such as JAS and WIRED.
There seems to be considerable support for continuing discussion on architectural issues. The ad hoc study group should become a technical forum to deal with this need.
All major software production units should be encouraged to participate in the technical forum.
The size of the forum needs to be kept to manageable. Each unit should be represented by at least one person, normally this person being the unit's architect.
Relevant experience should be collected and documented and made widely available. This requires a non-negligible amount of effort but would bring great benefits.
A number of practical issues will need further discussion

Should we attempt to follow a common set of architectural guidelines ?
Should we collate experience on design patterns, architectural and algorithmic, good and bad?
Can work be done together on specifying common services?

Who should convene this technical forum?
How can its activities be given good visibility?
What is the optimum size?

Members of architecture study group are :

Alberto Aimar, Christian Arnault, John Apostolakis, Rene Brun, Federico Carminati, Dirk Duellmann, John Harvey (convenor), Vincenzo Innocente, Pere Mato, Fons Rademakers, RD Schaffer, David Stickland, Craig Tull, Lassi Tuura, Pierre vande Vyvre