IBM®
本文へジャンプ
    Japan [変更]    ご利用条件
 
 
検索範囲検索:    
    ホーム    製品    サービス & ソリューション    サポート & ダウンロード    マイアカウント    
skip to main content

developerWorks Japan  >  Architecture | SOA and Web services  >

実際のアーキテクチャー: 第 2 回 SOA ソリューション・シナリオの紹介

developerWorks
ページオプション

JavaScript を要するドキュメントオプションは表示されません

原文はこちら

原文はこちら


レベル: 上級

Tilak Mitra, Executive IT Architect, IBM

2007年 01月 30日

IBM では現在、SOA (Service-Oriented Architecture) の導入を支援する 8 つのシナリオを提供しています。この連載の一部となっているミニシリーズの第 1 回では、入門編としてそれぞれの SOA ソリューション・シナリオを紹介し、SOA 実装を迅速化する方法を説明します。

はじめに

この連載の最初の記事では、IBM SOA Foundation ライフサイクル (SOA ライフサイクル) の概要、そして IBM のツールと技術を使用して SOA ベースのソリューションをデプロイし、サービスのライフサイクルを管理する方法を説明しました。その説明から学んだように、IBM SOA ライフサイクルは以下の 4 つのフェーズで構成されます。

  1. モデル
  2. アセンブル
  3. 展開
  4. 管理
これらのフェーズを一括すると、MADM という頭字語で呼ぶことができます。

SOA ライフサイクルは、この 4 つのフェーズ、そしてそれぞれのフェーズを構成するアクティブティーとタスクを中心にプロジェクト・プランを編成できるようにします。その一方、SOA ベースのソリューションのアプリケーションに繰り返し使用される共通のテーマとパターンを見つけ、現在 SOA が使用されている一般的な状況を特定できたとしたら便利だと思いませんか?IBM ではそのような SOA の共通使用パターンを 8 つ用意しています。これらのパターンはまとめて SOA シナリオと呼ばれています。

IBM は企業が SOA の導入に成功できるように、SOA シナリオを 5 つの別個でありながらも相互に関連したエントリー・ポイントを中心に体系化しています。これらのエントリー・ポイントはビジネスと IT 両方の必要性に左右されるもので、以下の内容に基づく 5 つに大別されます。

  • 人 -- 人間とプロセスの対話を可能にする場合のエントリー・ポイント
  • プロセス -- ビジネス・モデルのイノベーションによって効率性と有効性を大幅に向上させる場合のエントリー・ポイント
  • 情報 -- ビジネス・プロセスを可能にするための信頼性の高い情報を提供する場合のエントリー・ポイント
  • 接続性 -- ソフトウェア・システムとサービスを接続することにより、オンデマンドの柔軟性を実現する場合のエントリー・ポイント
  • 再利用 -- 価値の高いエンタープライズ・アセットの再利用を促進することにより、SOA の導入と実装の複雑さを最小限にする場合のエントリー・ポイント

エントリー・ポイントのそれぞれには、1 つ以上のシナリオが含まれ、これらのシナリオが対応するエントリー・ポイントを実装する際のロードマップとなります。各シナリオは、さらに「実現方法」へと細分化されます。実現方法とは、特定の問題を解決するために設計された具体的な開発タスクです。SOA シナリオは、IBM サービス・チームが実際にクライアントのソリューションを実現するときに直面する一般的な状況を表します。

それぞれのシナリオは特定のビジネス価値を伝え、SOA ソリューションのアーキテクチャーと、そのソリューションの特定の部分を実装するために使用が推奨される一連のオープン・スタンダード・ベースの IBM ソフトウェアを記述します。これらのソリューションは、実現可能なすべてのニーズを一度にすべて満たすのではなく、SOA ベースのソリューションを段階的に実装することでニーズを満たせるように設計されています。各シナリオが定義するソリューションは本質的にモジュール式であるため、それぞれを重ね合わせていくことができます。つまり、複数のシナリオに含まれる要素を組み合わせた複合シナリオを作成できるということです。シナリオはまた、SOA シナリオのさまざまなバージョンを構成するパターンのそれぞれに、IBM が提供するツール、技術、製品を使用してマッピングし、そのパターンを実現する際の模範的な方法のガイダンスにもなります。

シナリオは、機能もしくはサポートという 2 つのカテゴリーに分類されます。機能に関するシナリオは、1 つ以上の SOA エントリー・ポイントに直接対応する一方、サポート・シナリオはすべてのエントリー・ポイントに共通します。

