At the back end, each deployment requires some form of a user directory. This can be as simple as leveraging an embedded file-based repository to support a pilot deployment and as complex as enabling a mix of multiple corporate LDAP subtrees. Lotus Connections leverages the WebSphere Application Server federated repository functionality to provide this support. The list of directories supported by Lotus Connections includes Sun Java System Directory Server 5.2, SunOne 6, IBM Lotus Domino^® Versions 7.0.2 and 8, Microsoft Active Directory 2003 SP2, Microsoft ADAM, IBM Tivoli Directory Server 6.0.0.3 and 6.1, and Novell eDirectory 8.8. Each of these directories does not have an individual listing in the WebSphere federated repository directory type selector but rather should be mapped to the selections detailed in Table 3.1.

Once configured, the directory information is leveraged for two purposes within Lotus Connections. The first purpose is authentication and authorization. The second is user profile metadata. In all cases, your LDAP server will be used to verify user credentials, but it is not required that all user metadata resides in this same directory server that was selected from Table 3.1. In complex deployment scenarios in large organizations, the realities of a directory topology necessitate the flexibility to be able to retrieve user profile metadata from alternate repositories including secondary directories, CRM systems, and proprietary storage databases. An important service that Lotus Connections brings to a production deployment is the ability to collect and surface this user information seamlessly from all of these sources, open or propriety, through standard and custom TDI production lines. More on these production lines is discussed in the following section.

If your directory information does not live in a single traditional directory, Lotus Connections Profiles will offer the necessary glue to roll out each of the social software services available in Lotus Connections and enable your organization to build additional Web 2.0 applications that require a unified user repository available through modern REST-based access techniques. In addition, Profiles and the other Lotus Connections services can supplement your directory information with critical social network data about your employees to maximize your annual investment in human capital by exposing cross-team collaborations patterns such as related colleagues. This enables your organization to quickly find people by keywords, projects, expertise, location, and many other criteria. Even in the simplest of directory topologies, Profiles can provide a highly scalable single source of user profile data.

In Figure 3.2, you are presented with a flow diagram that illustrates the communication flow between each of the Lotus Connections services and the underlying Lotus Connections directory infrastructure. The complexities of a directory topology are isolated in the center diamond, shown in the diagram as WPI (which stands for Waltz-Profiles Integration).

Figure 3.2. Flow diagram depicting directory use for both authentication and authorization and directory lookups

In the world of dance, the waltz is famous for its smooth, gliding steps, which in their simplest form even novice dancers can pick up, but when advanced steps are used, significant training and experience are required. Lotus Connections named this layer Waltz for that very reason. With Profiles integration, Waltz can ensure seamless handling of user metadata for both entry-level and complex deployments. In its most basic rollout, no additional configuration is required beyond setting up standard WebSphere security settings for user authentication and authorization. Waltz will communicate with this same directory for user metadata by introspecting these settings and leveraging WebSphere Federated Repositories for the data. For more demanding environments, Waltz can leverage Lotus Connections Profiles and its directory extensions. This setting enables the collection of user metadata from various alternate sources. Following is a sample configuration setting that instructs Waltz to communicate with Profiles for user metadata:

<sloc:serviceReference serviceName="directory"

waltz_profiles_integration_href="http://example.com/profiles/dsx/"
    waltz_profiles_integration_enabled="true"
    ...
/>

By enabling Waltz to leverage Profiles as its user data repository, Lotus Connections can unify multiple underlying data sources to provide a highly scalable single point of access. This approach offloads the demands of a new breed of Web 2.0 social applications that are thirsty for user data that has previously been served by your traditional directory backbone. In addition to serving user data to Lotus Connections services, the Profiles REST APIs can provide other applications with this same information. This support is provided via a rich set of feeds over HTTP using an Atom 1.0–compliant XML response format. More details on these APIs are described later in this book, and formal documentation can be found on the IBM InfoCenter website for Lotus Connections.

In deployments containing Profiles and the Profiles directory service extensions, Tivoli Directory Integrator will manage the synchronization of user information between the Profiles database and the underlying directory sources. This process can be either one-way (from the directory to the Profiles database) or two-way. Two-way synchronization allows changes on administrative designated attributes to get pushed back into the originating repository. This process is managed by a TDI solution containing assembly lines. An assembly line is nothing more than piecing together smaller executable units to make up a more meaningful work unit that is performed repeatedly on individual items provided by one or more source connectors. In this case, the source connector is the directory and the work items are user records from this directory. The assembly line operates on these individual records, ultimately delivering them to Profiles, the destination output connector. The operations performed on these records are determined by the custom flow controls as stated in your assembly line descriptor (that is, loops, branches, and switches) and via embedded script elements to manipulate the data attributes. This process can collect data from additional sources, join attributes, and compute new ones, with the net output being a work item that conforms to the Profiles required data schema.

