Export (0) Print
Expand All

Developer References

Communications Server 2007 R2

Topic Last Modified: 2009-05-14

The Office Communications group provides the following SDKs and API sets:

The following sections provide an overview of each SDK and API set. Find links to the MSDN documentation for each SDK and API set in the See Also section at the end of this topic.

The Microsoft () contains two API sets:

  • Application API
  • Management API

Communications Server Application API

A developer can use the Application API to create applications that extend and enhance the SIP-based functionality of . From developing custom message filters and routing applications to multithreaded transactional models and secure logging functionality, this set of APIs targets developers who want to implement custom behaviors for . These APIs can monitor and change SIP messages as they flow through . They cannot be used to create SIP messages from the server. For example, you cannot write applications that create instant messages with these APIs.

The Application API provides a set of tools for implementing custom SIP message filters and for dispatching messages to applications registered with Office Communications Server. The three primary tools are:

  • Application manifests, which define the basic message filtering and proxy behaviors.
  • The Microsoft SIP Processing Language (MSPL), which provides more granular control over filtering and proxy behaviors as well as a facility for dispatching specific messages to transaction-based SIP applications.
  • The Microsoft.Rtc.Sip namespace, which allows applications to access resources outside of while performing routing and filtering.

Applications that provide routing and filtering using only the resources, such as presence, provided by , can be created using MSPL. An application that blocks all instant messages that contain HTTP references can be written entirely in MSPL.

Applications that need resources external to , such as domain information or database access, need to have their MSPL code dispatch SIP messages to a separate process that uses the Microsoft.Rtc.Sip namespace. An application that allows instant messages that contain HTTP references to enterprise trusted sites, but blocks messages that reference sites that are not trusted or external sites, requires a separate application in addition to MSPL.

For information about the previously listed tools, see the following sections in this documentation:

  • "SIP Application Manifests", which are XML documents that describe a SIP application to the computer on which the application runs.
  • "Using the SIP Managed Application API", which contains the specifics of creating transaction-based SIP applications that run on .
  • "SIP Managed Application API Reference", which contains reference documentation for the Microsoft.Rtc.Sip namespace and other SIP-specific resources.

Communications Server Management API

The Management API consists of a set of Windows Management Instrumentation (WMI) classes used to manage components. WMI uses the Common Information Model (CIM) industry standard to represent systems, applications, networks, devices, and other managed components. Most class properties are exposed in the management console. All properties are accessible using a scripting language that supports ActiveX® script hosting, such as Microsoft Visual Basic Scripting Edition (VBScript).

You can use WMI scripting to automate administrative tasks in your deployment. You can also use WMI to remotely read or change WMI properties, but the computer running the script must either be an computer or have the Administrator Tools installed.

For more information about WMI, see Windows Management Instrumentation (WMI) on MSDN.

The Microsoft Unified Communications Managed API 2.0 Core SDK is a managed-code platform that provides access to and control over instant messaging, telephony, audio/video conferencing, and presence. It is intended to support the development of middle-tier applications targeting Microsoft Office Communicator and Microsoft Office Communications Server 2007 R2.

UCMA 2.0 Core SDK abstracts away most of the Office Communications Server protocols by offering an API that exposes almost all of the features of the protocol, yet is simpler to understand and use. For example, the contacts and groups for a user can be consumed using the ContactGroupServices class. A conference can be scheduled using the ConferenceServices class. A user or application can initiate a conversation with other users or applications using the Conversation class. An application can subscribe to the presence of other users or applications using the LocalOwnerPresence and RemotePresence classes.

The Microsoft Unified Communications Managed API 2.0 Speech SDK enables developers to build Office Communications Server applications that utilize speech recognition and text-to-speech features.

UCMA 2.0 Windows Workflow Activities can be used to quickly build workflow-enabled speech and instant message applications on OCS. UCMA 2.0 Windows Workflow Activities can be used to provide solutions for simple scenarios such as call routing, or for complex scenarios encountered by large enterprises, such as audio collaboration and business process workflow integration.

The Microsoft () contains a set of COM interfaces, objects, events, enumerated types, and other related programming entities. With , you can program an () instance from a third-party application and write applications that provide extended and customized user experiences with .

For example, you can sign into by calling the IMessenger::Signin method. This is similar to signing in from a running instance by clicking Sign In on the Connect menu. In addition, features can be integrated into other applications and extended or customized for special application needs. A scheduling application can use to leverage its contact management and query features, so that users can organize, display, or query their contacts.

As a COM-based API supporting Automation, can be called from applications written in Microsoft Visual Basic®, C/C++, VBScript, and many other scripting languages. For security reasons, some API calls are disabled for scripting languages. For a full description of these restrictions, see the Reference.

With the help of the System.Runtime.Interop namespace in.NET Framework, the API can also be called from applications written in any of the .NET-based programming languages, including the Microsoft Visual C#® development tool, Visual Basic .NET, the Visual J#® development tool, and others.

