The JEDI infrastructure and its application to the development of the OPSS WFMS G. Cugola, E. Di Nitto, A. Fuggetta Politecnico di Milano and CEFRIEL WISEN Irvine, July 1998

WISENElisabetta Di Nitto2 Contents zJEDI: a Java Event-based Distributed Infrastructure zOPSS: Orchestra Process Support System zEvaluation zOngoing research activities

WISENElisabetta Di Nitto3 JEDI a Java Event-based Distributed Infrastructure Event notification operations: Subscribe Unsubscribe Publish Receive Key features: Anonymity Multicasting Asynchronicity Support to mobility Based on Java and RMI Active object 1 Active object 2 Active object 3 Active object 4 Active object n Event dispatcher Notifications

WISENElisabetta Di Nitto4 Notification structure and subscriptions  Notification structure: tuple WindowOpen(foo.c,read)  Subscription: based on regular expressions Window*(*,read)

WISENElisabetta Di Nitto5 JEDI Architecture (centralized dispatching) Active object Active object Node i j Active object Active object Node m Active object Active object Event dispatcher Active object

WISENElisabetta Di Nitto6 JEDI Architecture (decentralized dispatching) Active object Active object Node i j Active object Node m Active object Dispatching server Dispatching server Active object Dispatching server

WISENElisabetta Di Nitto7 Hierarchical distribution of notification with decentralized dispatching Dispatching Server Active Object Partial notification order is preserved

WISENElisabetta Di Nitto8 Mobility in JEDI zActive objects can autonomously move across the network of dispatching servers zThe event dispatcher supports the mobility of active objects: yfreezes the active object subscriptions; ytemporarily stores all the notifications to be delivered; and ydispatches the notifications as soon as the object is ready in the new location.

WISENElisabetta Di Nitto9 OPSS zGoal: to support the development of business services zRequirements: yScalability with respect to the distribution and number of operators and users yDynamic deployment of service components

WISENElisabetta Di Nitto10 OPSS architecture (1) Software agent Agenda State server Event dispatcher Synchronous request Software agent Agenda

WISENElisabetta Di Nitto11 OPSS architecture (2) Software agent State server Created OnGoing Assigned Activity CreateActivityAssignAgent Event dispatcher Agenda

WISENElisabetta Di Nitto12 Evaluation: advantages zWe have experienced all the advantages of the event-based paradigm: yEasy reconfigurability of the system. yEasy distribution/replication of components. yEasy plug & play of components. yExamples: process state visualization.

WISENElisabetta Di Nitto13

WISENElisabetta Di Nitto14

WISENElisabetta Di Nitto15 Evaluation zOpen issues

WISENElisabetta Di Nitto16 Problem: possible race conditions T1: Publish(CreateActivity) T3: Subscribe(AssignAgent) T4: Publish(AssignAgent) Desired behavior Agent 1 State Server T2: Activity created Activity

WISENElisabetta Di Nitto17 State Server Problem: possible race conditions Agent 1 T1: Publish(CreateActivity) T4: Subscribe(AssignAgent) T3: Publish(AssignAgent) Wrong behavior T2: Activity created Activity

WISENElisabetta Di Nitto18 Cause: this is not a true asynchronous event notification zSolutions: ythe activity acknowledges its creation by issuing a response notification; ythe interaction among agents is modeled in a different way (different notifications); yA synchronous mechanism is introduced. This seems to us unavoidable.

WISENElisabetta Di Nitto19 Events granularity zIf the granularity of events is very low ymany notifications have to be generated; ythe programming activity is more difficult; ythe performance of the system are reduced; yit is difficult to test and monitor the system. zIf the granularity is too course ynotifications might hide significant operations that must be made visible to the rest of the system.

WISENElisabetta Di Nitto20 Structure of notifications zAt least three different possibilities:  tuple  record  object class NewSoftwareRelease: public Notification { private String ProductName; private String URL; private Integer ProductRelease; public void Install(); }

WISENElisabetta Di Nitto21 Subscription language zContent-free zSubject-based zContent-based  Single event ProductName=“JEDI”, ProductRelease>1  Event Combination (ProductName=“JEDI”, ProductRelease>1) and (Share=“JEDI”, Variation>10)

WISENElisabetta Di Nitto22 Evaluation: open issues 4Synchronous vs. asynchronous event generation. 4Event granularity. 4Structure of notifications. 4Subscription language. zScalability. *Critical issue: interplay of all these features.

WISENElisabetta Di Nitto23 Ongoing research activities zNotifications with return ticket and synchronous notifications. zStructured notifications (objects). zRicher subscription language. zSupport to application design.

WISENElisabetta Di Nitto24