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:47:45 GMT

kevin.s.ruland@mail.sprint.com wrote:
> 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.

Can you please supply a use case in code?
Thanks :-)

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

jakarta-commons-sandbox


Ken

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


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


Mime
View raw message