avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: [Cornerstone] Silk server questions
Date Tue, 14 May 2002 13:08:37 GMT
> From: Marc Schier [mailto:MSchier@infogation.com] 
> 
> 
> 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?  

:)

I'm glad you recognized this is just the beginning.  The Event
package is just a cleaned up SEDA infrastructure.  My initial
thoughts on the Stage was to have the StageManager control
how to perform the plumbing of the stages.  Kind of like the
Manager concept in Sandstorm.  The SinkMap was an artifact
that the StageManager gives to the stage (kind of like the
ComponentManager concept) so that the stage can use the output
queues properly.

So the stage itself is made up of the EventHandler and the
SinkMap.  Kind of like this:


     +-----------+-+
     | Stage     |M|---->
     +-------+   |a|
---->|handler|   |p|---->
     +-------+---+-+

The concept is somewhat like Unix named pipes.  If there is only
one pipe (EventQueue), then the Stage uses it.  If there are more
than one pipe, the Stage can address the one it wants by name (or
just send events to the default pipe).

> 
> 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...


That's the general idea I was working towards.  I haven't gotten
there though.  (you know how it gets, the project you were
working on got canceled, you got moved to work on an MFC
[Microsoft F****** Code]).

> 
> <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>
> 


--
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