You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by jz...@symcor.com on 2003/07/02 22:41:24 UTC
Re: Architecture Guide: Chain of Responsibility, Interceptor and Composite
patterns
In GoF, the closest pattern should be "decorator", not chain of
responsibility.
oleg shteynbuk
<oshteynbuk@nyc. To: axis-dev@ws.apache.org
rr.com> cc:
Subject: Architecture Guide: Chain of Responsibility, Interceptor and Composite
27/06/2003 07:00 patterns
PM
Please respond
to axis-dev
Thanks for "Axis Architecture Guide" it was very useful to me.
Below is a feedback::
1) In "Message Flow Subsystem" -> "Handlers and Chains" under the
second diagram first paragraph:
"A Chain also has similarities to the Chain of Responsibility design
pattern in which a request flows along a sequence of Handlers until it
is processed. Although an Axis Chain may process a request in stages
over a succession of Handlers, it has the same advantages as Chain of
Responsibility: flexibility and the ease with which new function can be
added."
I don't believe that there are similarities to the Chain of
Responsibility design pattern. GoF implies that each handler in the
chain either handlers the request completely and chain stops there, or
if it could not handle the request then it passes the request to its
successor without doing anything. "The Design Patterns Smalltalk
Companion" book in chapter on Chain of Responsibility discusses OO
recursion and says that examples of Chain of Responsibility is hard to
find and considers Chain of Responsibility a specialization of
Object-Oriented recursion but we do not have recursion here, it looks
more like an iteration.
Flexibility and the ease with which new function can be added are also
different. In the Chain of Responsibility handlers are chained and each
handler has a reference to the next one and it is usually used if you
want to configure chain at run time. In Axis handlers usually are
configured at design time in deployment configuration and we have more
like AOP interceptors and some processing or weaving is needed before we
can use it.
Interceptors and AOP becoming increasingly popular, and a lot of
developers are familiar with it, did i mention JBoss. Interceptor would
be also more descriptive word then handler.
BTW theserverside.com recently has a discussion "Opinion: Interceptors
should be added to J2EE".
it make sense to replace the Chain of Responsibility paragraph with:
"Handlers act like interceptors, the Interceptor pattern is in POSA 2
book."
2) The sentence before the same diagram in "Message Flow Subsystem"
-> "Handlers and Chains"
"A Chain is a composite Handler, i.e. it aggregates a collection of
Handlers as well as implementing the Handler interface as shown in the
following UML diagram:"
and after the diagram it make sense to add the following sentence to
clarify relationship to the GoF Composite pattern.
"Interface Chain acts like a Composite and interface Handler like a
Component from the GoF Composite pattern. In GoF Component is a common
abstract class; in Axis Handler is an interface that Chains and Handlers
implement so they could be treated uniformly."
I believe that Composite pattern usage is related to item 4 in the "Open
Issues" chapter.
3) The Iterator pattern could be mention too and there are other
patterns that are used internally in Axis. Maybe it make sense to have
two Architectural Guides, one simplified version for Axis users and
another one with all patterns for Axis developers.
oleg
Re: Architecture Guide: Chain of Responsibility, Interceptor and
Composite patterns
Posted by oleg shteynbuk <os...@nyc.rr.com>.
If your goal is to choose from GoF then the Decorator pattern will be
the one that you will thin of. there are some similarity to decorator,
in a sense that it is about extending functionality. But the same
arguments that were in original mail apply to Decorator too except for
the argument that in Chain of Responsibility the first handler that can
handle request stops the chain. You can probably use the Decorator to
implement the Interceptor pattern if you replace iteration with OO
recursion, but i like the current Axis implementation, it is an
excellent design, and Architecture Guide is very good; this particular
part on Chain of Responsibility was a little bit misleading to me, but
it was not a big deal because reading further it was very clear what
handlers are actually doing.
in the Interceptor pattern there is a Dispatcher class that in addition
to this can control the behavior of framework and not simply forward the
request.
POSA 1 group pattern into three categories: design, idioms and
architectural. According to this classification GoF is about design
patterns and POSA 1 and 2 discusses architectural patterns too. However
when implementing the Interceptor pattern from POSA 2 GoF patterns will
be used and i believe that Axis uses the Composite, the Iterator and
probably the Strategy and some others.
oleg
jzhang@symcor.com wrote:
>In GoF, the closest pattern should be "decorator", not chain of
>responsibility.
>
>
>
>
> oleg shteynbuk
> <oshteynbuk@nyc. To: axis-dev@ws.apache.org
> rr.com> cc:
> Subject: Architecture Guide: Chain of Responsibility, Interceptor and Composite
> 27/06/2003 07:00 patterns
> PM
> Please respond
> to axis-dev
>
>
>
>
>
>
>Thanks for "Axis Architecture Guide" it was very useful to me.
>Below is a feedback::
>
>1) In "Message Flow Subsystem" -> "Handlers and Chains" under the
>second diagram first paragraph:
> "A Chain also has similarities to the Chain of Responsibility design
>pattern in which a request flows along a sequence of Handlers until it
>is processed. Although an Axis Chain may process a request in stages
>over a succession of Handlers, it has the same advantages as Chain of
>Responsibility: flexibility and the ease with which new function can be
>added."
>
>I don't believe that there are similarities to the Chain of
>Responsibility design pattern. GoF implies that each handler in the
>chain either handlers the request completely and chain stops there, or
>if it could not handle the request then it passes the request to its
>successor without doing anything. "The Design Patterns Smalltalk
>Companion" book in chapter on Chain of Responsibility discusses OO
>recursion and says that examples of Chain of Responsibility is hard to
>find and considers Chain of Responsibility a specialization of
>Object-Oriented recursion but we do not have recursion here, it looks
>more like an iteration.
>
>Flexibility and the ease with which new function can be added are also
>different. In the Chain of Responsibility handlers are chained and each
>handler has a reference to the next one and it is usually used if you
>want to configure chain at run time. In Axis handlers usually are
>configured at design time in deployment configuration and we have more
>like AOP interceptors and some processing or weaving is needed before we
>can use it.
>
>Interceptors and AOP becoming increasingly popular, and a lot of
>developers are familiar with it, did i mention JBoss. Interceptor would
>be also more descriptive word then handler.
>BTW theserverside.com recently has a discussion "Opinion: Interceptors
>should be added to J2EE".
>
>it make sense to replace the Chain of Responsibility paragraph with:
>"Handlers act like interceptors, the Interceptor pattern is in POSA 2
>book."
>
>2) The sentence before the same diagram in "Message Flow Subsystem"
>-> "Handlers and Chains"
>"A Chain is a composite Handler, i.e. it aggregates a collection of
>Handlers as well as implementing the Handler interface as shown in the
>following UML diagram:"
>and after the diagram it make sense to add the following sentence to
>clarify relationship to the GoF Composite pattern.
>"Interface Chain acts like a Composite and interface Handler like a
>Component from the GoF Composite pattern. In GoF Component is a common
>abstract class; in Axis Handler is an interface that Chains and Handlers
>implement so they could be treated uniformly."
>I believe that Composite pattern usage is related to item 4 in the "Open
>Issues" chapter.
>
>3) The Iterator pattern could be mention too and there are other
>patterns that are used internally in Axis. Maybe it make sense to have
>two Architectural Guides, one simplified version for Axis users and
>another one with all patterns for Axis developers.
>
>oleg
>
>
>
>
>
>
>
>
>
>
Re: Architecture Guide: Chain of Responsibility, Interceptor and
Composite patterns
Posted by oleg shteynbuk <os...@nyc.rr.com>.
I believe that GoF says in the Chain of Responsibility is that more then
one object may handle the event but the first one that can handle the
event stops the chain. and it is actually not the only argument.
oleg
Srinath Perera wrote:
>Hi all
>
>It is through when the chin of responsibility is discuss it says that
>either a object handle it or passed to sucssesor.
>But I belive it is geneally said one can use it in such a way number of
>handlers handle the request.
>e.g. The book design Patterns, elements of object reusable object
>oriented software, Erich Gamma... under appliability it mention about
>more than one handler handles the request.
>
>I am not a expert in this area, but I belive the fact that more than one
>handler handle the request alone does not imply that it is not change
>of responsibility.
>
>regards
>Srianth
>
>---------------
> Lanka Software Foundation (http://www.opensource.lk)
> Promoting Open-Source Development in Sri Lanka.
> ---------------
>
>
>
>On Thu, 2003-07-03 at 02:41, jzhang@symcor.com wrote:
>
>
>>In GoF, the closest pattern should be "decorator", not chain of
>>responsibility.
>>
>>
>>
>>
>> oleg shteynbuk
>> <oshteynbuk@nyc. To: axis-dev@ws.apache.org
>> rr.com> cc:
>> Subject: Architecture Guide: Chain of Responsibility, Interceptor and Composite
>> 27/06/2003 07:00 patterns
>> PM
>> Please respond
>> to axis-dev
>>
>>
>>
>>
>>
>>
>>Thanks for "Axis Architecture Guide" it was very useful to me.
>>Below is a feedback::
>>
>>1) In "Message Flow Subsystem" -> "Handlers and Chains" under the
>>second diagram first paragraph:
>> "A Chain also has similarities to the Chain of Responsibility design
>>pattern in which a request flows along a sequence of Handlers until it
>>is processed. Although an Axis Chain may process a request in stages
>>over a succession of Handlers, it has the same advantages as Chain of
>>Responsibility: flexibility and the ease with which new function can be
>>added."
>>
>>I don't believe that there are similarities to the Chain of
>>Responsibility design pattern. GoF implies that each handler in the
>>chain either handlers the request completely and chain stops there, or
>>if it could not handle the request then it passes the request to its
>>successor without doing anything. "The Design Patterns Smalltalk
>>Companion" book in chapter on Chain of Responsibility discusses OO
>>recursion and says that examples of Chain of Responsibility is hard to
>>find and considers Chain of Responsibility a specialization of
>>Object-Oriented recursion but we do not have recursion here, it looks
>>more like an iteration.
>>
>>Flexibility and the ease with which new function can be added are also
>>different. In the Chain of Responsibility handlers are chained and each
>>handler has a reference to the next one and it is usually used if you
>>want to configure chain at run time. In Axis handlers usually are
>>configured at design time in deployment configuration and we have more
>>like AOP interceptors and some processing or weaving is needed before we
>>can use it.
>>
>>Interceptors and AOP becoming increasingly popular, and a lot of
>>developers are familiar with it, did i mention JBoss. Interceptor would
>>be also more descriptive word then handler.
>>BTW theserverside.com recently has a discussion "Opinion: Interceptors
>>should be added to J2EE".
>>
>>it make sense to replace the Chain of Responsibility paragraph with:
>>"Handlers act like interceptors, the Interceptor pattern is in POSA 2
>>book."
>>
>>2) The sentence before the same diagram in "Message Flow Subsystem"
>>-> "Handlers and Chains"
>>"A Chain is a composite Handler, i.e. it aggregates a collection of
>>Handlers as well as implementing the Handler interface as shown in the
>>following UML diagram:"
>>and after the diagram it make sense to add the following sentence to
>>clarify relationship to the GoF Composite pattern.
>>"Interface Chain acts like a Composite and interface Handler like a
>>Component from the GoF Composite pattern. In GoF Component is a common
>>abstract class; in Axis Handler is an interface that Chains and Handlers
>>implement so they could be treated uniformly."
>>I believe that Composite pattern usage is related to item 4 in the "Open
>>Issues" chapter.
>>
>>3) The Iterator pattern could be mention too and there are other
>>patterns that are used internally in Axis. Maybe it make sense to have
>>two Architectural Guides, one simplified version for Axis users and
>>another one with all patterns for Axis developers.
>>
>>oleg
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
Re: Architecture Guide: Chain of Responsibility, Interceptor and
Composite patterns
Posted by Srinath Perera <he...@vijayaba.cse.mrt.ac.lk>.
Hi all
It is through when the chin of responsibility is discuss it says that
either a object handle it or passed to sucssesor.
But I belive it is geneally said one can use it in such a way number of
handlers handle the request.
e.g. The book design Patterns, elements of object reusable object
oriented software, Erich Gamma... under appliability it mention about
more than one handler handles the request.
I am not a expert in this area, but I belive the fact that more than one
handler handle the request alone does not imply that it is not change
of responsibility.
regards
Srianth
---------------
Lanka Software Foundation (http://www.opensource.lk)
Promoting Open-Source Development in Sri Lanka.
---------------
On Thu, 2003-07-03 at 02:41, jzhang@symcor.com wrote:
> In GoF, the closest pattern should be "decorator", not chain of
> responsibility.
>
>
>
>
> oleg shteynbuk
> <oshteynbuk@nyc. To: axis-dev@ws.apache.org
> rr.com> cc:
> Subject: Architecture Guide: Chain of Responsibility, Interceptor and Composite
> 27/06/2003 07:00 patterns
> PM
> Please respond
> to axis-dev
>
>
>
>
>
>
> Thanks for "Axis Architecture Guide" it was very useful to me.
> Below is a feedback::
>
> 1) In "Message Flow Subsystem" -> "Handlers and Chains" under the
> second diagram first paragraph:
> "A Chain also has similarities to the Chain of Responsibility design
> pattern in which a request flows along a sequence of Handlers until it
> is processed. Although an Axis Chain may process a request in stages
> over a succession of Handlers, it has the same advantages as Chain of
> Responsibility: flexibility and the ease with which new function can be
> added."
>
> I don't believe that there are similarities to the Chain of
> Responsibility design pattern. GoF implies that each handler in the
> chain either handlers the request completely and chain stops there, or
> if it could not handle the request then it passes the request to its
> successor without doing anything. "The Design Patterns Smalltalk
> Companion" book in chapter on Chain of Responsibility discusses OO
> recursion and says that examples of Chain of Responsibility is hard to
> find and considers Chain of Responsibility a specialization of
> Object-Oriented recursion but we do not have recursion here, it looks
> more like an iteration.
>
> Flexibility and the ease with which new function can be added are also
> different. In the Chain of Responsibility handlers are chained and each
> handler has a reference to the next one and it is usually used if you
> want to configure chain at run time. In Axis handlers usually are
> configured at design time in deployment configuration and we have more
> like AOP interceptors and some processing or weaving is needed before we
> can use it.
>
> Interceptors and AOP becoming increasingly popular, and a lot of
> developers are familiar with it, did i mention JBoss. Interceptor would
> be also more descriptive word then handler.
> BTW theserverside.com recently has a discussion "Opinion: Interceptors
> should be added to J2EE".
>
> it make sense to replace the Chain of Responsibility paragraph with:
> "Handlers act like interceptors, the Interceptor pattern is in POSA 2
> book."
>
> 2) The sentence before the same diagram in "Message Flow Subsystem"
> -> "Handlers and Chains"
> "A Chain is a composite Handler, i.e. it aggregates a collection of
> Handlers as well as implementing the Handler interface as shown in the
> following UML diagram:"
> and after the diagram it make sense to add the following sentence to
> clarify relationship to the GoF Composite pattern.
> "Interface Chain acts like a Composite and interface Handler like a
> Component from the GoF Composite pattern. In GoF Component is a common
> abstract class; in Axis Handler is an interface that Chains and Handlers
> implement so they could be treated uniformly."
> I believe that Composite pattern usage is related to item 4 in the "Open
> Issues" chapter.
>
> 3) The Iterator pattern could be mention too and there are other
> patterns that are used internally in Axis. Maybe it make sense to have
> two Architectural Guides, one simplified version for Axis users and
> another one with all patterns for Axis developers.
>
> oleg
>
>
>
>
>
>
>