Deploying IBM Lotus Connections: Planning and architecture considerations

This article, part 1 in a seven-part series about deploying IBM Lotus Connections, focuses on planning and architecture considerations to ensure that your deployment is built properly. Learn from an expert on recommended planning and architecture practices.

Stephen Hardison, I/T Architect, IBM Software Services for Lotus

Stephen Hardison is a Certified Consulting I/T Specialist with IBM Software Services for Lotus. Stephen has been working on early adopter customer deployments of Lotus Connectioons since January 2007. Stephen joined IBM Software Services in 1999. Prior to that, he worked as an I/T professional for several public and private sector companies. You can reach Stephen at shardison@us.ibm.com.



11 September 2007 (First published 31 July 2007)

Also available in Chinese Russian Japanese

This article covers some of the most common steps to prepare for an IBM Lotus Connections deployment. At a high level, it outlines the architectural concepts and alternatives available so that you can plan a successful Lotus Connections deployment appropriate to your organization. The content of this article is intended for both I/T architects and I/T specialists.

Introduction

Lotus Connections is a new product from IBM that introduces a set of J2EE-based social collaboration services tailored to support the needs of the enterprise. It consists of five lightweight, independent features designed to allow for incremental implementation and adoption by the business, while at the same time providing a simple and extensible integration framework that allows the individual features to interact when they are deployed together in an organization.

The five functional features of Lotus Connections include the following:

  • Profiles. Provide quick access to information about people in the organization, including the ability to search across the organization using keywords that help identify expertise, current projects, and responsibilities.
  • Communities. Provide a facility for creating communities of common interest, responsibility, or areas of expertise that people across the organization can join.
  • Blogs. Provide a weblog service available to individuals or groups to share points of view and to get feedback from others.
  • Dogear. Provides a facility to save, organize, and share bookmarks to valued online resources and a means to discover bookmarks that have been shared by others.
  • Activities. Provide a means for individuals and groups to organize work, to plan and save process steps for reuse, and to collaborate easily on everyday deliverables.

Because Lotus Connections is a new product, few people know which steps to take to plan a deployment. The intention of this article is to outline the architectural concepts and alternatives available so that you can plan a successful Lotus Connections deployment appropriate to your organization.


Architecture of Lotus Connections features

Let's look at both the logical architecture and the operation architecture of features.

Logical architecture of features

Figure 1 illustrates the logical architecture of Lotus Connections features. It consists of the following:

  • Clients used to access the features
  • HTTP transport and proxy caches
  • J2EE container that hosts and controls access to all Lotus Connections features and data
  • Backend systems for use by those features for authentication, data storage, and integration with external messaging systems
Figure 1. Lotus Connections logical architecture
Lotus Connections logical architecture

Lotus Connections provides features to various types of clients over standard Web ports through an API based on the REST protocol and the Atom standard. While several means of accessing the features are provided natively, such as browser access and application plug-ins for IBM Lotus Sametime V7.5 or IBM Lotus Notes V8, the API is designed to allow customers to create, update, query, and manage Lotus Connections information from their own custom applications.

Because the Lotus Connections REST API is similar in structure to HTTP (in fact, HTTP is a REST-based protocol), and because it uses the same transport layer as standard Web servers, calls to the features are compatible with standard Web servers and proxy servers.

The API allows information to be entered and managed using POST, PUT, and DELETE methods with the service data encapsulated in an HTML form or an XML Atom document. Information can be retrieved using the GET method and rendered either as an HTML or an XML Atom document, depending upon the needs of the requesting client.

For example, the following URLs illustrate two different variants of a Dogear REST call to retrieve a user's bookmarks. The first retrieves the information in HTML format; the second retrieves it as an Atom feed and adds an additional filter to select only a subset of the user's bookmarks:

http://dogear.ibm.com/html?user=Jane_Roe@us.ibm.com
http://dogear.ibm.com/atom?tag=java&user=Jane_Roe@us.ibm.com

In addition to the five functional features that are accessed by clients, Lotus Connections provides four additional common utility modules:

  • JMX administration. Used to configure and manage the Lotus Connections environment. Most administration functions are managed using the WebSphere wsadmin command, but others are exposed through a Web interface.
  • Navigation header. Allows all installed features to be aware of one another and to provide consistent Web navigation to users. Extensible to include links to other external services.
  • Person card. Displays consistent business card information when a person's basic Profile information is requested from within each of the features. Requires the Profiles feature.
  • User directory. Interfaces to the directory used by Lotus Connections for authentication, authorization, and query features.

Lotus Connections also relies on several key backend services:

  • LDAP. Provides authentication and authorization services to Lotus Connections and serves as the primary data source for person information used by the Profiles feature.
  • Relational database. Stores databases and tables needed by the Lotus Connections features. Each functional feature has its own data store.
  • Data integration (IBM Tivoli Directory Integrator). Extracts person information from enterprise data sources, such as the LDAP directory, and pushes that information to the Profiles feature's database tables. Can also be configured to push updates made to Profiles entries back to the original data source. Used only with the Profiles feature.
  • File system. Stores service indexes, as well as service-specific data, such as file attachments uploaded to blogs or activities. Activities may alternately use a Domino database for file attachments and large objects.
  • Outbound SMTP. Lotus Connections leverages an organization's existing messaging infrastructure to transmit notification messages. This can be any mail system that can accept and forward an SMTP message packet.

Operational architecture

Figure 2 illustrates the primary deployment components that make up Lotus Connections. These are the minimum required components. In some instances, components may be co-located on the same physical server. For example, while it is normally a deployment best practice to install an HTTP server on a separate physical unit from the IBM WebSphere Application Server, it may be appropriate to install them on the same physical unit in some low-usage scenarios, such as a development or test server, or for a small proof-of-concept or pilot deployment.

Figure 2. Lotus Connections operational components
Lotus Connections operational components

Lotus Connections requires WebSphere Application Server V6.1 running on Microsoft Windows or Linux as its host platform. A single functional feature can be installed, or multiple features can be deployed into separate application servers on the same physical instance. In additional, you can deploy features across several physical servers that are part of a network deployment cluster if a company requires a highly available environment or if Lotus Connections must scale to support deployment to a large user population.

With Lotus Connections, two directory servers are supported: IBM Tivoli Directory Server V6.1 and Microsoft Active Directory 2003. Other LDAP directories, such as IBM Lotus Domino and Sun Java System Directory Server, will be supported in upcoming maintenance releases.

Lotus Connections databases can be hosted on either IBM DB2 V9.1 or Oracle 10g. On DB2, each service's data is stored in a separate database. On Oracle 10g, Profiles and Activities data are stored in separate database instances, while Blogs, Communities, and Dogear data are stored in separate tables that share a single database instance. With most deployments, the Tivoli Directory Integrator V6.1 application that is used to populate the Profiles database is co-located with the database server.

As mentioned previously, certain data is stored outside of databases in the file system that is accessible by the Lotus Connections features. These file system components, such as indexes and file attachments, must be stored on drives attached to WebSphere Application Server. If you are deploying in a clustered WebSphere Application Server environment, each cluster instance must have access to a file share on common file servers or enterprise network storage devices.

The Activities feature allows for one additional file storage option. Instead of writing attachments and content to the file system, Activities can be configured to use a Domino NSF file hosted on a Lotus Domino server. This option is available regardless of whether Lotus Connections is installed in a stand-alone environment or in a clustered environment.


Deployment architectures and scalability options

Lotus Connections is designed to support a very flexible set of deployment scenarios. For example, an organization can deploy only one feature, such as an Activities feature to support an IBM Lotus Notes V8 rollout. On the other hand, if deploying across the enterprise, a company may choose to build a clustered environment and to allocate multiple nodes to the features that see the highest usage in the organization.

Test systems and POC environments

Figure 3 illustrates a minimal deployment topology for Lotus Connections that could be appropriate for a low-usage scenario, such as a test system used by a company's development organization, or for a limited proof-of-concept.

Figure 3. Sample test/proof-of-concept deployment topology
Sample test/proof-of-concept deployment topology

