サービス指向アーキテクチャー環境でパッケージ・アプリケーションを選択するための基準

サービス指向アーキテクチャーのためのパッケージ・アプリケーションの選択について

パッケージ・アプリケーションを選択する場合、単に機能を満たせるかどうかを検証するだけでは十分ではありません。ビジネスの高い目標を達成するためには、機能以外にも満たさなければならない重要な要件があります (例えば、ビジネス・アジリティーや、ソリューションの市場投入までの時間など)。しかし、機能以外の領域での要件を明確に定義しようとすると困難なことが多いものです。この記事では、機能以外のビジネス要件も考慮した上でパッケージ・アプリケーションの選択基準を作成するための、基本的な考え方について説明します。

Geert-Willem Haasjes, Senior IT Architect, IBM

Geert-Willem Haasjes はオランダの University of Twente で電気工学の学位を取得しています。彼は IBM Global Business Services の Open Group Master 認定 IT アーキテクトです。彼は分散ビジネス・ソリューションの設計と実現に 10 年を超える経験を持っています。彼の関心分野は、ソフトウェア・エンジニアリング、サービス指向アーキテクチャー、ビジネス・プロセス管理ソリューションです。



2010年 10月 11日

はじめに

サービス指向アーキテクチャー (SOA) 環境でパッケージ・アプリケーションを実装する場合、通常は合意に基づく決定に従って実装が行われます。しかしこの方法では、必ずしも完全にビジネス要件を満たすことができるとは限りません。合意を得る場合、パッケージ・アプリケーションを独自に作成する場合と他社から購入する場合の利害得失を考えることが多いものです。独自に作成するシナリオでは、カスタムで開発したコンポーネントによって、機能要件を完全に満たす実装をすることも、ビジネス・アジリティーを実現する実装をすることもできます。一方、他社から購入するシナリオでは、既製のパッケージ・アプリケーションによって組み込まれた標準的で成熟したプロセスを利用することができます。

ビジネス要件のあらゆる側面を明確に記述しようとすると複雑になるため、SOA 環境でのパッケージ・アプリケーションの選択基準の設定は難題です。そのため、次のような疑問が湧いてきます。あらゆるビジネス要件に対応し、パッケージ・アプリケーションを適切にデプロイするためには、SOA 環境でのパッケージ・アプリケーションの選択基準をどう設定すべきなのでしょう。

SOA 環境でパッケージ・アプリケーションを選択する場合、その選択基準には、ビジネスの機能面だけではなく、機能以外の側面も含める必要があります。機能以外の側面を真剣にとらえる理由はいくつかあります。第 1 に、目標とするサービス指向アーキテクチャーを実現するためのシナリオは複数考えられ、それぞれのシナリオには機能以外のビジネスの側面が関係してきます。第 2 に、真のサービス指向を実現するためには多様なビジネスの側面に取り組む必要があります。第 3 に、パッケージ・アプリケーションの購入やデプロイメントの際、サービス指向によって約束される成果を実現するためには、サービス指向における機能以外の側面にも対処する必要があります。

以下の 3 つのセクションでは、これらの側面を個別に取り上げます。最後のセクションでは、SOA 環境でのパッケージ・アプリケーションの選択基準を設定する上での実用的な指針を示します。


目標とするサービス指向アーキテクチャーの実現シナリオは複数考えられること

サービス指向で構築されるアーキテクチャーが増えています。目標とする (あるべき姿の) サービス指向アーキテクチャーを実現するためには、いくつかの方法があります。例えば、新しいコンポーネントを開発する方法、企業内にある既存のアプリケーションを再利用する方法、パッケージ・アプリケーションをデプロイする方法などがあります。この 3 つの方法を組み合わせ、目標とするサービス指向アーキテクチャーを実現することもできます。ただし、以下のような多様な側面について考慮する必要があります。

新しいコンポーネントを開発する場合には、例えば相互運用性やセキュリティーの領域で、SOA の標準を採用することが重要です。SOA の領域では、アーキテクチャーの一部となるコンポーネントの開発や統合を標準化するために、多くの成果が実現されています。

