This paper presents a novel approach to inter-organizational workflow cooperation. Our goal is to provide support for organizations which are involved in a sharedAbstract. This paper presents a novel approach to inter-organizational workflow cooperation. Our goal is to provide support for organizations which are involved in a shared but not pre-modeled cooperative workflow across organizational boundaries. Our approach allows for partial visibility of workflows and their resources, thus providing powerful ways for inter-organizational workflow configuration. Varying degrees of visibility of workflows enable organizations to retain required levels of privacy and security of internal workflows. Our presented view concept provides a high degree of flexibility for participating organizations, since internal structures of collaborative workflows may be adapted without changes in the inter-organizational workflows. Furthermore, we provide workflow participants with the freedom to change their workflows without changing their roles in the cooperation. This increases flexibility and is an important step to increase efficiency as well as reduction in costs for inter-organizational workflows. The presented approach is inspired by the Service-oriented Architecture (SOA). Accordingly, our approach consists of three steps: workflow advertisement, workflow interconnection, and workflow cooperation.

The study we have conducted of existing cloud platforms shows that their operating requires the use of specific and proprietary APIs. This PaaS providers' policy is hampering the interactions between different clouds. If appropriate solutions are not considered, this issue would for instance slow down the democratization of clouds federation and cooperation. In this paper, we propose (i) a unified description model that allows the representation of applications independently of the targeted PaaS for their hosting and (ii) a generic PaaS application provisioning and management API (called COAPS API). Our proposed solution applies the separation of concerns principle by separating the provisioning and the management API from the defined description model. We motivate our solution with real use case scenarios and an implementation to show its feasibility.

No abstract