2013 IEEE Seventh International Symposium on Service-Oriented System Engineering

Architecture-based Adaptivity Support for Service Oriented Scientific Workflows

Yan Liu1, Ian Gorton2, Adam Wynne2
Concordia University, Montreal, Canada Pacific Northwest National Laboratory, Richland WA yan.liu@concordia.ca ;ian.gorton@pnnl.gov; adam.wynne@pnnl.gov
2 1

Abstract Adaptivity is the ability of a program to change its behavior automatically according to its context. Programs over multiple scientific workflows and analytic domains have similar needs of adaptivity to handle data intensive computing. These include dynamically selecting analytical models or processes according to data sets at runtime, handling exceptions to make long running workflows reliable, and reducing large volumes of data to a suitable form for visualization. Architecture support to reuse these adaptive techniques across different scientific domains helps to enhance the workflows efficiency, extensibility and reliability. In this paper, a service oriented architecture framework is presented to compose adaptive scientific workflows. This framework has a core of service components and mechanisms that eases the interoperation between disparate workflows and programs that encapsulate the adaptive control logic. The uses of this framework are demonstrated by scientific workflow scenarios. Keywords-adaptive software, scientific workflow, SOA

I.

INTRODUCTION

State-of-the-art scientific instruments and simulations routinely produce massive data sets that must be processed to discover key features of the artifact or model under study. Scientific applications to process these data are typically structured as pipelines, or workflows, comprising a number of distinct computations [3]. Complex scientific workflows have been developed in a variety of scientific domains including climate sciences, carbon capture and simulation and chemical imaging. The application workflows range from simple pipelines of a few stages, to those with complex topologies, highly concurrent processes and tens of individual stages that must be orchestrated. Numerous general-purpose workflow technologies exist for scientific computing, for example MeDICi [2], Kepler [4] and Taverna [5]. These technologies provide a visual and/or scripting language that can be used to define the processing required in a workflow, and to raise the level of abstraction employed in a workflow application solution. None however have general purpose mechanisms for specifying adaptive behaviors in the workflow descriptions. Frameworks for business applications such as BPEL [6] incorporate mechanisms for compensation when failures occur, but these are oriented towards commercial applications with well understood failure modes. More general design guidelines, such as M-A-P-E are applicable to scientific workflows. However no scientific workflow framework supports a MAPE-like framework, making this concept too abstract to use cost-effectively in scientific workflows. Hence, new

ways are needed to exploit these general-purpose workflow technologies for building adaptive workflows. In this paper, a service oriented architecture framework is proposed to compose both adaptive control logic and workflow pipelines in a unified way. The design of this framework encompasses the following architecture principles: Componentization. To make the adaptive techniques reusable to different workflows, it is essential to encapsulate the implementation details and only expose interfaces for inputs and outputs. Service bus for communication and interaction. The framework needs to support interactions between disparate programs, codes and applications for building workflows and adaptation logic. These elements are first wrapped as components, and then deployed to the service bus with welldefined interfaces and protocols for communication. Dynamic endpoints. An endpoint is always tied to a component, so that the component can be uniquely identified on the service bus. Interceptors and executors can be tied to endpoints to gain better control of dispatching the incoming requests to components. A workflow or an adaptive logic is composed by connecting the components endpoints. A dynamic endpoint is a technique to change the behavior or structure of the workflow or adaptive logic. This framework is built on MeDICi 1 , an open source middleware platform that provides an API called the MeDICi Integration Framework (MIF) to componentize programs and scripts. MeDICi uses an enterprise service bus as its core, and thus allows the components built on MIF to communicate through any languages and any protocols. Using this framework, mechanisms for constructing adaptive workflows such as intercepting workflow messages and dynamically changing the path are developed as new MIF components. Therefore they can be easily reused or customized by property settings in new workflows. The contribution of this paper is twofold: identifying the adaptivity needs of scientific workflows; and building a service oriented architecture framework that composes workflows and adaptive control logic in the unified way. The uses of this framework are demonstrated by three scenarios. II.
ADPATIVE WORKFLOWS USE CASESE

The context of adaptivity is considered in three aspects along with use cases. These are adaptivity driven by data sets, adaptivity driven by analysis processes, and adaptivity

http://medici.pnl.gov/

978-0-7695-4944-6/12 $26.00 2012 IEEE DOI 10.1109/SOSE.2013.37

309

driven by non-functional requirements. To describe the use of the system by performing remedial actions when errors, cases, we give examples of concrete scenarios. failures or exceptions occur. More advanced adaptive control Adaptivity driven by data sets. Different data sets can be logic can take proactive actions to prevent a workflow from inputs to the same analysis model. The workflow path varies performance degradation or failure. This is crucial, as according to the data set properties. An example workflow is scientific workflows are often comprised of multiple, long assessing the effect of soil erosion on productivity. The running steps. Those long running steps are critical to calculation workflow accepts inputs from historical data produce meaningful results from workflow runs, but they are collected from weather stations including measures on often vulnerable to exceptions from the program itself and temperature, precipitation, wind speed and solar radiation. from the computing environment. To predict the effects of climate policies and management In addition, the need for adaptivity evolves during the decisions on soil loss, water quality and crop yields, this lifecycle of a scientific workflow system. The development workflow needs to take predicted weather data as another of many scientific workflow systems follows an agile source of inputs. The calculation procedure remains the approach along exploratory stages. At these stages, scientific same, but the predictive input data sets need to be converted models are continuously modified and revised to improve the into the spatial and temporal scales, as well as to the same analysis. Hence, the requirements on adaptivity can be any format as the historical data set. combination of the above scenarios. However, at the Since the region under study may vary from the whole production stage, the scientific models are configured and nation to specific climate zones, it is not practical to the workflow system tends to be stable. At this stage, some preprocess the data. Therefore, injecting the data conversion adaptivity requirements may not be necessary any longer in function ahead of the soil erosion calculation occurs the workflow. For example, when all the necessary data sets dynamically at runtime. are preprocessed for quality checking, steps to assess the Adaptivity driven by analysis processes. The above quality of data sets are not part of the production workflow. workflow for assessing the effect of soil erosion on This indicates the adaptive logic should be defined separately productivity has other adaptive dimensions. To assess the from the workflow model so it can be easily modified or quality of the predicted data, uncertainty quantification needs removed. to be performed. This process needs to evaluate how In general, the techniques and their relationship to accurately the climate model outputs match the historical adaptivity needs are organized in Table 1. The rows are weather data for the region. If there are substantial technical components. The columns are general adaptivity differences then a correction is necessary by adjusting the needs. The crossover shows the example scenarios that a differences to the historical baseline. This leads to additional technical component can support in term of adaptivity. steps in the workflow. Importantly, these steps are activated Specifically, the column of agile style development of based on the analysis process and the quality of the data sets, scientific workflows uses most of the technical components. which cannot be known until runtime. Componentization and service orientation are key to enable Adaptivity driven by non-functional requirements aims to including and removing of adaptive controls from workflow make the workflow reliable and robust. The adaptivity refers models. to the ability of being able to respond to one or a set of states Adaptivity driven by Adaptivity driven by Adaptivity driven by Agile development of data sets analysis processes non-functional scientific workflow requirements Dynamic endpoint Provenance Handler Metadata Message Splitter Switch workflow path Intercept messages _ Split a list of objects to multiple instances of workflow component Aggregate multiple data sources Switch workflow path Switch workflow or adaptive path Intercept messages; Monitor workflow status Access metadata of workflow components and endpoints _ Componentization of workflow steps and Service oriented workflow composition

Message Aggregator

Intercept messages; Monitor workflow status Access metadata of workflow components and endpoints Different contexts can be wrapped as a list objects and split to multiple workflow instances Aggregate multiple Aggregate data from data sources multiple monitors Table 1 Adaptivity Scenarios and Techniques

