|
||||||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||||||
| BPELにおけるデータハンドリング | ||||||||||||||||||
|
BPELによるビジネスプロセスでは、パートナー(呼び出すWebサービスやBPELにリクエストを送るリクエスター)との間のメッセージ交換が大きな比重を占めています。メッセージ(リクエストおよびリプライ)によってWebサービスをインボークしたり、BPELフロー自身が起動されたりするからです。しかしながら、BPEL仕様にはデータの取り扱いについて豊富な機能が用意されているわけではありません。 BPELフローで使用できるデータハンドリングのアクティビティは、assignの1つだけです。assignアクティビティのシンタックスは「<assign><copy><from/><to/></copy></assign>」となっています。from、toには、変数、リテラル値、WSDLで定義されたメッセージタイプをおきます。シンタックスからわかるように、基本的にはfromからtoに値をコピーするだけです。 |
||||||||||||||||||
| BPELにおけるデータの問題点 | ||||||||||||||||||
|
BPELではコピーによってメッセージを作成していくのですが、本社と配送センターのように、異なる部門間のシステムを連携したシステムの場合に頻繁に問題が発生します。それは配送システムへのリクエストに必要な「顧客名」や「発送先住所」のデータが、どのパートナーからの受信データにも含まれていないということです。これらのデータは本社で管理している顧客マスターのデータベースに格納されているのですが、配送センターにある配送システムからは、何らかの理由によってアクセスできません。 Webサービスは、異なる組織間の連携(B2BやB2C)に適した仕組みとされてきました。B2B連携にはデータ構造やデータのセマンティクスの違いをどう吸収するかという問題が常につきまといますが、Webサービスを連携させるためのBPELには残念ながらこれに対処するための機能が乏しい状態です。 |
||||||||||||||||||
| ESBにおける解決方法 | ||||||||||||||||||
|
そこでESBによる解決策が生まれました。ESBに外部データベースへのアクセス機能やデータ変換のアプリケーションを呼び出せる機能を設けるのです。本連載の「第4回:ESBにおけるデータ変換(後編)」の図3で示したものがESBにおける解決方法です。 BPELにおいても同様に、データベース検索やコード変換アプリケーションの呼び出しが行えればよいのですが、現行のBPEL仕様にはそのような機能はありません。マスターデータ参照のような処理を行うためには、外部に処理ロジックを用意しておき、Webサービスとして呼び出さなければなりません。 本来は、連携の基盤であるBPELエンジンで吸収すべきアプリケーション間の違いを、業務ロジックと同じレベルのWebサービスとしてミドルウェアの外に設けなければならないのは、システム管理の面でも、システムの処理パフォーマンスの面でも、あまりよいこととはいえません。 |
||||||||||||||||||
| BEPL 2.0における改善の兆し | ||||||||||||||||||
|
さすがに、OASIS側にもこの認識はあるようで、BEPL 2.0ではassignアクティビティを拡張して2つの機能を追加し、改善の兆しが見えはじめています。
表1:BEPL 2.0で拡張された2つの機能 このようにBEPL 2.0では、assignの機能拡張が行われていますが、まだまだ不十分です。本連載の「第3回:ESBにおけるデータ変換(前編)」および「第4回:ESBにおけるデータ変換(後編)」であげた問題は、すべてそのままBPELについてもあてはまります。現行のBEPL 2.0仕様では、これらの問題のごく一部しか解消できないことに注意してください。 |
||||||||||||||||||
| 次回は | ||||||||||||||||||
|
次回はパートナーとの関連づけについて、BPELエンジンの機能とからめながら説明します。 |
||||||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||||||
|
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||

