Package org.bedework.synch

Class SynchEngineImpl

  • All Implemented Interfaces:
    SynchEngine, org.bedework.util.calendar.XcalUtil.TzGetter, org.bedework.util.logging.Logged
    public class SynchEngineImpl
extends Object
implements org.bedework.util.logging.Logged, SynchEngine, org.bedework.util.calendar.XcalUtil.TzGetter
    Synch processor.

    The synch processor manages subscriptions made by a subscriber to a target. Such a subscription might be one way or two way.

    There are two ends to a subscription handled by connectors. The connectors implement a standard interface which provides sufficient information for the synch process.

    Synchronization is triggered either when a change takes place - through some sort of push-notification or periodically.

    For example, we might have a one way subscription from bedework to exchange. Exchange will post notifications to the synch engine which will then resynch the modified entity.

    Alternatively we might have a subscription to a file which we refresh each day at 4am.

    A subscription may be in the following states:

    • dormant - that is there is no current activity, for example a file subscription with a periodic update,
    • active - there is some active connection associated with it, for example, an Exchange push subscription waiting for a notification
    • processing - for example, an Exchange push subscription which is processing a notification
    • unsubscribing - the user has asked to unsubscribe but there is some activity we are waiting for

    Interactions with the calendars is carried out through an interface which assumes the CalWs-SOAP protocol. Messages and responses are of that form though the actual implementation may not use the protocol if the target does not support it. For example we convert CalWs-SOAP interactions into ExchangeWS. --------------------- ignore below ----------------------------------------

    This process manages the setting up of push-subscriptions with the exchange service and provides support for the resulting call-back from Exchange. There will be one instance of this object to handle the tables we create and manipulate.

    There will be multiple threads calling the various methods. Push subscriptions work more or less as follows:

    • Subscribe to exchange giving a url to call back to. Set a refresh period
    • Exchange calls back even if there is no change - effectively polling us
    • If we don't respond Exchange doubles the wait period and tries again
    • Repeats that a few times then gives up
    • If we do respond will call again at the specified rate
    • No unsubscribe - wait for a ping then respond with unsubscribe

    At startup we ask for the back end system to tell us what the subscription are and we spend some time setting those up.

    We also provide a way for the system to tell us about new (un)subscribe requests. While starting up we need to queue these as they may be unsubscribes for a subscribe in the startup list.

    Shutdown ought to wait for the remote systems to ping us for every outstanding subscription. That ought to be fairly quick.

    Author:
    Mike Douglass