WPF(Windows Presentation Foundation)は、Windowsアプリケーションを構築するための.NET APIです。WPFについて書かれたものの多くは、WPFを使えば以前と比べていかに簡単に、見栄えのかっこいいアプリケーションを作れるか、について述べています。しかし、WPFはフロントエンドの構築を行うためのパワフルなテクノロジーという他の(あまり目立たない)潜在能力も備えているのです。特に、システム間接続における.NETフレームワークの強力なサポートがWPFのアプローチと組み合わさってデータバインディングが行えることは、Java やRuby、.NETといったあらゆるバックエンドのサービスから情報を取得して表示する際の魅力的な選択肢となりました。
この記事では、WPFとその他のテクノロジー、たとえばAjax/DHTML、Swing、そしてFlashを比較します。そして、Javaをベースとしたバックエンドのサービスを例として用いて、WPFフロントエンドを構築してリッチクライアントとして役立たせるいくつかのシナリオをお見せしたいと思います。
WPFに関する簡潔なガイド
WPFはリッチクライアントアプリケーションを構築するためのプラットフォームです。.NETフレームワーク3.0の一部であり、そのため Windows Vistaには最初から組み込まれていますが、Windows XP サービスパック2とWindows 2003(Server)にもインストールすることが可能です。WPFのユーザインターフェースは.NETのオブジェクトモデルとして組み立てられています。しかし、WPFはXAML(eXtensible Application Markup Language)を勧めています。XAMLはマークアップ言語の一種で、デザインが必要なユーザインターフェースの外観と、その振る舞いを定義するためのコードを分離しておくことができます。どちらのアプローチ(.NETオブジェクトモデルとXAML)も等価で、XAMLは単に別の構文であるというだけです。しかし、XAMLの構文はツールにとって作成するのも取り扱うのも簡単なようにデザインされており、コーディングのスキルなしにデザイナが直接ユーザインターフェースを作成できるよう、そうしたツールが作成されることを意図しています。
(WPFに関するより詳しい情報はこちらのサイトを見てください:http://wpf.netfx3.com/)
WPFは、.NETで利用できる最初のリッチクライアントAPIというわけではありません。しかしその前任であるWindows Formsは、本質的にはWin32ウィンドウシステムの上に位置する.NETのレイヤです。そして、Windows FormsはWin32上で多くの機能を追加されましたが、基礎となるUIプラットフォームが持つ明らかな限界により制約を受け続けていました。WPFは Win32のウィンドウシステムの上には構築されていません。代わりにDirectXの上に構築されており、ローカルマシンに搭載されたグラフィックカードのパワー全てを利用することが可能です。しかし、WPFの目的は、単に見栄えの良いアプリケーションではありません。
WPFによってもたらされる最も大きな一つの利益は、多くのリッチクライアント機能を一つのプラットフォームに統合していることです。こうした個々の機能のほとんどは、しばらくの間は他のUIテクノロジーにおいて孤立して利用可能です。例えば、WPFはアニメーション化されたベクターグラフィックスとビデオを提供しますが、これは長い間Flashの十八番でした。WPFは一般的なボタン、リストボックス、ツリービューといった一般的なWindowsコントロールを提供しますが、これは何年にもわたってWin32とWindows Formsで利用可能でした。自由に配置可能な文章のレイアウトを提供しますが、HTMLはその一部分を最初から備えていました(しかし、WPFのテキストレンダリングは今日のHTML & CSSよりもはるかに進んでいます)。WPFによるアプリケーション構築の際用いるマークアップ・コードビハインドスタイルはまた、JSPや ASP.NETといったHTML指向のテクノロジーからそのまま持ってきたものです。基本的な3Dをサポートしていますが、OpenGLとDirectX ではより進んだ3Dレンダリングを何年にもわたって利用可能でした。
WPFの先達たちは自分が成すべきことについてはきちんとこなしますが、複数のテクノロジーからなる機能を一つのアプリケーションの中で使用するのは非常に困難です。Windowsのボタンやコンボボックスと連動してFlashのアニメーション機能を使用するのは非常に難しいです。(Flashアプリケーションは自身でコントロールを定義する傾向がありますが、それらは概してユーザが選択したOSの視覚テーマとは相容れない場合が多く、しばしばアクセシビリティの基準を満たさず、その振る舞いは通常ネイティブのコントロールとは調和がとれていません。)リッチクライアントアプリケーション内で、 HTMLによる文章レイアウトと連動したデータバインディングを使用することは、あまりサポートされていません。概して、テクノロジーを混ぜ合わせようとすると、アプリケーションは複数の異なる世界に引き裂かれるのが落ちです。
そうした隔たりの橋渡しをするのは、良くても不自由、しばしば不可能な場合が多いです。
対照的に、WPFはこれを簡単にします。不幸なことに、公開されているWPFサンプルの多くは、こうした(UIテクノロジーの)統合については、デモとして若干ふさわしくありません。フローレイアウト文書の真ん中に埋め込まれた、見た目は普通のWindowsボタンの見出しの一部として、回転する立方体上にフルモーションのビデオが張り付いているのは、さまざまに異なるUI機能が一つになっていることを確信させるデモンストレーションではあるでしょうが、こんな疑問もわいてきます。まともな思考をしていたら、誰が現実のアプリケーションでこんなデザインをするのでしょう?
実際には、一つのアプリケーションの中にUI機能をできうる限り統合するというのは起こりそうもありません。それをするのは、Webの初期に多くのサイトがあまりよく考えもせず、HTMLの機能をできる限り全て使ってやろうとしていたのを思い起こさせます。その結果は、めちゃくちゃでした。よいWebアプリケーションを作るために、テクノロジーをどう使うのがベストかを学ぶには、少し時間がかかりました。同様に、WPFの視覚機能をあらゆる組み合わせで使用するのはパワフルですし自由ですが、使いやすいアプリケーションを作るにはちょっとしたセンスと節度が必要でしょう。さらに、WPFは視覚的な冒険をしないアプリケーションにとってもかなり多くのものを提供してくれます。
なぜWPFのフロントエンドを作るのか?
なぜWPFのフロントエンドを作りたいのか、という議論を意味あるものにするためには、いくつか他の選択肢と比較する必要があります。明らかな候補として挙げられるテクノロジーとしては、Web、Swing、Flash、Windows Forms、またはWin32です。
Webフロントエンドと比較すると、WPFはより高い品質の対話性を実現できます。最近の対話的なWebアプリケーションの標準は改善されてきています。しかし、AJAXは昔ながらのプレーンなHTMLよりもかなり良い対話的な振舞いを提供しますが、実際何とも言いがたいです。我々は、対話性にひどい問題を抱えているということにほとんど気付かないほどWebに慣らされてしまっていましたから、単に「ひどくない」というだけのWebサイトに圧倒されてしまいました。最もよくできたAJAXアプリケーションでも、リッチクライアントの標準からするとかなり当り前のユーザエクスペリエンスの基準を満たしているだけです。さらにAJAXツールは急速に進歩してはいますが、満足のいく対話的な体験をAJAXで構築するには、リッチクライアント技術で少なくとも同程度のものを生産するのに比べて、依然として多大な労力が必要です。また、WPFアプリケーションはクライアントのマシンがネットワークにつながっていない状態でも動作します。Webアプリケーションにおいてもこの問題を解決すべく進歩が進んでいますが、現在では、リッチクライアントアプリケーションだけが断続的にしかネットワークにつなげないユーザにとっての説得力のあるソリューションを提供しています。
Swingと比較すると、WPFは注目に値する二つの利点を提供します。第一に、WPFのデータバインディングシステムです。特にXMLバインディングとデータテンプレート機能については、この記事でも後で取り上げます。二番目の利点はWPFを使いたくないという理由にもなり得る、もろ刃の剣です:WPFは Windowsでのみ動くよう設計されているのです。これは、ローカルPCが持つ性能を、特にグラフィックハードウェアのパワーをフルに活用することができるということを意味します。これにより、データの先進的な視覚化による高いパフォーマンスのレンダリングや、アニメーションやビデオでより飾り立てる、といった外観も可能になります。
Flashを使えば、アニメーションやビデオのプレイバックといったように、WPFと幾分同じように飾り立てることはできます。しかし、もし標準的なWindowsプログラムと同じような外観と振舞いを持つアプリケーションを作るとしたら、少し弱いです。WPFの素晴らしい強みの一つが、先進的なヴィジュアルの外観と、ユーザが期待するとおりにふるまうWindowsコントロールの標準セットをどちらも備えていることです。その両方を使用することもできますし、一つのアプリケーション内で自由に組み合わせることもできます。
他のWindows特有のリッチクライアント技術、たとえばWindows Formsや昔ながらのWin32開発と比べると、WPFはより良いデータバインディング機能を提供し、データをリッチな見せ方にするのもより簡単です。しかし、WPFは多くの利点を持ってはいますが、それを使わないと選択するであろういくつかの理由も存在します。
なぜWPFでフロントエンドを作らないか?
WPFの阻害要因として最もありそうなのは、クライアント上で.NET 3.0があまり利用されていないことでしょう。WPFアプリケーションは、エンドユーザのマシン上に.NET 3.0フレームワークがインストールされていることが必要不可欠です。もしWindows以外のオペレーティングシステムを走らせている、もしくは Windows XP サービスパック2よりも古いバージョンのWindowsを使用しているユーザをサポートする必要があった場合は、WPFは問題外です。もしクライアントマシンが適切なバージョンのWindowsを走らせていたとしても、.NET 3.0がインストールされているかどうかはわかりません。
(もしこうした理由でWPFを除外したとしても、WPF/Eを除外する必要はありません。これは、WPFの機能を切り詰めたサブセットを提供するUIプラットフォームです。'E'はEverywhereを表しており、Firefox WebブラウザやMac OS Xを含む非マイクロソフトプラットフォームでも動作するということから来ています。しかし、WPF/Eはまだリリースされておらず、現在ではその実用性も限られています。確かに、非常に初期段階の公開プレビューがちょうどこの記事の執筆中にリリースされました。それはWPF/Eの初期段階であり、今すぐその上に何かを築けるといったものではありません。)
気にとめておくべき他の点としては、典型的なWPFアプリケーションのメモリ使用量です。現在私のマシン上で動いているWPFアプリケーションを見ると、それらはすべてMicrosoft Officeスイートとサイズを競っており、'メモリを一番食う豚'選手権で競い合っているかのようです。(しかも、そうした特定のWPFアプリケーションはすべて、Officeアプリケーションのどれよりも機能がひどく少ないのです。)もし省メモリ設定のクライアントマシンをサポートする必要があるなら、WPFは最良の選択肢ではないでしょう。
また、さらに他のテクノロジーを採用したいと考えているかもしれません。もしあなたが.NETをすでに使っているなら、WPFは魅力的です。なぜなら、 WPFは単に.NETの世界における他の部分というだけですから、比較的学ぶのも採用するのも簡単です。しかしもしあなたのシステムが.NETを使っていなかった場合は、開発者達が学ぶ必要のある複数のテクノロジーを追加するコストより、潜在的な利益が勝っているかどうかを考慮する必要があります。
しかし、こうした阻害要因がないと仮定して、その有益さは試す価値があるように見えたなら、次のステップはどういう種類のWPFアプリケーションを構築するかを考えることです。
アプリケーションタイプとデプロイメント・オプション
WPFアプリケーションは様々な形をとります。Webライクなナビゲーションを持つUIを提供することも、より昔ながらのフォーム指向なスタイルをとることもあります。スタンドあローンのアプリケーションとして実行することも、ブラウザのフレーム内で全て実行されるようにすることもあるでしょう。そして、アプリケーションがどうデプロイされるかについて様々なオプションもあります。
リッチクライアントアプリケーションの伝統的なスタイルでは、Webブラウザの代わりに自身のウィンドウ内で動き、スタートメニューのプログラムリストから実行を開始できます。典型的なWebアプリケーションが持つ中央集権的なアップデートのモデルを失うことなく、こうしたスタイルをとることができます: WPFは.NETフレームワークの'ClickOnce'デプロイメント技術を使用でき、更新をWebサーバにデプロイしてクライアントマシンに自動的にダウンロードされるようにすることができます。
もしすでにWebベースのJavaアプリケーションがすでに確固としてあるなら、スタンドアローンのWPFアプリケーションはちょっと合わないように見えることでしょう。こういう場合は代わりに、ブラウザ上で実行されナビゲーションされるスタイルのWPFアプリケーションを一つ、もしくはそれ以上作ることで、アプリケーション全体の構造に混乱をきたすことなくWPFを活用し始められます。こう言ったアプリケーションの種類は'XBAP:XAML Browser Application'と呼ばれます。(先に述べたとおり、XAMLはWPFのユーザインターフェースを構築するときにしばしば使われるマークアップ言語です。) これはJavaアプレットにとてもよく似たモデルです。XBAPはWebページに埋め込まれたり、Webページ全体の代わりになることができ、どちらの場合でもセキュアなサンドボックス内で実行されます。全体的な構造を適切な形で残したまま、WebアプリケーションにXBAPを追加、もしくは置き換えていくことができます。これにより最も利益を得られる適切な部分にのみWPFを適用することができるため、「全か無か」というアプローチを必要としません。そしてまた、.NET 3.0が入っていないクライアントに対しては、XBAPの代わりに通常のWebページをいったことも可能です。
その他のオプションとしては、純粋なマークアップのアプローチがあります。XBAPをビルドする代わりに(常にアプリケーションをコンパイルされます)、単にXAMLを生成することができます。もしWebサーバがXAMLページを提供していたら、クライアントがWPFをサポートしている場合に限り、コンテンツはパースされ、レンダリングされます。これはWPFコンテンツを取り入れるための特に簡単な方法です: もしWebサーバのコンテンツ・マネジメント・システムがXSLTを使ってWebページを生成する機能をサポートしていたら、ソースからHTMLを生成するのと同様XAMLを生成することで、これが可能になります。
もし新しいWPFアプリケーションをスクラッチから構築しているのであれば、こうしてWPF を少しずつ適用できるというのはほとんど便利ではありません。そんな場合は恐らくスタンドアローンのクライアントアプリケーションに向かうのではないでしょうか。すると、クライアントアプリケーションがJavaサービスと対話するにはどうすれば良いかという疑問がわいてきます。
クライアントからサーバに接続する
WPFは.NET 3.0フレームワークの一部であり、.NET 3.0フレームワークにはWCFも含まれています。(WCF: Windows Communication Foundationは、分散サービスを作り、使用するためのテクノロジーです。それはまた、Webサービス標準も幅広くサポートしています。) これが示唆する、WPFクライアントをJavaサーバに接続するための戦略は明白です: クライアント側でWCFを使い、XML Webサービスを利用するのです。しかし、これが唯一の選択肢というわけではありません。(これは幸運なことです。なぜならいくつかの場合WCFを使えないことがあるからです。例えばWCFは現在、部分信頼のシナリオをサポートしていません。これの意味するところは、XBAPの中でWCFを使用できないということです。)
また、.NET 2.0スタイルのWebサービスクライアント機能を使用することもできます。WPFのデータバインディングシステムは幸運なことに、こうしたシステムでも WCFと同じように動作します。実際、どこからデータが来たかなんて全く気にしないのです。これが嬉しいのは、古いオブジェクトのセットをデータソースとして使用するときです。
同様にオブジェクトに対してバインドを行うこともでき、WPFはXMLデータへの直接的なデータバインディングにも優れたサポートを持ちます。これにより、POX (Plain Old XML)アプローチもとても良く機能します。次の章で、単純な例をお見せします。
XMLデータバインディング
WPF は、データソースとしてXMLに直接バインドすることができます。何らかの方法でXMLをラップする必要もありません。これを説明するために、非常に単純ですがとてもポピュラーなXMLデータ形式:RSSをバインドすることにしましょう。もちろんRSSは、多くの異なる技術で生成された、膨大な量の異なる発信元が世界には存在します。以下の例では、Sunの開発者サイトから発信されたRSSフィードを使用することにしましょう。(このサーバのどこかで Javaが関わっていると考えても間違いはなさそうです。) これは、RSSフィードからいくつかの情報を提供する、WPFのユーザインターフェースにおけるXAMLコードの断片です。
<Border BorderBrush="Black" BorderThickness="1" Padding="2">
<Border.Resources>
<XmlDataProvider x:Key="source" XPath="/rss/channel"
Source="http://developers.sun.com/rss/java.xml" />
</Border.Resources>
<StackPanel DataContext="{StaticResource source}">
<TextBlock Text="{Binding XPath=title}" FontSize="18"
FontWeight="Bold" Margin="0,5" />
<TextBlock Text="{Binding XPath=description}"
TextWrapping="Wrap" />
</StackPanel>
</Border>
例を単純にするため、XMLソースのURLは、ここではXmlDataProvider要素にハードコードされています。現実のアプリケーションでは、アプリケーション内にXMLを取り込む方法は他にもたくさんあります。
この例でいちばん興味深い部分は、StackPanelの中に入れ子になったTextBlockのペアです。(StackPanelは、子供要素を縦に積み重ねて整列するレイアウトコンポーネントです。) TextBlock要素のそれぞれは、ソースのXML文書と部分的に関連しています - その関連は、どちらのケースでも、'{Binding ...}'シンタックスで記述されています。これら要素中のXPath式は、ここであげた例の一番上部近くにあるXmlDataProvider要素と関連があります。最初のテキストブロックは、本質的には /rss/channel/titleというXPath式を評価し、その結果をテキストとして表します。以下に、この例の実行結果を示します。
この例で、私たちはXMLデータに対して何かする必要は何もありませんでした - Webから生の形式でそれを引っ張ってきただけなのに、です。WPFのデータバインディングサービスは、我々が表示したいと考えるデータを直接XPath 式で指すことができます。このアプローチは、データをXML形式で吐き出すあらゆるサービス(Java、もしくはその他)に対しても動作します。
この例では、フィードから情報の一つを取り出して見せるだけです。もう一つのWPFのデータバインディング機能が持つ利点を生かし、もうちょっと手間をかけるだけで、もっと興味深いものを作ることができます。それはデータテンプレートです。
データテンプレート
データテンプレートは、データをどう表示するかにおける再利用可能な記述方法です。データテンプレートは、複数個のアイテムに対して適用でき(例えばリスト内のすべての項目)、一貫した表示方法を行うことができます。以下の例は、前の例のStackPanelの内側に加えることができます。これは ListBoxコントロールを生成しますが、そのリスト項目は、この場合RSSフィード内の'item'要素の集合です。
<ListBox ItemsSource="{Binding XPath=item}"
ScrollViewer.HorizontalScrollBarVisibility="Disabled">
<ListBox.ItemTemplate>
<DataTemplate>
<Grid Margin="2,8">
<Grid.RowDefinitions>
<RowDefinition />
<RowDefinition />
<RowDefinition />
</Grid.RowDefinitions>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="80" />
<ColumnDefinition />
</Grid.ColumnDefinitions>
<TextBlock Grid.Row="0" Grid.Column="0" Text="Title:" Margin="0,0,0,6" />
<TextBlock Grid.Row="1" Grid.Column="0" Text="Description:" />
<TextBlock Grid.Row="2" Grid.Column="0" Text="Link:" />
<TextBlock Grid.Row="0" Grid.Column="1" FontWeight="Bold" FontSize="14"
Text="{Binding XPath=title}" TextWrapping="Wrap" />
<TextBlock Grid.Row="1" Grid.Column="1"
Text="{Binding XPath=description}" TextWrapping="Wrap" />
<TextBlock Grid.Row="2" Grid.Column="1" Foreground="Blue"
Text="{Binding XPath=link}" TextDecorations="Underline" />
</Grid>
</DataTemplate>
</ListBox.ItemTemplate>
</ListBox>
リスト内のそれぞれの項目はDataTemplateによって表示されます。この例では、内側に埋め込まれたListBoxで指定されています。このテンプレートからは、それぞれの項目をどう配置しフォーマットするか、データのどの部分をitemから取り出すか、といったことがわかります。結果はこのように見えます。
これは、データテンプレートが視覚的にどういったことを行えるか、について表面的な部分をかろうじて撫でているにすぎません。データテンプレート内でどんな WPFの機能を使うかは完全に自由ですし、テキストにこだわる必要もありません。データテンプレートは例えばイメージ、グラフィカル要素、アニメーション、3Dコンテンツなども取り込むことができます。テキストボックスのようなデータの編集を許容する対話的なコントロールや、あなたが好む対話的な振舞いを何でも提供するカスタムコントロールといったものも追加できます。
お解りの通り、データテンプレートはサービスからリターンされたデータのリストを整形するための異常なほど簡単な方法です。この例のように、プレーンな XMLデータに対して直接データテンプレートを適用することができます。また、オブジェクトに対してもデータテンプレートを使用することができます。たとえばWCFのWebサービスラッパーによってリターンされたオブジェクトです。
Webサービスとオブジェクトデータバインディング
XML に直接バインドできるという能力は便利ですが、何らかのラッパーオブジェクトに対しても動作してくれるとより便利なことがあります。もしWSDL定義を提供するWebサービスを扱っているなら、そうしたラッパーをツールを使って生成できることもしばしばです。そうした場合、WPFが持つオブジェクトベースのデータバインディングを使い、生のXMLに直接バインドする代わりにそうしたオブジェクトにバインドすることができます。
例えば、eBayは彼らのWebサービスAPIのWSDL定義を提供しています。ここからダウンロードできます。 http://developer.ebay.com/webservices/latest/eBaySvc.wsdl
(APIを使用するためには、彼らのサービスにサインアップする必要があります。しかしWSDLは自由にダウンロードできます。) eBayは、サーバのヘッダやサービスが返すエラーメッセージが示しているように、バックエンドにJavaを使用しています。Webサービスなので、 Javaで実装されているという事実がクライアント側のテクノロジーに何らかの制約を課すことはありません。そのため、WSDLを.NETクライアントにインポートすることができます。
.NET の最も初期段階のバージョンから利用可能だったWebサービスのサポートを使用することができます。代わりに、.NET 3.0から導入された新しいWCF (Windows Communication Foundation) ツールを使用することもできます。どちらのテクノロジーも、WSDLで定義されたメッセージや関連付けられた型に対する、同様のラッパークラスを生成するためのツールを提供しています。eBayのWebサービスAPIにおけるそうした型の一つにUserTypeがあり、ユーザについての情報を提供します。これに対してツールが自動生成したラッパーは、XMLから要素の値を抜き出し、.NETのプロパティとして表現します。我々はそれら(プロパティ)を WPFからバインドすることができます。以下のマークアップは、UIをUserType内のプロパティのいくつかとバインドしています。(この例では、 UserTypeのインスタンスをWebサービスから取得し、UIの'データコンテキスト'にそれを置き、バインディング目的でそのインスタンスを使用できるようにしているというコードが、アプリケーションのどこかに存在すると仮定しています。)
<Grid TextElement.FontSize="20">
<Grid.ColumnDefinitions>
<ColumnDefinition Width="Auto" />
<ColumnDefinition Width="10" />
<ColumnDefinition />
</Grid.ColumnDefinitions>
<Grid.RowDefinitions>
<RowDefinition />
<RowDefinition />
<RowDefinition />
<RowDefinition />
</Grid.RowDefinitions>
<TextBlock Grid.Column="0" Grid.Row="0" Text="User ID:" />
<TextBlock Grid.Column="2" Grid.Row="0" Text="{Binding Path=UserID}" />
<TextBlock Grid.Column="0" Grid.Row="1" Text="Email:" />
<TextBlock Grid.Column="2" Grid.Row="1" Text="{Binding Path=Email}" />
<TextBlock Grid.Column="0" Grid.Row="2" Text="Feedback score:" />
<TextBlock Grid.Column="2" Grid.Row="2" Text="{Binding Path=FeedbackScore}" />
<TextBlock Grid.Column="0" Grid.Row="3" Text="Registration date:" />
<TextBlock Grid.Column="2" Grid.Row="3" Text="{Binding Path=RegistrationDate}" />
</Grid>
注目すべきは、Binding式の中で"XPath=..."と指定する代わりに、"Path=..."と指定していることです。これは、データがXML 形式ではなくオブジェクトのプロパティ内にあると期待していることをWPFに対して伝えます。上のマークアップは、以下のようにユーザ情報を表示します。
このようにオブジェクトのラッパーを扱うことの利点としては、データを単に表示するという以上の事を、クライアントが行うのが簡単になるということが挙げられます。WPFアプリケーションは通常、マークアップとコードが混ざり合って成り立っています。Webサービスから取得したデータを、XMLから抜き出しオブジェクトにラップすれば、コードがこのデータを取り扱うのが簡単になり、アプリケーションに必要なクライアント側の振る舞いを何でも提供できます。
結論
Java サービスの上にWPFのフロントエンドを置くという、二つの非常に単純な例について見てきました。今回私たちが利用した、主なWPF特有の機能はデータバインディングです。それはサービスから取得したデータをUIにつなげるための非常に便利な手段を提供します。他のリッチクライアントアプリケーションと同様に、もちろんWPFアプリケーションもクライアントサイドのパワーと振舞いを私たちが望むだけ提供します。この例では、WPFは単に見た目が良いという以上の物であることを強調するため、わざと極端に単純なヴィジュアルにしていますが、WPFはデータバインディングや通常のWindowsコントロールといった平凡だけど退屈な世界を取り扱い、それを視覚的にリッチなプレゼンテーションへと高めていける可能性を秘めています。
.NETとJavaの統合シナリオに関する他のコンテンツについては、InfoQのJ+N (サイト･英語) コンテンツページも見てください。
著者について
Ian Griffithsは独立系のコンサルタント、開発者、講演者、そして作家です。彼はWindows Presentation Foundation、Windows Forms、そしてVisual Studioに関する書籍を執筆してきました。彼はロンドンに住んでいますが、様々な開発者のメーリングリストやニュースグループでしばしば見かけます。そうした場では、ほんの短い質問に対する返事として、彼からすさまじく長大なメールを受け取ってしまった人を眺めるのが人気の娯楽となっています。Ian についてもっと知りたければ、彼のブログ(http://www.interact-sw.co.uk/iangblog/)を見てください。
原文はこちらです：http://www.infoq.com/articles/wpf-rich-client-java
（このArticleは2006年12月20日にリリースされました）