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
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
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
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)
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
- 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
- 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
- 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
- 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
- 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 didnt 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 dont need to share thoughts. They want to be the best.
Thats 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 dont 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
- 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.
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
- 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
- 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
- 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