SOA for Antelope

1. SOA for Antelope Web Services for Antelope-based Observing Systems Tony Fountain (fountain@sdsc.edu) Longjiang Ding (ljding@sdsc.edu) Neil Cotofana (neil@sdsc.edu) April 2005

2. Overview • Web Services Motivation • Web Services Solution Overview • Services Details: implemented actions • Services-Antelope interface layer • US Array Usage Scenario • WS-RF and Security • Status and Plans

3. Web Services Motivation • Why WS for Antelope: • Provide foundation for Antelope control system that is efficient, scalable among many-orb/rtexec systems topology • Loosely-coupled base for automating many Antelope manual configuration processes (e.g. US Array) • Basis for client-side system-manager applications (e.g. Kent’s system operator portal )

4. ROADNet Web Services Solution • Web Services Software Stack • Web Services application environment bundled with ROADNet software suite and installed by default on newly deployed Orb hosts • JDK 1.4.2 • Jakarta Tomcat 4.1.x (application server) • Apache AXIS 1.2 (Soap Server) • Modular Web Services for Antelope for configuration and control of Orbs and related processes • Supports various deployment scenarios: • Central ORB configuration • Distributed, multiple ORBs configuration • Orb Control Web Services • Initially focus on • Rtexec task manager system • Orbmonrtd ORB topology manager system • Q3302orb datalogger manager system • Behavior of deployed real-time system can be dynamically modified via control web services (e.g. turn on/off process, add/remove process)

5. Conceptual SensorNet Architecture Web Client Standalone Client Workflow Portal … Kepler Web Services Event Detection RT Monitoring Command Control Analysis SensorNet Middleware … Antelope … Lab Resources Field Devices Databases Analysis Sensors Actuators Visualization … Dataloggers … Resources

6. Desktop and Mobile Users Geospatial SensorNet Architecture Standaloneweb service clients Portal Server WSDL WSDL SOAP Servers SensorMiddleware Sensors Lab Resources Datalogger Field Devices …

7. Antelope Web Services (Details) • Currently implemented rtexec services include:http://phalanx.sdsc.edu:8080/SensorService/services/Rtexec?wsdl • getAllProcesses: • retrieve all the defined processes within rtexec “Processes” array • getAllOnProcesses: • retrieve all processes listed as “on” within the rtexec “Run” table • getStatus4Process: • get status info. ('on' or 'off') of given process within “Run” table • turnOnAProcess: • turn on a given process within rtexec “Run” table • turnOffAProcess: • turn off a given process within rtexec “Run” table • restartAProcess: • restart a given process with an optional delay before restart • addANewProcess: • add a new process into the rtexec • removeAProcess: • remove a process from the rtexec • getPfFile: • retrieve whole content of rtexec entity as string for viewing or editing

8. Antelope Web Services (Details) • Currently implemented orbmonrtd services include: http://phalanx.sdsc.edu:8080/SensorService/services/Orbmonrtd?wsdl • getAllSources: • retrieve all the defined sources within orbmonrtd “Sources” table • addANewSource: • add a new source into the orbmonrtd • removeASource: • Remove a source from the orbmonrtd • getPfFile: • retrieve whole content of orbmonrtd entity as string for viewing or editing • Currently implemented q3302orb services include: http://phalanx.sdsc.edu:8080/SensorService/services/Q3302orb?wsdl • getAllDataloggers: • retrieve all the defined dataloggers within q3302orb “Dataloggers” table • addANewDatalogger: • add a new datalogger into the q3302orb • removeADatalogger: • Remove a datalogger from the q3302orb • getPfFile: • retrieve whole content of q3302orb entity as string for viewing or editing

9. Services-Antelope Interface: Pf2Java • Pf2Java: • Java package for parsing and representing Antelope PF “entities” or specific PF files • Handles the cascading/composite definition of certain PF entities via the $PFPATH system variable • Naming conventions parallel those found in existing Antelope APIs (where possible) • Motivation: • Antelope system relies heavily on parameter files (PF). System behavior can be modified at run-time by editing these files programmatically (e.g. rtexec.pf) • Description of classes: • User classes: • PfValue • PfArray (extends PfValue) • PfTable (extends PfValue) • Pf (extends PfArray) • System classes: (used by Pf class to parse PF files) • AntelopePfLexer • AntelopePfParser • AntelopePfParserSymbol • Dependencies: • java_cup.runtime library required for compiling and executing Java code • Built with: • Java CUP parser builder API (GPL open source software) • FLEX lexer/tokenizer builder API (GPL open source software)

