Webサービスの制限

まずは（EAIアプリケーションと対照的に）Webサービスの制限に（重要性の低い方から高い方に順番に）注目し、システム障害のしきい値が機能に対してどのようなインパクトを持つかについて考察しましょう。

制限その1: 複数のWebサービスが自身を実行することは滅多にありません。目的を達成するために複数のサービス実行を画策するには、SOAにある高レベルなサービスまたはビジネス・プロセスの連続をともなうことになります。これに反して、EAIアプリケーションは（ときにはWebサービスのコンダクター(conductor)として）自身を実行することができます。

制限その2:Webサービスは成長中の業界標準のリストを基にしているのにもかかわらず、SOAPは業界全体を通して完全に相互運用性を持つわけではありません。大半のEAIの標準は占有的(proprietary)なのです。

制限その3: 短時間でビジネス・プロセスを処理するWebサービスを（ビジネス・プロセス・ルールの複雑な組み合わせを基にした長期的なアプリケーションと関与する）他のWebサービスと統合させようとすると、問題が発生するかも知れません。なぜならば、Webサービスの消費者が常時いなくてはならないようにするためにWebサービスは疎結合であり同期的に実行されなくはならないからです。それに反して、EAIアプリケーションは密結合しており、同期的でも非同期的でもかまいません。SOAサービスの消費者が常時存在する必要はないのです。

制限その4:企業間にてアプリケーションの統合と集約において互いに協力しあう能力を持っていても、関係、チェーン管理、そしてリソース計画に焦点を合わせるWebサービスは異なる統合ルールを所持します。それとは対照的に、（チェーン管理とリソース計画を含む）EAIアプリケーション、レガシー・システム、データベース、Webサービス、そして非Webサービスの間のミドルウェアとして機能する統合ハブを介して、EAIシステムのコンポーネントは互いに通信します。

上に戻る

システム障害しきい値

Webサービスが滅多に自身に対して実行しないと言う主要な制限を考慮しましょう。SLAでのWebサービスの実行可能時間に対するシステム障害のインパクトは何でしょうか？実行可能時間のしきい値のインパクトを示すためにパフォーマンス・メトリックス(performance metrics)を開発するときに、何のシステム障害しきい値を確立すべきなのでしょうか？

1つ、それとも複数のWebサービス用のしきい値について語っているのでしょうか？Webサービスそして非WebサービスのコンダクターとしてのSOAにあるより高レベルのサービスのことを言いたいのでしょうか？Webサービスがタイムアウトになるとどうなるのでしょうか？タイムアウトがしきい値測定にもたらすインパクトはどのようなものなのでしょうか？

上に戻る

しきい値のシナリオ

まずは、可能性として考えられる3種類のしきい値（50%、67%、98%）を考慮してください。これらは何を意味するのでしょうか？図1に示されるとおり、しきい値50%は、0%から49.999%のシステム全体の障害が重要性を持たずパフォーマンス・メトリックスの一部として認められないことを意味します。例えば、99.5%の実行可能時間に向けてカウントされるには低すぎます。

それとは反対に、50%から100%の障害は重要でありメトリックスの一部として扱われるべきです。しきい値が67%そして98%の場合でもそれは同じです（図2と図3を参照）。例えば99.7%の実行可能時間に向けてより高いしきい値がカウントされます。

しきい値が高ければ高いほど、しきい値サービスをモニターするのにビジネスはより多くの代償を払わなくてはなりません。同様に、しきい値が高ければ高いほど、ある一定のしきい値に達しなかった場合にはプロバイダーはより高いペナルティーを課せられます。しきい値のペナルティーは、WebサービスのSLAにて指定される実行可能時間のペナルティーに加えてあります。

重要ではない しきい値

著者が執筆した過去の記事「SLAによるWebサービスの保証」（参考文献を参照）にて、デジタル音声が閲覧中のWebサイトに流れ乱れるとき、そしてマウス・カーソルが少しでも揺れた場合に、パケット損失の発生を知らせられることを述べました。乱れる音声と不安定なカーソルのどちらもが、人間の目では確認できないほどに短い一瞬の間にシステム障害があったかも知れません。しかし、パフォーマンス・メトリックのインディケーターは、システム障害が0.6%のしきい値で発生したことを示すイベントを自動的にログに記録します。

不安定なカーソルは、ユーザーが8から10秒の間まで我慢できるただ単なる小さな不快要素です。当然ですが、パケット損失の影響が極小なので、この障害のしきい値はかなり些細です。

重要なしきい値

重要なシステム障害のわかりやすい例は、プロバイダーの過失そしてモニタリングまたは測定のシステム障害による（クライアントの過失または故意の違法行為を除く）サービスの妨害です。表1は他の例外条項を羅列します。

