1. 1 Silverlight×Javaで業務アプリ 田中 孝佳 (@tanaka_733) 2011/07/09

2. AGENDA 背景 Javaと.NET(C#)の違い 公開の仕方 Wc3の設計思想 通信部分の実装 認証機能 ログの出力 ファイルダウンロード まとめ 2011/07/09 2

3. あらかじめおことわり Javaとの連携部分を中心に話すので、MVVM的な話はほとんどありません でも、MVVM的に作ってますよ 同様に細かいViewの作り方もないです サンプルコードが細かい字ですが、あとで公開します デモもやるつもりですが、マシンスペックの都合で動かないかも・・・ 2011/07/09 3

4. Agenda 背景 Javaと.NET(C#)の違い 公開の仕方 Wc3の設計思想 通信部分の実装 認証機能 ログの出力 ファイルダウンロード まとめ 2011/07/09 4

5. 自己紹介 ㈱ワークスアプリケーションズ所属 ERPパッケージの会社です 研究部門 クラウド担当 パブリッククラウドでERPパッケージを提供 お仕事 AWS, Java, Oracle, Silverlight お仕事ブログ http://dev.worksap.co.jp/Members/t_tanaka/ 趣味 Silverlight, WP7(without 実機) Azure Kinect(without Xbox) 趣味のブログ(URL変えました。リダイレクトされます) http://techblog.hilife-jp.info/ 2011/07/09 5 1.背景

6. お仕事の内容 2011/07/09 6 1.背景

7. 業務アプリのSilverlight実用例 社内製のクラウド管理ツールWc3のフロント 2011/07/09 7 1.背景

8. Silverlightを選択した理由 RIA技術の調査 JavaのGUI作成コストは高い！ クライアントアプリは当然高い ブラウザ系でもなかなか決定打がない・・・ Flashよりも業務アプリ向き UI部品とか、アーキテクチャとか 開発生産性の向上 GUIツールがいけてる アーキテクチャがいけてそう 2011/07/09 8 1.背景

9. サーバーサイドはJavaで 社内的な事情で。。。 Javaエンジニア多し クライアントはWindowsがほぼ全部でも、サーバー側はそうとは限らない これはこれで面白いという判断もあり サーバーとクライアントを分離できる レガシーシステムのRIA化にも役立つ（かも） 2011/07/09 9 1.背景

10. どうやって通信するんでしょう？ 2011/07/09 10 1.背景 .NETならWCF RIA Services使えるのに・・・

11. RESTful APIで通信 RESTful API URIに対してリソースを割当てる URIに対するHTTPメソッドで、XML, JSONetc… を取得 メッセージの中身を見ても比較的理解できる WCF SOAPベース(バイナリ形式だけど中身はSOAP) リクエストはXML形式で送信 レスポンスも基本XML(REST対応でJSON, RSSなども可能) メッセージの中身を見ると死ねる・・・ 2011/07/09 11 1.背景

12. JSONって？ JavaScript ObjectNotation JavaScirptベースの記述法をベースにオブジェクトを記述できる 多くのプログラム言語で解釈できる RFC4627で仕様が決まってはいるけど細かな実装が違ったりする・・・ リストとか日付とか C#はDataContractJsonSerializerでOK JavaはSDKには入っていない で、各ライブラリごとに微妙に動作が異なる リストの振る舞いが仕様通りのJacksonを使用 2011/07/09 12 1.背景

13. RESTでJSONの例 2011/07/09 13 1.背景 リクエストの例) http://example.com/rest/products/827635/detail レスポンスの例)

14. SOAPメッセージ 2011/07/09 14 1.背景 リクエストの例) レスポンスの例)

15. RESTfulとWCF(SOAP)の所感 2011/07/09 15 1.背景

16. クライアントとサーバーを疎結合にできます 明確な境界をクライアントとサーバーの間作ります 実装言語に依存しないAPIを定義できます つまり、APIさえ維持できれば任意の言語の実装に置き換えられます サーバーサイドをIISで.NETにしたり .NETやJavaでクライアントアプリを作ったり (やりたくないけど)HTML+JavaScriptにしたり 2011/07/09 16 1.背景

17. クライアントとサーバーを疎結合にできます 2011/07/09 17 1.背景