The complexity of an assembly line will vary depending on your deployment needs. Out of the box, Profiles will provide assembly lines for both one- and two-way synchronization with one or more LDAP repositories. There are also assembly lines to allow for supplemental information provided from CSV files. The default solution containing each of these assembly lines can be run as a one-off execution, providing the initial population via a population wizard. This wizard provides a simple means to specify connection information to both the database and the LDAP repository, as well as specify custom attribute mappings and JavaScript functions. This process can be executed via the wizard user interface or via manual scripts. For continued synchronization of changes in your directory with the Profiles database, you can again leverage the out-of-the-box assemblies to execute as a scheduled task, either through the TDI interface or via the operating system. Two-way synchronization is performed by keeping track of what has changed in both your source and your destination repository since the last synchronization and replaying these changes. The Profiles’ data repository provides this capability using a look-aside table that is later flushed back to the source directory. Profiles can provide a uniform approach for synchronizing almost any type of source repository. Each scheduled synchronization will create a custom hash of available source records, identify them by a unique key, and group them into page sizes that it is able to process in memory. Each grouping is then processed using a comparison algorithm for relevant attributes, and each record that has changed since the last synchronization is updated. This approach enables synchronization with almost any source repository and greatly simplifies the complexities introduced by the varying degrees of support that each vendor’s source repository change logs provide. For more complex deployments that integrate with non LDAP directories, custom assembly lines are necessary. In these cases, it is possible to extend an existing assembly line or build your own custom assembly from scratch. Since TDI assembly lines are fully customizable with regard to workflow, connectors, and data manipulation via custom hooks, the possibilities are endless when it comes to pulling data from your non-LDAP sources. TDI eases such integration by providing prebuilt connectors for many popular enterprise systems. For those systems without existing prebuilt connectors, plumbing for low-level transport protocols is also made available through various programming languages.

In setting up Lotus Connections with your directory infrastructure, one important aspect to consider is your choice in an appropriate globally unique user identifying key from your directory. This key is used by the Lotus Connection services to uniquely identify each user in the system. This key is consumed by the running TDI assembly line and fed into Profiles, which later serves up this same key through Waltz and into each of the other Connections service databases. After the key is stored in the Lotus Connections repository, it ensures that user data is always associated with a single user regardless of changes over time to other identifying attributes, such as an email address or a login name. This identifier must meet three key characteristics to fill this role:

Each LDAP repository provides a single LDAP attribute that is guaranteed to meet the first two criteria, and, if the directory entries are properly maintained, it can also meet the third criteria. The first release of Lotus Connections utilized this default attribute provided by each directory for maintaining the association of user data to an individual. This approach safely guaranteed the desired characteristics in most deployments, but in some cases the nonmutable characteristic of this ID was not maintained in practice. In organizations that use a custom LDAP attribute as a globally unique identifier, they might choose to freely insert and remove directory records for an individual user without worrying about the maintenance of the directory’s default ID. These actions will break the nonmutable characteristic that is required of a GUID and is the reason they maintain an alternate custom attribute. With this in mind, Lotus Connections in release 2.0 added additional support to allow the selection of custom LDAP attributes as the globally unique identifier for users. If your organization does not maintain an alternate identifier, you should continue to use the default GUID for your LDAP. Table 3.2 lists the default identifiers provided by each supported LDAP repository.

When you’re choosing to use a default identifier as listed in Table 3.2, it is important to ensure that each user’s directory records will be properly maintained so that new IDs are not inadvertently generated for an existing user. Changes to this identifier will result in a break in the linkage between a user’s identity and his or her associated data throughout Lotus Connections. If this happens, it can get resolved via administrative commands, but in general it is important that each deployment chooses a GUID that doesn’t violate this constraint often. When it is violated, end users will experience a time-window during which they cannot access the Lotus Connections services until the GUID is resynchronized using the administrative facilities. If your organizational policies for LDAP administration result in behaviors that don’t respect the default GUID in your LDAP (such as removing and reinserting directory objects for an individual), we recommend the selection of an alternate GUID that maps to what your organization is able to maintain as a truly permanent and globally unique identifier.

