Overview

Besides following and fulfilling general framework requirements, each component or at least a group of similar components should have their own requirements.

Component classification

Generally speaking, all SMILA's components can be classified in three groups:

Data source specific components

Components that implement some kind of business logic

Components that provide some kind of persistence

The common problem is that sometimes we tend to mix 2. and 3. in our component's concepts and implementations. Although this is quite tempting it is really a BAD idea. Here is why this should not be practiced:

Natural/productive deployment environment of SMILA is some kind of cluster. This means that each core component (that actually falls down either into group 2. or 3.) has to have at least two instances to avoid having single point of failure. As long as one component is stateless this is no problem. But when the component becomes stateful all instances muss share their states while being online.

To overcome this problem and to let component developer only concentrate on the business logic, we should offer adequate persistence components (store services) that are dedicated to the task of preserving and serving (specific) data.

The implementation of store services depends mainly of two factors:

amount of data and

type of data they should manage

For example, the implementation of the binary storage service will extremely depend of the amount of the data that needs to be managed and therefore there should exist several implementations of it. Some implementation may keep its data on the local hard drive, some in RDBMS and some in distributed file system.

The second factor implies that we should provide dedicated persistence services for some specific type of data. In fact Blackboard service needs two stores (XML and binary store). Ontology service and DeltaIndexer needs their own storage too.