Before we can decide on this we need to clarify the concept of "portal" a bit better. The one portal approach can mean:
At the beginning of the AEPortal portal project everybody was quite convinced that a single source code base and runtime instance was the right approach. Services should not know about customer segmentations (because this can change quickly).
THE LAST FIVE MONTH HAVE SHOWN THAT WE UNDERESTIMATED THE DIFFERENCES IN ARCHITECTURE AND IMPLEMENTATION CAUSED BY THE DIFFERENCES IN NON-FUNCTIONAL REQUIREMENTS.
•Is it clever to have only one instance of a Portal for a large Enterprise? (update problem, QOS for special customers)
•What is the price of having only one code-base? (missed time to market, missed optimization, missed functionality, missed opportunities)
While the conceptual model of a portal is quite simple, the non-functional requirements can lead to many differences in architecture and implementation.
The Portal conceptual model:
• Must contain the basic building blocks
• Real implementations need to specialize the conceptual model with respect to scalability (batch, caching, SDK) or special requirements (rule engine)
Benefits | Requirements |
Standard coding practices | Requires a module concept that allows all departments to integrate their parts |
Common framework, re-use and efficiency | Requires a service development kit supporting this |
Robust and scalable services | Requires implementations to support large scale and high-speed operation |
Integration of enterprise information systems | Requires backend services to scale enormously Changes to backends (e.g. External Data System) needed |
Centralized operating | Integration into operations infrastructure |
Common services used (authentication, authorization) | Integration into service infrastructure (authentication and authorization services etc.) Wait for those services to complete and scale |
Problems:
• Hard to guarantee Quality of Service for special customers
• Upgrades are hard and dangerous!!
• Upgrades to individual components are tied to general release plan!
My guess: It won’t work!
Not much different from a) besides duplicated operating needs. The biggest benefit is that it is easier to guarantee a certain quality of service for special customers and to make installations more flexible
Benefits | Requirements |
Different installations can be upgraded independently | Need to deal with different releases. Duplicated operating. |
Problems of the Retail Portal:
• Implementation must work on a much larger scale
• Implementation requires different architecture
• No rule engine (performance). Static template based rendering
• High-speed profile server necessary
• High-speed cache server necessary
The common code base would have to follow the retail portal requirements first - because of the scalability problems.
This list is easy to create: take the table from a) and put a NOT in the requirements column.
Benefits | Requirements |
Authorization, page integration etc. will NOT be able to integrate services from other departments automatically | NOT: Requires a module concept that allows all departments to integrate their parts |
No common framework, re-use and efficiency. | NOT: Requires a service development kit supporting this |
Services scale to real need | NOT: Requires implementations to support large scale and high-speed operation |
No Integration of enterprise information systems | NOT: Requires backend services to scale enormously. NOT: Changes to backends |
NO Centralized operating, Quick deployment! | NOT: Integration into operations infrastructure, |
Common services used (authentication, authorization) | NOT: Integration into service infrastructure (ESAUTH,BBS etc.) NOT: wait for those to complete But the integration can be an OPTION! |
Clearly alternative a) sounds the most attractive. It serves all the buzzwords of re-use, framework, scalability etc. The only problem is that AEPortal/SEPortal might show that it simply does not work and that it put EVERYBODY involved into a disadvantage!
Note: SEPortal is much later because of the integration into the large-scale site AEPortal. The large-scale site AEPortal itself is later because some of the technology used for SEPortal does not scale for AEPortal. The reason for this is simply the non-functional requirements which are very different for both portals!
The SEPortal Portal can:
• Live with a simpler architecture because of fewer scalability problems
• Does not need SDK. Needs less caching and batch processing.
• Rule engine possible (fewer user). Advanced XSL based rendering, better integration and aggregation. In general, a small to medium scale portal can serve as a test-bed for new technology that wouldn’t work right away on a large scale.
• No high-speed profile server necessary
• No high-speed cache server necessary
• Faster time to market.
• No need to change back-ends (MADIS etc.)
The Usability tests conducted recently may even force us to recognize fundamentally different user behavior (e.g. much longer sessions for External Asset Manager and other specialists, a much higher degree of customization for those expert groups).
Note: the Servlet API 2.1 introduced HttpSession.setMaxInactiveInterval(int interval). This MIGHT allow a specific timeout PER session.
See: www.javaworld.com/javaworld/jw-12-1998/jw-12-servletapi_p.html (Jason Hunter)