310

III.

ARCHITECTURE FRAMEWORK

The architecture of the framework has three layers depicted in Figure 1. The top layer is the models of the workflow and the adaptive logic. A model is an executable description of the workflow. In this framework, the adaptive logic is also expressed using the workflow model. Therefore the modeling and execution of the workflows and the adaptive logic are unified in this framework. The middle layer is the MeDICi platform. A component model is defined by the MeDICi Integration Framework (MIF) API so that scientific applications, programs and scripts can be exposed as well-defined components. Hence a workflow can be modeled as MIF pipelines, consisting of MIF components and typed connectors. Similarly, an adaptive model is also composed by MIF components and connectors. The bottom layer is the service bus, which provides a multi-threaded service-oriented platform that connects MIF components to communicate over most standard communication protocols or messaging schemes.

transport, such as setting streaming to get the file content from InputStream. Below is a simple example of specifying a MIF pipeline for processing incoming files under a specific directory.
// Construct MIF pipeline for file connector MifPipeline bendPipeline = new MifPipeline(); MifConnector conn = bendPipeline.addMifConnector(EndpointProtoco l.FILE); conn.setProperty("streaming", true); conn.setProperty("autoDelete", true); // Setup endpoint for file directory File tmpDir = new File("filetestor"); tmpDir.mkdir(); String databundleUri = "file://" + tmpDir; // Construct a MIF module with processor and endpoints MifModule fileModule = bendPipeline.addMifModule(FileProcessor.clas s, databundleUri, "vm://run-setup.queue"); //Start pipeline bendPipeline.start();

Figure 1 Architecture Framework A. Components and Pipelines in MIF The key concepts in the MIF component model are Modules, Components, Endpoints and Connectors as shown in Figure 2.

Components communicate by passing messages down the pipeline as the incoming data is progressively transformed. Complete messages can be simply copied between components, or a reference to the message payload as a URI can be exchanged to reduce the overhead of passing large messages. The MIF container implements the APIs for component lifecycle management and inter-component communications. Essentially, when a component sends a message to an outbound endpoint, the container intercepts the message and delivers it over the connector associated with that endpoint. When messages arrive on a connector, the container delivers the message to the inbound endpoint associated with the receiving component. The component code can be Java (e.g. a Message Driven Bean), a WSDL-based Web service, a HTTP server, a RESTful Web service, a socket server or an executable written in any programming language. The MIF component API wraps the external code and provides the data movement capabilities to communicate with it from a MIF pipeline using a configurable connector. This approach hides the complexity of integrating heterogeneous, distributed codes into a MIF pipeline. B. Modeling Adaptivity using MIF The adaptive control is composed using MIF components the same way as a workflow is composed. Therefore the interaction between an adaptive control and the workflow is supported by the MIF communication mechanism. This mechanism uses the MIF provenance handler which can be attached to a MIF component in a workflow (see Figure 2). Figure 3 shows how the adaptive control components

Figure 2 Anatomy of MIF Component MIF supports a number of connectors based on standard transports such as HTTP, sockets and SOAP, and provides an API to incorporate new transports. Since many scientific workflows are triggered by large data files produced in a specific location, a file connector in MIF transports incoming files to its processor. Connectors support properties that can be set to configure the precise behavior of the underlying

311

interact with the workflow through a message interception mechanism.

