 |
||||||||||||
|
||||||||||||
| 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| .NET Frameworkに加わった新しいテクノロジ | ||||||||||||
|
第1〜2回では、.NETという基盤の性質や方向性をいくつかの例を通してみてきました。 今回は、これまで説明してきた内容を踏まえ、最新の.NET Framework 3.0のテクノロジについて解説していきます。 .NET Framework 3.0は、これまでの.NET Framework 2.0を基礎として、新しく以下の4つのテクノロジが追加されました（注1）。
表1：.NET Framework 3に加わった新しい機能
注1：
それぞれは、プレゼンテーション、通信、プロセス、認証に関する新しいテクノロジです。これらは適材適所に使うことができるうえ、.NET Framework 2.0のすべての機能も従来通りに動作します。
.NET Frameworkは、「第1回：あらためて『.NET』を考える」で説明したようにWindows上の多くのソフトウェアの実行を支えるエンジンとしての役目を果たします。家庭での利用、モバイルデバイス上での稼動など、OSと同じように生活の中に浸透し、幅広い基盤としてその役割を担う必要があります。その一方で、「第2回：開発の視点からみた.NET」でもみてきたように、開発のフレームワークとしても高度で先進的な様々な仕組みを提供しています。 表1の4つの新しいテクノロジについても、こうした従来の考え方は継承されています。以降では、これら4つのうち、Windows Communication Foundation（WCF）、Windows Workflow Foundation（WF）、Windows Presentation Foundation（WPF)の3つのテクノロジに絞って、こうした点を順番にみていきましょう。 |
||||||||||||
| Windows Communication Foundation（WCF） | ||||||||||||
|
第2回で、.NETの開発フレームワークの側面について説明しましたが、WCFは、この方向性をさらに強化しています。 WCFを使えば、キューを使用した処理などあらゆる通信処理の実装において、通信手段などのシステム的な動作はソースコードに記述する必要はありません。こうした内容はすべて構成ファイルに設定しておき、ソースコードでは、開発者が記述すべき要件のみに集中して記述できるようになります。 WCFによる実装（C#によるコントラクトの実装）
[ServiceContract()]
しかし、WCFが提供するこうした抽象化は、単なるビジネスロジックへの集中化や、位置透過のための通信テクノロジではないという点が重要です。 開発者が作成するソースコードが、通信手段を意識せず、単にビジネスロジックに集中して書ける（つまり、通信手段を実装コードに含めなくてよい）というだけであるならば、第2回でみてきたように、.NETにおけるWebサービスの開発などでもすでにその目的が達成できています。WebMethodという「属性」を指定すれば、実際に開発者が作成するコードはビジネスロジックのみで十分でした。 WCFにおいて重要なことは、メッセージングプロトコルやシリアライズ方法などの通信処理におけるバインド方法と独立性を持たせているという点です。 特定の通信コンポーネントやメッセージングプロトコルへ依存している場合、あるいは機動的にこうしたコンポーネントを切り替えられないという場合は、サービス指向開発によるシステム整備など、企業内で特定のメッセージングルールへ統一的に切り替えようとする際の大きな阻害要因となります。 例えば、あるキューを使用しているシステムでは、処理を随時受け付けて、データがすべて揃った段階で夜間などマシンを使っていない時間にまとめてバッチ処理を実行しなければ、翌日に間に合わないのかもしれません。 また別の例として、.NETリモーティング（TCPを使った.NET独自の通信方法）を使っているある企業では、XMLのペイロード（データの転送量）やパフォーマンスの理由でWebサービスを使うことができないのかもしれません。 このように、企業がその実装方法を採用している背景には、様々な理由や経緯があります。通信手段が特定のメッセージングプロトコルに依存している場合、こうした状況に対処するためにそのメッセージングプロトコルと連携できるブリッジを作成する必要があるかもしれません。しかし、結果としてそのブリッジによるレスポンス低下が次の新たな課題となることでしょう。つまり、アーキテクチャを見直さず、こうした応急措置的な対処をしても限界があります。これら諸問題を抱えながら、新しい通信基盤に段階的に切り替えようとしても到底無理な話です。 こうした経験則を踏まえ、WCFではメッセージングプロトコルなどの通信要件をいつでも差し替えることができるようになっています。それらと独立したより高度な抽象化を実現しています。 例えば、プログラムコードを変更せずに、Webサービス（XML／HTTP／SOAPなどのインターネット標準を使った通信方法）をあるタイミングでTCPによる別の通信方法に切り替えたり、すでに稼動している従来のキューのシステムやWebサービスをWCFで利用したり、さらには、WCFを使ってキューでもWebサービスでもどちらでも受け取れるサービスとして動作させるなどといった混在が可能です。 移行も可能なところから順次行っていき、その過程では既存の実装を混在させたままWCFと連携することが可能です。また、パフォーマンステストの結果などによってメッセージングプロトコルを簡単に差し替えるなど、実際の開発の場面においてもその恩恵を受けることができることでしょう。必要な場合には、UDPトランスポートなどWCFがビルトインしていないバインド方法についてもカスタマイズしてWCFに組み込んでいくことが可能です。 またWCFは、こうしたバインド方法以外にも、セキュリティ、トランザクション、リライアビリティなどの様々な動作上の性質もコードと分けて構成することができるようになっています。 OASISなどの標準化団体では、こうしたWebサービスに関するセキュリティやトランザクション管理など多数の拡張仕様を規定していますが、これらのすべてを開発者が理解して実装コードに自身で組み込んでいくことは、よほどの専門家でなければ不可能でしょう。WCFは、こうした複雑化する実装技術を簡素化し、開発者にとって扱いやすくしているという利点もあります。 |
||||||||||||
|
1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
