BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル 事例研究:IPテレフォニー統合

事例研究:IPテレフォニー統合

序論

2回目となるInfoQの事例研究では(第1回のBrasilian National Healthcare Systemについてはこちら(サイト)を参照してください)、テレフォニー分野の興味深いソリューションに目を向けます。LiteScape Technologiesは株式非公開のソフトウェア会社で、組織における情報通信の一元管理を行うアプリケーションを提供しています。LiteScapeのアプリケーションは、IPテレフォニーとビジネスアプリケーションおよび、IP電話、モバイル機器、パソコンなどのあらゆるIP機器上の企業データをしっかりと統合します。LiteScapeのソリューションは、小売販売、製造、専門的サービス、金融業、公共分野および医療などの複数の垂直産業に渡って実装されてきました。今日における現代的な作業環境の特徴は、電子メール、電話会議、オンライン・プレゼンテーションなどの幅広い情報伝達媒体があることです。そしてそれぞれに固有のユーザーインターフェース、起動方法などがあります。LiteScapeのソフトウェア・アプリケーションはそれらすべてをまとめ、使い方を簡単にするとともに、今までばらばらだったデータや機器を強力に統合することを可能にします。

本事例研究では、LiteScapeのソフトウェアソリューションの内容に注目し、まず要求事項から始め、Javaおよび .NET実装のアーキテクチャ面の概要に触れ、WebEX/LiveMeetingと電話との統合、Java/.NET統合の相互運用性、同じマシンにインストールされたシステム間の通信におけるHTTP通信とIPC通信の比較といったプロジェクトの興味深い技術的側面をいくつかクローズアップしながら、最後にプロジェクトから学んだ総括的な教訓について説明します。

ドメイン分析

端末相互間のビジネス・ソリューションの提供者であるということは、LiteScapeは次のような多様な入出力方法をサポートしなければならないということを意味しています。

  • Outlook/Exchange
  • 社外のコラボレーション(WebEx、Live Meetingなど)
  • CRMソリューション(Salesforce.com、MS-CRMなど)
  • 電話番号案内(LDAP / Active Directory )
  • プレゼンスサーバー(MS-LCS、AOL)
  • 通信基盤 (IP-PBX、MS-LCS、デスクの電話 )

これらのサービスはネットワーク中に散在し、数多くの様々なプロトコルやインターフェースを通してアクセスされます。そして顧客はIPベースの電話だけでなくウェブやデスクトップクライアントからも、統一された情報にアクセスしたいと望んでいます。

実質的に、電話はマルチメディアのエンドポイントとして、ユーザーがPCで行うすべての処理を直接統合したり、補完したりするものになりつつあります。また、パソコンの代わりに高度な通信機能を提供するインテリジェント装置としての役割も果たしています。電話は拡張されたデスクトップの要素の一部であり、通信作業の簡素化や自動化にコンピュータより適していることが多々あります。そのように利用する例として、ワンタッチで電話会議を開始/参加するアプリケーション、電話をかける前に相手の状態を電話に表示する機能、企業および個人の電話番号案内へのアクセスなどがあります。また、企業はIP電話ネットワークを利用してメッセージの送信を行っています。メッセージには、建物内の電話が存在する物理的位置に基づいた各従業員の最も近い避難経路の視覚地図を含む、火災警報の警告メッセージなどがあります。

アプリケーションをIP電話に拡張することは簡単な作業ではありません。ほとんどの場合、単なる移植ではユーザーインターフェースは使えません。電話上での入力や画面の仕様にうまく合うユーザーインターフェースを提供するには、よく考える必要があります。その作業はアプリケーションを単に電話に“移植する”というよりは、アプリケーションやデータの“状態”を電話に拡大適用するということです。しかし一旦この作業が終了すれば、オンライン会議にログインするのは、電話にカレンダーの会議の項目を表示しながら“会議に参加”ボタンを押すと、コラボレーションセッションの一員として音声会議と(パソコン上の)ウェブ会議の両方に同時に参加する、というように簡単にできるのです。

