アプリケーション・フレームワークの誤解と真実

日本ユニシス株式会社
サービスビジネス統括部 .NETビジネスディベロップメント
チーフSE
尾島良司

日本ユニシス株式会社
サービスビジネス統括部 .NETビジネスディベロップメント
猪股健太郎

聞き手、文責:デジタルアドバンテージ
2003/09/13

Page1 Page2

.NET Frameworkを超えるアプリケーション・フレームワークはあり得ないのか

―― .NETでは、アプリケーション・フレームワークのレベルとして.NET Frameworkが標準で提供されていることは分かりました。それでは、.NET Frameworkよりも使い勝手のよいアプリケーション・フレームワークを開発するということはできませんか。

 

尾島:技術的には可能です。これには2つの方法があります。1つは、.NET Frameworkよりも大幅に簡単なラッパーを開発する手段です。汎用のアプリケーション・フレームワークである.NET Frameworkがカバーする範囲は非常に広範ですが、そのうちビジネス・アプリケーションで使う範囲は限られます。そこで、あらかじめ使用する範囲のものだけしか利用できないような環境を作ってしまうのです。しかしこの方法では、開発範囲を狭めてしまうので、それによってどれだけ見返りがあるかは疑問です。もう1つは、.NET Frameworkよりも分かりやすくコーディングしやすいAPIを作成する方法ですが、これはあり得ないでしょう。百歩譲ってそのようなAPIが開発できたとしても、マイクロソフトの優れた開発ツールはそれらをサポートしません。いずれにせよ、実質的には不可能だということです。

 
 

猪股:APIではなく、CASEツールのようなものなら、適用範囲を絞ることで、マイクロソフト製品よりも使い勝手のよいものは開発可能ですし、実際にそうした製品もあります。例えば、データ・アクセスの部分だけに特化して、与えられたデータを表示し、データベースに格納するというだけなら、かなり生産性の高いCASEツールを開発できます。ユニシスでもそのような製品を提供しています。

ユニシスのアプローチはアーキテクチャ中心主義

―― 利用可能なドメイン・フレームワークが存在しないことは分かりました。それでは、アプリケーションを効率的に開発し、かつそれを柔軟性や拡張性のあるものにするにはどうすればよいのでしょうか。

 

猪股:実装の再利用は困難ですが、アーキテクチャのような構造を再利用していくことは可能です。ユニシスでは、アーキテクチャ中心主義のアプリケーション開発を推奨しています。

 
 

尾島:ここでいう「アーキテクチャ」とは、Rational社が提唱するRational Unified Process(RUP)でいうところの「アーキテクチャ」です。簡単にいえば、情報システム全体の論理構造をどのように分離すればよいのかを明確化するコンセプトです。アーキテクチャ中心主義をコンセプトとして、アプリケーション開発を支援するのが、ユニシスが提供している「LUCINAテクニカルドキュメント for .NET」(以下LUCINA)と呼ばれるものです。

―― 「テクニカルドキュメント」というのは少々漠然としていて実体が分かりにくい気がしますが、具体的にはどのようなものでしょうか。

 

尾島:広義の意味では、フレームワークと呼んでもおかしくないものだろうと思います。しかしこれまでお話ししてきたとおり、安易にフレームワークという言葉を使うとお客さまに誤解を与える可能性があるので、このような名前にしました。分かりにくいという点は私たちも同意見なのですが、技術者の良心のようなものだと考えてご容赦ください。

―― LUCINAテクニカルドキュメント for .NET(以下LUCINA)について、もう少し詳しく教えてください。

 

尾島:LUCINAではまず、フロントエンドとバックエンドを分離して考えます。そしてバックエンドをビジネスロジックとデータ・アクセスとデータ層に分けます。さらに、ビジネスロジックの中にコントロールとビジネスという論理的な構造を作り、その論理構造をどのような実装技術を使って作成していけばよいのかを定義しています。例えばコントロールやビジネスであれば、COM+コンポーネントを作成する、データ・アクセスであればVisual Studioで自動生成させるなどです。実装技術の選択肢は基本的に1つですが、別のオプションが存在する場合にはそれらも提供します。また、これらの概念で実際に作成されたソース・コードも併せて提供します。さらにLUCINAでは、こうしたシステムの構造を規定するアーキテクチャに加え、それをどのように開発するかというプロセスまでを規定します。開発プロセスには複数の道筋があるので、実際にどのような手順で開発するのが妥当か、プロセスの重要ポイントはどこかなどを踏まえて、プロセス・フレームワークを定めています。

―― LUCINAでは、ドメイン・フレームワークのレイヤ、すなわちシステムの業務依存部分はどのようにアプローチするのでしょうか。

 

