SOAのための資産ライフサイクル管理

ページオプション JavaScript を要するドキュメントオプションは表示されません 原文はこちら

レベル: 初級

Grant Larsen, STSM, Chief-Architect -- Asset Management, IBM　
Jack Wilber, Independent Consultant, JGW Consulting, LLC

2005年 10月 15日

サービス指向アーキテクチャー（SOA: service-oriented architecture）ソリューションの開発における資産ライフサイクル管理に関するプラクティスやツール、標準などを検証します。組織はサービスのライフサイクルを効率的に管理することによって、こうした資産の統括や管理、適用、再利用のためのツールや手法を適用することができ、SOA開発の利点をさらに強化することができます。

非常な速さで変化しつつある市場要求やビジネス優先順位に対して迅速に対応しようとする組織にとって、SOA（Service Oriented Architecture）は大きな可能性を秘めています。SOAでは、アーキテクトはサービス（通常、個々のビジネス機能やプロセスはサービスとして実現されます）を組み合わせ、再利用することによって、複雑なビジネス・ソリューションを構築することができます。

ビジネスの観点から見ると、SOAによって組織はビジネスに整合した構成ブロックから素早くソリューションを構築できるため、応答が改善され、また製品の市場投入までの時間が短縮されます。SOAをITの観点から見ると、大規模開発に伴う複雑さを大幅に低下させることができ、柔軟性を大幅に高めることができるだけではなく、ビジネス・プロセスの自動化や統合によって、ビジネスにとって真の価値を持つソリューションの実現を加速することができます。

こうした利点の基礎となっているのが、再利用性という概念です。サービスは資産（asset）であり、再利用されるにつれて、その価値が高まります。新しいソリューションにサービスを適用するために必要な時間や努力が少なければ少ないほど、そのサービスの価値は高くなります。別の言い方をすれば、再利用されれば再利用されるほどサービスの価値は保持され、そのサービスを再利用するための努力は少なくて済みます。そのため、サービスのライフサイクルを効率的に管理することが、現在の、そして将来の開発のために致命的な重みを持つことになります。そうした管理によって、組織は資産を、SOAの利点を増幅するような方法で統括し、管理し、適用することができます。

認定され、証明された資産やソリューションのプールから開発チームが引用できるようになると、組織は応答を改善し、市場投入までの時間を短縮し、また生産性を高めることができます。また、開発者はこうした資産の内部動作を理解しなくても資産を利用できるため、開発チームにとっての複雑さが低減されることになります。

資産とは何か

5年ほど前、ソフトウェア業界のリーダー達（IBMや（IBMに買収される前の）Rational Software、Microsoftなど）による協議会が、組織がソフトウェア投資を再利用しやすくするための方法の模索を始めました。この協議会では、資産を次のように定義しています。

・・・ある対象コンテキストでの問題に対するソリューションを提供する成果物の集合。

資産は、ユーザーが様々なパラメーターを使ってカスタム化できるような可変部分（variability point）を持っているかも知れません。このように扱える資産は『テンプレート』と言われます。現在、IBM Rationalツールは、この定義を念頭に実装されています。

資産には、開発者が資産を発見し、分析し、利用し、テストするための時間が最小限になるように、使うための手順や規則も含まれています。また資産は、その資産がどこで利用できるのか、どこで利用すべきなのかを規定した、開発コンテキストやビジネス・コンテキストも記述しています。

資産に含まれている成果物の種類は、再利用のコンテキストによって異なります。例えば開発コンテキストでは、資産には要求事項やモデル、ソースコード、テストなどが含まれるかも知れません。サービスを構築する人達は、そのサービスを他の開発者が効率的に再利用できるように、こうした種類の成果物を含めるべきです。

資産は、サービスの場合もあれば、パターンやコンポーネント、他のソリューション要素などの場合もあります。開発者がサービスを構築する場合、通常はパターンやコンポーネント、あるいはレガシー・システムの成果物などを再利用します。そして、そのサービスを、他のサービスと共にSOAソリューションの一部として、複合アプリケーションの中に組み込みます。

