Communicator Web Access Core Architecture

Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 will reach end of support on January 9, 2018. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

Communicator Web Access (2007 R2 release) is comprised of three main components: the zero download browser-based client, the application logic layer, and the Unified Communications Managed Application Interface (UCMA) layer. The application logic layer and the UCMA layer are hosted on the Communicator Web Access (2007 R2 release) server and form a web site that is hosted by Internet Information Server (IIS) 6.0 or 7.0.

The Communicator Web Access (2007 R2 release) server is a middle tier between the browser client and the Office Communications Server 2007 R2 pool. The Communicator Web Access server does not provide any functionality without the pool. Users with accounts homed on an Office Communications Server 2007 pool are not supported. However, you can configure the Communicator Web Access (2007 R2 release) server to redirect users who are homed on an Office Communications Server 2007 pool to a Communicator Web Access (2007 release) server.

IIS provides the authentication services for Communicator Web Access (2007 R2 release). IIS provides this service either through integrated authentication in the case of a domain-joined workstation or through forms-based authentication in the case of an external user, or Safari or Firefox users. Communicator Web Access (2007 R2 release) server does not provide authentication services. After the authentication token is passed from IIS to the Communicator Web Access (2007 R2 release) server, the server does not attempt or perform any further authentication.

When the client browser contacts the Communicator Web Access (2007 R2 release) Web site, a compressed JavaScript client is downloaded from the Communicator Web Access (2007 R2 release) server (that is, by using IIS) to the client browser. In the case of a domain-joined workstation that uses Internet Explorer, integrated authentication occurs. In the case of a non-domain joined Windows-based workstation that uses Internet Explorer, Safari, or Firefox, the client displays a forms-based authentication screen where the user enters a valid Session Initiation Protocol (SIP) address and password. The client browser must accept pop-up windows from the Communicator Web Access (2007 R2 release) server.

As can be seen in the following figure, the Communicator Web Access (2007 R2 release) server is a virtual Web site that is hosted by an IIS server. The browser-based client communicates with IIS through the HTTPS protocol. The IIS passes the data packets to the client communication component which translates the incoming XML packet and sends the packet to the application logic layer. The application logic layer performs actions based on the XML header and, through the UCMA, passes those results to the Office Communications Server 2007 R2 pool through SIP. The path from the pool server to the client is the reverse as follows: pool to UCMA, UCMA to the application logic layer, application logic layer to the client communication component, and finally through HTTPS to the browser-based client.

Figure 1. Communicator Web Access (2007 R2 release) server architecture

The Communicator Web Access (2007 R2 release) server components are nearly stateless. The application logic layer maintains persistent states for the HTTPS to client link and the (that is, through the UCMA) registered user endpoints. The client posts a Get request after each receive packet to establish the ability for the server to send more data without a specific client request. The Get request is necessary so that the server can send the browser client data, such as conversation requests or contact list presence changes. The open Get request cycle is controlled by the Communicator Web Access (2007 R2 release) server load control function which can request that clients delay posting the next open Get request.

UCMA Layer Functions

The UCMA layer of the Communicator Web Access (2007 R2 release) server uses the UCMA application programming interface (API) to do the following:

• Create and manage all of the communications between the Communicator Web Access (2007 R2 release) server and the Office Communications Server 2007 R2 pool.

• Create and manage a UserEndpoint, registered with the Office Communications Server 2007 R2 pool, for each user of the Communicator Web Access (2007 R2 release) server.

• Create and manage all sessions, such as IM sessions, between the users of the Communicator Web Access (2007 R2 release) server and the Office Communications Server 2007 R2 pool.

• Subscribe to presence information about the user (that is, self information) and the user’s contacts.

• Publish presence information on behalf of the users of the Communicator Web Access (2007 R2 release) server.

Application Logic Layer Functions

The application logic layer is a translator between the pool and the Asynchronous JavaScript And XML (AJAX) and facilitates communication with the JavaScript client. The application logic layer provides the following basic functions:

• Registers user endpoint. Logically, the Office Communications Server 2007 R2 pool sees the application logic layer user endpoint as the client, not the actual client on the browser.

• Manages proxy client communications to and from the pool. The client browser is never in direct contact with the Office Communications Server 2007 R2 pool.

• Maintains the registered user endpoint for each user connected to Communicator Web Access 2007 R2.

The UserEndpoint is the object that the Communicator Web Access (2007 R2 release) server uses to support all the operations between the client running in the user’s browser and the Office Communications Server 2007 R2 pool. The UserEndpoint is used to do the following:

• Subscribe to the self-presence information for the registered user, including:

  • List of contacts

  • Published phone numbers

  • Call handling settings (that is, forwarding, simultaneous ring, and so on)

• Publish presence information for the user.

• Register for incoming session requests from the Office Communications Server 2007 R2 server.

• Create outgoing sessions requested by the client using their browser.

The Communicator Web Access (2007 R2 release) server attempts to minimize the amount of state that it maintains for each registered user. As requests and data are received by the application layer from the Office Communications Server 2007 R2 pool, they are forwarded to the user’s browser session. As requests and data are received from the user’s browser session, they are forwarded to the Office Communications Server 2007 R2 pool.

Client Functions

The client functionality for Communicator Web Access (2007 R2 release) is implemented by a set of JavaScript libraries that are downloaded to the browser when the user’s session with the Communicator Web Access (2007 R2 release) server starts. These code libraries are sent from the Communicator Web Access (2007 R2 release) server in a compressed form to the browser and provide the communications functions and logic of the Communicator Web Access (2007 R2 release) client. The libraries also provide the user interface (UI) of the Communicator Web Access (2007 R2 release) client along with the DHTML in the Web pages.

The following figure shows the architecture of the browser-based client. All communication with the Communicator Web Access (2007 R2 release) server is by HTTPS. The data packets are XML. The overall layout has three layers: the proxy layer, the data and logic layer, and the UI layer. The UI layer consists of the visual components that are presented to the user in the form of browser windows. The sole exception to this paradigm is the system alert which appears in the form of a small pane sliding open from the system tray.

Figure 2. Communicator Web Access (2007 R2 release) client architecture

The proxy Layer is the only component of the client to communicate with the server. It is responsible for sending HTTP requests and receiving HTTP responses from the server. The data and logic layer is responsible for managing data and logic for the user endpoint. The UI layer provides all user input and screen that the user sees.

The client provides all user interface functions. After the user logs on, the client performs the following actions automatically with requiring user input:

• The client uses the registered user endpoint to publish a set of endpoint capabilities with the Office Communications Server 2007 R2 pool.

• The client requests self data from the pool. Self data includes contacts, end points, client configuration, and calendar data.

The data and logic layer consists of the user session, the presence manager, the contact list manager, the options manager, the conversation manager, the system alert manager, the search manager, and the component store. In the UI layer, there is a one-to-one relationship between the UI component and the manager in the data and logic layer. For Example, the system alert manager controls the UI system alerts and included functions, and the conversation manager affects the UI conversation window.

A use case example of an IM conversation would use the server communicator (proxy layer), the user session, the presence manager (that is, to report to the pool that the user state has changed), and then the component store invokes the conversation manager, which opens a conversation window. During the course of the conversation, if the user receives a data packet that needs open a system alert to notify the user of an audio call, the component store will invoke the system alert manager which then opens a system alert.

In each case where you use the component store to control the UI experience, the headers in the data packet contain information from Office Communications Server 2007 R2 that determine which function is being called, while the data and logic layer determines how to respond to the XML packet header. The previous conversation example is duplicated for each component manager. The XML packet is received, the XML header indicates the action(s) to be taken, and the component store either triggers a new conversation instance or adds components to the existing conversation windows.

See Also

Concepts

Communicator Web Access Scenario