100 likes | 234 Views
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)
E N D
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 CMS RCMS TK RCMS HCAL RCMS ECAL RCMS EVB RCMS MUON RCMS ECAL DAQ ECAL DCS XDAQ BARREL ENDCAP BARREL ENDCAP XDAQ XDAQ HV LV XDAQ XDAQ XDAQ XDAQ XDAQ XDAQ
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? • <ON originator=“rcms001”/> • logical datapoints– serving as commands • <SET_DP originator=“rcms001” dpName=“STATE_DP” dpValue=“ON”/> • raw access– full PVSS DP name • <SET_DP originator=“rcms001” dpName=“STATE_DP” dpValue=“ON”/>
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 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” <setParameter … /> command (?) • <setParameter originator=“rcms001” dpName=“STATE_DP” dpValue=“ON”/> • 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