Chapter 1. Architectural Choices
Depending on your environment and goals, you have to decide which components make up the final portal. Some elements may already be in place, such as an identity server, and others may be a matter of choice. This section aims to guide you in making those decisions.
1.1. Identity server
Red Hat JBoss Portal (JBoss Portal) comes with a component named PicketLink IDM, which allows to store and retrieve users and groups from various identity sources. PicketLink IDM supports three general options:
- Database
- Users, groups and their relationships are stored in an RDBMS database. Table names and column names can be changed, but the overall relationship between tables remains the same. This solution suits identity servers that are build from scratch and will handle thousands of users.
- LDAP
- Users, groups and their relationships are stored in an LDAP (or ActiveDirectory) server. The directory's structure can be adapted by configuration to the most common scenarios. This solution is particularly suited to environments that already use an LDAP server, environments that will share the identity server amongst multiple services (the website being one of them) or for very large sets of users (millions). When using LDAP with large number of users, it is recommended to use LDAP tools to do the provisioning of users.
- Custom
- When retrieving users, groups and their relationship cannot be done by configuration, it is possible to use the Picketlink IDM Service Provider Interface (SPI) to implement custom methods which control retrieving and storing user information.
PicketLink IDM also supports mixed environments, which is very useful when an LDAP infrastructure is provided in read-only mode. Since a website may need to store additional information about users (such as their preferred language), LDAP and database services can be combined so that users' information is stored in an LDAP source and additional properties in a database. During calls to the identity API, the information from both sources is merged transparently.
For more information about PicketLink IDM, see the JBoss Portal Administration and Configuration Guide.
1.2. Storage
The portal framework stores page compositions, portlet preferences and gadget code in a database through a Java Content Repository (JCR) API. A set of database servers and JDBC connectors are tested by Red Hat and details of supported configurations can be found on the JBoss Enterprise Portal Platform Supported Configurations page here; http://www.jboss.com/products/platforms/portals/testedconfigurations/ page.
The database schema is automatically created during the initial start up of the portal, at which point it is required that the database users have sufficient rights to create tables. This privilege can be revoked after the initial start up. The database's content can be exported and imported without
CREATE TABLE permission. The automatic creation of the database schema minimizes the manual effort involved in the installation of the product.
Since an RDBMS is not suited to the storage of large files, it is recommended to configure eXo JCR to store such files in the filesystem instead of a database, with metadata about the files stored in the database.
Note
If the website is running on a cluster, the filesystem must be accessible from all nodes and an NFS solution is required. For more details see "value storage" in the chapter eXo JCR.
1.3. Cluster
Clustering to meet failover or load-balancing goals requires a more complex configuration than a single node configuration. There is a cost associated with clustering since Red Hat JBoss Portal 6.1 has some optimizations when running on a single node, but the product is designed to scale linearly so that performance is improved with each new node.
In a cluster environment, all critical components are synchronized across all nodes, while less critical components are de-prioritized to achieve better performance. It is important that custom applications behave in the same manner when replicating data across a cluster of nodes.
The number of nodes required will vary according to factors such as: infrastructure, performance criteria, and applications developed. Performance analysis with tools such as JMeter and Grinder is recommended for measuring the impact of heavy loads prior to production implementation.
1.4. SSO
If a website is a part of a global infrastructure, a deployment of Single-Sign-On (SSO) may be beneficial to end users. Various SSO solutions are supported by Red Hat JBoss Portal, as documented on the "Supported Configurations" page available at https://access.redhat.com/site/articles/119833.
In some cases it can be better to have the token manager service on a specific server.
1.4.1. Summary
The infrastructure required is as follows:
- A database.
- LDAP (Optional).
- NFS (Optional, unless in a cluster configuration with default settings).
- An SSO token service (Optional)
- A cluster of nodes (Optional).
An example of the simplest configuration:
An example of a more complex configuration:
