fesa collaboration & dependencies alexander schwinn
DESCRIPTION
FESA Collaboration & Dependencies Alexander Schwinn. Topics. Framework – CERN build system Framework – Middleware Abstraction Layer 3rd Party – cmw-rda 3rd Party – cmw-stomp ACC-Accounts for CERN. Framework – CERN build system. Global. Make.generic. Global-Project-Specific. - PowerPoint PPT PresentationTRANSCRIPT
FESACollaboration & 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
Makefile
Makefile.dep
Sub-Project-Specific
Make.parent
Global
Global-Project-SpecificMake.generic
Make.common.maven
Doxyfile Make.[Project]
Make.targets
includes
includes
(e.g. fesa-core)
…
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
rdaDeviceServerBase
rdaValueChangeListener
rdaData
Subscription Tree
is a
SubscriptionTreeManager
has a
uses
GeneratedCode
FESADeviceServeruses
cmw-rda
fesa-core
some fesa-classGetSetDefaultServerAction
ServerActionexecutes
uses
8
Framework – Middleware Abstraction Layer
• Encapsulation of middleware (RDA) in an additional abstraction 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
cmw-rda
cmw-rbac
pm
cmw-log
cmw-stomp
cmw-log-stomp
cmw-serializer
cmw-util
cmw-directory-client
fesa
OmniOrb
Abstract middleware layer, used to transfer dataRole based access control framework
The concrete network-middleware layer
General logging library,
CERN log-appender ( UTC-Channel )
What is the difference to cmw-stomp ?
CERN post-mortem framework
???
Collection of utility-methods
Client part of cmw-director (nameserver)
11
• 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?
3rd Party – cmw-rda
12
Topics
Framework – CERN build system Framework – Middleware Abstraction Layer 3rd Party – cmw-rda 3rd Party – cmw-stomp ACC-Accounts for CERN
13
• 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.
3rd Party – cmw-stomp
cmw-stomp
fesa-navigator
cmw-log fesa-binary
diagnostic-data, send to UTC port
instantiate
register stomp appender
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
• Motivation: access the fesa-gsi codebase in svn• Who should get acc-net accounts ?• What is the current state / do we have blockers ?
ACC-Accounts for CERN
16
? ? ?
17
Thanks for your attention !