Eclipse Community Forums: SeMantic Information Logistics Architecture (SMILA) » SearchProcessingService with PipeletConfiguration

Home » Eclipse Projects » SeMantic Information Logistics Architecture (SMILA) » SearchProcessingService with PipeletConfiguration

Show: Today's Messages :: Show Polls :: Message Navigator

SearchProcessingService with PipeletConfiguration [message #631941]

Sun, 10 October 2010 18:12

UNI-HI Stud
Messages: 6
Registered: August 2010
Location: Germany

Junior Member

Hello, i am actually integrating Drools via some Declarative Services and SearchProcessingServices in SMILA.

But now i have some problems where i don't know how to solve them :/
1) I need an invocation-specific and non global configuration for my SearchProcessingService.
2) While (search-)processing i need to know which pipeline is used.

I need these things because i have a couple of RuleBases which had to be set as a default RuleBase for an Index or a Pipeline/Process. Furthermore it should be possible to define that my Service should not use the default RuleBase (invocation-specific).

Here some examples of what i want to do:

The "default" Mapping (conceptional):

<PipeletConfiguration [...]>
    <Property name="Pipeline1DefaultRuleBase">
        <Value>rulebase1</Value>
    </Property>  
    <Property name="Pipeline2DefaultRuleBase">
        <Value>rulebase2</Value>
    </Property>
</PipeletConfiguration>

BPEL-Search-Pipeline (Pipeline1):

<!-- Use default RuleBase: rulebase1 --> 
<extensionActivity name="invokeServiceDroolsFireRules">
	<proc:invokeService>
		<proc:service name="droolsFireRulesService" />
		<proc:variables input="request" output="request" />
	</proc:invokeService>
</extensionActivity>
<!-- Use invocation-specific RuleBase: rulebase3 --> 
<extensionActivity name="invokeServiceDroolsFireRules">
	<proc:invokeService>
		<proc:service name="droolsFireRulesService" />
		<proc:variables input="request" output="request" />
		<proc:PipeletConfiguration>
			<proc:Property name="USE_THIS_RULEBASE">
				<proc:Value>rulebase3</proc:Value>
			</proc:Property>
		</proc:PipeletConfiguration>  
	</proc:invokeService>
</extensionActivity>
<!-- Use default RuleBase: rulebase1 --> 
<extensionActivity name="invokeServiceDroolsFireRules">
	<proc:invokeService>
		<proc:service name="droolsFireRulesService" />
		<proc:variables input="request" output="request" />
	</proc:invokeService>
</extensionActivity>

Use of the "default" and "invocation-specific" Mappings (conceptional):

if(pipeletConfiguration.getPropertityFirstValue("USE_THIS_RULEBASE") != null){
    useRuleBase(pipeletConfiguration.getPropertyFirstValue("USE_THIS_RULEBASE"));
} else {
    useRuleBase(mappingConfiguration.getPropertyFirstValue(actualPipeline+"DefaultRuleBase"));
}

kind regards,

UNI-HI Stud

--> Please excuse my poor English Wink

[Updated on: Sun, 10 October 2010 18:16]

Report message to a moderator