Figure 3 Structure of MIF Adaptive Control Flow The handler intercepts the incoming (inbound handler) and outgoing (outbound handler) messages of a workflow component. From the modeling point of view, the routing of these intercepted messages to their destination is simply set by the URL values in the endpoints. Intercepted messages are routed by the dispatcher. MIF thus acts as a management proxy between the workflow components and the adaptive control components. The adaptive control in this paper follows a three-phase process of monitoring, analyzing and executing. The monitoring phase collects the metrics of interests, and does necessary filtering, or data extraction and transforming the monitored data into the format that inputs to the analysis phase. The logic is encapsulated in a monitor component. The analysis phase implements the logic for reasoning about the status of the workflow. The analysis logic is implemented in an analyzer component. It may do a simple statistical calculation or employ a complicated machine learning algorithm to determine the status of the workflow. The analysis logic depends on the complexity level of the workflow and the adaptivity requirements as discussed in section II. The analyzer component outputs its analysis result (such as a status report) to the executor component where the execution phase takes place. The executor may follow the ifcondition-then-action pattern to implement its action logic. This structure of modeling adaptive control has two benefits. First, adaptive control models are loosely coupled from the workflow models. Changes made to the workflow model or the adaptive control models are transparent. In addition, MIFs communication mechanism incorporates the necessary flexibility for including and removing adaptive control as required. This matches well with the agile style development. IV. DEMONSTRATION

regional climate-energy workflow, including 1) launching concurrent workflow instances based on input data; 2) dynamically changing a workflow path when an error occurs; and 3) detecting abnormal behavior of long running workflows. This workflow quantifies climate change impacts on energy demands and consumption of residential and commercial buildings in the energy ecosystem. It predicts changes in temperature in various geographical locations, and relates them to changes in energy use or demand based on an individual building level [12]. The workflow inputs any combination of the hourly weather files (in each year) and building profiles into an energy simulation program that estimates the climate impact on an individual building mix in a single year. The workflow includes steps to extract each row within the building profile, generate the input files for the energy simulation program using a template and running the simulation as parallel jobs. The workflow also aggregates the final simulation outputs of individual years across multiple building mixes. Since the workflow contains longrunning steps on clusters, monitoring every step of a workflow is necessary to understand the status of the workflow. Given this workflow, three scenarios of adaptivity are described as follows. A. Launch Concurrent Workflows for Scalability One run of the workflow is to process every combination of a building file and a weather file. The data processing task in the workflow is exactly the same except for the pair of combined input files. Since there are no dependencies between pairs of input files, concurrent instances of the workflow can be launched, each processing a pair of input files. As the number of pairs depends on the datasets selected by a user, concurrent workflow instances are launched adaptively according to the datasets. The solution to implement this adaptivity scenario is using a message splitter. When a MIF component returns a list of independent objects and each object needs to be processed by its destination component, a message splitter is added to the MIF components. As shown in Figure 4, upon returning the list of objects, the message splitter automatically launches a set of new instances of the destination component, and routes one object to one workflow instance. A message splitter is useful for processing the list of returned objects concurrently.

The architecture framework is demonstrated by three scenarios to address adaptivity needs of an integrated

Figure 4 Message Splitter

312

A workflow model to compose a message splitter is simple as shown below:

MifModule multiplexModule = pipeline.addMifModule(MultiplexProcessor .class, "vm://multiplex", "vm://setup"); MifSplitter splitter = pipeline.addMifListSplitter(); multiplexModule.setSplitter(splitter); multiplexModule.setName("MULTIPLEXER");

runtime by either vm://componentB.

vm://componentA

or

A MifSplitter component splitter is added to the pipeline and set to multiplexModule. multiplexModule has defined its own processor class MultiplexProcessor that browses the input directories of weather files and building files, and generates combinations of the input file pairs as a list of objects. Upon returning this object list, the splitter creates a set of new instances of the workflow component at the endpoint "vm://setup" that receives the returned object from multiplexModule. The splitter routes one object from the list to one workflow instance respectively. The concurrent instances of the workflow are dynamically created at runtime. Thus the workflow model defines the logic composition of the workflow while the MifSplitter manages the dynamics and adaptation at runtime. B. Use Dynamic Endpoints for Error Checking A dynamic endpoint is essential to address the adaptivity requirements for changing the workflow path dynamically according to the runtime conditions. An example is for error checking. At a certain point of a workflow, error checking is necessary to validate the workflow results, check conditions and make decisions on the next workflow steps. When an error occurs, the workflow may loop back to re-run previous steps before processing the next step in the pipeline if the step contains stateless component. Therefore, a workflow path cannot be statically defined. To model a workflow that potentially changes its path according to a certain condition, a dynamic endpoint is used to specify the outbound endpoint of a workflow module that changes its routing destination.

