Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。Systemについてはこちら(サイト)を参照してください)、テレフォニー分野の興味深いソリューションに目を向けます。Technologiesは株式非公開のソフトウェア会社で、組織における情報通信の一元管理を行うアプリケーションを提供しています。LiteScapeのアプリケーションは、IPテレフォニーとビジネスアプリケーションおよび、IP電話、モバイル機器、パソコンなどのあらゆるIP機器上の企業データをしっかりと統合します。医療などの複数の垂直産業に渡って実装されてきました。今日における現代的な作業環境の特徴は、電子メール、電話会議、オンライン・プレゼンテーションなどの幅広い情報伝達媒体があることです。それぞれに固有のユーザーインターフェース、起動方法などがあります。LiteScapeのソフトウェア・アプリケーションはそれらすべてをまとめ、使い方を簡単にするとともに、今までばらばらだったデータや機器を強力に統合することを可能にします。.NET実装のアーキテクチャ面の概要に触れ、WebEX/LiveMeetingと電話との統合、Java/.NET統合の相互運用性、同じマシンにインストールされたシステム間の通信におけるHTTP通信とIPC通信の比較といったプロジェクトの興味深い技術的側面をいくつかクローズアップしながら、最後にプロジェクトから学んだ総括的な教訓について説明します。端末相互間のビジネス・ソリューションの提供者であるということは、LiteScapeは次のような多様な入出力方法をサポートしなければならないということを意味しています。)関連スポンサーコンテンツこれらのサービスはネットワーク中に散在し、数多くの様々なプロトコルやインターフェースを通してアクセスされます。顧客はIPベースの電話だけでなくウェブやデスクトップクライアントからも、統一された情報にアクセスしたいと望んでいます。実質的に、電話はマルチメディアのエンドポイントとして、ユーザーがPCで行うすべての処理を直接統合したり、補完したりするものになりつつあります。パソコンの代わりに高度な通信機能を提供するインテリジェント装置としての役割も果たしています。電話は拡張されたデスクトップの要素の一部であり、通信作業の簡素化や自動化にコンピュータより適していることが多々あります。そのように利用する例として、ワンタッチで電話会議を開始/参加するアプリケーション、電話をかける前に相手の状態を電話に表示する機能、企業および個人の電話番号案内へのアクセスなどがあります。企業はIP電話ネットワークを利用してメッセージの送信を行っています。メッセージには、建物内の電話が存在する物理的位置に基づいた各従業員の最も近い避難経路の視覚地図を含む、火災警報の警告メッセージなどがあります。アプリケーションをIP電話に拡張することは簡単な作業ではありません。ほとんどの場合、単なる移植ではユーザーインターフェースは使えません。電話上での入力や画面の仕様にうまく合うユーザーインターフェースを提供するには、よく考える必要があります。その作業はアプリケーションを単に電話に“移植する”というよりは、アプリケーションやデータの“状態”を電話に拡大適用するということです。この作業が終了すれば、オンライン会議にログインするのは、電話にカレンダーの会議の項目を表示しながら“会議に参加”ボタンを押すと、コラボレーションセッションの一員として音声会議と(パソコン上の)ウェブ会議の両方に同時に参加する、というように簡単にできるのです。LiteScapeが最初に提案を始めたとき、IP電話統合は本来特有な場所における作業を特徴としていました。予算の制限や特有な業務の性質のためコンピュータが非常に少なく誰もが使うことができないけれど、IP電話なら利用できるというような(小売や製造といった)環境です。(IP電話統合の)結果として、会社はIP電話アプリケーションをタイムカードの入力およびマルチメディア製品に関する教育といった業務に使えるようになりました。法律事務所は、顧客と話すのにかかった時間を直接記録できることを見出しました。あらゆる電話の後に電話から直接時間を顧客記録に残すことが出来るのは、時間と紙の費用を減らすという点で大変有益です。LiteScapeの製品は電話番号案内および時間/請求管理などの分野とアプリケーションレベルの統合を行います。その技術はInfosysやWebExなどの他の企業が、自社の製品やサービスをIP電話レベルに拡張するために利用するプラットフォームになりつつあります。アーキテクチャは3つの主要な構成要素に分類することができます。最初の構成要素は、PBXシステム、IP電話、企業の業務アプリケーション、電話帳などで企業に使われている、サードパーティとの通信基盤コンポーネントです。2番目の構築要素はマルチモード・アプリケーションプラットフォーム(MAP)です。最後となるLiteScapeアーキテクチャの3番目の要素は、MAPを利用してアプリケーションをユーザーのIP電話とデスクトップの両方に拡張するクライアントです。クライアントには、Outlook/Notesのプラグイン、単独のデスクトップクライアント、ウェブブラウザなどがあります。製品が発展してきたのと同じように製品を支える技術も進歩してきました。製品はJavaベースのソリューションとして始まりました。Communicationと統合したいというニーズがあったことから、LiteScapeは.NETを基盤の一部として利用することに着手しなければなりませんでした。メディア・フレームワーク・サーバーなどの製品とのJavaベースの統合、およびIISが搭載されたWindows2003との統合をサポートしています。Studio.NETが使用されました。2003のIISの上にインストールされます。その中に含まれる数多くのWindowsサービスは.NETで書かれており、統合をサポートします。Tomcatが別のポートにインストールされ、必要なJavaコンポーネントをすべて実行します。APIを大いに利用して、ウェブサービスのサポートを行います。両方のウェブサーバーは同じマシン上で並行して動作します。XPおよび2003上でのデスクトップアクセスを提供します。Startクライアントが提供されます。図2:MAPサーバーのコンポーネント図2はMAPサーバーの可動部分を示しています。.NETで書かれたWindowsサービスは、OnCastの電話帳モジュールなどの機能を提供します。TomcatサービスおよびJavaランナブルはSIPゲートウェイなどの機能を提供します。Axisを使用してサーブレットとしてデプロイされます。最後に、Javaと.NETにまたがる、OnCastプレゼンスやコンピュータ/テレフォニー統合(CTI)モジュールなどのいくつかのモジュールがあります。アーキテクチャそのものの後に、システム面で次に目につくのは多様な技術プロトコルです。図2に示すように、それらはすべて一体となって統一された通信エクスペリエンスをユーザーに提供します。Outlookなどのデスクトップアプリケーションとの情報のやり取りに加えて、MAPサーバーからのメッセージを表示します。ネットワーク会議などの通信機能を円滑に進めるためにウェブブラウザやWebExなどのサードパーティのアプリケーションを起動することもあります。MAPサーバーと通信を行います。このような通信は実行中の作業に応じた様々なプロトコルを通して行われます。リアルタイム通信では、SIPのようなプロトコルが最も効率的です。認証や個人化といった他の作業はウェブサービスによって処理されます。Directory、OpenLDAPのような電話番号案内などのサードパーティの構成要素へ、クライアントがアクセスできるようにします。Manager、AsteriskなどのサードパーティのIP-PBX上で動作するIP電話ネットワークの機能を初期化することもあります。電話番号案内への通信はプラットフォームごとに固有のプロトコルを通して処理されます。API、そしてSNMPといったプロトコル/トランスポート技術が大体使われています。LiveMeetingを利用した会議サポートがあります。人々の多くはネットワーク会議の開始や参加といった作業が、様々なURL、番号によるダイヤル、入力すべきアクセスコードでいらいらさせられることを知っています。LiteScapeはこれらのすべての作業を自動化するので、電話から開始できるばかりではなく、ユーザーのデスクトップのWebEX/LiveMeetingと統合することもできます。ユーザーがWebEX/LiveMeetingセッションに招待されているといった典型的な使用事例の場合、2つの方法のいずれかで進めることができます。最初の方法として、ユーザーは自分のカレンダーに手入力でその招待を追加できます。(2つ目の方法として、)Exchangeのように電子メールサーバーとして招待メールを監視するOnCastサーバー・エクステンションに招待メールを受け取らせることによって、自動的にユーザーのMS-Outlook/Exchangeカレンダーに招待を追加することもできます。この時点で、統合プロセスを進める準備が整いました。MAPサーバーは(IP電話プロトコルを利用して)WebEx/LiveMeetingのセッションを知らせるOnCastマルチメディアメッセージ(OCM)をユーザーの電話に送ることができます。OCM構造はXMLで記述されたペイロード文書と関連コンテンツの集まりで、LiteScapeプラットフォームにおいて、デスクトップエージェント、電話、IP/アナログスピーカーなどの様々な通信端末間に、マルチメディア・コンテンツを双方向で配信するのに必要です。PDFファイルなどのための複合コンテンツハンドラなどがあります。OCMは、必要な属性、プロパティおよび実行すべきマルチモーダルイベント処理の必要条件を参照するXMLベースの”ペイロード“文書を含んでいます。CiscoやAvayaタイプのIP電話で共同セッションに参加するユーザーがいるオーガナイズドセッションのためのOCMペイロードスニペットを次に示します。</LSBC>OCMには、電話会議を要求しているユーザーの埋め込み/リンクされた画像、あるいはPowerPointプレゼンテーションなどのコンテンツに対する、会議に関するコールや音声クリップ(埋め込みまたはリンク)に関連付けられた添付またはリンクなどを含めることができます。ユーザーはそれから電話会議に参加するか自分の電話で選択できます。Meetingセッションの開始要求を受け取ります。PBXに通知し、また、デスクトップのOnCastクライアントと通信を行います。このクライアントは自動でWebEXセッションをユーザーのデスクトップ上で起動し、ユーザーを会議セッションにログインさせます。このような処理の流れを図4に示します。Mapプラットフォーム・サーバーのコンポーネントを示しています。.NET技術を十分に利用しています。.NETで書かれ、インストールされたIISインスタンスと通信しながらWindowsサービスとして動作します。SIGゲートウェイなどの他のコンポーネントはJavaで書かれています。最後に、MAPプラットフォームにはOnCastプレゼンスおよびコンピュータ・テレフォニー統合モジュールのようなJavaと.NETをフル活用した混合コンポーネントもあります。.NET技術を両方利用することを選びました。第一に、Windowsで統合されたデスクトップクライアントを実行したいという顧客の強い要望がありました。顧客はまたOutlookアドレスブックなどのプラットフォーム特有のデータへのアクセスも希望していましたが、これはMicrosoftのMAPIインターフェースを利用することで可能でした。最後に、シングルサインオンのセキュリティを提供してほしいという要求がありました。利用することでWindows認証とドメインセキュリティを使うことができました。メディア・フレームワーク・サーバーなどのJavaサービスにアクセスする必要性に加えて、これらすべてのニーズがあったのです。最善のソリューションによって、デプロイメントもまた簡単になりました。LiteScapeの顧客の多くは既にMicrosoftの技術を活用していたため、IISは他の目的のためにあらかじめインストールされていました。このような混合アーキテクチャをサポートするためにはプラットフォームにとらわれない通信を行うことが必要でした。.NETおよびJavaコンポーネントは多くの共通機能のためにXMLベースのウェブサービスを提供しています。TCPやSIPベースのプロトコルも使われています。.NETとJavaの統合ライブラリのようなオプションを選ばなかったのには多くの理由がありました。LiteScapeのアーキテクトはそういった技術についてあらかじめ十分な経験を積んでいませんでした。リアルタイム通信を実装しようとした時に障害になるかもしれないことを心配していました。重要なことは、LiteScapeはサードパーティの統合ライブラリの制限に縛られることを望みませんでした。積み上げてきた主要な技術の開発が続けられなくなったり、機能面で不十分なものになる事態を避けたかったのです。LiteScapeのアーキテクトは、一つの技術ですべてのニーズを満たそうとするのではなく共存の世界で働いています。APIとそれをサポートする機器を使うのは理にかなったことなのです。Directoryなど他のアプリケーションとの統合は.NETを使ってもっと簡単にプログラムされます。パズルの最後のピースはこのような様々な技術をお互いに結合することです。様々なピースが複数の技術の上で相互運用される例としてCTIエンジンが呼び出しを受け取る場合が挙げられます。CTIエンジンはあらゆる関係者にイベントを発行しますが、そのうちの一つにJavaで書かれたSIGゲートウェイがあります。典型的な実務の事例として、電話が社内にかかってきた時、かけてきた人に関する名簿やビジネス情報とともに利用可能な基本情報を補う場合があります。Directoryコンポーネントにリクエストを行います。クライアントに通知しますが、その際に電話をかけてきた人に関する付加情報をユーザーに示すことができます。ドリルダウン3:OnCastクライアントとOutlook/Notesプラグインによる通信の単純化LiteScapeが提供する、統一された通信エクスペリエンスというタイプの技術の具体例はOutlook統合プラグインです。その機能の中で特徴的なのは、電子メールの名前の上で右クリックすると電話または電話会議を開始できることです。技術的には、多くの手順を実行することによって、この機能が働いています。.NETで書かれており、.NETベースのOnCast通信レイヤー(CIL)もインストールされます。CILはアプリケーションに依存しないモジュールで、連絡相手のローディング、ユーザーの状態(プレゼンス)の更新、P2Pメッセージ送信、そしてSIPメッセージ送信などのサービスを提供します。CILコマンドのいずれかを受け取ります。ソケットサーバーとして起動し、HTTP経由で来るリクエスト(ダイヤル、会議、放送、コラボレーションおよび遠隔呼制御リクエスト)を処理します。これによって、コマンドは次のような簡単なURLで発行できるようになります。CILライブラリでHTTPCommandオブジェクトに変換されます。CILクライアントがMAPサーバーと通信を行い、呼び出しの開始などの操作を実行します。プロトコルの観点から見ると、リクエストの処理の流れはHTTPとして始まり、.NETの内部のメソッドコールに変換され、そしてウェブサービスリクエストとして電線上に送られ、最後にMAPサーバーでIP-PBXリクエストとして実行され、呼び出しが開始されます。.NET統合ではなくHTTPプロトコルがクライアント上で使われたのかということです。このような設計を行った理由には2つの側面がありました。Swingなどの技術で書かれた他のクライアントが同じ機能にアクセスできます。第二に、LiteScapeは経験上、Outlookのプラグインがクラッシュしやすいことを知っています。CILサービスが止まることはなくなるでしょう。Outlookは単純に再起動することができ、ユーザーが再び通信処理を試みることができます。学んだ教訓/ベストプラクティスLiteScapeサーバーとクライアントプラットフォームのコンポーネントの開発を通して、LiteScapeの技術者は多くの価値ある教訓を得ました。後になっても統合が簡単なものであるために、各プラットフォームのコンポーネントはできるだけプラットフォームに依存しないようにするべきです。.NETにも同じライブラリを用意しなければなりません。サードパーティの技術を検討するときも、同様のプロセスを踏むことになります。サードパーティのコンポーネントに不安があるなら、トランスポートレイヤーで統合します。その際には、上に述べたようなプラットフォームに依存しないプロトコルを利用します。ラインフィード、バッファリング、ユニコード文字列の変換など、プラットフォームに特有の通信特性に細心の注意を払います。.NET分野のコミュニティおよび利用可能性はJavaより小さいのですが、受話器をとれば800箇所の技術サポートに電話できることは計り知れない価値があります。JavaおよびJava関連ライブラリの問題の原因を突き止めるのには検索知識やメーリングリストが必要ですが、それに対して、Microsoftのサポート担当者はIISのようなコンポーネントの問題を多くの場合正確に突き止めることができます。IP電話は変化の速い技術であり、完全にサポートするには練り上げられた最善のストラテジーが必要です。(ワンサイズですべてカバーするような)フリーサイズ式のアプローチではすべての顧客のニーズを満たすことはできません。自分のニーズにあったプロトコルや技術を使用します。プロトコルのために電子メールの待ち時間が5~10秒増えても支障はありません。ミリ秒の速度が問題になる電話の通話ではそうはいきません。今後の方向性LiteScapeは自社で熟成させた技術を引き続き使っていこうとしています。Meetingなどの通信技術の強化には絶えずサポートを加える必要があります。アプリケーション分野に統合を広げていくことに目を向けています。技術的な面では、Monoライブラリを利用して.NETベースのサーバーコンポーネントをLinuxベースのサーバーにデプロイする可能性を探っています。要約すると、LiteScapeは自分達が使ってきた技術がモルモットにならないように努力を続けてきました。一つ一つの技術を十分に成長させ、自分達がまだ安心して使うことができない技術に顧客が頼るようなことはさせませんでした。サポートするアプリケーションをさらに拡大する時が来た時に、徐々に転換をはかってきました。その結果が、LiteScapeのサービスを企業が効率的かつ効果的にアクセスしながらも、LiteScapeのビジネスに価値をもたらすことができるシステムとなっています。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員��して、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。