avalon-apps-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kevin.s.rul...@mail.sprint.com
Subject RE: Proposed interfaces for InfoMover
Date Fri, 16 Aug 2002 15:18:32 GMT

Berin,

I think it's unnatural for the job to have to worry about
how many manipulators are in the chain.  Instead, it should
only worry about taking transactions from the input and putting
them in the output.  If the output happens to be a manipulator,
then it should worry about pushing the transaction down the pipe.

So the Job would have one input and one output and do the following:

while ( ( transaction = input.getNextTransaction() ) != null )
{
    resp = m_output.process( transaction );
    m_notifier.handleResponse( resp );
}

If m_output happens to be a manipulator then it would do:

Output:

Response process( Transaction t ) {

  Transaction newTransaction = do_what_this_needs_to_do_to(t);

  if (newTransaction == null) {
    return new Response( ROLLBACK, t );
  }

  return m_output2.process( newTransaction );

}


Kevin

> -----Original Message-----
> From: bloritsch [mailto:bloritsch@apache.org]
> Sent: Friday, August 16, 2002 10:07 AM
> To: avalon-apps-dev; bloritsch
> Cc: bloritsch
> Subject: RE: Proposed interfaces for InfoMover
> 
> 
> > From: Berin Loritsch [mailto:bloritsch@apache.org] 
> > 
> > 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 {}
> 
> 
> You know what?  It would be better if I was not so specific
> in my method name for processing.  It is clear what I am
> processing by the type, and all it does is add verbosity.
> The new Output would be:
> 
> 
> interface Output
> {
>     Response process( Transaction trans );
> }
> 
> 
> Also, since the Job is what performs the pipelining, I think
> changing the Input so that the Job performs the pull and push
> we might be able to do this:
> 
> interface Input
> {
>     Transaction getNextTransaction();
> }
> 
> 
> 
> The implication of this change is that it #1 puts the Job in
> control, #2 allows us to handle a bad response as soon as it
> occurs, and #3 forces the Manipulator to cache processed
> transactions until they are grabbed back out.
> 
> The processing loop would look like this:
> 
> Transaction transaction = null;
> 
> while ( ( transaction = input.getNextTransaction() ) != null )
> {
>     Response resp = manip1.process( transaction );
>     if ( isBadResponse( resp ) ) continue;
> 
>     resp = manip2.process( manip1.getNextTransaction() );
>     if ( isBadResponse( resp ) ) continue;
> 
>     resp = output.process( manip2.getNextTransaction() );
>     m_notifier.handleResponse( resp );
> }
> 
> //.... go to isBadResponse() method
> 
> boolean isBadResponse( resp )
> {
>     boolean isBad = ! resp.isSuccessful();
> 
>     if ( isBad )
>     {
>         m_notifier.handleResponse( resp );
>     }
> 
>     return isBad;
> }
> 
> 
> 
> Opinions, do you like one approach above the other?
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:avalon-apps-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: 
<mailto:avalon-apps-dev-help@jakarta.apache.org>



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


Mime
View raw message