struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BaTien Duong <>
Subject Re: Struts + Chain enhancement idea
Date Mon, 13 Dec 2004 19:29:06 GMT
Ted Husted wrote:

>Is your implementation of Agility something you could share with us, BaTien?
Absolutely and hope some fruits may come out of this discussion.


Expose some of my experience in using Jsf + Tiles + CoR agility + Spring 
IoC to construct required infrastructure for a modern portal. My bottom 
line is to suggest that this standard component-based SOA portal is 
deliverable now using the above technologies, and that Struts 2 with a 
CoR framework for building standard portlet applications (Shale plus 
Jericho CoR for portlet applications) are  valuable technologies to be 
welcome by many.


Relevant and intelligent portal required a standard framework for 
assembling specialized dynamic processes from sophisticated re-useable 
components. Jsf meets the need. Many parts of a web-based application 
also requires a quick way to add static fragments before a full business 
process can be justified to replace the original static parts. Tiles is 
a proven technology for this job. Portlet specification (JSR 168 plus 
the next round of portlet communication) enables a standard approach for 
content aggregation from specialized portlet applications. Hence a 
portal presentation layer built from Jsf and Tiles will be able to 
leverage many off-the-shelf reuseable components from Jsf and portlet 
technologies. Jsf+Tile, in my opinion, will replace Struts-1.x+Tiles 
(e.g. our current portal and LifeRay) and proprietary API (e.g. Jetspeed 
2 and the rest) portal presentation layer, since vertical portal 
aplications requires complex re-useable components that Jsf can 
economically provide.

Next is the issue of dependencies between software layers, components 
within the same layer and the assembling of a complex process from 
re-useable simple components. CoR chain offers a simple, elegant, but 
very flexible solution. The solution is customized for each specialized 
service between software layers (web layer, business layer, integration 
layer, etc) and modules within the same layer (e.g. portletContainer and 
serviceContainer in the business layer). Within the context of 
assembling a complex process from re-useable components, i view CoR and 
IoC much more flexible and simpler than other alternatives (such as 
cocoon pipeline). In this process, there are many application-level 
singletons and those not directly involved in Jsf (UI). This plus other 
reasons justify the use of Spring IoC.

Implementation process and lessions learned:

1) Leveraging on Jsf configuration and its UI persistence, we build a 
portal interface from a custom tabbedPane connected to a nested company 
and user bean. User enters the site through different url (touch point 
via DNS) is directed to different welcome page with a default guest 
profile and unique id.
   - the portal site can serve many companies, divisions, departments 
with their own name brands just by changing the content of backing 
company bean that contains the company logo vision, product image, menu, 
   - the portal tabs and their layouts are fully personalized and have 
locale support. User can select different layouts for different tab 
panes. No restriction on the layout design since there is no proprietary 
presentation API.
   - the first user requested action will wire default guest profile to 
a complete backend processing via a portalProcessor placed in the user 
session and connected to Jsf UI components. Thus, even without login a 
guest user can personalize all public services. After a successful 
login, user has a choice to continue the current process or override the 
current page with the place last logout and save in the user profile. 
When a system crashed, the user current page can be easily constructed 
thanks to Jsf persistent UI facility.

2) User action is connected to server side processing through Jsf 
actionListener and action. ActionListener assembles user inputs together 
with a designated action command and its service container, and passes 
the request string to the portalProcessor. The action command is a chain 
command and service container is a chain catalog which also serves as 
the container front controller.

The portalProcessor uses the architecture of chain agility. It extends 
the agility pattern of the same name attribute for command, request, 
response objects with an outcome attribute in its received response and 
a pattern of corresponding between business (services, portlets, etc) 
beans and view (jsf managed) bean. Using this naming pattern, the 
portalProcessor updates Jsf managed beans by calling the corresponding 
DTO (example of our pattern is user, userBuilder, and userBean. Our 
xxxBuilder objects are assembled by Spring IoC as singletons.) with 
whatever the changed contents of business beans and set the Jsf 
navigation outcome of the portalTabbedBean. Jsf takes over and renders 
the navigation outcome.

3) The request/response pattern is constructed in each specialized 
software module. Among other things, we have auth for 
authentication/authorization, services for company business processes, 
portlets for embedded portletContainer, dataAccess, etc. Three hot areas 
i think struts-Jericho can have significant immediate impacts are the 
request/response frameworks for implementation-independent portlets in 
any compliant portletContainer, dataAccess and auth. Since CoR isolates 
the dependencies among software modules and components within a module, 
developers can take whatever required for the current job and build 
their component-based SOA infrastructure 1 step at a time. It turns out 
that Struts-Jericho and Struts-Shale from current vision work together 
beautifully and let people choose whatever most fit for their business 
case. Each part of the Struts framework is a top-class piece of 
technology. This is a showcase of open sources :-)

3.1 PortletContainer:

CoR pattern of request/response and its handling mechanism is very 
similar to standard portlet API: actionRequest, actionResponse, 
renderRequest, renderResponse. Jericho implementation of portlet 
protocol will result in a template (similar to Struts Action) for 
creating standard portlet independent of the implementation of 
portletContainer. This is the best part that developers can dream of. 
The next version of Apache portletContainer Pluto 1.1 will probably use 
IoC. This is one reason for us to use Spring IoC as an assembling mechanism.

Under the current implementation, our portletCatalog (the chain catalog) 
is the front controller to interact with embedded portletContainer 
(Pluto). We extend the current portlet protocol with a server-side event 
model and will make it compatible with the standard portlet event of the 
next version. It turns out to be even simpler than Jsf client-side event 
model since it does not need a defined set of phases. The actionResponse 
state is the place for portlet to broadcast its event and the controller 
portletCatalog will take care to call the render phases of interested 
portlets. Instead of inventing another event model, we use JMX generic 
event model as the server-side event model and let portlets to 
participate in our Enterprise Service Bus (ESB) in the integration 
layer. Since business layer and integration layer are usually in the 
same physical server, there is NO DTO between these two. Just direct 
call. Jericho CoR implementation of portlet protocol will definitely set 
its de-facto standard for developers to build on.

3.2 AuthContainer:

A CoR implementation of separate authentication/authorization container 
will definitely be a welcome news to many developers. I found Jetspeed-2 
security implementation based on JAAS is sound. The use of CoR will 
isolate the dependencies of components within the container. For 
example, using CoR we can replace any part of ACL with another one 
without destroying and/or messy patches to other components within the 
same container.

3.3 DataAccessContainer:

A framework of CoR pattern applied to current EJB3 and its DAO will make 
many developers happy.

4. Some more lessions learned:

   - Jsf and Jsp currently have some conflicting issues. Hope that these 
issues will be ironed out in their next versions. So, do not expect a 
smooth ride. But once a working framework has been established, we get a 
lot of rewards due to the availability of off-the-shelf complex UI and 
data-processing components.

   - CoR is a great framework to enable a rough-in to get the job done, 
and a drill-down when there is a business case for it. Out of this 
pattern, we look for many add-in utilities that developers will develop 
for their current needs and donate back to the community.

I will expect may different opinions. The bottom line that benefits all 
developers is a top-class business application framework comming out 
from Struts 2 (Shale and Jericho).


>On Tue, 30 Nov 2004 12:23:39 -0700, BaTien Duong wrote:
>> 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.
>> 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
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message