第一世代のアーキテクチャー

「SLAによるWebサービスの保証」（参考文献を参照）にて考察されるとおり、下記の図はSLAが取り扱うWebサービスのアーキテクチャーを表わします。ご覧のとおり、構造はとてもシンプルです。

Webサービス内で、サービス・プロバイダーが別のサービスを公開する間にクライアントがサービスを探し、サービスがプロバイダーにバインドされていれば、この構造はそのWebサービスと共にうまく機能します。互いのサービス・ロールをつなぐのは、それぞれ一本の矢印（上記の図を参照）のみです。

今日の日々複雑さを増し続けるWebサービスの世界では、このアーキテクチャーは不適切です。特にSOA（Service-Oriented Architecture: サービス指向アーキテクチャー）にて、次に挙げる4つの理由から、それは時代遅れになりつつあります。

• 理由1:発生するWebサービス・アプリケーションのタスクを完了する別のWebサービスを発見するWebサービスのアプリケーション・クライアントの必要性を、第一世代のアーキテクチャーは根本的に考慮しません。タスクを終了させるのに費やす時間は、割り込み無しで非常に長くなるかも知れませんし短いかも知れません。Webサービスの発見の成功または失敗を確認または検証するうえで重要なアラートをクライアントは受信しません。
• 理由2:プロバイダーが全てのサービスを何の問題も無く公開するように要求を送信し、ブローカーが100%の確率と信頼性でそれらを公開することを、アーキテクチャーは前提とします。リポジトリーでのサービス公開の完了の成功または失敗の通知を、プロバイダーはブローカーから受ける必要はありません。
• 理由3:WebサービスをWebアプリケーションと統合する上で次にどうするかで、プロバイダーから応答を受信する必要性をクライアントに強調しません。通信が同期（クライアントがATMで預金からお金を引き出す）または非同期（数週間もの間在庫切れで注文された品物にからむ長期的な取引期間）のどちらかであることを、統合は必要とするかも知れません。
• 理由4:SOAでは、照会またはWebサービス・アプリケーションへの要求に応答するのに必要とするリソースのために、Webサービス・アプリケーションが非Webサービス・アプリケーションと競合します。しかし、アーキテクチャーはそのSOAを考慮しません。それはインターオペラビリティーの課題がもたらす可能性を排除し、非Webサービス・アプリケーションをWebサービス・アプリケーションと統合すると言う論点を扱いません。

上に戻る

第二世代Webサービスのアーキテクチャー

第一世代アーキテクチャーの欠陥を修正するために、ブローカーからのプロバイダー・アラート（Provider alert）とクライアント・アラート（Client alert）そして通信（Communicate）を起動する仕組みに、SOA内のプロバイダーとクライアント間の処理を取り込みます。そうすることにより、サービス・ロール同士をつなぐ2本ずつの2方向の矢印（図2を参照）を取り入れる第二世代のアーキテクチャーが完成します。

プロバイダー・アラートとクライアント・アラートを両方とも独断で3種類（確認、検証、障害）に分類してみましょう。イベントにより、それぞれのタイプの内容は異なります。

例えば、アプリケーション・クライアントがWebサービス・アプリケーションの発見に成功したとき、ブローカーは発見の成功を確認または検証するためにアラートを発信します。もしもクライアントがサービスを発見できなければ、発見の試みが失敗したことを通知する別の種類のアラートをブローカーは送信します。

発見の成功を受信すれば、クライアントはそれをプロバイダーと共にバインドします。引き起こされるWebサービス・アプリケーションのタスクを完了させるには追加的なWebサービスをサービスが必要とするかどうかをプロバイダーが判断したら、次に何をするかについてクライアントと通信します。

アプリケーション・プロバイダーはサービスを発行するために要求をブローカーに送信します。もしもブローカーがそのリポジトリー内のサービスの発行を成功させたら、それはプロバイダーにアラートを送信し成功を確認させます。さもなければ、その発行への試みが失敗したことをアラートで知らせます。

上に戻る

SOA: 総括的な展望

Webサービス・アプリケーションはプラットフォームから独立したプロトコル（SOAP、WSDL、UDDI、HTTP）の上に構築されます。これらのプロトコルはWebサービスよりも昔から存在するSOAの必須条件を満たします。サービスが発見可能であり呼び出し可能なインターフェースを抱いてビジネス処理を実行することを、SOAは必要とします。

Webサービス以前の時代には、WebサービスはSOAに存在しませんでした。今日では、WebサービスはSOAの主力選手です。非Webサービス・アプリケーションまたはコンポーネントからなるEAI（Enterprise Application Integration: エンタープライズ・アプリケーション統合）アプリケーションを補足します。発見する照会、公開する要求、そしてバインドする要求に反応するのに持つべきリソースのために、Webサービス・アプリケーションは非Webサービス・アプリケーションと競合します。

