FESA Collaboration & Dependencies Alexander Schwinn

1. FESA Collaboration & Dependencies Alexander Schwinn

2. Topics Framework – CERN build system Framework – Middleware Abstraction Layer 3rd Party – cmw-rda 3rd Party – cmw-stomp ACC-Accounts for CERN

3. Framework – CERN build system Global Make.generic Global-Project-Specific Make.common.maven includes Make.[Project] Doxyfile … Make.parent Make.targets Sub-Project-Specific (e.g. fesa-core) includes Makefile Makefile.dep

4. Framework – CERN build system • Current CERN NFS- Makefile approach • pro • Standardisation • Easy to use • con • Portability • Flexibility • Usage of absolute pathes

5. Framework – CERN build system • Alternatives ? • Usage of generalized makefile-project, which has to be located at same level then sub-project for compilation & can be used for all c/cpp-projects? • pro /con ? • Only local makefiles per project • pro / con ? • Other ideas ?

6. Topics Framework – CERN build system Framework – Middleware Abstraction Layer 3rd Party – cmw-rda 3rd Party – cmw-stomp ACC-Accounts for CERN

7. Framework – Middleware Abstraction Layer rdaValueChangeListener rdaDeviceServerBase cmw-rda uses rdaData is a FESADeviceServer uses has a SubscriptionTreeManager fesa-core Subscription Tree uses ServerAction executes GeneratedCode some fesa-class GetSetDefaultServerAction

8. Framework – Middleware Abstraction Layer • Encapsulation of middleware (RDA) in an additionalabstraction layer • pro • Possibility to replace middleware • Easy to mock rda in unit-tests • ?? • con • Is a replacement realistic? Only makes sense if it is lab-specific ! • A lot of work for adding an additional possibility • ??

9. Topics Framework – CERN build system Framework – Middleware Abstraction Layer 3rd Party – cmw-rda 3rd Party – cmw-stomp ACC-Accounts for CERN

10. 3rd Party – cmw-rda fesa cmw-rda Abstract middleware layer, used to transfer data cmw-rbac Role based access control framework cmw-log General logging library, cmw-stomp CERN log-appender ( UTC-Channel ) cmw-log-stomp What is the difference to cmw-stomp ? pm CERN post-mortem framework cmw-serializer ??? cmw-util Collection of utility-methods cmw-directory-client Client part of cmw-director (nameserver) OmniOrb The concrete network-middleware layer

11. 3rd Party – cmw-rda • current situation at GSI • OmniOrb  ZeroMessageQueue • Compatibility / API ? • Already some estimate release-date ? • Extension of collaboration to cmw-rda • to get rid of cmw-rbac and pm dependency @GSI • to be able to use GSI-log-appender in cmw-rda • cmw-rda-core + cmw-rda-cern/gsi ? • Who to ask ? • at CERN • at GSI • Who will take care for the extension of the collaboration?

12. Topics Framework – CERN build system Framework – Middleware Abstraction Layer 3rd Party – cmw-rda 3rd Party – cmw-stomp ACC-Accounts for CERN

13. 3rd Party – cmw-stomp • cmw-stomp is default CERN log-appender. It just streams data to a defined udp-port. • currently fesa-gsi uses syslog-appender + std::out-appender for logging • cmw-stomp is still used inside fesa-core in order to send diagnostic-data to the navigator • Plan is to keep cmw-stomp, until we have a GSI log-appender • than we can evaluate if a lab-specific replacement for the diagnostic-stream would make sense. fesa-navigator diagnostic-data, send to UTC port instantiate cmw-log fesa-binary register stomp appender cmw-stomp

14. Topics Framework – CERN build system Framework – Middleware Abstraction Layer 3rd Party – cmw-rda 3rd Party – cmw-stomp 3rd Party – pm (PostMortem) ACC-Accounts for CERN

15. ACC-Accounts for CERN • Motivation: access the fesa-gsi codebase in svn • Who should get acc-net accounts ? • What is the current state / do we have blockers ?

16. ? ? ?

17. Thanks for your attention !