Selecting a unique identifier first requires a change to your Federated Repositories configuration. Using a text editor and the Federated Repositories wimconfig.xml found in the deployments cell-scoped configuration directory under the folders /wim/config, you can look for the line containing the <config:repositories> element and add to the <config:attributeConfiguration> block your custom GUID. The snippet would look as follows:

<config:externalIdAttributes name="<custom_attribute>"
      syntax="<attribute_syntax>"/>

The syntax attribute on the externalIdAttributes tag is necessary only if the chosen attribute name contains values other than a string, such as an octetString. If this value is changed, it is important to keep in mind that this will also require updates to the Profiles service field mappings for TDI synchronization, and when setting up and configuring Waltz in your LotusConnections-Config.xml. If existing data resides in your Lotus Connections servers, you will also need to invoke the administrative commands to resync all existing user GUIDs with the updating settings.

In choosing any identifier (custom or default), the populating functions for the Profiles TDI scripts need to match the appropriate LDAP syntax. Table 3.3 provides the syntax used for each directory’s default id and the corresponding TDI script function for processing that format.

Waltz does not require any specific configuration settings when a default LDAP attribute is used for the system GUID since it can derive this value from the chosen directory configuration, but it will require knowledge of any custom user and group attributes. When using a custom user or group attribute, you must update the LotusConnections-Config.xml directory service references, found in the LotusConnections-Config.xml with the chosen attribute names:

<sloc:serviceReference serviceName="directory"
   ......
   custom_user_id_attribute="customUserID"
   custom_group_id_attribute="customGroupID" />

With this flexibility to choose a default or custom attribute as a unique GUID, Lotus Connections can seamlessly identify individual users regardless of changes to other secondary user identifying attributes. Starting in 2.0.1, the Lotus Connections API can also support mashups with other applications that identify users by this GUID.

Another important aspect to the data tier of a Lotus Connections deployment is the underlying persistence model. Lotus Connections requires the use of a relational database as its primary storage medium but also relies on file system storage where appropriate. The deployment topology of the Lotus Connections relational database tables can be as small as a single physical machine and database instance but is expandable to as many as six physical database servers and corresponding instances, along with matching passive servers for HA redundancy. The Lotus Connections database tables are horizontally divided so that each service has its own set of tables associated with it via a unique schema. Since each of the six services has its own schema and database tables, you can utilize planned and actual utilization rates at the service level to split out workload across new machines where necessary. You can also selectively scale individual machines with additional hardware resources based on the usage characteristics for each service.

The recommended physical split of database tables across machines will vary depending on many characteristics, including the type of hardware available and the amount of expected user traffic. A machine with only two cores should not host all six services’ database tables in a high-throughput environment, but a machine with additional cores might adequately handle such a configuration, assuming that best practices for RAID disk IO and memory configurations are followed. High-level sizing guidelines are made available by IBM to help pick an initial deployment topology to meet your needs, but ultimately many factors prevent this choice from being an exact science. For example, a well-tuned disk infrastructure with an allocation of separate RAID disk clusters for the tablespaces, indexes, and logs will experience higher throughput than a deployment constrained by shared read/write heads.

Another service-level configuration is the JNDI resource pools. Since each Lotus Connections service can maintain isolated non-XA transactions, the installer will create six JNDI resource pools. This approach allows for improved performance by the reuse of shared connections at the service level and independent tuning of pool sizes for each of the services while keeping the possibility of separating database tables across multiple physical database instances. Tuning each connection pool is an important aspect to ensure optimal response times because an improperly tuned environment might mean unnecessary time spent waiting for a free connection. Setting the pool sizes large enough will eliminate this risk, but it is also important to respect the overall system resources on the application server by not setting this value higher than necessary for the expected peak workloads. Increasing the default value of 10 connections to 50 is a safe assumption for any size of deployment and should not have a negative impact on overall system resources. Tuning to higher values, such as between 75 and 150 connections, might be needed to support maximum load for some of the components in a large deployment, but as you tune these values higher, keep an eye on overall memory consumption to ensure that your system is able to provide the necessary memory allocations without excessive paging. Increasing the default prepared statement cache size from 10 to a value closer to 100 is also recommended. If an individual WebSphere node cannot handle the required increased allocations, additional server nodes can be added to a cluster for supporting this user traffic. More details on adding WebSphere nodes are covered in the Tier 2 section of this chapter.

