OCS creates some really cool opportunities for developers. Having presence information in application can let you show or test fo availability beforer outing a message. You can use IM as a message transport. You can add voice, or even video really easily. Joe Calev has a couple of good posts about getting started with OCS development and about the APIs available.
Joe identifies five types of OCS apps:
In terms of application types, there are five main application types in OCS 2007.
Client applications - These are communications applications that consist of .exe's and .dll's that run on the client - similar to the way Communicator runs. You can further subdivide this into three categories.
Is it OK if Communicator handles the communications aspect for me? - In this case, OC API will be your best choice and your job should not be very difficult because this is an easy API to learn and use.
Can I achieve my goals by adding a tab to Communicator? - If this is the case, your job is even easier. See my post on this for details.
Do I need to embed communications within my application? - This should be the rarest case, as in general you should let Communicator do the work for you. But if you need to do this we do have an API called UCCA that will enable you to do this. In this case, you will need an experienced developer and a lot of time. However, as I pointed out already, this API should only be used in exceptional cases.
Web applications - Here the answer is simple as we have only one API - Communicator Web Access. This is a very simple API and does not require an experienced developer.
Routing and filtering applications - In this case you're goal is really to change the routing and filtering behaviors of OCS. In terms of what language to use, you just need to ask yourself this question - "do I need to access external resources (such as databases) or make use of complicated algorithms to make decisions?". If the answer is 'yes', then you need to use the managed API. Otherwise you should use MSPL. Although these APIs are not trivial, they are also not overly complex.
Server applications - Here the most useful API available is UCMA. Admittedly, this is not a simple API and will require a more experienced developer. You can find a lot more information that I hope will simplify this API for you on my blog. Note that the most complex aspect of this API is the prerequisite that you are familiar with SIP. If you are already familiar with SIP then the API is not overly complex.
Speech IVR applications - I outlined three different APIs in my blog, but the truth is you should use only one of them. VXML is included for those familiar with it, but writing managed code is far more efficient and flexible. When using managed code, it is highly preferred to use Workflow activities, as we do not guarantee that that the Core API will have an easy upgrade path in future versions. Besides, the Core API is more difficult than using the Workflow activities and provides no additional functionality.
As you can see, the APIs available for Office Communications Server 2007 are like a toolbox. You will likely need only one or two tools from the box and in most cases the tools are easy to use.
In the API post Joe gives an overview and references for:
- Office Communicator API
- Extending Communicator through tabs
- Microsoft SIP Processing Language (MSPL)
- Office Communications API – managed filtering
- Communicator Web Access (CWA)
- Speech Server Core API
- Speech Server Workflow