トランザクション管理の複雑性を克服する（パート1）：The Rational Edge（2/4 ページ）

[Benjamin Lieberman，＠IT]

自動化と業務活動

　100年前の業務活動には大変な労力が伴った。部屋には事務員があふれ、注文、配送、支払いを処理すべく、業務処理の追跡と、整理され、一貫性のある経理システムの維持のため、慌ただしく働いていた。彼らは複式簿記などのテクニックを使い、業務に具体的な影響が出る前に、手作業でミスを突き止め、修正した。ビジネス「トランザクション」は、注文の受け付けに始まり、顧客からその製品やサービスに対する最終的な支払いを受けるまで、経理全体を指している。

　今日では、ソフトウェアの自動化によって、人がほとんどいなくても業務活動が行えるようになった。従業員が1人も介入することなく、Webで注文を取り、代金を計算し、製品を納入する。従って、企業は経理の精度をかなり高レベルで維持しながら、業務を安く早く遂行できるようになっている。また、トランザクションがはるかに複雑になり、最終的にクライアントの手元に届くまでに複数の企業が関与する可能性があることも事実だ。

　例えば、1社の通信ベンダから顧客が衛星放送の受信、ブロードバンドインターネット、携帯電話サービス、そしてインターネットゲームの定期利用サービスを購入するバンドル通信サービスを考えていただきたい。そこでは、このベンダ自身がほかのベンダ各社と提携して各サービスを提供し、最終的に支払われる料金を分配している。何らかの形で自動化された監視ができなければ、このように複雑な業務交流の管理はかなり困難（かつ高価）になる。従って、いまの業務活動には、分散し、非同期でやりとりする独立した多数のソフトウェアシステムが関与する場合がある。

　サービス指向アーキテクチャ（SOA）の登場により、この相互運用性が一段と複雑化した。SOAベースのシステムでは、疎結合され、プラットフォームに依存しない形で、1つのシステムから別のシステム（多くの場合は、複数の競合企業のもの）へとサービスが提供される。これらのサービスは、注文管理、請求、在庫、そして販売業務全般まで、あらゆるレベルの業務機能を提供できる。一連のサービスを一緒に集めることにより、分散ネットワーク全体ですべてをシームレスにやりとりさせながら、さまざまな複雑性を持つ業務活動を構築することが可能になる。

　ただ、気を付けなくてはならないのは、あるところから来た情報を別のところが必要とする場合だ。例えば、在庫を割り当てるのに注文番号が必要になり、そこから請求システムが毎月の請求書作成に使用するレコードが生成される。このような環境でデータの一貫性を確保するためには、トランザクション・コーディネーションサービス（TCS）による何らかの形のトランザクション管理が必要となる。TCSは、資源の確保、業務機能管理、並行処理コントロール、および障害復旧など、複雑な業務活動を整理およびコントロールできなくてはならない。

分散サービスのコーディネート

　分散サービスを利用するためには、自動化される業務機能を十分に理解しておく必要がある。サービスを素早く入れ替えられるサービス指向アーキテクチャの柔軟性実現に要するコストは、業務活動の整理とコントロールにおいて大きな負担となる。各サービスが提供するのは商取引全体のごく一部の機能にすぎない場合もあり、（注文処理や請求処理など）ある処理の結果が別のプロセスに渡される。複雑な相互依存型の一連のサービスをうまく作成するには、「サービスコーディネーター」（すなわち「システムアーキテクト」）が各サービスインターフェイス、これらのサービスによって作成および消費される成果物、および例外ルールを定義する必要がある。

　最初は、情報の自動化によってサポートされるビジネスプロセスで確定した業務機能を定義することだ。XMLを使った業務フローの宣言と参加者の仕様が、（IBM、BEA Systems、Microsoft、SAP AG、およびSiebel Systemが参加する）業界団体によって先ごろ公開されている。この仕様は、「Business Process Execution Language for Web Services（BPEL4WS）」と呼ばれている［注1］。

　この仕様では、　WSDL（Web Services Description Language）によるWebサービスの宣言同様に、プラットフォームから独立した形での業務機能の定義を認めている。もちろん、BPELの定義をインプリメントするクライアントシステムは、同仕様のXMLタグをパースして解釈する必要があるが、このアプローチの方が、サービスの記述と順序の情報をハードコーディングするよりはるかに柔軟だ。ビジネストランザクションを記述するもう1つの標準、WS-Transactionでは、業務機能が相互に結び付けられ（WS-Coordination）、独立した作業単位（WS-AtomicTransaction）、あるいは長期業務の集合（WS-BusinessActivity）を形成する［注2］。

---

［注1］ BEPL4WS仕様はココを参照。

---

［注2］ 仕様のドラフトはココを参照。

---

業務機能のコーディネーション

　SOAでは、業務機能は定義された成果物を作り出す目的で実行される分散サービスの集合、と定義されている。例えば、lookupOrder（図1）は、顧客の注文情報を詳細に記述する定義済みデータ構造を返す業務機能となっている。さらに複雑な例が、finalizeOrder（図2）で、ここでは注文を処理し、請求情報を更新するために一連の処理が実行される。業務ワークフローの各作業は、呼び出されるサービス、入力パラメータリスト、そして出力データによって定義されている。

図1 lookupOrder（クリックすると拡大）

図2 finalizeOrder（クリックすると拡大）

・作業定義（services and messages）

　サービスの大半は、図3のようにWSDLの記述で定義されている。そこには、サポートされるメッセージタイプやサービスと結合した情報の記述が含まれている［注3］。　サービスは、データタイプ、I/Oメッセージ、メッセージを渡すportType、結合したプロトコル、結合したアドレスポート、そして指定サービスという主要な6つの要素によって定義される。メッセージデータタイプと構造は、各種ebXMLインプリメンテーション［注4］など、既存の業務データ転送の定義に準拠していたり、各サービスプロバイダによって定義される場合もある。利用されるプロトコルはSOAP（Simple Object Access Protocol）もしくはHTTP（Hypertext Transport Protocol）ベースの場合が多いが、サービス指向アーキテクチャでは、すべてのサービスに1つのプロトコルを使う必要はなく、プロトコルを定義さえすればよい。一般的には接続ポートやサービス情報も定義されるが、UDDI（Universal Description and Discovery and Integration）レジストリが使われている場合は、レジストリから正当なサービスを特定するための情報が作業定義に含まれる場合もある。

---

［注3］ WSDL仕様の詳細はココを参照。

---

［注4］ ebXMLの定義の詳細はココを参照。

---

図3 WSDLサービスモデル（クリックすると拡大）