XMPP service. System Facade

In previous posts (here and here) I’ve started describing XMPP subsystem and analyzing requirements. Before we proceed with the analysis of  requirements (8)+ it’s time to create overview of current structure

XMPP System Facade

The diagram above reflects current components of XMPP Subsystem. They implement requirements (1)-(7) from the main requirements list. Before we continue with analysis of requirements (8)-(14) lets review all active classes  and determine how the subsystem will be created, initialized and shut down.

XmppService and all it’s main components heavily use SysLog for logging various events (e.g. notifications, failures etc). So initially SysLog instance should be created. You can read about system logging here. I hope that someday I’ll create separate post about it… After creation of system log the XmppService can be instantiated. Then the service creates MessageProcessor (by design it is the plugin manager) which will be responsible for processing incoming xmpp messages. We will look at the plugin manager later.

XmppService contains Connection which manages actual connection to remote xmpp server. Connection is also responsible for creation Room instances.  So XmppService initially creates Connection instance and delegates the creation of all needed rooms to the Connection. There is one thing that should be taken into account. Rooms can be created by Connection only when it is in connected state (in other words the actual underlying connection to remote xmpp server has been established and the user has been logged in). At this point we have to separate two actions which can be performed on service:

1. Instantiation of service. We create Connection and other stuff which is persistent between sessions. It means that some objects do not depend on the actual connection’s state (opened, logged in, closed and so on). They can be created once and reused between sessions. By session I mean the connection to remote xmpp server, authorization and authentication, normal workflow and finally disconnection. Once connection becomes actually disconnected from remote xmpp server the session is assumed to be closed. On reconnection and successful logging in the session is assumed to be opened.

Broadly speaking instantiation of service invokes creation if Connection. Once Connection has been created TransportQueue can be instantiated. After that we can attach this transport queue to MessageProcessor in order to provide the ability to send xmpp messages back to server by plugins andMessageProcessor itself.

2. Starting up the service. We create all needed Room instances and other stuff which is dependent on the Connection‘s state. As we described above rooms can be instantiated only when Connection is in opened, logged in and authorized state.

Let’s review the first action in details and start from sequence diagram.

XMPP System Instantiation

XmppService itself is shown in read.  Note that active objects are created but not started.

Now let’s see service start up:

Service start up

First of all service start MessageProcessor and TransportQueue. Then it calls StatusWatcher in order to handle underlying Connection. Finally it  calls StatusWatcher for each Room instance of Connection. Status watcher is responsible for reconnecting to remote server in the case of Connection and rejoining Room in the case of Room. During service startup connection is in disconnected state and each room is not in joined state, so StatusWatcher will attempt to open connection and then rejoin all rooms.

Finally let’s illustrate service shutdown:

XMPP System Shutdown

After service receives shutdown call it stops MessageProcessor and TransportQueue. Then it removes all messages from transport queue and stops StatusWatcher. Then service is considered to be stopped and can be started once again (if needed).

I’ve uploaded all sources into SVN of jxmpp-bot project. Next time we’ll talk about plugins management