Loading
|
|
＠IT｜＠IT自分戦略研究所｜QA＠IT｜イベントカレンダー＋ログ |
|
Loading
|
| ＠IT > Webサービスを実現するhp netaction > 第1回 Webサービスの課題とその解決を探る |
 |
|
|
|
|
| 2001/12/19
Webサービスは、インターネットを介して複数の企業が提供するサービスを利用することで、より価値の高いサービスの実現したり、業務の効率化やシステム間連携の短期開発を実現するものだ。最近では、Webサービスの適用分野として、従来からのBtoBをWebサービスに置き換えるケースや、企業内のシステム間連携にWebサービスを適用とするケースが論じられる傾向が出てきた。もちろん、これらもWebサービスであるが、想定される相手（システム）との連携は、いわば「Simple Webサービス」であり、既存のSOAP、WSDLなどのテクノロジーを使って実現可能な分野だ。 しかし、本来Webサービスが目指すのは、複数のサービスが随所から自由に利用されるアドホックな連携だ。本稿ではこれを「Complex Webサービス」と呼ぶ。これを実用化するとなると、いくつかの課題が浮かび上がる。例えば、サービスを提供する側の信用とサービスの品質をどう保証するか、セキュリティをどう確保するかなどの重要な問題がある。そして、これらの問題に合わせて重要となるのは、複数のサービス間のトランザクションをどう確立させるかという問題だ。アプリケーションでカバーすればよいという議論もあるかもしれないが、トランザクションをプラットフォームとして用意すれば、アプケーションからは隠蔽され、どんなアプリケーションでもトランザクション利用できるようになるし、異なるアプリケーションでさえ、トランザクションで管理できるだろう。 そうすれば、Complex Webサービスのスタートを加速することになる。 本稿では、Webサービスにおけるトランザクションの実現について論じ、これをサポートするHPのミドルウェアhp netactionに含まれるHP Web Services Transactionについて解説しよう。
少し抽象的な表現になるが、Webサービスにおいて、A、B、Cという3つのサービスをデータが渡り歩き、それぞれのサービスのデータベースを更新する例を考えてみる。A→B→Cとトラブルなく順調に処理が終了し、それぞれのデータベースが更新されるなら問題ない。しかし、実は、Bだけ処理が異常終了していたというケースでは、A、B、Cの間にデータの矛盾が生じ、正常なサービスの利用ができていないことになる。 A、B、CというサービスがWebサービスではなく、通常の密な結合の上に存在していれば、この矛盾が生じない方策として2フェーズ・コミットを利用すればよい。つまり、最初のフェーズでトランザクションを構成する個々のサービスについて一度正常に処理が実現できるかを問い合わせ、すべての処理が実現可能であることが確認できた時点で、次のフェーズとして更新処理を行う。この 2つのフェーズのどこで不都合があってもコミットはせず、トランザクション処理自体がまったく実行されなかったことにするため、 複数のサービス上のデータベース更新する場合でも、矛盾なく更新できるわけだ。 しかし、Webサービスでは、この2フェーズ・コミットを利用できない。これが、Webサービスでのトランザクションにおける最大の課題だ。前述したように、サービスの側でデータの整合性をカバーする方法もあるが、複数のサービスとの柔軟な連携を考えると、2フェーズ・コミットのような仕組みがあるほうがよい。 では、なぜ2フェーズ・コミットが利用できないのか、そしてその代案として、分散したサービス（アプリケーション）の間で処理の一貫性を保つ分散トランザクションを保証するにはどうしたらよいのかについて、これから解説していこう。
まず、2フェーズ・コミットのプロトコルをインターネットに流すことは難しい。分散トランザクションとしてはCORBA OTS、DCOMなど既存技術が存在するが、これらのプロトコルはファイアウォールを超えることが難しい。 また、2フェーズ・コミットは、イントラネットなどの閉じた環境で用いられ、トランザクションマネージャ、リソース、アプリケーションのすべてが同じ人々によって作られ、利用され、管理されることを前提としている。つまり、すべてのコンポーネントが１つの組織でコントロールされる状態にある。その上、安定して稼動するインフラストラクチャ環境が前提であり、万が一、障害が起きたらロールバックを行う。一方、Webサービスのコンポーネントはしばしば自社内ではなくインターネットの向こう側に存在し、そのシステムは自分のコントロールが及ばない。IT管理者が社内システムを管理するよりも不確定要素が多く障害のリスクが高いことが予想される。しかも、こちらが24時間運用しようとしても、Webサービスの提供者が彼らの営業時間外にはサービスを停止する、といったこともあるかもしれない。つまり、トランザクション中のサービスの中断は頻繁に起きうるものとして、それに対応できるメカニズムが必要となる。 また、Webサービスにおけるトランザクションは、ビジネス・プロセスの一連の処理に対応し、トランザクションのスコープには時としてアプリケーションの実行にとどまらず、承認など人為的なタスクを含むこともある。トランザクションのライフサイクルは、古典的なトランザクションのせいぜい数秒といったオーダーに対して、何日・何週間という長期に及ぶことがある。このことからWebサービスのトランザクションはロング・リブド・トランザクションと呼ばれる。 ロング・リブド・トランザクションと古典的なACIDトランザクションとの大きな違いは、リソースのロック期間の長さとロックをかける人が誰か、ということである。ACID属性を保つためには、コミットをかけるまでのある一定時間、リソースをロックする必要があるが、果たしてコントロールが及ばない他人（他社）のアプリケーションによって自分のリソースが長期間ロックされることが許されるだろうか。へたをすればサービス妨害攻撃（DOS）など悪意のある攻撃によってサービスが容易に中断されてしまう危険性もある。Webサービスのトランザクションでは、リソースのロックによってACID属性を保証することが難しい場合があるということだ。
こうしたWebサービスのトランザクション問題に対して、現在、OASISではBusiness Transaction Protocol（以下BTP）と呼ばれる仕様の策定が進められている。BTPはHPやBEAによって標準化が進められており、2001年12月10日現在ではドラフト0.9版が提案されている。BTPは次に挙げる4つの要件を満たすようデザインされている。
BTPのメッセージはXMLで記述され、SOAPメッセージのHeaderやBodyに埋め込まれる形となる。BTPではトランザクションをAtom（原子）とCohesion（結合）という2つのユニットに分けて考え、これらを組み合わせることにより複雑なトランザクション管理の柔軟性を確保している。
AtomによるACID属性に基づいた厳密なトランザクション管理と、Cohesionを使ったより大きなビジネス・トランザクションの構成により、BTPではトランザクションの信頼性と柔軟性を両立させている。注意して欲しいのは、BTPはWebサービスがその内部でどのようにACID属性を保証するか、ということには関与しないということだ。処理の失敗時に、古典的なロールバックでデータを元通りに戻しても良いし、ほかの形で失敗に対する埋め合わせの処理を行ってもよい。BTPが要求するのはただAtomでACID属性が保証されることだ。 ところで、HPでは、BTP1.0が正式勧告となり次第、その実装製品であるHP Web Services Transaction（以下HP-WST）をリリースする予定だ。次に、実際に例を上げながらBTPによるトランザクション管理、そしてHP-WSTについて簡単に解説しよう。
あなたがいま、ニューヨークのホテルにいると仮定しよう。今回の旅行はあなたにとって初めての海外旅行で、ニューヨークの勝手がよく分からないのだが、夜は遊びに出たい。あなたは最新のミュージカルをみて、イタリアン・レストランで食事をした後にタクシーでホテルに帰りたいと考えている。 さて、ミュージカル、レストラン、タクシーそれぞれの予約をWebサービスで行うことを考えてみよう。ミュージカル劇場、レストラン、タクシー会社はそれぞれ自前の予約システムを持っており、インターネット上にWebサービスとして提供しているとする。インターネット上には劇場予約、レストラン予約、タクシー予約のWebサービスが存在するとする。これらのWebサービスはBTPをサポートしている必要がある。そして、トランザクション・コーディネータとなる（これも1つのWebサービスであるが）BTPサービスが存在する。BTPサービスはHP-WSTが提供するものだが、この例のようにクライアントアプリケーションと独立して提供されても良いし、クライアントアプリケーションに合わせて実装されていても良い。なお、ここでのクライアントとはユーザに代わって一連の予約業務を代行してくれるサービスだ。ホテルのコンシェルジェに相当するものと考えれば良い。 ■Atomを使ったトランザクション さて、あなたが遊びに行くかどうかの条件を「劇場、レストラン、タクシーすべてが予約できたら遊びに行く、どれか1つでも失敗したら外出は中止」としよう。この場合、劇場、レストラン、タクシー予約のWebサービスをまとめて1つのトランザクションと定義する必要がある。BTPではこの処理単位をAtomと呼ぶ。予約が正常に完了できる場合の処理の流れを以下に示す。
次に劇場が満席で予約できなかった場合を考えてみよう。この場合、このAtomはロールバックし、レストラン、タクシーへの予約はキャンセルしなければならない。先ほどの処理の流れで(9)までは共通である。
BTPサービスがトランザクションのコーディネータとして機能し、WebサービスやクライアントとBTPメッセージを伝播させる様がお分かりいただけると思う。 ■Cohesionを使ったトランザクション 次はCohesionを使った例を考えてみよう。今度はあなたが遊びに行く条件を「劇場の予約成否に関わらず、レストランとタクシーさえ予約出来れば遊びに行く」とする。これをBTPで表すには、タクシーとレストラン予約を合わせて1つのAtom（Atom A）、劇場予約を別のAtom（Atom B）とし、Atom AとAtom Bを合わせたものをCohesionとして定義する。あなたの条件をBTPで表現すると、Atom Aが失敗したらCohesionはロールバックするが、Atom Bが失敗してもAtom Aが成功すればCohesionはコミットする、となる。 劇場が満席で予約できなかったが、タクシーとレストランは予約できた場合は、以下のような処理となる。
この例でのAtomとCohesionの構成と処理結果は下図の通りだ。劇場の予約が失敗（=Atom Bの失敗）しても、Cohesionとしては成功し、タクシーとレストランの予約は確定したわけである。どのAtomの成否がCohesionの成否に影響するかはアプリケーション側で自由にコントロールできる。
より複雑なトランザクションを表現するために、Atomを入れ子（ネスト）させることも可能だ。なお、ここで紹介した内容はBTPのドラフト仕様に基づいており、正式勧告時では仕様が変わる可能性があるので注意して欲しい。
ところで、Complex Webサービスの実現に向けたもう１つの課題は、多数のWebサービスをいかに連携させるか、ということだ。Webサービスの可能性の1つは、他社のアプリケーションを利用できることであり、それはすなわち、他社のビジネス・プロセスを自社のビジネス・プロセスに組み込んで利用できることを意味する。これを実現するポイントはWebサービスがコンポーネントであることだ。複数のWebサービスをプラグ・アンド・プレイで柔軟に組み合わすことができれば、新しいサービスを短期間で生み出すことができるし、ビジネス・プロセスを動的に変更することもできる。ビジネス・ロジックのコンポーネント化という点からすれば、既にEJBコンポーネントの流通が始まりつつあるが、より大きな複雑な業務プロセスを考えた場合、より簡単に定義出来、後々の変更が容易な方法が求められるだろう。 UDDIを使えば、あなたは自分の求めるWebサービスを見つけることができる。しかしながら、見つけたWebサービスは果たしてどうやって組み合わせればよいのか。どういった順番で実行させれば良いのか。あるWebサービスの実行結果によって、次に実行するWebサービスを分岐したいときはどうすれば良いのか。これはいわゆるワークフローの世界だ。Webサービスとなるアプリケーションがアプリケーションサーバ上にある以上、ワークフローエンジンをアプリケーションサーバ上に持ち込むという方法が選択肢の1つとして自然に浮かんでくる。 ■Webサービスの連携を実現するHP Process Manager interactive Webサービスのプラグ・アンド・プレイを実現するためには、Webサービスをプロセスとして考え、プロセスの組み合わせやプロセス間の処理の流れをビジュアルに定義し、その定義に沿って処理を実行していくプロセス管理、ワークフローの仕組みが必要となる。HP Process Manager interactive（以下HP-PMi）はこうしたワークフローの機能を有し、Webサービスの連携とその管理に必要な機能を提供する。HP-PMiでは、ドローツールによって処理の流れを定義できるため、非常に高い柔軟性を保ちながらWebサービス間の連携を定義することができる。少し語弊があるかもしれないが、MVCモデルでのコントローラに相当する処理の制御ロジックをドローツールでビジュアルに定義し、モデルに相当するWebサービスの呼び出しとユーザとの対話であるビューを制御できると言えばイメージが湧きやすいかもしれない。
真の意味でのサービス連携をインターネットの世界で実現させるためには、そのほかにもセキュリティ、信用・保証などさまざまな問題が存在することは、既に論じられている通りである。 この連載では、真の意味でダイナミック・サービス連携を実現するためのさまざまな試みを、先進的な技術を実装したHPミドルウェア製品群「hp netaction」を通じて紹介していく。これらの製品群には、今回紹介したHP Web Services Transaction（HP-WST）、HP Process Manager interactive（HP-PMi）のほかに、以下の主要なミドルウェアが含まれる。
次回以降、個々のミドルウェアについて、詳細なプロダクトレビューを展開する。ご期待いただきたい。第2回は、Webサービスの基盤となるHP
Application ServerとHp Web Services Platformについて解説する。
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
