This post is the second part of our public paper writing experiment for the SAC 2012, the 27th Symposium On Applied Computing. The complete version of the paper can be foundhere and will change in the in the course of the next weeks.
We now introduce a more complex application scenario. The organization of music festivals is a complex task and requires the coordination of dozens of mobile workers which offer security, technical or other support (human provided) services on a festival site. Basically, these workers are in charge of maintaining the functioning of the festival infrastructure (power generators, stage lighting, sound) and ensure the safety of the spectators.
In our application scenario, we consider the case of having problems with power outages on one of the festival stages, due to problems with the local power supply. To solve this problem, we require to organize an auxiliary power generator and to transport it to the stage. This process involves the coordination of local workers and services which provide the power generator and for the transport of the power generator.
For example, the power generator transport team needs to know about the characteristics of the festival location, like narrow roads or other obstacles that can hinder the transport. The security workers must know when the power generator arrives, to clear the transportation route (e.g., moving spectators away) in time and to lead the transport team to the stage. Stage technicians must inform the provider of the power generator about the electrical specifications that are necessary to connect the power generator to the stage.
While scenarios like the aforementioned can be modeled and handled with existing workflow languages and systems, there are several challenges that limit the application of existing workflow systems.
2.1 Challenge One: Context information
It is very difficult to foresee exceptions during the design of a workflow. In particular, in scenarios like festivals, we need to handle different physical execution contexts. For instance, the transportation of a power generator may be difficult to a festival location A, because of infrastructure limitations (narrow or muddy roads). The same might pose no problem on festival location B, because B has a highway nearby. Thus, we need to weave contextual information into the workflow at design time, which in fact can only be known at the location. This context information can take various formats: photos of the festival location can inform transport teams about the condition of roads (e.g., a muddy road because of rain), sensor data of mobile phones can give the exact geo location (instead of the address which can be ambiguous).
2.2 Challenge Two: Ad hoc creation of a workflow in a mobile environment
Workflow editors are tools (Active BPEL, express flow) that require at least a laptop to work. While laptops are per-se mobile, the size of a laptop limits its mobility. In scenarios like festivals, creating ad hoc workflows that includes context information, walking around with a laptop is not practical. In addition, laptops might do not provide the necessary sensor array to capture context information (GPS data, camera). Consequently, we need a tool that can be used on mobile phones to create the workflow in situ and be able to integrate sensor data (GPS, pictures) during the design of the workflow.
2.3 Challenge Three: Lightweight communication interfaces
Workflow languages like BPEL provide a large set on functions that are not used for ad hoc coordination (transactions, rollback). Evidently, BPEL has simply a different design goal which hinders its application in the mobile domain: connect and coordinate businesses and exchange data between businesses with complex business processes. On a conceptual level, we do the same in our working scenario: we connect different service providers and coordinate their activities. However, we operate on a different scale in terms of hardware and software. Our workers have access to services on their mobile devices (e.g., google maps) which do not offer a BPEL compatible service interfaces. Thus, we need to integrate these mobile services with a lightweight coordination and communication infrastructure which is available on mobile devices.
2.4 Challenge Four: Working the Crowd
In contrast to traditional workflow systems which are used in static settings with a small number of participants, we have a considerably larger number of participants (which may be subject to change). As discussed in our scenario, we may have to get context data like photos of the location. For this purpose, we can advise local workers and volunteers to take pictures of different areas of the location with their mobile devices. After selecting the most meaningful location photos (entry gates, streets, transportation routes), the transport team can access these and assess the characteristics of the festival location for selecting the proper transport vehicle. This task requires the ability to address a crowd consisting of volunteers and local workers in order to perform a specific task.
your ikangai science teamPaper Application Scenario Public Paper Writing, SAC, Tweetflows