本文へジャンプ

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。プロフィールで選択した情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

  • 閉じる [x]

developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む


送信されたすべての情報は安全です。

  • 閉じる [x]

IT サービス・マネジメントに関する標準の進化

IBM Systems Journal: IBM Service Management: Volume 46, Number 3, 2007

本稿では、情報技術サービス・マネジメント (ITSM) の展開を促進する標準と広く導入されているベスト・プラクティスについて説明します。情報技術 (IT) サービスを提供するためのベスト・プラクティスの情報技術インフラストラクチャー・ライブラリー® (ITIL®) フレームワークを対象とします。ITIL の一部として、構成管理データベース (CMDB) が担う中心的役割について説明します。また、CMDB を支援するデータ・リポジトリーをフェデレートするための新しい標準である CMDB フェデレーション仕様について説明します。さらに、管理データとそれに関する制約を表現するためのサービス・モデリング言語 (SML) とソリューション展開記述子 (SDD) の 2 つの標準について説明します。最後に、関連性はあるが互換性のない Web サービス標準がどのように一貫した標準セットに統一されるかについて説明します。

はじめに

近年、企業は、顧客の要求により迅速に対応して、新しいビジネス機会をより巧みに獲得するようになってきました。この進化は情報技術 (IT) の進歩によってもたらされたものであり、世界中の企業が外部クライアントと内部ユーザーの両方の要件を解決するために IT サービスへの依存度を高めています。これらのサービスは、先進テクノロジーが組み込まれた IT インフラストラクチャー上に構築されています。その結果、テクノロジーとサービスが複雑に絡み合って動的に変化し、サービスの更新またはテクノロジーの刷新のための変更が頻繁に行われています。

IT サービスやサポート・インフラストラクチャーに対する変更は厳格に管理して中断を避ける必要があります。複数の管理者とオペレーターが、同じ IT コンポーネントの変更を計画して実行する権限を共有している場合があります。彼らがその活動を調整しなければ、妨害し合うことになりかねません。このように、サービスとインフラストラクチャー構成に対する変更は、変更管理プロセスを通して制御する必要があります。障害が発生した場合は、管理者とオペレーターがタイムリーにインシデントを記録、分析、および解決する必要があります。

新しいビジネス・プロセスをサポートし、コスト、複雑さ、および政府規制の順守に関する課題を解決するために、多くの IT 組織が、情報技術サービス・マネジメント (ITSM) への包括的なアプローチを実装しています。このアプローチでは、テクノロジーや IT システムに重点を置くのではなく、IT サービスとビジネス目標の整合に重点を置きながら、会社全体のパフォーマンスの最適化を追求します。

図 1. ITSM 標準

拡大図

IT 組織は、既存の IT インフラストラクチャーとプロセスを ITSM に変換する方法を模索しています。多くの場合、明確に定義されたプロセスの活用、それらのプロセスの統合、および変換をサポートするアーキテクチャーが必要になります。変換を支持する IT 組織は、標準ベースのソリューションを使えば、IT コンポーネントの相互接続性を向上させ、関連コストを節約するための新しいテクノロジーが利用できることを認識しています。標準に基づくソリューションによって、目標の達成が早まり、リスクが軽減されます。また、標準によって、内外のアプリケーションとデータを接続するために必要な相互運用性が向上します。さらに、標準によって、新しいハードウェアとソフトウェアを既存のインフラストラクチャーに迅速に統合できる能力が提供されます。ITSM への包括的なアプローチは、情報、プロセス、およびサービスに関する標準を活用して、人とテクノロジーが効果的かつ効率的に相互作用できるようにします。このように標準は、IT に不可欠な要素です1。

IT 管理に関する標準のすべてが、公認の標準化団体によって作成および承認されているわけではありません。デ・ジュリ (つまり「正当な」) スタンダードは、標準を発行する権限を与えられた団体によって作成されています。権限が、行政機関、国際協定、業界協定のどこから与えられたかに関係なく、その組織はその領域内において標準を発行する権限を与えられていることが広く認識されています。ITSM に関連した正当な標準化団体には、国際標準化機構 (ISO)、Internet Engineering Task Force (IETF)、Worldwide Web Consortium (W3C**)、構造化情報標準促進協会 (OASIS**)、Distributed Management Task Force (DMTF) などがあります。デ・ファクト (つまり「事実上の」) スタンダードは、広く使用されるようになった功績によって標準の属性が与えられたスタンダードです。この標準は、広く業界に受け入れられており、企業の膨大な投資を象徴しています。デ・ファクト・スタンダードが後になってデ・ジュリ・スタンダードとして採用される場合があります。

本稿では、ITSM に影響を与える可能性の高い既存の標準または新しい標準を中心に説明します。図 1 に示す ITSM 用のアーキテクチャーの観点からこれらの標準を取り上げます (このアーキテクチャーの詳細については、参考文献 2 を参照してください)。取り上げる標準は、IT プロセス、データ/メタデータ、および管理プロトコルの 3 つの領域に対応しています。

IT サービス・マネジメントに関するプロセス・ベースのベスト・プラクティスのセットである情報技術インフラストラクチャー・ライブラリー** (ITIL**)3-5 は、United Kingdom Office of Government Commerce で開発されました。国際標準化機構が、認定要件を設定することによって ITIL ベスト・プラクティスを形式化した ISO/IEC 20000-1:20056 (一般的には ISO 20000 として知られている) を発行しました。ITSM ソリューションは、ITIL のような一貫性のある堅牢なプロセス・フレームワークの使用から多くの恩恵を受けます。ITIL では、IT 組織が、効果的かつ確実にサービスを管理し、パフォーマンス、可用性、およびコストに関する目標を満たせるようにするためのプロセスが定義されます。たとえば、ITIL では、ユーザーの変更要求 (RFC) の提出から始まり、その変更を分析してその実施を計画し、他のサービスに対する容認できない影響を回避して、すべての変更が許可されていることを保証するために必要な手順を含む変更管理プロセスが定義されます。

ITSM ソリューションでは、データがプロセスによって共有され、他の管理ソフトウェアが保存される 1 つ以上のデータ・リポジトリー (図 1 の Data) が使用されます。保存されるデータ (およびメタデータ) には、IT コンポーネントに関する測定データとそれらの関係だけでなく、同じデータの許可された (期待された) バージョンを含めることができます。ここでは、構成管理データベース (CMDB) フェデレーション仕様、サービス・モデリング言語 (SML)、およびソリューション展開記述子 (SDD) の 3 つの新しいデータ関連標準について説明します。

CMDB フェデレーション仕様7は、外部クライアントからフェデレーテッド CMDB として見えるようにデータ・リポジトリーを管理する方法とクライアントがそのデータにアクセスする方法が記載された新しい標準です。CMDB フェデレーション仕様では、整合化するリソース ID と関連する管理データのどちらかまたはその両方に基づいて、複数のソースからのデータを単一のビューに合成するためのインターフェースが定義されます。たとえば、複数の管理ツールが、同じリソースに別々の ID を割り当てて管理している場合があります。そのデータが同じリソースに関するものであることを知らない IT プロセス同士が妨害し合うことになり、IT インフラストラクチャー内の問題や不安定さにつながる可能性があります。CMDB フェデレーション仕様を通して、この単一のビューを使用すれば、複数の ID を相互に関連付けることができるため、信頼性の高い、予測可能なプロセスが実現します。