18. AGENDA 背景 JavaとC#の違い 公開の仕方 Wc3の設計思想 通信部分の実装 認証機能 ログの出力 ファイルダウンロード まとめ 2011/07/09 18

19. 年表 2011/07/09 19 2.JavaとC#の違い

20. 言語レベルの違い 2011/07/09 20 2.JavaとC#の違い

21. 言語レベルの違い 2011/07/09 21 2.JavaとC#の違い Javaはhowを詳細に記述させられるC#はhowよりwhatに専念できる

22. イベントリスナの登録 2011/07/09 22 2.JavaとC#の違い Java C# リスナを定義したインターフェースの実装クラスを登録 (上は匿名内部クラスを利用) ラムダ式、もしくは関数ポインタで、イベントハンドラに追加

23. 文字列の比較(演算子オーバーロード) 2011/07/09 23 2.JavaとC#の違い C# Java Javaでは演算子オーバーロードがないので Stringの==比較は参照の一致です。 C#を知らないJavaプログラマが見たら、「この人、初心者だ」といいかねない 書き方です。

24. 指定の型を返り値の型にしたい 2011/07/09 24 2.JavaとC#の違い C# Java JavaではGenericsの型情報は、実行時には完全には残らないので、 引数指定が必要です。 しかもクラスしか指定できません。 C#ではメソッドで指定した型を返り値の型として定義できます。 また、クラスではなく、構造体も指定できます。

25. 開発ツール(IDE)の違い C#はVisualStudio Javaはいろいろ Eclipse (Eclipse Foundation) NetBeans (NetBeans Community) JDeveloper (Oracle) IntelliJ IDEA (JetBrains) 設定とかコンパイラの実装が違って面倒な問題を起こすこともしばしば・・・ 2011/07/09 25 2.JavaとC#の違い Eclipseなどは自分でコンパイラを持っているので、 Eclipseではコンパイルが通るけど、 いざjavacでリリースビルドが通らないとかあります

26. サーバーの違い .NETはIIS Javaはいろいろ JavaEE準拠(仕様に定められた機能を持っている) WebShpere (IBM) WebLogic(Oracle) GlassFish etc… 準拠していないもの(その分軽量などのメリット有) Tomcat Jetty Springetc… どれを選ぶかが実装にも影響を与える 2011/07/09 26 2.JavaとC#の違い

27. JavaとC#の違い 2011/07/09 27 2.JavaとC#の違い

