1 / 10

PVSS SOAP Interface

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)

tierra
Download Presentation

PVSS SOAP Interface

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 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

  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? • <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”/>

  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 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” <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!

  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

More Related