LiteScapeが最初に提案を始めたとき、IP電話統合は本来特有な場所における作業を特徴としていました。例えば、予算の制限や特有な業務の性質のためコンピュータが非常に少なく誰もが使うことができないけれど、IP電話なら利用できるというような(小売や製造といった)環境です。(IP電話統合の)結果として、会社はIP電話アプリケーションをタイムカードの入力およびマルチメディア製品に関する教育といった業務に使えるようになりました。また、法律事務所は、顧客と話すのにかかった時間を直接記録できることを見出しました。あらゆる電話の後に電話から直接時間を顧客記録に残すことが出来るのは、時間と紙の費用を減らすという点で大変有益です。LiteScapeの製品は電話番号案内および時間/請求管理などの分野とアプリケーションレベルの統合を行います。また、その技術はInfosysやWebExなどの他の企業が、自社の製品やサービスをIP電話レベルに拡張するために利用するプラットフォームになりつつあります。

ソリューション概要

LiteScape のアーキテクチャは3つの主要な構成要素に分類することができます。最初の構成要素は、PBXシステム、IP電話、企業の業務アプリケーション、電話帳などで企業に使われている、サードパーティとの通信基盤コンポーネントです。2番目の構築要素はマルチモード・アプリケーションプラットフォーム(MAP)です。最後となるLiteScapeアーキテクチャの3番目の要素は、MAPを利用してアプリケーションをユーザーのIP電話とデスクトップの両方に拡張するクライアントです。クライアントには、Outlook/Notesのプラグイン、単独のデスクトップクライアント、ウェブブラウザなどがあります。

図1:LiteScapeアークテクチャの概要

LiteScape の製品が発展してきたのと同じように製品を支える技術も進歩してきました。製品はJavaベースのソリューションとして始まりました。しかしながら、Microsoft Unified Communicationと統合したいというニーズがあったことから、LiteScapeは.NETを基盤の一部として利用することに着手しなければなりませんでした。今日ではJava と.NETの両方がJava Web Start や.NETクライアントとともにバックエンドおよびフロントエンドとして使われ、SunのJava メディア・フレームワーク・サーバーなどの製品とのJavaベースの統合、およびIISが搭載されたWindows2003との統合をサポートしています。

Javaでの開発にはInteliJ IDEが、.NETではVisual Studio.NETが使用されました。LiteScapeサーバーはWindows 2003のIISの上にインストールされます。その中に含まれる数多くのWindowsサービスは.NETで書かれており、統合をサポートします。同時にApache Tomcatが別のポートにインストールされ、必要なJavaコンポーネントをすべて実行します。サーバーのJavaの部分はApache Axis などのAPIを大いに利用して、ウェブサービスのサポートを行います。両方のウェブサーバーは同じマシン上で並行して動作します。相手のクライアント側では、.NETベースのOnCastクライアントがWindows XPおよび2003上でのデスクトップアクセスを提供します。Linuxのサポートを必要とする企業には、Java Swing Web Startクライアントが提供されます。

図2:MAPサーバーのコンポーネント

図2はMAPサーバーの可動部分を示しています。IISおよび .NETで書かれたWindowsサービスは、OnCastの電話帳モジュールなどの機能を提供します。TomcatサービスおよびJavaランナブルはSIPゲートウェイなどの機能を提供します。JavaベースのウェブサービスはApache Axisを使用してサーブレットとしてデプロイされます。そして最後に、Javaと.NETにまたがる、OnCastプレゼンスやコンピュータ/テレフォニー統合(CTI)モジュールなどのいくつかのモジュールがあります。

アーキテクチャそのものの後に、システム面で次に目につくのは多様な技術プロトコルです。図2に示すように、それらはすべて一体となって統一された通信エクスペリエンスをユーザーに提供します。

図3:使用された通信プロトコルの概要

LiteScape OnCastクライアント(OCクライアント)はデスクトップアプリケーションで、アドレス帳やMicrosoft Outlookなどのデスクトップアプリケーションとの情報のやり取りに加えて、MAPサーバーからのメッセージを表示します。また、ネットワーク会議などの通信機能を円滑に進めるためにウェブブラウザやWebExなどのサードパーティのアプリケーションを起動することもあります。OnCastクライアントは通信レイヤー(OC CIL)を使用してLiteScape MAPサーバーと通信を行います。このような通信は実行中の作業に応じた様々なプロトコルを通して行われます。リアルタイム通信では、SIPのようなプロトコルが最も効率的です。認証や個人化といった他の作業はウェブサービスによって処理されます。MAPサービスは、Microsoft Active Directory、OpenLDAPのような電話番号案内などのサードパーティの構成要素へ、クライアントがアクセスできるようにします。また、MAPサーバーは、CiscoのCallManager、AvayaのCommunication Manager、AsteriskなどのサードパーティのIP-PBX上で動作するIP電話ネットワークの機能を初期化することもあります。電話番号案内への通信はプラットフォームごとに固有のプロトコルを通して処理されます。 IP-PBX通信には、バックエンドシステムに応じて、XML、HTTP、Java Telephone API、そしてSNMPといったプロトコル/トランスポート技術が大体使われています。

ドリルダウン1:WebEx / LiveMeeting との統合

LiteScapeが提供する、アプリケーション/IP電話統合タイプの一例として、WebEx/Microsoft LiveMeetingを利用した会議サポートがあります。人々の多くはネットワーク会議の開始や参加といった作業が、様々なURL、番号によるダイヤル、入力すべきアクセスコードでいらいらさせられることを知っています。LiteScapeはこれらのすべての作業を自動化するので、電話から開始できるばかりではなく、ユーザーのデスクトップのWebEX/LiveMeetingと統合することもできます。

ユーザーがWebEX/LiveMeetingセッションに招待されているといった典型的な使用事例の場合、2つの方法のいずれかで進めることができます。最初の方法として、ユーザーは自分のカレンダーに手入力でその招待を追加できます。また、(2つ目の方法として、)Exchangeのように電子メールサーバーとして招待メールを監視するOnCastサーバー・エクステンションに招待メールを受け取らせることによって、自動的にユーザーのMS-Outlook/Exchangeカレンダーに招待を追加することもできます。この時点で、統合プロセスを進める準備が整いました。

会議の開始がスケジュールされる前に、OnCast MAPサーバーは(IP電話プロトコルを利用して)WebEx/LiveMeetingのセッションを知らせるOnCastマルチメディアメッセージ(OCM)をユーザーの電話に送ることができます。OCM構造はXMLで記述されたペイロード文書と関連コンテンツの集まりで、LiteScapeプラットフォームにおいて、デスクトップエージェント、電話、IP/アナログスピーカーなどの様々な通信端末間に、マルチメディア・コンテンツを双方向で配信するのに必要です。

OCM構造には、文字、音声、画像、声など、基本的なコンテンツフォーマットのサポートや、コラボレーション、RSSフィード、株価情報、多肢選択調査、MS PowerPointプレゼンテーション、Adobe PDFファイルなどのための複合コンテンツハンドラなどがあります。

LiteScape OCMは、必要な属性、プロパティおよび実行すべきマルチモーダルイベント処理の必要条件を参照するXMLベースの”ペイロード“文書を含んでいます。

CiscoやAvayaタイプのIP電話で共同セッションに参加するユーザーがいるオーガナイズドセッションのためのOCMペイロードスニペットを次に示します。

<LSBC>
<Organizer>
<UserID>John.Coyle</UserID>
<Extension>20353</Extension>
<MainPhone>20353</MainPhone>
<LDAPDN>CN=John Coyle,CN=Users,DC=litescape,DC=local|AD</LDAPDN>
<ServerLDAPID />
<ProviderID>IP-PBX 1</ProviderID>
<ProviderSource>IP-PBX 1</ProviderSource>
<OnCastBCLocationName>Headquarters</OnCastBCLocationName>
<Prefix />
<IPAddress>10.12.2.52</IPAddress>
<Email />
<DeviceType>Cisco 7961</DeviceType>
<Key>20353</Key>
</Organizer>
<EmergencyRingTone />
<NormalRingTone />
<Audio>
<Type>NONE</Type>
<Streaming>MULTICAST</Streaming>
</Audio>
<Video>
<FileName />
</Video>

<Presentation>
<Count>0</Count>
</Presentation>
<Survey />
<Stocks />
<RSSFeeds />
<Workflow />
<image>
<X1>170</X1>
<Y1>107</Y1>
<X2>195</X2>
<Y2>132</Y2>
<URL>http://10.2.0.145:80/MW/HandleEvent.aspx?scannedItemSize=26</URL>
<Name>25|BLUE+RIBBON|Dark+Blue|01FFAA06000104E0</Name>
</image>

<Invitees>
<Invitee>
<UserID>Samira Kashani</UserID>
<Extension>20365</Extension>
<MainPhone>20365</MainPhone>
<LDAPDN>CN=Samira Kashani,CN=Users,DC=litescape,DC=local|AD</LDAPDN>
<ServerLDAPID />
<ProviderID>IP-PBX 1</ProviderID>
<ProviderSource>IP-PBX 1</ProviderSource>
<OnCastBCLocationName>Headquarters</OnCastBCLocationName>
<Prefix />
<IPAddress>10.11.2.4</IPAddress>
<Email />
<DeviceType>Cisco IP Communicator</DeviceType>
<Key>20365</Key>
</Invitee>
<Invitee>
...
</Invitee>
<Invitee>
...
</Invitee>
</Invitees>

<OCMFile>ConferenceTemplates\WebEx.ocm</OCMFile>
<Conference>
<PhoneNumber>18665551212</PhoneNumber>
<PassCode />
</Conference>
<Action>Dial</Action>

<shortcutURL>http://10.12.0.5:80/oncastdirdialer/AD/createShortcut.aspx?key=20353</shortcutURL>
<Priority />
<WebExMeetingID />
<HostMeeting>False</HostMeeting>
<SendToOrganizer>True</SendToOrganizer>
<SessionID>58c5cdcb-b1be-4dab-9bcd-7d9ea3a55465</SessionID>
<InviteesGroup />
<SessionEvents>
<Event>RunBCPayLoad</Event>
</SessionEvents>
</LSBC>

OCMには、電話会議を要求しているユーザーの埋め込み/リンクされた画像、あるいはPowerPointプレゼンテーションなどのコンテンツに対する、会議に関するコールや音声クリップ(埋め込みまたはリンク)に関連付けられた添付またはリンクなどを含めることができます。ユーザーはそれから電話会議に参加するか自分の電話で選択できます。この時点で、MAPサーバーはWebEx/Live Meetingセッションの開始要求を受け取ります。MAPサーバーはWebEX/LiveMeeting会議の呼び出しを始めるようにIP PBXに通知し、また、デスクトップのOnCastクライアントと通信を行います。このクライアントは自動でWebEXセッションをユーザーのデスクトップ上で起動し、ユーザーを会議セッションにログインさせます。このような処理の流れを図4に示します。

図4:IP電話からWebEXセッションを起動する処理手続き

ドリルダウン2:Javaおよび .NET

図2はLiteScape Mapプラットフォーム・サーバーのコンポーネントを示しています。MAPプラットフォーム・サーバーはJavaおよび .NET技術を十分に利用しています。OnCast 電話帳といったコンポーネントは .NETで書かれ、インストールされたIISインスタンスと通信しながらWindowsサービスとして動作します。SIGゲートウェイなどの他のコンポーネントはJavaで書かれています。最後に、MAPプラットフォームにはOnCastプレゼンスおよびコンピュータ・テレフォニー統合モジュールのようなJavaと.NETをフル活用した混合コンポーネントもあります。

LiteScapeはいくつかの理由からJavaと .NET技術を両方利用することを選びました。第一に、Windowsで統合されたデスクトップクライアントを実行したいという顧客の強い要望がありました。顧客はまたOutlookアドレスブックなどのプラットフォーム特有のデータへのアクセスも希望していましたが、これはMicrosoftのMAPIインターフェースを利用することで可能でした。最後に、シングルサインオンのセキュリティを提供してほしいという要求がありました。LiteScapeは、.NET を利用することでWindows認証とドメインセキュリティを使うことができました。SunのJava メディア・フレームワーク・サーバーなどのJavaサービスにアクセスする必要性に加えて、これらすべてのニーズがあったのです。最善のソリューションによって、デプロイメントもまた簡単になりました。LiteScapeの顧客の多くは既にMicrosoftの技術を活用していたため、IISは他の目的のためにあらかじめインストールされていました。

