avalon-apps-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Proposed interfaces for InfoMover
Date Fri, 16 Aug 2002 15:01:49 GMT

Berin Loritsch wrote:
> 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 {}

Honestly, I think tha (Input).setDestination(Output) is very confusing, 
especially for users, and semantically incorrect.

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

Here the sfromentioned problem shows.

> If we have a Notifier component it would look like this:
> interface Notifier
> {
>     void handleResponse( Response resp );
> }

There is already a Notifier Component in Cocoon.
It was intended to notify in a generic way, and do 

In this way You don't even have to give a response, it could be anything.

I think that most of it can be reused in this context, and the result 
used both here and in Cocoon.

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

Yes, this is good.

> Thoughts? Input?

Morphos is a project to do what a "Manipulator" does.
It already works with XSLT and POI HSSF.

We had a long discussion on commons-dev over the interfaces.
Here is the result:


  public interface Morpher {

      * Construct a "call method" rule with the specified method name.
      * @param input The associated Digester
      void setInput(Object input) throws ObjectFlavorException;

      void setOutput(Object output) throws ObjectFlavorException;

      * Execute the morph.
      * Usually it's needed to have setInput(Object input)
      *  and setOutput(Object output)
      * called before.
      void morph() throws MorphException;

/*  TDB
      void addNotificationListener(NotificationListener nl);
      void removeNotificationListener(NotificationListener nl);
      void clearNotificationListeners();

  public interface MorpherPipeline extends Morpher {

      * Construct a "call method" rule with the specified method name.
      * @exception MorphException? FIXME if the nextMorpher
      * cannot be added
      void addStage(Morpher nextMorpher);

If we make the two compatible, InfoMover will be able to use all of 
Morphos' components, and extend on simple pipelines (Manipulators) for a 
complete infomover system.

Eventually we can make Morphos, Infomover and Cocoon share the same 


Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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>

View raw message