InfoQ ホームページアーティクル SilverlightとJavaのインターオペラビリティ

SilverlightとJavaのインターオペラビリティ

ブックマーク

2008年11月22日読了時間 35 分

作者：

Robert Bell

翻訳者

松本清一

はじめに

概要

Silverlightを連携することに関心があるJavaコミュニティの人々に対するソリューションの一つとして、本稿では、それを始める手助けとなる有益な情報を提供します。MicrosoftのSilverlightは、次世代のメディアエクスペリエンスとWebのためのリッチでインタラクティブなアプリケーションを実現する手助けとなるように設計された、クロスブラウザ、クロスプラットフォーム、クロスデバイスのブラウザプラグインです。ここでは、インターオペラビリティのシナリオを含めて提供するために、Silverlightの背景を含んでいます。基本的な Silverlightの機能、Silverlightの開発コンセプト、Silverlightがリッチなインターネットとして良い位置につける方法、メディアが利用可能なことを通して、Silverlightのメリットと制限事項を含んだアーキテクチャとアプリケーションに"到達します" 。

SilverlightとJavaのインターオペラビリティのシナリオを3つについてとりあげます。具体的には、SOAPの Webサービス、RESTのWebサービス、シンジケーション(RSS)のフィードサービスについて概観します。SOAPのWebサービスとRESTの Webサービスは、NetBeansで現在利用可能なツールを使用して作成します。各インターオペラビリティの概説には、デモコードと共に、インターオペラビリティのシナリオが最も使われるであろう部分に関するいくつくかの見解を含みます。注意点として、Silverlightはソケットや、より複雑であまり一般的ではないインターオペラビリティのシナリオでも機能します。しかし、それは将来の記事のテーマとする予定です。本稿では、いくつかのアーキテクチャのガイダンスだけでなく、Silverlight 2 ベータ2によるSilverlight-Javaのインターオペラビリティの概説をします。

対象範囲

本記事では、Silverlightアプリケーションを作成し、開発者が以下のインターオペラビリティのシナリオを活用するために、Visual Studioを使用したJava-Silverlightインターオペラビリティにフォーカスします。:

SOAP Webサービスのインターオペラビリティ
RESTサービスのインターオペラビリティ
シンジケーション(RSS)サービスのインターオペラビリティ

Silverlightは、ソケットや、より複雑であまり一般的ではないインターオペラビリティのシナリオでも機能しまが、それは本記事の対象外です。

ゴール

Javaコミュニティに基本的なSilverlight-Javaサービスのインターオペラビリティを実装するための選択肢を提供します。

目的

読者は、Silverlightが何であるか、それがどこで使われるかについて、適切な理解が得られます
読者は、Silverlightの利点と制約を含む、そのアーキテクチャに関する基本的な理解が得られます
読者は、前節の対象範囲で記した3つの基本的なサービスのインターオペラビリティのシナリオを利用したJavaサービスと、Silverlightクライアントが、どのようにして相互運用できるのかについての有用なガイダンスが得られます

Silverlight概説

MicrosoftのSilverlightは、次世代のメディアエクスペリエンスとWebのためのリッチでインタラクティブなアプリケーションを実現する手助けとなるように設計された、クロスブラウザ、クロスプラットフォーム、クロスデバイスのブラウザプラグインです。 Silverlightは、リッチなインターネットアプリケーションがブラウザクライアントにインターネットを素早く展開するためのシナリオに「到達する」ことを目的としています。Silverlightは、Webページの内容がそのホストと接続し、ユーザーと深く関わり、あらゆるブラウザでの表示を可能とするために設計されています。Silverlightの利用シナリオです(リンク)。

ユーザーインターフェース設計とロジックの関心事を分離することにより、アプリケーション開発のライフサイクル(ADLC)生産性が改善しています。Microsoft Expression(リンク)とMicrosoft Visual Studio(リンク)を使用することにより、ユーザーインターフェースのデザイナと開発者が、今ある技術をより有効に活用して協業することができます。

Extensible Application Markup Language (XAML)(リンク)は、フロー制御をサポートした宣言型のXMLベースの言語で、ユーザーインターフェース設計に使用されます。VB.NET、C#、IronRuby、 IronPythonといった.NET言語は、ユーザーインターフェースの裏でロジックを組むために使用されます。Windows Presentation Foundation(WPF)とSilverlightは、共にXAMLを使用します。

