Coalevo Architecture - Overview

This document presents an overview of the platform's architecture and its properties, which are inherited partially from the foundations: Java (object oriented) and the OSGi framework (service oriented and component based).

Service Oriented

From a top down point of view, the Coalevo platform has a service oriented architecture (SOA). While the mainstream use for this type of architecture is nowadays about web services, this is not necessarily the case for Coalevo's architecture. Not necessarily, because:

1. it allows implementations that do not have to be distributed, but they actually may be; and
2. web services (REST, SOAP whatever) may be a way to expose access the actual service implementations, but they are definately not the only way.

Especifically the first point may be an extension of the definitions in OASIS Reference Model for Service Oriented Architectures: capabilities don't have to be distributed. Otherwise, definitions and cornerstones of the reference apply to the Coalevo architecture:

• capabilities can be used without needing to know all the details; and
• capabilities are mainly provided by services.

Mainly refers to the fact that, as an exception, there may be components that are actually basic libraries that are reused for the implementation of various services; contrary to services, these components provide building blocks for the OO design of services (e.g. like collections, pools and codecs).

Service

A service is an entity that has capabilities that it provides to others or that it uses to realize basic tasks for the system itself.

Visibility is provided by:

1. the standard mechanisms that are part of the service layer of the OSGi framework; and
2. descriptions that provide information about functions, technical requirements, constraints, policies and access mechanisms; these descriptions are in a form that has a clear syntax and semantics, and are widely accessible and understandable.

Interaction - the activity of using a capability - is mediated by the exchange of messages, and proceeds through a series of invoked actions. The purpose of the interaction is to result in effects. These effects may change the state that is shared between at least those involved in the actual execution context. Services may use private actions to provide their capabilities, but these are inherently unknowable by other parties and irrelevant for the current interaction.

Component Based

Another top down point of view of the architecture reveals it as inherently component based. Components are provided as bundles, which are defined by the OSGi framework specification, in particular the module layer of the framework. Each bundle is a unit of development and deployment; bundles can be developed independently as sub-projects, and they can be deployed into an OSGi container. The container actually provides mechanisms - these are part of the lifecycle layer - to add, update and remove bundles at runtime, either from a local storage, or over the network.

Bundle

Bundles should provide some coherent portion (i.e. a component) of the system, that uses (bundle imports) and exposes (bundle exports) one or more services and corresponding types (i.e. the model). For more information, please visit the documentation of the anatomy of a Coalevo bundle.

Object Oriented

From a bottom-up point of view Coalevo is an object oriented design. All services and types are defined by classes and interfaces, as defined within the boundaries of the Java Programming language.

The architecture permits to construct either monolithic deployments (i.e. on a single node) or distributed systems (i.e. on a variety of physically distributed nodes).

The main constraint imposed by the architecture in terms of deployment is the OSGi container at the node level. A visual presentation of the deployment in a node is depicted in the following figure (UML deployment diagram notation):

In the case of a distributed system with a given number of physically distributed nodes, the components and services located in different nodes need to communicate with each other over a network link to achieve interaction.

Instead of imposing any constraints, the Coalevo architecture only suggests that the communication is achieved through implementation and deployment of specialized components:

1. protocol service bundles; and, if necessary
2. protocol adapter bundles.

Protocol service bundles provide a generic implementation of the protocol that is being used for communication; in this context service is not used at the application or real world level, but rather at the network level. Protocol adapter bundles, if required, are components that provide the glue between a generic application service, and the protocol service.

An example for this architectural construct, is provided in the following figure:

The suggestion actually aims at achieving an architectural construct (i.e. design pattern) that allows reuse and extensibility at this level (i.e. many adapters may provide access to various application services through a single protocol service instance). There is no limitation whatsoever on the possibilities for the creation of instances of this architecture that are distributed systems.

The Coalevo platform is organized into a number of different building blocks, which may be composed of one or more components (i.e. bundles), and, provides certain aspects of a system constructed based on the platform. These blocks are:

