Sun Microsystems Portal Server 6 2005Q1, Planning Manual

Page: 88 / 192

Portal Server System Communication Links
88 Portal Server 6 2005Q1 • Deployment Planning Guide
• Figure 5-1 on page 87 shows that if the following processes or communication
links fail, the portal solution becomes unavailable to end users: Portal Server
Instance
. Runs in the context of a web container. Components within an
instance communicate through the JVM™ using Java™ APIs. An instance is a
fully qualified domain name and a TCP port number. Portal Server services are
web applications that are implemented as servlets or JSP™ files.
Portal Server is built on top of Access Manager for authentication single
sign-on (session) management, policy, and profile database access. Thus, Portal
Server inherits all the benefits (and constraints) of Access Manager with
respect to availability and fault tolerance.
By design, Access Manager’s services are either stateless or the services can
share context data. Services can recover to the previous state in case of a service
failure.
Within Portal Server, Portal Desktop and NetMail services do not share state
data among instances. This means that an instance redirect causes the user
context to be rebuilt for the enabled services. Usually, redirected users do not
notice this because Portal Server services can rebuild a user context from the
user’s profile, and by using contextual data stored in the request. While this
statement is generally true for out-of-the-box services, it might not be true for
channels or custom code. Developers need to be careful to not design stateful
channels to avoid loss of context upon instance failover.
• Profile Database Server . The profile database server is implemented by
Directory Server software. Although this server is not strictly part of Portal
Server, availability of the server and integrity of the database are fundamental
to the availability of the system.
• Authentication Server . This is the directory server for LDAP authentication
(usually, the same server as the profile database server). You can apply the
same high availability techniques to this server as for the profile database
server.
• SRA Gateway and Proxies . The SRA Gateway is a standalone Java technology
process that can be considered stateless, because state information can be
rebuilt transparently to end users. The Gateway profile maintains a list of
Portal Server instances and does round robin load balancing across the
Gateway instances. Session stickiness is not required in front of a Gateway, but
with session stickiness, performance is better. On the other hand, session
stickiness to Portal Server instances is enforced by SRA.