Silverlightランライムは、Silverlightアーキテクチャの基盤です。Silverlight 2 ベータ2では、Internet Explorer、Firefox、Opera、Safariのブラウザのプラグインとして、4.6 MBのダウンロードが一度必要となります。zip形式の「.xap」ファイルは、Silverlightアプリケーションのデプロイパッケージです。「.xap」パッケージには、アプリケーションと実行のためのSilverlightプラグインコントロールへのエントリポイントが含まれます。「.xap」ファイルは、Visual Studio .NETで開発します。ビルドがあるたびに、Silverlightではクライアントの「.xap」ファイルが更新されます。Silverlightアプリケーション(「.xap」ファイルパッケージ)は、あらゆるWebサーバーにデプロイ可能です。

図1: Webブラウザサンドボックス内のSilverlight

Silverlightコントロールは、HTMLページ内に含まれます。言い換えれば、Webブラウザのサンドボックス内に含まれるということです。MSDNの技術記事、Silverlight アーキテクチャ概説(リンク)には、Silverlightアーキテクチャに関する高レベルな解説や、マイクロソフトのユーザーエクスペリエンス(UX)のcontinuumでの Silverlight位置づけの説明、Silverlightのデプロイメントとパッケージングに関する概説があります。Silverlightの実行のために、クライアントマシンへの.NETのインストールが不要であるという点に注意することは重要です。Silverlightアプリケーションを実行するために必要なもの全ては、Silverlightブラウザプラグインの中に含まれています。インターオペラビリティのシナリオは、 Silverlight 2 ベータ2でおこないます。新しいSilverlight 2 ベータ2の機能(リンク)は、以下のとおりです。:

フレームワーク言語(Visual Basic.NET、C#、IronPython、IronRuby)
分離したストレージ
(ソケットのサポートだけでなく、) JSON、REST、SOAP/WS-I、POX、RSSのWebサービス
WCFサポート
ADO.NETデータサービス
オブジェクトとXMLのLINQ
Deep Zoomの技術
XMLプログラミング
メディアコンテンツの保護
豊富なマネージコントロールフレームワーク
開発者の生産性を改善するための新しいコントロールセット(チェックボックス、クロスドメインネットワークアクセス)
オブジェクトのLINQ
StackPanel、Grid 、Panel Layoutのサポート
マネージコントロールフレームワーク
コントロールのフルセット(TextBox、RadioButton、Slider、Calendar、DatePicker、DataGrid、ListBox、TabControlなど)
Deep Zoomの技術
マネージHTMLのブリッジ
マネージ例外のハンドリング
メディアコンテンツの保護
豊富なコアフレームワーク(例. Generics、collections)
セキュリティの実施
タイプセーフな検証
XMLReader/Writer

SilverlightのWebサービスチームのブログには、Silverlight 2 ベータ2のWebサービス機能の詳説があり(リンク)、Silverlight 2 ベータ2での優れたWebサービスのバックグラウンドを提供しています。現時点では、WS-IベーシックプロファイルをこえたWS-*をサポートしていません。

図2: Silverlight でのサービスインターオペラビリティのアーキテクチャ(リンク)

Java Scriptと.NETのランタイムコードの両方が、イベントとメソッド呼び出しによってSilverlightプラグインと通信します。 Silverlightコントロールは、HTMLページとJavaScriptを通したそのコンテンツとやりとりすることができます。MSDNのページ「Silverlightプログラミングモデル(Silverlight 2)」(リンク)では、SilverlightオブジェクトモデルのWebページ(DOMオブジェクトモデル)の中での適合について説明しています。

リソースバインディングとデータバインディングは、(Page.xaml.cs)のコードへの参照を通して、XAML (Page.xaml)の中でおこなわれます。Silverlightのプラグインは、ユーザーインターフェースでXAMLを表現します。

Silverlightのイベントモデル(リンク)は非同期です。非同期モデルは、効果的にSilverlightを使うために採用されるべきものです。ブラウザ全体に対する共通のユーザーインターフェース (UI)スレッドがあり、UIスレッドがブロックされると、ブラウザ全体が反応しなくなるかもしれません。バックグラウンドのスレッドは、ネットワーク呼び出しやUIスレッドをブロックするかもしれない別のコードすべてを実行することができます。

セキュリティ

認証

Silverlightはブラウザープラグインなので、ブラウザーによって提供されるセキュリティに依存します。大部分の認証のケースは、HTTPSとベーシック認証と連動しています。HTTPSは、Secure Socket Layer (SSL)プロトコルで、認証と通信のセキュリティを提供します。HTTPSを利用することで、トランスポート層を通してなりすましや機密情報の漏えいの脅威を軽減しなければなりません(サービスのアクセスに関するセキュリティ上の留意点(リンク))。

1) URI、あるいは、2) メッセージ本体(たとえばSOAPヘッダ)、に認証情報を埋め込むといった、メッセージ内の認証が代替の認証アプローチです。


     
       MyName
       MyPassword