既存のエンタープライズ・アプリケーションを再利用する場合やパッケージ・アプリケーションをデプロイする場合には、アーキテクチャーに関する判断が必要なポイントが出てきます。まず、統合や相互運用性を考える場合に、どんな方式で統合するのか (すなわち、より望ましい統合方式の選択肢は何か)、アーキテクチャー上の判断が必要になります。

既存のアプリケーションを統合する場合、統合方式は多岐にわたります。ここですべてを挙げることは不可能ですが、統合方式としては、スクリーン・スクレーピング、バッチ指向処理、メッセージ指向統合、サービス・ラッピングなどがあります。既存のエンタープライズ・アプリケーションを再利用する場合、インターフェースは提供されているとみなすことができます。パッケージ・アプリケーションを購入する場合やデプロイする場合、全体的なアーキテクチャーの統合方式は他の場合よりも選択肢が豊富にあるように思えます。しかし目標とする統合方式を確実に実現するためには、パッケージ・アプリケーションを購入する際、高い目標とする統合を選択基準という形で表現し、関係者同士がよく話し合う必要があります。


複数のビジネスの側面に対応する必要があること

サービス指向を実現するには複数のビジネスの側面に対処する必要がある、ということを認識することが重要です。ビジネスと IT との整合やビジネス・アジリティーといった成果を実現するためには、機能面で分解するだけでは十分ではありません。機能面でのビジネス要件を満たすために必要なサービスやコンポーネントを特定するためには、プロセス・ベースで機能を分解する手法が現実的であることは間違いありません。ただし当然ながら、ビジネスの要望を満たすための側面は他にもあります。そうした他の側面は、機能とは別であることが多いものです。

複数のビジネスの側面を区別するための用語として、この記事では「機能面のビジネス要件」と「機能以外のビジネス要件」という表現を用います。この表現では言葉を注意深く選んだ結果として「要件」という言葉の前に「ビジネス」という言葉を付けています。この、「機能面のビジネス要件」と「機能以外のビジネス要件」という区別は、機能要件と非機能要件という従来の区別の仕方とは異なります。

機能面のビジネス要件というのは従来の機能要件であり、システムによって実現しなければならない必須の要求事項やオプションの要求事項を表します。これらのビジネス要件はプロセスやユースケースに焦点を当てています。サービスはプロセスやユースケースの分析によって特定され、反復可能なビジネス・タスクに割り当てられます。

機能以外のビジネス要件というのは機能以外の要求事項を表し、ビジネスにとって少なくとも機能面のビジネス要件と同程度の重要性を持ちます。ビジネス・アジリティー、ビジネス概念の拡張性、ビジネスの監査可能性などの側面での高い目標は、機能以外のビジネス要件として記述されます。こうした、機能以外のビジネス要件により、例えばプロセスのオーケストレーション、反復可能なビジネス・ステップ (サービス)、サービス・コンポーネントのデプロイメント・モデル、サービスのテスト計画などの詳細さに関する判断が下されます。機能以外のビジネス要件の他に、従来の非機能要件 (可用性、セキュリティー、パフォーマンスなど) も相変わらず重要な役割を担います。機能以外のビジネス要件は、完全なサービス指向を実現するために対応が必要な追加の側面として考える必要があります。図 1 は要件のタイプの分類を示しています。この図では、上で説明した、機能以外のビジネス要件の位置づけを、他のタイプの要件との相対的な関係として表現しています。

図 1. 要件のタイプの分類
要件のタイプの分類

今日の業界では、機能面のビジネス要件を適切に定義することがソリューションを成功させる上で不可欠である、という見方が確立されています。モデリングと定義のための言語を使用して機能面のビジネス要件を定義することは一般的になっています。機能のモデリングと定義のための言語の例として、UML をベースとするユースケース・モデリング、そして BPMN (Business Process Management Notation) をベースとするプロセス定義言語があります。

しかし、機能以外のビジネス要件を適切かつ明確に記述することがプロジェクトの成功に不可欠である、という考え方は、まだ必ずしも定着していません。機能以外のビジネス要件を明確に記述するためのモデリング言語や定義言語は大きく遅れており、ほとんど使用することができません。次のセクションでは、その点に関する指針を紹介します。


