SCC: A Service Centered Calculus

We seek for a small set of primitives that might serve as a basis for formalising and programming service oriented applications over global computers. As an outcome of this study we introduce here SCC, a process calculus that features explicit notions of service definition, service invocation and session handling. Our proposal has been influenced by Orc, a programming model for structured orchestration of services, but the SCC’s session handling mechanism allows for the definition of structured interaction protocols, more complex than the basic request-response provided by Orc. We present syntax and operational semantics of SCC and a number of simple but nontrivial programming examples that demonstrate flexibility of the chosen set of primitives. A few encodings are also provided to relate our proposal with existing ones

A Calculus for Orchestration of Web Services

We introduce COWS (Calculus for Orchestration of Web Services), a new foundational language for SOC whose design has been influenced by WS-BPEL, the de facto standard language for orchestration of web services. COWS combines in an original way a number of ingredients borrowed from well-known process calculi, e.g. asynchronous communication, polyadic synchronization, pattern matching, protection, delimited receiving and killing activities, while resulting different from any of them. Several examples illustrates COWS peculiarities and show its expressiveness both for modelling imperative and orchestration constructs, e.g. web services, flow graphs, fault and compensation handlers, and for encoding other process and orchestration languages

Resilient store: a heuristic-based data format selector for intermediate results