図3: SOAPヘッダー認証

WS-*

WS-* の対応は、Silverlightの将来のリリース機能として検討されています。

URLのアクセス制限

Silverlightは、URLを3つの種類のアクセスに制限することによって、ネットワークの脅威を防ぎます。それは、スキーム間URL、ドメイン間URL、ゾーン間URLの3つです。URL アクセス制限(Silverlight 2)(リンク)

トランスポート層のセキュリティ

Silverlight 2 ベータ2では、HTTPとHTTPSのURIスキームをサポートしています。Silverlight 2 ベータ2の段階では、HTTPSとスキーム間のサポートは非常に制限されていますが、Silverlight 2 RTMではHTTPのスキーム間サポートがフルサポートされる予定です。

図4: Silverlight 2 ベータ2でのHTTPサポート

生成されたプロキシでのSOAPサービスの利用については、HTTPとHTTPSの設定が、 ServiceReference.ClientConfigファイルにあります。security mode要素のHTTPSの方には「Transport」が、HTTPの方には「None」が設定されています。

図5: security modeの設定

Silverlightと.NETフレームワーク

Silverlightのための.NETフレームワーク(リンク)の名前空間は、.NETフレームワーク名前空間のサブセットです。これらの名前空間の内包によって、Silverlightのランタイムに含まれているサイズについてのコストに対して、与えらたすべての.NETアセンブリの効用の均衡を保ちます。

Silverlight 2ベータ2では、XMLとJava Object Serial Notation(JSON)フォーマットの両方をサポートします。(SilverlightでのJSONデータの使用(リンク)、方法: JSONデータをシリアル化および逆シリアル化する(リンク))

ブラウザ制限

Silverlightは、クロスブラウザーのプラグインです。Silverlightの機能の多くが開発中で、 Silverlightをサポートしているブラウザーの全ての機能に依存し、制限されています。たとえば、これらのブラウザーのいずれかがPUTや DELETEのHTTPメソッドをサポートしない時点で、SilverlightもPUTとDELETEのHTTPメソッドをサポートしません。言い換えれば、実際には多くの制限が「広範なブラウザのサポート」に依存していて、明確なSilverlightの制限ではありません。

その他のブラウザの制限には、以下を含みます。:

ドメイン間のケースだけで発生する制限。たとえば、カスタムのGETヘッダーがドメイン間のリクエストに対して作成することができない。とか、
Content-Type以外のレスポンスヘッダを読むことができない。

サービスインターオペラビリティのシナリオ

サービスインターオペラビリティのシナリオは、「現実世界」の実装で動いているさまざまなシナリオをどのように示すかという、単純な「証明のポイント」です。

Silverlightを起動、実行するための第一ステップとして、Silverlight Get Started(リンク) のページへ行ってください。これらのシナリオでは、NetBeans 6.1(リンク)と、Visual Studio 2008(リンク)で開発をします。Silverlightの最新リリースに対応するためのVisual Studioの設定方法については、Silverlight 2アプリケーション開発をはじめる(リンク) を参照してください。

ドメイン間のシナリオ

このシナリオではドメインを超えるので、サービスを利用可能とするために、Java WebサーバーのドキュメントルートディレクトリにSilverlightの「clientaccesspolicy.xml」ファイルをおきます。(オプションです)

