アーキテクチャ・ジャーナル

コンポジット アプリケーション ― 新しいパラダイム

Chris Keyser
2009/02/16
Page1 Page2

複合化のレイヤ

 複合化の意味についてご理解いただいたところで、その他に起きる複合化の種類についても理解を深めたいと思います。ここでは、複合化が起きるレイヤごとに複合化を分類して説明します。

図 3: 複合スタックのレイヤ
  • ユーザー インターフェイスとクライアント ロジックの複合化―関連したフレームワークを通じて協調する、結合の緩いユーザー インターフェイス部分によってビューを組み立てることができます。これらのビューは、トリガされるイベントと情報を通じて互換性のあるインターフェイスを持つシーケンスに組み立てて、さらに高いレベルの機能を作成することができます。そのような複合化は、デスクトップや Web サーバーのポータルから行われることがあります。現在この例には、Microsoft Patterns and Practices コンポジット アプリケーション UI ブロック、 Microsoft Office SharePoint のコンポジット アプリケーション フレームワーク、Eclipse Rich Client Platform、および他に多数のポータル フレームワークなどがあります。ページを構成する部分を定義する用語である Web パーツは、コンポジット フレームワークの構築を可能にするテクノロジです。Web 2.0 マッシュアップは通常このレイヤで、AJAX (Asynchronous Java and XML) を使用してブラウザで直接作成され、略式で予期しない複合化を表現します。

  • サービスの複合化―複数のサービスをプロセス フロー、メタデータ、およびルールと相互接続して、付加価値サービスを提供することができます。簡単ですが一般的な例に、注文サービスに対するサードパーティの信用調査の追加が挙げられます。サービスの複合化は、Microsoft BizTalk Server などの統合エンジン機能を使用して実行されることがよくあります。

  • データ/情報の複合化―3 番目のレイヤであるデータ/情報の複合化は、最も解決が困難であることが多いため、ほとんどのベンダは、明確に定義されたニッチを除いてこの問題を解決しません。ただし、この課題の克服に役立つ手法がいくつかあります。たとえば、マスタ データの管理 (MDM) は、(シンジケート モデルを使用して) 特定の種類の企業情報を集約、確定、分散します。エンティティ集約もここ数年話題になっていますが、ETL/データ ウェアハウスに基づいた、より一般的なアプローチを表します。本質的に異なるサービス間で機能の実行の調和を達成するのに必要な共有情報の集中化ビューを実現する一貫処理のメカニズムに EII (Enterprise Information Integration) を使用することもできます。レガシ システムにはサービス機能ラインに沿った、厳密に分割されたデータの境界という概念がないため、このようなアプローチが現在の実情です。また、現在のシステムが、これらの分割境界線に従って情報を管理するサービスを構築しやすいということもありません。参照データ、リソース データ、アクティビティ データ、メッセージ データの概念については、Pat Helland が Metropolis シリーズ(編集部注:リンク先ファイルがなくなっているため、参考になる別記事にリンクを設定しています)で詳しく説明しています。Maarten Mullender もサービス エージェントに関する記事でこのことについて解説しています。IBF (Information Bridge Framework) のようなフレームワークを使用すると、開発者はメタデータで示されたエンティティ ビューとリレーションシップを移動して、中間層サーバーではなくアプリケーションによるローカルな複合化を行うことができます。

  • エンドツーエンド プロセスの複合化―この場合、プロセスは、多数のビジネス システム間で通常長期間に渡って異なるメカニズムを使用して、まったく別の相互作用を統合するさらに高いレベルの複合化となります。従業員のプロビジョニングなどがその一例です。図 3 の段階説明は、一定期間中にバックエンド プロセスにアクセスする複数のクライアント アプリケーションを使用した相互作用を示しています。LOB システムが見積もりから現金までの構造化プロセスを明確化するような場合でも、プロセス複合化を使用することで、LOB 構造化プロセスの周囲で起きる相互作用を活用できる多くの機会があります。プロセスは、上記のユーザー インターフェイスやサービスなどの複合化の境界線内の他の領域にとっても重要ですが、そのような状況におけるプロセスの使用は、この場合とは異なります。そのような状況では、プロセスは複合化された表面の境界線の内部―たとえば、タスク駆動型 UI (ウィザードなど) の複合化されたクライアント内で定義されたワークフローや、多数の派生的なサービスの実施とビジネス ルールの評価を編成して、1 つの単位のビジネス機能を提供する複合化サービス内部のワークフローで行われます。