このような混合アーキテクチャをサポートするためにはプラットフォームにとらわれない通信を行うことが必要でした。MAPサーバーで動作する .NETおよびJavaコンポーネントは多くの共通機能のためにXMLベースのウェブサービスを提供しています。また、TCPやSIPベースのプロトコルも使われています。

JNIおよび他の .NETとJavaの統合ライブラリのようなオプションを選ばなかったのには多くの理由がありました。LiteScapeのアーキテクトはそういった技術についてあらかじめ十分な経験を積んでいませんでした。また、リアルタイム通信を実装しようとした時に障害になるかもしれないことを心配していました。最も重要なことは、LiteScapeはサードパーティの統合ライブラリの制限に縛られることを望みませんでした。積み上げてきた主要な技術の開発が続けられなくなったり、機能面で不十分なものになる事態を避けたかったのです。

LiteScapeのアーキテクトは、一つの技術ですべてのニーズを満たそうとするのではなく共存の世界で働いています。例えば、呼制御のような機能を提供する際に、Java Telephone APIとそれをサポートする機器を使うのは理にかなったことなのです。ExchangeやActive Directoryなど他のアプリケーションとの統合は.NETを使ってもっと簡単にプログラムされます。パズルの最後のピースはこのような様々な技術をお互いに結合することです。

様々なピースが複数の技術の上で相互運用される例としてCTIエンジンが呼び出しを受け取る場合が挙げられます。CTIエンジンはあらゆる関係者にイベントを発行しますが、そのうちの一つにJavaで書かれたSIGゲートウェイがあります。典型的な実務の事例として、電話が社内にかかってきた時、かけてきた人に関する名簿やビジネス情報とともに利用可能な基本情報を補う場合があります。この機能を実行するために、SIPゲートウェイはウェブサービスを経由して、.NETベースのOnCast Directoryコンポーネントにリクエストを行います。追加情報を受け取った後、SIPゲートウェイは、次にSIP/CSTA経由でOnCast クライアントに通知しますが、その際に電話をかけてきた人に関する付加情報をユーザーに示すことができます。

ドリルダウン3:OnCastクライアントとOutlook/Notesプラグインによる通信の単純化

LiteScapeが提供する、統一された通信エクスペリエンスというタイプの技術の具体例はOutlook統合プラグインです。その機能の中で特徴的なのは、電子メールの名前の上で右クリックすると電話または電話会議を開始できることです。


技術的には、多くの手順を実行することによって、この機能が働いています。

Outlookプラグインは .NETで書かれており、.NETベースのOnCast通信レイヤー(CIL)もインストールされます。CILはアプリケーションに依存しないモジュールで、連絡相手のローディング、ユーザーの状態(プレゼンス)の更新、P2Pメッセージ送信、そしてSIPメッセージ送信などのサービスを提供します。OnCast CILには別のスレッド上にHTTPListenerがあり、TCP(ローカルIP 127.0.0.1)ポートをリッスンして主なOC CILコマンドのいずれかを受け取ります。ソケットサーバーとして起動し、HTTP経由で来るリクエスト(ダイヤル、会議、放送、コラボレーションおよび遠隔呼制御リクエスト)を処理します。これによって、コマンドは次のような簡単なURLで発行できるようになります。

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

図5:HTTPListenerからOnCast 電話帳までのコマンド例の流れ

図5に示されるように、httpコールは、.NETベースのOnCast CILライブラリでHTTPCommandオブジェクトに変換されます。それは次にCILコマンドをトリガーすることができ、それによってOC CILクライアントがMAPサーバーと通信を行い、呼び出しの開始などの操作を実行します。プロトコルの観点から見ると、リクエストの処理の流れはHTTPとして始まり、.NETの内部のメソッドコールに変換され、そしてウェブサービスリクエストとして電線上に送られ、最後にMAPサーバーでIP-PBXリクエストとして実行され、呼び出しが開始されます。