ドメイン間の脅威を防ぐために、オプションのポリシーファイルで許可されている他ドメインのホストサービスを除いて、イメージやメディアといったすべてのリクエストに対する通信は、自ドメイン内の通信のみが許可されています。そのオプションのファイルとは、次の2つです。1) Silverlightの‘clientaccesspolicy.xml’ ファイルで、サービスの細かなアクセス許可に使用されます。または、2) Adobeの‘crossdomain.xml’です。Silverlightのクライアントは、初めに‘clientaccesspolicy.xml’ ファイルを確認し、その後で‘crossdomain.xml’ を確認します。どちらも見つからなければ、“404 Not Found” のHTTP標準のレスポンスコードが返されます。Tim Heur氏は、クロスドメインのサービスについて、以下で詳細な説明をしています。 Silverlightのドメイン間サービスと有用なツール(リンク): .

そのポリシーファイル(‘clientaccesspolicy.xml’ と ‘crossdomain.xml’)は、1) すべてのヘッダー、または、 2) Content-Type と SOAPアクションヘッダー(リンク)のどちらかを許可することで、SOAPを明確に有効にする必要があるという点に注意することが重要です。

すべてのドメインからのドキュメントへのアクセスは、domain="*" と記述することで可能となります。あるいは、特定のドメイン(群)からのドキュメントへのアクセスは、たとえば、 domain="*.microsoft.com". とすることで可能となります。Silverlightのポリシーファイル形式の記述は、以下で得られます。ネットワークセキュリティのアクセス制限 (Silverlight 2)(リンク) crossdomain.xmlファイルのサンプルは、方法 : ドメインの境界を越えてサービスを利用できるようにする(リンク)にあります。本稿でのこのサービスのシナリオのすべてにおいて、clientaccesspolicy.xml、あるいはcrossdomain.xmlを、ドメインルートに置く必要がある点に注意してください。

図6: http://localhost:8081/clientaccesspolicy.xml (リンク)

RESTサービスのシナリオ

REST(REpresentational State Transfer)は、Roy Thomas Fielding氏(リンク)により、2000年の彼の博士論文(リンク)で初めて登場した考えです。その単純さと親しみやすさから、人気が高まりつつあります。World Wide Webは、RESTアーキテクチャです。RESTは、以下の原則に基づきます。:

全てのリソースがリソース識別子を持つ
表現(方法)が標準である
リソースが複数の表現を持つ
コネクタはリソースのアクセスや転送の動作をカプセル化する(コネクタの種類は、クライアント、サーバー、キャッシュ、リゾルバ、トンネル)
RESTのインタラクションはステートレスである

RESTの単純さと親しみやすさは、その人気の高まりの一因となっています。RESTの単純な考え方は、次のとおりです。リソースの状態が、URIの操作によって変化します。

「純粋なREST」イデオロギーは、次の考えを含みます。1）すべてがアドレスとリソースとして表現されます。 2) リソースの操作に必要なのは、create、read、update、deleteの4つのオペレーションのみです。

「RESTへのHTTPのマッピング」の部分(多くの人々のRESTの見方)については、「純粋なREST」と同じです。しかし、アドレスがURIで、4つのオペレーションがHTTPメソッドのGET、PUT、POST、DELETEとなります。

POXサービスが「純粋なREST」アーキテクチャに従わないとき、このアプローチは時々「低級なREST」と呼ばれます。4つの標準のオペレーションの代わりに、複数のカスタムオペレーションがあるかもしれません。あるカスタムオペレーションは、オペレーションに対する特定のHTTPメソッドの利用というよりは、POSTのHTTPメソッドのURLパラメータです。

RESTは、開発と維持が容易ですが、メッセージセキュリティ、トランザクション、ルーティング、メッセージングを扱いません。(これは、WS_IのSOAP Webサービスの領域以上です) SilverlightのSOAP Webサービスでは、メッセージセキュリティ、トランザクション、ルーティング、メッセージングを扱いません。Silverlightでは、自動的に SOAPプロキシを生成するのと同じ方法で、RESTプロキシを自動的に生成することはできません。

HTTPメソッド

HTTPメソッド(リンク)は、大抵のREST実装で使用され、(リンク)それは、リソースの基礎を成すCreate、Read、Update、Delete (CRUD)オペレーションで動作します。

