[chain] Is anybody out there using chain in a production system?

[José Antonio Pérez Testa <ja...@indra.es>]

Hello all,
I'm evaluating commons-chain to implement some sort of components.
The idea is to have components fire events and those events be processed 
in a xml configurable chain of execution.
This schema allows me to insert processing commands in the flow of 
execution dinamically and change from SimulatorExecutor to RealExecutor, 
for example, or to insert a LoggerCommand that writes a detailed log of 
the current event.

In order to give flexibility to the system I have to put almost 
everything in the Context of the Command Chain, that is implemented as a 
Map. This way leads to a lack of robustness and ellegance in the overall 
implementation.

Anybody has faced the same dilema ??
-------------------------------------------------------------------------------------------------------------------
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, contiene información de carácter confidencial exclusivamente dirigida a su destinatario o destinatarios. Queda prohibida su divulgación, copia o distribución a terceros sin la previa autorización escrita de Indra. En el caso de haber recibido este correo electrónico por error, se ruega notificar inmediatamente esta circunstancia mediante reenvío a la dirección electrónica del remitente.

The information in this e-mail and in any attachments is confidential and solely for the attention and use of the named addressee(s). You are hereby notified that any dissemination, distribution or copy of this communication is prohibited without the prior written consent of Indra. If you have received this communication in error, please, notify the sender by reply e-mail

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [chain] Is anybody out there using chain in a production system?

[Craig McClanahan <cr...@gmail.com>]

On Tue, 19 Oct 2004 10:46:59 -0400, Sean Schofield
<se...@schof.com> wrote:

> [snip]
> I think the main drawback to the chain of responsibility (COR) pattern
> is the lack of type safety (and transparency) that pops up in a typical
> implementation.  As you mentioned, commons-chain requires everything to
> be "jammed" into a context.
> 

This is indeed a key consideration ... the price of making the method
signature of a Command be generic is that the state of the computation
is encapsulated in a "context".

However, you do have an architectural choice in how you actually
implement this, thanks to the fact that the base implementation of
Context provided in [chain] supplies "attribute-property
transparency":

* Command implementations may treat the Context argument
  as an opaque Map, calling get() and put() operations with
  casts in the usual way.

* The application architecture may supply subclasses of
  Context that include typesafe properties for application specific
  "well known" properties, but allows the use of generic accessors
  for everything else.  The Command would have to cast the
  Context instance, but from there on gains type safety for the
  well known things.

Indeed, [chain] supplies examples of the latter technique in the
org.apache.commons.chain.web package, where predefined slots for
things specific to using [chain] in a web environment are provided. 
My sense is that, no matter how generic we try to make our commands,
we're always building in *some* level of assumptions about the
contents of the Context (if nothing else, you have to agree on keys,
for example).  Therefore, I will tend to write application specific
context classes for the most commonly shared attributes.

It's also possible to think about Context items being used in more
than one application specific context -- for that, you can define the
typesafe properties contract for each application domain in an
interface that extends Context, and then build an implementation that
implements all of the interfaces.

It's not perfect, but to me this approach seems like a reasonable
tradeoff for the flexibility that [chain] gives you in composing the
processing that will actually happen.

Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [chain] Is anybody out there using chain in a production system?

[Sean Schofield <se...@schof.com>]

Jose,

We are getting ready to use commons-chain in a production system.  I 
think it works quite well for certain problems.  You'll want to make 
sure you have the latest build because we just added a few things to it 
yesterday (also the javadoc on the commons-lang site does not mention 
these new classes.)

I think the main drawback to the chain of responsibility (COR) pattern 
is the lack of type safety (and transparency) that pops up in a typical 
implementation.  As you mentioned, commons-chain requires everything to 
be "jammed" into a context.

I have a few thoughts on how I plan to use commons-chain after 
considering the pros and cons.  You can take 'em or leave em.

I think chain is most appropriate when you can use it with only a 
limited number of objects in the context.  My application deals with 
documents (which are beans with lots of properties, some of which are 
beans themselves.)  So when a user wants to save changes to a document, 
I  have a chain for "saving".  Each command in the chain can check the 
part of the document that it is interested in and handle changes as it 
sees fit.  I've got one or two other objects in the context (such as 
"user") but its mostly just document.  None of my commands add anything 
or remove anything to the context because there is no assumption about 
what command is next in the chain.

I also have a chain for reading a document from the database.  I create 
an empty document object and put it into my context and then kick off 
the chain.  Each command populates the portion of the document its 
concerned with.  I don't really like the idea of my commands "returning" 
information through the context.  I limit myself to modifying at most 
one object in the context and make it clear that the chains only 
function is to modify that document (in the read case) or to read that 
document and perform some function (in the save case.)

Well there's some ideas for you. 

HTH,
sean