サービス・モデリング言語 (SML)8 は、IT リソースとそれらの相互関係を記述するための拡張マークアップ言語 (XML) スキーマに対する拡張を規定した新しい標準です。関連仕様の SML Interchange Format (SML-IF)9 には、標準的な交換手段で SML モデルを表現する方法が記載されています。SML と SML-IF を使用することによって、基になるテクノロジーが全く異なる場合でも管理ツールとプロセスの統合が支援されます。実装を分離することによって、IT 組織は、ITSM 実装における統合と一貫性の目標を犠牲にすることなく最良のソリューションを提供するコンポーネントをより柔軟に選択することができます。

SDD10 は、OASIS から提案された、インストール可能なソフトウェア・パッケージとその構成、依存関係、およびライフ・サイクル情報を表現するための新しい標準です。この情報は、ソフトウェア・ソリューションの展開における手作業を自動化するために使用されます。SDD のような標準がなければ、IT スタッフは、ソフトウェア・パッケージごとにその接続方法と構成方法を理解する必要があります。これは、大きな負担であり、多くの場合、ソフトウェア・パッケージの構造や要件に関する知識の不足によって信頼性が低下することになります。ITSM ソリューションは、各ソフトウェア・パッケージを熟知している開発者が SDD を使って必要な情報を明示的に提供することによって、より高い信頼性と効率性を実現します。

IT 環境内のリソースを管理するための Web サービスに基づく標準11-13が、数多く作成されています。ここでは、OASIS からの Web Services Distributed Management (WSDM) と DMTF からの Web Services for Management (WS-Management) に関連した、似ているが互換性のない標準のファミリーを統一する提案標準を中心に説明します。これらのプロトコルを単独でまたは組み合わせて使用することによって、異機種環境内のリソースを管理することができます。たとえば、リソースに対するアクセス・レイヤーを実装するコンポーネントに、WS-ResourceTransfer 仕様と WS-EventNotification 仕様を実装することができます。管理ツールで、WS-EventNotification を使用してリソース状態変更に同意することができます。リソース・アクセス・コンポーネントから通知を受け取ったら、WS-ResourceTransfer を使用して詳細なリソース・プロパティーを参照したり、リソースを構成することができます。これによって、コンポーネント実装を制限することなく、コンポーネント間の相互運用性を改善することができるため、ITSM ソリューションでは Web サービスに基づく管理プロトコルがよく使用されます。

本稿の残りの部分は以下のように編成されています。続く 5 つのセクションでは、ITIL、CMDB フェデレーション仕様、SML、SDD、および Web サービス・ベースのプロトコルの個々の標準を取り上げます。最後から 2 つ目のセクションでは、レビューした標準に関する見解を示します。最後のセクションはまとめです。

ITIL/ISO 20000

ITSM の基本的な目標は、企業がすべてのビジネス・プロセスに応用できるような、同種の品質管理を使った IT サービスとインフラストラクチャーの管理です。これが実現すれば、企業は、自信を持って、その使命に不可欠な新しいまたは更新されたサービスを展開することができます。これを実現するための広く受け入れられている方法は、プロセス・フレームワークを通した管理です。

最も普及している IT サービスとインフラストラクチャーの管理用プロセス・フレームワークである ITIL は、IT 管理とビジネス要件を整合させるためのベスト・プラクティスのセットです。ITIL の導入によって、サービス品質が改善され、IT サービスのプロビジョニングと管理用のコストが削減される可能性が高くなります。

ITIL Version 2 は、IT 管理のいくつかの側面に関するベスト・プラクティスが記載された一連の資料で構成されています。本稿では、サービス・サポートとサービス・デリバリーで構成されたサービス・マネジメントを中心に説明します。これらは、ITIL の最も広く使用されている部分であり、ISO 20000 の基礎になっています。また、最も需要の多い個人証明書として使用されているシラバスの基礎にもなっています。

ITIL v3は、「テクノロジー・ベースとビジネス要件の継続的な進化に合わせて変化するユーザー・ニーズを解決すること」によって、また、「その小規模組織への適用可能性を強化して適用すること」によって、ITIL の実用性と適用可能性を向上させます14

ITIL は、ベスト・プラクティスが記載されたフレームワークですが、ソリューションを保証または制約するものではありません。たとえば、複数のすべてのインストール環境で ITIL とすべて完全に調和しながらも相互運用は行わない、というプロセスが構築される場合もあります。実装者には、それぞれのビジネス・ニーズにあったベスト・プラクティスを導入することが推奨されています。それでは、その価値はどこにあるのでしょう。その価値は、2 つの主要なソースからもたらされます。

まず、ベスト・プラクティス自体が、さまざまな IT 環境においてその価値を証明しています。このようなプラクティスを実装した組織は、現行のプラクティスにつながった累積経験に基づいています。したがって、ITIL からのガイダンスを応用しない場合によく行われる試行錯誤はしなくてすみます。

さらに、異なるプロセス実装の間で自動的に直接の相互運用が行われない場合でも、共通の用語やアプローチといった共有概念によって相互運用性の問題を軽減することができます。たとえば、2 つの IT 組織を合併する場合の最初のステップが、バックエンドのインシデント処理を数カ月間分離したまま、単一のサービス・デスクに統合することだとします。両方のインシデント管理プロセスの概念、定義、およびインシデントとその処理方法の記述が似ている場合は、どちらかのインシデント・レコードを変換するだけでこの統合は完了します。別のアプローチを使用した場合の統合には、多くのコストと困難が伴う可能性があります。

ITIL v2 サービス・サポート