図7: HTTPメソッド

Silverlightは、GETとPOSTのHTTPメソッドのみをサポートします。一部のファイアウォールでは、PUTとDELETEのHTTPメソッドの使用を制限します。

本当のRESTサービスは、GETとPOSTのHTTPメソッドの使用のみで(上記のRESTの原則すべてに合致したものを)作ることができるという点に注目することは重要です。言い換えれば、RESTアーキテクチャはHTTPへの特定のマッピングを必要としません。GoogleのGData X-Http-Method-Override(リンク)ヘッダーは、このアプローチの例です。

Webサービスが、POSTに対してX-HTTP-Method-Overrideを解釈する場合、PUTやDELETEアクションをおこなうために、以下のHTTP method overrideを、ヘッダーにセットします。:

X-HTTP-Method-Override: PUT
X-HTTP-Method-Override: DELETE

PUTとDELETEのHTTPメソッドをサポートしないブラウザー制限を克服するための別のアプローチは、Silverlightの制御をホストするHTMLページで、Asynchronous JavaScript and XML (AJAX)を使用することです。JavaScriptイベントのXMLHttpRequestの使用により、HTMLのブリッジを通して適切なタイミングで、正しいHTTPメソッドを送信することができます。MSDNの記事、HTML ブリッジ: HTMLとマネージコードの対話(リンク)ではこれを成し遂げる方法を示しています。このテクニックは、HTMLページ、「.xap」、サービスエンドポイントすべてが同一ドメインにあるときのみ機能します。

RESTスキーマ定義、WADLとXSD

RESTの一つの制限は、スキーマが知られていなくて、変わるかもしれないということです。つまり、RESTサービスを確認するための契約が無いということです。

Web Application Development Language (WADL)(リンク) は、RESTfulなWebサービスを明確にサポートするためのWSDLに代わるものです。WADLは、まだ広く採用されていません。

XML Schema Definition(リンク) (XSD) は、RESTサービスに与えられたあらゆるリソースに対する「契約」として利用されるかもしれません。

JavaのRESTサポート

多くのツール、フレームワーク、IDEがRESTfulサービスの開発をサポートしています。NetBeans Java IDEは、以下のものが完全に統合されています。1) エンティティからのRESTサービスの自動生成。 2) 統合されたRESTサービスのテスト(NetBeansとGlasshFishでのRESTful Webサービスについて(リンク))。 Eclipse IDEもRESTサービスの開発をサポートしています(STPによるEclipseのRESTサポート(リンク))。JSR 311(リンク)、RESTful Web サービスのためのJava APIでは、現在、PUT、DELETEのHTTPメソッドをサポートしています。Jersey(リンク) は、JSR 311を追っているオープンソースの参照実装です。

Silverlight .NETのRESTサポート

Silverlightでは、以下についてRESTをサポートしています。:

WebClientクラス(たとえば、DownloadStringCompleted(GET)、UploadStringAsyncと UploadStringAsync(POST)メソッドを使用する)と、HttpWebRequestクラス（より複雑な使用で、少し進んだシナリオを可能とします)。単純で簡単なWebClientクラスが、このシナリオで使用されました。
先に述べたHTMLブリッジの使用。
JavaScriptとXMLHTTPオブジェクト、あるいはAJAXツールキットのどちらかによるAJAX。

リクエストURIを作成するためのテクニックは様々です。XMLメッセージボディ(「POX」サービス)と連携するためには、XmlSerializerか LINQ-to-Xml (System.Xml.Linq)を使用します。JSONメッセージボディと連携するためには、DataContractJsonSerializer かLINQ-to-JSON (System.Json)を使用します。LINQの技術は、高速でアドホックな利用を可能にします。RSS/Atomボディとの連携は、以降を参照してください。

図8: RESTのインターオペラビリティアーキテクチャ

このRESTシナリオは、現在のJavaのREST実装がどのようにSilverlightと連携するのか、そして、その特定のインターオペラビリティのシナリオに対する制限は何であるかを明らかにしています。NetBeans 6.1では、「EntityクラスからのRESTful Webサービス」を作成するための機能が同梱されています。NetBeansで作成した単純なRESTサービスは、データベースのテーブル(リソース)にアクセスします。そのテーブルDiscountCodesは、DiscountCodeの文字列カラムとRateの整数値カラムを持っています。

