A Pragmatic And Versatile Architecture for LHC Controls Software

1
A Pragmatic And Versatile Architecture for LHC
Controls Software

• 11 / 10 / 2005
• iCALEPCS 2005 - Geneva
• Lionel Mestre on behalf of LSA Team

2
A bit of context

• CERN Controls Group
• Controls Software for the LHC
• LSA shared project between Controls and Operation
• Provide homogenous application software to
  operate the SPS, its transfer lines and the LHC

3
Overview

• Software challenges
• 3-tier architecture approach
• Design of a solution
• Results
• Conclusion

4
Logging
Fixed Displays
Operator Console 1
Operator Console 2
Operator Console 3
Operator Console 4
Broadcasting
Publication
BLMs Concentration
4000 Beam Loss Monitors

5
Operator Console 1
Operator Console 2
Operator Console 3
many applications
many applications
many applications
Complex Business Logic (Settings, Trim, Trim
History, Generation, Optics, Exploitation,
Reference)
Datastore
Devices
6
3-tier architecture

• Technical advantages
• Central access to hardware
• Central access to database
• Central security
• Reduced network traffic
• Reduced processing load on consoles
• Possibility of Web based clients
• It can scale

7
3-tier architecture

• Software Engineering Advantage
• Modular architecture
• Layered architecture
• Separation of a core set of services from the
  applications

8
Distributed Architecture Complexity

• 3-tier comes at a cost
• Complexity of programming
• Complexity of testing and debugging
• Complexity of deployment

9
Complexity must be handled

• Need of Standard Services
• Service discovery
• Remoting
• Transaction handling
• Database access (mapping)
• Security

10
One Answer J2EE EJB

• Widely used
• In house experience (TH2.3-7O, TH3A.1-5O)
• Change of programming model
• Intrusive
• Force the use of container
• Force the use of components
• Tie the persistency to the container
• Deployment hell

11
Important facts for us

• Design for 3 logical tiers
• Run 2 or 3 physical tiers
• Developers write plain Java
• No change in the programming model
• Focus on our domain
• No time for doing infrastructure

12
Another Answer J2EE EJB Spring Framework

• Spring Framework is a complete alternative to
  EJBs
• Provides
• POJO-based programming model
• Abstract Transaction layer
• Remoting facilities
• Configuration management
• JDBC Abstraction layer
• Integration layer with many 3rd party
• Much more

13
What we used

• XML based Application configuration and wiring
• AOP based transaction abstraction
• Integration with Hibernate
• IoC based JDBC abstraction
• HTTP based remoting
• JMS Integration
• Web Framework

14
Architecture
15
Client Tier
Applications
LSA Client API
JAPC API (TH1.5-8O)
JAPC CMW/RDA
JAPC-LSA
Spring HTTP Remoting / Proxies
JAPC Remote Client - JMS
HTTP
HTTP
JMS
Business Tier (Web Container)
LSA Client API
JAPC Remote Server - JMS
LSA Client implementation
CORBA IIOP
LSA CORE (TH1.4-8O) (Settings, Trim, Trim
History, Generation, Optics, Exploitation,
Reference)
Parameters Concentration
JAPC
Data Access Object (DAO)
JAPC CMW/RDA
Hibernate / Spring JDBC
CORBA IIOP
JDBC
Datastore
Devices
16
Results and Future Targets

• Control of TI8 (October 2004)
• Steering of the SPS ring orbit
• LEIR controls (TH4.2-1O)
• SPS start-up
• Extraction sequencing TI2/TI8
• LHC sector test

17
(No Transcript)
18
Assessment

• Risky move in 2003 (obvious in 2005)
• Industry embraced the lightweight approach
• Spring Framework momentum
• EJB 3.0
• We dont feel trapped in one technology choice

19
Conclusion

• We designed 3-tier with none of the usual
  overhead
• We were not tied to a given technology
• We did all of our developments in 2-tier and ran
  in 3-tier with no problem
• We were much more productive
• Our experience was very positive