Consideration on Persistence of WiseMan

1. Consideration on Persistence of WiseMan FuDan-Hitachi InSTech (Innovative Software Technology) Joint Laboratory 2008/03/31

2. outline • Overwiew • Subscriptions’ persistence • Events’ persistence • The other consideration

3. Consideration on persistence • It is very important for a reliable system management application to provide persistence mechanism in WiseMan. • There are subscription persistence & events persistence.

4. Consideration on persistence –cont. • J.F. Denise wrote: I like the idea to persist (I think that we already logged an RFE to have more freedom for context handling). It needs to be designed carefully (allow for pluggable backend, ...). Having the event serializable is a good idea but we can't mandate all events to be Serializable. It needs to be designed first.

5. outline • Overview • Subscriptions’ persistence • Events’ persistence • The other consideration

6. subscribe unsubscribe <<store>> <<delete>> <<load>> Consideration on subscriptions’ persistence Please project this slide. Three operations: 1. store when subscribing 2. delete when unsubscribing 3. load when server restart Client (system management software) WiseMan Server DataBase File Subscription Mgr restart contextMap : Map<UUID, BaseContext>

7. Subscription persistence in current WiseMan • WiseMan has provided one interface by implementing which application developers are able to customize “store” and “delete” operations. • No mechanism to support “load” operation.

8. <<interface>> ContextListener + contextBound(requestContext:HandlerContext, context:UUID) + contextUnbound(requestContext:HandlerContext, context:UUID) Current WiseMan’s support to store & delete operations (1) WiseMan has provided an interface name ContextListener in current version. BaseContext + getListener():ContextListener + … EnumerationContext EventingContext EventingContextWithAck EventingContextBatched

9. Current WiseMan’s support to store & delete operations (2) In current function subscribe(…), the contextBound(…) has been called so that we can implement the contextBound(…) where we customize the store operation. Sequence diagram of subscribe(…) Sequence diagram of initContext(handlerContext, ctx) subscribe:Subscribe BaseSupport contextMap:Map :ContextListener WSEventingSupport request <<create>> uuid:UUID ctx :BaseContext getSubscribe() getDelivery() put(uuid,ctx) <<create>> ctx:BaseContext getListener() contextBound(handlerContext,uuid) initContext(handlerContext, ctx) schedule(uuid,handlerContext,ctx) in contextBound(…), we can store the subscription into file or database

10. Current WiseMan’s support to store & delete operations (3) In current function unsubscribe(…), the contextUnbound(…) has been called so that we can implement the contextUnbound(…) where we customize the delete operation. Sequence diagram of unsubscribe(…) Sequence diagram of removeContext(handlerCtx, uuid) UUID BaseSupport ctx :BaseContext contextMap:Map :ContextListener WSEventingSupport request get(context) getIdentifier() getListener() fromString(identifier) contextUnbound(handlerCtx,uuid) removeContext(handlerCtx, uuid) remove(uuid) in contextUnbound(…), we can delete the subscription from file or database

11. Design of subscriptions persistence (1) public class BaseSupport { public static final Map<UUID, BaseContext> contextMap = new ConcurrentHashMap<UUID, BaseContext>(); static{ … } … } When to “load” subscriptions? We think the load operation should be executed in the static block of class BaseSupport. // TODO : Load subscriptions to contextMap here, we think.

12. Design of subscriptions persistence (2) • Define one set of abstract operations which can support store/delete/load operation. interface ISubscriptionPersistence { boolean store(UUID, BaseContext); boolean delete(UUID); boolean load(final Map<UUID, BaseContext>); } <<interface>> ISubscriptionPersistence PersistenceFile PersistenceDB

13. Design of subscriptions persistence (3) • WiseMan’s users (i.e. application developers) can implement ISubscriptionPersistence to concrete class such as PersistenceFile and PersistenceDB. • WiseMan’s developers can complete the code of PersistenceFile in WiseMan by serializing BaseContext object. • WiseMan’s developers can NOT complete the code of PersistenceDB because we have no idea the database schema.

