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

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

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

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 (?)

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

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

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

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

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!

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