資産の定義がパターンの定義と驚くほど似ていることに注意してください。これは両者の設計がそうなっているためです。パターンも資産も、その背景となる基本概念として、コンテキストや問題、ソリューションなどを統合しているのです。両者の違いは詳細にあります。資産の概念は、パターンよりも一般的です。厳密に言うと、資産の可変部分は成果物のレベルにありますが、パターンは、必ずしも特定な成果物には適用されずパターン全体に適用されるような、パラメーターや参加者（participant: 一種の可変部分）を持っています。

上に戻る

RAS: 資産のための標準

この協議会が、「資産とは何か」という質問への答えを出すと、今度は新たな質問が持ち上がりました。つまり、「資産をどのように整理し、構成するのか」「資産について知るために、どんな情報が必要なのか」という問題です。こうした質問に答えるために、協議会はRAS（Reusable Asset Specification）を作成してOMG（Object Management Group）に提出し、OMGはそれを2005年に標準として採用しました。

先に書いた通り、ソフトウェア開発の成果物には様々な種類がありますが、これらは多くの形式で存在し、また様々なスタイルを反映しています。こうした多様性は、他の人が作った成果物を発見し、理解し、再利用するためのコストを増加させます。RASでは、こうした成果物を整理し、構成し、記述し、そしてパッケージするために、資産全体に渡って一貫性を持たせ、また資産を予測できるようになっており、そのため資産管理や利用コストを大幅に低くすることができます。

資産を標準化してパッケージすることの価値を理解するために、標準化が運送業者にもたらした成果を考えてみてください。標準化された封筒と箱を顧客に提供し、また送付ラベル上に記入する情報に一貫性を持たせることによって、これらの会社は高度な追跡システムを構築することができました。さらにこうしたポリシーによって、ベルトコンベヤーの幅の決定や、1台の飛行機に積み込めるパッケージ数の見積もり、必要な飛行機の便数など、ビジネス全体に渡って計画や意志決定が改善されたのです。

これと同じように、資産の標準化も効率の向上に役立ちます。つまり資産の標準化によって、ソフトウェア開発ツールの効率化や自動化が促進され、またそれらを利用するチームの生産性を改善することができます。RASを利用することによって、開発者は最上位レベルの属性（資産の名前やバージョン、記述など）を含んだメタデータ・ラッパーの中に、各資産をパッケージすることができます。これを図1に示します。

図1が示す通り、RAS資産には、検索やブラウズのための『分類（classification）』というセクションがあります。このセクションには、単純な、名前と値の対による記述子、コンテキストの宣言（特定なドメインや、開発やデプロイのコンテキストなど）などが含まれます。

図1に示す『ソリューション』セクションは、この資産の「中身」に当たる部分です。この部分は、ソリューションを提供する成果物の集合を記述します。

『利用方法（usage）』セクションは、資産の適用やカスタム化に関する指針を、可変部分（variability point）を使って提供します。利用方法に関する情報の一部は、スクリプトやウィザード（他の資産成果物と共にソリューション・セクションに保存されます）を使って自動化できる場合があります。

『関連資産（related asset）』セクションは、この資産と他の資産との関係を定義します。またこのセクションは、資産の集合や資産のファミリーから粒度の粗いソリューションを構成する上で役立ちます。

再利用の程度や、形式化の度合い、処理の成熟度などは組織内でも大きく異なります。それらに対応するため、RASの資産セクションの多くはオプションとなっています。また、RASは、『プロファイル』を使って拡張、カスタム化することができます。OMGでは現在、3つのプロファイルを提供してます。つまりデフォルト・プロファイルとデフォルト・コンポーネント・プロファイル、そしてデフォルトWebサービス・プロファイルの3つです。

デフォルト・プロファイルは、任意の種類のソフトウェア資産をパッケージするために使われます。他の2つはそれぞれ、コンポーネントとWebサービスに使うことを想定しています。

上に戻る

資産のライフサイクル