尾島:繰り返しになりますが、この部分に狭義のフレームワークは適用できません。そこでLUCINAでは、一方にアーキテクチャを適用し、他方に実装に使えるコンポーネント群を適用して、システムの要件に合わせてその間を詰めていくというアプローチをとります。

―― その際、ベースとなるアーキテクチャは業種に依存しないのですか。

 

尾島:あまり依存しないと考えます。例えばマイクロソフトは、.NETテクノロジをベースとするアプリケーション開発のアーキテクチャ・ガイドとして、「Application Architecture for .NET: Designing Applications and Services」というドキュメントを提供しています。これは特定の業務を意識しない一般的なアプリケーション開発について述べたものですが、このドキュメントのガイドラインに従って、業務によらず70〜80%程度は開発が可能でしょう。ただし、アーキテクチャの方は業務にはあまり影響を受けないのですが、開発プロセスは業務によって大きく違ってきます。例えば、金融向けのシステムと、流通向けのシステムでは、開発プロセスのポイントや手順などがまったく異なります。このためLUCINAでは、開発プロセス部分については、柔軟性を持たせて入れ替えができるようにしています。

LUCINA for .NETとLUCINA for JAVA

―― 当初LUCINAは、Java環境向けに開発されたものだと伺っています。Java向けに開発されたものを、.NET環境に移行したということでしょうか。

 

尾島:実装基盤が異なるので、まったく違うものです。Java版とは別に新規に作成しました。JavaバージョンのLUCINAと.NETバージョンのLUCINAでは、定義されるアーキテクチャに大きな違いがあります。加えて、Javaバージョンでは、J2EEがプリミティブなインフラの機能しか提供しないので、独自にフレームワーク製品を提供しています。一方、.NETには.NET Frameworkがあるので、独自のフレームワークは提供していません。ただし、.NETとJavaのアプリケーションが企業全体の視点で柔軟に整合性を持って結合できるよう、互いを意識しています。

―― アプリケーション開発を行ううえで、Javaバージョンと.NETバージョンの良しあしの違いはありますか。

 

尾島:速く、低コストで開発したいというなら、.NETの方が圧倒的に有利だと思います。理由は、.NET Frameworkとして標準で提供されているAPIのレベルが高いので、独自に実装が必要となる部分が少ないと考えられるからです。

―― 逆に、.NETバージョンの欠点は何でしょうか。

 

尾島:当たり前ですが、アプリケーションがマイクロソフト・テクノロジに依存してしまうことでしょうか。もっとも、Javaバージョンにしたところで、程度の違いはあっても同じような問題は発生するので、.NET独自の問題とはいえませんが。

エンタープライズ・アーキテクチャの4階層による過去の資産継承

―― 特に大規模な情報システムでは、システム全体をいっぺんに変更するということはまれで、段階的に開発してきた情報システムを鋭意統合しながら使うことになると思います。そうした過去の資産継承において、アーキテクチャ・モデルとの不整合が発生するということはないのですか。

 

尾島:LUCINAでは、過去の資産継承を重視しています。この点については、エンタープライズ・アーキテクチャ(EA)の4階層に当てはめてシステム開発を進めます。エンタープライズ・アーキテクチャでは、情報システムを上位から「ビジネス」「データ」「アプリケーション」「テクノロジ」と4階層に分類します。そしてこれらそれぞれのレイヤについて現状(as is)から将来(to be)のあるべき姿を明らかにし、そのうえで、現状から将来へ移行するプランを練ります。企業によって考え方に違いがありますが、このエンタープライズ・アーキテクチャによって、ビジネス全体としてのアーキテクチャや、アプリケーションをどのような標準で開発していくかを決定することになります。具体的にいえば、現時点はVisual Basic 6を利用したクライアント/サーバ・システムだが、将来的には.NET Frameworkを利用したコンポーネント指向のアーキテクチャを目指すなどです。しかしこれまでの経験から、ユニシスでは、現実のシステム開発を円滑に進めるために、エンタープライズ・アーキテクチャの4階層における「アプリケーション」を、さらに企業全体を受け止めるような「エンタープライズ」と「アプリケーション」の2層に分離しています。

 

エンタープライズ・アーキテクチャの4階層

エンタープライズ・アーキテクチャでは、情報システムを上位から4階層に分類し、各レイヤについて現状から将来のあるべき姿を明らかにして、移行プランを練る。

―― テクノロジの部分は.NETで統一していくということでしょうか。

 

尾島:ベンダによるシステム・インテグレーションでは、自社製品を使うという理由から、テクノロジの部分を中心に考えることになるでしょうが、ユニシスでは「テクノロジ」は統一する必要はないという立場を取っています。