In this topology:

  • The HTTP server is co-located with WebSphere Application Server, so clients access the Lotus Connections server directly through both SSL secured and unsecured HTTP channels.
  • The SSL certificate used by the HTTP server may be a self-signed certificate rather than one registered with a certificate authority.
  • The Lotus Connections/WebSphere Application Server binds to the directory server through LDAP or LDAPS and to the database server over a thin JDBC connection.
  • Tivoli Directory Integrator is co-located with the database server, and it connects to the directory server through LDAP or LDAPS to populate the Profiles database with detailed user data.
  • In most cases, the Tivoli Directory Integrator connection may be a one-way feed with periodic updates as users are added to, updated in, or removed from the directory.

Because each Lotus Connections feature must have its own application server, these servers must be created prior to installation. When using a stand-alone WebSphere Application Server, the simplest approach is to leave the default server1 application server in place to host the WebSphere Application Server Console, and to create a new application server instance under the same application server profile to host the specific Lotus Connection feature being installed:

<WAS_ROOT>/AppServer/profiles/<profile>/wsadmin.sh (or wsadmin.bat)
$AdminTaskcreatApplicationServer <node> {-name <lcservice_server_name>}
$AdminConfig save

For example, to set up three servers to host Activities, Profiles, and Dogear on a Linux server, you issue the commands shown in listing 1.

Listing 1. Setting up hosting servers
/opt/WebSphere/AppServer/profiles/AppSrv01/wsadmin.sh
$AdminTaskcreatApplicationServer Node01 {-name ActivitiesServer}
$AdminTaskcreatApplicationServer Node01 {-name ProfilesServer}
$AdminTaskcreatApplicationServer Node01 {-name DogearServer}
$AdminConfig save

These commands create three servers, each with different sets of service ports, and save their settings to the WebSphere Application Server profile's configuration.

Small production systems

Figure 4 illustrates a deployment topology for Lotus Connections that could be appropriate for a small-scale production deployment of one or all services for use in an organization. Depending upon which services are deployed and how heavily the systems are used, such a system could support a relatively large population of registered users.

Figure 4. Sample small production deployment topology
Sample small production deployment topology

In this topology:

  • The HTTP server is located on its own server, which clients access through both SSL-secured and unsecured HTTP channels. The HTTP server binds to the Lotus Connections/WebSphere Application Server through HTTP or HTTPS if needed.
  • The HTTP server's URL(s) must have a valid SSL certificate registered with a certificate authority.
  • Tivoli Directory Integrator may be configured for a bi-directional feed so that data that includes certain Profile updates made by users, such as mobile phone numbers, can be synchronized with the source directory server.
  • If Tivoli Directory Integrator is configured to perform synchronizations on a near real-time basis, it may be necessary to move the Tivoli Directory Integrator server processes to a separate server to limit potential resource constraints on the database server.
  • An outbound SMTP channel is configured between the Lotus Connections WebSphere Application Server and one of the organization's mail servers to allow notifications from the Activities or Blogs features to be sent to interested parties.

NOTE: While this configuration supports a basic production deployment, it does not provide any redundancy for system failover nor does it provide the ability to scale up to support growing user loads. That requires a clustered solution as described in the next section.

Enterprise deployments and scalability options

Figure 5 illustrates a topology for Lotus Connections that may be appropriate for enterprise deployment. This configuration provides component redundancy to support operational high availability and failover, and it also provides a way of scaling Lotus Connections features to support large system loads and concurrent user populations.

Figure 5. Sample enterprise deployment topology
Sample enterprise deployment topology

In this topology:

  • Clients reach HTTP proxy servers or load balancers through both SSL-secured and unsecured HTTP channels, which in turn connect to an HTTP server cluster. The HTTP cluster provides binds to a Lotus Connections/WebSphere Application Server cluster through HTTP or HTTPS if needed.
  • The Lotus Connections server binds to the directory cluster through LDAP or LDAPS using DNS round-robin.
  • The Lotus Connections server binds to the database cluster through the DB2 High Availability and Disaster Recovery (HADR) feature or Oracle Real Application Clusters (RAC).
  • Tivoli Directory Integrator is located on its own server. It connects to the database cluster through JDBC and to the directory cluster through LDAP or LDAPS to populate the Profiles database with detailed user data. In addition, Tivoli Directory Integrator also connects to the company's HR data source for key organizational information that may not be stored in the corporate LDAP.
  • Tivoli Directory Integrator may be configured as a multi-directional feed so data that certain Profile updates made by users can be synchronized back to the source directory server and the HR system.

