EIP/ebXML and - Java EE勉強会

Menu

ebXML and the Electronic Business Messaging Service(ebMS) †

ビジネスのコラボレーションやB2Bの統合プロジェクトで働いてる頭のいい人たちは、XMLメッセージングを使ってビジネス情報をやりとりするのに、オープンで、セキュアで、相互運用可能なインフラを開発する必要があると思ってた
ebXMLを使った仕様や構想が開発され、ebXMLはそれらを取り込んで大きくなっていった
OASISとUN/CEFACTがebXML initiativeを立ち上げた

ebXMLはいくつかの仕様から構成される
- 企業はどのようにビジネスプロセスを公開するのか
- 企業はどのように潜在的なパートナーを探すのか
- パートナーはどのように合意するのか
- パートナーはどのようにやりとりを始めるのか
- 見つけやすくビジネスのやりとりをしやすくする登録の仕方
- やりとりをしやすくするのに求められるメッセージングのインフラの振る舞い
  - この最後の仕様が特に注目され、メッセージングのパターンにフォーカスを当てる目的で分けられた

ebMSは他の標準同様全く「新しく生まれた」ものではなく、ビジネスプロセスの統合ではすでにかなりの成功を収めていた
- EDIシステムの促進
- Webサービスで信頼性とセキュリティを提供するSOAP拡張
1999年から3年以上かけてOASISによって作られ、他のビジネスプロセス標準の開発に多大な影響を与えている

ebMSのゴールはXMLフレームワークでビジネスメッセージの交換を簡単にできるようにすること
- とはいえ、メッセージ本体はXMLである必要はなく、バイナリフォーマットの旧世代のEDIフォーマットといったものでも構わない
- 既存のメッセージングシステムをくるんで、Message Translatorの実装といったフレキシブルな技術の橋渡しを提供
  - ビジネスパートナーとのエクストラネットやB2B通信の統合をスケールするのに特に有用
ebMS利用ケースで重要なもの
- 独立した企業間のメッセージ指向ミドルウェアの接続
- ベンダーと開発者間のやりとりの妥当性をチェックしやすくするテスト容易性
ebMSに絶対欠かせないもの
- レガシーなEDIシステムのサポート

ebMSはEDIの反復と相性がよい一方、洗練されたSOAPベースの標準的なサービスである
- XML転送はebMSに特化したヘッダを含んだSOAPのエンベロープに基づくebMSシステムで使用
  - メッセージID
  - タイムスタンプ
  - 電子署名
  - メッセージ内容のメタデータ
- ebMSは、メッセージルーティングパターンと、Idempotent Receiverなどのメッセージエンドポイントパターンを実装するSOAPヘッダを使っている

ebMSは電子メールのメッセージに付け加えられるのと同様、SOAP with Attachmentsを使ってデータを転送する
- 添付されるデータのフォーマットは制限なし
  - XMLデータ
  - バイナリデータ
  - 外部データへ参照しているリンク
  - などなど
- さらに、それぞれのデータは各々の電子署名を持っており、ebMS実装で提供された認証と認可も追加できる

ebMSは非同期がデフォルトだが、同期も可能
エラーハンドリングのメカニズムは洗練されており、データごとのエラーメッセージと合わせてSOAP Faultを送れる

信頼性のために、ebXML Message Service Handlersと呼ばれるebMSの実装により、メッセージのやりとりが終わるまで保存される
- 開発者は、once-and-only-onceやstore-and-forwardといった意味論的な宣言を、単一のメッセージあるいはメッセージグループに対して適用できる
ebMSは連続した配信と管理を制御するサービスを明確にしている
- Control Busに相当するMessage Status Sericeによって実現される
- Message Historyやそれに関連するパターンの実装に基いて、以前にebMSシステムに送られたメッセージのステータスを問い合わせるリクエストを送れる
ebXMLに関しては http://www.ebxml.org/ で
- ebMSに関しては http://www.ebxml.org/specs/ebMS2.pdf

Business Process execution Language for Web Services (BPEL4WS) †

BPEL4WSとは
- ビジネスプロセスのコンポーネントとその相互作用の定義で標準的なもの
- bee-pel for wuss
- IBMのWeb Services Flow Language(WSFL)とMicrosoftのXLANGをマージ
  - WSFLはサービスのエンドポイントを作ったり、Webサービスのワークフローにリンクを割り付けたりを定義
  - XLANGはBiztalkServer?で実現されている、ワークフローコンポーネントを作るためのモデルを定義したり開発したりするのに使われる
- BPEL4WSはこれらの一部を提供
  - 既存サービスのプロセスを構成する文法
  - 大きなワークフローをリンクするためのプロセスインターフェイスの記述する文法

BPELの設計では、パートナーと呼ばれるWebサービスとのつながりを指示する
- コンテナと呼ばれるメッセージストアの内外にあるXMLメッセージ
- アクティビティと呼ばれるルール
サービスのつながり、メッセージコンテナ、アクティビティの論理的なセットは一つのビジネスプロセスコンポーネントを構成
BPELの仕様で次のものを作るProcess Managerを定義
- Routing Slip
- Durable Subscriber
- Datatype Channel
- 宣言的なXMLの文法に基づく他のもの
開発者はビジネスプロセスコンポーネントを作るのに（おそらくヴィジュアルツールを使って）XMLで振る舞いを定義する
- サービス間のメッセージングプログラムを作る必要はない