José Antonio Pérez Testa wrote:

> Hello all,
> I'm evaluating commons-chain to implement some sort of components.
> The idea is to have components fire events and those events be 
> processed in a xml configurable chain of execution.
> This schema allows me to insert processing commands in the flow of 
> execution dinamically and change from SimulatorExecutor to 
> RealExecutor, for example, or to insert a LoggerCommand that writes a 
> detailed log of the current event.
>
> In order to give flexibility to the system I have to put almost 
> everything in the Context of the Command Chain, that is implemented as 
> a Map. This way leads to a lack of robustness and ellegance in the 
> overall implementation.
>
> Anybody has faced the same dilema ??
> ------------------------------------------------------------------------------------------------------------------- 
>
> Este correo electrónico y, en su caso, cualquier fichero anexo al 
> mismo, contiene información de carácter confidencial exclusivamente 
> dirigida a su destinatario o destinatarios. Queda prohibida su 
> divulgación, copia o distribución a terceros sin la previa 
> autorización escrita de Indra. En el caso de haber recibido este 
> correo electrónico por error, se ruega notificar inmediatamente esta 
> circunstancia mediante reenvío a la dirección electrónica del remitente.
>
> The information in this e-mail and in any attachments is confidential 
> and solely for the attention and use of the named addressee(s). You 
> are hereby notified that any dissemination, distribution or copy of 
> this communication is prohibited without the prior written consent of 
> Indra. If you have received this communication in error, please, 
> notify the sender by reply e-mail
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [chain] Is anybody out there using chain in a production system?

[Sean Schofield <se...@gmail.com>]

On Tue, 19 Oct 2004 21:03:47 -0700, Craig McClanahan <cr...@gmail.com> wrote:
> By the way, don't miss the recently implemented changes from Sean that
> allow a nice way to look up catalogs in a catalog factory without
> having to pass any arguments around.  I'm definitely going to leverage
> that in struts-chain and other places.
> 

Craig, just an FYI that the latest javadoc on the chains site doesn't
mention these new classes.  No rush, but at some point we should
update it.  The javadoc is often the first place I look when
evaluating something like this.

> Craig

sean

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [chain] Is anybody out there using chain in a production system?

[Craig McClanahan <cr...@gmail.com>]

On Tue, 19 Oct 2004 14:24:02 -0500, Vic Cekvenich
<ce...@portalvu.com> wrote:

> We are using it in alpha.
> It is wounderfull. At the end of the project, we have a bunch of "same
> size bricks" and have interchanged them quite a bit.
> I used to use IoC.

Interesting comment from someone who has been a fairly strong advocate
of IoC :-).  I'd be interested in hearing more about what you found
beneficial using CoR instead -- it sounds like the Lego analogy
(everything plugs together the same way) might be part of it -- and/or
if there is anything that would improve the design of [chain] before
we go 1.0 with it.

By the way, don't miss the recently implemented changes from Sean that
allow a nice way to look up catalogs in a catalog factory without
having to pass any arguments around.  I'm definitely going to leverage
that in struts-chain and other places.

> .V

Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [chain] Is anybody out there using chain in a production system?

[Vic Cekvenich <ce...@portalvu.com>]

We are using it in alpha.
It is wounderfull. At the end of the project, we have a bunch of "same 
size bricks" and have interchanged them quite a bit.
I used to use IoC.
.V

José Antonio Pérez Testa wrote:
> Hello all,
> I'm evaluating commons-chain to implement some sort of components.
> The idea is to have components fire events and those events be processed 
> in a xml configurable chain of execution.
> This schema allows me to insert processing commands in the flow of 
> execution dinamically and change from SimulatorExecutor to RealExecutor, 
> for example, or to insert a LoggerCommand that writes a detailed log of 
> the current event.
> 
> In order to give flexibility to the system I have to put almost 
> everything in the Context of the Command Chain, that is implemented as a 
> Map. This way leads to a lack of robustness and ellegance in the overall 
> implementation.
> 
> Anybody has faced the same dilema ??
> ------------------------------------------------------------------------------------------------------------------- 
> 
> Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, 
> contiene información de carácter confidencial exclusivamente dirigida a 
> su destinatario o destinatarios. Queda prohibida su divulgación, copia o 
> distribución a terceros sin la previa autorización escrita de Indra. En 
> el caso de haber recibido este correo electrónico por error, se ruega 
> notificar inmediatamente esta circunstancia mediante reenvío a la 
> dirección electrónica del remitente.
> 
> The information in this e-mail and in any attachments is confidential 
> and solely for the attention and use of the named addressee(s). You are 
> hereby notified that any dissemination, distribution or copy of this 
> communication is prohibited without the prior written consent of Indra. 
> If you have received this communication in error, please, notify the 
> sender by reply e-mail


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org