10. US Array Usage Scenario • Activity: provisioning new monitoring sites • Candidate tasks for Web Services: • Data Logger Configuration (q3302orb.pf) • Transition from “prelim” Orb to “production” • Update Display Tools (orbmonrtd.pf) • Case Study: Transition from “prelim” Orb to “production” Orb • Web Service tasks: • Remove connection from Data Logger to Prelim Orb • Add connection from Data Logger to Production Orb • Notify data logger to send future data to new Orb • Can be triggered from Web Portal interface • Diagram: q3302orb serviceremove datalogger Prelim Orb 1. X Web Portal Data Logger q3302orb serviceadd datalogger 2. 3. Product -ion Orb orbmonrtd serviceadd source

11. US Array Scenario: adding new ORB-based sensor station 1. Get notification (email, call) 2. Gather info. (Data Logger type, IP Address, password, comm. Type) 3. Init communication with datalogger(edit param file: q3302orb.pf) 4. Verify Data Transmissionwith dlmon 5., 6. Get lat/lon, verify lat/lon 7. Build DB: add info into “prelim” DB 8. Wait 24 hours, check data 10.a Update real-time displays (orbmonrtd.pf files) 9. Transfer info from prelimto production DB (Send metadata to down-stream users through ORB; send email notification) Site is now operational. Begin real-time QA/QC cycle 10.b Regenerate Travel Time stuff (ttgrid.pf); restart orbassoc Web service automated process 10.c Update NAGIOS config files Interactive manual process

12. SoapRequest Proxy Cert Soap Body Request Params WS-Resource WS-Resource WS-Resource WS-Resource WS-Resource WS-Resource WS-Resource Antelope WSRF Extensions Services Repositoryname, definiton, others Proxy RepositoryCerts,username, password, others Soap Header ORB Manager Databaseoperator LookupService Portal WSRF Authentication & Authorization ORB commander SOAP/HTTP Data Analyzer ORB Monitor Event Coordinator ServiceInvoker Antelope Web Services Services Subscriber OtherServices field digitizer Object Ring Buffer Field Interface Module field digitizer Databases ORB Operations: Orb ImportOrb ExportProcessingArchiving Antelope Executive Module field digitizer

13. Security in WSRF • WS Authentication Authorization in GT4 • Replacement of Grid Security Infrastructure (GSI) • Included: • Message level security which implements two standards: • WS-Security • Describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication • Provides a general-purpose mechanism for associating security tokens with messages • Describes how to encode binary security tokens • WS-SecureConversation • Layered on top of WS-Security • Mechanisms for establishing and sharing security contexts as well as deriving session keys from security contexts • Suitable for multiple messages exchanged between service provider and consumer • Authorization framework • Handle many authorization schemas including grid-mapfile, access control lists (ACL), and custom authorization handlers via the Security Assertion Markup Language (SAML) protocol • GT4: the new WSRF implementation (release in Jan. 31, 2005)

14. Status and Plans • Current Status • Antelope web services: • Rtexec: http://phalanx.sdsc.edu:8080/SensorService/services/Rtexec?wsdl • Orbmonrtd: http://phalanx.sdsc.edu:8080/SensorService/services/Orbmonrtd?wsdl • Q3302orb: http://phalanx.sdsc.edu:8080/SensorService/services/Q3302orb?wsdl • Pf2Java package foundation complete and functional • Plans • Security: • For initial, prototype services, will have IP Address-based access controls to Web Services (a la Antelope native security system) • For longer term, will implement certificate-based security, taking advantage of WS-RF security APIs and mechanisms • Web Portal: web-based collection of customized web services clients for various domain applications • Make use of underlying Antelope Web Services • Certificate-based user authentication system • Integrate the latest WSRF standards for authentication/authorization of WS execution • Elaborate on US Array case study (adding a new monitoring site) • Integrate into KEPLER workflow system