It is always important to keep in mind that the settings discussed in this chapter are only a few of the many variables that will require adjusting to provide optimal performance. By the nature of a relational database, administration and maintenance are very important for the continued operation of your applications. Utilizing a database platform that matches the skill set of your database administrators will greatly ease this process. For this reason, we fully support three database vendor platforms:

Each platform, although functionally equivalent to the others, will require different procedures with regard to index maintenance, backup and restore, and data integrity. The Lotus Connections installation package provides a set of utilities to automate the creation of database tables, users, indexes, and maintenance schedules for all three platforms based on recommended configuration settings determined by the system verification and performance analysis teams at IBM. The installer also provides utilities to enable migration of existing data sets across database vendors, allowing the migration of pilot evaluations into full-fledged production deployments without loss of user data.

File System storage is used by all the services in Lotus Connections for purposes for which storage in a relational database is not appropriate. In many cases, this is secondary storage, such as an optimized search index on data already persistent in the relational database. Such an index can get rebuilt at any point so no backup policy is necessary. In some cases, the file system is used as primary storage for large files. The use of the file system for large files provides deployments with the flexibility to leverage existing low-cost, high-bandwidth file storage architectures and was determined to be the best choice to maximize overall system performance and minimize resource contention in these specific scenarios.

A pilot deployment is ideal for an evaluation of the Lotus Connections features. This is a self-contained single server environment that requires no preexisting software beyond the operating system. Installed for the pilot in addition to Lotus Connections 2.0 is all the necessary prerequisite software. This includes IBM WebSphere Application Server 6.1.0.13 and IBM DB2 Express Edition. No external LDAP integration is provided in a pilot configuration but you can import a set of registered users. The pilot installation provides a quick and easy way to get a deployment off the ground, allowing an evaluation of the Lotus Connections feature set. For use after a pilot evaluation is complete, the migration wizard that is shipped with the Lotus Connections installation package eases the conversion of a pilot installation to a product environment. A migration is possible only if the users defined in the pilot also exist in the production directory with a shared secondary key, such as the user’s email address. Starting in release 2.0.1, we will also utilize the login name attribute as an additional shared secondary key. In a pilot, this key maps to the uid, but in your production directory, it can map to any number of possible attributes. Assuming that your pilot user base clearly has a 1-to-1 mapping to actual users in your production LDAP, moving to a production installation should succeed with little issue. The migration procedures can be broken down into three important high-level steps that are all performed when the production deployment is being set up:

A more detailed breakdown of the steps required to install a production environment and migrate pilot data to the production deployment is available in the IBM InfoCenter site for Lotus Connections.

A simple deployment aligns with the intents of a pilot deployment with regard to scale but now lets you utilize any of the production operating systems and will integrate with the directory and database platform of your choosing. This environment is well suited for small organizations that don’t need the redundancy of highly available deployments or can be used as a staging environment for a larger deployment. When installing a nonpilot environment, Lotus Connections requires an existing WebSphere cell and profile installed with proper security and directory settings preconfigured but will automate the generation of server instances and associated resources.

A simple deployment topology usually breaks out Lotus Connections into a two-server configuration. The first server is hosting your chosen database platform (and optimally TDI for Profiles), and the second server is hosting your Application and HTTP servers. Figure 3.3 depicts the communication between these two servers and your supporting directory infrastructure.

Figure 3.3. A physical topology depicting a two-server configuration

As shown in the figure, TDI resides on server 1 along with your relational database and uses its assembly lines and connectors to communicate with both an LDAP directory and a secondary HR repository. The WebSphere Application server and HTTP server are both installed on the second server; this machine will communicate directly with the LDAP for authentication and authorization and the relational database for user data. The top rectangle depicts your existing directory for authentication and user data. In planning for a larger-scale deployment in the future, it might be logical to span the Lotus Connections services across multiple WebSphere server instances even though they will still reside on a single physical machine.

