Ubiquitous Computing is considered as enabler for linking everyday life with information and communication technology. However, developing pervasive applications that provide personalized user assistance is still a challenge. Relevant scenarios are diverse and encompass domains like healthcare, logistics, and business collaboration. Two of the technologies that show increasing maturity in respect to the demands of such applications are light-weight frameworks and process engines for mobile computing. Their fusion, however, is in a rather premature state. Generally, the support of mobile collaboration using a process engine raises challenging issues that need to be addressed. In the MARPLE project we target at a tight integration of process management technology with mobile computing frameworks in order to enable mobile process support in the aforementioned scenarios. In this demo paper we give insights into the MARPLE architecture and its components. In particular, we introduce the MARPLE process engine which enables light-weight as well as exible process support on mobile devices.
Mobile assistance in daily life as empowered by information and communication technology is a much discussed topic. To better understand the challenges emerging in this context, we analyzed real-world scenarios in which mobile user assistance is urgently needed and which stem from domains like healthcare, logistics and business collaboration. In particular, our analyses revealed the fundamental role of process support in respect to mobile and personalized user assistance. This paper picks up a healthcare scenario in which chronically ill patients shall be assisted by mobile devices. Such mobile device gives recommendations in respect to medications. These recommendations, in turn, are made remotely by healthcare professionals and depend on the previously gathered patient data (e.g. blood pressure). Despite its high potential, so far there exists no comprehensive mobile assistance for such scenarios. One issue emerging in the given context is to decide which process parts shall run on mobile devices and which on stationary computers. In the following we refer to the described scenario to discuss fundamental challenges and to show the high potential of mobile assistance. Fig. 1 illustrates both traditional realization of this scenario 1 and its realization based on mobile devices and mobile assistance respectively 2 .
Patient Treatment (as abstract process)
A Realization After discharging a patient the usual way to monitor his health status is to schedule regular visits for him in the clinic. In certain cases, however, this can lead to delayed adaptations of his treatment plan in case his status has changed. To improve this situation and to enable real-time monitoring, mobile data collection and mobile assistance 2 of the patient would be highly welcome by all parties; i.e., the patient needs to be assisted by a mobile device which gathers medical data from him and informs clinicians about status changes. To realize the second scenario patient-speci c application logic needs to be provided on the mobile device. Consequently, the overall treatment work ow is maybe partitioned 2 and process fragments may run on stationary computers as well as on mobile devices. In particular, the process fragment running on the mobile device needs to be adapted to the speci c patient and may evolve over time, i.e., hard-coded process implementations are not tolerable. To enable mobile assistance we developed a light-weight process engine called MARPLE that runs on the mobile device and that is able to interact with backend processes if required. In addition, we provide advanced tools for de ning, con guring and verifying process fragments. In this paper, we focus on the core architecture and components of the MARPLE mobile process engine. Conceptual issues related to the partitioning of processes as well as to the synchronization of the resulting fragments are outside the scope of this paper.
When developing our MARPLE engine we had one shining example to follow
- the ADEPT process management system we had developed during the last
decade [
Section 2 introduces a concrete application scenario. In Section 3 we give insights into the MARPLE architecture, while Section 4 shows how the described scenario can be supported in MARPLE. Section 5 discusses related work and Section 6 concludes with a summary and outlook.
Let us consider the process 3 to be run on the mobile device of the patient in more detail: While the patient stays at home, he rst gets a message through his mobile device. Then he measures and collects the requested data being assisted by the process running on his mobile device. Following this, results 4 are sent back to the clinic which then decides 5 about next steps. Ideally no special actions are required. In this case a message is sent back to the patient's mobile device containing information about his medication 6 . Alternatively, the clinic may send a message with information about further treatment or special treatment to home care 7 (either provided by a professional service or a relative of the patient). In the latter case, an additional process fragment is started on the mobile device of the person who is responsible for home care. This process has to be synchronized with the process with the one running on the patient's mobile device. Finally, either the process running on the mobile device of home care or the one running on the mobile device of the patient sends back a report 9 to the clinic. Then the process is nished.
Altogether the process fragments of three parties need to be synchronized. Thereby, the runtime infrastructure must be able to cope with communication problems, device failures and so forth. In Fig. 2 the pictograms with label DS and NS indicate a Network Switch or Device Switch within the overall process choreography. Assume that the mobile device of the patient or its connection with the clinic fail. Then the clinic has now knowledge about the status of the patient, but only has the information that the network connection has broken. Such failure scenarios must be covered by the architecture. In particular, the following requirements need to be met by a supporting infrastructure: { It must be possible to partition a process model and to allocate the resulting fragments on mobile devices as well as stationary computers. { Soundness of the process (i.e., the process choreography) needs to be ensured. { The runtime infrastructure has to cope with physical problems like broken connections or malfunctioning devices. { When running the fragments on distributed devices their execution must be synchronized and messages be exchanged in a reliable way. { Both the overall process model as well as its fragments might have to be adapted during runtime, e.g. to deal with exceptional situations. { A mobile process must be able to gather sensoric data during its execution. 3
In this section we give insights into the MARPLE architecture (cf. Fig. 3). Its two core components are the MARPLE Mobile Process Engine V1.3 and the MARPLE Mediation Center. Here we focus on those parts of the MARPLE architecture that are relevant in the context of our application scenario. Other components and features of MARPLE are only mentioned shortly and will be subject of future publications.
.NET 3.5 / WPF
MAINTENANCE o CONFIGURE PDA o INSTALL ENGINE
DESIGN oo CMOONDFEILGURATION o TESTING o SIMULATE
CONTROL oo AASDSHIOGCNDPERVOICATEISOSNES o PROCESS MIGRATION o PROCESS
MONITORING
REPOSITORY oo PPDRAOCCEOSNSFTIGEUMRPALTAITOENS o ACTIVITY TEMPLATES o INSTANCE DATA MARPLE MEDIATION CENTER
XML PERSISTENCE MANAGER .NET CF 3.5
MOBILE PROCESS ENGINE V1.3
CORE COMMUNICATION SERVICE (CCS) DEVIATION SERVICE
MARPLE MOBILE DEVICE
Current Version: 1.3
LOC: 48t
If a mobile device shall be added to the MARPLE environment, it rst needs to
be equipped with the basic software services required in the MARPLE context.
Amongst others this includes Core Communication Services (CCS) as part of
the MARPLE Mobile Process Engine V1.3. Thereby, we follow a light-weight
approach; i.e., services that are initially not needed are not loaded to the device.
Following this, the mobile device can connect to the MARPLE Mediation
Center and indicate that its con guration may start. When starting the MARPLE
con guration procedure on the mobile device through the MARPLE Mediation
Center, CCS dynamically loads the MARPLE Mobile Process Engine V1.3, the
MARPLE XML Persistence Manager, and the relevant process as well as
Activity Templates to this device. In this context, Activity Templates encapsulate
pre-manufactured application components that implement the process steps. In
MARPLE, for example, activity templates can be associated with a user forms
or a (remote) web service call. Regarding our example from Section 2, in process
step 7 a report is sent from the patient's mobile process to the clinic. When
realizing the MARPLE Mobile Process Engine V1.3, we re-use fundamental concepts
and design principles of the ADEPT process management technology, which we
developed during the last decade [
Despite these commonalities with ADEPT it is noteworthy that we provide a complete new implementation of the kernel of the MARPLE Mobile Process Engine V1.3 in order to meet performance requirements of mobile scenarios and to cope with their speci c requirements (e.g., broken connections and limited GUIs). In particular, the implementation framework MARPLE is based on is not the same as the one used in the context of ADEPT. While ADEPT relies on JAVA, our MARPLE architecture is based on .NET Compact Framework. The MARPLE Mediation Center consists of four major parts. First, its Maintenance component allows us to con gure mobile devices such that they can be used for mobile process support. Second, the Control Unit enables users to assign executable processes to mobile devices, to enact them on the mobile device, to invoke user forms or web services during process execution, and to apply ad-hoc deviations from the pre-modeled process logic.
Another fundamental feature of the MARPLE Control Unit is its ability to migrate running process instances from one mobile device to another (e.g., if a patient wants to switch his device). Like ad-hoc changes such process migration can be initiated by the owner of the mobile device as well as by authorized users via the Control Unit. Another important component of the MARPLE Mediation Center is its Modeler. This component adopts basic correctness principles we developed in ADEPT, but provides additional features for partitioning processes and for specifying conceptual models for mobile processes. Consider again our example from Section 2. Using MARPLE Modeler, the fragment representing the data collection process (see Lane 3 ) can be de ned. The same holds for the process fragment relating to home care. All meta data (e.g., PDA con gurations) needed by the di erent components of the MARPLE architecture are maintained in the Repository of the MARPLE Mediation Center. Fig. 4 exemplarily illustrates the interaction between the MARPLE Mediation Service and two mobile devices: Initially, only one mobile device is involved in the interaction. Then a second device is added. Following this, the process instance running on the rst mobile device is migrated to the newly introduced one (e.g., due to connection problems with the rst device or better technical features of the new one). Note that this migration can be triggered either by the MARPLE Mediation Center or by the owners of the two devices. During process executions, the Control Unit may suspend, resume, abort and monitor running processes. Further, the MARPLE Mobile Process Engine V1.3 logs progress of the process using the Persistence Manager.
PDA 2
PDA 1 foreach n in Nodes I1 updateState (n) Suspend, Migrate,
Abort MARPLE Mediation Service send: #1 InstanceTemplate I1 (XML) (including workflow sequence and data elements) #2 ActivityTemplates
for each (n in Nodes I1) { #3 P}DAL-PoarodfAilectivityTemplate (n) (Security Aspects, User Aspects,
Environment Aspects) after every finished step, the status of the data elements of the whole process are made persistent
Online sendTemplate (T1)
InstanceStarted (I1) foreach (n in Nodes I1) { } RunActivity(n); I1
InstanceMigrated (I1)
Instance I1 finished
InstanceMigrationDeclined foreach n in Nodes I1 updateState (n) Suspend, Migrate,
Abort
Instance I1 finished
available
migrateInstance (I1)
acknowledge
sendInstance (I1)
I1
foreach (n in Nodes I1) {
} RunActivity(n);
We revisit our scenario from Section 2 and show how it can be realized using
MARPLE. Fig. 5 depicts the user interface of the MARPLE Mediation Center.
With MARPLE Modeler, we can completely de ne the patient-centered data
collection process from the middle lane in Fig. 2. Further, MARPLE, enables
remote monitoring of process instances; e.g. Fig. 5 1 shows a concrete process
instance running on a mobile device as it can be monitored using MARPLE.
Note that this perspective displays both the current status of the mobile
process and the data values collected during process execution (see 7 ). Obviously,
this is exactly the information a medical professional would need when remotely
monitoring patient processes. Let us shortly consider how the above mentioned
process fragment is modeled in MARPLE. Fig. 5 shows a part of this model
together with instance-speci c markings. Activity 2 is a receive activity which
is waiting for an incoming message requesting a health check. The subsequent
three activities constitute data collection steps which are either implemented as
user forms or sensing activities; the blood pressure is gathered via a bluetooth
activity template from the linked blood pressure system. Blood glucose and ECG
recordings are entered via form-based activities; i.e., the user of the mobile device
gets respective requests in his worklist and then has to ll in the two forms (e.g.
see the PDA display in Fig. 4). Following data collection, activity 4 is
automatically executed. It invokes a web service at the clinic to report about measured
results (e.g., to add them to the electronic patient record). Subsequent activity
4 then waits until a message is received either from the clinic or from home care.
The toolbar on the left of Fig. 5 ( 8 ) displays available functions for managing
process templates, users, mobile devices and mobile device settings. Further, 6
displays the list of currently released process templates, which can be assigned
to registered mobile devices. So far, we have focused on the implementation of
the MARPLE Mobile Process Engine V1.3 and on robustness issues emerging
with mobile processes.
In literature we can nd approaches which focus on logical models for mobile
processes on the one hand and approaches addressing architectural and
implementation issues of light-weight process engines on the other hand. Regarding
the rst category, for example, [
We introduced our MARPLE architecture and described how its core components enable the execution and monitoring of processes on mobile devices. Our overall vision is to provide sophisticated mobile process support; i.e., to realize generic process management features including support for process instance changes, instance migrations, etc. To foster this vision we base our work on core design principles and fundamental concepts we developed in our ADEPT project. In future work we will extend the MARPLE Modeler such that it provides sophisticated methods for modeling complex process choreographies like the one from Fig. 2. This will include, for example, a methodology for correctly partitioning processes models, for allocating resulting fragments on di erent machines and devices, and for synchronizing them at runtime. In particular, we will adopt and extend concepts from autonomic computing and self-healing systems to cope with the many failure scenarios in connection with distributed and mobile applications.