案例研究:IP 电话集成架构

阅读数:1555 2007 年 6 月 20 日 00:58

简介

作为 InfoQ 的一个案例研究,本文将向我们展示电话领域的一个有趣的解决方案。LiteScape Technologies 是一家私有制的软件公司,它为每个机构提供通讯一体化的应用。这些应用可能使用任何 IP 设备,例如 IP 电话、移动设备和 PC,利用业务应用系统和协同的数据来安全地整合 IP 电话技术。LiteScape 的解决方案已经被应用于多个垂直行业,包括零售业、制造业、专业服务业、金融服务业、公共事业和医疗保障。今时今日现代化的工作环境衍生了一系列通讯媒介,例如 Email、电话会议、在线演示。每种方式都有自己的用户界面、进行初始化的方式等。LiteScape 的软件应用系统简化了这些方式的使用,并有效的在早期不兼容的数据和设备间进行集成,它通过这种方法将以上通讯媒介整合在一起。

本案例将揭开 LiteScape 软件解决方案的神秘面纱,引导你从需求的角度审视它们基于 Java 和.Net 实现的架构全貌,随后我们还将聚焦它们项目中一些有趣的技术方向,包括基于 WebEx/LiveMeeting 的电话集成、对 Java 与.NET 间互操作的集成,安装在同台计算机上的各个操作系统间的 HTTP 与 IPC 通信比较,最后是此项目中的收获。

问题域分析

作为端到端业务解决方案的提供方,ListScape 必须支持以下一系列的输入和输出:

  • Outlook/Exchange
  • 远程协同组件 (WebEx, Live Meeting 等)
  • CRM 解决方案 (例如 Salesforce.com, MS-CRM)
  • 目录服务 (LDAP / Active Directory)
  • Presence 服务器 (MS-LCS, AOL)
  • 通信基础设施 (IP-PBX 的产品, MS-LCS, 桌面电话)

这些服务利用网络进行传输,涉及许多不同的协议和接口。客户接着会希望通过 Web、桌面客户端甚至是基于 IP 的电话来访问同样的信息。

事实上电话正在成为多媒体终端,它们直接集成用户在 PC 上完成的所有工作,并加以补充。它们还能像智能设备那样代替 PC 提供高级通讯功能。电话成为桌面计算机的一个扩展,它比计算机更适合来简化通讯任务并使之自动化。这类用途的例子包括用于启动 / 加入电话会议的 one-touch 式 应用,在呼叫联系人前在电话上显示联系人信息,以及访问共享的和个人的目录服务。公司还使用 IP 电话网络来广播信息,例如广播火灾警报,信息中包括标有针对每个员工最快逃生路径的可视地图,逃生路径根据员工的电话在大楼中的物理位置产生。

将应用扩展到 IP 电 话上并非易事。大多数情况下,用户界面就不能直接迁徙。要兼容各种电话的输入和特定的屏幕,设计用户界面时就一定要慎重思考。这种扩展更侧重于应用或数据在电话中的呈现,而非简单的将应用迁徙到电话上。一旦这个过程完成,登录到在线会议就会非常简单,在电话上查看会议日历,随后选择“加入会议”的按钮来同时加入到同一个协同会话的音频会议和 Web 会议中(译者注:音频会议使用电话,Web 会议使用 PC)。

当 LiteScape 首次提供 IP 电话时,任务的特殊性是集成案例的一大特点。例如,在许多环境中(零售业或制造业),电脑是稀缺的并且不能为每个人所使用,这归咎于预算限制和业务的特殊性,但 IP 电话没有这些问题。因此,公司能够依赖 IP 电话应用来进行各项活动,例如工时卡打卡或多媒体产品培训。律师事务所也发现 IP 电话的作用,例如直接记录利用客户端进行通话所耗费的时间,并且在每次通话结束后将时间与客户端 / 事件的记录关联起来,这在减少时间和纸张成本方面具有不可估量的价值。LiteScape 的应用提供了针对各个领域的系统级集成,这些领域包括目录服务和时间 / 帐单管理等。该技术也成为许多其它公司竞相使用的平台,例如 Infosys 和 WebEx 利用该平台将自身的产品和服务扩展到 IP 电话级别。

解决方案概述

LiteScape 的架构可分为三个部分。第一部分是公司已经拥有的第三方通讯基础设施组件,例如 PBX 系统,IP 电话,以及企业级业务应用系统和目录。架构的第二个组成元素是 LiteScape 的多态应用系统平台(MAP)。最后是 LiteScape 架构的第三个部分,它包括多种客户端,这些客户端利用 MAP 将应用扩展到用户的 IP 电话和计算机桌面。客户端包括 Outlook/Notes 插件,一个标准的桌面客户端,以及 Web 浏览器。

图 1: LiteScape 架构总览 

随着 LiteScape 的产品不断升级,产品的技术也在不断发展。产品最初不过是基于 Java 的解决方案。然而,与 Microsoft Unified Communications 进行集成的需求使得公司开始将.NET 纳入基础设施中。今天,以 Java Web Start 和.NET 客户端的形式,Java 和.Net 都能被用作产品的前后端,LiteScape 产品支持装有 IIS 的 Windows 2003 和基于 Java 的集成产品(例如 Sun 的 Java Media Framework 服务器)。

他们使用 IntelliJ IDE 进行 Java 开发,使用 Visual Studio.Net 进行.Net 开发。LiteScape 的服务器安装 Windows 2003 并使用 IIS,同时利用一些 Windows 服务来支持.Net 编写的集成产品。与此同时,一份 Apache Tomcat 的拷贝会被安装在不同的端口,来运行任何必要的 Java 组件。服务器上的 Java 应用服务器满足了一些 API 的需要,使得诸如 Apache Axis 能够提供 Web 服务支持。.Net 和 Java 的 Web 服务器一起运行在同一台计算机上。在对应的客户端中,基于.Net 的 OnCast 客户端提供 Windows XP 和 2003 平台上的桌面访问,而企业级的 Linux 同样提供了 Java Swing Web Start 客户端来满足企业需要。

图 2: Map 服务器组件

图 2 中展示了 MAP 服务器的动态组成部分。IIS 和 Windows 服务的.Net 组件提供了一些功能(例如 OnCast 的目录模块)。Tomcat 服务和 Java 组件提供了另一些功能(例如 SIP 的网关)。利用 Apache Axis,基于 Java 的 Web 服务被部署为 servlet。最终,某些模块,例如 OnCast Presence 和 CTI(Computer Telephony Integration,计算机电话集成),贯穿于 Java 和.Net 的运行时。

撇开架构自身,各式各样的技术性协议成为我们下一个关注的方向,它们共同为图 2 中所介绍的这类用户提供了统一的通讯体验。

图 3: 涉及到的通讯协议总览

LiteScape 的 OnCast 客户端(OC 客户端)是一个桌面程序,它能够展示从 MAP 服务器获取的消息,同时还能够与其它桌面程序(例如地址簿和 Microsoft Outlook)等交互。它还可以启动一些第三方程序,例如 Web 浏览器和 WebEx,来实现一些通讯功能(例如在线会议)。OnCast 客户端利用一个通讯层(OC CIL)来与 LiteScape 的 MAP 服务器通讯。通讯过程依赖于任务执行中所涉及的各项协议。对实时通讯而言,SIP 协议是最为有效的。其它活动,例如验证和个性化都由 Web 服务来处理。MAP 服务还使得客户端能够访问第三方组件(例如像 Microsoft Active Directory 和 OpenLDAP 这样的目录服务)。MAP 服务器还能初始化某些 IP 电话网络的功能,这些 IP 电话网络通常运行在第三方的 IP- PBX(译者注:IP-PBX,基于 IP 的公司电话系统)上,第三方 IP-PBX 包括 Cisco CallManager, Avaya Communication Manager, 或者 Asterisk。针对目录服务的通讯由平台的每个特定的协议来处理。协议 / 传输技术,例如 XML,HTTP,Java Telephone API,以及 SNMP,都会被应用于基于后端系统的 IP-PBX 通讯。