One of the most important performance gains for Lotus Connections occurs through caching. Seventy percent of network traffic to Lotus Connections is from plug-ins and RSS/Atom readers feed polling. Feeds can be served by caching proxies, which offload unnecessary traffic from the WebSphere Application Server.

For extremely large implementation and for maximum scalability, it may be worth considering placing each Lotus Connections feature in its own cluster. This approach allows for individual feature scaling versus scaling all five features.

For example, if an organization is implementing Activities and Communities, you may find that usage of Activities is significantly higher than that of Communities. It may be possible for Communities to be hosted on a two-server cluster to support redundancy, whereas Activities might require a four-server cluster to support the user load.


Planning your Lotus Connections deployment

Lotus Connections features are versatile, and they can be configured to support a variety of business requirements. A successful Lotus Connections deployment requires careful planning that maps the organization's business needs to the deployment architecture.

Desired services and users demographic

The first step to planning a Lotus Connections deployment is to determine which services need to be deployed. Although it is possible to deploy all the features at once, in most cases a more practical alternative is to get one feature fully deployed and operational before deploying the next. The order of deployment should be based on what is most important to the business. For example, in one organization, it may be important to implement an expertise location service, such as Profiles, to support global project staffing, while another organization may need to leverage the work-sharing capabilities of Activities to manage tasks across workgroups and to capture process best practices.

An additional consideration is to identify the target user population and to understand how they use the system. Some key questions regarding user demographics include the following:

  • How many users are expected to access the features concurrently?
  • What are expected to be the most active features, and by how much?
  • Which types of client software are used to access the features (browsers, feed readers, plug-in components, and so on)?
  • What are expected to be the most active features, and by how much?

It is also important to understand key installation and implementation considerations:

  • URLs to Lotus Connections features must be identified and registered to DNS prior to product installation.
  • When users authenticate, they are forced into an HTTPS connection to protect their credentials, so Lotus Connections URLs must have associated SSL certificates.
  • WebSphere Application Server security must be enabled and configured to support federated repositories before installing any Lotus Connections features.
  • The WebSphere Application Server application servers on which the services run must be defined, and the servers' default_host HTTP and HTTPS ports must be known at installation.
  • Databases must be created before the individual features are installed on the Lotus Connections server, and database user credentials must be entered during the service installation.
  • Credentials are needed to bind to the directory server for authentication, data synchronization must be identified prior to installation, and the proper rights must be set to allow the bind ID access to all needed user attributes and directory schema.
  • For Activities and Blogs features, credentials needed to connect to an outbound SMTP server must also be available prior to installing features.
  • Desired changes to the Lotus Connections user interface should be identified, and graphics and styles should be defined.
  • For the Dogear feature, internal IP address ranges must be identified so that the feature is able to differentiate between internal and external bookmarks. Also, you must ensure that the Dogear feature has the ability to access target sites that could be bookmarked.
  • For the Blogs feature, the user account that has administration rights should be defined prior to installing the feature, and the Blogs Home must be defined immediately upon installation.

Integration with key supporting systems

Of all the Lotus Connections features, Profiles requires the greatest amount of technical planning to implement. This is due primarily to the need to preload the Profiles data store with user information from other sources. When performing the initial planning, some key questions include:

  • Which data source(s) hold the user data to be loaded into the Profiles data store?
  • What are the field specifications of the source data (field name, type, data length)?
  • Is the load a one-time event, or are new source updates periodically pushed to Profiles? If so, does the data source have a change log that is accessible to Tivoli Directory Integrator?
  • Is user data that is updated in Profiles be synchronized with its original data source?
  • Is the desired organizational hierarchy defined in the data source, and is the information both consistent and complete?
  • Is additional multimedia information such as user photos and name pronunciations included in Profiles data? If so, where are these media files located?
  • Are standard codes used in source fields, such as user department or location codes? If so, where is the detailed user-friendly information such as department name or location address available to map to those codes?
  • Which data fields are displayed in a profile entry, and which of them are editable by users?

