|| TODO: Add architecture introduction consisting of architecture feature list -or- just new feature list ||
Jabber, in the form of the XMPP protocol, provides a protocol for messaging, and as such it provides a standardized platform for Jabber server communication:
Figures 13.1 and 13.2 below demonstrate how these three types of communication can occur.
Figure 13.1.1. Jabber Deployment Diagram (High Level View)*:
PC 2 SVR 2 PC 3
.-----------------. .-----------------. .-----------------.
| | | | | |
| ,---------. | | ,---------. | | ,---------. |
| ,' `. | | ,' `. | | ,' `. |
|( Jabber Client -+-------+- Jabber Server -+-------+- Jabber Client )|
| `. ,' | | `. ,' | | `. ,' |
| `---------' | | `----+----' | | `---------' |
`-----------------' `--------+--------' `-----------------'
|
PC 1 |
.-----------------. .--------+--------.
| | | | | SVR 1
| ,---------. | | ,----+----. |
| ,' `. | | ,' `. |
|( Jabber Client -+-------+- Jabber Server )|
| `. ,' | | `. ,' |
| `---------' | | `----+----' |
`-----------------' | | |
| ,----+----. |
| ,' Foreign `. |
|( IM )|
| `. Gateway ,' |
| `----+----' |
`--------+--------'
|
|
.--------+--------. .-----------------.
| | | | |
| ,----+----. | | ,---------. |
| ,' Foreign `. | | ,' Foreign `. |
|( IM -+-------+- IM )|
| `. System ,' | | `. Client ,' |
| `---------' | | `---------' |
`-----------------' `-----------------'
SVR 3 PC 4
Figure 13.1. Adapted from XMPP Core Draft
Figure 13.1.2. Key to Deployment Diagrams:
Key for Deployment Diagrams
+--------------------------------------------+
| |
| +-------------+ TCP/IP Connection |
| |
| ,---------. |
| ,' `. |
| ( ) Software Package |
| `. ,' or Module |
| `---------' |
| |
| .---------------. |
| | | |
| | | Computer: |
| | | PC or Physical |
| | | Server |
| `---------------' |
| |
+--------------------------------------------+
In the diagram above, Jabber Clients on PC 2 and PC 3 are able to communicate via Jabber IM provided by SVR 2. Both clients have accounts on this server, and this part of the diagram, if taken by itself, would represent a closed or private Jabber system.
Note that a Jabber Client is not necessarily a user-based IM client. For example, the client running on PC 3 might actually be part of a web server. In this manner, a user on PC 1 might make updates to the web server by using a Jabber client.
Communication between SVR 1 and SVR 2 demonstrates how Jabber employs a distributed architecture. Clients on PC 1 and PC 2 are able to communicate with each other even though these clients have accounts on separate servers. These clients do not need to know anything about the remote servers. Instead, each client needs only to know the address of the client with which it wishes to communicate.
Jabber servers running on SVR 1 and SVR 2 rely on the Domain Name Service (DNS) for address lookup in order to communicate with each other. In this manner, the Jabber IM system resembles the email network architecture provided by POP and SMTP, the most widely used email protocols on the Internet. The ability to resolve names of other jabber servers and to route messaging makes jabber unlike proprietary IM systems. Jabber does not rely on a centralized server farm. Thus, Jabber is easily scalable, and it can be used as a closed or open system.
In this diagram, SVR 1 communicates with a Foreign IM Gateway running on the same machine. This gateway is able to communicate with a Foreign IM System, such as AOL, MSN, Yahoo or IRC. Connection with this communication gateway allows clients on PC 1 and PC 4 to communicate despite the fact that the user on PC 1 is running Jabber client software, while the user on PC 4 is running software, such as AIM, that uses a completely different messaging protocol.
The foreign IM example demonstrates the flexibility that Jabber provides. The XMPP protocols dictate set of XML-based communication standards. Therefore, a gateway for other protocols can be created, provided that the details of such a non-XMPP protocol are known.
The beauty of the Jabberd 2 architecture lies in the fact that its component architecture distributes services across five components, each of which communicates over TCP/IP:
Jabberd 2 also relies on third-party components:
Figure 13.2 shows how these components communicate and how they are generally located on a single physical server.
Figure 13.2. Jabberd Deployment Diagram (Component Level View):
PC 1 SVR 2 SVR 3
.-----------------. .-----------------. .-----------------.
| | | | | |
| ,---------. | | ,---------. | | ,---------. |
| ,' `. | | ,' `. | | ,' Foreign `. |
|( Jabber Client )| |( Jabber Server )| |( IM )|
| `. ,' | | `. ,' | | `. System ,' |
| `----+----' | | `----+----' | | `----+----' |
`--------+--------' `--------+--------' `--------+--------'
| | |
| | |
.---------------------------------+----------------------+----------------------+----------.
| | | | |
| ,---------. ,----+----. ,----+----. | |
| ,'Authentica-`. ,' Client to `. ,' Server to `. | |
| ( tion Data +-----+ Server ) +--+ Server ) | |
| `. Package ,' `. (C2S) ,' | `. (S2S) ,' | |
| `---------' `----+----' | `---------' | |
| | | | |
| | | | |
| | | | |
| ,----+----. | ,---------. | |
| ,' `+----+ ,' `. | |
| ( Router +------+ Resolver ) | |
| `. +----+ `. ,' | |
| `----+----' | `---------' | |
| | | | |
| | | | |
| | | | |
| | | | |
| ,---------. ,----+----. | ,----+----. |
| ,'Application`. ,' Session `. | ,' Foreign `. |
| ( Data +-----+ Manager ) +-------------------------+ IM ) |
| `. Package ,' `. (SM) ,' `. Gateway ,' |
| `---------' `---------' `---------' |
`------------------------------------------------------------------------------------------'
SVR 1
Figure 13.2.1 shows how Jabberd 2 distributes functions across five separate modules. Just as the data stores and gateway(s) may be located on separate machines, the Jabberd 2 components may be easily distributed across machines because each component consists of a configuration file and a binary executable that communicates via TCP/IP. This architecture allows the server to scale. When load on a Jabberd 2 server becomes high, component(s) can be moved to separate machines.
The Router is the backbone of the Jabberd server. It accepts connections from Jabberd components and passes XML packets between components.
The S2S (Server to Server) component handles communications with external servers. S2S passes packets between other components and external servers, and it performs dialback to authenticate remote Jabber servers.
The Resolver acts in support of the S2S component. The Resolver resolves hostnames for S2S as part of dialback authentication.
The SM (Session Manager) component implements the bulk of the instant messaging features:
The SM component connects to the "Application Data Package (db) in order to provide persistant data storage. Additionally, the SM component handles the Jabber extensions of disco (discovery) and privacy lists*.
The C2S (Client to Server) component handles communication with Jabber clients:
The C2S component connects to the Authentication Data Package (authreg) in order to register and authenticate users.
|| TODO: Section TBD ||
Jabberd employs data handling that allows for mapping to various data packages. The concept of a collection object lies at the core of Jabberd data handling. Each collection object has the attributes of type and owner. Type specifies what category of data is being handled, such as queue, vcard or roster-items. Owner specifies who owns the collection. For user-related data, Owner is a jabber ID (JID).
Each collection holds one or more data objects. Each of these data objects is a tuple consisting of a key, value and type. Key is a string that specifies the kind of data being held. Value is the data being held, and type is the is the data type, i.e. Boolean, integer, string, etc. The diagram below shows how these objects are related.
Figure 13.4. Jabberd Data Objects:
+--------------+
| Collection |
+--------------+---+
| Collection | |
+--------------+---+ |
| Collection | | | Key for Object Diagram
+--------------+ | | +-------------------------------------+
| Type | |---+ | |
| Owner | | | +-------+ |
| |---+ | | | |
| | | +-------+ Object |
+--------------+ | | | |
| | | | |
| | +-------+ |
| | | |
| | | One-to-Many Relationship |
^ | | |
+-------------------+ | ^ |
| Collection Data | | |
+-------------------+ +-------------------------------------+
| Key |
| Value |
| Type |
| |
+-------------------+
Jabberd Data handling becomes clearer as we see it applied to the MySQL data package. In the relational world, each collection type becomes a table, and each collection data key becomes a table field. Thus, each row consists of a collection owner (JID) plus one or more data fields.
The following is a list of MySQL tables for a deployment that uses Jabberd for both its authentication and its application data package (authreg and db, respectively):
Each of the above tables represents a collection type in Jabberd. Note that the authreg table handles the authentication aspect for Jabberd when MySQL is used as the authentication data package.
Descriptions for the Jabberd tables (as they exist in MySQL) appear in the diagram below:
Figure 13.5.2. Jabberd Table Descriptions:
MySQL Table Descriptions
+------------------------------------------------------------------------------------------------------------+
| |
| +-------------------------------+ +-----------------------+ +------------------------------+ |
| | active | | authreg | | disco-items | |
| +-------------------------------+ +-----------------------+ +------------------------------+ |
| | | | | | | |
| +-------------------------------+ +-----------------------+ +------------------------------+ |
| | collection-owner: TEXT | | username: TINYTEXT | | collection-owner: TEXT | |
| | object-sequence: BIGINT(20) | | realm: TINYTEXT | | object-sequence: BIGINT(20) | |
| | time: INTEGER(11) | | password: TINYTEXT | | jid: TEXT | |
| | | | token: VARCHAR(10) | | name: TEXT | |
| +-------------------------------+ | sequence: INTEGER(11) | | node: TEXT | |
| | | | hash: VARCHAR(40) | | | |
| +-------------------------------+ | | +------------------------------+ |
| +-----------------------+ | | |
| | | +------------------------------+ |
| +-----------------------+ |
| |
| |
| +-------------------------------+ +------------------------------+ +-------------------------------+ |
| | logout | | motd-message | | motd-times | |
| +-------------------------------+ +------------------------------+ +-------------------------------+ |
| | | | | | | |
| +-------------------------------+ +------------------------------+ +-------------------------------+ |
| | collection-owner: TEXT | | collection-owner: TEXT | | collection-owner: TEXT | |
| | object-sequence: BIGINT(20) | | object-sequence: BIGINT(20) | | object-sequence: BIGINT(20) | |
| | time: INTEGER(11) | | xml: TEXT | | time: INTEGER(11) | |
| | | | | | | |
| +-------------------------------+ +------------------------------+ +-------------------------------+ |
| | | | | | | |
| +-------------------------------+ +------------------------------+ +-------------------------------+ |
| |
| |
| +------------------------------+ +-------------------------------+ +------------------------------+ |
| | privacy-default | | privacy-items | | private | |
| +------------------------------+ +-------------------------------+ +------------------------------+ |
| | | | | | | |
| +------------------------------+ +-------------------------------+ +------------------------------+ |
| | collection-owner: TEXT | | collection-owner: TEXT | | collection-owner: TEXT | |
| | object-sequence: BIGINT(20) | | object-sequence: BIGINT(20) | | object-sequence: BIGINT(20) | |
| | default: TEXT | | list: TEXT | | ns: TEXT | |
| | | | type: TEXT | | xml: TEXT | |
| +------------------------------+ | value: TEXT | | | |
| | | | deny: TINYTEXT(4) | +------------------------------+ |
| +------------------------------+ | order: INTEGER(11) | | | |
| | block: INTEGER(11) | +------------------------------+ |
| | | |
| +-------------------------------+ |
| | | |
| +-------------------------------+ |
| |
| |
| +------------------------------+ +------------------------------+ +-------------------------------+ |
| | queue | | roster-groups | | roster-items | |
| +------------------------------+ +------------------------------+ +-------------------------------+ |
| | | | | | | |
| +------------------------------+ +------------------------------+ +-------------------------------+ |
| | collection-owner: TEXT | | collection-owner: TEXT | | collection-owner: TEXT | |
| | object-sequence: BIGINT(20) | | object-sequence: BIGINT(20) | | object-sequence: BIGINT(20) | |
| | xml: TEXT | | jid: TEXT | | jid: TEXT | |
| | | | group: TEXT | | name: TEXT | |
| +------------------------------+ | | | to: TINYTEXT(4) | |
| | | +------------------------------+ | from: TINYTEXT(4) | |
| +------------------------------+ | | | ask: INTEGER(11) | |
| +------------------------------+ | | |
| +-------------------------------+ |
| | | |
| +-------------------------------+ |
| |
| |
| +-------------------------------+ +------------------------------+ |
| | vacation-settings | | vcard | |
| +-------------------------------+ +------------------------------+ |
| | | | | |
| +-------------------------------+ +------------------------------+ |
| | collection-owner: TEXT | | collection-owner: TEXT | |
| | object-sequence: BIGINT(20) | | object-sequence: BIGINT(20) | |
| | start: INTEGER(11) | | fn: TEXT | |
| | end: INTEGER(11) | | nickname: TEXT | |
| | message: TEXT | | url: TEXT | |
| | | | tel: TEXT | |
| +-------------------------------+ | email: TEXT | |
| | | | title: TEXT | |
| +-------------------------------+ | role: TEXT | |
| | bday: TEXT | |
| | desc: TEXT | |
| | n-given: TEXT | |
| | n-family: TEXT | |
| | adr-street: TEXT | |
| | adr-extadd: TEXT | |
| | adr-locality: TEXT | |
| | adr-region: TEXT | |
| | adr-pcode: TEXT | |
| | adr-country: TEXT | |
| | org-orgname: TEXT | |
| | org-orgunit: TEXT | |
| | | |
| +------------------------------+ |
| | | |
| +------------------------------+ |
| |
+------------------------------------------------------------------------------------------------------------+
© 2003 Will Kamishlian and Robert Norris
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/1.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.