図9: DiscountCodeテーブル

RESTアクションの概要

このシナリオで使用されるHTTPメソッド(RESTアクション)の概要です。:

GET: http://localhost:8081/resouces/discountCodes
- 全てのDiscountCodeレコードを返します
GET: http://localhost:8081/resouces/discountCodes/A/
POST: http://localhost:8081/resouces/discountCodes
- DiscountCodeレコードを作成します

図10: POSTのXML

GET: http://localhost:8081/resouces/discountCodes

Silverlightアプリケーションでは、はじめに、/resources/discountCodes URIによる「GET」(DownloadStringCompleted)の呼び出しをおこないます。

図11: GETによる全てのdiscountCode

そのXMLは、レスポンスが何であるかを正確に知るために表示されます。次は、単一のリソースで、URIに /A/を指定することで得られます。/resources/discountCodes/ URIからのレスポンスを見ることによって、リソースのスキーマを推測することができます。

GET: http://localhost:8081/resouces/discountCodes/A/

図12: GETリソース /A/

POST: http://localhost:8081/resouces/discountCodes

今、新たに得られた/A/リソースをコピーすることで新しいリソースが追加され、POSTのテキストボックスに新たに/D/リソースを作成します。

図13: POSTリソース /D/

ET URIに/D/を追加し、GETボタンを押下することで、リソースが追加されたことを確認してください。

図14:GET(検証)リソース /D/

WebClientは、Get_Xml_ClickとPost_ClickイベントでJavaサービスと通信します。簡潔にするために例外処理が省略されていることに注意してください。

図15: Page.xaml.cs

「Get_Click」イベントでは、リクエストでgetUriテキストボックスの内容を送信します。そして、レスポンスのXMLはTextBox_GETテキストボックスに設定されます。

「Post_Click」イベントでは、リクエストはpostUriテキストボックスの内容を送信します。そして、レスポンスのXMLはTextBox_POSTテキストボックスに設定されます。

図16: Page.xaml

Silverlightでは、PUTとDELETEのHTTPメソッドが共に利用できないので、今回のREST実装でも更新と削除リソースがありません。しかし、更新と削除に対して、POSTを利用したREST実装が可能です(Silverlight がそれをサポートしていることを確認してください)。>何故RESTが失敗するのか(リンク)という記事では、多くのブラウザがPUTとDELETEのHTTPメソッドをサポートしていないことで、ブラウザでのRESTの採用を制限しているという問題について対処しています。

シンジケーション(RSS)サービスのシナリオ

Remote Site Syndication 2.0 (RSS) は、軽量なパブリッシュ/サブスクライブ標準で、一般的にはブログのようなコンテンツにサブスクライブするためのものです。もともとNetscapeが RSSを開発し、現在ではRSS 2.0 がデファクトスタンダードとなっています。Atom(リンク) シンジケーションフォーマットは、IETF(リンク) 標準プロセスを通じて、Atomフィードが何であるか、それがどのように解析できるのかをITEFのRFC(リンク)で述べています。大部分のシンジケートサイトは、両方のフォーマットをサポートしています。

Silverlightは、シンジケーション用にSystem.ServiceModel.Syndication.dllアセンブリがあります。(Silverlightの配信(リンク))。Syndication Feedは、Syndication Itemと共にこのフレームワークの中に含まれます。RSSやAtomと共にLanguage Integrated Query (LINQ)(リンク)を使用することで、フィードエレメントのパースがとても扱いやすいものとなります。

このシナリオは、クライアントが更新されたフィードコンテンツを見るために、クライアントが非同期にRSSサービスフィードにアクセスするための「ポーリング」のシナリオです。単純なJavaのRSSフィードが、フィードURIを通してSilverlightクライアントによってアクセスされます。

図17: シンジケーションのインターオペラビリティアーキテクチャ

結果がXMLなので、Silverlightコントロールでフィードの結果を表示するには3行のコードだけあれば十分です。

図18: シンジケーション(RSS 2.0)リーダー

