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: InfoMover Interfaces: the Proposals
Date Fri, 16 Aug 2002 19:46:10 GMT

Berin Loritsch wrote:
> So far, there are essentially three different proposals, two by me and
> one
> by Nicola.  I will enumerate the advantages and disadvantages of each.
> --------- From Nicola (Morpher interface) ----------
> public interface Morpher
> {
>       void setInput(Object input) throws ObjectFlavorException;
>       void setOutput(Object output) throws ObjectFlavorException;
>       void morph() throws MorphException;
> }
> public interface MorpherPipeline extends Morpher
> {
>       void addStage(Morpher nextMorpher);
> }
> ------------------ NOTES -----------------
> * The bidirectional registration ( setInput(), setOutput() ) seems
>   unnecessary.  A pipeline flows in one direction--from the input
>   to the output.  Our API should reflect that.

Initially it was just

    morph(input, output)

but it was showed how the setup and generation phases had to be separate 
to be able to pipeline streams and events correctly.

Also, sometimes the input or the output are not used, hence the separate 

> * The MorpherPipeline (or equiv.) interface may make it easier to add
>   stages, but InfoMover's logic is pretty simple.  It the pipeline
>   can safely be implicit instead of explicit.  We have no need of
>   caching pipelines or other more esoteric solutions.  IMO they
>   are FS.  If we need to cache, that should be designed intelligently
>   into the system.

It's about SOC, so that Pipelines assemble Morphers. It's a conceptual 
layer that works pretty well IMHO.

> * There is no distinction between Input, Output, and Manipulator.
>   I think that these should have a definite distinction.

The Manipulator is the Morpher.
The input and output are just Objects because the Morpher is gotten from 
a factory.
So basically I don't have Input and Output objects but just Objects, 
similarly to Services not needing Components to work.

> * Required method ordering precludes the ability to have ThreadSafe
>   implementations, which can cause resource strains on a loaded system.
>   I don't want to be a victim of those issues if I can help it.

*This* is a valid point... I assumed that a Morpher wasn't a service, 
but could be used by a service...

This needs more thinking...

> * The morph() method doesn't make sense in this context.

Ok ;-)

> -----------  From Me (First Version) ---------
> interface Input
> {
>     void setDestination( Output out );
> }
> interface Output
> {
>     Response processTransaction( Transaction trans );
> }
> interface Manipulator extends Input, Output {}
> ---------------- NOTES -----------------
> * Requires registration, but it is unidirectional.  Still Manipulators
>   can't be threadsafe.
> * as Nicola pointed out, setDestination() is not intuitive
> * The more I look at it the less I like it


> ------------ From Me (Second Version ) -----------
> interface Input
> {
>     Transaction getNextTransaction();
> }
> interface Output
> {
>     Response process( Transaction trans );
> }
> interface Manipulator extends Input, Output {}
> ------------------ NOTES -----------------------
> * Does not require any registration of the next stage in the pipeline
> * It is more intuitive to use
> * The Job is in finite control of the pipeline
> * Manipulator still has issues with threadsafe implementations, and
>   worse, if the calls to process() and getNextTransaction() are not
>   symetrical we can get some weird runtime errors--so that is a blocker.

Yup :-(

> ---------------- From Me (Third Version) --------------
> interface Input
> {
>     Transaction getNextTransaction();
> }
> interface Output
> {
>     Response process( Transaction trans );
> }
> interface Manipulator
> {
>     Transaction manipulate( Transaction trans );
> }
> ----------------- NOTES -------------------

First not from me... at a first glance I don't get it...
...but it seems that you have solved the threadsafe problem by putting 
the extra methods needed to setup first and then execute in different 
objects... interesting...

So instead of having one object with three methods to call in order, we 
have three objects each with an atomic method.

I'm still not sure if this is clever or just illusionism 8-) but still 

> * has all the strengths of the second version, but finally gets
>   rid of the method ordering issues.

yes, I saw this...

> * The Manipulator does what it does best, manipulates a transaction.
>   Unfortunately we have no way of extracting a Response if the
> transaction
>   violates some integrity checking issues.
>   - We can create a "struct" like class that encapsulates the
> Transaction
>     and Response together, allowing us to keep the same strengths and
> check
>     if the transaction is still good.
>   - We can alter the Transaction so that we can make the Response
> encapsulated
>     inside the Transaction.  That would cut down on Response object
> creation,
>     and still let us know if the transaction was successful.  This is
> probably
>     the better of the two solutions.

Yes, this last point is what I thought of too, that there should not be 
a separate response...

BTW, this method

   Response process( Transaction trans );

is not what we would use in Morphos, since if we want to make
data flow from one Stream to another I need two parameters in
input, not only one.

I'm starting to get a bit dizzy with this last proposal @-|

I need to process an Object into another Object.
Your interfaces are not clear in this respect.
Can you show me some code how it could be used?

Here is an example from Morphos.java:

                 InputSource input = new InputSource(new FileInputStream(args[0]));	
		OutputStream output = new FileOutputStream(args[1]);

                 MorpherFactory mf = new BasicMorpherFactory();
		MorpherPipeline mp = new SAXMorpherPipeline();

		Morpher xslt = mf.getMorpher("xslt");
javax.xml.transform.sax.SAXSource(new InputSource(new 



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