You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <hu...@apache.org> on 2004/12/01 05:17:02 UTC
Re: Chain enhancement idea
Is your implementation of Agility something you could share with us, BaTien?
-Ted.
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts + Chain enhancement idea
Posted by BaTien Duong <ba...@dbgroups.com>.
Ted Husted wrote:
>On Mon, 13 Dec 2004 12:29:06 -0700, BaTien Duong wrote:
>
>
>> This is a showcase of open sources :-)
>>
>>
>
>Are we talking about the next-generation of DB Group's PSI package?
>
>Is this a framework that you will be able to share with the community, or will the code remain in-house?
>
>-Ted.
>
>
>
Greetings:
Yes, it is the next-generation of our Portal Service Infrastructure
(Psi), which hopefully to be appeared by the end of this month or early
next year.
I am very busy to get Psi out of the door with barebone backend
infrastructure and database. When things get a little stable and if
nobody beat us (e.g. CoR agility for portlet), i like to bring it to
Jericho for community improvement. I hope you will have this out first,
Ted, and we will go along with your leadership. :-)
By the way, for the benefit of our developer community, i just read an
article " Creating a Pet Store Application with JavaServer Faces,
Spring, and Hibernate"
http://www.sys-con.com/story/?storyid=46977&DE=1 that demonstrates the
readiness of involved technologies. I like to add 2 things to what the
article has revealed:
1) Jsf and tiles are fuly integrated under myfaces. You do not need 2
jsp pages for every view (a wrapper page and a real fragment). Just 1
fragment jsp that makes a new page and 1 tiles definition. For those who
used Struts-1.x + Tiles to create a portal page (e.g. our current portal
and LifeRay), you may choose to forget about the portlet layout to gain
maximum flexibility for the portlet view i.e. perfectly fit for a
complete jsf dynamic fragment + total flexibility to scrap an html
fragment over the Internet + mixing of [Jsf + Jsp + Jstl] in the portlet
fragment. (I had this issue and asked the Jsf forum. I took me 4 days to
have it worked out and answered myself for the question)
2) CoR agility will make the J2EE application framework much more
component-based SOA as explained in my previous message. The name
Agility, given by Ted, does stand up. :-)
BaTien
DBGROUPS
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts + Chain enhancement idea
Posted by Ted Husted <hu...@apache.org>.
On Mon, 13 Dec 2004 12:29:06 -0700, BaTien Duong wrote:
> This is a showcase of open sources :-)
Are we talking about the next-generation of DB Group's PSI package?
Is this a framework that you will be able to share with the community, or will the code remain in-house?
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts + Chain enhancement idea
Posted by BaTien Duong <ba...@dbgroups.com>.
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: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org