mBot manages multiple RTC Client objects and exposes interfaces to them via .Net Remoting and .Net Web Services so that they can be managed and used remotely by other .Net applications or from entirely different platforms such as a Java J2EE/SOAP application like Jabber running on Linux or Windows.
![Managed_RTC_LCS_Bot.gif]()
Introduction
In his article "Implementing Automated Agents (Bots) using the RTC Client API[1]," Robert Osborne [Microsoft] provides a reasonable starting place for framing an automated information agent, or bot. This article is also about bots, but takes a very different approach by utilizing Microsoft's modern .Net technologies to enable a bot infrastructure with C#, .Net Remoting Services, and Web Services. Moreover, the significant limitations of the RTC Client 1.2 API's STA threading model are treated, making the infrastructure code for the bot much cleaner and better prepared to adapt to forthcoming collaboration APIs, such as those found in Longhorn.
The figure above provides an aerial view of what this article sets out to do: Craft a facility, called mBot, that will mange multiple RTC Client objects and expose interfaces to them via .Net Remoting and .Net Web Services so that they can be managed remotely by other .Net applications or from entirely different platforms such as a Java J2EE/SOAP application like Jabber running on Linux or Windows.
This article is more about framing a managed open infrastructure around the RTC Client COM object than it is about the RTC Client COM object itself. The RTC Client COM object is most certainly an essential central messaging component, but it is also one whose COM API we desire to abstract away with .Net Remoting and Web Service methods.
Documentation and Source Code Provided
The two zip files contain .Net C# code (source) and a 60 page pdf file (demo) that thoroughly documents the solution.