KITE Afterthoughts
J. Templ, Nov. 8th, 2004
The basic structure of the application server
KITE
is nowadys known as an IoC container or an IoC framework,
where IoC stands for 'Inversion of Control'.
Popular projects which develop around this notion are Apache Avalon/Turbine,
PicoContainer/NanoContainer, Spring, or OSGI, to name just a few.
Often, such a system is also called a 'lightweight' container as opposed to an Enterprise
Java Beans (EJB) container, which is usually considered to be a heavyweight container
both in terms of conceptual complexity and in terms of runtime resources needed.
KITE and many if not all of the mentioned approaches are essentially a non-standard
alternative to EJB.
The term IoC has been criticized by Martin Fowler and the alternative term 'Dependency Injection'
has been coined by Fowler. We agree with Fowler that the term IoC should be avoided because
inversion of control is a property of every framework and thus fails to characterize a
particular kind of framework. We are not sure, however, if dependency injection
is a much better term as it focuses around the ways of specifying dependencies between
services, which is only one aspect to be solved. In our oppinion, the pattern being
employed is nothing else but that of the 25 years old module loader or the
10 years old class loader with imports specifying the relationships
and with the important property that a module or class is being loaded only once into
a container, thus modules and classes serve as a static decomposition of an application.
This can be adapted easily to a service container dealing with
service instances rather than loading modules or classes.
Interface versus Implementation
A major difference between the newer projects and KITE is that KITE is both
a specification AND an implementation, whereas Avalon or PicoContainer, for example, are
a domain independent set of interfaces to be implemented by other
more domain specific projects. Seen as a specification, the
package kite.service roughly corresponds with Avalon,
for example. KITE is not intended to be a general purpose container
for an unknown target domain, but a container for the needs of an application
server to be used in the context of E-business applications. Therefore it can focus
on the needs of these usage scenarios, drop any exotic or speculative features,
and provide exactly the required support in the base architecture.
The resulting architecture is not explicitly targeted at E-Business applications,
but designed such that the kind of services, that are required can be
provided and combined easily. There is no database service in the KITE architecture,
for example, but the architecture allows one to introduce a database service
and even higher level services on top of a database service.
Since KITE provides a number of non-trivial standard services and service containers,
it is proven that the architecture is well suited at least for the intended target domain.
In particular KITE service containers provide features such as
transparent local or remote usage,
remote execution with compression and/or encryption and/or tunneling via http,
hot deployment of applications, clustering of servers,
localization of services, a concept for exeption handling, and a concept
for flexible and convenient configuration of applications.
The available standard services include logging, advanced database access, and OR-mapping.
Exception Handling
The life cycle model of KITE is rather simple compared with other
approaches but more advanced in at least one respect: exception handling.
KITE provides a conceptual framework and life cycle support for resetting services
contained in a service container after an exception has been caught.
The basic idea is that exceptions should only be used for handling 'unexpected'
situations, not as an alternative for function results. If an exception is thrown, there
is no way except informing the user (i.e. the top level program that invoked a service)
of the exception. Hiding the exception by catching it somewhere at a deeper level is
counter productive and impossible in the general case, because the service cannot
know about the state of other services that might need to be reset.
An example is a user action that invokes a sequence of different
services with a database transaction being involved.
Now if one of the non-DB-services throws an exception, the database transaction
must be rolled back, but this cannot be known to the faulty service. Therefore KITE
requests that exceptions are propagated to the top level and are thus handled at a central
place. The top level exception handler informs the user and
resets the service container, which in turn resets all
services of the container. In our experience, it is a widespread
misunderstanding that local exception handlers
together with exceptions declared explicitly in a method's signature improve the
quality of all programs. For frameworks the opposite is true. A framework cannot
anticipate the implementation of its plugins and therefore has to cope with all kinds of
exceptions. In other words, a framework has to expect the unexpected.
The omission of such a concept for exception handling in more recent
approaches is a severe problem for reliable and systematic exception
handling in application development.
Configuration
It might appear as a trivial addendum to many application developers that
most services need to be configured in order to work properly.
A database service, for example, needs to know the parameters for opening
a database connection. In practice it turns out that configuration is
a time consuming and error prone task that deserves some support.
Most approaches use XML and document type definitions (DTD)
for configuration tasks. KITE introduced the notion of
profiles (property files) as a hierachical Java property file and property type
definitions (PTD) for specifying the names and types of properties.
In addition, KITE supports inheritance of property types, which is not supported
by DTD and poorly supported by other schema definition languages.
A KITE property type definition may be defined as an extension of another
property type definition, which introduces polymorphism and compatibility between
the base type and the extensions. Thus, a KITE application profile can for example
be declared as a list of services, where every service has some basic properties and
according to the particular service class it can introduce additional properties.
A generic profile editor provides a GUI for defining properties and abstracts from
the underlying implementation. We found property inheritance of paramount importance
for organizing the configuration of applications. Surprisingly, it seems that this is not a topic
for any of the alternative general purpose approaches.
Complexity
A short look into alternative approaches unveils that all of them are
considerably more complex than KITE. OSGI (Release 3), for example is specified
in as much as 600 pages (including various standard services).
In general, this complexity may be attributed to the goal of
domain independency, but it is not really clear if this helps the
application developer to get his or her work done. It is also much more complex to implement
the specifications because a large number of sophisticated interfaces
with subtle semantics must be mastered by a conforming runtime system.
We believe that KITE is the only system that has been reduced to
the absolute minimum number of orthogonal concepts, while still being a powerful open
platform for a variety of environments and services.
A promising approach therefore seems to be to take the KITE architecture as a baseline
and see how far one can go with it and what, if any, the principal limitations are.
Outlook
It would be interesting to compare the KITE architecture and
implementation with Avalon and Turbine, for example and to see if the
standard KITE services can be implemented without any loss of functionality
and without introducing any non-standard extensions into Avalon.
It might also be interesting to compare
KITE with the 'Spring' framework developed by Rod Johnson and Jürgen Höller
and to learn more about Spring in general.