1 / 33

Moving Active Functionality from Centralized to Open Distributed Heterogeneous Environments

Moving Active Functionality from Centralized to Open Distributed Heterogeneous Environments. Mariano Cilia, Christof Bornhoevd, Alex Buchmann Databases and Distributed Systems Group Darmstadt University of Technology mcilia@acm.org. Motivation. Active functionality: DBMS+ ECA rules

meghan
Download Presentation

Moving Active Functionality from Centralized to Open Distributed Heterogeneous Environments

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. Moving Active Functionality from Centralized to Open Distributed Heterogeneous Environments Mariano Cilia, Christof Bornhoevd, Alex Buchmann Databases and Distributed Systems Group Darmstadt University of Technology mcilia@acm.org

  2. Motivation • Active functionality: DBMS+ ECA rules • useful for enforcing business rules • designed for monolithic centralized systems => difficult to extend or adapt • one of a kind prototypes • New generation of (global-scale) applications • business rules out of scope of a specific application • events and operations may not be directly related to database operations • involves events from diverse sources, actions performed on different subsystems

  3. Objectives • Move active functionality to open distributed heterogeneous environments • offer a flexible active service • decoupled from the database • constructed composing other services • event notification, complex event detection, event filtering, event logging, condition evaluation, action execution,... • components can be combined and configured according to the required functionality and scenario

  4. Moving away from … • Homogeneous environment • Centralized system • Database-hosted rules

  5. Heterogeneity Issues • Data from different sources/components is represented differently • Different organizations/departments use different units and representation formats • Many of the underlying assumptions about the meaning of a given data object are only implicit

  6. vocabulary Use of MIX Representation Model • Combines two aspects: • representation of data plus additional semantic metadata • flexible, self-describing data model for the representation of semi-structured data • Conversion functions • allow the integration of data from different sources by converting it to a common context • Not always bi-directional (lossy)

  7. vocabulary Ontology-based Infrastructure • Representation Ontologies • domain-independent physical representation basis • enables exchange and reuse of concepts • contains concepts like NumericValue, CharacterString, Boolean, ...

  8. vocabulary Ontology-based Infrastructure • Representation Ontologies • Infrastructure-specific Ontologies • correct interpretation of parameters involved in component interactions • refer to active functionality infrastructure • contains concepts like notification, timestamp, rule, event, condition, action, etc. • sub-ontologies: Timestamp, Notification, ECARule, and Service • Different (ECA)rule languages are mapped and described using the infrastructure-specific ontology

  9. vocabulary Ontology-based Infrastructure • Representation Ontologies • Infrastructure-specific Ontologies • Domain-specific Ontologies • refer to a concrete subject domain • provide a consistent conceptualization of this domain • for instance, online Auction domain contains concepts like PlaceBid, Item, BidAmount, Bidder, Seller, ...

  10. Rule name event condition action OK Rule Representation (domain-specific) Rule Definition Lang. Ontology-based Rule Representation RULE Analyse ON placeBid IF placeBid < U$D 100 THEN BidAnalysis(placeBid) transformation Ri infrastructure E C A domain …

  11. Ontology-based Infrastructure Wrap-up • Common vocabulary for all participants • Definition of active functionality concepts • Flexible, extensible, conversion functions • Allows integration of data from heterogeneous applications • Simplifies the mapping of Rule Definitions (dialects) to concepts • Adapters

  12. vocabulary Moving away from … • Homogeneous environment  Heterogeneous environments Ontology-based Infrastructure • Centralized system • Database-hosted rules

  13. Distribution Issues • Inherent characteristics of open distributed envs • Message delays • Node and channel failures • Lack of message ordering • No global time • Impact on active functionality • Event Ordering • Time stamping • Partial order of events • Event consumption • Exceptions, policies • Hard-wired event operators • Review specification and semantics of aDBMS operators

  14. Proposed Approach • Dissemination of events (Auctions [BoCiLiBu00]) • (proactively) push events • publish/subscribe • dynamic number of event consumers and producers • concept-based addressing • Reliable messaging (with transactional support [LiMaBu00]) • More accurate timestamp approach [LiCiBu99] • Flexible definition of event operators

  15. Moving away from … • Homogeneous environment  Heterogeneous environments Ontology-based Infrastructure • Centralized system  Distributed system concept-based event dissemination • Database-hosted rules

  16. Database-hosted Rules • Monolithic • Difficult to adapt and extend • Not ALL database functionality is needed • Event operators are hard-wired

  17. Service-oriented Architecture • Requirements: • flexible, extensible, powerful, multiple environments • reusable in other contexts • service interaction based on the ontology • Simple service interface • configuration: registration interface • run-time: single method interface

  18. Service-oriented Architecture (2) • Set of (basic) services • event notification, filtering, complex event detection, condition evaluation, action execution, event logging, transaction service, ontology server ... • Chain of services • connect (plug) services for different environments and scenarios

  19. Service-oriented Architecture (3)

  20. Moving away from … • Homogeneous environment  Heterogeneous environments Ontology-based Infrastructure • Centralized system  Distributed system concept-based event dissemination • Database-hosted rules  Service-based Service-oriented architecture

  21. Rule name event condition action OK The Whole Picture Ontology-based Rule Representation Rule Definition RULE Analyse ON placeBid IF placeBid < U$D 100 THEN BidAnalysis(placeBid) Transf. register ECA service configure Configuration Interface Event Adapter Action Cond. EvComp

  22. Prototype Details • Ontology implementation (MIX Model) • Representation • Infrastructure-specific Ontology • Domain-specific ontology: Auctions, Car, Profile • Ontology implementation extended with active capabilities • Event Adapter (API, XML wrapper) • Other Adapters (Messaging, Workflow, …)

  23. Prototype Details (2) • Services implemented • ontology server, filter, notification, alarm, (simple) timestamp, condition evaluation, action execution • Software/Technology used • Services on top of HP CSF • Java implementation of the Ontology (MIX Model) • HP Process Manager (workflow) • TIB/Rendezvous (event dissemination) • Generation of WSDL

  24. Prototype - Still to do ... • Extend infrastructure-specific concepts • Conditions and Actions (Database domain) • Timestamp Ontology • Event composition • (flexible) event operator definition • consumption modes • Integration with Transaction Service • Analysis, Management & Visualization of Rules

  25. Conclusions • Clean integration of data/events coming from heterogeneous applications (MIX Model) • common vocabulary • notion of context information • conversion function • Rule representation at conceptual level makes easy to map rules from different (domain-specific) rule specification languages • Context sensitive: subscriptions, conditions, actions

  26. Conclusions (2) • Event dissemination using concept-based addressing • Service-based Architecture • flexible, extensible and powerful • service composition • clean integration in the e-service world • Appropriate for new generation of (global-scale) applications • ECA difficulties (even more complicated?)

  27. References - Proposed Approach [LiCiBu99] C. Liebig, M. Cilia, A. Buchmann. Event Composition in Time-dependent Distributed Systems. In CoopIS‘99. [Bornhoevd01] C. Bornhoevd. Semantic Metadata for the Integration of Heterogeneous Internet Data (in German), PhD Thesis, Department of Computer Science, Darmstadt University of Technology, Germany, 2000. [LiMaBu00] C. Liebig, M. Malva, A. Buchmann. Integrating Notifications and Transactions: Concepts and X2TS Prototype. In Proc. Intl Workshop on Engineering Distributed Objects (EDO), 2000. [BoCiLiBu00] C. Bornhoevd, M. Cilia, C. Liebig, A. Buchmann. An Infrastructure for Meta-Auctions. In WECWIS’00. [CiBoBu01] M. Cilia, C. Bornhoevd, A. Buchmann. Moving Active Functionality from Centralized to Open Distributed Heterogeneous Environments. CoopIS’01.

  28. My Car Info Biography Occupants Current State My Info Medical Info Travel Preferences Units of Measures Prefs Preferred Payment Methods Info Status Location Software Car Scenario Car Portal Driver Portal Addition of ECA Rules to the Portals “Car” Personalization Dissemination of Events to other Portals (*.*) Portal Box

  29. My Car Info Biography Occupants Current State My Info Medical Info Travel Preferences Units of Measures Prefs Preferred Payment Methods Info Status Location Software Car Scenario Car Portal Driver Portal Rules (*.*) Portal onDrvGetInto then LoadPrefs R1 onFailure then start Wf R2 onChg.Country then Load Bilingual dictionary R3 Box Rules

  30. My Car Info Biography Occupants Current State My Info Medical Info Travel Preferences Units of Measures Prefs Preferred Payment Methods Info Status Location Software Car Scenario - Rule Example (1) Car Portal Driver Portal Rules (*.*) Portal 1 onDrvGetInto then LoadPrefs R1 3 2 DrvGetInto event 4 0 SetInstruments Box

  31. My Car Info Biography Occupants Current State My Info Medical Info Travel Preferences Units of Measures Prefs Preferred Payment Methods Info Status Location Software Car Scenario - Rule Example (2) Car Portal Driver Portal Rules (*.*) Portal 1 onFailure then start Wf R2 2 Failure event 0 3 SetDADestination Box

  32. My Car Info Biography Occupants Current State My Info Medical Info Travel Preferences Units of Measures Prefs Preferred Payment Methods Info Status Location Software Car Scenario - Rule Example (3) Subscription to specific context (country) Car Portal Driver Portal Rules (*.*) Portal 1 onChg.Country then load Biling dictionary R3 Find & load bilingual dictionary service (e.g. in all PDAs inside the car) NewPosition (x,y,z) event 0 2 LoadService Box

  33. Car Scenario - Implementation • CarBox Service (interaction with the car itself and with its portal) • Profile Mgmt (CoolTown Web Presence Mgr.) • Rule Definition • Actions • Workflow Processes • Car Failure • Find Gas Station • Check Up Control • Location Search • CarBox • Set Preferences • Set Destination • Load Service

More Related