図 4: 独立した LOB システム間での複合化

新しいアプリケーション パラダイム

 コンポジット アプリケーションのフレームワークは、アプリケーションの構築、提供、エンド ユーザー経験を変えてしまう可能性があります。ただし、どの部分の経験をどの媒体を通じて表面化すべきか十分に考えなければならなくなるため、アプリケーション開発者の業務はある程度複雑になります。また、ベンダにとっては、真のサービス指向アプリケーション開発について熟慮し、コンポジット環境における機能のサービス境界線について慎重に検討することに対するプレッシャーも生まれます。複合フレームワークが使用しやすくなって、コンポジット アプリケーションが実行しやすくなるまで運用モデルとサポート モデルが進化すれば、多くのベンダを引き込む力は、変化を加速させる強力な動機になるでしょう。

 フレームワークを成功させるためには、コンポジット境界線のあらゆるレベルで摩擦を大幅に減らすことが必要です。共同作業シナリオはコンポジット アプリケーションの前提条件ではありませんが、比較的簡単で価値が高い軽量ソリューションには自然な条件でしょう。これらのプラットフォームは、モデル、ワークフロー、ルール駆動型アプローチに向けて移行を進めており、ビジネス ロジックからさらに設定しやすい属性へと表面化しているため、アプリケーションの要素の作成機能は、技術的なビジネス ユーザーに任されるようになるでしょう。

 これを実現するためには、基幹業務アプリケーションの構文レベルとセマンティクス レベルの両方で相互運用性を達成する必要があります。本格的な複合インフラストラクチャを達成するには、日々の作業を担当する開発者が多数の困難な問題へのソリューションにアクセスできる必要があります。これらの領域にはそれぞれ独自の記事が必要です。また、他の筆者が既に詳しく取り上げているものもいくつかあります。次のような問題点があります。

  • 識別情報―特に、1 つのストアや連合から共通のユーザー識別情報を汎用的に認識できるメカニズムを持つことです。クラウドベースのサービスが成熟するにつれ、識別情報は重要なサービスとして浮上してくるでしょう。SaaS (Software as a Service) のモデルを実現するには、クラウドベースの識別情報ストアがローカル識別情報ストアと連携する必要があります。コンポジット クライアント、コンポジット サービス、およびバックエンド サービス ロジック間で識別情報と認証資格情報がシームレスに渡される必要があります。デスクトップ上であっても、アプリケーション間で行われる経験がシームレスでなければ、長い目で見て有効とは言えません。このためには、識別情報を連携させ、広めるメカニズムを広範に採用することが必要です。

  • コンテキスト―コンポジット アプリケーションを連携して、洗練されたアプリケーションに適した豊かな経験を提供するには、コンテキストの考えが共有されている必要があります。協調するコンポジット アプリケーションとコンポジット アプリケーション内でコンテキストをやり取りするメカニズムに対応する必要があります。

  • 複合エンジン間におけるプロセスの統合―特定のサービス内で設定されたプロセス インターフェイスを配置することにより、補足ロジックの作成が促進されます。たとえば、販売パイプライン管理用のユーザー インターフェイスを表示して、Microsoft Excel ドキュメントを管理し、セールス フォース オートメーション (SFA) ビジネス アプリケーションで予測するために多段階のロールアップ承認プロセスを統合するドキュメント ワークフローを設計することができます。ロールアップ プロセス インターフェイスを設計環境に配置することにより、バックエンドシステムでイベントやアクションをトリガする協調ワークフローの構築が簡単になります。加えて、計画したプロセス インターフェイスを使用して、別のシステムに対応するプロセスの最新状態を把握し、解釈することができます。

  • エンティティ定義―複合化がアプリケーションの境界を超え、エンティティを多くの形式で使用できるようにするには、概念的なエンティティを物理的表現から分離する一元的な考えが必要です。エンティティの概念を定義したら、物理的表現が異なる場合にもこれを再利用できます。エンティティの一元管理定義とエンティティ間のリレーションシップは、コンポジット経験の拡張につながります。組織間の境界を超えてエンティティをどのように管理するか、エンティティを 1 つの形式から別の形式に変換しやすくするためにプラットフォームはどんなことができるか、と言う重要な問題は、未解決のままです。過去の標準化アプローチは、功罪相半ばする結果を生み出すにとどまりました。Microformats は、デファクト標準となりうる興味深い需要主導型のアプローチです。エンティティ データ管理および.NET LINQ (Language Integrated Query) は、Microsoft プラットフォームでこの方向を目指す第 1 段階と言えます。

  • データ/情報管理―これはエンティティの問題に関連していますが、多少異なります。前のセクションでも説明しましたが、今日のサービスとアプリケーションは、データの境界に関する強力な概念や、高パフォーマンスを提供しながらデータの境界を徹底するメカニズムがない場合がよくあります。リソース データ、参照データ、アクティビティ データ (コンテキストに関連)、およびメッセージ データの考えをしっかり識別し、設計パターン、ツール指定、およびインフラストラクチャでサポートする必要があります。データ所有、データのバージョン管理、参照データのシンジケート、および複数の有効なバージョンなどの複雑性に対処することは、現在のアプリケーション構築では考慮されておらず、インフラストラクチャによってこれらの問題解決が簡単になることもありません。

  • イベント インフラストラクチャ―現状では、ほとんどの Web サービスが要求/応答の性質を備えています。洗練されたアプリケーションで必要とされる豊かな相互作用パターンには、WS-* プロトコル スタックによってサポートされる洗練されたアプローチが必要です。

  • リポジトリ/検出メカニズム―UDDI は 1 つのレベルの検出性を実現しますが、制限があります。WS-Policy および WS-MetaDataExchange は、サービスと機能の情報を検出する追加のレイヤを付与します。この領域は、さらなる成熟が求められます。

  • モデリングとメタデータのフレームワーク―開発者は、モデルやメタ データを通じて、技術的なビジネス ユーザー、ひいてはエンド ユーザーがアプリケーションの動作と組み立て方法を制御し、設定管理できるよう、今後も開発した機能を認識し、表面化していく必要があります。モデル コンポーネントは、ワークフローとルールベースのシステムを使用して組み立てられます。ソフトウェア ファクトリにおける多くの概念は、ドメインに特化した開発者向けの優れたソリューションを構築し、必要な場所で開発者から組織に制御を渡す、というこのシフトに反映されています。動作制御の一部のレベルを手放すべきかどうか、また構成可能性のどの部分を制約して、正確性と一貫性を確保するかを判断するには、アプリケーション アーキテクトと開発者による慎重な分析が必要です。

