Typemock: その過去・現在・未来
Eli Lopian氏率いるTypemock社の過去・現在・未来について、インタビュー形式にて記します。
作者 Dilip Krishnan, 翻訳者 編集部 投稿日 2008年11月20日 午前6時2分
Jack Van Hoof氏が投稿(リンク)でCEPとEDAを比較し、両者のSOAとの関係を対比している。氏は次のように述べている。
CEP(Complex Event Processing=複合イベント処理)は一定の時間フレーム内で複数のメッセージを相互に関連づけます。EDAはビジネスイベント的見地から情報システムをモデル化するアーキテクチャ的アプローチです。 EDAとSOAとの違いは、その焦点にあります。SOAではモデルの中心にサービスがきますが、EDAの場合はビジネスイベントです。SOAアプローチでは結果的に同期通信の方法がもたらされ、EDAアプローチでは非同期通信の方法がもたらされる傾向にあります。
市場がEDAを理解していないと考えるVan Hoof氏(リンク)は、CEPとEDAとの根本的な相違を説明し、CEPはツールで、EDAはアーキテクチャであると述べている。
CEPは定義上、ビジネスイベントに関係しているわけではありません。CEPはメッセージストリームを処理するテクニックです。こうしたメッセージがビジネスイベントを表す必要はないのです。ビジネスイベントとは、企業が予め定められた方法で反応すると計画したところで発生する何か(状態の変化)です。ビジネスイベントはメッセージで表現されますが、すべてのメッセージがビジネスイベントを表現しているわけではありません。CEPはメッセージに関係しており、EDAはビジネスイベントに関係しています。CEPはEDAの実装に使用できます。「EDAはビジネスレベルにおけるCEPである」と言えるかもしれません。
Van Hoof氏の投稿に対する返答として、Progress ApamaのGiles Nelson氏がSOA、EDA、CEPの関係を重要ポイントとともに詳述している(リンク)。Joe McKendrick氏も、「Why 'Event Driven Architecture' is more than Complex Event Processing」(リンク)(「イベント駆動型アーキテクチャ」が複合イベント処理を上回る理由)と題した自身の投稿で同じような見解を表明している。Udi Dahan氏(リンク)も同様で、現金注文のプロセスを示した見事な例を用いて(リンク),、現実世界のビジネス問題でこれらの概念がいかにして一緒に機能するかを説明している。Dahan氏は次のように述べて、自身の見解を要約している。
CEPは手腕を問われるエンジニアリング分野であり、状況によってはその周辺の技術的リスクの管理がプロジェクトの成功に必要な場合もあり、SOA/EDAの傘の下で使われれば実に威力を発揮しますが、CEPそのものだけを抜き出して、アーキテクチャの最上位レベルで使用すべきではありません。
Van Hoof氏は「SOAを含め、現在のビジネスアプリケーションの考察方法を、EDAが確実かつ根本的に変えると思います」と述べ、EDAの重要性を強調しながら投稿(リンク)を締めくくっている。
この議論については、過去にもアーキテクチャ的見地から取り上げた(参考記事)。CEP、SOA、EDAがいかに相互に関連するかについてはあちこちで混乱があるように思われ、その主な原因はベンダー(リンク)である。こうした技術がどのように企業に導入されているかについて、全体像をみるのも興味深い。みなさんの会社ではCEPはどんな役割を担っていて、EDAやSOAイニシアチブにおいてどのように使われているのだろうか。
原文はこちらです:http://www.infoq.com/news/2008/11/cep-eda-soa-relationship
この論文では、仮想化やクラウドサービスの複雑なメリットと実世界における応用を検討します。さらに重要なこととして、Contegixが複雑な問題の解決に仮想化を実装している方法や、仮想化を使うべきではないケースについて詳細を提供します。
Fiberはユーザに試練を課すことなくこの考えを実装する有益な並行性ツールとして、ライブラリが2つあります。まさにこのためのソリューションとしてあるのがNeverBlockライブラリです。私たちはNeverBlockプロジェクトのMohammad A. Ali氏とRevactorライブラリのTony Arcier氏に話を聞きました。
システムの保守容易性や拡張性を確保するためのベスト・プラクティスに関する記事は数多くありますが、この記事では避けた方がいい、いくつかの悪習慣(ワースト・プラクティス)を強調します。
この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。
Agileカンファレンスに「参加者としてだけでなく、発表者として参加しよう」を掲げたチームgoyattomは、サブミッションを提出し、7つのセッションが日本から選択されました。参加者はカンファレンスで各々の発表や、各セッションへの参加、諸外国のエンジニアとの出会い、ステージ上で DearXPを熱演などの様々な思い出を抱えて、無事日本に戻ってきました。
マイクロソフトのRobert Bellが、SilverlightとJavaを使用したインターオペラビリティのシナリオを紹介し、サンプルコードを例にとってアーキテクチャの手引きを提供します。
No comments
返信