We consider a design of uniform building blocks for an enterprise application portal, were the building blocks are EAR files that deliver UI as well as busines logic in one deployment. I'm interested in your opinion on this. Let me explain that:
- we want to build up on the best practices and open standards
- building blocks (one EAR) group business use cases
- the portal presents the available use cases to the user as it chooses from the deployed use cases (that calls for some kind of registry, hopefully EJB jndi is sufficient)
- we create portal pages for each instance of a use case (that gives the user something like tabbed browsing: one tab for each use case),
- on that page there are several portlets from different EARs (!) that are grouped and controlled under guidance of one orchestrating building block (an EJB), while the portlet implementation remains within the boundaries of its EAR
- a use case has a page flow
- we have a portlet that has navigation menu for the page flow
- we have on the use case portal page a working region where at one time there will only be one portlet displayed
- the page flow is beyond JSF page flow: it can render various portlets on the working area. When the portlet (the jsf app within, to be exactly) finishes its user interaction, the page flow takes over and renders the next portlet in flow to the working area
Why the efforts? We want to have those building blocks to be highly reusable, especially the UI must be reusable "as is"; the cohesion within the building block is high since it s coupled with its UI as well as with its database tier.
What i need is some kind of injection of portlets within other portlets (or at least their controllers), so that one controller calls another when he likes to give him preset values and when he wants to extract return values from the portlets.
In the Seam group I read warnings not to declare dependencies on EJBs from foreign ear files because of class loader issues, and I read that it was not possible to biject EJBs from foreign ears.
So I was thinking about leveraging the Seam concepts to the Portal?
I could imagine that portal page to be the visualization of something like a new SEAM context.
Any opinions to that?