An application developer can create the following types of API applications for real-time communications and collaborations:

  • A comprehensive communications client such as Microsoft (). In fact, is built on API. This type of application can support instant messaging, conferencing, voice or video over IP, and telephony integration. It can also be used to track the presence of the user's contacts and other application-specific data because of the platform support of a general publication and subscription framework.
  • A feature-focused application that interoperates with and provides augmented functionality or custom services. This type of application enables a service provider to take advantage of an existing installation base within an enterprise. However, these applications must be careful to avoid publishing data and creating or accepting sessions in a way that interferes with .
  • An integrated line-of-business (LOB) application that embeds presence and communications capabilities into existing LOB applications. For example, a customer relations management (CRM) application can integrate presence tracking to decide how to dispatch custom requests to the most suitable service representatives.

A developer can use API to create an application that enables integrated multimodal real-time communications within or across network boundaries. The resulting application can help to make the computer the center for business communications in real time. Audio and video calls as well as instant messaging (IM) and collaboration are all integrated into one user session on the computer. In addition to computer-to-computer communications sessions, the user can also create computer-to-phone calls, phone-to-phone calls, or text-only IM sessions.

Presence information provides a user with knowledge of the availability of the user's contacts in real time, with the help of a registrar server. A user can therefore use such an application to call the contacts without having to find out the exact location of a contact or to choose the right telephone number to call. For example, if you dial a contact at her work location and the presence information indicates that she is available on a computer at home, your call can be automatically redirected to that location. A user can also maintain privacy by blocking callers from accessing his or her presence information.

An example of such real-time communications for business application might be a custom communications experience for users of your applications; for example, a CRM application that brings all the parties interested in a sales opportunity into a video conference and shares data about the customer.

IM services are currently used by the Microsoft MSN® network of Internet services, Yahoo!, and AOL with hundreds of million users globally.

The Microsoft® () consists of the following components:

  • is an application programming interface to . The API is composed of methods and events. A client sends a method as a request to a server and the client receives data as events from the server. Requests and events are specified as an XML element. The communication is conducted primarily as HTTP POST requests with HTTP GET requests in individual scenarios. Unlike applications designed as Web Services, Server will not parse SOAP messages, nor does it provide a WSDL document for consumption by client application development tools. There are two advantages to this approach. Most importantly, it avoids the overhead created when JavaScript code must generate or parse larger SOAP documents. Secondarily, a general knowledge of XML rather than specific knowledge of SOAP messages is sufficient to be successful with the .
  • Unified Communications JavaScript Libraries based on the AJAX service. These are JavaScript classes that encapsulate the commonly used functionality required of a Unified Communications JavaScript Libraries Client. The common functionality includes creating and maintaining the communication channels, signing in to a server, embedding the display of a user presence in a Web page, starting an IM conversation, and so on. Using the libraries, an application developer can create a Unified Communications JavaScript Libraries Client by simply instantiating the libraries, setting appropriate properties, and invoking the desired methods.

The Server provides access to Unified Communications functionality.

The Microsoft () gives you programmatic access to most of the functionality that is available through the Windows-based and Web-based Office Live Meeting clients.

The documentation consists of two parts:

  • A general guide to introduce new programmers to the concepts of Live Meeting and the application programming interface (API) with examples and tutorials.
  • A detailed API reference, including information about publicly supported messages, constituent XML elements, error codes, and other technical information.

The API documentation is intended for engineers, developers, and programmers who design, implement, and test Web conferencing solutions based on the Live Meeting technology. You should have a basic familiarity with HTTP and XML.

A developer can use Live Meeting services to manage online meetings. The tasks include scheduling a meeting; inviting others to join the meeting; adding a user account to a Live Meeting conference center; uploading presentations and other resources; managing recordings, user preferences, and an address book; reporting on meeting attendance and other statistics. Many of these tasks can be performed programmatically.

Live Meeting services can be accessed through the Live Meeting Web user interface or the API processor. A user can use the Web user interface to perform all meeting-related activities. The Live Meeting service API processor serves as the gateway for programmatic access to Live Meeting services and for managing users, resources, and meetings.

The Microsoft () complements Service Pack 2.

The (the Portal) is a Microsoft Internet Information Services (IIS) Web application that uses ASP.NET. The Portal is installed on a Microsoft Windows® Web server. The Portal communicates with the Live Meeting service through XML API calls sent across the Internet.

Users can access the Portal Web pages from Web browsers to:

  • Create a new Live Meeting account.
  • Sign in to the Live Meeting service.
  • Change the password for the Live Meeting account.
  • Allow users to access rich content related to Live Meeting.

Programs or scripts that call the Portal Web methods can automate Live Meeting account management. Use the Web methods to:

  • Create or delete a Live Meeting account.
  • Activate or deactivate a Live Meeting account.
  • Change the password for a Live Meeting account.
  • Get the status of a Live Meeting account.
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft