Confluence 2.9 : Confluence Services
This page last changed on Dec 17, 2007 by jnolen.
Here's a quick overview of some of the services defined in Confluence (for more details of what a service is, see the High Level Architecture Overview). Current ServicesDatabase ServiceThis service is defined in databaseSubsystemContext.xml and productionDatabaseContext.xml. It provides database connectivity and Hibernate ORM to the application. The reason for splitting the service into two files is to allow for easier testing. productionDatabaseContext.xml extracts the database configuration from the bootstrap configuration, and brings up Confluence with the Tangosol Coherence clustered cache. If you substitute that one file with testDatabaseContext.xml you will instead get a pre-configured in-memory HSQL database and in-memory caching. Because configuring Hibernate dynamically is non-trivial, the database service is unavoidably dependent on every class we want to persist via Hibernate. You can see this in the list of .hbm.xml files loaded in databaseSubsystemContext.xml. Bandana ServiceProvides a generic configuration/preferences storing service using XStream to serialize POJO configuration objects to XML. Confluence's bandana service persists to the database. Cache ServiceProvides centralised caching services backed by Tangosol Coherence, and a transactional cache service. Defined in cacheServiceContext.xml. In integration tests, you might want to substitute testCacheServiceContext.xml which provides a basic in-memory cache without the overhead of Coherence. Event ServiceProvides a simple service for producing and consuming events. Defined in eventServiceContext.xml. Confluence's event service is cluster-aware, distinguishing between events that are limited to a single node of the cluster, and events that must be broadcast to every node. Plugin ServiceProvides the Atlassian plugin framework, in pluginServiceContext.xml. Confluence's plugin service is customised to deal with bundled plugins (plugins that are provided with the application but that may be upgraded by the end user), and to behave mostly sanely in a cluster. The plugin system hasn't been entirely service-ised yet, as all the different plugin module loaders result in dependencies back to whatever subsystem they're being plugged into. Task Queue ServiceA central manager for queues in Confluence. I'm not entirely sure this should exist as it currently adds no value whatsoever beyond being a lookup mechanism, which Spring does already. Not ServicesThings that should be services, but aren't. Quartz SchedulingPretty obvious next candidate for servicization, but possibly tricky because the Spring/Quartz integration might not be very friendly. Backup/RestoreSomething to keep in mind if we clean up the backup/restore code User ManagementI wasn't going to mess with user-management while there was a different atlassian-user task in the release pipeline. Wiki RenderingThis seems like a reasonably trivial candidate to convert to a service. There's only one dependency on non-service code (the image renderer depends on the attachment manager). Mail (sending and receiving)The sending and receiving of email is currently a mess of singleton configurations, clients sticking mail jobs directly on the queue, and very little going through Spring at all. This should be fixed. External Network AccessIt would be nice to have Confluence provide a service for accessing the outside world so we can throttle number of connections, provide central configuration of time-outs and authentication, and so on. Image ManipulationRight now we have a thumbnail manager that lives with attachments, but it would be nice to make this more generic, and at least support multiple thumbnail sizes. |
![]() |
Document generated by Confluence on Aug 07, 2008 19:08 |