パッケージ・アプリケーションを購入、デプロイする際には、機能以外の SOA の側面への対処が必要なこと

大まかに言えば、機能以外のビジネス要件を上位レベルで記述する方法としては、基本的に 2 つの方法があります。1 つは、マニフェストやアプリケーション統合パラダイムなど、値のトレードオフで考えるモデルを使用する方法です。もう 1 つは、SOA リファレンス・アーキテクチャーによって導入される側面を基に、新しいビジネス・システムの品質と制約を明確に記述する方法です。この 2 つの方法について、以下のセクションで説明します。


トレードオフ・モデルを使うことで機能以外のビジネス要件を詳述することができる

ここでは機能以外のビジネス要件をより適切に理解するためのトレードオフ・モデルとして、SOA Manifesto を選びます (「The SOA Manifesto Authors」による標準)。SOA Manifesto には、設計時の選択肢についてのトレードオフがいくつも記述されます。設計時の選択肢は、2 つの設計値を互いに突き合わせることによって表現されます。選択肢には、どちらの値が SOA 環境にとって望ましいかに関する記述も含めます。結果として、SOA Manifesto におけるこれらの選択肢から、いくつかの原則を導き出すことができます。

パッケージ・アプリケーションを選択するプロセスでは、SOA Manifesto から得られる以下の原則が関係してきます。

  • システムの側面のうち、変更の頻度が異なる側面を切り分ける。
  • 暗黙的な依存関係を減らし、外部への依存関係をすべて公開することで、堅牢さを高め、変更による影響を減らす。
  • 抽象化のあらゆるレベルにおいて、焦点の絞られた管理可能な機能単位に基づいて各サービスを編成する。
  • 外部から見た場合の統一性を追求しつつ内部での多様性を許容する。

以下のサブセクションでは、機能以外のビジネス要件と関連付けながら上記の原則について説明します。

システムの側面のうち、変更の頻度が異なる側面を切り分ける

変更の頻度に基づいてシステムの各部分を切り分けるためには、システムのアーキテクチャーをレイヤー化します。システム全体の中にパッケージ・アプリケーションが含まれる場合には、パッケージ・アプリケーションのアーキテクチャーをどのようにレイヤー化、コンポーネント化するかに注目します。パッケージ・アプリケーションのレイヤーとコンポーネントを個別に構成できると理想的です。そうすれば、パッケージ・アプリケーションのさまざまな部分を多様なビジネス要件に対応させることができ、パッケージ・アプリケーション全体を変更したり、新しく構成したパッケージ・アプリケーションをデプロイし直したりする必要がありません。

パッケージ・アプリケーションには、さまざまな理由から他の部分よりも頻繁に変更や再構成を必要とする部分があります。従って、パッケージ・アプリケーションをレイヤー化およびコンポーネント化できることが、機能以外のビジネス要件として重要です。レイヤー化とコンポーネント化により、システム全体としてのアジリティーを実現することができます。

暗黙的な依存関係を減らし、外部への依存関係をすべて公開することで、堅牢さを高め、変更による影響を減らす

パッケージ・アプリケーションに対する機能以外のビジネス要件として、暗黙的な依存関係を少なくすることは非常に重要であり、また外部への依存関係を公開することは特に重要です。この原則により、システム全体を堅牢にすることができるとともに、変更による影響を減らすことができます。この原則を SOA 環境に適用する上で、パッケージ・アプリケーションによってアーキテクチャーの他の部分にどんな制約や暗黙的な依存関係が生じるかを理解することが重要です。依存関係の例として、パッケージ・アプリケーションのサービスの呼び出し順序が決められていることなどがあります。サービスの前提条件を適切に定義することにより、このような依存関係が表現されている必要があります。

パッケージ・アプリケーションを選択する際の基準の中に、「統一的で包括的な記述言語によってサービスの依存関係が適切かつ明確に表現されていること」という記述が含まれている必要があります。

抽象化のあらゆるレベルにおいて、焦点の絞られた管理可能な機能単位に基づいて各サービスを編成する