Identifying and validating the user data source are critical to the setup of Profiles. Usually this is the organization's LDAP directory, although it may be necessary to extract some of this data from other locations such as the company's HR database.

To expedite the loading of Profiles user data, Lotus Connections ships with a copy of Tivoli Directory Integrator V6.1 and a set of prebuilt Tivoli Directory Integrator assembly lines, configuration files, and command-line scripts. The main scripts are designed to support the extraction of user information from Tivoli Directory Server V6.1 or Microsoft Active Directory 2003. Additional scripts are provided to load photos, AVI files with user name pronunciations, detail data for location codes, and more.

There are also assembly lines that can be used by Tivoli Directory Integrator in server mode to poll and synchronize the source LDAP and the Profiles data store when changes are made.

If the source of the user data is not in a supported LDAP directory, it is possible to build custom assembly lines to extract data from other sources. Built-in TDI connectors allow administrators to read or write data from LDAP directories, relational databases, file system resources, and so on as well as write custom scripts to parse and manipulate data before it is written to the target system. In many cases, a custom TDI assembly line can be created and tested in just a few hours.

It is also critical to work with the administrators of the data source to ensure that Lotus Connections has the proper access to the data and that there is agreement between the data source's administrator and the Lotus Connections administrator regarding data updates and synchronization.

Adoption of Lotus Connections in your organization

Even though Lotus Connections provides a strong set of social networking tools, keep in mind that there is no social network without people. It is a mistake to assume that if you implement the tool, people in the organization will automatically to adopt it. While some people in the organization may have experience with public social networking tools, others may not initially see the value of such tools and may be reluctant to change their normal way of working. This may be very similar to the experiences businesses had with the adoption of other collaborative tools, such as the initial introduction of email or instant messaging.

Facilitating successful adoption requires a solid community of committed volunteers to seed the use of social networking in an organization. This core group becomes the organization's social networking evangelists and encourages the adoption of the tools among those with whom they work. With proper seeding, social computing often has a viral effect; it spreads quickly among teams and departments as its business value as well as its value to individuals is demonstrated.

Keys to a successful deployment include:

  • Defining specific goals related to social networking in the organization.
  • Identifying key contributors/champions in the organization to promote the use of the application.
  • Tracking contributor's participation and setting weekly individual contribution targets.
  • Providing feedback and comments promptly (people participate more actively if they feel that someone is paying attention to them).
  • If you plan a phased or pilot rollout, finding two groups in your organization that need to form trusted working relationships with one another, but that don't have those relationships today.
  • If it is installed, leveraging Activities for delivery of tasks.
  • Encouraging champions to evangelize the product to others in the organization.
  • Establishing guidelines early. Creating a "how to get started" activity with relevant bookmarks and to do items. Also, defining and publishing guidelines on appropriate and inappropriate usage.

In addition to supporting the adoption of Lotus Connections by users, you need to identify the Content and Community Manager roles in the planning phase. These roles are the person or groups directly responsible for adoption and governance of social networking in the organization. They:

  • Develop and manage business plans related to social networking
  • Monitor and report frequently on usage
  • Provide feedback to management and participants
  • Define and manage usage guidelines

Conclusion

Although Lotus Connections is a new product, it was designed from the ground up to support a variety of deployment options from small departmental systems to enterprise deployments. It provides a public API to allow organizations to rapidly integrate Lotus Connections features with other components in their IT environment. With proper planning, organizations can develop a deployment architecture that meets their business needs and can help ensure the adoption of the technology by their users.

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into IBM collaboration and social software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Lotus
ArticleID=243635
ArticleTitle=Deploying IBM Lotus Connections: Planning and architecture considerations
publish-date=09112007