When orchestrating highly distributed and data-intensive Web service workflows the geographical placement of the orchestration engine can greatly affect the overall performance of a workflow. Orchestration engines are typically run from within an organisations' network, and may have to transfer data across long geographical distances, which in turn increases execution time and degrades the overall performance of a workflow. In this paper we present CloudForecast: a Web service framework and analysis tool which given a workflow specification, computes the optimal Amazon EC2 Cloud region to automatically deploy the orchestration engine and execute the workflow. We use geographical distance of the workflow, network latency and HTTP round-trip time between Amazon Cloud regions and the workflow nodes to find a ranking of Cloud regions. This combined set of simple metrics effectively predicts where the workflow orchestration engine should be deployed in order to reduce overall execution time. We evaluate our approach by executing randomly generated data-intensive workflows deployed on the PlanetLab platform in order to rank Amazon EC2 Cloud regions. Our experimental results show that our proposed optimisation strategy, depending on the particular workflow, can speed up execution time on average by 82.25 compared to local execution. We also show that the standard deviation of execution time is reduced by an average of almost 65 using the optimisation strategy.
@cite_4: Web services make information and software available programmatically via the Internet and may be used as building blocks for applications. A composite web service is one that is built using multiple component web services and is typically specified using a language such as BPEL4WS or WSIPL. Once its specification has been developed, the composite service may be orchestrated either in a centralized or in a decentralized fashion. Decentralized orchestration offers performance improvements in terms of increased throughput and scalability and lower response time. However, decentralized orchestration also brings additional complexity to the system in terms of error recovery and fault handling. Further, incorrect design of a decentralized system can lead to potential deadlock or non-optimal usage of system resources. This paper investigates build time and runtime issues related to decentralized orchestration of composite web services. We support our design decisions with performance results obtained on a decentralized setup using BPEL4WS to describe the composite web services and BPWS4J as the underlying runtime environment to orchestrate them.
@cite_2: As computer systems grow in size and complexity, their integration, while a necessity, becomes more difficult. Service oriented architectures and middleware systems in general deal with the issue by decoupling the components. However, these architectures are still designed and enacted from a centralised perspective: a single process invokes remote services, unaware of being part of a larger, more complex workflow. We claim that the orchestration-based approach does not scale well with increasing complexity and heterogeneity of the components, such as those required in the enactment of medical guidelines and workflows. Medical guidelines encode different aspects of a medical procedures, and they specify different level of abstraction in the procedure. They have to be adapted to the realities of different clinics and hospitals, to advances in knowledge, and to the changing of available resources within an institution. We address the problem of representing and enacting medical guidelines using a fully distributed approach. The framework provided by OpenKnowledge, based on sharing choreographies among actors, allows the representation and enactment of the coordination aspect of guidelines and the discovery of the medical knowledge provided by the distributed actors.
@cite_6: 
@cite_11: Utility grids such as the Amazon EC2 cloud and Amazon S3 offer computational and storage resources that can be used on-demand for a fee by compute and data-intensive applications. The cost of running an application on such a cloud depends on the compute, storage and communication resources it will provision and consume. Different execution plans of the same application may result in significantly different costs. Using the Amazon cloud fee structure and a real-life astronomy application, we study via simulation the cost performance tradeoffs of different execution and resource provisioning plans. We also study these trade-offs in the context of the storage and communication fees of Amazon S3 when used for long-term application data archival. Our results show that by provisioning the right amount of storage and compute resources, cost can be significantly reduced with no significant impact on application performance.
In previous work @cite_6 @cite_11 we proposed , a proxy-based architecture based on a centralised control flow, distributed data flow model. Our prior work @cite_2 has also focused on decentralised service choreography models. @cite_4 , an architecture for of composite Web services defined in BPEL is proposed.