OpenReadCompletedイベントが使われ、レスポンスの結果がXmlReader に入れられSyndicationFeedにロードされます。SyndicationFeedは、XAMLのitemsListコントロールにバインドします。簡潔にするために例外処理が省略されていることに注意してください。

図19: Page.xaml.cs

図20: Page.xaml

シンジケートに関する有益なSilverlightのクイックスタートとして、Silverlightでシンジケーションフィードにアクセスする(リンク) や、データバインディングとSyndicationFeedクラス(リンク)があります。

SOAP Webサービスのシナリオ

Webサービスの標準は、Simple Object Access Protocol (SOAP)(リンク)に基づいています(Web Services Interoperability Organization (WS-I )(リンク)によって定義されています)。SOAPは、メッセージをHTTP/HTTPSで扱うXMLベースのプロトコルです。W3Cには、Webサービスアーキテクチャ(リンク) のドキュメントがあり、SOAP Webサービスの基礎を成しています。JavaベースのSOAP Webサービスが既にあるなら、そのWebサービスに対するプロキシを作ることは簡単です。そして、そのWebサービスをVisual Studioで利用します。一つ注意しなければならないのは、Webサービスでの複合データ型の利用は、特にJavaと.NETのインターオペラビリティのシナリオでは問題がある可能性があるということです。JavaのSOAP Webサービスのデータ型を.NETがサポートしているデータ型(リンク)に対応付けなければなりません。

Webサービスのデバッグでも、問題がある可能性があります。Fiddler(リンク) のようなWebデバッグプロキシやWeb Development Helper(リンク)のツールが、Webサービスのデバッグには有効となるでしょう。

Silverlightでは、WS-I ベーシックプロファイルを超えたWS-*のサポートをしていません。「しかし、必要なプロトコルを手で実装することでこれらのプロトコルを使うサービスを利用することは、まだ可能です」(SOAPサービスへのアクセス(リンク))。WS-Iベーシックプロファイル1.0とHTTPのSOAP 1.1は、サポートしています。SOAP fault がクライアントに例外を投げても、発生した失敗に関する情報が明確ではないという点に注意してください。

Silverlightでは、WCF (Windows Communication Foundation)のクライアント側の技術をサポートしています。それは特定のインターオペラビリティの制限を前提としてSOAPサービスを利用することができます。利用するサービスはWCFのサービスで、Javaのサービスだけでなく、ASP.NETのWebサービス(“.asmx”)もあります。

Silverlight Webサービスのチームブログには、Silverlight 2 ベータ2 のWebサービス機能詳説(リンク)があります。SOAPを使用したJava-Silverlightインターオペラビリティの主要な関心事は、プロキシをコンパイルするのか、どのようなデータ型があって、Webサービスでのシリアライズの問題はどうか、といったことです。

設定

ServiceReference.ClientConfigの設定は、Silverlightコントロールの再コンパイルすることなく、バインディングやアドレスの変更が可能です。

図21: ServiceReference.ClientConfig

Windows Communications Foundation (WCF)

Silverlight 2 ベータ2では、「Silverlight対応WCFサービス」のテンプレートがあるので、WCFサービスでこのテンプレートを使用する場合は、サービスが Silverlightによってサポートされるプロトコルを使うように自動的に設定されます。BasicHttpBindingは、プレーンなHTTPの SOAP1.1を利用し、WS-Iベーシックプロファイル1.1に従うバインディングです。「SOAPサービスへのアクセス(リンク)」を参照してください。

ASMX

「サービス参照を追加する」で、アドレスに基づくサービス参照に対するASMXプロキシを作成します。以下のように指定します。

図22: サービス参照の追加

SOAP Faults

「Webブラウザの制限により、SOAP faultを受けとることはサポートしていません。サービスがfaultを返すとき、クライアントに例外が投げられます。しかし、faultの発生に関する情報は何も明記されません。」(SOAPサービスへのアクセス(リンク))

図23: SOAP Webサービスのインターオペラビリティアーキテクチャ

NetBeansでの単純なWebサービスのエンドポイントには、findAllとfindがあります。簡潔にするために例外処理が省略されていることに注意してください。

Figure 24: Page.xaml.cs

Visual Studioでのプロキシは、JavaのSoap2Serviceエンドポイントを参照します。

