1. Summary
  2. Files
  3. Support
  4. Report Spam
  5. Create account
  6. Log in

Introduction

SSL-Explorer (from which Adito was forked) had two versions: Community edition and Enterprise edition. 3sp - the firm behind SSL-Explorer - made money by selling software licenses to Enterprise edition which had several proprietary Enterprise extensions. The way 3sp made money had a few effects on the software itself:

  • The Enterprise Edition had to have some value add-ons to differentiate it from the Community Edition. This is the main reason for the Adito Enterprise Extension project. This is not actually related to the standardization effort.
  • SSL-Explorer had to be easy to install. If potential buyer could not install it, he would never pay for it.
  • SSL-Explorer had to be easy to use. This meant that there had to be several easy-to-use features not needed when maintained by professional system administrators (e.g. restarting SSL-Explorer from within SSL-Explorer).

These things should not be a high priority for a community open source project, but they nevertheless show in current Adito code. The most important thing is that the application is not deployable on a standard web container. Instead, it

  • Uses a custom boot module to launch itself
  • Utilizes an embedded Jetty and a custom Context instead of running inside an external [container]
  • Uses a Java service wrapper to allow some fancy things not possible in typical Java application.

As 3sp did all SSL-Explorer development themselves, they did not need to work with the community developers. This is clearly visible in SSL-Explorer's build system, which was pretty difficult to use, poorly documented and very prone to breakage. This is not acceptable in a community project.

For more technical information, take a look at list of non-standard parts in Adito?.

Why standardize?

In order to get developers to develop for Adito it has to be as easy to compile, understand and develop as possible. In other words, it has to be approachable (from a developer perspective). Only very motivated (or paid) developers will be willing to spend time understanding oddities of yet another large application. Those developers who only have a couple of hours a week to spare may not be able to contribute at all if there are too many non-standard parts to learn. In addition all time used to learn unnecessary Adito-specific stuff is wasted time. Hopefully standardization will go a long way in helping future Adito developers.

Another benefit from (webapp) standardization is that it allows Adito users (and developers) to replace some of the Adito's 3rd party components in any way they please. For example somebody might want have solid reasons to run Adito inside Tomcat instead of using Jetty. This, too, would make participation easier as people can use the applications they feel comfortable with. It also allows great flexibility in how Adito is deployed - something which Barracuda's SSL appliance will never be able to offer.

Parts of the standardization project

Migrating from Ant to Maven2

Migrating from Ant build system to Maven2 allows us to get rid of the really complex ant build system that consumes lots of valuable developer time. Developers who know one Maven2 project can move on to another one without much of a hassle. With ant every build system is different.

Making Adito a more standard web application

Adito Javadocs give some reasons as to why 3sp did not simply make SSL-Explorer a standard web application:

Whilst Adito is largely a standard web application, it has requirements of its environment above and beyond this.
The environment that services these requires is known as the Context. There should be a single instance of the
implementation of this interface and it should be registered with com.adito.boot.ContextHolder#setContext(Context).
The instance of the context may then be accessed in the web application and boot classes using
com.adito.boot.ContextHolder#getContext().

The context responsibilities include :-
* Service control. I.e. shutdown and restart
* Provide locations to store configuration, temporary files, logs etc
* Provide an HTTP server to serve web content and handle custom HTTP connections
* Provide and manager databases used for storing configuration and Adito resources
* Obfuscating / deobfuscating passwords
* Configuring the class loader
* Providing storewhere to store Context properties, i.e. those that are only applicable to this Context implementation

Part of these responsibilities have been moved away from the Context as of 18th Feb 2009. No showstoppers have been identified, either, so "web applification" is proceeding as planned. There is some non-webapp functionality that can't be removed, because they need to operate outside the web application. Most important is the server-side Agent component that provides SSL-tunneling.

In the end, Adito will be releases as a software bundle including the following components:

  • A web server / servlet container (Jetty)
  • A database (HSQLDB)
  • Adito server web application (WAR)
  • Adito extensions (agent, networkplaces, etc.)
  • A bunch of service control scripts

Making Adito database-agnostic

Current Adito is tied to it's embedded HSQLDB database. It is possible to allow TCP/IP connections to this internal database - in effect using it in non-embedded mode. In this mode the database is referenced to with a JDBC URI. It is trivial to replace the embedded database with and external one. Starting with an external HSQLDB is probably easy, but support for PostgreSQL/MySQL/whatever should be trivial to implement later on. Using an external database will allow wider range of deployment scenarios. It also makes things like load balancing much easier.

Replacing obsolete custom code

The various maverick packages contain obsolete, 3sp-written code. For example, the maverick-crypto package contains custom implentation of cryptographic hashing functions. In addition the various authentication modules duplicate functionality that's already available in standard Java packages and/or external projects. This kind of custom solutions are unnecessary, require maintenance, are not well tested and can pose a security risk. Therefore these need to be replaced with external code that's being maintained and tested actively.

Here's a list of custom code found from Adito and plans for replacing them: