Jump to: navigation, search

Difference between revisions of "SMILA/Component Requirements"

(Record storage requirements)
 
Line 28: Line 28:
 
{| class="table.gallery" border=0
 
{| class="table.gallery" border=0
 
|-
 
|-
| [[SMILA/Record_Binary_Storage_Requirements|Record binary storage requirements]]
+
| [[SMILA/Component_Requirements/Record_Binary_Storage_Requirements|Record binary storage requirements]]
 
|-
 
|-
| [[SMILA/Record_XML_Storage_Requirements|Record XML storage requirements]]
+
| [[SMILA/Component_Requirements/Record_XML_Storage_Requirements|Record XML storage requirements]]
 
|}
 
|}
  

Latest revision as of 10:41, 13 October 2008

This page defines requirements posed on SMILA's components.

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:

  1. Data source specific components
  2. Components that implement some kind of business logic
  3. 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.

Component specific requirements

Record storage requirements

Record binary storage requirements
Record XML storage requirements

Delta indexing storage requirements

Delta indexing storage requirements

Ontology storage requirements

Ontology storage requirements

Buffer storage requirements

Buffer storage requirements