―― エンタープライズ・アーキテクチャの4階層モデルでは、現在と将来の両方を念頭に入れたシステム開発を行うということのようですが、これによって過去の資産継承だけでなく、将来のビジネスの変化にも対応できるということでしょうか。

 

尾島:エンタープライズ・アーキテクチャの4階層モデルでは、状態は常に変化するという前提で、常にあるべき将来の姿を追求していきます。例えば、去年考えていた5年後のあるべき姿と、今年考える4年後のあるべき姿は違うわけです。これを毎年更新していき、ゴールに向かうための道筋も変えていくというのがエンタープライズ・アーキテクチャです。それをうまく進めるためのプラン作成が最も重要になります。優先順位が高く効果も高いものから順に実行していくというプランを立て、次にそのプランを受け止められるだけのアプリケーション・アーキテクチャやテクノロジ・アーキテクチャを検討します。マイクロソフトは、アプリケーションやツールのための優れたテクノロジを作り出していますが、それだけではビジネス・システムとして受け止められるアプリケーション・アーキテクチャは提供できません。そこでユニシスでは、LUCINA for .NETという形でその部分を拡張し追加しています。

アーキテクチャを理解するための参考文献

―― システム開発では、アプリケーションのアーキテクチャを理解することが重要であることが分かりました。これを学ぼうとするとき、参考になるよい文献はありますか。

 

尾島:少々難しいですし、現時点では英語版しかありませんが、米Microsoftが提供している“Application Architecture for .NET: Designing Applications and Services”(前出)が参考になるでしょう。

 
 

猪股:ただし、入門者にとっては敷居が高いかもしれません。そこでInsider.NETにおいて、このドキュメントのエキスとなる部分を解説する連載を始めました。ぜひとも読んでください。

 

尾島:.NETではないのですが、SunがJava環境向けに提供しているJ2EE Blue Printは、技術論から始まっていて非常に分かりやすかったです。

アプリケーション・フレームワーク製品をどう見極めるか

―― 広義のフレームワークと狭義にフレームワークが混同して使われていることや、.NET Frameworkでは、JavaのStrutsなどに相当するアプリケーション・フレームワークは標準で提供されていることなどが分かりました。それらを踏まえた上で、.NET対応として市販されているアプリケーション・フレーム製品をどのように評価したらよいのでしょうか。

 

尾島:市販のフレームワーク製品が提供する機能が、.NET Frameworkの中ですでに提供されているものかどうかで見分けるとよいと考えます。例えば、市販フレームワーク製品の特徴が「分散トランザクション機能」だとすれば、それは標準のCOM+で可能です。「Webフロントエンドの構築が容易」といわれれば、それはASP.NETで可能です。「分散オブジェクト機能」といわれれば、それは.NETリモーティングやCOM+で可能です。このように、.NET Frameworkが本来備えている機能しかないのなら、その製品は狭義のフレームワークとしては新しいものを何も追加しておらず、.NET Frameworkと同じものを表面上だけラップしたものである可能性があります。それでも使いやすければよいのですが、たいていは.NET Frameworkにあるものの方が使いやすく、マイクロソフトの強力なツール・サポートも受けられるなどのメリットがあります。

 
 

猪股:特定の領域に特化したものなら、狭義のフレームワークとしても有効なものがあると思います。例えば.NET Frameworkは、ビジネスのワークフローまではカバーしていません。ですからワークフロー分野に特化したものなら、優れた狭義のフレームワーク製品もあり得るでしょう。

―― 広義のフレームワーク製品はどうでしょうか。

 

尾島:例えば、CASEツールや、ミドルウェア・パッケージ製品なら、単純に開発支援ツールやジェネレータなどの完成度を評価するしか方法はありません。他方、開発方法を提唱する製品なら、どれだけオリジナリティがあるかで評価します。多くの場合、ベースになるのはRational Unified Processだと思いますが、それをそのままではなく、ベンダやインテグレータに蓄積された過去のノウハウなどを基に、独自に拡張した部分がどれだけ優れているかに注目しましょう。単純にRational Unified Processを焼き直しただけのようなものは、あまりお勧めできません。

―― 市販のアプリケーション・フレーム製品を評価するためには、.NET Frameworkに精通する必要があるということですね。

 

尾島:そうですね。しかしクラス・ライブラリの隅々まで精通しなくても、概要を正しく把握していれば判断はできると思います。End of Article

 
 

 INDEX
  [Trend Interview ]
     アプリケーション・フレームワークの誤解と真実(1/2)
   アプリケーション・フレームワークの誤解と真実(2/2)
 
インデックス・ページヘ  「Trend Interview」


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メールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

注目のテーマ

Insider.NET 記事ランキング

本日 月間
ソリューションFLASH