Hello all,
I've been thinking about how to go about the design of Silk. There are
some TDB questions in the JavaDocs that I wanted to get opinions on. As
it stands right now, there are interfaces for SinkMap, Stage, and
StageManager.
The SinkMap is how a Stage lookups up the Sink for the Queue that is to
handle the event next (Berin, why is it SinkMap.getSource() and not
getSink()?).
The Stages are where the real work is done. They each have a queue (or at
least a source, this is one question I have below), and a SinkMap as well
as an EventHandler and possibly a thread pool.
The StageManager isn't as clear to me. I'm guessing that it is what
actaully takes the Stages and strings them together to form a pipeline.
If this is correct then it is responsible for creating and providing
SinkMaps to Stages.
One thing that is left out is the idea of a StageController. In the SEDA
architecture this is what does the adaptation to increasing or decreasing
load.
So now for my questions (most of these are inter-related but I'm going to
try and separate them out and talk about them individually before taking
the whole thing together):
1) Where should the StageController be created? There are only two
options here:
i) The container
ii) The StageManager
I like letting the container do as much work as I can so I don't have to
recreate any code to do configuration and assembly of things, so I can see
letting the container create the controllers. Then again, if the EHs are
created by the container all we really need to grab are the EHs and policy
information for the controllers, so that's not a big deal. It also
doesn't really make sense for the StageControllers to be services
available to others, so I can see them being created by the StageManager
as well. I think I'm leaning towards the latter right now, but really am
up in the air on the matter.
2) Where should Stages be created? If we insert the idea of the
StageController there are 3 choices:
i) The container.
ii) The StageManager
iii) The StageController
I don't see much benefit in having the container create the Stages because
it seems to me that most configuration, etc. will be done elsewhere.
Plus, they aren't really things that should be accessed directly by other
components. That should be done through their queue. The StageController
could create the Stage, but it is really meant as more of a monitor of
Stages and not a creator or them. My vote here is for the StageManager to
create the actual Stage.
3) Where should queues be created? Here we have 4 options:
i) The container.
ii) The StageManager
iii) The StageController
iv) The Stage
Again, there is little benefit to creating a queue with the container and
doesn't seem to make much sense anyways - we don't want just anyone
pulling things from the Source, after all. The StageManager also doesn't
seem to make much sense because it doesn't have the information it might
need to create the queue, such as the type of queue to create. This is
the same reason I don't think the Stage itself should create the queue,
but the StageController should. The type of controller and policy of the
controller could dictate the type of queue to be created, whether it be an
unbounded queue or a fixed queue or a priority queue or whatever. So my
vote is for the StageController to create the queues and provide the
Source to the stage.
4) Where should the EventHandlers be created? Again, there are 4 options:
i) The container.
ii) The StageManager
iii) The StageController
iv) The Stage
This time there would be a great deal of benefit, IMHO, to letting the
container do the creation and assembly. To get it's job done an event
handler would likely need access to other system resources and/or
services. If the container creates and assembles the EventHandlers it can
provide them with their configuration and dependencies. If the
EventHandlers are created at some other layer getting them the things they
require becomes more complicated (although there may be a relatively
simple way that I'm not aware of yet). My vote here is for the container
to create the EventHandlers and provide them to whomever is creating and
assembling the Stages (unless it's easy to pass dependencies down to where
they are needed in which case either the StageController or the Stage
itself would be fine with me, but I'd lean towards the controller).
The only other thing I'm wondering about is the name of StageManager. If
it really is what is supposed to be what puts the stages together wouldn't
it be better to call it Pipeline or something?
Those are the main issues I can come up with that need to be figured out
before I can actually start hacking some actual code together. Let me
know what you all think and if I'm way off base on my understanding of
some things.
Thanks,
Rich
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
