Architecture is the foundation phase of building a portal application around which the other portal phases revolve, as shown in Figure 3-1.
Figure 3-1 Architecture Phase of the Portal Life Cycle
In the architecture phase you make the important design decisions about your portal application and its features that guide your portal development and administration. You define your application’s business processes, which involves:
Identifying resources such as web services, portal services, Java controls, data views, remote portals, content management, and search.
Determining security needs at different points in the processes.
Designing how different parts of your processes are to be surfaced in a portal user interface.
Determine if you want to share your portal with remote portals.During architecture you also create any necessary resources needed for your development efforts.
Avoid the temptation begin application development without proper planning and design. While bypassing architecture and moving straight to development may reap short-term benefits in development speed, your projects may suffer from confusion and inconsistency, have poor scalability and performance, be difficult to manage, and may ultimately take longer to develop.
When thinking about architecture, the guiding question should be, “What do we absolutely have to design and do before we start portal application development?” If any item on your list is not essential prior to development, do not include it in the architecture phase.
The planning and design that marks the architecture phase occur at multiple levels: the domain and enterprise application, the web application, and the individual feature areas.
This chapter provides an overview of the types of issues to consider in the architecture phase at all levels.
This section shows examples of architecture decisions you make and resources you create at each level.
Domain
The following are architecture decision and tasks for the domain:
Determine your staging strategy (such as cluster configuration, connection to an external authentication provider, and connection to an external content management system).
Determine your production strategy (such as cluster configuration, connection to an external authentication provider, and connection to an external content management system).
Determine whether you will store user properties externally or use WebLogic Platform’s LDAP user store.
Determine which database you will use.
Determine which external corporate systems you want to integrate into your portal applications.
Determine your team development and source control strategies.
Create a custom domain template (with appropriate string substitutions) for developers to create a development domain in their development environments.
Create custom SQL scripts for developers to populate their development databases.
Define coding conventions.
Define the process for moving application code and data between environments.
Portal Enterprise Application
The following are architecture decision and tasks for the portal enterprise application:
Create/reuse custom EJBs (corporate logic), servlets, Java source code, branding resources, and other enterprise application resources.
Create a custom portal enterprise application template for developers to populate their development environments.
Design the types of corporate applications you want to develop (such as custom administration consoles, executive dashboards, communities, ASP affiliate applications, ISV-branded applications, self-service applications, and OA&M applications).
Determine security requirements for each type of application you will create.
Determine application cache settings for performance.
Portal Web Application
The following are architecture decision and tasks for the portal enterprise application:
Create a custom portal web application template for developers to populate their development environments.
Determine the desktops and community templates you want to create.
Create custom look and feels.
Create or reuse custom JSP tag libraries, Java source code, and other web application resources.
Determine if there are remote books, pages, and portlets you want to consume in your portal application.
Feature Areas
For each WebLogic Portal feature you use, there are specific design decisions you must make. For example, if you are using campaigns:
Determine what conditions trigger campaigns (such as date/time, user profile properties, or events).
If you are using events to provide precise control over campaigns, design those events.
Determine the content properties needed to support your campaign content queries. For example, do you need a “season” property with values of “spring”, “summer”, “winter”, and “fall”, so that content added in the production environment with one of those values is picked up by campaigns automatically?
Decide whether or not a campaign can end before its end date if specific content items are viewed or clicked.
Architecture Tools and Resources
After the planning, design, and resource creation in the architecture phase, developers get those resources from source control and develop applications with the design guidelines. In conjunction with development, developers and administrators configure and test the application and its features in the staging environment. When the application is ready for release, administrators deploy it to the production environment where the end users access it. The following are links to the architecture section for each of the WebLogic Portal feature guides:
