Architecture

Physical Architecture

client/server (in fact, 3-tiers)
- Rich client application (Java/Swing)
- Servlet container (Servlet 2.3 compliant)
  - HiveBoard Web Archive (exposes "Web Services" based on Caucho's Hessian protocol)
- SQL DBMS (any server with a JDBC Driver)
  - HiveBoard DB schema
multi-server
- Central server (including DBMS)
- Federated servers (no DB) are just seen by the central server as "special" clients

Central Server Architecture

The central server -contrarily to federated servers- is responsible for the persistent storage of all data to a DBMS.

In addition, as all federated servers, it stores most information in memory at all times (list of authorized accounts and their current status, list of active whiteboards with their current status). Storing the most often accessed information in memory reduces the amount of database access, thus increasing the overall performance of the system. The only piece of information that is not permanently stored in memory is the pixmap image for each whiteboard (this would be too costly in terms of memory usage).

Most often, database modification statements are performed in deferred mode, whenever possible.

Following is a simple description of the various layers of important objects in the central server:

Servlet Filters
1. PerformanceMonitorFilter (from HiveUtils module): logs requests performance
2. GzipFilter (from HiveUtils module): uncompresses gzipped requests and compresses responses for higher network transfer rates
3. HiveMindFilter (from HiveMind library): ensures that HiveMind Registry is available to current request
4. VersionControlFilter (from HiveBoard): ensures compatibility between the calling client application and the current server
5. HiveMindRegistryPublishFilter (from HiveUtils module): publishes HiveMind Registry in a ThreadLocal to make it accessible to HiveBoardRealm
6. SecurityFilter (from SecurityFilter library): checks credentials and possibly authenticates new connections through the HiveBoardRealm
7. HiveLockFilter (from HiveLock module): puts current user Principal into HiveLock SecurityService
CauchoRemotingServlet (from HiveRemoting library): dispatches Hessian requests to WhiteBoardUserService
Services (in the context of HiveMind)
1. WhiteBoardUserService: uses the "user" ServiceModel (stateful service), delegates all calls to WhiteBoardManager, except the pull method that gets the list of pending events from the current user's events queue. Acts as a facade.
2. WhiteBoardManager: the core of the system, centralizes all requests, generate events and pushes them to a Channel (managed by HiveEvents module) which will in turn put them at disposal of WhiteBoardUserService instances. The list of accounts (in memory) is delegated to AccountRepository service and the list of whiteboards (in memory) to BoardRepository service. Any SQL statements that can be deferred are delegated to the TaskPerformer service.
3. AccountDAO, BoardDAO: services used to access database. All based on iBATIS SqlMaps (through HiveTranse library)

Multi-Server Architecture

In this architecture, there exists a central server (as described above) plus a certain number of federated servers.

A federated server has no DB on its own. It connects to the central server through a specific service (still based on Hessian protocol over http/https transport).

On the central server, this special service stores the following about a federated site:

list of currently connected users
list of rooms for which there is at least one user connected to the remote site declared as participant to this room
list of rooms for which there is at least one one user connected to the remote site currently present in the whiteboard room

Based on this information, the central server filters events to be forwarded to the federated server. Event forwarding is done using a push-model. When the federated server receives events, they are forwarded to the connected users following the same rules as for users directly connected to the central server.