avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Schier <MSch...@infogation.com>
Subject RE: [Cornerstone] Silk server questions
Date Tue, 14 May 2002 23:10:33 GMT
Berin, 
thanks for your quick reply.  I now see much clearer.  I think there are two
options for me to implement the stage manager.  The first would be to make
it a container for (just) stages.  The alternative would be two make stage
manager a component that exposes sink maps for a specific stage by stage
name.  I do not like the second propsal anymore, although I mentioned it in
my first email.  I would now rather like to implement the stage manager as a
special kind of fortress container extending abstract container and adding
the stage setup from a xconf container configuration like the one below.
Do you think it would be a good idea to implement the stage manager as a
fortress container, which in addition to setting up the deployed components
(stages) also evaluates a stage specific configuration and sets up the
stages with the sink maps?  As the author of fortress and silk server, how
would you do it?

Thanks again.
Marc

possible xconf:
<stage-manager>
	<components> 
		<component
			role="com.infogation.event.IStage"
			id="http_receive_stage"
			class="http_receive_stage_class"
			handler="ThreadSafeComponentHandler">
		</component> 
		<component
			role="com.infogation.event.IStage"
			id="process_on_localhost_stage"
			class="process_stage_class"
			handler="ThreadSafeComponentHandler">
				<host name=localhost port=80>
		</component> 
		<component 
			role="com.infogation.event.IStage"
			id="process_on_remote_stage"
			class="process_stage_class"
			handler="ThreadSafeComponentHandler">
				<host name=245.128.44.53 port=80>
		</component> 
		<component
			role="com.infogation.event.IStage"
			id="http_send_stage"
			class="http_send_stage_class"
			handler="ThreadSafeComponentHandler">
		</component> 
	</components>

	<stages>
		<thread-manager class="thread_manager_class">
			[Configuration...]
		</thread-manager>

		<stage name="http_receive">
			<component id="http_receive_stage" />
			<sinks>	
				<!-- The sinks to enqueue events to, only
visible from
				     this stage -->
				<sink stage="http_send"/>
				<sink stage="xyz"/>

				<!-- Marking a sink as default makes it the
main outgoing
				     sink, otherwise the first sink in the
list is the 
				     default sink -->
				<sink stage="process" default="true"/>

				<!-- if the stage needs access to its own
sink it must be
				     configured here -->
				<sink stage="http_receive_role"/>
			</sinks>
		</stage>
		<stage name="process">
			<!-- specifying more than one class makes the stage
manager
			     provide more than one sink for a stage to allow
for load
			     balancing (Replication) -->
			<component id="process_on_localhost_stage" />
			<component id="process_on_remote_stage" />
			<sinks>
				<!-- Multicast sinks allow to group sinks
into
				     a single sink that can be used by a
stage -->
				<sink-multicast name="notification">
					<sink stage="bar"/>
					<sink stage="foo"/>
				</sink-multicast>
				<sink stage="http_send" default="true"/>
			</sinks>
		</stage>
		<stage name="http_send"> 
			<component id="http_send_stage" />
			<sinks>
				<sink stage="xyz"/>
			</sinks>
		</stage>
	</stages>
	<!-- more stages with separate Thread Manager -->
	<stages>
		<thread-manager class="thread_manager_class">
			[...]
		</thread-manager>
		<stage name="foo">
			[...]
		</stage>
	</stages>
</stage-manager>

> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Tuesday, May 14, 2002 6:09 AM
> To: 'Avalon Developers List'
> Subject: RE: [Cornerstone] Silk server questions
> 
> 
> > 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>

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