Basic questions on OpenFire architecture

Openfire Openfire Dev
1

Firstly, I’ve looked at the dev docs I can see online and have had a little wander through the JavaDocs. But what I can’t see are any documents about how Openfire fits together, diagrams showing how packets are routed, etc. I can only in fact see documentation about adding plugins. Does other documentation exist in downloadable content?

Secondly, how modular is Openfire? For instance I see it is set up to let me plug in my own DB for authentication, but what if I want to replace the code which does authentication completely… is the core part of Openfire modular to allow different pieces to be replaced in this fashion? Or is the idea that Openfire is a complete system designed for adding functionality, but not changing the core? For instance I was slightly surprised to be told that Tigase models just about everything as plugins of one type or another, tied together by XML, and I wondered how Openfire compares (not saying either approach is better).

Thirdly, I see references to servlets in the dev guide to plugins. Does this main Openfire is fundamentally based around Servlets as a communication protocol, or is it perhaps using ports, or something else? Is there a key entrypoint class I can see, where packets are initially received by Openfire?

Thanks - sure I’ll have more questions but best not to overload right away!

2

Hello,

You’re right - you don’t find a lot of information on this in the documentation that ships with Openfire. This kind of information is documented in javadoc only (the documentation that is embedded in the source code).

Openfire does not feature an internal pluggable system (OSGI like) that offers one generic plugin architecture for every feature. That said, most of the core functionality is based on interfaces, of which new implementations can be added. Authentication, for example, is performed by classes that implement the AuthProvider interface. There are a number of default implementations available, but you’re free to create your own. Have a look at

http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/javadoc/ org/jivesoftware/openfire/auth/package-summary.html or more specificly http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/javadoc/ index.html for information on how this works.

We’re likely not as “pluggable-by-architecture” as Tigase (although I’m not familiar with their implementation), but in practice things that you’d like to change or modify in Openfire are typically easily changable.

Openfire is not based around Servlets, no. Openfire was developed in a way that would allow you to run it either stand-alone, or in an application server. This is probably where you got the references from. As far as I know, most people run Openfire as a standalone application.

To get an entrypoint in the code of Openfire, I’d start by following an XMPP stanza that arrives on the network. This is roughly what happens:

Openfire uses socket acceptors to receive raw data that is sent. For each type of connection, a specific socket acceptor is instantiated within Openfire. All data that is sent from client connections, for example, is handled by one socket acceptor (although a separate acceptor is used for clients that connect using SSL). All data that is sent from connections from multiplexers (the connectionmanagers) are handled by acceptor. The data sent from external components is handled by yet another acceptor.

A socket acceptor will first put raw bytes into XML. Next, these XML fragments are handed over to a connection handler (specific to the socket acceptor) that will process the data. This is where most of the magic happens: Sessions are opened and closed, XMPP stanzas are parsed from the XML data and are routed through all the appropriate subsystems of Openfire. Eventually, the stanza is delivered to its destination.

In all this, classes like http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/javadoc/ org/jivesoftware/openfire/nio/ConnectionHandler.html play a central role. Start investigating there, I’d suggest.

I hope this helps. Let me know if you need more.

Regards,

Guus

3

Thanks so much for taking the time to write such a detailed reply. Should definitely help me find how to ‘break in’ to understanding the code.

4

Alright, I’ve had a first run of the server, tracing through from init methods in XMPPServer. I have a few slightly more technical questions.

  1. It seems like in one sense Openfire is quite modular, even if it’s not configuration-driven. I’m looking at XMPPServer.loadModules here. However it seems like the concept of a Module is quite vague, I’m not clear how Openfire knows how to use loaded modules so far - I’ll have to dig into one or two perhaps but it looks like Modules are a very open-ended system, a way to load any old lump of functionality.
  2. XMPPServer.loadModules doesn’t appear to load all the modules I thought it would. For instance it doesn’t seem to mention MultiUserChatManager. And as far as I can tell, MUC is implemented as a core feature in Openfire, not a plugin.
  3. On the subject of socket acceptors, I’d like to trace an incoming XMPP all the way from this point, to see how things work from the ground up. Are there specific classes I can look at, and which class would actually create those acceptors? It doesn’t appear like XMPPServer does this directly
  4. Is there any reference mapping the implemented XEPs in Openfire (and plugins) to classes? From the javadoc summary some are clear (like MUC) but being able to see the list of XEPs and where they are found in code would be more helpful as a direct lookup - does this exist?
5

It seems like in one sense Openfire is quite modular, even if it’s not configuration-driven. I’m looking at XMPPServer.loadModules here. However it seems like the concept of a Module is quite vague, I’m not clear how Openfire knows how to use loaded modules so far - I’ll have to dig into one or two perhaps but it looks like Modules are a very open-ended system, a way to load any old lump of functionality.
True, a number of Modules are started (programatically, not by configuration) during initialization of the server. They do have a sort of lifecycle, which can come in handy.

XMPPServer.loadModules doesn’t appear to load all the modules I thought it would. For instance it doesn’t seem to mention MultiUserChatManager. And as far as I can tell, MUC is implemented as a core feature in Openfire, not a plugin.
Apart from a Module (which is quite generic in nature), there’s the concept of a Component. A Component is a very XMPP-specific entity, that is adressable in XMPP, for instance. A lot of functionality that is exposed to XMPP entities (such as MUC) is therefore implemented as a Component.

On the subject of socket acceptors, I’d like to trace an incoming XMPP all the way from this point, to see how things work from the ground up. Are there specific classes I can look at, and which class would actually create those acceptors? It doesn’t appear like XMPPServer does this directly
There are a couple of implementations of socket acceptors in Openfire. The most commonly used ones are based on Apache MINA. This document describes how they are used: Openfires Achilles’ heel

Is there any reference mapping the implemented XEPs in Openfire (and plugins) to classes? From the javadoc summary some are clear (like MUC) but being able to see the list of XEPs and where they are found in code would be more helpful as a direct lookup - does this exist?
No, not as far as I know. Most XEPs define at least one specific namespace (to identify functionality). You could do a text-search for that namespace, which should result in just a few hits. That way, you should be able to identify interesting portions of code quickly.

6

Using MUC as a nice example then, is MUC a plugin or loaded automatically as core code?