Logic Providers

Todd Wright twright at bbn.com
Mon Dec 10 19:55:09 EST 2007


Morgan Duchène wrote:
> Hi,
> 
> I have been wondering for some time what exactly logic providers are 

Logic Providers (LPs) are blackboard callbacks that run at the end of every 
blackboard transaction, i.e. at the end of every plugin "setupSubscriptions()" 
and "execute()".

LPs only run due to a plugin transaction or message input.  LPs don't have 
their own thread, alarms, or subscriptions.  This severely limits what LPs can do.

LPs perform several different types of jobs.  They translate blackboard 
modifications into output messages:
   - a "publishAdd" of a relay sends an "add-relay" message
and input messages into blackboard modifications:
   - a received "add-relay" message causes a blackboard "publishAdd"
LPs automate higher-level blackboard operations, e.g.:
   - a "publishRemove" of a Task recursively removes all child tasks
   - a "publishChange" of an Allocation updates the parent task's status
Lastly, LPs handle a couple special events such as:
   - a remote agent restart notification (which initiates state reconciliation)
   - a community membership change notification (causes relay add/remove msgs)

LPs run after each transaction but before the subscriptions are updated.  This 
means that the result of the above LP "recursive task removal" will be grouped 
into a single transaction instead of multiple transactions.  This is one reason 
why certain "higher-level blackboard operation" code must be written as LPs.

LPs are not components, but they are contained within pluggable Domain 
components.  The blackboard always loads the "root" domain, which contains the 
RelayLP.  Other domains, such as the "planning" domain, are optional and have 
their own set of LPs.

> and the best way to use them.
> 
> I don't really get the point when they should
> be used instead of plugins.

Usually you shouldn't.  The core's RelayLP is sufficient for nearly all 
applications.

Most of the planning domain's LPs could likely be rewritten to be plugins that 
use relays.  The above "recursive task removal" behavior could likely be 
relaxed from a single-transaction LP to a regular plugin.  The planning LPs 
predate the RelayLP.

Arguably even the RelayLP should be a plugin, which would separate the 
blackboard from the message transport.  For now they're intertwined, primarily 
for historical reasons (and some threading/persistence reasons).

Todd

> 
> Thanks for your help,
> Morgan
> 
> _______________________________________________
> Cougaar-developers mailing list
> Cougaar-developers at cougaar.org
> http://cougaar.org/mailman/listinfo/cougaar-developers
> 



More information about the Cougaar-developers mailing list