資産の定義と、その構成やパッケージ構造の標準化に合意が得られた後、Rationalが行う次のステップは、資産のライフサイクルを、より完全に記述することです。つまり資産が判別され発見されるプロセスや、取得され作成されるプロセス、認証され公開されるプロセス、再利用され計測されるプロセス、そして最後は資産をリタイヤー（retire）させるプロセスなどを記述します。図2に示すように、資産のライフサイクルには、4つの別々なワークフロー（判別（identification）、作成（production）、管理（management）、そして利用（consumption））が含まれています。

IBMはソフトウェア開発のための手法として、ABD（asset-based development）と呼ばれる手法を提唱しています。ABDはこうしたワークフローに基づく統合ソリューションであり、それぞれのワークフローを、プロセスやツール、標準などによってサポートしています。IBM Rational Unified Process®（RUP®）が提供するプロセス指針を使うことによって、誰が、どんなタスクを、いつ行うのかを知ることができます。また、IBM Rational Software Development Platformの中にある製品の使い方も知ることができます（これらの製品を利用すると、よく定義された標準（RASやUMLを含む）に基づいて、アーキテクチャーの整ったソリューションやモデル、その他の成果物などを開発することができます）。またIBMは、SOA用のABDプラグインやRUPプラグインを含め、幾つかのRUPプラグインも提供しています。これらのプラグインは、サービス指向アーキテクチャーやサービス指向ソリューションに対するサポートを、SOA特有の概念や指針、アクティビティー、成果物、ツール・メンター（mentor）などと共にRUPフレームワークに統合します。

資産のライフサイクルとプロジェクトのライフサイクル、そしてRUP

資産のライフサイクルは、プロジェクトのライフサイクルとは独立であるものの、関連していることは重要ですので注意してください。資産は、資産ライフサイクルの一部として作成されます。そして、それぞれが独自のライフサイクルを持ちながら、多くのプロジェクトで利用される可能性があります。その後、資産は、どのプロジェクトからも独立してリタイヤーし、資産ライフサイクルへの参加を終了します。通常、資産の成熟度は増加します。例えば、最初は1つのチームでしか再利用できない状態から、複数のチームやプロジェクトにまたがる大規模なコンテキストで再利用されるようになる、などです。

それとほとんど同じように、ABDに関連するロール（role）やユースケース・アクティビティー、資産ライフサイクルは、RUPのロールやアクティビティーとは独立していますが、関連もしています。誰かが関心を持つような資産は、（またそうした人達が、こうした資産にアクセスし、操作するために利用するツールも）通常、そうした資産の担うABDロールやRUPロールによって表現されます。

例えば、RUPでアーキテクトとしてのロールを担う人は、資産ライフサイクルにおける資産利用者としてのロールも担っているかも知れません。この場合、アーキテクトは、資産を検索し、ブラウズし、再利用することができます。アーキテクトは恐らくアーキテクチャー関連の資産（モデルなど）を探し、また恐らくIBM Rational Software Architectのようなモデリング・ツールを使うでしょう。

同じように、資産ライフサイクルのユースケース・アクティビティーとRUPアクティビティーとの特定な組み合わせが、あるRUPフェーズと相関している場合があります。通常、資産の利用者として作業するアーキテクトは、RUPのInception and Elaborationフェーズで資産を検索します。しかし、同じく資産の利用者として作業するテスターは、RUPのConstruction and Transitionフェーズでテスト・ケースや他の資産を検索します。こうしたロールを持つ人達が、いつ資産を検索できるのかについての制約はありませんが、どのRUPフェーズの場合も、他のロールよりも頻繁に検索を行うロールがあるものです。

要約すると、資産ライフサイクルでのロールとアクティビティーは、（RUPで記述されるプロセスを含めて）既存の開発プロセスに自然に対応するのです。また、ロールとアクティビティーの特定な組み合わせによって、対象とする資産の種類や、どんなツールが最も有用かも分かるのです。