サービス・サポートは、組織が ITIL フレームワークに基づくベスト・プラクティスを導入する場合の最も一般的なスターティング・ポイントです。サービス・サポートには、5 つのプロセス領域 (構成管理、変更管理、リリース管理、インシデント管理、および問題管理) と 1 つの機能 (サービス・デスク) があります。

  1. 構成管理 - このプロセスは、サービス・サポートの土台であり、他の ITIL プロセスの統合ポイントです。構成管理データベース (CMDB) は、構成管理プロセスの中心的コンポーネントです。CMDB には、単一の構成アイテム (CI) のライフ・サイクルと CI 間の関係が記述された構成レコードが保存されます。CI は、IT サービスを提供するために管理する必要のあるコンポーネントを意味します。CI には、ハードウェア、ソフトウェア、ビル、人、およびプロセス文書やサービスレベル・アグリーメント (SLA) などの正式な文書が含まれます。CMDB の商用実装には、多くの場合、インシデント・レコード、問題レコード、変更レコードなどの CI にリンクされたその他の情報が含まれます。

    構成管理プロセスでは、適切な制御文書なしで追加、変更、置換、または削除された構成レコードが存在しない (よって、対応する CI も存在しない) ことが保証されます。検証プロセスと監査プロセスでは、CI の物理的存在が確認され、構成レコードが正しく CMDB に記録されていることが保証されます。

    CMDB は、1 つの論理データベースです。実際には、CMDB の多くは、特に、組織が ITIL プロセスで管理したいすべての種類のデータを含んでいる場合に、複数のデータ・リポジトリーで構成されます。

  2. 変更管理 - これは、実際の CI とそれらの関係に対する変更を管理および制御するプロセスのセットです。CI とその関係に関する記述を管理する構成管理と変更管理の役割を比較してください。変更管理プロセスと構成管理プロセスの両方を使用すれば、IT 組織は、変更を計画および制御し、変更に関する記述と IT 環境の状態を確認することができます。変更管理プロセスは、クライアントまたは IT スタッフ・メンバーが変更要求 (RFC) を提出したときに開始されます。RFC には、「新しい注文処理サービスの展開」や「次の休暇シーズン中の 25% のトランザクション負荷の増加に対応するためのキャパシティーの増加」などのビジネス関連用語で必要な結果が記述されます。

  3. リリース管理 - このプロセスは、特に、実装が複雑な場合に、承認された変更を実施するために多く使用されます。影響を受けるコンポーネントの数や実装者間に必要な調整レベルなどの複数の要因が変更の複雑さの決定に影響を与えます。IT 組織によっては、すべての変更をリリース管理を使用して実施する場合と、簡単な変更はリリース管理を使用せずに実施する場合があります。

  4. インシデント管理 - これは、サービス中断に対処するプロセスのセットです。理想的な世界では、テクノロジーが停止することはなく、サービスとテクノロジーが正しく設計され、新しいまたは更新されたサービスの展開のすべてが完璧に計画および実行されます。もちろん、実際には、このような理想はいずれも現実にはなりません。環境は複雑すぎるし、変更は頻繁に行われるし、コストと時間の圧力は大きすぎるし、サービス、ビジネス・プロセス、および IT インフラストラクチャー間の相互作用の知識は不足しています。事態は悪化しています。少なくとも、クライアントの視点からはそのように見えます。インシデント管理のエントリー・ポイントは、サービス・デスク機能です。IT スタッフは、サービス・デスクを利用して、インシデントの進捗を記録および監視し、インシデントの優先順位を管理します。

  5. 問題管理 - このプロセスは、インシデントの根本原因の特定と、問題が解決されるか、恒久的な代替案が特定されるまでの問題の追跡を担当します。問題によっては、インシデントの調査中に発見されるものがあります。その他の問題は、インシデントの分析中か、可用性管理プロセスなどの他のプロセスによる分析中に発見されます。たとえば、問題によっては、クライアントからインシデントが報告されるほど深刻ではないが、再発する問題の累積効果がサービス・レベルに悪影響を及ぼしかねない場合があります。問題の解決には、開発者によるソフトウェアの再設計、ソフトウェア・パッチのインストール、性能を向上させるためのコンポーネントの置換または再構成などさまざまな形態があります。

ITIL v2 サービス・デリバリー

サービス・サポートは日常業務に重点が置かれるのに対して、サービス・デリバリーは IT サービスの計画と改善に重点が置かれます。サービス・デリバリーは次の 5 つのプロセスで構成されます。

  1. サービス・レベル管理 - このプロセスは一般的なスターティング・ポイントです。IT 組織は、顧客 (内部または外部) と SLA について交渉します。この契約では、エンド・ユーザー応答時間、許容可能な予定されたまたは予期せぬダウン時間、コストなどのサービス・レベルが設定されます。SLA によって、サービスを請け負うビジネス・ユニットと IT の間の直接的なリンクが確立されます。

  2. 可用性管理 - このプロセスは、ビジネス・サービスの可用性の計画、監視、および改善を担当します。また、平均故障時間やリカバリー時間などの可用性メトリックとサービス・レベルの提供コストの間の最良のバランスを維持しようとします。アナリストがエンド・ユーザーに対する可用性を向上させるための冗長性を計画する場合がありますが、この可用性の向上には一定のコストがかかります。

    可用性管理には、サービスまたはコンポーネントが中断後に通常動作に回復させるプロセスの計画、つまり、保守容易性も含まれます。

    図 2. フェデレーテッド CMDB アーキテクチャー

    拡大図

  3. キャパシティー管理 - このプロセスは、ビジネス・サービスを提供するためのキャパシティーの計画、監視、および改善を担当します。キャパシティー管理は、キャパシティーとコストの間の最良のバランスを維持しようとします。キャパシティー・マネージャーの仕事には、時間当たりのキャッシュ・レジスターの売上高などのビジネス指向の要件を、キャッシュ・レジスターの売上高が推定できる時間当たりのデータベース・トランザクション数に変換することが含まれます。

  4. IT サービス財務管理 - このプロセスは、IT サービス・プロバイダーの予算、経理、および課金に関する要件の管理を担当します (資本コストと減価償却については、本稿では説明しない資産管理と呼ばれる別のプロセスに含まれます)。

  5. IT サービス継続性管理 - このプロセスは、可用性管理と特徴が似ていますが、対象が異なります。可用性管理では、特定のサービスとコンポーネントに重点が置かれ、多くの場合、数秒または数分の時間で処理されます。IT サービス継続性は、このような時間で処理することが可能ですが、何時間または何日という時間のかかる大規模なリカバリーに対処する場合がほとんどです。たとえば、洪水によって計算センターが使用不能になった場合は、どうやって代替サイトをオンライン化し、どうやってオンライン化が完了するまで最低限のサービスを提供しますか。

CMDB フェデレーション仕様

IT 管理データ (変更データ、構成データ、問題データ、インシデント・データ、資産データ、リリース・データなど) は、社内の到る所にあります。複数の別々に開発された分散データ・ソースから意味のある情報を収集するのは、技術的観点から見て、特に、ベンダー間でインターフェースやデータ・モデルが異なる場合は、非常に困難な仕事になります。ツールやサービスに対する複数ソースの使用がランドスケープの大きな部分を占めているため、広く使用されている ITIL 資料に対する更新では、複数ソース環境のサポートが重要なドライバーの 1 つと見なされています。多くの組織が、構成とその他のデータをフェデレートする CMDB を IT 管理のベースにしようとしています。これは、図 2 に示されているように、共有データを中心として構築される ITSM アーキテクチャーと調和します。IT プロセスと管理ツールは、相互に調整し合うためと自動運用の基礎としてデータを使用します。

管理データ・リポジトリー (MDR) をリポジトリーごとの内容の全部または一部を担当する仮想 CMDB にフェデレートする方法を定義した仕様を開発するために協力している企業もあります7 。一般的に、フェデレーテッド CMDB は、データを正規化し、同じリソースに複数の名前が付けられている場合にリソース名の整合をとり、データが重複している複数のソースを解決します。フェデレーテッド CMDB は、複数の重複していることの多いデータ・ソースとツールを含む環境で IT プロセスを実装するために使用されます。多くの場合、すべての管理データを 1 つのデータ・リポジトリーで維持するのは実用的でも理想的でもありませんが、データのさまざまなサブセットを統合するのは実用的かつ理想的な場合があります。

