我想创建一个可以执行以下任务的简单服务器服务：
检索指定用户的状态信息。 向指定用户发送消息。
根据我一直在阅读的内容，并且因为我在服务器端进行选址，我可以选择使用 UCMA 5.0？但是我看到了很多新的 UCWA SDK 的推动和与 UCWA 休息服务的合作。为什么我会使用 UCWA 服务器端而不仅仅是 UCMA API，有什么特别的原因吗？我读到 UCWA 将在未来得到 Microsoft 对云的支持 --- 在这方面分享的任何意见和经验都会很棒。
谢谢，迈克
【问题讨论】：
标签： ucma ucwa lync-server-2013
Office 365 确实会在某个时候支持 UCWA。因此，如果您使用 UCWA 创建应用程序，您可以预期它会在未来的 S4B On-Prem 以及 Office 365 上运行。 无论如何我不得不说，365 对 UCWA 的支持已经期待已久，但仍然没有关于可用日期的官方公告。
选择 UCWA 而不是 UCMA 的一个很好的理由是，同样在服务器自动化的情况下，UCWA 的部署要简单得多（UCMA 部署非常困难）。
UCMA 必须在基本上加入 S4B 场的 Windows Server 操作系统上运行（因此位于您的 DMZ 中） UCWA 可以在任何“说”HTTP 的设备上运行。例如，您的 UCWA 应用程序可以在 Raspberry Pi 上运行
我认为这是一个巨大的差异，肯定是针对您的系统管理员的
【讨论】：
旧线程，但根据我的经验，使用 UCMA 编写服务器端代码比尝试使用 UCWA 更容易——而 UCWA 的真正含义是一个 UCMA 应用程序，它位于您的 Lync/S4B 服务器上，带有一个 REST 包装器。
对于您所描述的相当简单的用例，您可以将服务编写为客户端端点 UCMA 应用程序，这样可以避免 Massimo 为 TrustedApplication 提到的相当烦人的 Lync/S4B 拓扑更改和部署难题。在此配置中，您本质上只是一个第三方客户端，并且您提供凭据以作为指定用户登录 Lync/S4B。在这种情况下，唯一的要求是运行您的应用程序的服务器需要加入您的域，运行 64 位 Windows 操作系统，并安装 UCMA 运行时。
迫切需要在 Office365 上为 Skype for Business 提供某种 API 支持。有一些承诺会为 Office 365 提供类似 UCMA 的 SDK，但已经超过 6 个月没有实际发布的迹象。
【讨论】：