Distributed Workflows: The OpenKnowledge
Experience
Paolo Besana1, Vivek Patkar2, David Glasspool1, and Dave Robertson1
1 University of Edinburgh
2 UCL Department of Oncology
Abstract. Software systems are becoming ever more complex, and one
source of complexity lies in integrating heterogeneous subsystems. Ser-
vice Oriented Architectures are part of the answer: they decouple the
components of the system. However normally SOA is used from a cen-
tralised perspective: a single process invokes remote services, unaware of
being part of a workflow. We claim that the centralised, or orchestration-
based, approach cannot scale well with increasing complexity and
heterogeneity of the components, and we propose an alternative distrib-
uted, or choreography-based, approach, that forces developers to think
in terms of actors, roles and interactions. We first present the Open-
Knowledge framework, designed according to choreography-based prin-
ciples and then show how a complex, distributed model for managing the
triple assessment of patients suspected with breast cancer can be easily
implemented using this framework.
1 Introduction
Software systems are getting more and more complex. An important source of the
complexity is the need to integrate different, heterogeneous subsystems. Service
oriented architectures decouple the components of complex systems: every com-
ponent exposes services that are accessible through the network using standard
methods. Decoupling is a good software engineering practice, as it reduces the in-
terdependencies between components and, if well designed, simplifies reusability
of the services in different systems.
Complex systems can be pulled together, invoking services belonging to dif-
ferent and possibly external systems using workflow languages like BPEL or
YAWL. These framework are based on a centralised, imperative paradigm: a
central process controls everything, and the other services are passive, unaware
of being part of a workflow.
We claim that this approach does not scale well with the growing complex-
ity of systems: we advocate a different paradigm, based on the choreography of
actors. We believe that the design of systems can gain from this paradigm, inde-
pendent of the deployment technique. In fact, the choreography paradigm forces
the developers to think in terms of the actors, their roles and their interactions
in complex scenario, making them explicit.
R. Meersman, Z. Tari, and P. Herrero (Eds.): OTM 2008 Workshops, LNCS 5333, pp. 965–975, 2008.
c
© Springer-Verlag Berlin Heidelberg 2008

966 P. Besana et al.
The OpenKnowledge1 project has allowed us to developed a fully distributed,
peer-to-peer framework, focussed on shared interaction models that are executed
by peers. Based on this framework, we have tested the paradigm in different sce-
narios of varying level of heterogeneity and complexity. In this paper we will
focus on a choreography-based implementation, based on the OpenKnowledge
framework, of the assessment procedure followed by a patient suspected of breast
cancer. In Section 2 we explain our claims about the choreography-based archi-
tecture, at the core of the OpenKnowledge project, presented in Section 3. In
Section 4 we describe the triple assessment scenario, comparing the centralised
and the distributed models. Finally, in Section 5 we show how we applied the
OpenKnowledge framework to the assessment scenario.
2 Choreography- and Orchestration-Based Architectures
Our claim, as stated in the introduction, is that a choreography-based archi-
tecture forces the developers to think distributed applications from a different
perspective that scales better with an increasing number of interacting actors.
A distributed application becomes an set of interactions between actors that
take different roles. The paradigm is independent from actual implementation
and deployment: the implementation can be a complete peer-to-peer, fully open
architecture, or a more traditional, closed architecture where every component
is certified, and deployed by certified administrator, or it can be something in
between. What is different is how the application is conceived, and the type of
middleware that connects the pieces.
For example, an online pharmacy that provides a service for buying prescribed
drugs can be designed using an orchestration-based language such as YAWL [10]
or using a choreography-based approach. Figure 1 shows a YAWL workflow for
the service. It runs as a central process started by the reception of a request from
a customer. The process invokes a remote service for verifying the prescription,
invokes another remote service for ordering the delivery of the drug and calls
another service for charging the cost (it can be the national health service, a
private insurance or a direct payment system). The roles are implicit: the fo-
cus is on the flow of activities. Figure 2 shows a distributed workflow for the
same application: it focuses on the actors’ roles and on their interaction. The
choreography-based approach forces us to analyse more explicitly the domain of
the problem. In writing this simple example, I quickly found out that I needed
to specify the ID of doctor to contact, and the ID of the funding body. Thinking
about this, it was evident that the information was connected to the customer
ID. The same information could be obviously defined in the orchestration-based
architecture, but because the roles are implicit, the analysis is independent from
the representation.
The choreography model, especially if implemented with an open, peer-to-peer
architecture, requires designers to address issues of heterogeneity and brokering.
Peers are likely to be different and they need to understand each other. The
1 www.openk.org