ITIL によって定義された CMDB には、IT 環境の許可構成のレコードが保存されます。この仕様におけるフェデレーテッド CMDB は、情報が仕様のパターン、スキーマ、およびインターフェースに準拠している限り、管理者が構成するすべての管理情報をフェデレートするように基本定義を拡張します。たとえば、図 2 に示されているように、フェデレーテッド CMDB には、実際の構成だけでなく、許可構成、変更履歴、インシデント・レコードと監査レコード、ステータス変更イベント、およびその他の関連情報 (推奨または予定されている将来像や RFC などのプロセス成果物など) を含めることができます。仕様では、これらのデータのすべてをアイテムと呼びます。

フェデレーテッド・アプローチの主なメリットは、すべてのデータを中央のデータ・ストアに複製しなくてもデータの一貫したビューを作成して維持できることです。また、管理ツールで既存のデータ・ストアを使用し続けることができるため、組織は、フェデレーテッド CMDB 内のデータに移行する時期と方法を柔軟に決定することができます。このフェデレーテッド CMDB を作成するためのアプローチは、さまざまな MDR、管理ツール、および IT プロセスに対応します。

このアーキテクチャーには、主要な 2 つの要素 (フェデレーテッド CMDB と MDR) があります。フェデレーテッド CMDB は、管理、リソース・フェデレーション、およびリソース・クエリー・サービスを実装します。MDR は、リソース・クエリー・サービスを実装します。

CMDB は、管理対象リソースと相互作用するためのプロキシーではありません。たとえば、CMDB 内で関係インスタンスを作成しても、実際のリソース関係の構成は変更されません。CMDB モニターの範囲外にあるエージェントとリソースを変更するエージェントを分離してください。同様に、各 MDR でデータの取得に使用されるメカニズムも、またデータの保存に使用されるメカニズムとフォーマットも仕様の範囲外です。フェデレーテッド CMDB 仕様は、データの交換にのみ関係します。データの管理方法は規定しませんが、ITIL プロセスの使用の有効化も対象とします。

サービス・モデリング言語

企業によっては、CMDB の中核を形成する正式なデータのソースが多数存在する場合があります。2 つのデータ・ソース間の情報交換は、そのフォーマットに互換性がない場合に問題になる可能性があります。データベース・キーなどの従来の技術的アプローチでは、データを一意的に識別して相互に関連付けることができますが、相互作用するコンポーネントが必要以上に緊密に結合される場合がほとんどです。さらに、このアプローチは、データに適用する制約を明示的に表明する方法が存在しないために、他のコンポーネントによって作られた前提に関する暗黙の知識を持ったコンポーネントに依存する可能性があります。

さまざまなベンダーからのさまざまな実装によって、特定のリソースに含まれる情報の種類に影響を与えるさまざまな範囲と深さの結論が下される可能性があります。ソフトウェアの設計とそれに続く実装にこれらの決定が反映されます。たとえば、資産データ・ストアとインシデント・データ・ストアを比較してみましょう。この例では、資産管理システムは、粒度の粗いマシン属性に重点を置いて物理的な場所や価値を重視するのに対して、インシデント管理システムは、粒度の細かいマシン属性に重点を置いて IT インフラストラクチャー内の論理的な場所を重視します。この 2 つの管理システムは似ていますが、その目的は異なります。この 2 つのシステムはどちらも、複数の同じリソースに関する情報を必要としますが、必要な情報の範囲や粒度が異なります。このような違いが、この 2 つの管理システムのデータを相互に関連付ける場合の困難さにつながる可能性があります。

サービス・モデリング言語 (SML) とその関連 SML Interchange Format (SML-IF) の目的は、このような要件を解決することです。これらは、フェデレーテッド CMDB を構成するデータ・リポジトリーなどの管理システム間のデータ交換で重要な役割を果たすことが期待されています。

SML の概要

SML モデルは、IT リソースとそれらの相互関係のセットを記述するための XML 文書の集合です。すべての SML モデルには、定義文書と呼ばれる、モデルを構成する文書のサブセットが含まれています。定義文書には、スキーマ文書と制約文書の 2 つのカテゴリーがあります。モデル内のスキーマ文書は、SML プロファイルと XML Schema 1.015 への拡張に準拠した XML 文書です。モデル内の制約文書は、SML プロファイルと Schematron16 の拡張に準拠した XML 文書です。定義文書は、モデル全体が有効かどうかを判断するためにモデル・バリデーターが必要とするほとんどのデータを提供します。SML 内のモデル妥当性検査はモデルを構成する文書間の依存関係に左右される場合があるため、ある意味で有効な文書を既存の有効なモデルに追加した結果、そのモデルが無効になる可能性があります。

インスタンス文書と呼ばれる、モデル内のその他の文書には、モデルが表現する個々のリソースが記述されます。インスタンス文書は、定義文書で定義されたスキーマと制約に準拠します。大まかに言うと、SML モデルは、ノード間を弧で結んだグラフです。モデルのインスタンス文書がノードを形成し、明示的な文書間参照が弧を形成します。

SML 内のスキーマ

XML スキーマ妥当性検査の世界では、SML スキーマは他のスキーマと同様です。一連のスキーマに対して妥当性検査が可能な文書は、それらのスキーマに対して有効な場合と無効な場合があります。SML は、XML Schema 1.0 を拡張して、スキーマ作成者に、作成するスキーマに準拠した文書の形式と内容に対して制約を追加する手段を提供します。文書間制約と呼ばれるこの制約は、XML Schema に組み込まれた Schematron ルールの形態をとります。この制約によって、作成者は、特定の要素の属性を同時に発生させるかどうかなどを指定することができます。文書間と文書内の制約を指定できる (XML では指定できない) この能力によって、フェデレーテッド CMDB のより堅牢な実装の促進が期待されます。

また、SML によって、スキーマ作成者は、モデル内のインスタンス文書がモデル内の他の文書と依存関係があるかどうかを指定することができます。この種の依存関係が満たされない場合は、すべてが有効な文書で構成された集合が無効なモデルになる可能性があります。たとえば、サーバーに取り付ける特定の種類のイーサネット・アダプターをモデル化するために、その種類のイーサネット・アダプターをモデル化するスキーマで、文書インスタンスのそれぞれを、サーバーをモデル化する文書のインスタンスに関連付けるように要求されているとします。サーバーをモデル化する文書と関係のないその種類のイーサネット・アダプター文書を含むモデルは無効になります。

SML 内の制約

制約文書は、SML モデルに関する一種の「物理的過程」を形成します。モデルのスキーマによって文書に配置される制約に加えて、制約文書を特定のインスタンス文書にバインドすることができます。制約文書には、構成するモデル内の文書の形式を制限する Schematron ルール・パターンが含まれています。制約文書の範囲は、モデル全体の、個々の文書だけでなく、文書間の参照も制限できる能力です。制約文書は、モデル全体のポリシー設定などのさまざまな目的に使用することができます。