Adding high availability or redundancy to a deployment topology means providing a means for one server instance to go down without losing the service provided by that instance. Adding HA support to the application server tier of Lotus Connections is accomplished by deploying each of the functional units to a multinode cluster across multiple physical boxes. These boxes can reside in a separate building or on independent power grids for greater availability. The additional HA nodes can be set up either as active servers for handling greater throughput or as standby servers that are partially utilized for other purposes. Virtualization is another technique to reduce the cost of ownership in an HA deployment. Although using an application server cluster will provide the necessary availability at this tier, it is important to keep in mind that an overall deployment is still most vulnerable at its weakest point, so a true HA deployment will also require redundancy at each of the other tiers, including the file system, relational database, directory, HTTP servers, and any SSO or caching proxies fronting the deployment. Each product vendor will provide the necessary solutions to ensure high availability at each level. How these products are rolled out for HA will vary by vendor. For example, at the persistence tier, DB2, Oracle, and SQL Server provide similar but different approaches for HA support. These are the three solutions:

You can find more details on each of these solutions through your chosen vendor’s documentation and support sites. The capability of Lotus Connections to use a wide arrange of vendors at each tier allows for reuse of existing skills and infrastructure within your organization.

Large-scale deployments are designed to maximize throughput, usually provide high availability, and are effective for serving a global organization. Earlier in this chapter, we discussed the database tier and how you can start with a single database server and spread to six active database servers. In a large-scale deployment, you likely will spread the database instances across multiple physical machines, with the number of machines depending on the type of hardware utilized. High-end hardware with large numbers of core and memory will require less scale-out. At the application server level, it is usually expected that each service will have its own cluster with at least two server instances on multiple physical machines for HA. With the size of this deployment, it is strongly recommended that WebSphere ND is utilized and all administration is done with a single deployment manager. With large-scale deployments often being global, they typically should include the use of regional proxy caches to minimize network latency and maximize server throughput across the weakest points in your network bandwidth. Details on the benefits of a reverse proxy cache and a complete depiction of a large-scale deployment for Lotus Connections are discussed in the Tier 1 section that follows. After a discussion of this final tier, Figure 3.4 provides a picture detailing a large-scale deployment.

Figure 3.4. A physical topology depicting a large-scale server configuration

A proxy can be used to front a deployment for many reasons, including security, load balancing, and caching. Usually a proxy server is hosted in a web-accessible zone while the underlying tier 2 and tier 3 infrastructure will get deployed in protected zones. This is to prevent unwanted access to user data by constraining direct interaction with the deployment via the secured proxy. Only traffic between the proxy and the HTTP server will be allowed to tunnel between these security zones. Proxies are also commonly used in large-scale deployments to offload back-end services from hosting static content and publicly cacheable dynamic content. With proper deployment topologies a proxy can also reduce network latency for the delivery of cached content to a geographically dispersed client. Significant portions of content served by Lotus Connections are publicly cacheable, and the deployment of a proxy can provide a low-cost means to increase the overall scalability of your server environment.

Performance tests of the Dogear, Blogs, and Profiles services have shown significant gains on overall scalability and response time by the introduction of a reverse proxy cache. More moderate gains were observed in the other services but they were still significant enough to warrant its use. In the performance lab, Blogs showed as much as four times improvement in overall TPS and Dogear exhibited three times improvement in TPS. These gains were achieved by leveraging the proxy cache to offload dynamic content generation where data has not changed. Additional benefits are also possible by minimizing HTTP connections for static content and moving such requests closer to the edge of your infrastructure and ultimately the client.

In a standard deployment topology in which all six services share the same host name, such as connections.example.com, or the same parent domain name, such as activities.example.com and dogear.example.com, no external SSO solution is required to allow for WebSphere to provide a single authentication token that is utilized across all of Lotus Connections. Each request made by a browser will send along a set of browser cookies. In these browser cookies will be a cookie called “LTPAToken.” This is basically a ticket for the end user that was generated at login and is valid for a time period configured by the deployment. When multiple servers are set up to share this ticket with all other servers in the same parent domain, the ticket is passed by the browser on each such request. Each server in the environment can then validate that the ticket was generated by a trusted authority and accept it as a valid authorization token. When multiple servers are in the same cell, this will work out of the box. With minimal configuration, servers in multiple cells can also participate in this trust association without requiring an external solution.

The single sign-on solution that is provided out of the box not only allows all Lotus Connections servers to trust the tickets generated by other servers in the same deployment but also can interoperate with other non–Lotus Connections environments that support LTPA. This includes WebSphere Portal, Lotus Quickr™, and even Lotus Domino servers. As a deployment complexity expands beyond a single parent domain or a single authentication technology for cross-vendor compatibility, Lotus Connections provides support for integration with an external single sign-on solution. The supported platforms include Tivoli Access Manager and SiteMinder. These two solutions can provide a complete SSO strategy across your organization and the inclusion of additional auditing capabilities, policy-based authorization, and many other advanced security solutions.