焦点の絞られた管理可能な機能単位に基づいて各サービスを編成するということは、どのようにシステムをレイヤー化およびコンポーネント化して関心の分離を実現するか、ということです。先ほど触れたように、パッケージ・アプリケーションはコンポーネント化されているのが理想です。この原則の目標は、緊密に関連する機能の単位によって (パッケージ・アプリケーションを含む) システム全体を構成することです。この原則に基づいて構成することで、パッケージ・アプリケーションは管理しやすくなり、変更の影響を受けにくくなります。

外部から見た場合の統一性を追求しつつ内部での多様性を許容する

外部から見た場合の統一性を追求しつつ内部での多様性を許容する理由は、実装のバリエーションを犠牲にすることなく統一的かつ標準的な方法でコンポーネントが呼び出される環境を実現するためです。呼び出しが標準的な方法で行われる限り、内部機能の実装についてのガイドラインを許容範囲の広いものにすることができます。この原則はパッケージ・アプリケーションにもそのまま当てはまります。パッケージ・アプリケーションの機能の実装はさまざまな方法で実現できるからです。パッケージ・アプリケーションによる呼び出しの方法が標準的な方法で行われる限り、外部コンポーネントはそのパッケージ・アプリケーションの機能を統一的な方法で利用することができます。外部から見た統一性を規定するための標準の例として、WS-I (Web Services Interoperability Organization) によって制定された標準とベスト・プラクティスがあります。


SOA リファレンス・アーキテクチャーのさまざまな側面を基に選択基準を導き出す

機能以外のビジネス要件と選択基準を導き出すための、もう 1 つの重要なソースとして、SOA リファレンス・アーキテクチャーがあります。アーキテクチャーをレイヤー化することにより、機能以外のビジネス要件に対応することができます。つまり、機能以外のビジネス要件を特定するための補助として、リファレンス・アーキテクチャーのレイヤーを利用することができます。また、機能以外の一連のビジネス要件や、それらの要件に対応する選択基準をカテゴリー分けする上でも、リファレンス・アーキテクチャーのレイヤーを利用することができます。

最初のサブセクションでは、SOA リファレンス・アーキテクチャーを紹介します。続いて、機能以外のビジネス要件の典型的な側面に対し、複数のアーキテクチャー・レイヤーによって対処する方法を説明します。

SOA リファレンス・アーキテクチャーの紹介

図 2 は SOA リファレンス・アーキテクチャーの概要を示しています。このアーキテクチャーは 5 つの水平レイヤーと 4 つの垂直レイヤーで構成され、それぞれリソース (Resources) レイヤー、サービス・コンポーネント (Service components) レイヤー、サービス (Services) レイヤー、ビジネス・プロセス (Business processes) レイヤー、コンシューマー・インターフェース (Consumer Interfaces) レイヤーと、統合 (Integration) レイヤー、サービス品質 (Quality of services) レイヤー、情報 (Information) レイヤー、ガバナンス (Governance) レイヤーです。このレイヤー化されたリファレンス・アーキテクチャーは、Open Group によるリファレンス・アーキテクチャーをベースにしています。このアーキテクチャーの各レイヤーの詳細な説明については、Open Group の SOA リファレンス・アーキテクチャーの Web サイトを参照してください (「The Open Group SOA Reference Architecture Authors 2009」による標準)。このアーキテクチャーは業界で広く採用されています。このアーキテクチャーのレイヤー構造を採用することで、機能以外のビジネス要件を特定し、カテゴリー分けすることができます。

パッケージ・アプリケーションそのものは、このアーキテクチャーのなかではリソース・レイヤーに位置づけられていることを認識しておくことは重要です。この記事ではリファレンス・アーキテクチャーのレイヤー構造を採用することにより、パッケージ・アプリケーションの選択プロセスにおける機能以外のビジネス要件を導き出します。言い換えれば、機能以外に該当するビジネス側面、またその側面に対応する選択基準を特定するための思考モデルとして、リファレンス・アーキテクチャーを使います。以下のセクションでは、機能以外のビジネス側面の例について、SOA リファレンス・アーキテクチャーの特定のレイヤーと対応させながら説明します。