（製造環境にSLA付きのWebサービス・アプリケーションが登場する以前から、SOAP、WSDL、そして他のインターオペラビリティー関連の問題がすでに解決されているという前提で）SOAは主に（企業をとおしてインターオペラビリティーをサポートするために）Webサービス標準を使用します。UDDIや他のパブリック・レジストリー内のパブリック・サービスとしてSLAを公開するSLA Webサービスをそれは包括します。応答時間のリソースにからむ競合の性能面のインパクトに与えられる技術面と資金面での権限と改善措置を、これらのWebサービスは扱わなくてはなりません。

Webサービス・アプリケーションのアーキテクチャーのロジックと類似する形で、SOAサービス・クライアントはサービスのためにディレクトリー・サービスを照会します。クライアントがサービスを検出すれば、ディレクトリー・サービスはプロキシーを介してサービスを呼び出すサービス・プロバイダーを入手します。他方では、クライアントがサービスを探せない場合には、それは失敗したサーチを表示するディレクトリー・サービスからのアラートを受信するかも知れません。同様に、プロバイダーがディレクトリー内でサービスを公開できないのであれば、それは失敗した試みを示すアラートを受信するかも知れません。

上に戻る

障害アラートを送信

様々な障害の事態から回復するうえでプロバイダーが踏まえるべきステップを、全てのSLAが含みます。それぞれのサービス・ロールが多種にわたる失敗事象（致命傷を除く）にどれだけの時間をかけて応答し、そして警告の失敗からどれだけの時間をかけて自動的に回復したかの情報を、通信そしてアラート・メッセージは包括すべきです。

この障害イベントのインスタンスはプロバイダーの制御下にあるべきです。サービスの保証が一定のレベル（例えば、99.9%未満の実行可能時間）で障害を起こす場合には、プロバイダーは回避すべき障害の種類、そして強制すべき権限と改善措置を決定する必要があります。それがプロバイダーの制御の手に負えないのであれば、プロバイダーと共に開発者はそれを（ハードの障害、通信の障害、ソフトウェアのバグに欠陥、そして画像表示システムに測定システムの障害のような）SLAの例外として受け入れるべきです。

障害によっては説明が回りくどくなりがちですので、実際のそして潜在的な障害の事態のそれぞれのメッセージにコード（数値（できれば16進数）、アルファベット、またはその両方）を割り当てる作業でプロバイダーを援助するのが得策でしょう。測定された応答時間にウェイトを割り当てる場合、任意的にコードを3種類のはっきりとしたカテゴリー（警告、重大、致命）に分けるべきです。もしもビジネス・オペレーションがあまりにも頻繁に割り込むのであれば、クライアントは繰り返し発生する問題への不十分な対処に不満を覚え、SLAを終了する条項を実装する権限の行使を希望します。

上に戻る

応答時間を測定

質問を送信し解答を返すのが、応答時間を測定する最も妥当な手段のひとつです。質問を集めた後、待ち時間、スループット、そしてフェイルオーバーを基に優先順位を付けられます。

待ち時間とは、データ・パケットがある地点から別の地点に移りそしてまた元の場所に戻る往復に費やす時間です。例を下に記します。

• データベース・サーバーでのSQL待ち時間
• Network AのルーターからNetwork Bのアプリケーション・サーバーへの待ち時間
• 動的なアラート(dynamic alerts)とバインディングの待ち時間
• 動的なアプリケーション統合(dynamic application integration)の待ち時間

スループットとは、与えられた特定の時間内にブローカーが供給できる要求の容量です。フェイルオーバー・テストは、Webサービス・アプリケーション用のフェイルオーバーの解決法がどれほどうまく機能しているかを測定します。待ち時間とスループットの間にあるトレードオフを、開発者は考慮すべきです。別の測定の要素として、デッドロック、ハングされた処理、そしてタイムアウト期間への修正処置をどれだけアプリケーションが提供しているかを考慮するのもあります。

疑問点

アプリケーションの修正そして新規アプリケーションの開発により、Webサービス・アプリケーションのパフォーマンスの向上に努めるには、ここに例として挙げられる疑問を投げかけるべきです。

• クライアントの照会に応答するのに、Webサービス・アプリケーションは時間を（例として、10秒間以上）かけ過ぎていないでしょうか？Webサービスが公開そして呼び出し不可能なときに、アラートをエンド・ユーザーに送信するのは可能なのでしょうか？
• プロバイダーにより開始させられた通信への応答に、Webサービス・クライアントは時間をかけ過ぎていませんでしょうか？Webサービス・クライアントがサービス発見に失敗したことを知らせるアラートをブローカーが開始するのに、時間をかけすぎているのでしょうか？
• サービス公開の要求への応答に、Webサービス・ブローカーは時間をかけ過ぎていませんでしょうか？サービスを公開または発見した後に要求を検証または確認するのはどうなっているのでしょうか？
• 多量のクライアントまたはプロバイダーの照会要求を処理するのに必要なリソースのために、SOA内にてWebサービス・アプリケーションは非Webサービス・アプリケーションを相手に競合しているのでしょうか？
• Webサービス・アプリケーションのネットワーク・トラフィックの増加は不適切なキャッシング・メカニズムによるものなのでしょうか？