機能関連のシナリオには以下のものがあります。

  • サービス作成
  • サービス接続
  • 対話および連携サービス
  • ビジネス・プロセス・マネージメント
  • サービスとしての情報
サポートしている共通のシナリオには以下のものがあります。
  • SOA 設計
  • SOA ガバナンス
  • SOA セキュリティーおよび管理

この記事は、SOA シナリオについて説明する 9 回の記事の第 1 回目です。今回は 8 つのシナリオのそれぞれの背後にある理念を、そのシナリオを使用できる広範なコンテキストと併せて紹介します。また、特定の SOA シナリオを典型的な IT プロジェクトに適用する方法についても説明します。今後の記事では毎回 SOA シナリオのいずれか 1 つに重点を絞り、シナリオの定義とそのシナリオ内部で考えられる各種のパターンを明確にした上で、それぞれのパターンを IBM が提供する技術と製品を使用して実現する方法を詳説します (SOA の初歩的な内容については、developerworks の SOA の入門ページにアクセスしてください)。




上に戻る


概要: SOA シナリオ

それぞれの SOA シナリオでは、業種内、業種間のさまざまなプロジェクトでの経験に基づいて、SOA の使用パターンが十分に文書化されています。シナリオは、特定の状況で SOA イニシアチブを活性化させるために適用できる使用パターンを識別する上で役立ちます。シナリオはビジネス文書と技術文書の両方によって強力にサポートされており、シナリオ内の特定ソリューションを IBM の製品、ツール、そして技術を使用して実現する方法を示す模範的なガイダンスになります。これらのシナリオは、いわば料理の本に記載されたレシピのようなものだと考えてください。料理の本では、適切な材料を選べるようにそれぞれの手順を明確に定義し、そのレシピを実現する模範的な方法を案内します。

まずは、各シナリオの概要を明らかにすることから始めます。

サービス作成 -- 柔軟性に優れたサービス・ベースのビジネス・アプリケーションを作成するシナリオです。新しいサービス指向アプリケーションではビジネスの振る舞いをサービスとして公開すると同時に、サービスとして公開されたビジネス・ロジックを再利用します。このシナリオはまた、サービスを作成すると同時にそのサービスをプロビジョニングする方法についてのガイドラインも提供します。サービスの識別と実現方法は、最適化された一連のビジネス・プロセスの構想を実践に移す際の第一歩となります。サービスは基本的に以下の 3 つの主要ソースから識別できます (既存のアセットの再利用に重点が置かれていることに注意してください)。

  • 既存のアセット -- 既存のシステムにすでに配置されている、高価値のビジネス機能から識別されたサービス (レガシー・アプリケーション、パッケージ化されたアプリケーションなど)。
  • 外部サービス・プロバイダー - 外部のベンダー (大抵の場合、特定分野でのサービスを提供する外部のベンダー) によって提供されるサービス (これらのサービスは通常、共通の一般的タスクをカプセル化したもので、戦略的な差別化機能を提供するとは限りません)。
  • 「トップダウン」手法で識別された新規サービス -- トップダウン分解手法 (つまり、プロセスの分解) によって識別されたサービス (これらのサービスは上記の 2 つのソースが対応していないギャップを埋めるもので、一から実装する必要のある新しいサービスです)。

サービス接続 - サービス作成シナリオをベースに識別、設計、構築したサービスに従って作成したシナリオで、ビジネス中心の SOA をサポートするための基礎となる接続に重点が置かれています。このシナリオによって、ユーザーはサービス・コンシューマーを変更する際に、サービスの状態とは無関係に行ったり、あるいはサービスを中断することなく行ったり、柔軟な対応ができるようになります。このシナリオは、サービス・プロバイダーとサービス・コンシューマー間の接続を切り離すために使うことが可能な ESB (Enterprise Service Bus) の特性 (ルーティング、変換、メディエーションなど) を識別するのに役立つだけでなく、サービス・ゲートウェイ・パターンを論理的および物理的に実現する方法に関するガイダンスにもなります。 サービス・ゲートウェイ・パターンは、整合性を持たずに進化する複数のシステム間でのトランスペアレントな相互運用をプロトコルおよびインターフェース・レベルの両方で可能にするメディエーション機能を提供する他、サービス呼び出しにおけるセキュリティーをどのように実施するかについてのガイダンスを提供します。

対話および連携サービス -- ユーザー (人間) に対して、サービスまたはサービスのセットをブラウザー、PC、モバイル機器、音声応答システムなどを通じて提供するシナリオです。このシナリオで重点を置いているのはユーザビリティーの問題で、例えば複数のシステムへのシングル・サインオンを可能にしたり、ロール・ベースのポータルを提供して企業内および企業間で共有する情報やアプリケーションへのアクセスを統一したりします。また、このシナリオの重要な原動力となっているのは、システムを使用するユーザーの生産性を向上すること、そしてシステムを構成するアプリケーションとコンテンツの使いやすさを改善することです。コンテンツは、ユーザーのロールをベースに集約したポータル・ページで、それぞれのユーザー向けにパーソナライズすることも可能です。

ビジネス・プロセス・マネージメント -- ビジネス・プロセスの最適化と自動化を支援し、組織のコア・アセット (人、プロセス、情報、技術) を連携させて 1 つに統一したビューや、リアルタイムの情報、そして適切なビジネスおよび IT のメトリックを作り出すことによって、経営効率を高めるシナリオです。このシナリオで主に重点を置いているのは、プロセスのモデル化とシミュレーション、プロセスの統合、プロセスの監視 (別名、BAM (Business Activity Monitoring))、プロセス指向のコンテンツ集約、ビジネス・ルールの管理、そして人、プロセス、技術の効果的な連携です。プロセスを中心とする企業は、このシナリオを SOA 変換の際に使用することによってメリットを得ることができます。

サービスとしての情報 -- データのビジネス価値を広げることによって、SOA で使用できる情報にするシナリオです。このシナリオがとりわけ当てはまるのは、以下のような企業です。

  • 大量の情報があるものの、ビジネスとの関連性が明確ではない。
  • 同じ情報が複数のバージョンで保管されるため、どの情報源を使用するべきかの判断が難しい。
  • データ品質について厳密に規制せずに情報を蓄積している。
  • 情報がそれぞれ分離した保管場所で維持されているため、重複した情報があったり、調整不可能な異なるデータ・セットが含まれていたりする可能性がある。
このシナリオで最も重要な点は、情報を仮想化および一元化して、一貫した信頼できるデータを作成することです。そのような単一の仮想バージョンのデータをサービスとして SOA システム全体で使用できるようにすると、SOA システムではこのデータを標準化された方法でビジネス・プロセスを実現するために使用できることになります。

SOA 設計 -- SOA をベースとしたソフトウェア開発のモデル化方法、設計、そしてアーキテクチャーに重点を置いた、分野を問わないシナリオです。このシナリオは一連のロール、メソッド、成果物を通してビジネス設計と IT ソリューション設計のモデル化を連携させます。このような連携が達成されれば、ビジネス・プロセスはサービスとして最適化および実現できるようになるため、サービスとビジネスとが連携して真のビジネス価値をもたらすことになります。

SOA ガバナンス -- SOA の計画と実行を監督する意思決定および実施プロセスに重点を置いた、分野を問わないシナリオです。このシナリオがベースとするのは決定権と管理フレームワークで、これには SOA ライフサイクルの 4 つのフェーズを対象とした権限、ロール、制御などの制定も含まれます。決定権の制定と SOA ライフサイクルの管理の他、このシナリオでは価値の高いビジネス・サービスの定義、そしてそれらのサービスの実行時におけるその有効性の測定も重点としています。

SOA セキュリティーおよび管理 -- 実行時のサービス管理を焦点とした分野を問わないシナリオで、外部コンシューマーからの価値の高いビジネス・サービスへのセキュア・アクセスを確実にします。サービスの管理で重点としているのは、IT プロセスの自動化と簡易化、サービスおよびアプリケーションのサービス・レベルの管理、そして互いに依存する複合サービスにおける変更の予測と管理です。一方サービス・セキュリティーの重点は、サービス間でのフェデレーテッド ID とアクセス制御の管理、サービスとアプリケーションへのセキュアなアクセス、サービスに対する一貫したセキュリティー・ポリシーの実施に置かれています。




上に戻る


SOA シナリオ間の関係

SOA シナリオはまとめて同時に使用することも、段階的に導入することもできます。図 1 に、シナリオ間の一般的な関係を図解します。


図 1. SOA シナリオ間の関係

「サービス作成」シナリオが作成するのは基本的にサービスです。サービスは、「ビジネス・プロセス・マネージメント」シナリオでモデル化されたビジネス・プロセス・モデルから識別することができます。「サービスとしての情報」および「対話および連携サービス」の両シナリオから識別されたサービスは、「サービス作成」シナリオで使用されます。主にポータル・ベースでエンタープライズ・サービスにアクセスする「対話および連携サービス」シナリオは、「ビジネス・プロセス・マネージメント」シナリオによるビジネス・プロセスだけでなく、「サービスとしての情報」シナリオによって定義されたサービスも呼び出すことができます。「対話および連携サービス」シナリオと「サービスとしての情報」シナリオで定義されたサービスは、「サービス接続」シナリオを使用してサービス間の通信を行います。「サービス作成」シナリオで作成されたサービスで複合サービスを構成する場合にも、同じく「サービス接続」シナリオを使用してサービス間の接続が行われます。

「SOA 設計」、「SOA ガバナンス」、そして「SOA セキュリティーおよび管理」は分野に特定されないシナリオで、5 つの機能関連のシナリオ全体で使用され、シナリオそれぞれの実現に影響します。

上記に示した関係以外にも、シナリオを相関させる方法は考えられます。SOA の経験を積むにつれ、ここで定義した他にも、十分に実証された関係を追加できるようになるはずです。




上に戻る


SOA シナリオの使用手順

このセクションでは、SOA シナリオを特定の問題に適用する方法として IBM が推奨している手順を紹介します。図 2 に示すように、この手順を大まかに分けると以下の 5 つのステップで構成されていることになります。


図 2. IBM が推奨する SOA シナリオの使用手順

ここからは、IBM サービス部門のアーキテクトが実際の業界ソリューションを作成する際にこの手順を適用する過程を追って、5 つのステップのそれぞれを説明していきます。

  • 顧客要件の収集 -- このステップでは、IBM のコンサルタントとアーキテクトが要件をユースケースという形で収集して初期のビジネスおよび IT コンテキストを理解し、顧客が彼らの企業の将来の状態についてどのような考えを持っているのかを文書化します。
  • 一般ユースケースによるフィット・ギャップ分析の実行 -- SOA シナリオ・フレームワークが、さまざまな業種での顧客要件の分析経験から一般ユースケースを導き出し、リストにします。最初のステップで特定した顧客のユースケースそれぞれが、一般ユースケースのリストと比較分析され、どの一般ユースケースが顧客のユースケースに最も類似しているかが評価されます。表 1 に、一般ユースケース (U1、U2、U3 などと呼びます) のリストを記載します。この表には、一般ユースケースを実装するために使用できる SOA シナリオも併記しています。

    表 1. SOA シナリオの選択基準


    上記の表にリストアップした一般ユースケースそれぞれの詳細な定義は、「IBM Redbooks Patterns: SOA Foundation Service Creation Scenario」の Section 5.2 に記載されています。重要な点として、特定ユースケースの実現方法にマッピングされている主要なシナリオは、3 つのシナリオ (SOA 設計、SOA ガバナンス、SOA セキュリティーおよび管理) によって補完されます。したがって、表 1 の最後の 3 列からわかるように、この3 つのシナリオには本質的に、分野に特定されない補足的な要素があります。
  • SOA シナリオの選択 -- SOA シナリオ・フレームワークの一環として定義された一般ユースケースのそれぞれは、表 1 に示されているように、そのユースケースを実装するために使用できる 1 つ以上の SOA シナリオにマッピングされます。この表を使用して、ユースケースを実現するために使用する SOA シナリオを選択します。このステップと前のステップは、すべてのユースケースに対して実行されます。一方、新しいプロジェクト・イニシアチブで使用する予定の SOA シナリオ・ベースのアクティビティーが、他の問題を解決するためにすでに開始されている場合もあります。そのような場合には、SOA シナリオから顧客定義のユースケースへのリバース・マッピングが実行されます。図 2 では、このリバース・マッピングが「SOA シナリオの選択」ステップから前のステップ、つまり「一般ユースケースによるフィット・ギャップ分析の実行」ステップを指す矢印で示されています。
  • ソリューション・アーキテクチャーを迅速化するパターンの識別、再利用、適用 -- このステップは、顧客がアーキテクチャーとソリューションの設計フェーズで既存の再利用可能なアセットを利用することを望む場合に実行されます。どのアセットを再利用するかを決定するプロセスには、以下の 2 つのステップがあります。
    1. IBM Patterns for e-business をよく理解した上で、ソリューション・アーキテクチャーの実装を迅速化するために使用できるパターンを識別します。各 SOA シナリオについての詳細は、「Patterns for e-business SOA architecture and design patterns」などの主要な参考資料に記載されています。表 2 に例として、各パターンとその SOA シナリオとの関連付けについての参考資料を一部抜粋して記載します (詳細のリストについては、「参考文献」で紹介している IBM Redbooks、「SOA Foundation: Service Creation Scenario」を参照してください)。

      表 2. SOA シナリオごとのパターンの参考資料
      SOA scenario process

      それぞれの参考資料は、特に断りのない限り IBM Redbooks® シリーズの本 (「参考文献」を参照) であることに注意してください。SOA シナリオ・フレームワークは現在も成長を続けているため、パターンに関する参考資料は今後さらに増えていくはずです。
    2. 次のステップは、パターン・アセットを開発方法に対応させることです。IBM が推奨している主なソフトウェア開発方法は RUP (Rational® Unified Process) と IBM GS (Global Service) Method の 2 つですが、このステップでは他の方法を選択することもできます。実装にどの方法を選択するにしても、メインのマッピング作業で重点を置くのは、再利用可能なパターン・アセットをその方法の各分野にどのようにマッピングできるのか、そしてこれらのアセットが各分野の成果物にどのように関係するかという点です。このような手法で再利用可能なパターン・アセットを使用することにより、成果物の作成が容易になります。表 3 に、RUP の場合での再利用可能なアセットのマッピング例を記載します。

      表 3. 再利用可能なアセットと RUP 成果物のマッピング


実装ガイドの活用 -- これは、IBM が推奨する手順の最終ステップです。このステップは、再利用可能なパターン・アセットを識別してから実行することも、SOA シナリオの選択ステップの直後に実行することもできます。

このセクションで参照する資料には、SOA MADM ライフサイクルの各フェーズや SOA シナリオで選択された一連の一般ユースケースに対するソリューションの実装方法を説明する実用例が含まれます。

シナリオを実現方法は、シナリオを使用する方法、製品を選択する方法を理解する上で役立つように作られています。つまり、実現方法は、現実での業界の状況とそのソリューションを説明するビジネス・ケースの例ということです。特定のシナリオに複数の実現方法がある場合もあります。そのため、それぞれのシナリオには、実現方法の選択や特定の実現方法のなかで行う必要がある決定に役立つ模範的な質問が含まれています。また、特定 SOA シナリオの実装プロセスを迅速に行うための実装ガイド (プログラミング・ガイド、インストールおよび構成ガイド、ソリューション・パターンなど) も用意されています。




上に戻る


まとめ

SOA シナリオは、顧客との典型的な関わりのなかで SOA が使用されている一連の汎用ビジネス・シナリオを表すものです。この SOA シナリオ・フレームワークには、IBM が SOA の実装で培ってきた豊富な顧客関連の経験が集約されています。それぞれの SOA シナリオが、現実世界での問題を解決するための SOA への取り組みで IBM 製品およびソリューションを使用する一般的なシナリオを代表しています。

SOA シナリオに関する連載の第 1 回目となるこの記事では、8 つのシナリオの概要、そしてシナリオ間の関係と相互依存性について説明しました。また、現実の SOA への取り組みのなかで、SOA シナリオを適用する手順も理解していただけたと思います。この手順は、連載の今後の記事で参照するとともに、実際に実行することになります。



参考文献

学ぶために

製品や技術を入手するために

議論するために


著者について

Tilak Mitra

Tilak Mitra は、エグゼクティブ IT アーキテクトとして IBM に勤務しています。サービス指向アーキテクチャー (SOA) を専門とする彼は、SOA における IBM のビジネス・ストラテジーおよび方向付けを支援しています。また、SOA 技術顧問の専門家として、複雑で大規模なエンタープライズ・アーキテクチャーを中心に、クライアントが SOA ベースのビジネスに転向する手助けもしています。彼が住んでいるのは太陽に光降り注ぐ南部のフロリダで、余暇にはクリケットや卓球に興じています。Tilak はインド・カルカッタの Presidency College で物理学の学士号を取得し、インド・バンガロールの Indian Institute of Science では学士号兼修士号を取得しました。




記事の評価


サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。



 


 


不充分・不完全である大変素晴らしい
 


この記事を共有する

del.icio.us del.icio.us newsing newsing FC2ブックマーク FC2ブックマーク
Choix! Choix! ニフティクリップ ニフティクリップ Yahoo!ブックマーク Yahoo!ブックマーク
MM/memo MM/memo CZブックマーク CZブックマーク livedoorクリップ livedoorクリップ
はてなブックマーク はてなブックマーク Buzzurl(バザール) Buzzurl(バザール)




上に戻る


    日本IBMについて プライバシー お問い合わせ