• Base libraries and OSGi services
• Foundation
• Security
• System services
• Application services
• Protocol services and adapters

They are put into a conceptual context in the following figure:

Basic libraries and OSGi services

Object oriented design and programming by itself provides a powerful foundation for modularity and consequently re-use. Many existing libraries are simply classes and interfaces that make it easier to implement all type of components, and thus, they are not handled as a service, but rather as library components. The most prominent example is probably Apache Commons - Commons Collection.

Coalevo uses some of this libraries, in a re-packaged form, so that they are valid and useable as OSGi bundles.

Some very common basic services are described by the OSGi R4 Service compendium. Coalevo uses some of these provided as implementations in bundles from different vendors (mainly Equinox and Knopflerfish). In particular:

1. ConfigurationManager;
2. MetaTypeService;
3. LogService; and
4. PreferenceService

Foundation

The foundation of the Coalevo platform is comprised of basic types that represent the basic model of the platform. Besides this basic model, the foundation also includes basic services for:

• simple use of template based message resources for easy localization of bundle messages (e.g. logs); see the MessageResourceService
• random strings and unique identifiers; see the RndStringGeneratorService and the UUIDGeneratorService

Furthermore there are some utility classes for configuration handling in bundles and cryptography:

• a relatively complete JCE provider named Cryptix
• an SRP v6a implementation; see SRP usage documentation

The complete foundation is actually provided by the Foundation bundle.

Security

OSGi security is essentially based on the Java 2 Security Architecture.

At the bundle level, there is JAR signing, a mechanism for authenticity and integrity of bundles that uses Public Key Cryptography (PKC) and X.509 certificates from Certificate Authorities (CA; trusted third party). Additionally bundles may be authorized based on permissions (PermissionAdmin).

At the user level, there is a password or certificate based mechanism for authentication and a role based mechanism for authorization.

While these are certainly useful for certain types of OSGi uses, there are some practical issues:

1. Execution Environment: OSGi may be used in environments that are not Java 2 at all; in such environments surrogates have to be added to make it work. This is maybe not such an issue for this platform, but generally needs to be considered;
2. Scaleability
3. Flexibility for authorization

To provide scaleability and flexibility, mechanisms for security by authentication and authorization were designed specifically for this platform. For more details, please visit the documentation on security concepts.

The corresponding model and services are provided by the security bundle.

System services

Some types of services are generally useful within the boundaries of a platform like Coalevo. These services are useful mainly to other services that need to schedule recurrent or non-recurrent task, need location information or to send some mail.

This building block seeks to provide such services, like for example:

1. an ExecutionService;
2. a MailService;
3. a MaintainanceService; and
4. a BackupService.

These services are actually all povided by the basic System Services Bundle.

There may be also need for:

1. an IP to Geographic-Location service; see the IPLocator Bundle;
2. XML parser bundles like the StAX bundle; and
3. a statistics service; see the statistics bundle.

Application services

This building block is comprised of all bundles that provide application level functionality, where application level is defined by a specfic application domain. The best way to further clarify the concept behind this block, here some existing examples are:

1. the presence service; the presence bundle;
2. the messaging service; the messaging bundle;
3. the discussion service; the discussion bundle; and
4. the user data service; the userdata bundle.

This is maybe the hot spot for development of systems that want to leverage the Coalevo platform for services beyond communication, respectively to extend the platform to provide further networking and communication services.

Protocol services and adapters

These bundles should provide network protocol based access to locally available application services. Plase the section on deployment for more information.

Examples for protocol services are:

• a HTTP service; this may be the standard OSGi defined one, or see the web bundle;
• an extended messaging and presence protocol; see the empp server bundle; or
• the Telnet and SSH service provided by the TelnetD FOSS project at SourceForge.

An example for a rather complex protocol service adapter is the shell access bundle.