The final publication is available at link.springer.comLarge-scale data analysis is an important activity in many organizations that typically requires the deployment of data-intensive workflows. As data is processed these workflows generate large intermediate results, which are typically pipelined from one operator to the following. However, if materialized, these results become reusable, hence, subsequent workflows need not recompute them. There are already many solutions that materialize intermediate results but all of them assume a fixed data format. A fixed format, however, may not be the optimal one for every situation. For example, it is well-known that different data fragmentation strategies (e.g., horizontal and vertical) behave better or worse according to the access patterns of the subsequent operations. In this paper, we present ResilientStore, which assists on selecting the most appropriate data format for materializing intermediate results. Given a workflow and a set of materialization points, it uses rule-based heuristics to choose the best storage data format based on subsequent access patterns.We have implemented ResilientStore for HDFS and three different data formats: SequenceFile, Parquet and Avro. Experimental results show that our solution gives 18% better performance than any solution based on a single fixed format.Peer ReviewedPostprint (author's final draft

CaSPiS: A Calculus of Sessions, Pipelines and Services

Service-oriented computing is calling for novel computational models and languages with well disciplined primitives for client-server interaction, structured orchestration and unexpected events handling. We present CaSPiS, a process calculus where the conceptual abstractions of sessioning and pipelining play a central role for modelling service-oriented systems. CaSPiS sessions are two-sided, uniquely named and can be nested. CaSPiS pipelines permit orchestrating the flow of data produced by different sessions. The calculus is also equipped with operators for handling (unexpected) termination of the partner’s side of a session. Several examples are presented to provide evidence of the flexibility of the chosen set of primitives. One key contribution is a fully abstract encoding of Misra et al.’s orchestration language Orc. Another main result shows that in CaSPiS it is possible to program a “graceful termination” of nested sessions, which guarantees that no session is forced to hang forever after the loss of its partner

Organizational factors associated with readiness to implement and translate a primary care based telemedicine behavioral program to improve blood pressure control: the HTN-IMPROVE study

Abstract Background Hypertension is prevalent and often sub-optimally controlled; however, interventions to improve blood pressure control have had limited success. Objectives Through implementation of an evidence-based nurse-delivered self-management phone intervention to facilitate hypertension management within large complex health systems, we sought to answer the following questions: What is the level of organizational readiness to implement the intervention? What are the specific facilitators, barriers, and contextual factors that may affect organizational readiness to change? Study design Each intervention site from three separate Veterans Integrated Service Networks (VISNs), which represent 21 geographic regions across the US, agreed to enroll 500 participants over a year with at least 0.5 full time equivalent employees of nursing time. Our mixed methods approach used a priori semi-structured interviews conducted with stakeholders (n = 27) including nurses, physicians, administrators, and information technology (IT) professionals between 2010 and 2011. Researchers iteratively identified facilitators and barriers of organizational readiness to change (ORC) and implementation. Additionally, an ORC survey was conducted with the stakeholders who were (n = 102) preparing for program implementation. Results Key ORC facilitators included stakeholder buy-in and improving hypertension. Positive organizational characteristics likely to impact ORC included: other similar programs that support buy-in, adequate staff, and alignment with the existing site environment; improved patient outcomes; is positive for the professional nurse role, and is evidence-based; understanding of the intervention; IT infrastructure and support, and utilization of existing equipment and space. The primary ORC barrier was unclear long-term commitment of nursing. Negative organizational characteristics likely to impact ORC included: added workload, competition with existing programs, implementation length, and limited available nurse staff time; buy-in is temporary until evidence shows improved outcomes; contacting patients and the logistics of integration into existing workflow is a challenge; and inadequate staffing is problematic. Findings were complementary across quantitative and qualitative analyses. Conclusions The model of organizational change identified key facilitators and barriers of organizational readiness to change and successful implementation. This study allows us to understand the needs and challenges of intervention implementation. Furthermore, examination of organizational facilitators and barriers to implementation of evidence-based interventions may inform dissemination in other chronic diseases.http://deepblue.lib.umich.edu/bitstream/2027.42/112820/1/13012_2013_Article_683.pd

NOW: Orchestrating services in a nomadic network using a dedicated workflow language

AbstractOrchestrating services in nomadic or mobile ad hoc networks is not without a challenge, since these environments are built upon volatile connections. Services residing on mobile devices are exposed to (temporary) network failures, which must be considered the rule rather than the exception. This paper proposes a dedicated workflow language built on top of an ambient-oriented programming language that supports dynamic service discovery and communication primitives resilient to network failures. The proposed workflow language, NOW, has support for high level workflow abstractions for control flow, rich network and service failure detection, and failure handling through compensating actions, and dynamic data flow between the services in the environment. By adding this extra layer of abstraction, the application programmer is offered a flexible way to develop applications for nomadic networks

Monotony in Service Orchestrations

Web Service orchestrations are compositions of different Web Services to form a new service. The services called during the orchestration guarantee a given performance to the orchestrater, usually in the form of contracts. These contracts can be used by the orchestrater to deduce the contract it can offer to its own clients, by performing contract composition. An implicit assumption in contract based QoS management is: "the better the component services perform, the better the orchestration's performance will be". Thus, contract based QoS management for Web services orchestrations implicitly assumes monotony. In some orchestrations, however, monotony can be violated, i.e., the performance of the orchestration improves when the performance of a component service degrades. This is highly undesirable since it can render the process of contract composition inconsistent. In this paper we define monotony for orchestrations modelled by Colored Occurrence Nets (CO-nets) and we characterize the classes of monotonic orchestrations. We show that few orchestrations are indeed monotonic, mostly since latency can be traded for quality of data. We also propose a sound refinement of monotony, called conditional monotony, which forbids this kind of cheating and show that conditional monotony is widely satisfied by orchestrations. This finding leads to reconsidering the way SLAs should be formulated

Slicing for architectural analysis

Current software development often relies on non trivial coordination logic for combining autonomous services, eventually running on different platforms. As a rule, however, such a coordination layer is strongly weaved within the application at source code level. Therefore, its precise identification becomes a major methodological (and technical) problem and a challenge to any program understanding or refactoring process. The approach introduced in this paper resorts to slicing techniques to extract coordination data from source code. Such data is captured in a specific dependency graph structure from which a coordination model can be recovered either in the form of an Orc specification or as a collection of code fragments corresponding to the identification of typical coordination patterns in the system. Tool support is also discussed.Fundação para a Ciência e a Tecnologia (FCT) - projeto Mondrian, PTDC/EIA-CCO/108302/200