C. Detect Abnormal Long Running Workflows This workflow involves submitting jobs to a cluster and running on a large number of processors. Depending on the data in the building definition file input and the number of processors used, the time to complete a job may vary. Therefore it is not possible to setup a constant time-out value to detect if a job is running abnormally and does not complete as expected. The detection mechanism must be specified at runtime given the current workload. Usually outlier detection performs a regression analysis between the run time and the amount of work and carries out feedback control based on the regression. Such an analysis needs to be done for every step. To make the regression model accurate, the feedback control needs to collect enough samples, but it remains uncertain of the sample size at runtime. In this paper, a detection approach from [14] is applied for each critical workflow step. The solution is to compose an adaptive workflow to monitor the performance of critical workflow steps. As shown in Figure 6, the adaptive workflow consists of the following MIF entities: Provenance Handler: this is added to workflow modules of interest and generates log files that record the start and end times of the task wrapped by the module; Log Monitor: this uses a MIF file connector to monitor log files under a specific directory. When the log files are generated, the log monitor is triggered. It extracts the start and end times, and computes the time interval t to complete the job. Performance Analyzer: it computes the suspicion level that the duration is abnormally long according to [14], = -log10(P(t)) where P(t) is the probability of variable t under normal distribution. if =1, it means 99% likely the job is running abnormally long; if =2, it means 99.99% likely the job is running abnormally long. Executor: given a certain value of , the executor can generate a report of the suspicion level and notify the user through emails or messages.

Figure 5 Dynamic Endpoint for Error Checking Figure 5 shows the dynamic endpoint is set to the error checking component. The actual outbound endpoint replaces the dynamic endpoint dynamic://asw.dynamic.ep at

Figure 6 Adaptive Workflow

313

The adaptive components, Log Monitor, Performance Analyzer and Executor, can be deployed on to a separate node from the nodes hosting workflow instances. As long as the Log Monitor can access the log files, the adaptive flow can be automatically triggered upon a new log file arrival. I. RELATED WORK

REFERENCES
[1]

[2]

Existing workflow tools and frameworks focus on providing an integrated development environment for quickly defining workflows that match inputs and outputs in a static way [3]. However, runtime dynamics can only be addressed by programs or tools that adapt the workflows structure and behavior according to the context. Scientists need new ways to exploit these tools in their workflows, ideally through seamless integration with their legacy tools and data in the workflow. This indicates it is essential to develop a unified architecture framework for composing workflows and adaptive control flows. The methodologies of developing architecture-based adaptive software systems have been studied widely in software engineering and software architecture research [7][11]. The applications addressed by the methodologies are mostly system level resource management [7], fault tolerance [10], robotics [13], and Web services [1][11]. In scientific workflows, the adaptivity needs are implicit and often solved by a tightly coupled implementation in the workflow logic. This makes it difficult to improve the quality attributes of a workflow system, especially as the scientific exploration process leads to the evolution of the workflow development. To address this problem, our approach is built on an architecture framework that models and deploys scientific workflows and adaptive control flows in a unified way. II. CONCLUSION

[3]

[4]

[5]

[6] [7]

[8]

[9]

Scientific applications are increasingly dependent on workflows for managing tasks of ingesting large volumes of heterogeneous data. These applications perform complex and often computationally expensive analysis on a variety of hardware in order to prodice useful results and visualizations. Scientific applications over multiple scientific and analytic domains have increasing needs to handle similar dynamics in selecting analytical models according to the data sets at runtime, handling exceptions to make long running workflows reliable, and reducing large volumes of data to a suitable form for visualization. To address such needs, this paper describes an architecture-based service oriented framework to compose adaptation techniques into a scientific workflow. This framework allows the workflow to change itself (in structure or in behavior) according to its context, and thus enhances the efficiency, extensibility and reliability of large scale, long running scientific workflows. The current solution assumes the workflow is independent and stateless. Our on-going work is to further evaluate the solution with stateful and dependent workflows.

[10]

[11]

[12]

[13]

[14]

Anis Charfi, Tom Dinkelaker, and Mira Mezini. 2009. A Plug-in Architecture for Self-Adaptive Web Service Compositions. In Proceedings of the 2009 IEEE International Conference on Web Services (ICWS '09). IEEE Computer Society, Washington, DC, USA, 35-42. Gorton, I.; Wynne, A.; Yan Liu; Jian Yin; , "Components in the Pipeline," Software, IEEE , vol.28, no.3, pp.34-40, MayJune, 2011. Adam Barker and Jano van Hemert. Scientific workflow: A survey and research directions. Parallel Processing and Applied Mathematics, volume 4967 of Lecture Notes in Computer Science, chapter 78, pages 746753. Springer Berlin Heidelberg, 2008. Bertram Ludascher, Ilkay Altintas, Chad Berkley, Dan Higgins, Efrat Jaeger, Matthew Jones, Edward A. Lee, Jing Tao, and Yang Zhao. 2006. Scientific workflow management and the Kepler system: Research Articles. Concurr. Comput. : Pract. Exper. 18, 10 (August 2006), 1039-1065. D. Hull, K. Wolstencroft, R. Stevens, C. Goble, M. Pocock, P. Li, and T. Oinn, Taverna: a tool for building and running workflows of services., Nucleic Acids Research, vol. 34, iss. Web Server issue, pp. 729-732, 2006. OASIS. BPEL web site. http://www.oasisopen.org/committees/wsbpel/ Kephart, J.O.; Chess, D.M.; , "The vision of autonomic computing," Computer , vol.36, no.1, pp. 41- 50, Jan 2003 doi: 10.1109/MC.2003.1160055 Betty H. Cheng, et al. Software Engineering for Self-Adaptive Systems: A Research Roadmap. In Software Engineering for Self-Adaptive Systems, Betty H. Cheng, Rogrio Lemos, Holger Giese, Paola Inverardi, and Jeff Magee (Eds.). Lecture Notes In Computer Science, Vol. 5525. Springer-Verlag, Berlin, Heidelberg 1-26, 2008. Taylor, R.N.; Medvidovic, N.; Oreizy, P.; , "Architectural styles for runtime software adaptation," Software Architecture, 2009 & European Conference on Software Architecture. WICSA/ECSA 2009. Joint Working IEEE/IFIP Conference on , vol., no., pp.171-180, 14-17 Sept. 2009 Liu, Y.; Babar, M.A.; and Gorton, I., "Middleware Architecture Evaluation for Dependable Self-managing Systems", in Proc. QoSA, 2008, pp.189-204. Liu, Y.; Gorton, I.; , "Implementing Adaptive Performance Management in Server Applications," Software Engineering for Adaptive and Self-Managing Systems, 2007. ICSE Workshops SEAMS '07. International Workshop on , vol., no., pp.12, 20-26 May 2007 Ning Lu; Taylor, T.; Wei Jiang; Chunlian Jin; Correia, J.; Leung, L.R.; Pak Chung Wong; , "Climate Change Impacts on Residential and Commercial Loads in the Western U.S. Grid," Power Systems, IEEE Transactions on , vol.25, no.1, pp.480-488, Feb. 2010 Chih-Han Yu and Radhika Nagpal. 2011. A Self-adaptive Framework for Modular Robots in a Dynamic Environment: Theory and Applications. Int. J. Rob. Res. 30, 8 (July 2011), 1015-1036. Hayashibara, N.; Defago, X.; Yared, R.; Katayama, T.; , "The accrual failure detector," Reliable Distributed Systems, 2004. Proceedings of the 23rd IEEE International Symposium on , vol., no., pp. 66- 78, 18-20 Oct. 2004

314