図25: Soap2Serviceのプロキシ参照

Webサービスは、リクエストパラメータのパスを呼び、Webサービスのレスポンスを受け取ります。Webサービスのレスポンス(String)は、XAMLにバインドします。XAMLは、Silverlightコントロールによってユーザインタフェースに表示します。

図26: SOAP Webサービス -Find All

図27: SOAP Webサービス -Find 'B'

プロキシオブジェクトは、バインディングとエンドポイントを持ちます。プロキシは、findAll リクエストを送信するためにfindAllAsnycイベントを使用し、findAll レスポンスを受け取るためにfindAllCompleted イベントを使用します。findAllレスポンスは、XAMLのfindAllResponseテキストボックスに表示されます。簡潔にするために例外処理が省略されていることに注意してください。

図28: Page.xaml.cs

図29: Page.xaml

プロキシの設定情報は、ServiceReferences.ClientConfigにあります。ServiceReferences.ClientConfig設定ファイルは、複数のエンドポイントの設定をサポートしています。

ServiceReferences.ClientConfig設定ファイルを変更するときに、Silverlightアプリケーションを再ビルドする必要はありません。

図30: ServiceReferences.ClientConfig

まとめ

Silverlight/Javaのインターオペラビリティの話題は、発展しつづけています。単純なSOAP Webサービス、RESTサービス、シンジケーションフィードサービスのインターオペラビリティがSilverlightで機能します。SOAP Webサービスには、WS-Iの基本的レベルのサポートだけを見ても、潜在的なデータシリアライズの問題があります。そして、それは本質的により複雑なものです。しかし、一旦、Visual StudioのSilverlightクライアントでプロキシが首尾よく作成されれば、それらはすぐに実装できます。RESTサービスを開発するときに、旧式、あるいは不正確なドキュメントに頼らなければならないかもしれません。GETとPOSTのHTTPメソッドのみを使用した既存のRESTful実装は、Silverlightでベストに機能します。RESTサービスは、クエリータイプのサービスにぴったり合い、SOAP Webサービスは、CRUDサービスによりよく合います。シンジケーションサービスは、ほとんど制限のない実装では単純です。

開発者はどんなインターオペラビリティのスタイルを選んでも結構です。そして、自身の特有の開発とデプロイシナリオに最もふさわしいものを選択してください。

理解するための基本概念は、Silverlightがブラウザのコンテキスト内で動作するということです。ドメイン間、スキーム間、ゾーン間の問題、ブラウザ接続数の制限、さまざまなMIMEタイプのサポート、これらすべてはSilverlight を開発、デプロイするだけでなく、ブラウザプラットフォームで実行するすべてのアプリケーションにおいて重要な留意点です。ブラウザで動作するとき、その最小公倍数は、しばしばブラウザ制限を定義するためのベンチマークとなります。

興味深い事柄として、JAXBスタイルのオブジェクト参照がSilverlight 2 RTMでサポートされる予定です。同じことが、.NET Framework 3.5 SP1でサポートされる予定です(DataContractSerializer)。

リソース

Silverlight

はじめに(リンク)

コミュニティサイト(リンク)

製品のメインサイト(リンク)

MSDNセンター(リンク)

オンラインフォーラム(リンク)

オンラインSDK(リンク)

ブログ

Tim Sneath氏の(リンク) ブログ

blogMike Harsh氏の(リンク) ブログ

Joe Stegman氏の(リンク) ブログ

Laurence Moroney氏の(リンク) ブログ

Tim Heur氏の(リンク) ブログ

Robert Bell氏の(リンク) ブログ

技術

ドメインの境界を越えてサービスを利用できるようにする(リンク)

Silverlight のHTTPネットワークスタック(リンク)

HTTP 1.1のヘッダーフィールド定義(リンク)

Project Zero(リンク)

RFC2616 - Hypertext Transfer Protocol -- HTTP/1.1(リンク)

XAML

XAMLの概要(リンク)

Extensible Application Markup Language (Xaml)(リンク)

新たなイテレーション～XAML革命のホワイトペーパー(リンク)

原文はこちらです：http://www.infoq.com/articles/silverlight-java-interop
（このArticleは2008年8月5日に原文が掲載されました）

Login with:

アカウントをお持ちでない方