深入探索 1: 集成 WebEx/LiveMeeting

以下是一个此类应用与 IP 电话集成的例子,LiteScape 提供了基于 WebEx/Microsoft LiveMeeting 的会议支持。在尝试开始或加入在线会议的过程中,许多人频频受挫于复杂的 URL、数字键入以及必需的访问码。 LiteScape 使这个流程自动化,因此它不仅能通过电话被初始化,还能在用户桌面中与 WebEx/LiveMeeting 进行集成。

在一些典型使用案例中,用户已经被邀请来加入到 WebEx/LiveMeeting 会话中,以下两种方式之一都可以使流程继续。第一种方式,用户可以手工将邀请添加到他们的日历中。而在拥有 OnCase 服务器扩展(以 email 服务器的形式监听邀请 email,Exchange 接收它们的方式与此相同)的情况下,邀请同样可以自动地被添加到用户的 MS-Outlook 或 Exchange 中。随后,集成过程将继续执行。

会议开始前应该启动 OnCast MAP 服务器(使用 IP 电话协议),通过向用户的电话发送 OCM(OnCast Multimedia message)来传递 WebEx/LiveMeeting 会话。OCM 的结构中提供了一个集合来容纳一个有效负载(译者注:payload)XML 脚本的文档和必需的相关内容,这些内容都是 LiteScape 平台在各类通讯终端(例如桌面代理、电话、IP/ 模拟扬声器等)间进行双向多媒体传输时所需要的。

OCM 的结构为许多基本的内容形式提供了支持,这些内容形式包括文本、音频、图像、语音,同时该节后还支持诸多混合内容的处理器,如协同工作、RSS 种子、股票报价、多选项调查、MS-Power-Point 演示、Adobe PDF 文件等。

LiteScape 的 OCM 包含一个基于“有效负载”的 XML 文档,这个文档提到了必需的字段和属性,以及将被传递的多态事件处理需求。

以下是 OCM 有效负载的片段,这个片段针对的是一个现实场景中的会话,用户采用 Cisco 和 Avaya 类型的 IP 电话参与到这个会话中来:





John.Coyle

20353

20353

CN=John Coyle,CN=Users,DC=litescape,DC=local|AD



IP-PBX 1

IP-PBX 1

Headquarters



10.12.2.52



Cisco 7961

20353





NONE

MULTICAST



0









170

107

195

132

http://10.2.0.145:80/MW/HandleEvent.aspx?scannedItemSize=26

25|BLUE+RIBBON|Dark+Blue|01FFAA06000104E0



Samira Kashani

20365

20365

CN=Samira Kashani,CN=Users,DC=litescape,DC=local|AD



IP-PBX 1

IP-PBX 1

Headquarters



10.11.2.4



Cisco IP Communicator

20365

...

...

ConferenceTemplates\WebEx.ocm





18665551212

Dial

http://10.12.0.5:80/oncastdirdialer/AD/createShortcut.aspx?key=20353







False

True

58c5cdcb-b1be-4dab-9bcd-7d9ea3a55465



RunBCPayLoad

OCM 可能会包括一张发出会议呼叫请求的用户的图片(被嵌入或链接的),一个附件或一个用来指向与会议内容相关 ppt 的链接,又或者一段与会议相关的视频剪辑 (被嵌入或链接的)。用户随后可以通过他们的电话选择加入电话会议。这个时候 MAP 服务器将接收到请求并启动 WebEx/LiveMeeting 会话。 MAP 服务器还会通知 IP PBX 来初始化 WebEx/LiveMeeting 会议的呼叫监听。MAP 服务器还将与桌面的 OnCast 客户端通讯,该客户端将在用户桌面自动启动一个 WebEx 会话,并将它们登录到会议的会话中。图 4 展示的是这个顺序:

图 4:通过 IP 电话启动 WebEx 会话的流程

深入探索 2: Java 与.NET

