 |
| Titel |
Event-Driven Service Oriented Architecture Foundations for Industrial and Natural Crises Management Scenarios |
| VerfasserIn |
Rainer Haener, Joachim Waechter, Martin Hammitzsch, Matthias Lentholt, Zoheir Sabeur, Stefan Poslad |
| Konferenz |
EGU General Assembly 2011
|
| Medientyp |
Artikel
|
| Sprache |
Englisch
|
| Digitales Dokument |
PDF |
| Erschienen |
In: GRA - Volume 13 (2011) |
| Datensatznummer |
250056258
|
|
|
|
|
|
| Zusammenfassung |
| TRIDEC, a system for Collaborative, Complex and Critical Decision-Support in Evolving Crises focuses on new technologies for real-time intelligent information management in collaborative, complex, critical decision processes in earth management. Key challenge is establishing communication infrastructures of interoperable services through which management of dynamically increasing volumes and dimensionality of disparate information is efficiently possible. TRIDEC’s architecture will be based on SOA 2.0, an event-driven extension of Service Oriented Architecture (SOA) principles. This approach supports creating high-level business events from low-level system events. Events are created by analysing real-time data from services (e.g. Sensor Alert Service), business processes including service chaining, or system components (e.g. simulation) and enhanced with details such as dependencies or causal relationships discovered by correlating other events and additional information. This process is facilitated by applying data-fusion and pattern-matching techniques as well as know-how derived from various knowledge bases, each covering domain-specific information. Correlating disparate information -which separately might not be useful- makes the enriched information utilizable for decision makers, affected public users, or task forces. Both correlation and enrichment of information enable adaptive system behaviour. When certain criteria or conditions are met (e.g. exceeding thresholds) appropriate business processes addressing the event patterns are triggered like e.g. real-time reaction on unforeseen events, system- or sensor failures. This approach supports and improves decision processes in evolving crises e.g. increase the significance of warnings by using additional information from numerical models. Even more important, this allows collaborating systems to respond dynamically in real-time, automate decision processes, or autonomously take actions like service-orchestration and -choreography to react on unique event patterns. The architecture also enables evolvement and evolution of systems by facilitating long-running processing capabilities, e.g. data-mining of information from various asynchronous events, time series, information networks, numerical models, messages, or human feedback as well as the deduction of patterns, trends, and rules over a long period of monitoring. TRIDEC’s SOA 2.0 approach will be demonstrated within two scenarios: One concerns a large group of experts working in crisis centres and government agencies using sensor networks. Their goal is to make and improve critical decisions in evolving tsunami crises in real-time based on various sensor events. The other involves groups of consulting engineers and financial analysts from energy companies working in sub-surface drilling operations. Their common objective is to monitor drilling operations in real-time using sensor networks, optimising drilling processes and detecting critical trends of drilling system functions. For the composition of web services TRIDEC adapts both ways SOA 2.0 offers: orchestration and choreography. In orchestration, a central knowledge-based processing framework takes control over the involved services and coordinates the execution of the operations on the services. Thus TRIDEC enables an adaptive framework for decision activities facilitating the support of complex business processes which are common across system boundaries. The involved services do not need to know that they are part of a composition or a high-level business process and may be therefore developed independently by the adoption of accepted standards. Choreography on the other hand does not rely on central coordination. Rather, each service involved in the collaboration environment knows exactly itself and when to execute its operations based on specifically defined trigger conditions (e.g. alerts or threshold exceedances), whom to interact with (e.g. notification recipients) and which protocols and encodings to use. Choreography emphasizes collaborative processes which are focused on the exchange of messages. All participants of the choreography need to be aware of the specific business process, the operations to execute, the messages to exchange, and the timing of message exchanges. |
|
|
|
|
|
|