We have now seen the many layers of a three-tiered deployment topology and the flexibility Lotus Connections can bring to each of these tiers to allow for vendor freedom, high availability, improved scalability, hardware virtualization, and integration into your existing back-end services. Figure 3.4 pulls this all together to demonstrate a complete large-scale deployment that leverages each of these choices to their fullest extent.

The Lotus Connections user experience can surface in many clients. Out of the box, it includes a native browser experience and a set of REST APIs that enable integration into a large set of client platforms. Available on the Lotus Connections Business Solution Catalog are many of these platform on-ramps, including integration with Lotus Sametime, Lotus Notes, WebSphere Portal, Microsoft Office, and Microsoft Windows. Each of these client renderings build on many of the same public REST APIs available for custom integration into any third-party platform. Browser support for the web experience includes Microsoft Internet Explorer 6.0 and 7.0 and Mozilla Firefox 2.0 on Windows, Linux, and Macintosh. As part of Lotus Connections 2.0, the browser experience is translated into 25 languages, including many bidirectional languages. Lotus Connections 2.0 has also added support for accessibility, including screen readers and high-visibility mode.

Most page views in Lotus Connections contain a feed icon that represent a link to an Atom feed document of the visible page’s resources. This feed document semantically represents the same data shown in the web experience but delivered via an XML document formatted based on the Atom 1.0 specification. In addition to having a view into a service’s data using the standard Atom Syndication Format, each Lotus Connections service also provides a discoverable service document as an entry point into the Atom Publishing Protocol. This protocol allows two-way resource manipulations, over HTTP, again using Atom as the data format. HTTP as a communication protocol allows a deployment to seamlessly leverage existing infrastructure, including proxies, firewalls, and other intermediary layers that work on the HTTP stack. Common tasks such as auditing, workload balancing, and secure tunneling are all supported by one’s existing infrastructure. Atom publishing uses the HTTP verb GET for retrieving a resource that is associated with a given URL, POST for creating a resource into a collection associated with a URL, PUT for updating a resource associated with a URL, and DELETE for removing a resource associated with a URL. Since each interaction is independent with no server state and all context information maintained in the HTTP request, one can easily explore both programmatically and visually to discover additional resources. For example, Dogear follows a basic scheme for filtering a collection of bookmarks. Manipulation of the output format part of the URL can result in a list of bookmarks in the webui (/html), via the public Atom API (/atom), or in alternate JavaScript and json formats (/snippet, /lisnippet, and /json). The use of basic query parameters on each of these URLs will constrain the list of bookmarks for the specified format to a filtered list.

With HTTP clients available in almost any programming language, the Lotus Connections API is also platform agnostic. Having been built on the standards-based Atom XML format and protocols, open-source client libraries exist for higher-level resource manipulation using native object models. One sample client is the Apache Abdera project, which provides a higher-level abstraction for communication in Java with any service that conforms to the Atom Publishing or Syndication specifications. Not only can existing programming libraries consume the Lotus Connections feeds, but some end-user applications such as feed readers, blog authoring tools, and other Atom-compliant applications can interoperate with Lotus Connections out of the box.

Each of the Lotus Connections services is built on a set of common components that enable the business tier to provide a consistent user and administrative experience across the functional units that make up the Lotus Connections product suite. Each of these common components provides a single access point for customization, administration, and feature injection that uniformly surfaces throughout the Lotus Connection portfolio.

Person Card and Awareness (hCards)

The concept of a person as an entity is an important aspect of a social networking offering such as Lotus Connections. The success of a deployment is primarily driven by the creation of user-generated content and the ability of end users to dynamically forge new relationships as a means to discover information. A person’s name is a natural pivot point for this discovery to initiate, and Lotus Connections provides this capability through contextual business cards that surface on every name. This enables users to explore, identify experts, and collaborate across organizational boundaries. This integration technique is built using open standards and a pluggable framework that enables the inclusion of contextual business cards throughout Lotus Connections and even on pages outside of the product. At the heart of all this functionality is the concept of an hCard. An hCard is an industry-standard approach for semantically representing a person in HTML markup. This means that the HTML syntax used for displaying a name on a page is appended with other nonvisual HTML attributes that are programmatically detectable by a JavaScript application. A normal person link without this markup would look like a simple HTML anchor tag:

updated by <a class="lotusPerson"
href="#[email protected]">Frank Adams</a>

Usually this anchor tag will contain a class attribute to allow for custom link styling using CSS, a href attribute pointing to an action when the user clicks the link, and a display name as the link’s body. With additional semantic hCard markup added to the standard anchor tag, the page will look no different to an end user but can now allow for services like Lotus Connections to enhance this link with rich dynamic content via simply embedding a JavaScript include on the top of the page. The updated hCard markup looks like this:

updated by <span class="vcard">
   <a class="fn person lotusPerson"
href="#[email protected]">Frank Adams</a>
   <span class="email" style="display:
none;">[email protected]</span>
   <span class="x-lconn-userid" style="display: none;">e1234a56-
7b8c-9012-34d5-ef67890g12h3</span>
</span>

When looking closely at the preceding markup, you will see that the additional tags have a style attribute that tells the browser that they are nonvisible parts of the page but are still programmatically accessible via an embedded JavaScript framework. By installing the Lotus Connections Profiles Service in addition to the other Lotus Connections services, this markup is used to introduce rich business card enhancements to all names on every page. Figure 3.6 shows a sample business card when a user interacts with a dynamic name.

Figure 3.6. A person link enhanced by a live business card in Lotus Connections

Figure 3.6 demonstrates how a user not only can have an in-line view of the person’s contact information and picture, but also is able to cross-navigate on a person’s bookmarks, blogs, communities, activities, and profile. Additional features include Sametime awareness, sending of an email, and the ability to invite someone as a colleague or to download the person’s vCard into an address book.

Rebranding Lotus Connections

The Lotus Connections navigational headers, footers, and overall theme are enabled for rebranding to provide a consistent and integrated user experience with existing sites. Lotus Connections also has a common set of style definitions across the services that provide an integrated look and feel for end users and enable simple modifications to integrate the user experience with alternate branding guidelines. To begin customizing, it is easiest to work from a starting point and progressively replace images and styles. To start, you need to copy the header.html file found within any of the deployed services into a web-accessible location. This is usually an HTTP server such as IHS. Next you can override Lotus Connections to use the new header file found on the HTTP server by running an admin command and providing it the new web-accessible URL for the header file:

LCConfigService.updateConfig("style.header.url",
"http://example.com/templates/header.html")

This header file is now the default header for all Lotus Connection services and contains fully customizable HTML markup plus a number of supported macros for variable replacement. For example, you will notice that image files start with a macro path of {default images}, which when updated to {images} will instead download image files from a custom-defined web-accessible URL. A similar admin command is used to define the location of the {images} macro to allow for custom images in the header:

LCConfigService.updateConfig("style.images.url",
"http://example.com/images")

The links shown horizontally across the Lotus Connections header are also customizable. All of the six enabled services are dynamically inserted as styled <li> entries at the spot denoted by the macro {{application links: li }}. Placing additional <li> tags before or after this macro will allow for custom links:

<ul class="lotusInlinelist lotusLinks">
    {{application links: li }}
    <li><a href=http://example.com/learning>Learning</a></li>
</ul>

The preceding example would add a Learning link to the navigation bar. Figure 3.7 shows what this would look like in the header.

Figure 3.7. A customized Lotus Connections header including an additional Learning link

Customizing the footer is equally simple. Again using the LCConfigService, update the configuration setting to point to a new web-accessible location where the footer HTML file is copied:

LCConfigService.updateConfig("style.header.url",
"http://example.com/templates/footer.html")

Inside this file is a table with four columns, each with rows of links to related information. These links also get generated via the same macros substitution strategy. You can remove, add, or update any of these links and/or columns to ensure that the footer contains information relevant to your deployment. For example, if a deployment has custom tools, a link in the footer will provide end users a means to install these tools.

A significant part of rebranding Lotus Connections is to replace the overall look and feel of the main content area to match your organizational guidelines. This part of customization will take the most time to get an overall site experience that blends cleanly with that of another site. To make this easier, a sample alternate set of style sheets and images, along with a theme editing guide, is provided with Lotus Connections as a resource. This package includes sample CSS styles and images to give Lotus Connections a red look and feel. The theme editing guides provides a complete list of class names, descriptions, and the default values for both the blue and red themes.