資産のライフサイクルは、プロジェクトの中で発生します。RUPの大部分は、プロジェクトの中に適用されます。しかし資産ライフサイクルは、プロジェクトの境界の外で起こることもあります。この一例を図3に示します。この図では、Asset Identification（資産の判別）やAsset Production（資産の作成）、Asset Consumption（資産の利用）はプロジェクト内で行われますが、図の下の方にあるAsset Management（資産の管理）とAsset Productionは、プロジェクトの外になっています。

こうした関係は、資産ライフサイクルそのものの視点から見ることもできます。図4は、幾つかのプロジェクトにまたがる様々なABDワークフローを表現しています。この例では、それぞれのABDワークフロー内で発生する幾つかの上位レベル・アクティビティーが示されています。Asset Identification のためのアクティビティーはProject Aで行われますが、Asset ProductionとAsset Managementのアクティビティーは、どのプロジェクトからも独立してAsset Manufacturingチームが行います。そして最後に、Asset ConsumptionアクティビティーがProject Bで行われます。

アプリケーション開発プロジェクトがAsset Production（資産の作成）を行うことがあるかも知れません。しかし、そうした資産の再利用範囲は、より広い範囲での再利用を目的として資産を評価するまで制限すべきです。

要約すると、ABDワークフローは、図3に示すようにRUPフェーズにマップすることができ、また図4のように、プロジェクト境界にまたがって適用することもできます。

資産ライフサイクルをサポートするツール

パッケージングのための標準を定義することや、資産や一連の資産ワークフローを記述することは重要なマイルストーンですが、多くの開発チームでは、RASやライフサイクル・ワークフローをサポートするツールを必要としています。IBM Rational Software Development Platformはこうした要求に応えるものとして、RASを活用し、また資産ライフサイクル・ワークフローを実装することができます（図5）。

こうしたツールを利用すると、再利用可能な資産としてサービスを作成し、認証し、パッケージすることができます。また自分たちのWebサービス・インターフェースをWSDL（Web Service Definition Language）で表現し、UDDI（Universal Description, Discovery, and Integration）レジストリーを指示させることができます。そして、サービスと関連資産をRASリポジトリーに保存する（これについては後でさらに説明します）ことによって、チームのメンバーは、それらを効率的に検索でき、計測でき、評価でき、そして何よりも重要なこととして、それらを『再利用』することができます。

資産ライフサイクル管理におけるロール

資産ライフサイクル・ワークフローのそれぞれは、そのワークフローの中で実行するアクター（actor）とアクティビティーを定義する、関連した一連のユースケースを持っています。RASには、こうしたアクター（またはロール）とユースケースをライフサイクル全体に渡ってサポートするために必要なメタデータと、拡張可能な構造が用意されています。図6に示す各アクターは、一連の特定な責任を持っています。このようにロールを定義することによって、1人の人に1つ以上のロールを担わせたり、複数の人に1つのロールの責任を持たせるなど、より柔軟性を高めることができます。

図7に示すように、資産判別と資産作成のワークフローでは、最上位レベルのセクションやソリューション・セクション、利用セクション、関連資産セクションなどを使いますが、資産管理ワークフローでは主に最上位レベルと分類メタデータを利用し、また資産利用ワークフローでは、すべてのメタデータを利用します。

IBM Software Development Platformのツールは、各ワークフローの中で実行されるアクティビティーをサポートしています。これを下記に説明します。

資産判別ワークフローに対するIBMのサポート

資産判別ワークフローでの最初のステップは、問題と、その問題へのソリューションとなりうるものを判別することです。図8のように『資産判別者（asset identifier）』として作業する人は、候補となりうる資産や成果物を検索します。そして、そのサービス候補をRAS資産としてパッケージし、またRASリポジトリーに保存することによって、サービス候補をサブミットします。この人の目標は、役立ちそうな既存成果物をすべて判別すること、また組織がサービスを作成し、利用するための基礎を作ることです。

