Share via

Developing applications for OCS - where do I start?

  • Article

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.

Comments

  • Anonymous
    August 25, 2007
    PingBack/TrackBack from http://msgoodies.blogspot.com/2007/08/interesting-posting-developing.html

  • Anonymous
    September 05, 2007
    The comment has been removed

  • Anonymous
    September 06, 2007
    I build a bot(using you're examples as a starter) which funtions fine  except one part and i can't seem to figure it out. Depending on the questions and anwser i want the session to be refered to a different RealtimeAddress. But i only get timeouts, is this depending on the the client application in this case Mocc2007??? Any Idea's are welcom.

  • Anonymous
    September 14, 2007
    Developing applications for OCS - where do I start? An overview of the APIs in Office Communications

  • Anonymous
    September 20, 2007
    What APIs would I need to implement call ring feature to OCS? With call ring I mean that for instance me and my two friends should be alerted when somebody calls me and only the quickest one can take the call. Would OCS Server API serve the purpose (which you don't cover in your blog)?

  • Anonymous
    September 21, 2007
    Weckstrom - yes, this would be the OCS Server API Marc - I haven't tried this, but TerminateWithRedirection on SipSignalingSession should do what you need to. Keep in mind the Communicator sends the message before the dialog is complete - see my posts on bots for how to work around this.

  • Anonymous
    October 08, 2007
    I'm developing an application to set a users presence and this presence "notice" field. With the OC API, it is possible to set the presence but I couldn't find a possiblity to change the notice field. Any suggestions? Thanks.