Maintaining a solid look and feel that works across many languages, including bidirectional languages, requires care. To best take advantage of the effort made by Lotus Connections and to ensure that the site remains functional in all of these languages; it is recommended that any branding is done by starting with the out-of-box styles and images and making necessary incremental changes from this point forward. When you are updating or replacing images, it is best to stick with consistent dimensions and not alter the overall layout of the page. To maintain consistent font and color throughout the site requires updating multiple styles at a time, and the best approach is to use a search-and-replace strategy that makes the same change to all instances of a single font or color. Also, when picking updated fonts, be sure to keep in mind that not all fonts are universal across browsers and platforms.

Organizations with existing investments in WebSphere Portal can extend this investment with features from Lotus Connections using one of three approaches. The first and simplest approach is to utilize a Lotus Connections portlet made available on the IBM Lotus Connections Business Solutions Catalog. This portlet can provide in-context information from each of the Lotus Connections services on any portal page. The portlet was built using the Lotus Connections REST APIs and provides access into each of the Lotus Connections services. Since these APIs are available via HTTP, a second integration approach is to build a custom portlet using these same APIs. This provides the most flexibility when integrating specific features into a custom application on a WebSphere Portal page. Finally, for those looking for seamless navigation across both deployments, the IBM Web Application Integrator for WebSphere Portal is your answer. This solution allows existing web applications, including Lotus Connections, to seamlessly integrate into the WebSphere Portal navigational structure. This solution provides a complete visual integration without requiring the development of any portlets. It works by injecting a live rendering of the portal navigational banner into Lotus Connections. Along with the creation of Lotus Connections page links in the WebSphere Portal navigation header, you are able to navigate between portal and Connections pages seamlessly. Figure 3.8 provides a screenshot of this integration in which a portal navigation header is shown as part of a Lotus Connections page.

Figure 3.8. Lotus Connections embedded with a WebSphere Portal Navigation header using the IBM Web Application Integrator for WebSphere portal

The Lotus Connections Communities feature provides groups of users with common interests to create ad hoc spaces for collaboration on shared interests. Out of the box, these spaces include topical feed aggregation, discussion forums, and community bookmarks as means to share content. A community membership can also be utilized for email communications and Sametime broadcast lists. The features available to a community are extensible through the installation of one or multiple available plug-ins. Plug-ins are available to integrate Socialtext or Confluence wiki spaces as part of a community. Both are made available through the Lotus Connections Business Solutions Catalog. When they’re installed, end users creating communities can choose to include a wiki space with either of these technologies. This space will maintain a synchronized membership list, a navigational link to the wiki in the side panel, and a feed of recent wiki changes in the main Community view.

In release 2.0.1, Lotus Connections has expanded its integration points with Lotus Quickr. The first integration point is with Lotus Connections Activities and Quickr Document Libraries. Activities provide a focused space for ad hoc collaboration and development of best practices to manage repeated tasks more effectively. In these collaboration patterns, files are used as a piece of a greater collaboration around a topic. As an activity is brought to completion, the outcome is often a document. Integration with Lotus Quickr allows for the publishing of this file to a team library, making the file available to a broader audience and for long-term storage in an enterprise content management platform. This integration allows for quick publishing of files into ones most frequented Quickr libraries, removing the file from the Activity and replacing it with a link back to the published file now residing in Quickr. Lotus Connections Communities also provides integration with Lotus Quickr, allowing a Quickr wiki to surface as part of a community in the same manner as Socialtext and Confluence. This integration provides the seamless generation of a Quickr wiki when creating a community space along with membership synchronization and an integrated feed of recent changes in the Community page.

A pilot deployment can successfully get off the ground with a single Intel^® 64 or IA-32 based server, but in planning for a production deployment, it is recommended to have a minimum of two servers each containing two cores and at least 4GB of memory (preferably per core). In this minimum configuration, we would have the application server on one machine and the database server on a second. This is the simple deployment topology described earlier in this chapter. As a simple deployment expands to support high availability or adds clusters for greater scale, the amount of physical hardware required will increase.

Space requirements will greatly vary by deployment depending on the data characteristics of the user base and the chosen configuration settings. For example, with Activities you can determine the maximum size of a file upload, which will greatly impact your space requirements. Blogs will also allow caps on the upload space per blog. As a rule of thumb, plan on having at least 80GB of free disk space per machine after installing the software. Space requirements by feature fall into two categories: space required per node in the cluster, and shared space made available to all nodes in a cluster via a network file share.