28. AGENDA 背景 Javaと.NET(C#)の違い 公開の仕方 Wc3の設計思想 通信部分の実装 認証機能 ログの出力 ファイルダウンロード まとめ 2011/07/09 28

29. サーバーサイドJavaでXAPをどう公開するか 2011/07/09 29 3.公開の仕方

30. HTMLをIISと同様に書きます 2011/07/09 30 3.公開の仕方 IISじゃないから、aspxはかけないけど。

31. AP Web HTMLとXAPを静的ファイルとして公開 2011/07/09 31 3.公開の仕方 ../index.html html文書 HTML ../Clientbin/hoge.xap XAP XAP これはServletが公開してもいいし、 Webサーバー(apache)が公開してもいい。 AzureBlobとかCDNとかで公開するのもあり。

32. xapをAPと別な場所におく場合の注意 <iframe>による読み込みが必要な場合 ホストするHTMLと別なホストにxapがある場合 ブログとかにxapを配置する場合も必要かも clientaccesspolicy.xmlの配備が必要な場合 xapのある場所と別ホストのWebサービスを呼び出す場合 Webサービス側に必要 信頼されたOOBは不要 おまけにWP7でも不要 2011/07/09 32 3.公開の仕方

33. xapをAPと別な場所におく場合の注意 2011/07/09 33 3.公開の仕方 コンテンツ配信サーバー(CDNとかBlobとか) Webサービス XAP clientaccesspolicy.xml Webサーバー HTML <ifarame> … 別ホストのWebサービスを呼び出すので clientaccesspolicy.xml 必須 別ホストのXAPを 参照するのでiframeで

34. AGENDA 背景 Javaと.NET(C#)の違い 公開の仕方 Wc3の設計思想 通信部分の実装 認証機能 ログの出力 ファイルダウンロード まとめ 2011/07/09 34

35. アーキテクチャ図 2011/07/09 35 4.Wc3の設計思想

36. こういう構成になります 2011/07/09 36 4.Wc3の設計思想 AWS (EC2) 社内 AP Web クライアント(ブラウザ) DB JSON over HTTPS xap JDBC Query Cloud Srevice endpoint

37. サーバー側のライブラリ 2011/07/09 37 JPA(Java Persistence Assistant) 標準仕様が定められたORマッパー SQLを埋め込まずにDBアクセスできる 拡張メソッド、ラムダ式がないので使い勝手は・・・ マルチDB対応できる Oracle, SQL Server, MySQL, SQLite etc… 実装はEclipseLinkを使用 JAX-RS RESTfulAPIのサービスを提供するライブラリ 実装はJerseyを使用 AWS API + Concurrent Framework AWS のAPIをJavaから非同期で叩く 4.Wc3の設計思想

38. Silverlight側のライブラリ 2011/07/09 38 Silverlight ToolKit UI部品が足りないので Blend SDK Expression Blendは使わなくても、これは必須 Prism MVVMサポート DI的な使い方 テストサポート Rx 非同期をLINQ的に簡単に扱える 4.Wc3の設計思想

39. AGENDA 背景 Javaと.NET(C#)の違い 公開の仕方 Wc3の設計思想 通信部分の実装 認証機能 ログの出力 ファイルダウンロード まとめ 2011/07/09 39

40. HttpWebRequestを使います Visual Studioの自動生成はwadlに対応してないので自分で実装 wadl: wsdlのREST API版 再送処理とかを考えるとWebClientより柔軟 2011/07/09 40 5.通信部分の実装

41. 2011/07/09 41 5.通信部分の実装 非同期APIなんて面倒だ！！

42. Rx使いましょう 非同期をLINQ的に簡単に 個人的におすすめの解説はこちら http://www.slideshare.net/neuecc/reactive-extensions-8049041 Data Developer Center入りして開発プロジェクトとしても継続されそう NuGetから取得可能 安定版もリリースされました 2011/07/09 42 5.通信部分の実装

43. HTTP処理はクライアント側で MSDNドキュメントに詳細があります http://msdn.microsoft.com/en-us/library/dd920295%28v=vs.95%29.aspx ※ただし英語版で クライアント側じゃないとできないこと 404以外のステータスコードの取得 エラー時のレスポンスボディの取得 気をつけること CooKieなどは自前で管理(ブラウザは管理しない) 2011/07/09 43 5.通信部分の実装

44. サンプルコード 2011/07/09 44 5.通信部分の実装

45. JSON⇔C#、Javaのクラスを定義 2011/07/09 45 5.通信部分の実装

46. サンプルコード 2011/07/09 46 5.通信部分の実装

47. 2011/07/09 47 5.通信部分の実装 の前に DEMO

48. DEMOの構成 2011/07/09 48 5.通信部分の実装 ポートが違う場合も必須 clientaccesspolicy.xml デバッグ起動 デバッグ起動

49. 2011/07/09 49 5.通信部分の実装 DEMO

50. AGENDA 背景 Javaと.NET(C#)の違い 公開の仕方 Wc3の設計思想 通信部分の実装 認証機能 ログの出力 ファイルダウンロード まとめ 2011/07/09 50

51. 認証方法(WCF使わない前提) 2011/07/09 51 6.認証機能

52. Cookieを使う方法の1つ ログイン成功時に、サーバー側でCookieを埋め込む ユーザー/パスワードはDBに格納 パスワードは適宜ソルト付きハッシュ化＆ストレッチングしてね クライアント側はそのCookieを使ってリクエストを送信 Cookieでログイン中か判断 Cookieに秘密情報を入れるのはよろしくない XSSとかあるとばれる RESTAPIとは相性悪い 最初に必ずログインが必要だから 2011/07/09 52 6.認証機能

53. サンプルコード 2011/07/09 53 6.認証機能

54. 2011/07/09 54 6.認証機能 DEMO

55. HTTPBasic/Digest認証を使う方法 HTTPで定義されている認証 RESTAPIとも比較的相性がよい ダイアログが出てくるやつです Basic認証は盗聴や改ざんが容易 せめて通信はHTTPSで SilverlightではHTTP通信をクライアントにする必要があります 2011/07/09 55 6.認証機能

56. サンプルコード 2011/07/09 56 6.認証機能

57. 2011/07/09 57 6.認証機能 DEMO

58. Azure Storage, AWS API認証方式 最近REST的なAPIで取り入れられている方式 あらかじめ1組の文字列(鍵)をクライアントとサーバーで共有 鍵から生成する一意な文字列をリクエストに付与 リピート攻撃を防ぐため現在時刻も入れる API単位で認証するため、RESTとは相性よし Silverlightから使う場合、鍵情報をメモリに乗せておかないといけない 2011/07/09 58 6.認証機能

59. Azure Storage, AWS API認証方式 2011/07/09 59 6.認証機能 元のリクエスト文字列 受け取ったリクエスト 現在時刻 AccessKeyにひもづくSecretKey DB SecretKey HMAC-SHA256署名 HMAC-SHA256署名 生成した署名 送信 生成した署名 AccessKey 受け取った署名 両者の一致を確認

60. サンプルコード 2011/07/09 60 6.認証機能

61. AGENDA 背景 Javaと.NET(C#)の違い 公開の仕方 Wc3の設計思想 通信部分の実装 認証機能 ログの出力 ファイルダウンロード まとめ 2011/07/09 61

62. ログをどうやってだそう・・・ 2011/07/09 62 8.ログの出力 ブラウザでは、 Console.WriteLineしても なにも起きない・・・

63. そうだ、開発者ツールがある！ 2011/07/09 63 8.ログの出力

64. JavaScript経由で出力(旧) 2011/07/09 64 8.ログの出力 なぜか、Chromeでは正しく動作しない・・・

65. JavaScript経由で出力(改) 2011/07/09 65 8.ログの出力 ホストするHTMLでscript書いておいて Silverlightから呼び出し

66. 2011/07/09 66 8.ログの出力 DEMO

67. AGENDA 背景 Javaと.NET(C#)の違い 公開の仕方 Wc3の設計思想 通信部分の実装 認証機能 ログの出力 ファイルダウンロード まとめ 2011/07/09 67

68. Azure管理コンソールでこんなことできます 2011/07/09 68 9.ファイルダウンロード

69. 疑問に思いませんでしたか？ 2011/07/09 69 9.ファイルダウンロード Silverlightではファイルは 保存ダイアログ経由でしか保存できないはず デフォルトファイル名が指定できないとか、 呼び出せるスレッドが限定されているとかいろいろ使いづらい制約が・・・

70. ブラウザからの実行 2011/07/09 70 9.ファイルダウンロード 何よりの違いは、 ブラウザからファイルを開けること (ファイルタイプの関連付けが必要) ちなみにOOB(OutOfBrowser)なら、起動処理をCOMにして呼び出すこともできます。

71. これもJavaScript経由で実現できます 2011/07/09 71 9.ファイルダウンロード 追記： 実はNavigateメソッド使えばJavaScriptは必要ありませんでした。

72. Navigateメソッドを使います 2011/07/09 72 9.ファイルダウンロード _blank を指定して、 新しいウィンドウもしくはタブが開いて ダウンロードが開始されます。

73. ダウンロードさせるにはサーバーサイドも一工夫 2011/07/09 73 9.ファイルダウンロード

74. 2011/07/09 74 9.ファイルダウンロード DEMO

75. AGENDA 背景 Javaと.NET(C#)の違い 公開の仕方 Wc3の設計思想 通信部分の実装 認証機能 ログの出力 ファイルダウンロード まとめ 2011/07/09 75

76. まとめ Silverlightは好きなサーバーサイドテクノロジと一緒に使える 明確な境界(API)を作るこが必須 適切なフレームワークも大切 開発生産性の向上、個人のスキルに依存しない 通信・認証まわりは大事 みんなが書く必要はないので適宜ライブラリ化 非同期必須なのでRxがいいんじゃない 細かい機能が意外と求められる ログ出力とかファイルダウンロードとか 2011/07/09 76 11.まとめ

77. 2011/07/09 77 ご清聴ありがとうございました