The European PLAY project aims at providing platform for event management. This platform should be tested and stimulated through several use-cases. Obviously, these use-cases should be relevant on the business point of view, but to make them relevant, it could be interesting to be able to redesign them as often as required, in order to improve their business context. This article presents a specific crisis use-case for the PLAY platform evaluation and also a technical framework dedicated to make this use-case as agile as possible. The general principle is to fill the gap between business level (process models) and technical level (workflows definition and web-services implementation). The way the use-case will be simulated (to stimulate the PLAY platform) and the way the use-case will be designed and potentially re-designed (to be simulated) are described in this article.
The European PLAY project (Grant number: FP7-ICT-2009-5) aims at designing an event management platform. Any event provider, such as electronic devices, information systems, etc., would be able to send its events to the PLAY platform through a cloud infrastructure. The PLAY platform provides an event market place containing (i) the events received from event providers and (ii) new events generated by the Complex Event Processing tool (CEP layer) from the combination of the previous ones (the deduction is rule-based). Any event consumer would then receive the events from the topic it has subscribed for. Event consumers could finally use these events to act on a better way, according to the way the situation evolves.
In this article, we aim at presenting the way one specific use-case could be implemented to stimulate the PLAY platform and demonstrate its features. This use-case concerns a nuclear crisis. The global objective is to define the workflows and the web-services used to simulate the crisis management and using the PLAY platform to run and adapt the overall behavior of the crisis cell. Furthermore, in order to match with the business level definition of the crisis management, this article introduces the mechanisms in charge of ensuring the direct generation of these workflows and webservices from the process models and activities.
In the first section of this article, we introduce the global architecture of the demonstration platform and the way workflows and web-services will be used in a SOA context. The second section presents the use-case scenarios. The remainder of the article describes the automatic transformation of business models (process cartography) into technical components (workflows and web-services) that will be implemented in the demonstration platform of the first section. 1
In our use-case of a nuclear crisis management, the scenarios are very complex and a lot of sub-processes are involved. One of the objectives of our current research work is to simulate this use-case through a demonstration platform.
This platform will be based on the Service Oriented Architecture (SOA) principles
[
Furthermore, considering the fact that we have to describe the event exchanges between actors during the crisis response, BPMN is a good choice: this language is not only strongly aligned with computer implementation of workflows, but also structurally event-oriented (events are represented via circles and can be typed). BPMN is at the intersection between our need to represent events and the technical requirements of our demonstration platform (proximity between BPMN and workflow language). 1.1
The PLAY Platform
Figure 1 shows the conceptual architecture of the PLAY Platform. The Distributed
Service Bus (DSB) provides the Service-oriented Architecture and Event-driven
Architecture (EDA) [
The Event Cloud provides storage and forwarding of events so that interested
parties can be notified of events according to content-based subscription. The storage
operates as an event history to fulfil queries for older events, which do not need
realtime results e.g., when generating statistics. The Event Cloud is comprised of a
peerto-peer system of storage nodes organised in a CAN network [
The Distributed Complex Event Processing (DCEP) component has to detect
complex events and do reasoning over events in real-time. Events per se might not be
meaningful, but meaningful events can be derived from available, simpler events. The
platform can readily detect such derived events, because it has knowledge of all
events and applies event patterns, as described in [
Finally, the Service Adaptation Recommender suggests changes (adaptations) of services’ configurations, composition or workflows, in order to overcome problems or achieve higher performance.
Basically, the structure of the demonstration platform will be the following: several ESBs will run (now, the prototype uses only one), thanks to their workflow engine, several BPEL workflows (representing decisional, operational or support processes) among several web-services (representing activities of actors that might be invoked in a crisis management context).
Each web-service is able to generate events (such as status but also business events
like radiation measures or requested resources). These events are formatted using the
WS-Notification [
Then, these events are sent to a special service of ESB. This special service (event manager or event proxy) is in charge of gathering events, translating them into an appropriate format for further processing (in the case of PLAY this is an RDF Schema) and sending them to the cloud platform of PLAY (see Figure 3). The PLAY platform can use these events to generate new events and enrich the event market place. The event manager is also in charge of receiving new events from the cloud PLAY platform in order to send them to the web-services that are subscribers for that type of event.
The considered crisis situation use-case takes place in a French nuclear plant which
reactor is water-pressurized (water-pressurized type is used for all nuclear reactors in
France, exception made for a single reactor [
The throttle valve does not respond
A leak between primary and secondary loops (due to a very thin layer of metal)
i. The metal of the steam generator is very thin. Due to the wearing effect of time, a leak appeared in the steam generator. As a consequence, the water within the primary loop, which is contaminated, spreads through the secondary loop.
Consequences: The steam (and the water) of the secondary loop are contaminated and the pressure within the secondary loop increases. ii. The throttle valve, a safety device of the secondary loop, opens due to the increased pressure inside the secondary loop. Unfortunately, it does not respond to the manual bypass of the safety loop, requiring its closure.
Consequences: The steam of the secondary loop, contaminated, escapes from the secondary loop to the atmosphere.
To solve, or at least reduce, this crisis situation, several stakeholders are involved. They are grouped into an organization called “crisis cell”, which is in charge of the crisis response. The representative of the French national authority (the prefect), outside the nuclear plant, pilots this crisis cell. Delegates of each actor are present in the crisis cell. Firemen, policemen, weather survey network, scientists, emergency medical service, and any other actor involved in response process has one representative in the crisis cell. The delegates validate the feasibility of the decisions, ensure link with actors on the field and ensure communication between actors.
Each actor involved in the crisis response has its own abilities, the events it is listening to and the events it is able to generate and to send to the cloud (i.e. the technological platform that manages the events).
The crisis cell is structured according to three kinds of process, regarding the
standards of business process cartography (as defined by the European standard NF
EN ISO 9001 version 2000 [
We have designed eighty-three BPMN processes to cover the whole cartography of the interactions between the crisis cell stakeholders. As an example for this article, we focus on a little part of that process cartography we have already implemented in our prototype. The following Figure 6 presents several swim lanes (horizontal containers) that represent the involved actors for this process (here the French weather forecast network Meteo France and the Radiation Survey Network) and the PLAY system. Each pool embeds its own activities and flows, while exchanges between pools are represented through flows generating events.
The matching workflow of the previously presented BPMN process now runs on our prototype of simulation platform (we have designed the matching BPEL files and also the web services called by the processes).
The input of this step is a set of ordered business activities, each under the
responsibility of an actor. Nevertheless the business activities could not be directly used by
the platform, it is necessary to match these business activities with technical services
(as an operation of web-services). Research works try to define semantics service
search engine, like [
Since the aim of our research work in the PLAY project is to configure a technical platform, which has to simulate a business description, we decided at first to manually realize this matching before improving our work with any semantics service search engine.
Based on this choice, the automatic configuration of the technical platform, represented by the Figure 7, is divided in four main steps for each business process:
Step 1: In practice, once the knowledge about the crisis situation is gathered, the crisis response is represented by a set of BPMN models. In all these models, a pool represents each partner and a pool represents the cloud.
Our set of generic tools, as a result of our internal research work, allow to retrieve the business services used in the BPMN files and to match them with « real » services, i.e. technical services provided by the collaboration partners. The tools extract the whole business services information from the BPMN process description: they produce a list of services (name of the service and its responsible partner’s name).
Step 2: The next step is to match these business services with technical services. For the moment, we suppose that a business service matches with a single technical operation (i.e. a single operation of a WebService). This matching is manually done with the help of our tools.
For each business service, the user has to choose an operation from a WebService (thanks to WSDL file). If the concerned partner doesn’t provide a relevant WSDL file, our tools allow creating such a file and the associated WebService.
Once the WSDL file is chosen, the tools parse it and propose the operations contained into it (and sort it by port types) to the user. The step is repeated as many times as needed to match all the business services with technical operation. Through a Model Driven Engineering (MDE) (model transformation of the BPMN files) and with this service matching, we will obtain the workflow, expressed in Business Process Execution Language (BPEL), and a set of configuration files (that are linked to the server used to run the workflow)
Step 3: In PLAY, the workflow is run on an Enterprise Service Bus (ESB), which is PETALS, developed by the French editor PETALS Link. This ESB is compliant with the JBI standard (also based on JSR208 standard).
The JBI standard implies the use of Services Unit (SU) and Services Assembly
(SA) that compose the configuration of the services on the ESB. The several SUs and
SAs are automatically generated for all the services of the collaborative process. A
SU is composed of the WSDL of the service and a JBI file that defines, in a unique
way for the ESB, the web-service. A SA makes the link between a protocol (SOAP,
HTTP, …) and the web-services through the SU [
Step 4: Finally, all the artifacts on the ESB are automatically deployed. These artifacts are composed of, on the one hand all the SAs and SUs created during the previous step, and, on the other hand all the binding component (BC) needed to communicate with the web-services (one BC per protocol) and the potentially requires service engine (for instance a workflow engine).
Step 5: In PLAY, our research work consists in simulating the execution of the
defined crisis response. Consequently, we need graphical user interface for each service,
in order to simulate the response for the invocation of any operation by the
workflows. We use a tool name EasiestDemo, also developped by PEtALS Link [
To demonstrate the powerful capabilities of the PLAY platform, and especially the way interactions and interconnections of events could be handled, complex workflows have been be designed. These workflows must also be directly connected to the cloud infrastructure of PLAY. There are two main issues in this objective: (i) the quality of the considered use-case (and of the associated workflows) and (ii) the way these usecases can be easily executed to stimulate the PLAY platform.
This article tried to deal with both these issues. The presented use-case is a very complete one that could be easily made simpler or more complex. The main objective of this approach is to show how a platform like PLAY could support and hide the complexity of a concrete business situation. Choreography and orchestration of heterogeneous business processes in a real size imply a high-level of complexity. In crisis management context, crucial decision tasks (that require human vision) could be embedded in that complexity. Consequently, these crucial tasks could be partially hidden and decision makers could miss the fact that these tasks are so important (among the mass of other tasks). By assuming orchestration and choreography, an event-driven platform like PLAY could deal with the quantity of computable tasks in order to highlight critical ones (the ones that requires decision makers).
To deal with both the main issues of the overall objective (business quality of the use-case and the ability of workflow simulation to stimulate the PLAY platform), the whole set of services; workflows and events are currently being implemented. Simultaneously, the whole structure of the PLAY platform (presented in figure 1) is also being deployed. The concrete and complete confrontation between both these worlds (even if there are already partial confrontations, component by component) will be a great step of the PLAY project and should demonstrate the functional capabilities of the PLAY platform. However, there are still a lot of questions concerning nonfunctional aspects. For instance, scalability of the simulation platform will be a crucial issue in order to evaluate scalability of the PLAY platform. Some other points like quality of service or security, even if less crucial, are also to be considered. Acknowledgments. The authors would like to thank very gratefully the members of the PLAY consortium (FZI, Karlsruhe; ARMINES/CGI, Albi; PetalsLink, Toulouse; ICCS, Athens; CIM, Nis; INRIA, Sofia-Antipolis; Orange-Labs, Sophia-Antipolis) and European commission for their support.