これらの例外条項の全てが潜在的にSLAに包括されています。しかしながら、競争相手である他のサービスがより少ない例外条項でSLAを提供するかも知れません。そうであれば、（より高いシステム障害しきい値を含む）より優れたサービス保証付きのビジネス・オペレーションにてより多くの実行可能時間を提供する契約を選択するオプションをクライアントに与えることを推奨します。（保険または災害回復費用として認められないかぎり、『不可抗力』や『戦争勃発』は厳密に言えば例外です。）

タイムアウト

Webサービスがタイムアウトすると、どうなるのでしょうか？関連するWebサービスとのドミノ効果が発生し、それらも一緒にタイムアウトすることになり、システム障害につながるのでしょうか？タイムアウトがただひとつのWebサービスのみに影響をおよぼすにとどまり、ユーザーに再度のログインまたは今後の来訪を要求するメッセージの表示につながるだけであれば、障害はかなり些細な問題だと言えます。

これに反して、複数のWebサービスがほぼ同時にタイムアウトすれば、「Not Found」ページが表示されるかも知れず、ビジネス・プロセスの様々な段階にてユーザーへのサービス（例: 物品を購入するために小切手を発行したり認証したりなど）を大きく否定することになります。不安定なカーソルはパケット損失によるものかも知れませんし、タイムアウトするWebサービスが原因である可能性もあります。

上に戻る

Webサービスのパラダイム

図4にて示されるとおり、（特にプロバイダーからブローカー、プロバイダーからクライアント、そしてクライアントからプロバイダーの間にある）しきい値を第二世代Webサービス・アプリケーションのパラダイム（参考文献を参照）に応用しましょう。

しきい値を設定

図4にて示されるようなアプリケーション・プロバイダーがブローカーにサービスを発行するように要求を送信し、その途中で予期せぬ障害が発生した場合、システム障害しきい値は98.7%以上でなくてはなりません。ブローカーがサービス発行の成功または失敗のアラートをプロバイダーに送信し、パケット損失が発生すれば、ネットワーク障害は98.7%以上のしきい値にて重要になります。

しかしながら、（予期せぬ一時的な割り込まれたサービスによるサービス発見のステータスに対する）アラートをブローカーがクライアントに再送信すれば、システム障害しきい値は少々高くなり、SLAの契約にて指定されるWebサービス発見の重要性により、99.5%となります。クライアントとプロバイダーの間のシステム障害のしきい値は96.97%に設定されており、それは他の2つのしきい値よりも多少低いです。

変動的なしきい値

第二世代Webサービス・アプリケーションのパラダイムにあるプロバイダー、ブローカー、そしてクライアントの間のしきい値が双方向ともに同じ値である必要はありません。それぞれの役割のプレイヤーのしきい値は、方向によって異なり、そのうえ時期（例: ネットワーク・トラフィックの起伏の影響）によっても変動します。例えば、それはネットワーク・トラフィック、ボトルネックに入ったときに互いに競争する帯域幅、そしてSOAのWebサービスそして非Webサービスでの異なる帯域幅の要件に依存します。

例えば、プロバイダーがブローカーにサービス発行要求を送信する場合にはしきい値は98.5%に設定され、ブローカーがプロバイダーにアラートを送信する場合には98.7%となります。同様に、クライアントがブローカーにサービス発見要求を送信する場合にはしきい値は99.2%に設定され、ブローカーがアラートをクライアントに送信すれば99.5%となります。

上に戻る

しきい値への同意

大半のSLAは、実行可能時間の測定を（それらのSLAがあてていないシステム障害の範囲を隠す）『被覆』として扱います。この問題を回避する方法のひとつとして、SOAにて実行可能時間をテストするときに使える測定可能なしきい値を作成することがあげられます。

SLAが99.9%の実行可能時間を指定する場合に、SLAのシステム障害しきい値のリスト作成は、Webサービス・アプリケーションのどの予期せぬシステム障害が重要であるとクライアントが同意するかに依存します。例えば、潜在的に重要なシステム障害の問題へのしきい値98.1%にクライアントが同意したら、そのしきい値を実行可能時間99.9%の保証に応用できます。しきい値の契約を作成するうえで、クライアントを支援できます。

上に戻る

まとめ

実行可能時間への重大な負の影響をもたらす過去のシステム障害から見て発生する可能性の高いトラフィックのボトルネックそしてパケット損失による（可能性としてあり得る）、システム障害の範囲を考慮すべきです。この後、SLAにて指定されているように実行可能時間を最大化するためにWebサービス・アプリケーションをEAIに統合するソリューションのリストを作成しましょう。システム障害しきい値が高いほど、WebサービスのEAIへの統合での実行可能時間にSLAが提供する保証がさらに良くなります。

参考文献

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

著者について

この記事を評価する

コメント

上に戻る

目次

• Webサービスの制限
• システム障害しきい値
• しきい値のシナリオ
• Webサービスのパラダイム
• しきい値への同意
• まとめ
• 参考文献
• 著者について
• コメント