まとめ

 複合可能性とは、不安定で一体型の開発者中心のアプリケーションで特定の 1 つの問題を解決するコンピューティングから、敏捷性に優れ、コンテキストが豊富で、ユーザー主導のアプリケーションで特定のビジネス プロセスをサポートするコンピューティングへのパラダイム シフトです。サービス指向へのシフト同様、このためには既存のコードのリファクタリングだけでなく、新しいコードの再考が必要になります。アプリケーションをホストする新しいインフラストラクチャも必要になります。SharePoint サーバーのサポートとワークフローのサポートを備えた Microsoft 2007 Office System は、こうしたアプリケーションに向けた第 1 段階です。将来的には、ユーザーが自身の作業環境を効果的に設定および制御し、アプリケーション間、または企業の境界間でシームレスにデータを渡し、タスクを完了できるトレンドが続くでしょう。このビジョンを実現するには多くの作業が必要ですが、Web テクノロジの進歩によるユーザーの期待が刺激となって、引き返すことはできなくなるでしょう。End of Article

謝辞

 本書の仕上げと推敲に力を貸してくださった Daz Wilkin と Jon Tobey の両氏に特にお礼を申し上げます。

著者について

Chris Keyser : マイクロソフトのグローバル ISV チームの主任アーキテクト。コード作成が得意で、Web サービス、分散システムおよびリアルタイム システムに特に興味がある。マイクロソフトに入社する前には、リアルタイムおよびビジネス システム開発の多彩なテクノロジを駆使して、一連の新興企業 (B2B/e-コマース、音声による生体認証、物理層ネットワーク スイッチング) の仕事を請け負ってきた。大学を卒業してから最初の 5 年間、Chris はヴァージニア級原子力潜水艦に乗務し、米国海軍で核工学司令官として大活躍。このときの経験が、システム エンジニアリングの集中的な訓練として、現在まで非常に役立つ経験になった。Chris は 1984 年、コンピュータ サイエンスと歴史の 2 つの学位を取得し大学を卒業した。


 

 INDEX
  [アーキテクチャ・ジャーナル]
  コンポジット アプリケーション ― 新しいパラダイム
    1.複合化の段階的説明
  2.新しいアプリケーション パラダイム

インデックス・ページヘ  「アーキテクチャ・ジャーナル」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間