avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Schier <MSch...@infogation.com>
Subject [Cornerstone] Silk server questions
Date Mon, 13 May 2002 21:40:43 GMT
I came across the Silk Server / Stage Manager implementation in the
Cornerstone project.  I am kind of familiar with the SEDA architecture and
I'm thinking about implementing Matt Welsh's Sandstorm library in an Avalon
compliant way.  I took a close look at all the started implementations, and
now I would like to ask you guys a couple of questions.  Looking at the
interfaces in the excalibur event and command package I see a lot of
similarities with the SEDA interfaces, but how does the silk package in
Cornerstone fit into this?  The stage manager seems to be a candidate to be
a component or is it an extended ComponentManager?  Also, does the sink map
describe the main sink for a stage and all outgoing queues for the stage?
Do you envision to have the stage manager set up stages with sink maps, or
is this the responsibility of a stage-component-manager?  I would also be
very interested in what the initial idea behind this design was?  

If I were to implement an event driven management kernel, I could think of a
stage server manager that manages all the stages deployed in the system.
The stage manager would be configured with the system wide event flow
topology.   It would set up this topology everytime the component is
configured.  The event handlers are deployed into the system as components.
They can be selected using a regular component selector or specific
implementation.  This would allow the event handlers to be treated as
regular components that can be configured and contextualized and could
access other non event handler components if they wanted (Maybe to access
deployed services or so).  The stages itself would become what now is the
sink map, basically just providing a reference handle to the incoming and
outgoing event queues.  The stage manager is responsible for attaching a
thread manager to a set of stages.  Like the event handler, the thread
manager is a seperate component (which could be made selectable using a
thread manager selector).  An XML configuration for a stage manager could
then look like this...

<stage-manager>
	<stage-set thread-manager="thread_manager_role">
		<stage name = "http_receive">
			<!-- the handler for this stage -->
			<handler = "event_handler_role">
			<sinks>	
				<!-- the sinks to enque events to, only
visible from this stage-->
				<sink stage = "http_send"/>
				<sink stage = "xyz"/>
				<sink stage = "process"/>
				<!-- if the event handler needs access to
the own stages main sink
					it must be configured here!!! -->
				<sink stage = "http_receive"/>
			</sinks>
		</stage>
		<stage name = "process" >
			<!-- the handler for this stage -->
			<handler = "event_handler1_role">
			<!-- specifying more than one handler makes the
stage manager
   			    provide more than one main sink for a stage name
to allow for load balancing-->
			<handler = "event_handler2_role">
			<handler = "event_handler3_role">
			<handler = "event_handler4_role">	
			<sinks>
				<!-- the sinks to enque events to, only
visible from this stage-->
				<sink stage = "http_send"/>
			</sinks>
		</stage>
		<stage name = "http_send">
			<!-- the handler for this stage -->
			<handler = "event_handler_role">
			<sinks>	
				<!-- the sinks to enque events to, only
visible from this stage-->
				<sink stage = "xyz"/>
			</sinks>
		</stage>
	</stage-set>
</stage-manager>

The stage manager would also allows to configure more than one event handler
for a stage.  This could be used by other handlers to do load balancing.
The stage would therefore expose more than one main event queue in an
ordered way.  If enqueing into the first queue does not succeed because it's
full the handler could use the next equal queue in the list.
The stage would then be an internal class (like StageWrapper) and bundle
handler, main event queue, thread manager and sink map.  A sink map, that
only has information for the event handler, is exposed by the stage manager
and to support the particular configurable stage manager the interfaces
would then look something like this:

interface StageManager
{
	Sink getSinkMapForStage(String stageName);  
}



interface SinkMap
{
	Sink[] getSinks(String name);
	String[] getSinkNames();
	boolean containsSink(String name);
}


This is just a very quick idea and resembles much the original Sandstorm
design (I hope without the subversion of control).  I would appreciate very
much if you could comment on this design and of course answer my questions
above.  I have very high regards for your opinion, because I think all of
the implemented Avalon components have a very sophisticated and excellent
architecture, which shows the skills of the developers working on this
software.  

Thanks.

Marc

--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message