IBM WebSphere Studio Asset Analyzerは、再利用のために既存のサービスを判別する上で役立ちます。開発者やアナリスト、オペレーション・チームなどは、IBM WebSphere Studio Asset Analyzerを使うことで企業のソフトウェア資産をよりよく理解することができ、またそれらをより効率的に機能強化し、維持管理し、再利用することができます。IBM WebSphere Studio Asset Analyzerを利用すると、資産と、それらの持つ関係を、対話型のテキスト・リポートやグラフィカル・レポートを通して理解することができます。また、様々なレベルでのビジネス・プロセスやフロー、ソリューションの依存関係を判別することができるため、資産判別ワークフローの駆動に役立ちます。

資産作成ワークフローに対するIBMのサポート

『資産作成者（asset producer）』として作業する個人やチームは、追加成果物を開発することによって、あるいは既存成果物を改善することによって、あるいはその両方によって、資産候補を本当に再利用可能な資産へと変換します。このコンテキストでのサービスの「作成」に含まれるものとしては、IBM Rational Application Developerのようなツールを使ったサービスのモデリングやコーディングや構築、また、IBM Rational Software ArchitectやIBM Rational Software Modelerのようなツールを使ってのサービスの位置付け（サービスを、後から資産ライフサイクルで（あるいは任意の数のプロジェクトで）利用され、再利用されるものとして位置付けること）などがあります（図9）。

サービスを作成し、分類し、パッケージする際に最も考慮すべきことは、利用のしやすさです。誰がこの資産を使うのか、どんな環境で使うのか、またユーザーのスキル・レベルはどうなのか。こうした質問に答えるためには、3つの次元から考慮する必要があります。つまり可変性（variability）と精度（articulation）、粒度（granularity）の3つです。

可変性（variability）は、その資産をどの程度カスタム化すべきかを示します。一部の資産は、何ら変更やカスタム化を必要とせずに、そのまま利用することができます。その他の資産は、再利用する前に利用者が変更する必要があります。

精度（articulation）は、その成果物が提供するソリューションが、どの程度完全であるかを示します。成果物がソリューションを規定しながらそれを実装していない場合には、その資産の精度は低いと言えます。逆に、成果物がサポート・ファイルやモデル、要求事項、テストなどを含めてソリューションを規定して実装している場合には、その資産は高い精度を持っています。

