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
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
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.
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.
Container to Component relationship.
Two types of components (Passive and Active)
The implementation of Containers for each component included as a part of the framework
Components adhere to a common specification
Each component will be allowed to implement interfaces to use additional services provided by the container.
Component to Component Interoperability (Components will have access to other components through Container Context)
Containers manage multiple instances of components.
Container Contexts provide access to other services and components of the server.
Easy configuration using XML.
Allows for a limit on the number of Component instances per Container.
Each container only handles many instances of one Component class. (which would be one of the component types)
Container Manager is used to managed all Component Containers.
Container Manager Context provides services and configuration options to each Component Container.
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 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.
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:
init() [Component, required, default]
Active Service Stage
service() [Component, required, default]
destroy() [Component, required, default]
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.