BPELではWSDLドキュメントが非常に重要
- BPELコンポーネントはサービスのWSDLドキュメントに基づく複数のWebサービスで構成されてそれらを管理する
- ビジネスプロセスは、WSDLのメッセージ定義のフォーマットに従ったサービスのWSDLドキュメントで宣言されるサービスのエンドポイントへのメッセージを例示して、配信もする
- BPELのシンタックスは、どの順番でメッセージを受診するのか、どこへ送るのか、いつどうやてリプライするのか、いつ他のWebサービスを実行するのか、など宣言されたWSDLファイルをインポートして、portTypeやWebサービスのセットとをリンク付ける

サービス間のつながりを確立するのに、アプリケーション開発者はWebサービスのWSDLをインポートして、BPELのserviceLinkType?要素を使ってそれらのパートナー関係を定義する
この要素はフローに含まれるWebサービスのportTypesと、プロセスの関連におけるパートナーの役割を参照するもの

サービス間の関連を記述すると、開発者はサービスが入出力に使うメッセージを保持するコンテナを生成するため、BPELを使用する
- コンテナは、WSDLでメッセージタイプが宣言されたDatatype Channelに非常によく似ている
- コンテナの実装に依存するので、コンテナはShared Databaseの統合スタイルの観点から考慮される

BPELコンポーネントは、単一のインターフェイスとしてその入出力を、内部のWebサービスが使っているのと同じ形式でWSDLを通して公開する
- が、ビジネスプロセスのWSDLとWebサービスのWSDLはちょっと違う
  - ビジネスプロセスのWSDLのportTypesは単一プロセスの入出力のエントリーポイントを定義
  - サービスインタフェースのメソッドとして論理的に実装が分かれてるわけではない

BPELコンポーネントの振る舞いは、アクションのセットとして定義される
- どんなアクションでも次のようなことをする
  - ビジネスプロセスはサービスにメッセージを送りつける(invoked partnerと呼ばれる)
  - サービスからメッセージを受け取る(client partnerと呼ばれる)
  - client partnerがメッセージを返す
  - いくらかの論理的なルールに基づいてメッセージを送るのか受け取るのかを決定する
  - 決められた時間だけ待つ
  - エラーをレポートする
  - メッセージを別のところへコピーする
  - 全く何もしない

BPELのXML文法はこれらの基本的なアクションを反映してる
- invoke
  - invoked partnerにメッセージを送る
- receive
  - client partnerから受信する
- reply
  - client partnerに返信する
- flow
  - ロジックを並列化する
- pick
  - イベントを待機する
- throw
  - エラーをレポートする
- wait
  - 一時停止する
- empty
  - 何もしない
- terminate
  - 停止する
- while、sequence、pick、条件は、XPathで宣言される

ビジネスプロセスを構成するサービスを定義するXMLソースファイルを作り、サービスが使うメッセージコンテナを宣言し、メッセージ変換を含む一連の終えレーションを定義すると準備完了

サービスの関連づけとメッセージフローを定義したアクションに加え、BPELではBPEL4WSエンジンで使用できる実行ファイルについて記述できる
- エンジンはファイルを解釈し、一連のメッセージ構成を用意することで、ビジネスプロセスの一部であるWebサービスに接続できるようになる
- Process Managerの実装として、BPEL4WSランタイムはサービス間のメッセージフローを管理し、関連付ける
BPEL4WSエンジンが必要な文書は全て受け取り、メッセージング環境を動的に生成して管理する

BPELの仕様はこちらを参照
- http://www-106.ibm.com/developer-works/webservices/library/ws-bpel/

Web Service Choreography Interface (WSCI) †

whiskey
BPELと被ってる
- Sun、Intalio、SAP、BEA
- W3C

WSCIはBPMLに影響を受けてる
- 直接はインテグレーションパターンとは関係ないが、特筆すべきものがある
BPMLはプロセスモデリングで使われるXMLベースのメタ言語でビジネスプロセスを表現
BPMLのワークフローはWSCIで大きく占めるが、BPMLはグラフィカルな表記やクエリ言語も持つ

BPEL同様、Webサービスのプロトコルに基づく単一のオペレーションのやりとりよりも、エンタープライズインテグレーションは長ったらしいやりとりになる
WCSIは複数のオペレーションを複合プロセスにリンクする方法を提供している
- 以下の様なメッセージのやりとりが保証される
  - 適切な手順で送られて、受け取られる
  - ビジネスルールに合ったやりとり
  - トランザクションのやりとり
  - 単一のグローバルなプロセスとして表現でき、管理できる
旧来のメッセージ指向ミドルウェアに対するWebサービスの利点が活かせる
- 動的なサービスの検索
- 異なるプロトコル
- ワークフローの分散

BPEL同様、WSDLで公開されるサービスエンドポイント、portTypes、操作、メッセージタイプに強く依存する
- WSCIのアクションは、コレオグラフィにあるサービスのWSDLで公開されるオペレーションに直接マッピングされる
- WSCIのシンタックスは、WSDL文書に直接埋め込まれている
- WSCIの要素はWSDLのdefinitions要素に含まれる

WSCIの基本構成は、Webサービスメッセージングのアクションである
- アクションはプロセス要素でグループ化される
  - シーケンシャル、パラレル、ループ、条件分岐で宣言できる
- プロセエスのセットは一つのインターフェイス宣言としてグループ化される
  - interface要素はプロセス構成のインターフェイスで、WebサービスのWSDL定義に直接埋め込まれている
- 多くのアクティビティ要素はBPELと似たもので、その対応も同様でXPath表現も含んでいる

WSCIの仕様はこちらを参照
- http://wwws.sun.com/software/xml/developers/wsci/wsci-spec-10.pdf

Java Business Process Component Standards †

...

Menu