図 3. SML 内の文書間参照

拡大図

SML 内の参照

XML 文書では、1 つの単位として扱う必要のある内容に境界を設定します。XML Schema では文書間参照がサポートされていません。SML は、図 3 に示されているように、文書間参照をサポートするように XML Schema を拡張し、文書間参照に関する一連の制約を追加します。図 3 の各部分は、文書定義 B への参照を含む文書 A に関するスキーマ定義 (XML 属性の sml:ref=true で指定される) を表しています。このモデルを有効にするには、B の参照元が A の定義内の制約を満たす必要があります。文書間参照のサポートには、以下が含まれます。

概して、リソース情報の標準的な表現によって管理ツール間の情報の交換とリコンシリエーション (整合化) が促進されるため、SML によってリソースのモデリングの統一が支援されます。SML とSML-IF は、フェデレーテッド CMDB の要件にうまく適合します。加えて、交換する文書内の制約の妥当性検査によって、矛盾の検出が早まり、結果的に、IT 管理の堅牢性と効率性が向上します。

ソリューション展開記述子

開発者は、オペレーティング環境とそれに対するソリューションの構成方法に関する一連の前提条件に基づいてソリューションを構築します。この作業は、IT 管理者とオペレーターが、ソリューション要件とインストールおよび実行要件に伴う文書を理解しているかどうかにかかっています。管理者は、ソリューションと環境の互換性を評価して、ソリューションを正しく構成する必要があります。これは、さまざまな理由で間違いの元になる作業です。文書は、不十分な場合や不正確な場合があります。文書があいまいな場合は、IT スタッフの解釈が意図したものと異なることがあります。環境は、開発者が期待した環境と物理的に異なる場合があります。ITSM プロセスは、ソフトウェアのライフ・サイクルを通した前提や要件が、開発者、パッケージャー、ソリューション・インテグレーター、およびソフトウェアの展開プロセスや管理プロセスの参加者によって正式にコード化された場合に堅牢性が向上します。

SDD は、インストール可能なソフトウェア・パッケージとその構成、依存関係、およびライフ・サイクル情報に関するメタデータを表現するための新しい標準です10。伝統的に、ソフトウェア開発者が、インストール・ガイドの中でインストール要件を文書化し、ユーザーにその理解と順守を期待します。ソフトウェア開発者は依存関係がどのようなものかを理解しているため、ユーザーに依存するのではなくソフトウェアでシステムをチェックするべきです。依存関係とその他の要件を定義して検証する能力は、標準的なソフトウェア展開情報に基づくソリューション・インストール・テクノロジーの主要なメリットの 1 つです。SDD は、依存関係や他の要件に加えて、ソフトウェア展開に関する重要な情報を記述するためのメカニズムを提供します。ソフトウェア要件のチェックには、オペレーティング・システム・タイプの確認、十分なメモリーとディスク・スペースが存在することの保証 (インストール中とインストール後)、および他のソフトウェア・パッケージに関するすべての依存関係の検証と構築が含まれます。

展開情報に加えて、SDD ではソフトウェア・パッケージ情報も規定されます。現在は、多くの Linux** 配布や AIX* ファイル・セットで使用されている RPM (元は Red Hat Package Manager) フォーマットなどの同様の情報を含む数多くのパッケージ・フォーマットが存在します。ただし、パッケージは、独自仕様のフォーマットで成果物に組み込まれ、ターゲットのホスティング環境固有のアプリケーションによってのみ使用される場合がほとんどです。SDD は、パッケージ内とパッケージ間の関係を含むパッケージに関するメタデータを正式な標準フォーマットで外部化します。

パッケージと展開情報を表現するための複数の独自仕様の方法に関する課題を解決するために、OASIS は、SDD Technical Committee を設立して、ソフトウェアのインストール可能なユニットの特性を記述するための仕様とスキーマを開発してきました。ソフトウェアの展開、構成、および保守用のプロセスで、これらの特性を利用することができます。Installable Unit Deployment Descriptor Version 217 が SDD 仕様の基礎になっています。この委員会は、Open Grid Forum work groups for Application Content Services (ACS)、Job Submission Description Language (JSDL)、および Configuration Description, Deployment, and Life-Cycle Management (CDDLM) とも協力関係にあります。ACS ワークグループは、2006 年 9 月に SDD パッケージ記述子の使用を正式に承認しました。

参考文献 18 に SDD の詳細が記載されています。

Web サービス管理プロトコル

現在の IT 環境はさまざまな機種が混在しています。

既存のコンポーネントの多くが、標準化されたインターフェースを使用していないため、お互いにうまく通信することができません。Web サービスに基づくサービス指向アプローチによって IT 管理コンポーネントの統合が可能になります。

Web サービス分散管理

Web サービス・テクノロジーが、特に、異種の実装テクノロジーとプラットフォームを使って構築されたアプリケーションの統合に関する全般的な問題を解決します。システム管理ドメインに Web サービス・テクノロジーを適用することによって、管理可能リソースと管理容易性コンシューマー間の共通メッセージング・プロトコルを実現します。

WSDM は、Web サービスを使用した管理と Web サービスの管理に関する一連の仕様です。この仕様には、リソースを管理するための Web サービスの使用方法と他の Web サービスを管理するための Web サービスの使用方法が記載されています。WSDM は、Web Services Resource Framework リソース・アクセス仕様を利用しています。管理可能リソースを Web サービス・リソースとして扱うことによって、管理可能リソース情報にアクセスするために必要なインターフェースの一貫したセットが提供されます。WSDM 標準では、管理対象リソースとそれらのコンシューマーに対してこの共通メッセージング・プロトコルが規定されています。一方、管理対象リソースのプロパティー、オペレーション、関係、およびイベントに関するデータまたは情報モデルは規定されていません。WSDM では、Simple Network Management Protocol (SNMP)19、Common Information Model (CIM)20、独自仕様モデルなどの任意のリソース汎用モデルで記述されたリソース用の Web サービス・インターフェースが提供されます。したがって、WSDM インターフェースでラップされたレガシー・アプリケーションによって、すでに使用されているモデルへの Web サービス・アクセスが提供されます。

図 4. Web サービス管理仕様の統一

拡大図

WSDM アーキテクチャーの中心は、管理可能リソースの Web サービスとしての表現を可能にする管理容易性インターフェースです。WS-Addressing 標準21で定義されているエンドポイント参照 (EPR) によって、管理容易性エンドポイントで特定の管理可能リソースにアクセスする手段が表現されます。この管理容易性エンドポイントの後ろにある実装で、管理可能リソースに関する情報の取得と操作を可能にする必要があります。管理容易性コンシューマー (管理ツール) が、EPR で表現された場所にメッセージを転送します。コンシューマーが通知の受信を申し込んでいる場合に、管理可能リソースがコンシューマーに直接通知を送信するモデルも用意されています。管理可能リソース用の WSDM 機能は、プロパティーの取得と設定に WS-ResourceProperties 仕様を使用し、管理容易性コンシューマーに対するイベントの伝達と分配に WS-Notification 仕様ファミリーを使用することによってアクセス可能にすべき標準にマップされます。