図 2. SOA リファレンス・アーキテクチャーのレイヤー
SOA リファレンス・アーキテクチャーのレイヤー

プロセス管理

プロセス管理の側面は、上で紹介した SOA リファレンス・アーキテクチャーのビジネス・プロセス・レイヤーで処理されます。プロセス管理はビジネス・アジリティーとビジネスの最適化の両面で重要な役割を担います。

ビジネス・アジリティーに関しては、プロセス・テンプレートによって定義されたプロセス・エンジンにより、反復可能なビジネス・ステップの呼び出しが調整されます。ビジネス・ステップの呼び出し順序、それらのステップに対応するビジネス・ルールは、プロセス・テンプレートを変更することで調整が行われます。

ビジネスの最適化に関しては、プロセス管理機能には、プロセスのモデリング、オーケストレーション、モニタリング、そしてプロセス・モデルのアダプテーションから成る最適化サイクルが含まれています。

パッケージ・アプリケーションを適用する場合、ビジネス・アジリティーとビジネスの最適化を実現するためのシナリオとして、以下の 2 つを考えることができます。

第 1 のシナリオは、対象のパッケージ・アプリケーションの内部にプロセス管理機能が含まれている場合です。この場合には、この内部プロセス管理機能に対する機能以外のビジネス要件を導き出すことが重要です。パッケージ・アプリケーションの内部プロセスとビジネス・ルールは、構成可能なモデルとパラメーターによって調整できる必要があります。また、システム全体としてのプロセスにパッケージ・アプリケーションの内部プロセスをエンド・ツー・エンドで統合できることも重要です。エンド・ツー・エンドでプロセスに統合することで、モニタリングと最適化を全体として連結することができます。その場合、対象のパッケージ・アプリケーション自体がエンド・ツー・エンドのプロセスの大部分をカバーできることに注意してください。そうすることによって、このシナリオのバリエーションとして、パッケージ・アプリケーションのプロセス・エンジンによってエンド・ツー・エンドのプロセスを調整することもできます。

こうした機能以外のビジネス要件から導き出す必要がある (パッケージ・アプリケーションの) 選択基準として、BPMN (Business Process Modeling Notation) などの標準的なプロセス記法や BPEL (Business Process Execution Language) などの標準的なプロセス実装言語によってパッケージ・アプリケーションの内部プロセスが適切に記述されていること、という基準があります。さらに、パッケージ・アプリケーションは企業のイベント基盤の標準に従ってビジネス・モニタリング・イベントを送信できる必要があり、またパッケージ・アプリケーションのプロセス・モニタリング・エンジンによってエンド・ツー・エンドのプロセスを調整する場合のために、ビジネス・モニタリング・イベントを受信できる必要があります。事前定義されたプロセス定義に従うビジネス・モニタリング・イベントをプロセス・モニタリング・エンジンとの間で交換すると、(パッケージ・アプリケーションによってカプセル化された部分を含め) エンド・ツー・エンドでプロセスを追跡することができます。

第 2 のシナリオは、反復可能なビジネス・ステップをパッケージ・アプリケーションによって公開し、それらのステップを外部のビジネス・プロセス管理エンジンによって呼び出す場合です。この場合には、パッケージ・アプリケーションが、適切に記述されたサービスによって反復可能なビジネス・ステップを提供することが重要になります。サービスの定義については次のセクションで説明します。

サービスの定義

サービスの定義は SOA リファレンス・アーキテクチャーのサービス・レイヤーで処理されます。サービスの定義には、反復可能なビジネス・ステップの機能、そして呼び出しの詳細と前提条件を記述します。サービスを適切に記述することは、再利用を実現する上で重要な要素です。つまり機能以外のビジネス要件として、機能が明確に定義されていること自体が重要です。

機能が明確に定義されていること、という機能以外のビジネス要件から導き出されるパッケージ・アプリケーションの選択基準は、パッケージ・アプリケーションによって提供されるサービスが標準を使って記述されていることです。サービスを定義するための標準の例としては、WSDL (Web Service Description Language) があります (The Web Services Description Language Authors」による標準)。サービス・アクセス・プロトコルの例としては、SOAP (Service Object Access Protocol) があります (「The Service Object Access Protocol Authors」による標準)。

サービス・コンポーネント

サービス・コンポーネントは SOA リファレンス・アーキテクチャーのサービス・コンポーネント・レイヤーで処理されます。サービス・インターフェースによって定義された機能をサービス・コンポーネントによって実現します。サービス・コンポーネント自体は他の機能コンポーネントや技術コンポーネントに依存します。一般的に、システムをコンポーネント化することによってアジャイルなビジネス・ソリューションを実現することができます。これは調整や構成をコンポーネント単位で行えるようになるためです。

ビジネス・アジリティーを実現できるかどうかは、コンポーネント構造の詳細さに大きく依存します。一般的な言い方としては、コンポーネント構造の粒度が粗い場合よりも細かい場合の方が、反復可能なビジネス・ステップを構成しやすく、また反復可能なビジネス・ステップと連携しやすくなります。新しいコンポーネントによってコンポーネント構造をどの程度補強できるのかも、ビジネス・アジリティーを実現する上で重要な側面です。パッケージ・アプリケーションが調整や構成が容易なコンポーネント構造を持つ必要があるかどうかは、ビジネスの目標によります。ほとんどの場合、標準的な既製ソリューションをデプロイするのか、あるいはカスタムのビジネス・サービスによるシステムを開発するのか、という 2 つによる利害得失を判断することになります。

ビジネスの目標として、パッケージ・アプリケーションにもコンポーネント・レベルのアジリティーを拡張したい場合には、コンポーネント・レベルでの調整や構成の容易さに対する要件を表現した選択基準を設定する必要があります。

将来の発展についても考慮する必要があります。理想的には、パッケージ・アプリケーションが全体としてのリリース管理の方針に適合している必要があります。全体としてのリリース管理やテストの方針からコンポーネント・レベルでソフトウェアのプロモーション・プロセスが必要な場合には、パッケージ・アプリケーションもコンポーネント・レベルでのテストや本番稼働プロセスに対応できる必要があります。

データ

データの側面は上で紹介した SOA リファレンス・アーキテクチャーの情報レイヤーに位置づけられています。SOA ではサービスによってデータがカプセル化されています。とは言え、ビジネス・オブジェクトとビジネス・オブジェクト同士の相互関係を理解する上での最初のステップは、概念的なエンタープライズ・エンティティー・モデルであることが多いものです。このエンティティー・モデルを基に、ソリューションの SCA (Service Component Architecture) 要素間で交換されるすべてのメッセージで構成される正規のメッセージ・モデルが導き出されます。

パッケージ・アプリケーションによってもデータ・モデルが導入されるため、ビジネス・エンティティー・モデルの整合について考慮する必要があります。統合の観点から言えば、正規の交換メッセージ・モデルを拡張し、新しいパッケージ・アプリケーションによって導入される新しいビジネス・エンティティーを反映させる必要があります。そうした難題を克服する上で、メッセージ・ブローカーなどのミドルウェア技術やマスター・データ管理ソリューションが役立ちます。より詳細な技術レベルでは、交換メッセージのフォーマットや実装についても考慮する必要があります。交換メッセージが XML (Extensible Markup Language) によって実装され、XSD (XML Schema Definition) によって定義される場合、要素や型の宣言スタイル (グローバル宣言かローカル宣言か) は、企業全体としての望ましい宣言スタイルにパッケージ・アプリケーションがどの程度厳格に従う必要があるかによって変わってきます。

サービスの統合

サービスの統合に関する主な部分は SOA リファレンス・アーキテクチャーの統合レイヤーによって処理されます。SOA の統合メカニズムは、サービスの発見 (静的な発見または動的な発見) をベースにしています。サービスの定義についてのセクションで説明したように、サービスを統合するためには、まずサービスを適切に定義する必要があります。

サービスの発見とバインディングを実装するためには、SOA のサービス・レジストリー機能を利用します。つまり、企業全体にわたるサービス・レジストリー (または連携型サービス・レジストリー) に記載可能なサービス定義を提供するためには、パッケージ・アプリケーションに対する機能以外のビジネス要件を設定する必要があります。この選択プロセスの基準は通常、サービスの定義についてのセクションで紹介した基準と似ています。

