Ted Husted wrote:
Is your implementation of Agility something you could share with us, BaTien?
-Ted.
Absolutely and hope some fruits may come out of this discussion.
Intention:
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.
Rationale:
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, etc.
- 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).
BaTien DBGROUPS
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.
<snip/>
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
DBGROUPS
--------------------------------------------------------------------- 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]
