This paper introduces the idea of distributed orchestration of user interfaces (UIs), an application development approach that allows us to easily bring together UIs, web services, and people in a single orchestration logic, language, and tool. The tool is called MarcoFlow, and it covers three main phases of the software development lifecycle: design (by means of a dedicated, visual editor), deployment (by means of a set of code generators), and execution (by means of a distributed runtime environment for UI orchestrations). MarcoFlow targets the development of mashup-like applications that require (distributed) process support and, hence, targets researchers and practitioners interested in mashups, lightweight process design, web services, and innovative (and free) ways of providing process support.
After workflow management (which supports the automation of business processes
and human tasks) and service orchestration (which focuses on web services at the
application layer), web mashups [
This demo complements the concepts and solutions introduced in [
Challenges and contributions. Developing distributed UI orchestrations implies the coordination of individual actors and the development of a distributed user interface and service orchestration logic. Doing so requires (i) understanding how to componentize UIs and compose them into web applications, (ii) defining a logic that is able to orchestrate both UIs and web services, (iii) providing a language and tool for specifying distributed UI compositions, and (iv) developing a runtime environment that is able to execute distributed UI and service compositions.
Innovativeness of the tool. As of today, there is no single development instrument
that answers these challenges and allows one to develop UI orchestrations using one
language and one environment only. BPEL [
Significance to the BPM field. With MarcoFlow, we go one step beyond state-ofthe-art BPM and service composition and propose an original model, language and running system for the composition of distributed UIs. The approach brings together UIs, web services and people in a single orchestration logic and tool and supports the development of mashup-like applications that require (distributed) process support, a kind of application that so far was not supported by BPM practices and software.
The key idea to approach the coordination of (i) UI components inside web pages, (ii)
web services providing data or application logic, and (iii) individual pages (as well as
the people interacting with them) is to split the coordination problem into two layers:
intra-page UI synchronization and distributed UI synchronization and web service
orchestration. UIs are typically event-based (e.g., user clicks or key strokes), while
service invocations are coordinated via control flows. In this demo and in [
Figure 1 shows the simplified meta-model of BPEL4UI. Specifically, the figure
details all the new modeling constructs necessary to specify UI orchestrations
(grayshaded) and omits details of the standard BPEL language, which are reused as is by
BPEL4UI. In terms of standard BPEL [
faultHandlers
Name 1..1 accessibleTo 0..*
Name 0..* Description TemplateURL UIEngineName isStartPage
1c..o1ntai1n.s.* NaPmla1e.c.1eHroelnddeerredIn 1..1
Name 0..1 describedBy 1..1
WSDL-UI
has NaPmreoperty 1..1 0..* Value
Type partner links, while partner link types define the roles played by each of the services or UI components in the conversation and the port types specifying the operations and messages supported by each service or component.
Modeling UI-specific aspects requires instead introducing a set of new constructs that are not yet supported by BPEL. The constructs, illustrated in Figure 1, are: UI type (the partner link type for UI components), page (the web pages over which we distribute the UI of the application), place holder (the name of the place holders in which we can render UI components), UI component (the partner link for UI components), property (the constructor parameters of UI components), and actor (the human actors we associate with web pages).
It is important to note that although syntactically there is no difference between
web services and UI components (the new JavaScript binding introduced into WSDL
to map abstract operations to concrete JavaScript functions comes into play only at
runtime), it is important to distinguish between services and UI components as their
semantics and, hence, their usage in the model will be different. A detailed
description of the new constructs and their usage can be found in [
As for the layout of distributed UI orchestrations, defining web pages and associating UI partner links with place holders requires implementing suitable HTML templates that are able to host the UI components of the orchestration at runtime. For the design of layout templates we rely on standard web design instruments. The only requirement the templates must satisfy is that they provide place holders in form of HTML DIV elements that can be indexed via standard HTML identifiers following a predefined naming convention, i.e., <div id=“marcoflow-left”>… </div>.
The main methodological goals in implementing our UI orchestration approach were (i) relying as much as possible on existing standards, (ii) providing the developer with only few and simple new concepts, and (iii) implementing a runtime architecture that associates each concern to the right level of abstraction and software tool (e.g., UI synchronization is handled in the browser, while service orchestration is delegated to the BPEL engine).
Document flows System/human communications
Automatically generated elements
configurator
developer
templates
B
JS via HTTP
UUUIIeIenengngigninieneecclcileileinentnt(t(ww(weebebbbbrbroorwowwsseserer))r) UI compAonent container B C
System components
Notificaatitoionn NNootitfiifcication
handler hahnadndlelersr Evenntt
EEvveent fofrofowrrwawraadrreddreesrr JSON via JSON via HTTP HTTP
Layout and BPEL2UI UI2BPEL UI logic communication communication
UI composition
Evenntt EEvveent bpuprfrofoexxryy
Evenntt EEvveent pprproroxoxyxyy
XML via SOAP XML via SOAP XML via SOAP
between the UI components in the client browser and the BPEL engine; (ii) a standard BPEL specification containing the distributed UI synchronization and web service orchestration logic; and (iii) a set of UI compositions (one for each page of the application) containing the intra-page UI synchronizations. This task is achieved by the BPEL4UI compiler, which also manages the deployment of the generated artifacts in the respective runtime environments.
The execution of a UI orchestration requires the setup and coordination of three independent runtime environments: (i) the interaction with users and intra-page UI synchronization is managed in the client browser by an event-based JavaScript runtime framework; (ii) a so-called UI engine server runs the web services implementing the communication channels; and (iii) a standard BPEL engine manages the distributed UI synchronization and web service orchestration.
The MarcoFlow system shown in Figure 2 is fully implemented and running. A patent application for parts of the system has been filed.
An example of how MarcoFlow can be used for the development of a distributed UI orchestration is available at http://mashart.org/marcoflow/demo.htm. The demo in form of a video illustrates in few minutes the main features of MarcoFlow in the context of a simple home assistance management application. Particular emphasis is given to the three development phases supported by the tool (design, deployment, and runtime) and to the use of the final application by the different actors involved in the distributed process logic.