Return-Path: Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 22238 invoked by uid 500); 3 Jul 2003 17:01:18 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 22200 invoked from network); 3 Jul 2003 17:01:17 -0000 Message-ID: <3F0462D9.2000909@nyc.rr.com> Date: Thu, 03 Jul 2003 13:07:37 -0400 From: oleg shteynbuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en, ru MIME-Version: 1.0 To: axis-dev@ws.apache.org Subject: Re: Architecture Guide: Chain of Responsibility, Interceptor and Composite patterns References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N POSA 1 has the Pipes and Filters pattern and it is different from the Composite or the Decorator patterns. GoF Composite pattern has discussion on child ordering that i believe applies to Axis. oleg jzhang@symcor.com wrote: >In GoF it is, it is like exception handling that the processing stops once >a catch statement is invoked. > >Decorator is used to build pipeline-like structure (i.e., chain) >which is a special case of a tree. It is a tree with a single branch so >composite pattern applies to it. >However, "pipeline" seems to be a better wording than composite. > > > > > oleg shteynbuk > rr.com> cc: > Subject: Re: Architecture Guide: Chain of Responsibility, Interceptor and Composite > 02/07/2003 11:37 patterns > PM > Please respond > to axis-dev > > > > > > >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 >>> >>> > > > >>> >> >>> >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 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> > > > > > > > > > >