Web サービス管理仕様の統一

WS-Management は WSDM と互換性のある仕様です。前述したように、WSDM と WS-Management はどちらも、リソース、イベント、および管理に関する機能を提供する他の Web サービス仕様を参照したり、組み込んだりしています。

IBM、Hewlett-Packard Development Company、Intel Corporation、および Microsoft Corporation は、Web サービス管理仕様を統一する必要性を認識しており、公開済みのロードマップに記載されているように OASIS WSDM と DMTF WS-Management の委員会からの仕様に含まれている要件を満たす共通仕様を作成中です22。このセクションでは、Web サービスを使用してシステム・リソースを管理するための共通機能を定義する仕様の素材と状況について簡単に説明します。WSDM/WS-Man Reconciliation23 には、WS-Resource Framework 仕様から、ロードマップに記載された新しい統一仕様への詳細なマッピングが記載されています。

図 4 は、既存の仕様のスタックと予定されている仕様の結果スタックを示しています。既存のスタックはどちらも、Web サービス・プロトコルを使用したリソースの XML 表現の作成、取得、更新、および削除手段を提供します。また、どちらのスタックも、リソース表現内の変更に同意するための手段だけでなく、それらのイベントを伝達する手段も提供します。この統一では、管理固有の仕様ではない WS-Metadata Ex-change24 も、リソース仕様で定義されたメッセージ内の一部の技術的重複を排除するように変更しました。

管理仕様が、両方の取り組みに含まれていたユース・ケースのすべてに対応していることを保証するためには、特定の機能が別々の仕様に分かれる可能性があります (図 4 の共通管理仕様内の桃色のボックス)。このような仕様は不要になることが理想です。新しい仕様の機能は、次の 3 つの主要領域に分割されます。

(1) 情報管理、(2) イベントと通知、(3) 管理仕様とプロファイル

WS-Transfer と WS-ResourceProperties の両方で、Web サービス・プロトコルを使用してリソースの XML 表現にアクセスおよび操作するための手段が提供されます。WS-ResourceProperties と WS-Management の開発を促したさまざまなユース・ケースを検証することによって、統一の取り組みを通して 1 つの共通仕様である WS-ResourceTransfer が作成されました。WS-ResourceTransfer は、リソースの完全な表現と部分的な表現の両方 (フラグメント) にアクセスおよび操作する手段によって最新バージョンの WS-Transfer を拡張したものです。オペレーション中に、対象のサブセットを示す表現によってフラグメントが特定されます。この仕様によって、表現の形成に使用される方言 (または言語) を実装で指定することができます。リソースでサポートされている方言は、リソースのメタデータを通して発見することができます。特定のリソースでサポートされている方言に加えて、WS-ResourceTransfer では、リソースのライフ・サイクルに関するメタデータも定義されます。

WS-Eventing は、単純で相互運用可能なパブリッシュ/サブスクライブ・システムを実現する既存の仕様です。統一の取り組みの一部として作成される新しい仕様の WS-EventNotification は、WS-Notification 仕様からの機能を使って WS-Eventing 仕様をベースに構築されます。WS-EventNotification に追加予定の機能は、サブスクリプション、ポリシー、より豊富なフィルター言語の指定、サブスクリプションの停止、およびサブスクリプションを管理可能リソースとして扱うための手段です。

現在の管理仕様にはさまざまな相違点が見られますが、その多くは基になるリソース仕様が異なるためです。新しい WS-ResourceTransfer 仕様と WS-EventNotification 仕様をベースに開発中の新しい管理仕様とプロファイルでは、新しい統一仕様でサポートすべき WSDM 仕様と WS-Man 仕様ファミリーの両方からのユース・ケースを考慮する必要があります。

考察

ITSM に関する標準の未来は全く予測不能です。一般的に、標準は市場の要求に応じて進化し、新しい標準または拡張標準の価値の評価には時間がかかります。ITSM に関する最も古い標準は、SNMP19 や CIM20 などのリソース・インターフェースを定義するものです。これらの標準は、Web サービス標準によって拡張または置換されつつありますが、これらの基本的性質が大きく変化することはありません。コンポーネントを相互に接続するのに適したインフラストラクチャーであるサービス指向アーキテクチャー (SOA) をサポートする標準への進化は継続されるでしょう。SOA は Web サービスを利用して、ベンダー、プラットフォーム、ネットワーク、およびプロトコルに中立のフレームワークを提供します。このアプローチは、既存のコンポーネントを疎結合して、わずかな変更だけでツールを統合します。また、IT 組織に、ビジネス目標に最適のツールを選択する柔軟性を提供します。

IT プロセスや CMDB フェデレーションなどの標準が未熟な領域の今後は不透明です。ITIL は、プロセス定義に広く使用されているフレームワークですが、特定のプロセス・インターフェースは定義されていません。これは中途半端な制限のように思われるかもしれませんが、さまざまな IT 組織が ITIL をうまく使えるようになるためには有効です。モデリング時または実行時に IT プロセス定義を統合するための標準が開発される可能性があります。たとえば、あるモデリング・ツールを使って定義した IT プロセス・ワークフローと別のツールを使って定義した IT プロセス・ワークフローを統合することができます。また、ある実行環境で動作中の IT プロセス・ワークフローと別の実行環境で動作中の IT プロセス・ワークフローを統合することができます。Web Services Business Process Execution Language (WS-BPEL)25 標準ではこの種の統合の基になるテクノロジーが提供されます。将来、この標準が有力なワークフロー・テクノロジーになるかもしれません。

ITIL と BPEL では、ITIL 構成管理プロセスの検証および監査責任のような特定の相互運用可能なプロセス手順の定義が提供されません。このレベルで相互運用性を可能にする標準を定義することは意味のあることです。たとえば、あるベンダーからの検証および課金プロセスと別のベンダーからの構成ステータス評価プロセスを組み合わせて、単一のベンダーからのプロセスを使用した場合と同じ結果を実現することができます。業界の現状は、このレベルの相互運用性の実現には程遠い状態であり、標準化の取り組みを意味のあるものにする十分な価値が相互運用性にあるかどうかさえ判断できない状態です。

図 5. CMDB データ内の ID のリコンシリエーション

拡大図

本稿で説明した CMDB フェデレーション仕様は、最も新しく、最も未熟な標準です。初期の中心は、異種のデータ・モデルを使ってデータをリポジトリーに登録および照会するための共通インターフェースを定義することでした。リポジトリー全体のデータ整合性を向上させることによって、相互運用性が向上します。1 つの有効な強化は、SML を使って共通のデータ・モデルを定義することです。このようなモデルでは、CIM のように、広く使用されているプロパティーを定義することによって、拡張性を付加することができます。一貫したモデルを使用すれば、管理ツールやプロセスなどのクライアントは、別の実装との相互作用が容易になります。ただし、別のデータ・モデルを使用するための実装の変換には時間がかかります。仲裁手順は、リソース ID の整合をとるのに必要な情報だけを定義することです。

