Pilgrim, Peter wrote:
-----Original Message-----
From: BaTien Duong [mailto:[EMAIL PROTECTED]
Greetings and request expert advice:
Commons-chain invented by Craig proves to be very flexible and work in conjuction with other great technonologies. What i am trying to figure out is a proper and practical places for using CoR and IoC (such as Spring framework) in the construction and configuration of software objects. I put out some of my preliminary thinking and hope some experts care to add more arguments to enlighten us.
1) Both CoR and IoC (and also Jsf setter injection) enable the configuration and linking objects via XML metadata. But IoC allows the object configuration at a finer level of object attributes and take care of the objects declared as singleton. In this sense, IoC is finer grain than CoR in object creation, configuration and management.
2) CoR is very light weight and appropriate for programmatically created processes. It does not not have the complexity and the depth of plug-in features as Spring IoC.
Chain of Responsibility is pattern that separates the sending of a
message from the receiver of message. So it solves different problem for inverse of control. I think you are
looking at this from the perspective of `callback interfaces',
therefore IoC appears to have much more power and depth.
3) CoR is finer grain than IoC in the construction and rounting of services within and between software layers, while IoC is aprropriate at the application level.
IoC is an application level, because it does help with configuration
and look up of services, beans or other artefacts. The CoR is a messaging pattern primarily. It is not a question
of either CoR or IoC, you can use both of them together.
The question is how? That is question of architecture, what is the best way to build a house, I think you will find a million and one answers there. There are ways of designing software, but one needs to understand what the patterns are, what are they purporting to solve. After that it is easier to decide if a particular pattern is heavy or lightweight, better or worse, because each pattern has it original context of application.
hth
Here is how based on my working prototype:
Using commons-chain Agility, i build a request/response framework for communicating and specialized processing between different software layers or containers: web tier with portal container, business tier with containers such as authentication/authorization, portlets, services, etc. Each container is a singleton catalog to provide its specialized action commands. Each specialized thread-safe command just extends its base and override the handle(request) method similar to Struts actionCommand. Spring IoC is used to instantiate and configure application singletons (such as catalog) with default attributes, while CoR commands are instantiated only when needed and will be removed from its catalog if not used by a specified time.
In the above framework, i use Jsf+Tile as a view controller. A page is submitted directly to Jsf which is routed to a tile definition via MyFaces. I intent to use Shale as the application controller when shale has a custom ViewHandler to handle tiles. Currently, i use shale as a single servlet filter to wrap all application filters.4) If we want to combine Jsf as view controller, Spring IoC and commons-chain CoR, a practical infrastructure may be something like followings:
a) Jsf as a view controller takes care of objects directly related to User Interface (UI)
b) Spring IoC takes the responsibility of object creation, especially singletons and fine grain configurations of objects not directly related to UI. This is a proper choice of configuration if other features of Spring framework such as application level event and aop are used.
An IoC container can take over construction of objects that you required a lightweight container full stop (period).
If you want to take advantage of AOP light weight containers then you must register your objects with
the IoC container beforehand.
c) CoR is used to construct Front Controller a la pattern of Struts of each software module, the rounting of services among modules, and action commands (or chain) of specialized services in each service module. It programmatically links created components from IoC to a finer grain at each software module, which holds the module Catalog of commands.
I think Struts is a FrontController. So I'd be more inclined
to let Struts be Struts.
There appears to be confusion about CoR and IoC and also various idioms and patterns common place in the J2EE world.
In the new Struts applications I think there are three chains:
front controller, action, and view. The chain of the front controller
effectively ties together the CoR for the request processor.
The other two chains are for Web User Interface "actions" and "view" rendering technologies.
I think the latter two chains are well understood, but the
"front controller" chain is not at the moment, at least by me.
The original idea of commons chain was to solve the request
processor implementation debacle. If I have subclass `TilesRequestProcessor' with a class `MySpecialRequestProcessor', there was no way I could
also make it a subclass of another implementation ie `WorkflowRequestProcessor'. The theory is to compose
your own request processor, but has anyone got a working
example of such a beastie (yet)?
User action event is handled by Jsf actionListener that passes user and hidden inputs (which include not only the requested action but also the catalog of the action and other properties) to the processUserAction(passedString) of an adapter. It receives the request outcome and set the outcome for Jsf navigation.
Under this framework, chain catalog is the front controller of its specialized container, whose commands are very similar to struts actionCommand which must be done in thread safe. Since a chain is also a command, we can later drill down to a more elaborate process driven by business. The framework is very neat and flexible. That may be the reason why Ted calls his little framework Agility.
BaTien DBGROUPS
==////==
--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston, 10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497
============================================================================== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ==============================================================================
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
