Berin,
Are you planning on using Avalon lifecycle management functions for
each of
these components? If so, then implementors of Input could be Startable
and
start() method would begin the processing for the pipeline. This would
allow
the various components to be configured in any order.
Where would the Notifier get plugged in? Would each implementor of
Input could have an optional Notifier. In it's "main loop" (whatever
actually
sends transactions down the pipeline), it would then do something like:
while( more_stuff_to_process() ) {
Transaction t = get_next_transaction_to_process();
m_Notifier.handleResponse( m_Output.processTransaction( t ));
}
Or would the impelmentors Inputs also implement Notifier?
Kevin
> -----Original Message-----
> From: bloritsch [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 16, 2002 8:53 AM
> To: avalon-apps-dev
> Cc: bloritsch
> Subject: Proposed interfaces for InfoMover
>
>
> The Input/Output/Manipulator interfaces need to be really simple, that
> encourage
> processing one Transaction at a time, and handling one Response at a
> time. There
> is also the question of whether we want another component called the
> Notifier.
> The Notifier's responsibilities would be to handle the Responses and
> send notifications
> if there are errors. Anyway, here is the first cut at interfaces:
>
> interface Input
> {
> void setDestination( Output out );
> }
>
> interface Output
> {
> Response processTransaction( Transaction trans );
> }
>
> interface Manipulator extends Input, Output {}
>
>
> I am planning for each Job to have it's own dedicated
> Container, and its
> own
> dedicated Thread. For that reason each Input, Output, and Manipulator
> will
> be completely isolated from the corresponding components in
> other Jobs.
> That
> will help with the Manipulators having two methods that need to be
> called in
> a particular order as opposed to just one. The Job pipeline will have
> to be
> built backwards because when a pure Input has its destination set, it
> will start
> sending Transactions down the Pipeline:
>
> manip2.setDestination( out );
> manip1.setDestination( manip2 );
> in.setDestination( manip 1 );
>
> If we have a Notifier component it would look like this:
>
> interface Notifier
> {
> void handleResponse( Response resp );
> }
>
> Internally it would determine if the response is worthy of notifying
> someone
> else, and if so would perform the steps required such as
> paging someone,
> sending
> an email, etc.
>
> Separating out the Notifier would allow us to dynamically set
> up how we
> respond
> to bad transactions, etc.
>
> Thoughts? Input?
>
> "They that give up essential liberty to obtain a little
> temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
