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

Berin,

I have one alternative as well.  It is a variation on the last option 
you showed.  I'm going to change the names to make things a little more 
obvious:

interface TransactionSource
{
    Transaction getNextTransaction();
}
 
interface TransactionSink
{
    Response process( Transaction trans );
}

All Manipulators and Outputs will implement TransactionSink.  The only 
difference is that a Manipulator will need to have a registered 
Manipulator or Output to sent its stuff along to.

This requires registration to chain everything together, but I don't 
know how that can be avoided.

One big advantage over your third alternative, is that Input's don't 
need to know if they have a Manipulator or an Output.  And manipulators 
are free to return Responses as they see fit.

One thing I didn't like about Berin's second alternative, was that 
Manipulator extends Input so it has a getNextTransaction() method which 
really doesn't make much sense.  I don't really know what this method 
means in this context.

I'm afraid I can't seem to find the Morpher code to take a better look 
at.  Which cvs module is it in.

Kevin

> -----Original Message-----
> From: bloritsch [mailto:bloritsch@apache.org]
> Sent: Friday, August 16, 2002 1:19 PM
> To: avalon-apps-dev
> Cc: bloritsch
> Subject: InfoMover Interfaces: the Proposals
> 
> 
> 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.
> 
> * 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.
> 
> * There is no distinction between Input, Output, and Manipulator.
>   I think that these should have a definite distinction.
> 
> * 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.
> 
> * The morph() method doesn't make sense in this context.
> 
> -----------  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.
> 
> ---------------- From Me (Third Version) --------------
> 
> interface Input
> {
>     Transaction getNextTransaction();
> }
> 
> interface Output
> {
>     Response process( Transaction trans );
> }
> 
> interface Manipulator
> {
>     Transaction manipulate( Transaction trans );
> }
> 
> ----------------- NOTES -------------------
> 
> * has all the strengths of the second version, but finally gets
>   rid of the method ordering issues.
> 
> * 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.
> 
> 
> ---------------------------------------------
> 
> Ok, any comments?  Do you guys agree?
> 
> "They that give up essential liberty to obtain a little 
> temporary safety
>  deserve neither liberty nor safety."
>                 - Benjamin Franklin
> 
> 
> --
> 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