リソース ID の整合化は、恐らく、フェデレーテッド CMDB にとって最も重要な仕事です。各 MDR は、リソースの識別に役立つ 1 つ以上のプロパティーを認識しています。MDR が認識しているプロパティーを比較することによって、多くの場合、複数の MDR のデータを同じリソースに関連付けるタイミングを CMDB で決定することができます。たとえば、コンピューター・システムは以下のいずれかによって認識することができます。媒体アクセス制御 (MAC) アドレス、マシンのタイプ、モデル、およびシリアル番号の組み合わせ、システム・ボードに恒久的に割り当てられたグローバルな固有 ID、資産管理プロセスによって割り当てられた資産番号。図 5 に示されているように、フェデレーテッド CMDB は、MDR がリソースを登録するときに提示する識別プロパティーを分析することができます。多くの場合、この分析は自動的に実施されます。そうでない場合は、手操作による介入が必要になることがあります。想定されている標準では、これらのメカニズムの機能方法は規定されず、MDR によって維持される識別プロパティーとローカル ID のリソース・フェデレーション・サービスへの提示方法が規定される予定です。

その他のフェデレーテッド CMDB に対する拡張では、データ・アクセスの許可、パブリッシュ/サブスクライブ・メカニズムの追加、および共通のバージョン管理構造を定義するためのデータ・モデルの拡張用の共通モデルが開発されています。

結論

企業は、IT 組織により多くのものを期待します。スムーズな運用、予算の予測可能性、および顧客の満足を保証するためには、IT サービスのより統制のとれたプロビジョニングが必要です。また、IT と基幹業務間のコミュニケーションを改善する必要があります。さらに、IT 経費を管理する必要があります。IT には、適切なサービスを通して新しいビジネス機会に迅速に対応できる能力が求められます。

標準ベースのソリューションによって、内部と外部のアプリケーションとデータを接続するために必要な相互運用性が保証されます。また、オープン・スタンダードによって、迅速に、新しいハードウェアとソフトウェアを既存のインフラストラクチャーに統合して、変化の激しいビジネス・ニーズに合わせてインフラストラクチャーを調整することができます。標準を使用することによって、リスクが軽減されます。標準ベースのソリューションを使えば、異機種環境での新旧 IT 資産の相互運用性が保証されるため、お客様は使用している環境に最適のソリューションを見つけることができます。IT 組織は、標準ベースのソリューションによって自分たちのビジネスの俊敏性が改善され、テクノロジー・コストが削減されることを認識しています。IBM は、製品に標準を組み込み、オープン・ソース・プロジェクトを支援することによって、オープン・スタンダードの開発で指導的役割を果たしてきました。

本稿では、サービス対応環境での管理ソリューションの開発と導入に大きな影響を与えることが予想されるいくつかの標準について説明しました。ここで説明した標準を使用することによって、新しい ITSM ソリューションのよりスムーズな導入が可能になるでしょう。

*IBM Corporation の米国およびその他の国における商標または登録商標です。
**Massachusetts Institute of Technology、Organization for the Advancement of Structured Information Standards、United Kingdom Office of Government Commerce、または Linus Torvalds の米国およびその他の国における商標または登録商標です。

