Loading article…
ビジネスコンピューティングにおけるサービスオーケストラは、複数のパートナーサービス間の相互作用プロトコルをグローバルな視点から定義するサービス構成の一形態である。 [ 1 ] サービスオーケストラの概念の根底にある考え方は、次のように要約できる。
「ダンサーたちは、単一の統制ポイントを持たないグローバルなシナリオに従って踊る」
つまり、実行時には、サービスコレオグラフィーの各参加者は、他の参加者の行動に従って自分の役割を実行します。[ 2 ]コレオグラフィーの役割は、それを演じる参加者が消費および生成できるメッセージの順序とタイミングに関して、期待されるメッセージング動作を指定します。[ 3 ]
振り付けとは、何らかの有用な目的を達成するために、2人以上の参加者間でデータが交換される順序と条件を記述するものである。[ 4 ]
サービスコレオグラフィーは、サービス構成の別のパラダイムであるサービスオーケストレーションとの比較を通してよりよく理解できます。一方では、サービスコレオグラフィーでは、参加者間のメッセージベースの相互作用のロジックがグローバルな視点から指定されます。他方では、サービスオーケストレーションでは、ロジックはオーケストレーターと呼ばれる制御参加者のローカルな視点から指定されます。たとえば、サービスオーケストレーション言語BPELでは、サービスオーケストレーションの仕様（たとえばBPELプロセスファイル）は、サービスインフラストラクチャ（たとえばApache ODEのようなBPEL実行エンジン）にデプロイできるワークフローです。サービスオーケストレーション仕様のデプロイにより、ワークフローが複合サービスに変換されます。[ 5 ]
ある意味では、サービスコレオグラフィーとオーケストレーションは同じコインの裏表です。一方では、サービスコレオグラフィーの役割は、プロジェクションと呼ばれるプロセスを通じてサービスオーケストレーションとして抽出できます。[ 6 ]プロジェクションを通じて、スケルトン、つまりサービスコレオグラフィーに参加するウェブサービスを実現するためのベースラインとして使用できる不完全なサービスオーケストレーションを実現できます。他方では、既に存在するサービスオーケストレーションをサービスコレオグラフィーに構成することができます。
サービスコレオグラフィーは実行されるのではなく、実行されます。サービスコレオグラフィーは、参加者がそれぞれの役割を実行するときに実行されます。[ 7 ]つまり、サービスオーケストレーションとは異なり、サービスコレオグラフィーはサービスインフラストラクチャ上のエンジンによって実行されるのではなく、役割が実行されたときに「発生します」。これは、サービスコレオグラフィーのロジックがグローバルな観点から指定されているため、サービスオーケストレーションのように単一のサービスによって実現されないためです。
振り付けに関する研究の多くが答えようとしている重要な質問は次のとおりです。コラボレーションの参加者間の可能な相互作用を記述するグローバルな振り付けが構築されたとします。コラボレーションが成功することが保証されるためには、振り付けはどのような条件を満たす必要がありますか?ここで、成功するとは、各参加者が独自のスケルトンに従って独立して行動し、コラボレーションが実行されたときに生じる創発的な振る舞いが、スケルトンが最初に投影された振り付けに正確に従うことを意味します。この場合、振り付けは実現可能であると言われます。[ 8 ]一般に、振り付けの実現可能性を決定することは、特にコラボレーションが非同期メッセージングを使用し、異なる参加者が同時にメッセージを送信できる場合には、自明ではない問題です。
Webサービスに関する仕様の範囲内で、以下の仕様はサービスオーケストレーションをモデル化するための言語の定義に焦点を当てています。
さらに、OMG仕様BPMNバージョン2.0には、サービスオーケストレーションをモデル化するための図が含まれています。[ 9 ]
サービス振付言語に関する学術的な提案には、以下のようなものがある。
さらに、以下のような基準に基づいて、数多くのサービス振り付けの形式が提案されている。
Webサービスオーケストレーション（WS-Choreography）は、W3Cが定義したXMLベースのビジネスプロセスモデリング言語であり、連携するWebサービス参加者間のコラボレーションプロトコルを記述します。このプロトコルでは、サービスはピアとして動作し、相互作用は長期にわたり状態を持つ場合があります。（オーケストレーションは、非常によく似ていますが、意味が異なる別の用語です。）
振り付けを作成するための主要な取り組みであるW3C Web Services Choreography Working Groupは、2009年7月10日に終了し[ 24 ]、 WS-CDLは勧告候補として残りました。
2001年4月11日～12日に開催されたW3Cウェブサービスワークショップでは、多くのプレゼンテーションで、オーケストレーションに対応するための共通インターフェースと構成言語の必要性が指摘されました。ウェブサービスアーキテクチャワーキンググループが作成したウェブサービスアーキテクチャ要件ワーキングドラフトでも、ウェブサービスのオーケストレーション機能は、黎明期のウェブサービスアーキテクチャにおける複数の最上位目標を支援する重要な成功要因として挙げられています。。
当時、振り付けの問題は業界で大きな関心を集めており、WSCL (Web Service Conversation Language) や WSCI (Web Service Choreography Interface) などの取り組みが W3C に提出され、技術ノートとして公開されました。さらに、補完的な取り組みも開始されました。[ 25 ]
2002年6月、Intalio、Sun、BEA、SAPは、Web Services Choreography Interface（WSCI）という共同仕様を発表しました。この仕様は、2002年8月にW3Cにもノートとして提出されました。W3Cはその後、Webサービス活動内にWeb Services Choreographyワーキンググループという新しいワーキンググループを設立しました。WSCI仕様は、Web Services Choreographyワーキンググループへの主要なインプットの一つであり、同ワーキンググループは2005年11月9日にWS-CDLバージョン1.0の勧告候補を発表しました。「XLang、WSFL、WSCIは、もはやどの標準化団体や企業からもサポートされていません。BPELがXLangとWSFLに取って代わり、WSCIはWS-CDLに置き換えられました。」。
次期ビジネスプロセスモデリング表記法バージョン2.0では、サービスオーケストレーションを指定するための図が導入される予定です。[ 9 ]
学術分野では、例えば Let's Dance [ 10 ] BPEL4Chor [ 11 ]や MAP [ 19 ]など、他のサービス振付言語が提案されている。
サービスコレオグラフィーは、グローバルな視点から参加者間のメッセージベースのインタラクションを指定します。プログラミング言語がプログラミングパラダイムに分類できるのと同様に、サービスコレオグラフィー言語もスタイルに分類できます。[ 26 ]
サービス振付というテーマについては、現在いくつかの研究プロジェクトが進行中である。