图 2 展示了 LiteScape MAP 平台服务器中的组件。MAP 平台服务器同时使用了 Java 和.NET 技术。像 OnCast 目录这样以.NET 编写的组件,它们能与已安装的 IIS 实例通讯,并以 Windows 服务的形式运行。其它组件,例如 SIP 网关,是以 Java 编写的。最终,MAP 平台也会包括同时使用 Java 和. NET 的混合组件,例如 OnCast Presence 和 CTI(Computer Telephony Integration)模块。

由于一些原因,LiteScape 同时选择了 Java 和.NET 技术。首先,他们的客户有强烈的意愿去运行集成在 Windows 中的桌面客户端。他们同样也希望访问特定平台上的数据,例如能用微软的 MAPI 接口来访问的 Outlook 地址簿。最后,还需要提供安全的单点登录。应用.NET 的话, LiteScape 可以选择 Windows 授权和域安全机制。所有这些除了.NET 外,还能访问 Java 的服务(例如 Sun 的 Java Media Framework 服务器)。一个最佳组合的解决方案也简化了部署。许多 LiteScape 的客户都已经选择了微软的技术。因此,IIS 早已被安装了。

为了支持这种混合架构,我们需要不依赖于平台的通讯方式。运行在 MAP 服务器上的.NET 和 Java 组件提供了基于 Web 服务的 XML,这些 Web 服务提供了许多通用功能。这些组件还使用了 TCP 和基于 SIP 的协议。

其它选项,例如 JNI 和其它.NET 与 Java 间的集成库,它们没有入选的理由很多。LiteScape 的架构缺少前期成功使用这些技术的经验。在实现实时通讯时,它们还存在若干障碍可能需要再开发。最为重要的一点,LiteScape 不愿意受制于第三方集成库。某种技术被第三方库中止开发或第三方库提供的技术不够完善,由此导致 LiteScape 需要开发一个自身技术体系中的关键技术,这是它不希望遇到的。

LiteScape 的架构选择多种技术并存,而非以一种技术满足所有形式的需要。例如,这使得在提供呼叫控制功能时,在支持 Java 电话 API 的设备上能够使用此 API。其它集成例如 Exchange 和活动目录,使用.Net 让编程更容易。最后的难题是将五花八门的技术连接在一起。

各个部分通过技术手段进行互操作的一个例子是,当 CTI 引擎收到呼叫时,它将随后激活一个针对所有相关部分 (其中包括用 Java 编写的 SIP 网关)的事件。典型的业务案例是,当关于呼叫发起人的目录和业务信息进入企业时,对一些现有的基本信息进行补充。为实现这个功能,SIP 网关要通过 Web 服务将一个请求传递给基于.NET 的 OnCast 目录组件。获得了补充的信息后,SIP 网关将利用 SIP/CSTA 通知 OnCast 客户端,为用户展现呼叫发起人的额外信息。

深入探索 3: 利用 OnCast 客户端和 Outlook/Notes 插件来简化通讯

一个利用 LiteScape 的技术提供统一通讯体验的具体例子就是 Outlook 集成插件。它的特点就是,在 email 中右键点击一个名字将初始化一个电话 / 会议的呼叫。

技术上,为支持这个操作,系统执行了一系列步骤。

Outlook 插件是.NET 编写的,它的安装需要基于.NET 的 OnCast 通讯层(CIL)。OnCast 通讯层是一个与系统无关的模块,提供例如联系人加载、用户(参加会议的用户)状态更新、P2P 消息传递和 SIP 消息传递等服务。OnCast CIL 用一个独立的线程上的 HTTPListener 来过监听一个 TCP 端口,从而接收任何可能的 OC CIL 基本命令。它以套接字服务器的形式启动,处理 HTTP 协议中传输的请求(拨号、会议、广播、协同工作和远程呼叫控制请求)。这使得命令需要以简单 URL 的形式发出:

Dial: http://127.0.0.1/dial?number= [Number]

图 4: 从 HTTPListener 到 OnCast 目录的一个示例命令的流程

图 4 中所展示的 http 呼叫在基于.NET 的 OnCast CIL 库中,被转换为 HTTPCommand 对象。随后这将触发一个 CIL 命令,从而导致 OC CIL 客户端与 MAP 服务器的通讯,执行如初始化呼叫的操作。从协议的角度来看,请求的流程以 HTTP 开始,随后被转换为.NET 的内部方法调用,然后以 Web 服务请求的形式传输,最终被 MAP 服务器以 IP-PBX 的形式执行,从而启动一次呼叫。

这种方式集成带来的一个显然的疑问是,为什么将 HTTP 协议用于客户端,而不是在 OnCast 客户端和 Outlook 插件以及 OnCast CIL 通讯库间使用纯粹的.NET 集成。这种设计的理由有两重。首先,提供基于 HTTP 的 API,这将允许其它客户端在技术上使用诸如 Java Swing,来实现同样的功能。第二,在 LiteScape 的经验中,Outlook 插件易于崩溃。使集成保持尽可能的松耦合,那么一个插件的崩溃将不会影响客户端电脑上运行的 OnCast CIL 服务。Outlook 随后只需要重新启动,而用户也能再次尝试进行通讯。

经验 / 最佳实践

在 LiteScape 服务器与客户端平台组件的开发过程中,它们的工程师收获了许多经验:

  • 为了使未来的集成中更简单,组件都应该尽量不依赖于平台。例如,如果一个编码库被以 Java 编写了,那么相应地,LiteScape 需要为.Net 编写一个同样的库。当考虑第三方技术时,同样需要这样思考。
  • 如果无法确定第三方组件,那么使用平台无关的协议(例如上面提到过的那些)在传输层进行集成。
  • 关注平台的特定通讯特征,如换行和缓冲以及 Unicode 字符转换。
  • .Net 领域的社区和可用组件比 Java 领域少。然而,能够拿起电话并拨打 800 寻求技术支持(指微软的技术支持),这一点的价值不可估量。而 Java 或 Java 相关库中的问题诊断通常需要搜索知识库和邮件列表。相比之下,微软技术支持代表往往能够一针见血地指出组件例如 IIS 的问题所在。
  • IP 电话是一门快速变化的技术,只能通过最佳组合的策略来支持。一个一成不变的应用将无法应对每个客户的需求。I
  • 使用符合你需要的协议或技术。由于协议而导致的 5-10 秒的额外邮件延迟是可以接受的。以毫秒来计算电话呼叫,像这样的目标是永远无法实现的。

未来的方向

LiteScape 会继续使用他们最佳组合的技术。随着 IP 电话、VoIP 和协同空间日新月异,这些支持必然会被纳入新电话的研制,并成为例如 WebEx 和 Microsoft Live Meeting 技术上的模块,增强其通讯能力。LiteScape 还在找寻应用领域范围来继续扩展集成,这些领域包括 CRM、库存管理和人力资源。在技术层面,他们已经探索了利用 Mono 库,在基于 Linux 的服务器上部署基于.NET 的服务器组件的可能性。

总的来说,LiteScape 努力不使他们的产品成为新技术的实验品(译者注:原文使用“guinea pig”,指用于做实验的材料)。他们静候每项技术的成熟,并且努力不使他们的客户依赖于任何他们还未熟练应用的技术。当合适的时机来临时,他们一步一个脚印地完成升级,从而拓宽技术支持的范围(将新的技术纳入架构之中),支持更多的应用。最终的结果是,这个系统能使企业充分并且有效地访问自身服务,而企业的业务也因此受益。

查看英文原文: Casestudy: IP Telephony Integration
译者简介:魏泉,具有多年企业级开发经验,曾担任过博文视点出版公司的技术编辑,是《Spring技术手册》《Spring专业开发指南》的责任编辑。武汉大学 Google Camp 的创建者之一,关注 Web 发展的最新趋势。

收藏

评论

微博

用户头像
发表评论

注册/登录 InfoQ 发表评论