Scipio – Version 0.2 – Design Paper – Draft 2

Scipio Framework is being fully redesigned and implemented to include new features and improve the implementation of the framework's code base.
After a careful consideration and research a number of new features have been added that closely resemble those of Apache Avalon Framework's project.

Brief Design Overview

Scipio Framework version 0.2 will be based on a container-component idea. The programmers will write components which will be handled by a generic all-purpose containers, which are a part of the Scipio Framework package. Each component instance will be handled by one container, which in turn will be managed by a container manager. Containers could be instantiated and started by any Java Class with one or more containers being the bridge between the entry point of the program and other containers. Components in Scipio will adhere to a specified interface and will implement other interfaces if the developer chooses to utilize different services offered to the component by a container. Container Managers will be responsible for creating and managing Component Containers. They will provide configuration options and other services to each Component Container.

To simplify and reduce the development time, container classes will be provided as a part of Scipio Framework. Also the default container starter will be provided to the developers for testing purposes. It will be advised that developers create their own container starters for security and performance reasons. Each container will be managed by a container manager, which will provide references of other containers to each container. The container manager implementation will be included in the Framework distribution.

There will be two generic types of containers. The Communication Container and Service Component Container. The Communication Container is responsible for starting the components that will handle socket related communications between clients and servers. On the other hand Service Component Containers will be responsible for handling components that apply business rules to the received data.

An example of a Communications Component would be a SocketManager Component responsible for managing incoming connections, reading the data from the incoming connections and passing the data to the appropriate Service Component.

To make it more clear and understandable, the framework will consist of two types of Components, each of which will have a separate Container to handle those components. This will allow for a clear breakdown of the framework, which in turn will lead to better scalability and performance.

To allow developers to create components that could be constantly running without the interference of the container, Scipio Framework will provide a Startable interface. Each component instance that implements that specific interface will be started and run continuously in its own thread without the intervention of the component container. The two type of component will be called Passive and Active components. Each passive component will be called by the component container to perform a specific action. Active components, on the other hand, will be started and run constantly for the duration of their life in the server. Each component that wants to become active must implement Startable interface. If the component doesn't implement Startable interface, then it will be considered a Passive component. The component container will be able to handle both types of components.

Features Listing

The list below is not a complete list of features of this version of the Framework, however as the project moves on in the development stages these features will remain as a part of the framework. New features that will be added to the framework will not interfere with old ones.

These are the main features of the Framework. New features will be added as the stages of the development progress into the future.

Component Interface

Component interface is a set of methods that a component must implement to be managed by a Scipio Component Container. There are four methods that the component must implement. Service(Queueable object) method will be called by the container, whenever the container needs the component to do some work on the data represented by the Queueable object. Init(ContainerContext ctx) is used to initialize the component and pass the container context with all required services to the component.

Components will have a number of other interfaces that will serve as helpers and will not be required. Such as configurable() interface will allow the component to receive a configuration object, startable() which specifies to the container that the component must be running constantly during its life.

Component LifeCycle

Each component will go through a three stage life cycle. The stages are as follows: Initiliazation stage, Active Service stage, and Destruction stage (* stages borrowed from Avalon Framework project). Each stage will have a number of execution points repseneted by interfaces. Each component, will go through the specified execution points during its life cycle in a specified order. Some of the execution points will be skipped, however each component will always go through init process in the Initialization stage, service process in the Active Service stage, and destroy process in Destruction Stage.

Here is the list of execution points of the Components life cycle in order of execution:

Initialization Stage

Active Service Stage

Destruction Stage

Note: The basic component doesn't have to implement any of the above interface, except for the Component interface, which is required for a Java Class to be managed by a Scipio Component Container.