Developing applications for OCS - where do I start?
In a recent post, I presented an overview of all of the different APIs available in Office Communications Server 2007. The goal of that post was to help direct developers who want to know where to start. From that post I received some feedback that this proves that OCS 2007 development is only for advanced developers. This simply isn't true. What is true is that we have a wide breadth of APIs available in OCS 2007 and it is not always obvious which one is necessary.
Imagine that you wanted to develop an application on Windows Vista? How experienced would you need to be to accomplish this? Of course, the answer is "it depends". It depends what you want to create for Vista. Do you want to create a new device driver, web application, screen saver, client application, etc. The languages and APIs you use will be dependent on what you want to create. Even given the type of application you want to create, you still have myriad choices. Do you write native or managed code? It depends on what your goals are and the degree of control your application requires.
This is true to a degree with Office Communications Server as well, though thankfully we are nowhere near as complex as Windows. 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.