Re: SearchProcessingService with PipeletConfiguration [message #632445 is a reply to message #631941]

Tue, 12 October 2010 20:34

UNI-HI Stud
Messages: 6
Registered: August 2010
Location: Germany

Junior Member

While some further work i have decided to switch from SearchProcessingServices to Pipelets, because with this approach the user can make invocation- and process-specific Configuration. The Pipelets are using in turn the DeclarativeServices (before SearchProcessingServices) to get some global instances and configurations. But for some reasons I still want to use SearchProcessingServices for some kinds of work. After looking up the functionality of the blackboard service I have stumbled about the GlobalNotes. I think the GlobalNotes would solve some communication-problems between the Pipelets and SearchProcessingServices.

But nevertheless I don't understand why ProcessingServices can't be configured like it's possible with Pipelets. I don't mean Configuration which has to be set at instantiation time, I mean Configurations while processing → A simple attribute/value configuration option.

One example of what I mean:
example.bpel:

<extensionActivity name="invokeLuceneSearchService">
	<proc:invokeService>
		<proc:service name="LuceneSearchService" />
		<proc:variables input="request" output="request" />
		<proc:setProperties>
			<prop: n="actual_pipeline">testPipeline</prop:prop>
			<prop: n="in_which_line_was_i_invoked">100</prop:prop>
		</proc:setProperties>
	</proc:invokeService>
</extensionActivity>

(Search)ProcessingService:

public SearchMessage process(Blackboard blackboard, SearchMessage message, Properties configprops) throws ProcessingException {
	configprops.getProperty("actual_pipeline");
	configprops.getProperty("in_which_line_was_i_invoked");
	return null;
}

UNI-HI Stud

[Updated on: Tue, 12 October 2010 20:38]

Report message to a moderator

Re: SearchProcessingService with PipeletConfiguration [message #632773 is a reply to message #632445]

Thu, 14 October 2010 04:58

Daniel Stucky
Messages: 35
Registered: July 2009

Member

Hi,

please take a look at http://wiki.eclipse.org/SMILA/Documentation/Pipelets_and_Pro cessingServices. As you can see there the configuration of a Pipelet in a BPEL pipeline does not support "runtime" parameters, all the parameters that are passed are used when an instance of a Pipelet is created. An instance of a Pipelet and its lifecycle are tied to a pipeline. It may seem to you that you configure the call to the Pipelet but actually you configure its configuration at creation time.

A ProcessingService is independent of pipelines. An instance is created by the OSGi runtime and not by the pipeline the service is used in. Services can have any kind of initialization configuration (e.g. xml files, property files, etc.) as the initialization is specific to each ProcessingService implementation.

Still it is possible to change the behavior of a ProcessingService/Pipelet at runtime:
This is done by setting annotations on the record(s) to be processed. Of course the ProcessingService/Pipelet has to be implemented to check for annotations and then execute different code paths. An example for this is the LuceneIndexService. Besides others it uses an annotation named "executionMode" that can be set to either "ADD" or "DELETE" in order to change the behavior of the service adding or deleting the record to/from the index. Annotations ca be easily set in the pipeline:

<extensionActivity name="invokeLuceneService">
   <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">ADD</rec:V>
            <rec:V n="allowDoublets">false</rec:V>
         </rec:An>
      </proc:setAnnotations>
   </proc:invokeService>
</extensionActivity>

I hope this helps.

Bye,
Daniel

Report message to a moderator

Re: SearchProcessingService with PipeletConfiguration [message #632974 is a reply to message #631941]

Thu, 14 October 2010 16:54

UNI-HI Stud
Messages: 6
Registered: August 2010
Location: Germany

Junior Member

Hmm, after reading up my posts i would say that i have described that what i mean a little bit wrong. Nevertheless you are absolutly right and i have found one problem of the way i was thinking. --> Thanks for that and your reply at all!

But: Setting Annotations is a little bit "complicated" (umständlich) when i just want to make generell configurations (for the Proc.Service) which has nothing to do with the Records.

Quote:

I don't mean Configuration which has to be set at instantiation time, I mean Configurations while processing → A simple attribute/value configuration option.

"processing" was wrong discribed, i'm sorry :/ I mean somethin like that:

I have -lets say- 10 RuleBases who are instantiated when my Proc.Service/DeclarativeService is activated. My Problem is now: i don't know which RuleBase the consumer wants to use in the actual processing Pipeline. Yes, i could globaly configure my DeclarativeService so that he always has to use RuleBase1 when Pipeline1 is processing, but thats not what i want! I will, that in one Pipeline more than one RuleBase can be used.

I just need a "static" Properties-instance which is allways send to the process-Method when the Proc.Service is invoked.

Quote:

public SearchMessage process(Blackboard blackboard, SearchMessage message, Properties configprops) throws ProcessingException {
	configprops.getProperty("actual_pipeline");
	configprops.getProperty("in_which_line_was_i_invoked");
	return null;
}

Actually it's allready possible by using Pipelets which set GlobalNotes:
1.1) invokePipelet (ConfigPropertie: _useRulebase = "now use RuleBase1")
1.2) set GlobalNote in processing Method of the Pipelet:

blackbaord.setGlobalNote("rulebase",_useRulebase)

2.1) invokeService
2.2) get GlobalNote in processing Method of the Proc.Service:

String use_rb = blackbaord.getGlobalNote("rulebase")
if(use_rb == "now use RuleBase1"){
   useRuleBase(1);
} else if (use_rb == "now use RuleBase2"){
   useRuleBase(2);
} else ....

3.1) invokePipelet (ConfigPropertie: _useRulebase = "now use RuleBase96")
3.2) set GlobalNote in processing Method of the Pipelet:

blackbaord.setGlobalNote("rulebase",_useRulebase)

4.1) invokeService
4.2) get GlobalNote in processing Method of the Proc.Service:

String use_rb = blackbaord.getGlobalNote("rulebase")
if(use_rb == "now use RuleBase1"){
   useRuleBase(1);
} else if (use_rb == "now use RuleBase2"){
   useRuleBase(2);
} else ....

So from my point of view, this ping pong game between senseless Pipelet invocations and Proc.Service invocations can't be the only possibility for my Problem! And adding to each record an annotation is also senseless for this (my opinion).

---> Actually i simply let the DelarativeServices running in Background (outside of SMILA) and the Pipelets include the logic and reffer to memory-intensive instances (e.g. a KnowledgeBase/RuleBase)

Prost,

UNI-HI Stud

[Updated on: Thu, 14 October 2010 17:01]

Report message to a moderator

Re: SearchProcessingService with PipeletConfiguration [message #633503 is a reply to message #632974]

Mon, 18 October 2010 05:21

Daniel Stucky
Messages: 35
Registered: July 2009

Member

Hi,

I'm not sure if I understand your needs correctly so I will summarize:

- you want to have one static pipeline configuration with N services
- you want to send parameters with each call of the pipeline in order to configure each service to use a certain rule base

So, the first thing in question is how to call a pipeline with parameters ? The answer is - you cannot. The API does not support a pipeleine call with parameters.
But what you can do is to set attributes or annotations on the records you are processing. I assume you are using SearchProcessingServices so these parameters would be added to the query record. Then you can check the value of these record "parameters" to select your rulebase to use. I see no other way of getting the information on which rulebase to execute from the call of a pipeline to an actual service (or pipelet).

The interface you suggested

public SearchMessage process(Blackboard blackboard, SearchMessage message, Properties configprops) throws ProcessingException

seems reasonable for you problem, but I'm sorry to say that, at least at the moment, there will be no changes to interfaces.

Usually there are multiple ways of solving a problem using the SMILA framework. If you find it easier to achieve your goal using pipelets instead of ProcessingServices then go ahead and use pipelets that internally delegate the work to a ProcessingService or in general any OSGi Service. You are not forced to use ProcessingServices just from a BPEL invocation in a pipeline. Feel free to experiment Smile

Bye,
Daniel

Report message to a moderator

Previous Topic:	Seeds and POST-Parameters
Next Topic:	Using the RecordRecycler

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sun May 26 04:40:46 EDT 2013