[bothans-dev] about publish/subscribe request/reply

[Vincent GUILLARD]

Bothans Publish / subscribe system
===============================================

Both publisher and subcriber register.

When the subscriber register , it must identify itself, indicate the subject is interested in, and the callback or message queue where to deliver.
Subject is a hierarchical string whose component are separated by /. Two special wildcard characters can be used "*" and "?".

Publisher, when publishing, must identify itself (when registering it indicates information and receive an id it must give at each publication), indicate the subject and the content.

Publisher must give an heardbeat every 5 second, if no message has been published in this delay. That way the system can detect a crash of a publisher.

Subscriber must know if the subject they requiring are AVAILABLE.
Subscriber can ask to know which subject are available

If subscribing an info managed by a remote core, remote subscription must be engaged.

When subscribing, subscriber receive only messages from this time and not before.


Bothans Request/Reply system
=========================================

Requester must identify, indicate the information it wants (as in the publish/subscribe system)

When a request is finished, a message must indicate it (at least we must know that the request is over).

A time out alert should happen when request are too long. Request time should be indicated in the response.


Bothans Synchronisation system
===========================================

Synchronisation is necessary when we want data from a certain time in the past and the update coming after.
We don't want to loose any information, and , on the other side, we don't want duplicates informations.

Synchroniser first subscribe data needed, on the other side it request all the data from a certain time until now.

Synchroniser can give realtime data from now. For each request information it give only the one not already given (check for duplicate id). Once both action has been achieved, it gives a "synchronisation done".

Then, only updates are forwarded until the subscriber unsubscribe.

Synchroniser has finished when both information have been merged


Questions:
==============

�� We must define the format of information and how to get it (id, sql like language, xml…).
------------------------------------------------------------------------------------------------------------------------------

These are the informations we can ask:
- monitoring information given by service (xml info containing: identification info, status, performance info, special data format)
- target, map, user, …. Config info
- special infos: change status info (given by the data manager when a service status change), internal info (cluster synchro info), gui info (session info)
- archives info from the monitoring archive information (dated informations).
- We can also imagine we want an info on an id, without any idea of what it could be

�� How to handle remote subscription ?
-------------------------------------------------------

See the next question becaus this is quite the same problem: an intermediate subscriber.

�� How to handle map info subscription ?
---------------------------------------------------------

When dealing with map, two kind of information should be taken in account:
- status infos (for group and even services)
- detailed infos (info with last level, status, max, average ….)

It depends how status info are stored in the cluster.

We have decided not to stock status info on the map graph because we tought it could change to fast. But is it a good idea ?

When a map is requested status info for all services in this map must be subscribed.
Then, we should be able to subscribe a map node status info. This will subscribe every underlying service info and give the maximum alert level. Optimizations should be taken in account. In fact it is more interesting to subscribe to the whole services on a map despite the map node used. Indeed, we have more subcribtion to do, but every time the user look for another map node, we don't have to unscribe all of nodes et register the new one. We could thing about "make a diff" between the two, but it complexifies too much the system. On the other hand, if tomorrow, we have thousand of services and all in one map, a core will become overloaded by the informations. That why, put the infos status in the map node appears to be not a bad solution. Moreover, as the monitored service info being unique, no conflict can be encountered (two phases update not needed).

Status info reside on the monitored service info, not on the map because many maps can show the same monitored service. Then status infos will be duplicated on map graph whereas it won't on monitored service graph.

Details info remains on the core managing the service. Detailed infos will appear only when requested by user.

Then we need a subsystem which transforms a map node subscription as the maximum alert info status recursively among all the child from this node. I think this should be more thinked because I don't like the fact that at every change we walk through the graph to find the maximum alert. 


Then the question is : how maintain the fact that in a map each group node contains the maximum alert status info of every child under it. (static variable "parent node status" in every node: when a child change is status, it changes the status of the parent if it is higher or if it was the one that put the highest level. This is recursive). 



Vincent Guillard-Darque


*************************************************************************

 Ce message et toutes les pieces jointes (ci-apres le
 "message") sont
 confidentiels et etablis a l'intention exclusive de
 ses destinataires.
 Toute utilisation ou diffusion non autorisee est
 interdite.
 Tout message electronique est susceptible
 d'alteration.
 NEOCLES et ses filiales declinent toute
 responsabilite
 au titre de ce message s'il a ete altere, deforme ou
 falsifie.

 ********

 This message and any attachments (the "message") are
 confidential and
 intended solely for the addressees.
 Any unauthorised use or dissemination is prohibited.
 E-mails are susceptible to alteration.
 Neither NEOCLES nor any of its subsidiaries or
 affiliates shall
 be liable for the message if altered, changed or
 falsified.

*************************************************************************