この統合方法についての明白な疑問は、なぜOnCastクライアントまたはOutlookプラグインとOnCast CIL通信ライブラリの間に、純粋な .NET統合ではなくHTTPプロトコルがクライアント上で使われたのかということです。このような設計を行った理由には2つの側面がありました。第一に、HTTPベースのAPIを提供すれば、Java Swingなどの技術で書かれた他のクライアントが同じ機能にアクセスできます。第二に、LiteScapeは経験上、Outlookのプラグインがクラッシュしやすいことを知っています。統合をできるだけ弱くしておけば、プラグインのクラッシュによってクライアントコンピュータで動作するOnCast CILサービスが止まることはなくなるでしょう。Outlookは単純に再起動することができ、ユーザーが再び通信処理を試みることができます。

学んだ教訓/ベストプラクティス

LiteScapeサーバーとクライアントプラットフォームのコンポーネントの開発を通して、LiteScapeの技術者は多くの価値ある教訓を得ました。

  • 後になっても統合が簡単なものであるために、各プラットフォームのコンポーネントはできるだけプラットフォームに依存しないようにするべきです。例えば、Javaで暗号化ライブラリを使ったら、LiteScapeは .NETにも同じライブラリを用意しなければなりません。サードパーティの技術を検討するときも、同様のプロセスを踏むことになります。
  • サードパーティのコンポーネントに不安があるなら、トランスポートレイヤーで統合します。その際には、上に述べたようなプラットフォームに依存しないプロトコルを利用します。
  • ラインフィード、バッファリング、ユニコード文字列の変換など、プラットフォームに特有の通信特性に細心の注意を払います。
  •  .NET分野のコミュニティおよび利用可能性はJavaより小さいのですが、受話器をとれば800箇所の技術サポートに電話できることは計り知れない価値があります。JavaおよびJava関連ライブラリの問題の原因を突き止めるのには検索知識やメーリングリストが必要ですが、それに対して、Microsoftのサポート担当者はIISのようなコンポーネントの問題を多くの場合正確に突き止めることができます。
  • IP電話は変化の速い技術であり、完全にサポートするには練り上げられた最善のストラテジーが必要です。(ワンサイズですべてカバーするような)フリーサイズ式のアプローチではすべての顧客のニーズを満たすことはできません。
  • 自分のニーズにあったプロトコルや技術を使用します。プロトコルのために電子メールの待ち時間が5~10秒増えても支障はありません。しかし、ミリ秒の速度が問題になる電話の通話ではそうはいきません。

今後の方向性

LiteScapeは自社で熟成させた技術を引き続き使っていこうとしています。IP電話、VoIP(ボイス・オーバー・IP)およびコラボレーション分野は性質が変化していくため、新しい型の電話およびWebEXやMicrosoft Live Meetingなどの通信技術の強化には絶えずサポートを加える必要があります。LiteScapeはまた、CRM、在庫管理、人的資源などのアプリケーション分野に統合を広げていくことに目を向けています。技術的な面では、Monoライブラリを利用して.NETベースのサーバーコンポーネントをLinuxベースのサーバーにデプロイする可能性を探っています。

要約すると、LiteScapeは自分達が使ってきた技術がモルモットにならないように努力を続けてきました。一つ一つの技術を十分に成長させ、自分達がまだ安心して使うことができない技術に顧客が頼るようなことはさせませんでした。そしてサポートするアプリケーションをさらに拡大する時が来た時に、徐々に転換をはかってきました。その結果が、LiteScapeのサービスを企業が効率的かつ効果的にアクセスしながらも、LiteScapeのビジネスに価値をもたらすことができるシステムとなっています。

原文はこちらです:http://www.infoq.com/articles/litescape-ip-telephone-casestudy
(このArticleは2006年11月30日にリリースされました)

この記事に星をつける

おすすめ度
スタイル

BT