Re: InfoMover Interfaces: the Proposals

16 Aug 2002 19:48:20 -0000


[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>





--
Nicola Ken Barozzi                   [EMAIL PROTECTED]
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to