Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

SMILA/Specifications/Management Of The Smila Components

< SMILA‎ | Specifications
Revision as of 07:34, 21 November 2008 by Szhbankova.brox.de (Talk | contribs) (Use case)

Use case

Some Smila components have to be managed.

The Lucene index should be managed by means of JMX agent. Operations for deleting, renaming and creating indexes should be accessible. For XMLStorage operations for deleting and renaming partitions should be accessible



This article is written on the basis of discussions with Dmitriy Hazin and Ivan Churkin.

Description

Let's discuss a problem on an example of management of an index.

See Workflow Smila.

The core of the system Router -> ActiveMQ -> Listener -> BPEL processor work only with the records. Or in other words the record connects all components of the system.

The Router pushes the record in the JMS message queue ( ActiveMQ). The records are collected in the queue where expect the further processing. The Listener orders the queue and for each record invokes the respective pipeline. Actual Smila has 2 pipeline: AddPipeline and DeletePipeline, which invoke the services and pipelet to process a record.


Pipeline.jpg

Figure 1. Add pipeline (see addpipeline.bpel). Delete pipeline (see deletepipeline.bpel).

As shown in Figure 1, the AddPipeline invokes first the SimplemimeTypeIdentifier service and the pipelet HtmlTotextPipelet which prepare the record for adding in the index, and then the LuseneIndexService which directly accesses to an index. In this case for the adding of the record in the index. The DeletePipeline invokes the LuseneIndexService for the deleting of the record from the index.

LuseneIndexService accesses to an index by means of two methods:

private void addRecord(final BlackboardService blackboard, final Id id, String indexName)  ...
 
private void deleteRecord(final Id id, String indexName) ...
 
 
IndexConnection indexConnection = IndexManager.getInstance(indexName);

Thus the system does not know what an index is. To be more exact for the system the accesses to the index means a LuseneIndexService invoking. To cause this service in turn there should be a record which bears in itself the certain information or which is connected with the certain information.

On this basis there are two ways of implementation of the index management:

  • Natural way - Management by the fictive records
  • Surgical way - Directly by the LuceneIndexService.

Technical Proposal

Management by the fictive records

To send fictive (empty) record with special DataSource. This record hands over the information what exactly is necessary for executing: deleting, renaming and creating of the index.

The possible realization

To create additional pipeline IndexManagementPipeline and to send empty records this will cause it. For this pipeline

  • To create set of the pipelets, on one for each operation

or

  • To invoke LuceneIndexService, in which on one for each operation to add a new method.


Drawling3.jpg

Figure 2. Posible realization IndexManagementPipeline.

Configuration file for IndexManagementPipeline indexmanagementpipeline.bpel can consist:

<proc:invokeService>
    <proc:service name="LuceneIndexService" />
    <proc:variables input="request" output="request" />
          <proc:setAnnotations>
             <rec:An n="org.eclipse.smila.lucene.LuceneIndexService">
                <rec:V n="indexName">test_index</rec:V>
                <rec:V n="executionMode">DELETE_INDEX</rec:V>
             </rec:An>
          </proc:setAnnotations>
</proc:invokeService>

Advantages of the given approach

  • It is not necessary the new mechanism of execution of commands (It is especially important for the distributed system)
  • All history of commands easily remains


Directly by the LuceneIndexService

Let's accept that the LuceneIndexService has new methods: deleteIndex(), renameIndex() and createIndex().

Invoke directly to the LuceneIndexService and call of a necessary method, also will lead to desirable result. However, similar solution reminds surgical interference in the system and he cannot be considered correct. At appearance of each new task or change (extension) of the system, it is necessary to change already ready solution. The given approach does not use possibility of system and does not allow to control in the standard image any process. In it consists advantages of the first way.

Back to the top