Berin,
nice work as usual.
However, architecturally I have some random thoughts that I'd like to share.
I have looked into SEDA as part of my Avalon-for-C++ project, and regarding
queues, I can not really say whether the queue should or should not be exposed
to the stages producing events for that stage.
Axiom: Stage isa Component
Scenario:
class StageBeforeMyStage implements Stage { ... }
class MyStage implements Stage { ... }
class MyStageWorkElement implements QueueElement {
public MyStageWorkElement (String workDescription) { ... }
public String getWorkDescription () { ... }
}
StageBeforeMyStage produces MyStageWorkElements and feeds them to MyStage.
Now, I thought like this: The queue should hold event objects. But C++
templates enables you to design the queues with type safety - that is, you do
not need to cast the event object after dequeueing it. This is a major
advantage, as you do not need to rely on the previous stage producing the
correct work elements.
I imagine StageBeforeMyStage will use a ComponentManager to
lookup(MyStage.ROLE). Now, what does StageBeforeMyStage see of MyStage? Does it
see the Sink interface?
I would propose that it did not.
I would like to show this interface:
interface TransactionalSink {
public void beginTransaction ();
public void commitTransaction ();
public void abortTransaction ();
}
interface MyStageSink extends TransactionalSink {
public void addWorkDescription (String workDescription);
}
The usage would then be like this:
MyStageSink sink = (MyStageSink) manager.lookup (MyStageSink.ROLE);
.
.
.
try {
sink.beginTransaction ();
sink.addWorkDescription ("Do this.");
sink.addWorkDescription ("Do that.");
sink.commitTransaction ();
} catch (Exception e) {
sink.abortTransaction ();
}
A stage would then be just like a component with asynchronous methods. The
thread pool for each stage would be managed by the component manager the stage
belongs to.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