粒度（granularity）は、資産が提供する機能や資産の中に含まれる成果物という観点から見た資産のサイズを意味します。資産作成者は、すべての成果物を単一の資産の中に置くべきか、あるいは分割して、多くの小さな、しかし単純な資産とすべきかを決定する必要があります。関連する成果物のライフサイクルが非常に様々な場合には、細かな粒度を利用した方が適切です。またサービスを、利用シナリオを備えた別々なインターフェース（例えばSCDL (Service Component Definition Language）やWSDL (Web Service Definition Language) など）を公開する、複数の資産に分解することもできます。

図10は、成果物と、このサービスをサポートするメタデータの集合と共にパッケージされた（Service Xという）サービスを示しています。この資産は、RASリポジトリーに保存され、検索され、ブラウズされ、そして最終的には他のアプリケーション開発のために再利用されます。

適切なパッケージングの概念は、（美しさと同様）多くの場合、見る人によって異なります。パッケージングの原則は緩く見えるかも知れませんが、幾つかの基本原則があります。第1に、パッケージングはユーザー側の必要に基づいて行われる必要があります。第2に、パッケージを行う人は、各資産の成果物それぞれのライフサイクルを考慮する必要があります。

図11は、複数の資産にパッケージされたサービスを示しています。インターフェースが、それぞれ独自の資産の中にパッケージされていることに注意してください。これは、メインのエントリー・ポイント資産（要求事項やモデル、テストなど）にある成果物のライフサイクルが、インターフェース資産のライフサイクルと大幅に異なるためです。資産作成者は、RASの中にある関連資産セクションを利用して、サービスに対するインターフェース資産への関連付けを作成します。

クリックして拡大

IBM Rational Software ArchitectとIBM Rational Software Modelerは、どちらも資産のパッケージングと作成のプロセスを自動化する機能を備えています。RASのエキスポート・ウィザードを利用すれば、鍵となるRASメタデータを入力し、資産に対する成果物を選択するだけで、RASアーカイブ・ファイル（.rasファイル）をターゲット位置（RAS Repository for Workgroupsなど）にエクスポートすることができます。

資産管理ワークフローに対するIBMのサポート

資産管理ワークフローは、主にサービスのガバナンスに焦点を当てています。ガバナンスは、資産の開発やデプロイ、ランタイムなどの全体に渡って必要ですが、ここでは開発のみに焦点を当てることにしています。

効果的な資産管理ができるかどうかは、ロールやポリシー、状態、遷移などを記述する、よく定義されたガバナンス・プロセスを確立できるかどうかに大きく依存します。このプロセスは、どのように資産をリタイヤーし、資産メトリックスを追跡し、分類スキーマを作成し、資産を認証してリビューし、そして再利用可能資産として公開するかの詳細を記述している必要があります（図12）。また、このプロセスは、カスタムのRASプロファイルの作成方法も記述します。

開発時のガバナンスと言うと資産管理のみのように思われがちですが、実際には資産ベースの開発ワークフロー全体を横断するアクティビティーが含まれます。図13は、各ワークフローに対する開発時ガバナンスの概要例を示しています。

IBM Rationalでは、効果的なガバナンス・プラクティスを確立できるように、RAS Repository for Workgroupsを提供しています（図5）。これは軽量リポジトリーとしてIBM alphaWorksのWebsiteから入手することができます（注1）。このリポジトリーをIBM Rational ClearCaseと組み合わせることによって、資産管理を実現することができます。また、このリポジトリーのWebサービス・インターフェースを通して、次のような機能を提供することができます。

• リポジトリーの中にある資産の検索とブラウジング（RAS 1.0標準のリポジトリー・サービス・インターフェースと、より複雑なクエリーをサポートする、機能強化した第2のインターフェースを使います）。
• 複数フォーマットでの資産情報の取得（ドキュメンテーションやフィードバックのビューや、資産全体のビューを含みます）。
• リポジトリーへの資産の公開、リポジトリーの中にある論理ビューの作成や整理、メトリックスの追跡。

資産マネージャーは、RASのRepository for Workgroupsを使ってメトリックスを追跡することができます（メトリックスとしては、ある資産が何度検索されたか、そのドキュメンテーションがどの位頻繁にブラウズされたか、その資産が何度インポートされ、再利用されたか、などがあります）。また開発者や他の資産利用者も、RASのRepository for Workgroupsを使って資産やサービスを評価し、テキストでのフィードバックを提供することができます。

資産をリビューし、認証するために必要なプロセスは、IBM Rational ClearQuestを使って自動化し、強制することができます（IBM Rational ClearQuestは、よく定義された一連のステップによってチームの間をウォークスルーしてサービスを認証し、また公開準備可能な状態にします）。また、IBM Rational ClearQuestとIBM Rational ClearCaseは、成果物や資産を修正するための核心となる、ソフトウェア・コンフィギュレーションの管理機能も備えています。

資産利用ワークフローのためのIBMのサポート

図14が示すように、資産利用での最初のステップは、RASメタデータからのキーワードを使った明示的検索によって、あるいはRASリポジトリーの中にある資産をブラウズすることによって、サービスを見つけることです。そうすると資産の利用者は、リポジトリーを通してサービスを適用することができ、またフィードバックを提供することができます。

IBM Rational Software ArchitectとIBM Rational Software ModelerにはAsset Explorerが含まれており、これを使って任意のRASリポジトリーの中にある資産を容易に発見し、フィードバックを提供することができます。また欠陥レポートと変更リクエストの形でフィードバックを提供するために、Rational ClearQuestも使われます。

またIBM Rationalツールを使うと、資産の適用も容易に行うことができます。インテグレーション開発者は、RASリポジトリーから（IBM Rational Software Architectを使って）インポートしたサービスのWSDLを、IBM WebSphere Integration DeveloperのBPEL図の中にドラッグ・アンド・ドロップすることができます。図15は、RASリポジトリーの中にあるサービスの、インポート前の様子を示しています。

サービスをインポートした後、WSDLをIBM WebSphere Integration Developerにドラッグ・アンド・ドロップします。これによって、サービスを参照パートナーとして追加でき、BPELモデルの中に含めることができます（図16）。

上に戻る

ITをビジネス・ゴールに整合させる: ビジネス駆動開発

IT部門は、ビジネスにとって真の価値をもたらすために、自分たち独自のゴールをビジネスのゴールや優先順位に整合させる必要があります。（ビジネスのゴールや優先順位は資産ライフサイクル全体に浸透すべきものであり、各ワークフローでのアクティビティーに知らせるべきものです。）IBMでは、これをビジネス駆動開発（BDD: Business-Driven Development）と呼んでいます。サービス指向ソリューションでのBDDでは、ビジネスでのゴールや要求事項が、開発プロセス全体（設計から構築、統合、そしてテストまで）を駆動します。これを図17に示します。

BDDは、その鍵となるガバナンス面として、モデル駆動開発（MDD: Model Driven Development）とABDの手法を統合しています。こうした手法を使ってSOAを構成することが私達の考え方です。SOAによって、MDDとABDを適用するための、関連資産の性質やタイプを記述する基本的なソリューション・アーキテクチャーが実現するのです。

BDDは、ビジネスとビジネス・プロセスを確実に理解することから始まります。こうしたプロセスは、モデル化され、サービスにマップされます。個々のサービスは、構築され、テストされ、デプロイされ、そして最終的には、繰り返し手法を使って複合アプリケーションの中に組み込まれます。

ビジネスのゴールと要求事項が、ライフサイクル（サービス仕様に対するビジネス・プロセスから、サービスの開発、構築、合成、認証とデプロイまで）を駆動します。

ここで、『パターン』に注意する必要があります。パターンは、特定なコンテキストの中で繰り返し起こる問題へのソリューションを記述する特別な種類の資産であり、IT活動とビジネス・ゴールとを整合させるために効果的です。サービスの開発や再利用にパターンを適用することも、生産性を高めるための、そして複雑さを低減させるための強力な手法です（注2）。

上に戻る

まとめ

『再利用性』は、資産のライフサイクル管理とサービス指向アーキテクチャーの中心となるものです。IBMのツールや指針、リソースなどを利用して資産のライフサイクル管理を行うチームは、SOA開発を非常に優位に展開することができます。

皆さんの組織がSOA採用過程のどの段階にあるかにかかわらず、再利用性と資産ライフサイクルを真剣に考えることによって、大きな成果が得られます。こうした領域で改善を行うことによって、生産性を高め、複雑さを低減させ、開発を促進させることができ、またビジネス・ゴールとの整合性が確実に高まるのです。

上に戻る

注記

^注1alphaWorksからIBMの新興技術に直接アクセスすることができます。RASのRepository for Workgroupsは、http://www.alphaworks.ibm.com/tech/rasr4w から無料ダウンロードして入手することができます。

^注2パターンに関して詳細に説明することは、この記事の範囲外です。この話題に関しては、将来の記事で取り上げたいと思っています。

著者について

		Grant Larsenは、IBM Rational SoftwareのSOAソリューション・チームのシニア・アーキテクトです。彼はソフトウェア開発のアクティビティーを強化するための手法や仕様、プラクティス、再利用可能資産などを開発しており、現在、再利用可能資産とその構成、利用方法などに関する本（Addison-Wesleyから出版される予定です）を執筆中です。eメールの連絡先はこちらです。

		Jack Wilberは、1998年以来、独立のコンサルタントとしてRational Softwareに取り組んでいます。その間、多くのホワイトペーパーやケース・スタディー、製品データシートなどを執筆、あるいは共同執筆しており、『The Rational Edge』にも幾つかの記事を寄稿しています。Rationalに関する執筆を行っていない時には、サウス・キャロライナ州にある自分のホーム・オフィスでソフトウェア開発を行っています。彼はソフトウェア開発に10年以上の経験を持ち、カーネギー・メロン大学にてコンピューター工学と電子工学の学位を取得しています。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る