14. Design of subscriptions persistence (4) If the ISubscriptionPersistence is added, we can add some code to class BaseSupport where we initialize ISubscriptionPersistence before executing the “load” operation as necessary. public class BaseSupport { public static final Map<UUID, BaseContext> contextMap = new ConcurrentHashMap<UUID, BaseContext>(); static{ … } … } public static ISubscriptionPersistence persistence = null; // get the name of concrete class such as wiseman.persistence.PersistenceDB // also including some other information by reading a special configuration file, // then create an instance of ISubscriptionPersistence by reflection mechanism // and assign the instance to the variable persistence. if(persistence!=null) persistence.load(contextMap);

15. Persist to files VS. persist to database • When subscriptions are stored to files • Enable BaseContext serializable • In order to facilitate the operation of delete, we store each subscription as one file whose filename is the UUID of the subscription. • When subscriptions are stored to database, the concrete operation including store, delete and load should be implemented by WiseMan users(i.e. application developers).

16. outline • Overview • Subscriptions’ persistence • Events’ persistence • The other consideration

17. events <<save>> <<retrieve>> <<erase>> events Consideration on events’ persistence Please project this slide. Three operations: 1. save when receiving events from resources 2. retrieve before sending it to client 3. erase after sending successfully Client (system management software) DataBase File WiseMan Server Subscription Mgr

18. Shortage of file persistence • There are too many events. In order to facilitate the retrieving operation, it is more possible to use database in realistic. • As J.F. Denise said, we can't mandate all events to be serializable. • Taking into account all these factors, we only consider the database persistence of events.

19. Sequence diagram of sendEvent(UUID, Object, boolean) in current WiseMan WSEventingSupport :EventingContextPull :EventingContextWithAck HttpClient bctx := retrieveContext(id) :EventingContextBatched :EventingContext filtered := filterEvent(bctx,event,null) [bctx instanceof] [bctx instanceof] [bctx instanceof] [bctx instanceof] sendRequest(…)

20. Design of events persistence (1) • Define one set of abstract operations which can support save/retrieve/erase operation. interface IEventPersistence { boolean save(UUID, Object); Object[] retrieve(); boolean erase(Object); } <<interface>> IEventPersistence This class is implemented by application developer. EventPersistenceDB

21. Design of events persistence (2) • Add a static variable typed IEventPersistence to WSEventingSupport class • public static IEventPersistence eventPersistence = null; • Add a public static method to WSEventingSupport class. This method has to be called in advance when persistence is necessary. • public static void setEventPersistence(IEventPersistence iepersist) { eventPersistence = iepersist ; } • Add a public static method to WSEventingSupport class which is called when WiseMan received an event from resource. • public static void receiveEvent(…) { … } //detail in next slide • Change the function sendEvent(…) from public to protected. • protected static void sendEvent(…)

22. Design of events persistence (3) public static IEventPersistence eventPersistence = null; … public static boolean receiveEvent(final UUID id, final Object event, final boolean filter) { if (eventPersistence!=null) { eventPersistence.save(id,event); Object[] events = eventPersistence.retrieve( ); for(int i=0;i<events.size();i++){ if (sendEvent(id,event,filter)) eventPersistence.erase(events[i]); return true; } else return sendEvent(id,event,filter); } The detail operations of function receiveEvent(…) .

23. outline • Overview • Subscriptions’ persistence • Events’ persistence • The other consideration

24. subscribe unsubscribe <<store>> <<delete>> <<load>> How about persistence on client side ? DataBase File Client (system management software) WiseMan Server If so, we should consider to extend the client API of WiseMan. Subscription Mgr restart contextMap : Map<UUID, BaseContext>

25. save retrieve erase events events How about persistence on client side ? –cont. DataBase File Client (system management software) WiseMan Server If so, we should consider to extend the client API of WiseMan. Subscription Mgr

26. Thank you. Any Comments are welcome!