Application Server 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.
This topic provides an overview of the new Application Server infrastructure introduced with Office Communications Server 2007 R2.
Components
The Office Communications Server 2007 R2 infrastructure includes the following components.
Application Server
Application Server is a new component on the Office Communications Server 2007 R2 Front End Server. Application Server provides a platform to deploy, host, and manage unified communications applications. By providing applications with essential services and a consistent model for installation, activation, provisioning, and upgrading, Application Server simplifies application development, deployment, and administration.
Note
Application Server does not support third-party applications.
Application
In this discussion, an application refers to a unified communications application that is hosted on Application Server. For each application, every Application Server in a pool hosts a separate instance of that application. Each application instance is defined by a specific fully qualified domain name (FQDN).
Deployment and Topology
The Office Communications Server 2007 R2 deployment wizard installs Application Server automatically as a separate process on the same computer as the Front End Server. No administrator input is required. In addition, there are no settings required to configure Application Server, although the same pool name and pool certificate are used by all Application Server computers in a pool. Application Server always runs as a separate process on the Front End Server, and it cannot be deployed on a separate computer in the pool.
After the Application Server is installed, the deployment wizard offers to activate four applications:
Conferencing Attendant
Conferencing Announcement Service
Response Group Service
Outside Voice Control
The administrator can choose to activate one or more of the applications, or none at all.
Application deployment must be identical on all Application Servers in a pool. That is, if Conferencing Attendant, for example, is deployed on one Application Server, it must be deployed on all Application Servers in the pool.
Figure 1. Application Server architecture
.jpg "ac377ccc-5149-4f15-8f1a-361eeccf0e55")
The administrator can manage application-specific settings for all applications, except Response Group Service, using the Office Communications Server 2007 R2 snap-in. You can administer Response Group Service using its separate administrative snap-in.
For details about these applications, see New Server Applications in New Server Features in the Getting Started documentation.
Activation
Application Server does not start or stop independently from the applications it hosts. As each application instance is activated, it is added to the list of applications on the computer.
When an application is activated, the application is provisioned with contact objects and trusted service entries such that calls can be routed to it. This provisioning information includes the phone number or Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) associated with the application, the application’s SIP port, and the FQDNs of the multiple instances of the application.
Call Routing
For purposes of call routing, each application endpoint is represented in the Office Communications Server 2007 R2 consolidated configuration by a contact object, which points to the Application Server’s FQDN and port. If you have deployed a hardware load balancer, the contact object points to the Virtual IP (VIP) address and port of the hardware load balancer that, in turn, has been configured with the IP addresses of all corresponding instances of the Application Server. The Application Server does not provide a single SIP listening port on behalf of all hosted applications. Instead, each application listens separately, using its own port. The hardware load balancer directs calls to different application instances according to its own proprietary algorithms.
Contact objects are required to enable applications to function as SIP endpoints, which can be provisioned with SIP URIs and can receive and send calls as if they were end users. Contact objects required for an application’s internal use are created during application activation. For the Conferencing Attendant application, contact objects are created when each new access phone number is configured. Similarly, for the Response Group Service, contact objects are created when a new Response Group is created.
Contact objects that function as SIP endpoints to make an application available to external users are created after deployment and activation by using the Office Communications Server 2007 R2 snap-in.