1 / 7

Anatomy of a Workflow: A Service Oriented Architecture View

This paper discusses various aspects of workflow design in a service-oriented architecture, including portal design, dashboard prototypes, redundancy-based fail-over services, and distributed workflow security infrastructure.

louc
Download Presentation

Anatomy of a Workflow: A Service Oriented Architecture View

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. Anatomy of a Workflow (an Service Oriented Architecture view of the problem and solutions) Mladen Vouk NC State University, Raleigh, NC • Initial unified SPA portals design: consensus on portal design and portal technology to use. • Dashboard prototypes for common workflow activities: new technology. • Initial prototype for run-time redundancy-based fail-over service: redundant functionally equivalent services • Design distributed workflow security infrastructure: changing nature of the security model for the labs, one-time-password issues

  2. Workflow – Abstraction(after TSI workflow) Mass Storage Model Merge Backup Move Split Viz Parallel Computation Fiber C. or Local NFS Data Mover Channel (e.g. LORS, SABUL, FC over SONET Head Node Services Head Node Services Recv Data Send Data To VizWall Split & Viz Merge & Backup Model Parallel Visualization Web Services & DB Web or Client GUI Construct Orchestrate Monitor/Steer Change Stop/Start Control Provenance Monitoring

  3. A Hierarchical View of the Architecture Control Plane (light data flows) Provenance, Tracking & Meta-Data (DBs and Portals) Execution Plane (“Heavy Lifting” Computations and flows) Synchronous or Asynchronous?

  4. Uses registered local and remote services to construct new services and/or workflows. Saves product on a server and registers it. Global ArchitectureScientific Process Automation Registries (e.g, UDDI) and Context Gateways Workflow Composer e.g., a Web Service Registry Workflow Composer Tools Local Services Kepler Service Gateways, Virtualizations, different service Agents, etc. NCBI Services Users e.g., XML data descriptions WSDL process descriptions WSFL, MoML workflow descriptions URL/URI descriptors Data Transforms Etc. Agents and Workflow Domain Users LLNL Services SDSC Service NCSU Services Workflow Agent “Dials” needed services/workflows and executes/runs through the services/workflow, delivers output to user. Portal ORNL Service s

  5. Performance Dashboards Availability Load & Wait

  6. Other Dashboard Elements • LSF queue status on the HPC Linux clusters. This data is updated every 10 minutes or by forced refresh. • Job details

  7. Dashboard Questions • What should be displayed on the dashboard portal? • Should the information be part of the provenance data set? • Should provenance and dashboard be web-services? • Is it essential to use a service-oriented architecture to design and implement SPA solutions? • Other?

More Related