引用文献

  1. 「Information Technology Standards」、National Institute of Standards and Technology, United States Commerce Department, http://www.nist.gov/public_affairs/standards.htm
  2. D. Lindquist、H. Madduri、C. J. Paul、B. Rajaraman 共著、「IBM サービス・マネジメント・アーキテクチャー」、IBM Systems Journal 46, No. 3, 423-440 (2007 年、本号)
  3. 「ITIL Planning to Implement ITSM」、Office of Government Commerce, United Kingdom (2002 年)
  4. 「Foundations of IT Service Management Based on ITIL」、J. Van Bon、M. Pieper、および A. van der Veen (編集者), Van Haren Publishing (2006 年)
  5. 「ITIL Service Support」、Office of Government Commerce (2000 年), ITIL Service Delivery, Office of Government Commerce (2001 年)これらとその他の同様のタイトルが、英国 Office of Government Commerce から公開されています。
  6. 「ISO/IEC 20000-1:2005, Information Technology-Service Management-Part 1: Specification」、International Organization for Standardization (2005 年)
  7. 「The Federated CMDB Vision」、BMC Software, Inc.、Computer Associates International, Inc.、FUJITSU、Hewlett Packard Development Company、IBM Corporation、および Microsoft Corporation による共同ホワイト・ペーパー (2007 年 1 月、執筆者から入手可能)
  8. 「Service Modeling Language, Draft Specification, Version 1.0 (2007 年 3 月 21 日)」、World Wide Web Consortium (W3C), http://www.w3.org/Submission/sml/
  9. 「SML Interchange Format, Draft Specification, Version 1.0 (2007 年 3 月 21 日)」、World Wide Web Consortium (W3C), http://www.w3.org/Submission/sml-if/
  10. 「OASIS Solution Deployment Descriptor (SDD)」、Technical Committee, Organization for the Advancement of Structured Information Standards (OASIS), http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sdd
  11. 以下の文書が World Wide Web Consortium (W3C) から公開されています。「Web Services Eventing (WS-Eventing)」、BEA Systems Inc.、Computer Associates International Inc.、IBM Corporation、Microsoft Corporation, Inc.、および TIBCO Software Inc. からのW3C メンバー提案 (2006 年 3 月 15 日)。「Web Service Transfer (WS-Transfer)」、BEA Systems, Inc.、Computer Associates、Microsoft Corporation、Sonic Software、および Systinet からのW3C メンバー提案 (2006 年 9 月 27 日)。「Web Services Enumeration (WS-Enumeration)」、BEA Systems Inc.、Computer Associates International, Inc.、Microsoft Corporation, Inc.、Sonic Software、および Systinet からのW3C メンバー提案 (2006 年 3 月 15 日)。「Web Services Resource Transfer (WS-RT) Version 1.0」、Hewlett-Packard Development Company (HP)、Intel Corporation、IBM Corporation、および Microsoft Corporation からのW3C メンバー提案 (2006年 8 月)
  12. 「Web Services for Management (WS-Management)」、Distributed Management Task Force, Document Number DSP0226, http://www.dmtf.org
  13. 以下の文書が、Organization for the Advancement of Structured Information Standards (OASIS) から公開されています。「Web Services Distributed Management: Management Using Web Services (MUWS 1.0) Part 1, Committee Draft (2005 年 1 月 11 日)」、Document Identifier cd-wsdm-muws-part1-1.0。「Web Services Distributed Management: Management Using Web Services (MUWS 1.0) Part 2, Committee Draft (2004 年 12 月 9 日)」、Document Identifier cd-wsdm-muws-part2-1.0。「Web Services Distributed Management: Management of Web Services (WSDM-MOWS) 1.0, OASIS-Standard (2005 年 3 月 9 日)」。「Web Services Base Notification 1.3 (WS-Base- Notification) Committee Specification (2006 年 7 月 31 日)」、Document Identifier wsn-ws_base_notification-1.3-spec-cs-01。「Web Services Brokered Notification 1.3 (WS- Brokered Notification) Committee Specification (2006 年 7 月 31 日)」、Document Identifier wsn-ws-brokered-notification-1.3-spec-cs-01。「Web Services Topics 1.2 (WS-Topics), OASIS Working Draft 01 (2004 年 7 月 22 日)」。「Web Services Base Faults 1.2 (WS-BaseFaults), OASIS Standard (2006 年 4 月 1 日)」、Document Identifier wsrf-ws_base_faults-1.2-spec-os。「Web Services Resource Lifetime 1.2 (WS- ResourceLifetime), OASIS Standard (2006 年 4 月 1 日)」、Document Identifier wsrf-ws_resource_lifetime-1.2-spec-os。「Web Services Resource 1.2 (WS-Resource), OASIS Standard (2006 年 4 月 1 日)」、Document Identifier: wsrf- ws_resource-1.2-spec-os。「Web Services Resource Properties 1.2 (WS-ResourceProperties), OASIS Standard (2006 年 4 月 1 日)」、Document Identifier wsrf-ws_resource_properties_1.2-spec-os。「Web Services Topics 1.2 (WS-Topics), Working Draft 01 (2004 年 7 月 22 日)」OASIS
  14. 「ITIL Refresh Statement (2005 年 12 月 13 日)」、Office of Government Commerce, United Kingdom, http://www.itil.co.uk/refresh.htm
  15. 「XML Schema Part I: Structures (Second Edition)」、World Wide Web Consortium (W3C), Recommendation (2004 年 10 月 28 日), http://www.w3.org/TR/xmlschema-1/
  16. 「Information Technology-Document Schema Definition Languages (DSDL)-Part 3: Rule-Based Validation- Schematron, ISO/IEC 19757-3」、American National Standards Institute, http://webstore.ansi.org/ansidocstore/default.asp
  17. 「Installable Unit Deployment Descriptor Specification Version 1.0」、InstallShield Software Corporation、IBM Corporation、Novell, Inc.、および Zero G Software, Inc. からの W3C メンバー提案、World Wide Web Consortium (W3C) Recommendation (2004年 7 月 12 日), http://www.w3.org/Submission/InstallableUnit-DD/
  18. P. Brittenham、R. R. Cutlip、C. Draper、B. A. Miller、S. Choudhary、M. Perazolo 共著、「IT サービス・マネジメント・アーキテクチャーとオートノミック・コンピューティング」、IBM Systems Journal 46, No. 3, 565-581 (2007 年、本号)
  19. 「A Simple Network Management Protocol (SNMP)」、Request for Comments 1157, Internet Engineering Task Force (1990 年 5 月), http://www.ietf.org/rfc/rfc1157.txt
  20. 「Common Information Model (CIM) Standards」、Distributed Management Task Force, http://www.dmtf.org/standards/cim
  21. 「Web Services Addressing (WS-Addressing)」、BEA Systems Inc.、International Business Machines Corporation、Microsoft Corporation, Inc.、SAP AG、および Sun Microsystems, Inc. からの W3C メンバー提案、World Wide Web Consortium (W3C) (2004 年 8 月 10 日), http://www.w3.org/Submission/ws-addressing
  22. 「Toward Converging Web Service Standards for Resources, Events, and Management, Version 1.0」、Hewlett Packard Development Company、IBM Corporation、Intel Corporation、および Microsoft Corporation による共同ホワイト・ペーパー (2006 年 3 月 15 日), http://devresource.hp.com/drc/specifications/wsm/
  23. 「WSDM/WS-Man Reconciliation, An Overview and Migration Guide, Version 2.0」、IBM (2007 年 5 月), http://public.dhe.ibm.com/software/dw/specs/ws-wsdmmgmt/wsdmmgmt_v2.pdf
  24. 「Web Services Metadata Exchange (WS-MetadataExchange) Version 1.1」、BEA Systems Inc.、Computer Associates International, Inc.、IBM Corporation、Microsoft Corporation、SAP AG、Sun Microsystems, Inc.、および webMethods (2006 年 8 月), http://schemas.xmlsoap.org/ws/2004/09/mex
  25. 「Web Services Business Process Execution Language Version 2.0, Committee Draft」、World Wide Web Consortium (W3C) (2006 年 5 月 17 日), http://www.oasis-open.org/committees/wsbpel

2007 年 4 月 12 日に発表許可
2007 年 6 月 27 日にオンライン公開

Mark W. Johnson
IBM Software Group, Tivoli, 11501 Burnet Road, Austin, TX 78729。Johnson 氏は、Tivoli Technical Strategy and Architecture グループのシニア・ソフトウェア・エンジニアです。Cornell University で電気工学の学士号を取得しました。彼の主な興味領域は、複数の論文を発表し、いくつかの特許を取得したアプリケーションおよびサービス・マネジメントです。アプリケーション応答測定 (ARM) 標準の共同開発者です。The Open Group と Distributed Management Task Force 内のワーキング・グループの議長を務めてきましたが、現在は、CMDB Federation ワークグループのエディターを務めています。

Andrew Hately
IBM Software Group, Tivoli, 11501 Burnet Road, Austin, TX 78729。Hately 氏は、Software Standards グループのシニア・ソフトウェア・エンジニアです。Web サービス、レジストリー、およびリポジトリーに関するソフトウェア開発と参照実装の取り組みを主導してきました。彼の主な興味は、サービス・ディスカバリー標準、ネットワーク・ディスカバリー標準、およびサービス管理標準のビジネス問題への適用です。UDDI Version 3 仕様の共同開発者であり、OASIS、The Open Group、およびその他のコンソーシアムにおけるいくつかの仕様の取り組みに IBM を代表して参加しています。いくつかの業界会議で、標準、Web サービス、およびサービス指向アーキテクチャーに関するスピーチを行っています。ソフトウェア設計に関するいくつかの特許を取得しており、University of Waterloo で環境工学の学士号を取得しました。

Brent A. Miller
IBM Software Group, 4205 South Miami Boulevard, Research Triangle Park, North Carolina 27709。シニア・テクニカル・スタッフ・メンバーである Miller 氏は、オートノミック・コンピューティングのリード・アーキテクトを務めながら、自己管理オートノミック・システムと ITSM に関連したテクノロジーと標準の両方の取り組みに参加しています。Ohio State University でコンピューターおよび情報科学の学士号を取得しました。2000 年に Prentice-Hall 社から出版された「Bluetooth Revealed」の共著者です。

Robert Orr
IBM Software Group, Tivoli, 3901 South Miami Blvd, Durham NC 27709。Orr 氏は、Tivoli Chief Technology Office で先進テクノロジーと戦略のマネージャーを務めています。彼の技術的な興味には、コンピューター・アーキテクチャー、システム監視、およびパフォーマンスが含まれます。これらの領域でいくつかの特許を取得しています。現在は、CMDB Federation ワーキング・グループのプロジェクト・マネージャーです。University of Maryland でコンピューター・サイエンスの学士号を取得しました。

目次へ戻る

コンテンツ・ナビゲーション