If you followed the previous chapter through you should now have a Jabber server of your own up and running. If you did go ahead and make the configuration changes described there, you may be curious to find out about the other 99 percent of the configuration file contents - what they do, what sort of structure (if any) exists, and how you might modify the configuration to suit your own requirements.

Despite the initially daunting and seemingly random nature of the jabber.xml file contents, there is a structure to the configuration. This chapter will take you through that structure, explaining how all the pieces fit together, and describing what those pieces do. In order to understand the configuration structure, we examine the nature of the server architecture itself. This architecture is reflected in that structure, and if we are to understand the latter, it helps to understand the former.

Indeed, in order to take the best advantage of what Jabber has to offer in terms of being a basis for many a messaging solution, it's important to understand how the server works, and how you as a programmer fit in. Jabber programming solutions can exist at different levels within the Jabber architecture; understanding this architecture can help you make better decisions about what needs to be done to build a solution.

So in this chapter, we'll take a look at the Jabber server architecture, and follow that by an in-depth tour of the server configuration in jabber.xml. Finally we'll have a look at some of the server "constellation" possibilities—how you can organize parts of the server to run over different hosts, and how you can make the server host multiple virtual server identities.