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:[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]>
