システム管理者のための.NET入門 3.ビジネス・アプリケーションの論理3階層 デジタルアドバンテージ 小川 誉久2006/12/28 |
|
|
ビジネス・アプリケーションの論理3層構造
Web型システム開発では、アプリケーションのすべての処理をサーバ側で実行すると述べたが、実際には、ビジネス・アプリケーションの構造を論理的に階層モデル化し、それぞれを別のレイヤとして実装する方式が一般的になっている。異なるレイヤの独立性を高めてアプリケーションをモデル化することで、アプリケーションの開発効率や拡張性、柔軟性、メンテナンス性を高めることができる。3階層とは、ユーザー・インターフェイス層(UI層)、ビジネス・ロジック層、データ・アクセス層である。
ビジネス・アプリケーションの論理3階層 |
現在のビジネス・アプリケーション開発では、アプリケーション内部を階層モデル化し、レイヤの独立性を高めることで、開発効率や保守性を高めることが一般化している。 |
UI層(プレゼンテーション層と呼ばれることもある)は、ユーザーに情報を表示したり、ユーザーからの入力を受け付けたりする機能を担当するレイヤである。UI層は、使い勝手を向上させるためのインターフェイスの改善や、新デバイス対応など(PDAや携帯電話対応など)、ほかのレイヤに比較すると細かな変更や拡張が発生しやすい。ただし、UI層のプログラムは、ユーザー・インターフェイスの実装なので、ほかの層に比較すれば、実装やテストにかかるコストはそれほど大きくない。
ビジネス・ロジック層は、ビジネス・アプリケーションの実際の情報処理を担当するレイヤだ。このレイヤでは、業務フローや各種データ処理など、ビジネスで必要な情報処理をソフトウェアとして実装する。ビジネス・ロジック層は、ビジネスの処理そのものをプログラムとして表現したものであり、多少の変化があったとしても、本質的な部分は比較的長期にわたって変わりにくい特性がある。その代わり、ユーザー認証やトランザクション処理など、プログラム実装やテストには多大な工数が必要になることが多い。
データ・アクセス層は、データベース・システムへのアクセス機能を組み込むレイヤである。あらかじめ業務分析をきちんと実施してデータ構造を決定すれば、大規模な機能追加要請などが発生しない限り、データベースの構造を変更する必要に迫られることはそれほどない。アクセス効率や可用性、セキュリティ性能向上など、運用面からデータベース構造の見直しが発生することはあるが、本質的なデータ構造自体は何十年も変わらず使い続けられるというケースも少なくない。なお現実問題として、このレイヤは、利用するデータベース・システム(例えばSQL Serverか、Oracleかなど)によって内容が大きく影響を受ける。逆にいえば、データ・アクセス層を独立させることで、データベース・システムの違いから、ビジネス・ロジック層を分離できるというメリットがある。
.NET Frameworkにおいても、このような論理3階層ベースのアプリケーション開発を積極的に支援しており、.NET Frameworkが提供する各種フレームワークに従ってアプリケーションを開発することで、自然とこうしたモデルの適用が進むように構成されている。こうした高度なフレームワークの利点に直接享受するのはソフトウェア開発者だが、アプリケーション内部のモデル化が進んでいると、運用段階で発生した問題への対処や、運用して分かった改善点への対処なども、柔軟かつ低コストで実施しやすいという利点がある。
ビジネス・アプリケーションの構成と論理階層の関係
これまで説明してきたC/S型システム、Web型システムと論理階層の関係を図にまとめると次ようになる(スマート・クライアント型システムについてはすぐ次で述べる)。
ビジネス・アプリケーションの構成と論理階層 |
C/S型システムでは、アプリケーションのすべてのレイヤがクライアント・コンピュータ側に、Web型システムではサーバ側にある。ただし、従来のC/S型システムでは、3つの論理階層は明確には分離されず、混然一体として開発されているものがほとんどである。 |
C/S型システムでは、すべてのレイヤがクライアント・コンピュータ上で実行され、Web型システムではすべてがサーバ側で実行される。ただしこうした違い以前の問題として、Visual Basic 6.0などの古い環境で開発したC/S型ビジネス・アプリケーションでは、アプリケーションの論理階層化などはあまり意識せずに、UIからビジネス・ロジック、データ・アクセスまでを混然一体化して開発してしまいがちだった。このような作りにしてしまうと、UIに多少の変更が生じただけで、本来変更は不要なビジネス・ロジック処理やデータ・アクセス処理にまで変更の影響が及んでしまい、効率が悪い。
すでに述べたとおりWeb型システムの欠点は、UIをWeb(HTML)の制約の中で実現する必要があるため、Windowsアプリケーションのようなリッチで応答性能の高いインターフェイスを実現しにくいことだ。リッチなUIというと、見た目の問題と過小評価しがちだが、UIのデザインや応答性は、データ入力生産性に大きな影響を及ぼす場合がある。特に、オペレータが大量のデータを入力するようなアプリケーションでは影響が大きい。実際、クライアント・アプリケーションの配布問題を解消するため、それまでWindowsアプリケーションとしてUIを実装していたC/S型システムをやめて、Web型システムへの移行を検討したものの、操作時の応答性能が十分に得られずに、Web型システムの採用を断念した例などは珍しくない。
高度なUIとスケーラビリティの両立を目指すスマート・クライアント型システム
Windowsの機能を制限なく使ってリッチで応答性能の高いUIを実装できるWindowsアプリケーションと、Web型システムの高いスケーラビリティを両立しようと考案されたのが、3番目に示したスマート・クライアント型システムである。スマート・クライアント型システムでは、UI層をクライアント向けアプリケーションとして実装する。これはWindowsのネイティブ・アプリケーションなので、Windows OSが提供する高度なUI機能を最大限に活用できる。一方、ビジネス・ロジック層とデータ・アクセス層については、Web型システム同様サーバ側に実装する。
スマート・クライアント型システムの特徴は、クライアント側で実行されるUI層のWindowsアプリケーションと、サーバ側アプリケーションの通信をWebサービス・プロトコルで実現していることだ。Webサービスは、XMLとWebインターフェイスのHTTPを利用して、汎用性の高いアプリケーション通信を可能にするオープン・インターフェイスである。
分散アプリケーション用のインターフェイスとしては、これまでもOMG(Object Management Group)のCORBA(Common Object Request Broker Architecture、コルバ)やマイクロソフトのDCOM(Distributed COM)、SunのJava-RMI(Remote Method Invocation)、EJB(Enterprise Java Beans)などさまざまなプロトコルが開発されてきたが、仕様がシンプルで特定プラットフォームに依存しないことから、プラットフォームや用途によらず、現在ではアプリケーション連携の標準プロトコルとしてWebサービスが広く使われるようになった。
.NET Frameworkは、このWebサービスを強力にサポートしており、.NETアプリケーションは、容易にWebサービス・インターフェイスを使った通信機能を実装できるようになっている。
ただしこのスマート・クライアント型システムにしても、クライアント・アプリケーションの配布問題はC/S型システム同様につきまとう。これを解決するには、ClickOnce(後述)などを利用する必要がある。またいま述べたようにスマート・クライアント型システムでは、UIとビジネス・ロジックをクライアントとサーバ間で分離し、双方をWebサービス・インターフェイスで接続するのだが、この実装にあたっては、C/S型クライアント・アプリケーションでは不要だったUI設計の経験や開発スキルが必要になる。
以上、ビジネス・アプリケーションのタイプと特徴をまとめると次のようになる。
長所 | 短所 | |
C/S型 | ・VB 6など、過去の開発ツール、開発スキルを用いて開発が可能 ・クライアント・アプリケーションがデータベースに直接アクセスするシンプルな構造 ・リッチで応答性に優れたユーザー・インターフェイス |
・クライアント・アプリケーションがすべての機能を抱えており、修正のたびにアプリケーションの更新とクライアントへの配布が必要になる ・DBにアクセスするクライアント数が増えると、DB接続がボトルネックになりやすく、スケーラビリティが制限される |
Web型 | ・アプリケーションの機能はすべてサーバ側にあり、クライアントPCにアプリケーションを配布する必要がない。クライアント側はブラウザさえあればよい ・配布問題とは無関係に、サーバ側だけでアプリケーションの更新ができる |
・UIがHTMLの機能に制限され、自由度が低い(高度なインターフェイスを実現できない) ・操作のたびにWebサーバへのアクセスが発生するため、応答性が低下しやすい ・3階層型のアプリケーション・モデルを意識した、コンポーネント化やトランザクション設計などが必要。相応の開発スキルが必要とされる |
スマート・クライアント型 | ・C/S型と同じく、クライアント側にアプリケーションをインストールするので、リッチで応答性に優れたインターフェイスを実現できる ・ビジネス・ロジックやデータ・アクセス機能はサーバ側にあるので、UI以外についてはクライアントへの配布を発生させずに変更できる ・大規模クライアント対応など、C/Sよりも高いスケーラビリティを実現しやすい |
・C/S型と同じく、アプリケーションの配布問題が存在する ・UIとビジネス・ロジックをクライアントとサーバで分離し、Webサービス・インターフェイスで接続するため、アプリケーション設計の難易度が高まる。結果として、開発コストが増大する可能性がある |
構成によらずビジネス・アプリケーション開発を支援する.NET
第2回である今回は、ビジネス・アプリケーションの典型的な構成であるC/S型システムとWeb型システム、そして新しいWebサービスを利用して、CS型とWeb型の利点を両立しようとするスマート・クライアント型システムを紹介するとともに、ビジネス・アプリケーション開発を効率化する論理階層モデルについて述べた。.NET Frameworkは、これらのアプリケーション構成によらず、さまざまな面からアプリケーションの効率開発やメンテナンス性向上を支援している。
あらためていうまでもなく、一概にどの構成が優れているとはいえない。高度なUIやレスポンス性能ではC/S型、スマート・クライアント型が優勢だが、クライアント側の環境によらず広く使えるアプリケーションを実現し、クライアント管理のTCOを圧縮するにはWeb型システムが有利だ。
クライアントOSであるWindowsや、ビジネス・アプリケーションのOfficeを収益の大きな柱とするマイクロソフトにとって、クライアント管理のTCOをできるだけ圧縮しながら、C/S型やスマート・クライアント型の特長を生かせる仕組みを提供することは、極めて重要である。これに対するマイクロソフトの回答が、クライアントへのアプリケーション配布の問題を大幅に解消するClickOnce技術の提供だ。次回は、このClickOnceの挙動を詳しく解説し、ClickOnceがどのようにアプリケーションの配布問題を解決するのかを具体的に紹介することにしよう。
INDEX | ||
システム管理者のための.NET入門 | ||
第2回 ビジネス・アプリケーションの現在と.NET | ||
1.C/S型システムの特長と問題点 | ||
2.Web型システムの特長と問題点 | ||
3.ビジネス・アプリケーションの論理3階層 | ||
「システム管理者のための.NET入門」 |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|
.NET管理者虎の巻
- - PR -
- - PR -