Moving Active Functionality Moving Active Functionality from Centralized to Open from Centralized to Open

Distributed Heterogeneous Distributed Heterogeneous EnvironmentsEnvironments

Moving Active Functionality Moving Active Functionality from Centralized to Open from Centralized to Open

Distributed Heterogeneous Distributed Heterogeneous EnvironmentsEnvironments

Mariano Cilia, Christof Bornhoevd, Alex Buchmann

Databases and Distributed Systems Group

Darmstadt University of Technology

mcilia@acm.org

MotivationMotivationMotivationMotivation• 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

ObjectivesObjectivesObjectivesObjectives

• 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

Moving away from …Moving away from …Moving away from …Moving away from … Homogeneous environment

Centralized system

Database-hosted rules

Heterogeneity IssuesHeterogeneity IssuesHeterogeneity IssuesHeterogeneity 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

Use of MIX Representation ModelUse of MIX Representation ModelUse of MIX Representation ModelUse 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)

vocabulary

Ontology-based InfrastructureOntology-based InfrastructureOntology-based InfrastructureOntology-based Infrastructure

• Representation Ontologies– domain-independent physical representation basis– enables exchange and reuse of concepts – contains concepts like NumericValue,

CharacterString, Boolean, ...

vocabulary

Ontology-based InfrastructureOntology-based InfrastructureOntology-based InfrastructureOntology-based InfrastructureRepresentation 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

vocabulary

Ontology-based InfrastructureOntology-based InfrastructureOntology-based InfrastructureOntology-based InfrastructureRepresentation OntologiesInfrastructure-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, ...

vocabulary

Rule RepresentationRule RepresentationRule RepresentationRule Representation

RULE AnalyseON placeBidIF placeBid < U$D 100THEN BidAnalysis(placeBid)

OK

Rule name

condition

event

action

(domain-specific)Rule Definition Lang.

transformation

Ontology-basedRule Representation

…

infr

astr

uctu

redo

mai

n

Ri

EC A

Ontology-based Infrastructure Ontology-based Infrastructure Wrap-upWrap-up

Ontology-based Infrastructure Ontology-based Infrastructure Wrap-upWrap-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

Moving away from …Moving away from …Moving away from …Moving away from … Homogeneous environment

Heterogeneous environmentsOntology-based Infrastructure

Centralized system

Database-hosted rules

vocabulary

Distribution IssuesDistribution IssuesDistribution IssuesDistribution 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

Proposed ApproachProposed ApproachProposed ApproachProposed 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

Moving away from …Moving away from …Moving away from …Moving away from … Homogeneous environment

Heterogeneous environmentsOntology-based Infrastructure

Centralized system Distributed systemconcept-based event dissemination

Database-hosted rules

Database-hosted RulesDatabase-hosted RulesDatabase-hosted RulesDatabase-hosted Rules

• Monolithic

• Difficult to adapt and extend

• Not ALL database functionality is needed

• Event operators are hard-wired

Service-oriented ArchitectureService-oriented ArchitectureService-oriented ArchitectureService-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

Service-oriented Architecture (2)Service-oriented Architecture (2)Service-oriented Architecture (2)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

eventsources

eventcompositor

eventadapter

conditionevaluation

actionexecutionfilter

Service-oriented Architecture (3)Service-oriented Architecture (3)Service-oriented Architecture (3)Service-oriented Architecture (3)

notifiy notifiy

Event of rule R1

E-C C-A

register R1'sEvent register R1's

Condition

register R1'sAction

complex eventdetection service

condition evaluationservice

action executionservice

register rule R11

2

3

4a 4b

R1'sCondition

object

ECA-rule service

A

B

R1'sActionobject

Moving away from …Moving away from …Moving away from …Moving away from … Homogeneous environment

Heterogeneous environmentsOntology-based Infrastructure

Centralized system Distributed systemconcept-based event dissemination

Database-hosted rules Service-basedService-oriented architecture

eventsources

eventcompositor

eventadapter

conditionevaluation

actionexecutionfilter

The Whole PictureThe Whole PictureThe Whole PictureThe Whole PictureRule Definition

RULE AnalyseON placeBidIF placeBid < U$D 100THEN BidAnalysis(placeBid)

OK

Rule name

condition

event

action

Transf.

ECAservice

Ontology-based Rule Representation

register

EventAdapter

EvComp Cond. Action

ConfigurationInterface

configure

Prototype DetailsPrototype DetailsPrototype DetailsPrototype 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, …)

Prototype Details (2)Prototype Details (2)Prototype Details (2)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

Prototype - Still to do ...Prototype - Still to do ...Prototype - Still to do ...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

ConclusionsConclusionsConclusionsConclusions

• 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

Conclusions (2)Conclusions (2)Conclusions (2)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?)

References - Proposed ApproachReferences - Proposed ApproachReferences - Proposed ApproachReferences - 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.

Car ScenarioCar ScenarioCar ScenarioCar Scenario

Box

Car PortalDriverPortal

(*.*)Portal

• My Car Info• Biography• Occupants• Current State

• My Info• Medical Info• Travel Preferences• Units of Measures Prefs• Preferred Payment Methods

• Info• Status• Location• Software

• Addition of ECA Rules to the Portals

• “Car” Personalization

• Dissemination of Events to other Portals

Car ScenarioCar ScenarioCar ScenarioCar Scenario

Box

Car PortalDriverPortal

(*.*)Portal

• My Car Info• Biography• Occupants• Current State

• My Info• Medical Info• Travel Preferences• Units of Measures Prefs• Preferred Payment Methods

• Info• Status• Location• Software

Ruleson DrvGetIntothen LoadPrefs

on Failurethen start WfR2

R1

R3on Chg.Countrythen Load Bilingual dictionary

Rules

Car Scenario - Rule Example (1)Car Scenario - Rule Example (1)Car Scenario - Rule Example (1)Car Scenario - Rule Example (1)

Box

Car PortalDriverPortal

(*.*)Portal

• My Car Info• Biography• Occupants• Current State

• My Info• Medical Info• Travel Preferences• Units of Measures Prefs• Preferred Payment Methods

• Info• Status• Location• Software

on DrvGetIntothen LoadPrefsR1

DrvGetIntoevent

SetInstruments

1

23

40

Rules

Car Scenario - Rule Example (2)Car Scenario - Rule Example (2)Car Scenario - Rule Example (2)Car Scenario - Rule Example (2)

Box

Car PortalDriverPortal

(*.*)Portal

• My Car Info• Biography• Occupants• Current State

• My Info• Medical Info• Travel Preferences• Units of Measures Prefs• Preferred Payment Methods

• Info• Status• Location• Software

Rules

Failureevent

SetDADestination

1

2

30

on Failurethen start WfR2

Car Scenario - Rule Example (3)Car Scenario - Rule Example (3)Car Scenario - Rule Example (3)Car Scenario - Rule Example (3)

Box

Car PortalDriverPortal

(*.*)Portal

• My Car Info• Biography• Occupants• Current State

• My Info• Medical Info• Travel Preferences• Units of Measures Prefs• Preferred Payment Methods

• Info• Status• Location• Software

Rules

NewPosition(x,y,z)event

LoadService

1

20

on Chg.Countrythen load Biling dictionary

R3

Find & loadbilingual dictionary

service(e.g. in all PDAs

inside the car)

Subscription to

specific context (c

ountry)

Car Scenario - ImplementationCar Scenario - ImplementationCar Scenario - ImplementationCar 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