Definition of a nuclear crisis use-case management to s(t)imulate an event management platform Anne-Marie Barthe-Delanoë1, Sebastien Truptil1, Roland Stühmer2, Frederick Benaben1 1 Université de Toulouse – Mines Albi, 81000 Albi, France 2 FZI Forschungszentrum Informatik, Karlsruhe, Germany {sebastien.truptil, anne-marie.barthe, frederick.benaben}@mines-albi.fr roland.stuehmer@fzi.de Abstract. 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 arti- cle presents a specific crisis use-case for the PLAY platform evaluation and al- so 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 simu- lated) are described in this article. Keywords: events, web-services, use-case, nuclear crisis, SOA, business processes, workflows. Introduction The European PLAY project (Grant number: FP7-ICT-2009-5) aims at designing an event management platform. Any event provider, such as electronic devices, in- formation 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 pre- vious 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 imple- mented 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 adfa, p. 1, 2011. © Springer-Verlag Berlin Heidelberg 2011 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 web- services 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 cartog- raphy) into technical components (workflows and web-services) that will be imple- mented in the demonstration platform of the first section. 1 Overview of the global architecture 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 [1] and will be able to run the three levels of processes (decisional, operational, sup- port). Technically, we will use the Distributed Service Bus (ESB) PETALS developed by the French open-source software editor PETALS Link [2]. Such a technical infra- structure requires the description of the processes as workflows in a runnable lan- guage (Business Process Execution Language (BPEL) [3] for instance). In order to make this task easier, all the sub-processes will be described with Business Process Modeling Notation (BPMN) [4]. Furthermore, considering the fact that we have to describe the event exchanges be- tween actors during the crisis response, BPMN is a good choice: this language is not only strongly aligned with computer implementation of workflows, but also structur- ally 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 Ar- chitecture (EDA) [5] infrastructure to connect components, devices and end user ser- vices. The DSB enables the federation of separate SOAs through the formation of domains, which can be allowed to exchange events. Thus, distributed sources of events can be combined in the platform. The Event Cloud provides storage and forwarding of events so that interested par- ties 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 real- time results e.g., when generating statistics. The Event Cloud is comprised of a peer- to-peer system of storage nodes organised in a CAN network [6]. The Distributed Complex Event Processing (DCEP) component has to detect com- plex 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 [7], to the input events. Finally, the Service Adaptation Recommender suggests changes (adaptations) of services’ configurations, composition or workflows, in order to overcome problems or achieve higher performance. Fig. 1. PLAY Platform conceptual architecture 1.2 The Simulation Platform 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 [8] standard: they embedded at least a timestamp and an ID number. Any generated event follows one of the eight event types (Figure 2) we have defined for the crisis response domain. Fig. 2. The eight event types for crisis response domain. 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 Sche- ma) and sending them to the cloud platform of PLAY (see Figure 3). The PLAY plat- form 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. Fig. 3. Technical architecture (with event sources and exchanges) of the simulation platform 2 Description of the use-case through a BPM approach 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 [9]). The radiation leak in our scenario results of the combination of two issues (as presented in Figure 4). The throttle valve does not respond A leak between primary and secondary loops (due to a very thin layer of metal) Fig. 4. Nuclear Crisis Use-Case: the triggering event. 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 second- ary loop. Consequences: The steam (and the water) of the secondary loop are contam- inated and the pressure within the secondary loop increases. ii. The throttle valve, a safety device of the secondary loop, opens due to the in- creased pressure inside the secondary loop. Unfortunately, it does not re- spond 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), out- side the nuclear plant, pilots this crisis cell. Delegates of each actor are present in the crisis cell. Firemen, policemen, weather survey network, scientists, emergency medi- cal 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 lis- tening to and the events it is able to generate and to send to the cloud (i.e. the techno- logical 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 [10]): decisional process, operational process and support process. These three processes may be detailed through seven sub-processes, as shown on Figure 5. Fig. 5. Nuclear Crisis Overall Treatment/ Management 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). Fig. 6. Focus on a part of the crisis response in BPMN. 3 Use of the s(t)imulation platform The input of this step is a set of ordered business activities, each under the respon- sibility 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 [11] or [12], in charge of realizing automatically this kind of matching. 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, repre- sented 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 » ser- vices, 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 con- tained 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 Pro- cess 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 [13]. They are necessary to use both partners’ services (which can be real web services or just interfaces that make the link between the SOA architecture and a manual/technical operation) and the mediation service (the BPEL orchestrator which runs the collaborative process described into the BPEL file). Step 4: Finally, all the artifacts on the ESB are automatically deployed. These arti- facts are composed of, on the one hand all the SAs and SUs created during the previ- ous step, and, on the other hand all the binding component (BC) needed to communi- cate with the web-services (one BC per protocol) and the potentially requires service engine (for instance a workflow engine). Fig. 7. The (almost) automated settings chain Step 5: In PLAY, our research work consists in simulating the execution of the de- fined 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 work- flows. We use a tool name EasiestDemo, also developped by PEtALS Link [14]. It allows the creation of a graphical interface for each operation of a WebService. A graphical interface is composed of TextBox for each input and output elements of the operation and the colors of the interface are defined for each actor in a XML file. Conclusion 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 use- cases 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 heter- ogeneous 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 em- bedded 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 high- light 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. Simul- taneously, 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 non- functional aspects. For instance, scalability of the simulation platform will be a cru- cial 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. References 1. Vernadat, F.: Interoperable enterprise systems: Principles, concepts, and methods. In: An- nual Reviews in Control, vol. 31, no. 1, pp. 137—145 (2007) 2. PEtALS Link, http://www.petalslink.com 3. OASIS, Web Services Business Process Execution Language Version 2.0, http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html (2007) 4. Object Management Group, Business Process Model And Notation (BPMN), Version 1.2, http://www.omg.org/spec/BPMN/1.2/PDF/ (2009) 5. Luckham, D., Schulte, R.: Event Processing Glossary – Version 1.1, Event Processing Technical Society (2008) 6. Filali, I., Pellegrino, L., Bongiovanni, F., Huet, F., Baude, F.: Modular P2P-based Ap- proach for RDF Data Storage and Retrieval. In: Proceedings of The Third International Conference on Advances in P2P Systems. (2011) 7. Etzion O., Niblett P.: Event Processing in Action. Manning Publications Co. (2010) 8. OASIS, Web Services Base Notification 1.3 OASIS Standard (2006). 9. Electricité de France (EDF): Panorama de l’électricité : les différents types de réacteurs n nucléaires, http://www.edf.com/html/panorama/production/industriels/nucleaire/types_reacteurs.html 10. Norme européenne NF EN ISO 9001 version 2000, Systèmes de management de la qualité – Exigences. AFNOR (2000) 11. Bénaben, F., Boissel-Dallier, N., Lorré, J. P. et Pingaud, H.: Semantic Reconciliation in In- teroperability Management through Model-Driven Approach. In: Proceedings of PRO-VE 2010, pp.705—712, (2010) 12. Dong, H., Hussain, F.K., Chang, E.: A service search engine for the industrial digital Eco- systems. In: IEEE Trans. on Industrial Electronics, vol 99, (2009) 13. JSR 208: The Java Community Process (SM) Program - JSRs: Java Specification Requests - detail JSR# 208, (2005). 14. EasiestDemo, http://research.petalslink.org/display/easiestdemo/EasiestDemo+- +Open+source+BPEL+to+Java+generator