これらの質問に答えるには、応答時間を測定する基準が正確でなくてはなりません。そうでなければ、（多種にわたるネットワークのシナリオで）サービス、パフォーマンス、そしてSOA内のサービス・レベルでの測定で、SLAは合意しなくなります。

クライアントの見解を考慮

次にあげられる1つの例では、合意を得たサービス・レベルが（とある特定の時間にてWebサービス・アプリケーションと非Webサービス・アプリケーションの異なる分配をそれぞれがともなう）ネットワークを3種類にわたり測定するとクライアントは思うかも知れません。

次にあげられる別の例では、合意を得たサービス・レベルが上記と同一の分配で同じネットワークを測定します。3種類のネットワーク全てにて実行される非Webサービス・アプリケーションを応答時間測定から除外すると、クライアントは確信を持つことでしょう。

タスクの連続を完成するための非Webサービス・アプリケーションへのWebサービス・アプリケーションからの呼び出しは、問題のさらなる複雑化につながりますが、これらの非Webアプリケーションが測定から除外されるとクライアントは思うかも知れません。表3にて示されるとおり、全てのWebサービス・アプリケーションが非Webサービス・アプリケーションに依存するわけではありません。

SLAをテストそしてモニター

PushtoTest（下記にある参考文献の段落にて、リンクをお使いください）に提供されるようなWebサービス用テスト・ツールだけが、SLAモニターとして機能するメカニズムではありません。例外条件を設定し、Webサービスの待ち時間、スループット、そしてキャッシング・メカニズムをモニターそしてチェックできます。これらの条件は合意を得られたSLAの一部としてリストされなくてはなりません。

上に戻る

まとめ

ここまでに、SLA付き第二世代Webサービス・アプリケーションのより進歩した技術パラメーターの説明をしました。もしも非Webサービスと相互反応するWebサービス・アプリケーションを（出費を惜しまない）顧客に提供することを予定しているのであれば、予測される投資への見返りをSLAが確証するのをその顧客たちが期待するのは当然のことでしょう。

顧客の期待に応えるために、待ち時間とスループットの測定の土台を築き上げるのに使える質問形式をともなう実例も提供しました。それらに妥当な解答を提供すれば、SOAにて合意を得たサービス・レベルに顧客が満足する可能性が少しは高まると思われます。

そうでなければ、クライアントとプロバイダーは権限、改善措置、そして例外を含む契約条件の再交渉に乗り出し、EAIアプリケーションへの補足として顧客を満足させるレベルを確立しなくてはなりません。開発者にとって、Webサービス・アプリケーションを非Webサービス・アプリケーションと統合しそれらを実装する過程でそれを心に留めておくのは大事なことです。顧客が抱くビジネスそして技術的な（SOAにて結果として得られる統合がどう振る舞うかの）期待を考慮に入れなくてはなりません。

参考文献

• PushtoTestについてより多くを学び、Webサービスをテストそしてモニターしましょう。
  
  
• システム・デザインの本質的な原理と優先権に焦点を合わせe-commerceと分散統合システムの登場により推進される新たな必須条件を強調する、Judith Myerson著の「The Complete Book of Middleware」をお読みください。
  
  
• 「Enterprise Systems Integration, Second Edition」を読むことにより、システム統合を成功させるのに欠かせられないビジネス的洞察力と技術的なノウハウを養えます。
  
  
• 公共の使用に適したGUIそして順応するAPIを備えるIIBMのUDDI version 2 registryにて、Webサービスまたはアプリケーションを発行しましょう。IBMのUDDIバージョン3ベータの登録もテスト用にあります。
  
  
• SLA付きWebサービスの第一世代アーキテクチャーへの例外そしてテストのメカニズムを取り扱う「SLAによるWebサービスの保証」（developerWorks、2002年04月）をお読みください。
  
  
• 現存のJavaコードからSOAPを基にしたWebサービスを構築するのであれば、「SOAPベースのWebサービスにおける複雑なデータ・タイプ」（developerWorks、2001年05月）を探究することにより、より多くを学べます。
  
  
• Dominoアドミニストレーター用のIBM Redbookを読み、サービス・レベル・アグリーメント（SLA）の実践的な仕組みに入り込みましょう。
  
  
• IBMからのJavaを基にした最新のソフトウェア開発ツールとミドルウェア（トライアル版）、それとオンラインのチュートリアルと記事、そしてオンラインの技術フォーラムを提供するSpeed-start Web servicesにて、Webサービスに関する知識（情報）、ツール、そしてスキルを取得しましょう。
  
  
• Webサービスに関連する数百ものタイトルを含む技術書物の包括的なリストのあるDeveloper Bookstoreを訪れてみて下さい。
  
  
• 知識欲の袋に底はないのでしょうか？SOA and Web services のページは、数百にもわたる情報豊かな記事と、Webサービス・アプリケーションの開発方法についての（初級、中級、そして上級の）チュートリアルを提供します。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• 第一世代のアーキテクチャー
• 第二世代Webサービスのアーキテクチャー
• SOA: 総括的な展望
• 障害アラートを送信
• 応答時間を測定
• まとめ
• 参考文献
• 著者について
• コメント