In this paper we present an architecture for enabling complex workflow execution in Cloud-like environments. We focus mainly on modeling concepts and techniques to enhance accessibility to Cloud services by different kind of users. Complex workflow tasks need in some cases to be mapped to distributed resources and involves the cooperation between several partners. Workflow management is critical to a successful long-term Cloud computing strategy. The notion of inter-organizational workflow still needs conceptual and technical support especially in complex and dynamic environments like Clouds. New ways to tackle this problem have to be found. Therefore, existing workflow architectures need to be adapted for the Cloud and workflow management systems (WfMS) should be integrated with Cloud infrastructure and resources [3]. In this paper we use Inter-Cloud Workflow Petri Nets (ICWPN), an approach for enabling workflows in an (Inter)-Cloud environment. A specialized Cloud Task Transition (CTT) is introduced to facilitate the connection to the Cloud and to support Quality of Service (QoS) management [1]. The CTT (see Fig. 1 (a)) is based on the Workflow Task Transition [2], which is the core of the workflow net formalism in Renew1 (Reference Net Workshop). Workflow modelers specify their requirements as parameters to the CTT in form of tuples (S, Q, I), which correspond respectively to the Cloud service (S) that they want to use (it can be a storage or a compute service), the QoS constraints (Q) consisting of deadlines or costs and input data (I) consisting either of required files in case of a storage or scripts if they want to execute their codes on the Cloud. Synchronous channels are used to make the connection with the WfMS, which controls the completion of the task. It either initiates the firing or cancels it and all input parameters are put back onto the input places. To see how the CTT is used in practice, we introduce a Cloud-based workflow architecture, it is depicted in Fig. 1 (b). It includes three basic layers from top to bottom: user applications layer (UL), middle-ware layer (ML) and the resource layer (RL), which consits mainly of Cloud services. In our approach we view the process of executing an application in an Inter-Cloud environment as a 6-phase process: (1) Users use the offered modeling tools consisting mostly of Renew and the introduced CTT to specify the requirements (Cloud services, QoS constraints, specific input data) for their applications using Petri nets models. (2) 1 Renew is available at http://www.renew.de
ModBE’13 – Modeling and Business Environments (a) The Cloud Transition
(b) General Cloud Workflow Architecture
A list of requirements is created consisting of required services as well as their
related QoS constraints. (
Here we focused primarily on Cloud technologies. Nevertheless, the introduced model (see Fig. 1(b)) can be also applicable to other dynamic domains where distributed resources are shared and dynamically allocated and usually priced.