1. PVSS SOAP Interface RCMS  DCS XDAQ  DCS (anyclient  PVSS) Peter Rosinsky, CERN PH/CMD CMS week 15-19/3/2004

2. Motivation  RCMS communication with DCS  CMS DAQ (RCMS/XDAQ): SOAP messages (over http)  SOAP talker/listener  as decoupled as possible (avoid dependencies)  run on the side of PVSS  no native support in PVSS for external communication  solution: SOAP listener running as PVSS API manager  PSI = PVSS SOAP Interface

3. PSI communication MUON RCMS CMS RCMS ECAL RCMS HCAL RCMS TK RCMS ECAL DAQ ECAL DCS BARREL HV ENDCAP BARREL XDAQ LV ENDCAP XDAQ EVB RCMS

4. Requirements  SOAP messages over http  read/write access (read for all)  logical (Command  DP+value) and raw interface  multiclient operation  synchronous operation (hide asynchronous PVSS)  sync GET  command sync with states  identification, authentication, security  performance: from few/sec to maybe ~thousands/sec (?)

5. PSI Features  commands – internal translation into DP/value  configurable?   logical datapoints – serving as commands   raw access – full PVSS DP name 

6. PSI Features  identification – “any” unique ID  hostname, node name, number  originator attribute  ownership – for write access  TAKE/RELEASE commands  internal, or also PVSS synchonized (?)  authentification – user/pwd  PVSS?, other?, own?  security – SSL  http server future

7. PSI Features  multiclient operation  keep list/stack of multiple clients’ requests accessing multiple DPs  synchronous GET  send in the response message the value obtained asynchronously by PVSS  allows “synchonous” polling  command-state synchronization  response message sent only after certain state is reached  allows “synchronous” commads inside the client  native for RCMS/XDAQ

8. Implementation  EHS http server (pure C++)  embedded PVSS http server foreseen later  “any” PVSS version  XOAP - Xerces (DOM parser)  client-specific commands (RCMS)  Linux only for the moment

9. RCMS  DCS interface  state commands (ON/OFF/STANDBY) via logical datapoint  “standard” command (?)   synchronous GET for polling  so that RCMS does not need a special listener  no SUBSCRIBE (at least for the moment)  since it needs another listener  command-state synchronization  e.g. RCMS sends “ON” command – response comes only when the ON state is really reached  blocking!

10. Conclusions  basics of the interface defined and implemented  prototype working  RCMS FM can set and read the PVSS state DP  using RunControl applet TO DO:  finalize the message format and requirements (~this week)  finalize the interface and the RCMS (Java) client library (~next week)  port and test in Windows  identification, authentification, security  further clients, requirements