パッケージ・アプリケーションがサービス・カスタマーとしての役割を持ち、エンタープライズ・サービスを呼び出す場合には、そのパッケージ・アプリケーションは企業全体にわたるサービス発見およびサービス・バインディングのメカニズムを利用できなければなりません。

異種混成の環境では、サービス間のアクティビティーの調整が問題になる場合があります。そうした共通のアクティビティーのなかでパッケージ・アプリケーションが協調動作する場合には、企業レベルの調整フレームワークに合意することが重要です。パッケージ・アプリケーションを始めとするすべてのサービス構成要素は、トランザクションの整合性を維持するために、この調整フレームワークに従う必要があります。業界で広く確立されているフレームワークの例として、OASIS Web Services Transaction によって承認された、WS-Coordination (Web Services Coordination)、WS-AtomicTransaction (Web Services Atomic Transaction)、WS-BusinessActivity (Web Service Business Activity) による協調動作があります (「The OASIS Web Services Transaction Authors」による標準)。

サービスのセキュリティー

サービス品質レイヤーは、通常の品質面 (可用性、スケーラビリティー、スループット、応答時間性能など) の他に、サービスのセキュリティー面の処理を行います。

サービスのセキュリティー要件は、ID 認証や承認に関する方針に従って企業レベルで設定することができます。そうした方針の例としては、トークンを使ってサービス間で ID や承認情報を渡し合うシングル・サインオン (SSO) などがあります。パッケージ・アプリケーションを選択する上では、そのパッケージ・アプリケーションが企業全体にわたるセキュリティー実装スタイルに厳密に従う必要があるのかどうか、判断が必要です。厳密に従う必要がある場合には、それらのセキュリティー要件をパッケージ・アプリケーションの選択基準に反映する必要があります。選択基準を定義する場合には、業界標準を使用することを推奨します。広く受け入れられている標準の例として、OASIS が公開している Web Services Security があります (「The OASIS Web Services Security Authors」による標準)。

サービスのガバナンス

サービスのガバナンス面は、SOA リファレンス・アーキテクチャーの垂直ガバナンス・レイヤーで処理されます。サービスのガバナンスの重要な要素として、サービスの所有モデル、スポンサー・モデル、変更モデル、再利用促進モデルを定義し、デプロイする必要があります。SOA 環境では、サービスに対する所有者とスポンサーの割り当てが重要です。再利用モデルと変更モデルを定義する場合には、ビジネスの目標と整合させることを推奨します。

機能以外のビジネス要件として、サービス・ガバナンス・モデルを適切にデプロイすることを検討する必要があります。こうした機能以外のビジネス要件はパッケージ・アプリケーションをデプロイする際にも適用され、また購入プロセスの際の選択基準として表現されている必要があります。選択基準の例として、パッケージ・アプリケーションのサービス構造が詳細なサービス所有モデルと対応すること、という基準があります。また選択基準の別の例として、企業全体にわたるサービス・リポジトリーによって管理されるサービス・ライフサイクルの中に、パッケージ・アプリケーションのサービス構造を統合できること、という基準もあります。


謝辞

この記事を入念に校閲してくださった Gerard Alderden 氏に深く感謝いたします。


参考にした標準

参考文献

  • 皆さんの目的に最適な方法で IBM 製品を評価してください。製品の試用版をダウンロードする方法、オンラインで製品を試す方法、クラウド環境で製品を使う方法、あるいは SOA Sandbox で数時間を費やし、サービス指向アーキテクチャーの効率的な実装方法を学ぶ方法などがあります。
  • My developerWorks コミュニティーに加わってください。開発者向けのブログ、フォーラム、グループ、ウィキなど利用しながら、他の developerWorks ユーザーとやり取りしてください。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

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

 


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

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

ディスプレイ・ネームを選択してください



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

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

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

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

 


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


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=619352
ArticleTitle=サービス指向アーキテクチャー環境でパッケージ・アプリケーションを選択するための基準
publish-date=10112010