Configuration Server Architectural Design

The purpose of this document is to give a high level description of the components and technologies that make up the Configuration Server. Additionally this document was prepared by sipXconfig team to outline the process of rewriting sipXconfig to transform it into open source, extensible platform for management of SIP elements.

Product Description

sipXconfig is a management tool designed to automate and simplify the provisioning and operation of a network of SIP phones. It is our goal to evolve sipXconfig into open platform for mass deploying and monitoring SIP related components. Our customers are both end users (system administrators) who are deploying SIP-based solutions and developers who are adding support for phones, ATAs, gateways and other elements of sip infrastructure.

We want sipXconfig to provide a typical services (profile generation, user management, management UI, log viewer, statistic analyzer) and a plug-in architecture for supporting specific phones, gateways, proxies. We hope that developers and system integrators will be able to assemble sipXconfig based solutions by selecting self-contained services and plug-ins.

It is our vision that support for configuration and monitoring of new entities can be easily incorporated in sipXconfig system by reusing sipXconfig provided services and developing light weight, model driven configuration plug-ins.

Additionally developers should be free to develop parallel services - for example additional, fat client UI rendering engine - and use it to create different incarnations of sipXconfig framework. The sipXconfig platform will remain open to allow for internal and community-wide development of functionality.

We recognize necessity of insuring that sipXconfig platform remains extensible and open. Wherever possible we will implement sipXconfig services employing "extension point" architecture: developers should be able to modify and extend the system by registering external services or extending existing services.

sipXconfig services

As a pluggable framework sipXconfig should be seen as an enabling technology for developing useful solutions. We cannot possibly enumerate today all services that may be part of the platform. Below you can find one of the many possible classifications of sipX services. Some of those are already part of the framework, some are used but not exposed in a way that would enable developers to employ them when designing sipX based solutions, some may be only implemented in the future.

sipXconfig services

The following classification is just a high level draft of what's possible inside of the sipXconfig framework.

Modeling and persistence service:

Transport services:

Management services

UI rendering engines

Automation API services

Framework services

Technical details

Application servers - JBoss etc.

While JBoss is an excellent application server we cannot really justify using it in sipXconfig. JBoss seems to shine in enterprise class application, handling thousands of simultaneous transactions. We need something smaller, easier to install, faster to start.

We suspect that JBoss complexity may hinder wider acceptance of sipXconfig by both users and developers. Because of that we are planning to gradually reduce the dependence on JBoss and EJB technology and replace its parts with widely accepted IOC container (Spring), ORM library (Hibernate) and component-based WEB UI library (Tapestry).

Default UI engine

At the moment sipXconfig support a thin client, WEB based interface, but we are leaving the option of supporting additional rendering engines open. To implement current UI engine we will use only W3C accepted technologies: XHTML for presentation, CSS for styling and customization, limited client side scripting for usability improvements.

We chose Tapestry to implement UI layer because it combines 2 important properties:

To our best knowledge other WEB technologies, while providing some specific benefits, do not combined low level control and high level usability in a similarly elegant manner.

Other libraries and tools - selection criteria

We consider Java standard library and Jakarta commons library to be an accepted java core. We hope that packaging of Java components pretty soon achieves the level of maturity enjoyed by other libraries and tools in Linux world and that we will be able to stop bundling a lot of libraries that we use with sipXconfig, thus reducing the package size and simplifying installation.

We would like to use the best tools available. By the best we mean not only the fastest and newest. The wide acceptance in an open source community, availability of platform specific ports (which is less of a problem in Java world), simplicity of configuration are important factors for us.

When possible we will use just one library for one task. For example we will attempt to reduce that number of XML parsers or database access methods.

We will favor non-invasive, aspect based solutions. We want as much code as possible to be written as plain Java objects, easy to test and reusable on many platforms.

Approval of open source community is an important factor in selecting libraries and tools for sipXconfig.

Development Process

What's not automated is not part of the process. We automatically check the code quality (checkstyle), test it (junit and family) and check the test coverage (clover). We maintain incremental and full builds on several platforms. In future we also intend to automatically check the performance of the sipXconfig,

Test driven design and development is the underlying principle of the sipXconfig development process. Testability influences our design decision, the choice of the tools and libraries. We are suspicious of the code that cannot be automatically tested and we will be gradually eliminating such code.

We prefer to "design as we go" approach to upfront design methodologies. It is our firm belief that it is always easier to extend simple design than to fix an over-engineered one. We will only optimize the design when new features are requested or when problems arise.

