This is the first of a series of installments on creating applications in the latest Office Communications Server Beta.  I’m sure for many of you who have glanced through the documentation, this is a tall order.  OCS contains a number of API’s that each have their benefits.  I will not cover all of the API’s in this column.  Among the API’s that are present in OCS are.


Office Communicator Automation API – this contains a set of COM interfaces and .NET interop classes that allow you to query for presence information, launch IM, voice and video sessions, and enhance the client experience.  This is the API that is used in Microsoft Office and Sharepoint to display presence information.  I currently do not plan to cover this API.


Communicator Web Access – This AJAX API allows you to create web applications similar to a web based Office Communicator.  Some interesting applications can be created with this API and most people consider it to be the easiest to learn.  Applications using Communicator Web Access are typically written for Internet Explorer or Firefox and the API provides support for presence information and IM capability.  I may cover this in the future but in this installment I will not cover it.


OCS Server API – This includes Microsoft SIP Processing language (MSSPL) and allows you to create plugins directly into Microsoft Office Communications Server that can monitor, archive, and affect the routing of messages through the server.  These modules also support create .Net applications that  can call out to a database or perform some other operation.  Examples of applications that can be created with this API are

·         Content filters (remove or modify specific words/phrases or types of data)

·         Custom archiving of messages to specific stores or in specific formats

·         “Ethical Wall” applications that block specific people from communication (most often due to regulatory requirements)

·         Data mining where the contents of the message exchange is used to provide enhanced information to the participants

Note that I will not cover this API in this blog series.


Unified Communications Client API (UCCA) – This is an interesting API that allows you to create SIP clients.  I have not used it personally though I have heard it can be tricky.  The most interesting thing about this API is it contains support for media handling, which UCMA currently does not support.  This is also the API that was used to write Office Communicator itself.  I may cover this API in the future but I will not cover it in this series.


Unified Communications Managed API (UCMA) – There have been a number of names for this API.  Until recently it was called UCP.NET and within our team we still refer to it as Warsaw, which some of you may have heard.  Speech Server is built on top of this API and it allows you to create efficient SIP clients and SIP servers.  This is the recommended API for creating middle tier applications and it is designed to be highly scalable.  I will cover this API in depth in this series.


Speech Server API – For those of you who have followed my column from the Speech angle, this is the API you are most familiar with.  It contains the workflow activities and managed core API and can be used to create speech applications through telephony.  I may cover this API in this series.


Personally, the most confusing thing I found was whether to use UCCP.Net or UCMA.  Each has its advantages and disadvantages.  UCMA is more scalable but does not provide media handling.  UCCP.Net is not very scalable (so it isn’t very useful on the server side) but does provide media handling.  In general, you should try to use UCMA because it is the only API that is recommended for SIP server applications.


In the next installment, I will begin covering the UCMA API and we’ll start writing some code.