1 / 14

Alert-driven Process Integration in a Web Services Environment

Alert-driven Process Integration in a Web Services Environment. Eleanna KAFEZA, S.C. CHEUNG Dept. of Computer Science, Hong Kong University of Science & Technology {scc, kafeza}@cs.ust.hk Dickson K.W. CHIU Dept. of Computer Science & Engineering, Chinese University of Hong Kong

yakov
Download Presentation

Alert-driven Process Integration in a Web Services Environment

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Alert-driven Process Integration in a Web Services Environment Eleanna KAFEZA, S.C. CHEUNG Dept. of Computer Science, Hong Kong University of Science & Technology {scc, kafeza}@cs.ust.hk Dickson K.W. CHIU Dept. of Computer Science & Engineering, Chinese University of Hong Kong kwchiu@acm.org Presented by: Patrick C.K. Hung, CSIRO, Australia

  2. Introduction • Web Services - Commercial activities, value-added services provided over the Internet • Highly competitive and dynamic • Response actively and timely to customers’ needs – key success factor for the provision of quality services • Processes integration with stringent urgency requirements - healthcare and security applications • Alerts - urgent requests and critical messages • Alert Management System (AMS) • Routing, monitoring, and logging the alerts • Find suitable service - application specific considerations like costs, waiting time, service time • For both B2B and B2C applications

  3. Motivating Example – Emergency Healthcare Ambulance Car Accident SSGPS Internet Hospital B SSGPS Monitoring Headquarters Doctor's clinic Hospital A • Both human and computerized systems involved • Different degree of computerization • Web Services supports both type of interaction in a single framework

  4. Interaction of Medical Processes

  5. Background • We’ve developed ADOME-WFMS • WFMS based on an advanced object modeling environment • Support of reuse and exception handling • E-ADOME • Web-enabled • Strong basis for supporting e-services • Both human user and agents (programs) • ME-ADOME • Add mobile support

  6. Alert Conceptual Model

  7. AMS Architecture

  8. Alert Life Cycle

  9. Defining the policies according to which the urgencies of the alert will evolve Example Alert Urgency Strategy Definition

  10. Service Provider Matchmaking • Algorithm searches for those service providers that can play the role required for the alert • Selects those that have a response time that is less than the deadline • If the matching is successful, one service provider is selected according to a user-supplied cost function • In case no matching is available, the algorithm upgrades the alert by expanding the roles whenever possible

  11. Main Web Services Implementation • Service Name (Provider): requestAlert • Input: AlertID, RequestorID, AlertMessage, Roles, Urgency, ResponseRequired ( TRUE | FALSE ), Deadline • Response: AlertID, ServiceProviderID, Ack (Confirmed | Denied | Deferred), ResponseMessage, AlertReceiptTime • Service Name (Provider): cancelAlert • Input: AlertID, RequestorID • Response: Ack (Confirmed | Denied | Deferred ) • Service Name (Requestor): receiveDeferredResponse • Input: Item AlertID, ServiceProviderID, ResponseMessage, AlertReceiptTime • Response: Ack (Confirmed, NotConfirmed )

  12. Advantage of an AMS • The urgency requirements, associated interactions with service providers, and the monitoring required by the administrators can be systematically and modularly captured into an AMS, instead of scattering around in the main workflow specification. • The logic for sending, routing, and monitoring these alerts is supported in the AMS and can be heavily reused. • AMS evolves from the exception handling and user-interface mechanisms of our ME-ADOME WFMS, by factoring out and extending, in particular, urgency requirements. • Physical execution of individual tasks of regular processes is outside the scope of the AMS and is in capture in the application logic of individual information systems which can be a WFMS as well • An AMS is light-weight and highly coherent, but loosely coupled with other sub-systems, enabling it to be plugged into any information system that needs such services

  13. Conclusions • A conceptual model for specifying alerts based on the requirements of cross-organizational processes and a set of routing parameters • A practical architecture for the AMS based on contemporary Web Services – supports human and programmatic interfaces • An algorithm for matching service providers to alert requirements • A mechanism for (re-)routing alerts and increasing their urgency when alerts are not acknowledged or processed within deadline. • Flexible and reusable AMS can be plug into other systems

  14. Future Work • Healthcare process and data integration • Interfacing and platform-specific issues • Location dependent applications • Workforce management • Mobile CRM • Inter-relations among alerts. • Failure of commitments and their relation to contract enforcement • Impact of cancellations, other possible exceptions • Tradeoff between quality/response time and cost, and service negotiation

More Related