Although strict in how we accept contributions, we adopt Eclipse's philosophy that everything is a contribution. The architecture should not get in the way of letting developers and user solve their internal needs, whatever they may be.

We track the progress on JIRA using task and subtask. We attempt to try project velocity (defined as a ration of our estimates to the actual time spent on implementing new features) using JIRA time tracking tools. The content of the next release can be roughly assessed by checking JIRA road-map report.

We develop new functionality by implementing small self contained task. We add features incrementally, one at a time without breaking existing code. At any given moment we are not further than 4 weeks from having a release quality product. All architectural changes are driven by user visible changes.

The Configuration Server Components

server information flow Figure 1 - Configuration Server Context Diagram

The Configuration Server is composed of several processes or components. It was designed in this manner to improve robustness and to allow the different components to run on separate hosts to improve scalability.

Configuration Server Components below describes the main responsibilities of each component.

  1. Profile Generation Server (PGS) - Provides interfaces for users and external systems to interact with SIPxchange.
  2. Profile Writer Server (PWS) - The profile writer manages the writing of the device profiles onto various Content Delivery Servers.
  3. Profile Publisher Server (PPS) (formerly Software Delivery Server - SDS) - provides the SIP client functionality annd manages enrollments, notifications and profile retrieval.
  4. Content Delivery Servers (CDS) - The CDS servers are off-the-shelf servers that the phones use to retrieve the profiles from. We currently support HTTP(S) using Apache and TFTP using the Linux TFTP server.

Profile Generation Server (PGS)

profile generator design

Figure 2 - PGS Component Design shows the layers that exist in the PGS. They can be thought of in terms of tiers. There are the presentation, business and integration and persistence tiers.

Profile Writer Server PWS

profilewriter design

Figure 3 - Profile Writer Design

The Profile Writer is a relatively simple process which takes requests from the PGS to store and delete profiles and informs the PPS when these events occur. Figure 3 - Profile Writer Design shows the basic design of the PW. Requests (remote method invocations) are received over RMI from the PGS. Currently only two methods are used, write and delete profile.

The main thread is responsible for handing incoming requests over RMI, it places Command objects on a queue for the worker thread to process. All synchronization between these threads is done on this queue. The worker thread is used to write/delete profiles and to send method calls over RMI to the PPS.

When the PW gets a request to write a profile it determines what type of device the profile belongs to (Pingtel or Cisco) and then uses this information to decide which CDS to put the profile on. The profile is sent as a byte stream via one of the method parameters. Using RMI enables us to put the PGS and PW on separate servers if required. Once the PW has written the profile to the appropriate CDS it informs the PPS (using RMI) that a new profile is available. For Pingtel devices the PPS will then send a SIP NOTIFY message to the device who this profile belongs to if that device has previously enrolled with the PPS. For Cisco devices the PPS sends a NOTIFY / check-sync message to the device and the device will reboot (which causes it to fetch the new profile from the TFTP CDS).

Profile Publisher Server (PPS)

profile publisher design

Figure 4 - Context Diagram shows the architecture of the ProfilePublisher. The main application logic is contained in the Java Code shown at the top. This code is responsible for:

profile publisher detailed design

Figure 5 - PPS Design shows more details of the Java Code shown in Figure 4 - PPS Context Diagram. The main thread handles remote method invocations from the Profile Writer, creating and en-queuing Command objects onto the command queue. The Profile Listener Worker thread de-queues these command objects from the command queue and executes them.

These command objects are based around notifying devices that they have new profiles or should restart. The command objects use the SIP stack via JNI to send SIP messages to devices. The command pattern provides extensibility so as new uses are found for the PPS new command classes can be added.

The Subscription Listener thread registers with the SIP stack for interest in SUBSCRIBE messages. When it receives those it creates or updates a subscription context in the PPS database. This subscription context is used extensively by the Command objects to find out where to send SIP messages. The RDBMS is used as the means of synchronization between the Profile Worker Listener (Command objects), Subscription Listener and Housekeeper threads.

The Housekeeper thread is used to reap expired enrollments from the PPS database. It wakes up periodically and deletes old records.

Content Delivery Servers CDS

The CDS are off the shelf servers which the devices use to fetch their profiles. We currently support TFTP (used by the Cisco 79XX and Polycom) and HTTP (used by the Pingtel phones).

Last modified: Thu Jun 9 15:34:20 EDT 2004