BT

オーケストレーション対コレオグラフィー:定義に関する論争

| 作者: Boris Lublinsky フォローする 1 人のフォロワー , 翻訳者 編集部 フォローする 0 人のフォロワー 投稿日 2008年9月5日. 推定読書時間: 5 分 |

SOAへの注目度が増し、使用する専門用語の標準化(的確な意味を割り当てること)がますます重要になっている。興味深い論議で(リンク)、この点がクローズアップされている。論議の発端はMichael Poulin氏の質問で、Poulin氏は「オーケストレーション」と「コレオグラフィー」の相違を尋ね、両者の違いを「はっきりと明らかに表現している」場所を教えてもらおうと期待していた。単純な回答の代わりに、Poulin氏の質問には返答が相次ぎ、そのひとつひとつが両用語について少々異なる意味を授け、解釈も違っていた…。

Anne Thomas Manes氏の説明はまず、Merriam-Webster辞書に掲載されている両用語の伝統的な意味を引き合いに出している。

コレオグラフィー -- 舞踊を象徴的に表現する技術/技法:

  • 舞踊、特にバレエの構成やアレンジ
  • この技法によって創作された作品

 オーケストレーション -- オーケストラによる演奏向けの楽曲の編曲。また、オーケストラによる楽曲の表現方法

上記の定義では、ITにおけるオーケストレーションとコレオグラフィーの違いの明確化には実際役立たないが、論議の参加者の多数が暗にこの定義を使っていた。Thomas Manes氏は説明を続け、既存のWS-*仕様、具体的に言うとBPEL(Business Process definition Language)とWS-CDL(Web services Choreography Definition language)で使われている意味に触れている。

オーケストレーションとは、ワークフローの自動実行のことであり、すなわち、BPELのような実行言語を使ってワークフローを定義すれば、そのワークフローをランタイムに実行するためのオーケストレーション・エンジンが手に入ります。オーケストレーションされたワークフローの典型的な露出方法はサービスであり、このサービスはAPIを通じて呼び出し可能になっています。このワークフローは、2つ以上の関係者間で調整した相互作用については説明していません。

コレオグラフィーとは、2つ以上の関係者間で調整した相互作用を説明したものです。たとえば、あなたが付け値を要請して私が取引値を返すと、あなたは注文書を提出し、私はあなたに商品を送ります。

John Evdemon氏は少々異なった見方を示し、視認性に基づいて両用語を分類している。

オーケストレーションでは、プロセス全体が実行すると思われることの説明がありますが、プロセスの部分がどのように実装されるかについての具体的な説明はまったくありません。

コレオグラフィーはP2Pの相互作用の一形態と考えていますが、その理由は「指揮者」がいないからです。コレオグラフィーは相互作用の合意済みモデルであり、このモデルが一連のオーケストレーションで構成されている可能性もあるのです。

B2B的な見方をすると、オーケストレーションは組織内であり、コレオグラフィーは組織間です。もっと簡単に言えば、一組織が別の組織をオーケストレーションすることはありません。

Steve Johns氏がこの定義に磨きをかけている。

オーケストレーションは「固定している」という点において、一連のステップや決定の説明があります。コレオグラフィーはより目標指向のはずであり、その目標に向かってリソースを調整することに関連しています。

Alan Dean氏は、アーキテクチャ全体の一環として「中央集中化した制御要素」が存在するか否かに基づいて両用語を区別している。

オーケストレーション/コーディネーションには中心となる管理者/調整者がいるのに対し、コレオグラフィーにはいないように思われます…。
  • オーケストレーションは独裁的
  • コレオグラフィーは自治的

MetamaximのAshley McNeile氏はコレオグラフィーをRosettaNetの「パートナー・インタフェース・プロセス」標準まで追跡し、関係者間にみられる(相互作用)動作の特定の固定パターンを説明したもの、とみなしている。McNeile氏の考えによると、今回の論争は、

「コレオグラフィー」と「オーケストレーション」を概念として識別するというよりは、コレオグラフィーをオーケストレーションから切り離して説明・把握する言語上の必要性が原因となっています。

Rob Eamon氏はMcNeile氏に賛成し、次のように述べている。

アーキテクチャ定義や設計において、コレオグラフィーとオーケストレーションの区別が問題となる瞬間があるのでしょうか。アーキテクチャや設計で、一方もしくは他方の用語を使えば、それ以上の説明無しで十分でしょうか。私からしてみれば、これも特定のコンテキストにおける特定の意味に関する仮定が、誤解を招くケースのように思われます。使用している用語について関係者間には共通の理解があると確約することが賢明であっても、その用語には定義が存在するのです。

Gregg Wonderly氏も同じ意見である。

いつもどおりコンピュータ科学者の皆さんは、すでに存在する単語を選び、それを特定のコンテキストに当てはめようとしています。こうした単語を知っていて、異なるコンテキストで使用する人々には偏見と経験があり、この偏見と経験をもとに、そうした使用法の正否を判断するのです(絶対論理の世界では、論理的な説明に2進法の論理を用いることには「時々」困難があります)。そのため、議論がどれほど歪んだものになろうとも、私たち全員が合意できるところまで皆の意見をまとめていこうと、うんざりするほど議論する羽目になるのです…。

 SOAの連中が、ばかばかしい言葉を意味のない容れ物に無理やりはめ込もうとするのではなく、「はっきりと限定された」意味の単語や用語を喜んで使用する術を学んでくれさえしたらいいのにと思います。

Steve Jones氏が今回の論争を実にうまくまとめている。

要するに、コレオグラフィー、オーケストレーション、コーディネーション、プロセス管理など、あらゆる用語の定義があまりにもお粗末、というのが私の基本的な考えです。ベンダーがBPELエンジンをコレオグラフィー・プロダクトとして売り込んでも、私は驚かないでしょう。コレオグラフィーの人気がそれほど上がらない理由の1つとして(私見ですが)、現実世界のコレオグラフィー(舞踊)がITにとってはまったくの専門外となっていることが挙げられます。

今回の論争は、SOAやITでますます一般化している状況の一例にすぎない。人々は、実は異なる事を意味するのに同一の単語を使用しているし、また、実際は完全に意見が一致しているのに異なる単語を使用しているばかりに、言い争いを続けているのである。

原文はこちらです:http://www.infoq.com/news/2008/09/Orchestration

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT