IBM Connections is a product from IBM that uses a set of J2EE-based social collaboration services tailored to support the needs of the enterprise. It consists of 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.

Functional features

The functional features of IBM 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.

Bookmarks: 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.

The following figure illustrates the logical architecture of IBM 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 IBM Connections features and data

Backend systems for use by those features for authentication, data storage, and integration with external messaging systems

IBM 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 Sametime or IBM Notes, the API is designed to allow customers to create, update, query, and manage IBM Connections information from their own custom applications.

Because the IBM 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.
In addition to the functional features that are accessed by clients, IBM Connections provides four additional common utility modules:

JMX administration: Used to configure and manage the IBM 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.

Business 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 IBM Connections for authentication, authorization, and query features.

IBM Connections also relies on several key backend services:

LDAP: Provides authentication and authorization services to IBM 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 IBM 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.

Outbound SMTP: IBMConnections 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

The following figure illustrates the primary deployment components that make up IBM Connections. These are the minimum required components. In some instances, components might be co-located on the same physical server. For example, while it is normally deployment best practice to install an HTTP server on a separate physical unit from the IBM WebSphere Application Server, it might 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.

IBM Connections requires WebSphere Application Server running on a supported operating system . 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 IBM Connections must scale to support deployment to a large user population.

IBM Connections databases can be hosted on either IBM DB2, Microsoft SQL Server or Oracle. On DB2, each service's data is stored in a separate database. On Oracle, 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 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 IBM 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.