JavaエンタープライズアーキテクチャにおけるHTML5 - Enterprise ☓ HTML5 Web Application Conference 2014

Javaエンタープライズアーキテクチャ

Japan Java User Group

日本

エンタープライズアーキテクチャにおけるHTML5におけるHTML5

日本Javaユーザーグループ

鈴木雄介

2014/2/28

宣伝• 日本Javaユーザーグループから来ました。

–http://www.java-users.jp/

• 3/21(金祝) 「祝☆Java 8 Launch


• 3/21(金祝) 「祝☆Java 8 Launch–満員御礼

• 毎月第3水曜付近にナイトセミナー

• 5/18(日）「JJUG CCC 2014 Spring–3月末までセッション公募中！

ユーザーグループから来ました。users.jp/

Java 8 Launch」Java 8 Launch」

にナイトセミナー

JJUG CCC 2014 Spring」月末までセッション公募中！

1

自己紹介• 鈴木雄介

–日本Javaユーザーグループ

–日本Springユーザー会幹事

–グロースエクスパートナーズ株式会社» ビジネスソリューション事業本部


» ビジネスソリューション事業本部

–http://arclamp.hatenablog.com/

–@yusuke_arclamp

ユーザーグループ会長

幹事

グロースエクスパートナーズ株式会社執行役員ビジネスソリューション事業本部本部長ビジネスソリューション事業本部本部長

http://arclamp.hatenablog.com/

2

講演の概要• HTML5関連技術の進化は目覚ましく、その可能性は拡がっています。しかしながら既存技術を完全に置き換えるほどは成熟していません。

• 本講演では発展期にあるイズシステムに適用するにあたって考慮すべき


本講演では発展期にあるイズシステムに適用するにあたって考慮すべき既存資産活用、セキュリティ、複数デバイス対応、生産性と品質確保などについて、クチャ設計の観点からす。

関連技術の進化は目覚ましく、その可能性は拡がっています。しかしながら既存技術を完全に置き換えるほどは成熟していません。

本講演では発展期にあるHTML5をエンタープライズシステムに適用するにあたって考慮すべき本講演では発展期にあるHTML5をエンタープライズシステムに適用するにあたって考慮すべき既存資産活用、セキュリティ、複数デバイス対応、生産性と品質確保などについて、アーキテクチャ設計の観点からお話しさせていただきま

3

アジェンダ• アーキテクトの視点

• アーキテクチャの変遷

• HTML5の可能性

• HTML5の注意点


• HTML5の注意点

• エンタープライズでの適用

• まとめ

アーキテクチャの変遷

エンタープライズでの適用

4


アーキテクトの視点アーキテクトの視点

5

アーキテクトの視点• 「ITサービスを作る」とは

影響する


Inspired by JISX0129-1 ソフトウェア製品の品質

構造/構成プロセス

依存する

アーキテクトの視点サービスを作る」とは

影響する

6

ソフトウェア製品の品質第１部品質モデル

利用価値提供機能

依存する

アーキテクトの視点

特徴

利用価値・利用状況によって評価が異なる

提供機能・システムの振る舞い・誰がテストしても同じ結果・一般的な仕様策定の対象


・一般的な仕様策定の対象

構造/構成・システムを構成している要素すべて（含ドキュメント）

・後に残り、評価が可能・エンジニアがこだわるところ

プロセス・後に残らない


例

・利用状況によって評価が異な・ユーザーＡさんとユーザーＢさんで評価が異なる

・誰がテストしても同じ結果・一般的な仕様策定の対象

・テストケース・外部仕様

7

・一般的な仕様策定の対象

・システムを構成している要素すべて（含ドキュメント）

・後に残り、評価が可能・エンジニアがこだわるところ

・クラス図・フレームワーク・ドキュメント・ソースコード

・コミュニケーション・作業手順

アーキテクトの視点• 各要素は互いに依存し、影響する

–それらのバランスが崩れると良いない

• どうやって、それらのバランスを取ればいいの


• どうやって、それらのバランスを取ればいいのか？–プロセスを改善するだけはダメ

–いまどきなフレームワーク導入するだけはダメ

アーキテクトの視点各要素は互いに依存し、影響する

それらのバランスが崩れると良いITサービスは作れ

どうやって、それらのバランスを取ればいいのどうやって、それらのバランスを取ればいいの

プロセスを改善するだけはダメ

フレームワーク導入するだけはダメ

8

アーキテクトの視点• アーキテクチャを考える


IEEE-Std-1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems

アーキテクトの視点アーキテクチャを考える

9

Recommended Practice for Architectural Description of Intensive Systems（アーキテクチャ記述の推奨プラクティス）

アーキテクトの視点ミッション

システム制約（環境）


利害関係者の関心事ビューポイント

ビュー

アーキテクトの視点ミッション

システム

10

ビューポイント

モデルによって記述

アーキテクトの視点• アーキテクチャとは

–システムのミッションに従い、システムのおかれた制約を前提としながら

–システムに関わる複数の利害関係者の関心事を整合させ、


させ、» 経営者、オーナー、ユーザー、プログラマ、

ラ屋、PM、上司、オペレーター、保守エンジニア

–ライフサイクル（設計から保守）まで意識した

–システムの分け方と組合せ方のこと


システムのミッションに従い、システムのおかれた

システムに関わる複数の利害関係者の関心事を整合

経営者、オーナー、ユーザー、プログラマ、 DBA、インフ上司、オペレーター、保守エンジニア

ライフサイクル（設計から保守）まで意識した

システムの分け方と組合せ方のこと

11

アーキテクトの視点• アーキテクチャは各要素を繋ぐもの

–アーキテクチャ設計は各要素の関係を考えること

–構造/構成は結果であり、目的ではない» あくまでも利用価値の実現が最大



依存する

影響する

アーキテクトの視点アーキテクチャは各要素を繋ぐもの

アーキテクチャ設計は各要素の関係を考えること

構成は結果であり、目的ではないあくまでも利用価値の実現が最大

12


依存する

影響する

アーキテクトの視点• HTML5への視線

–HTML5が良い悪いということを語っても意味がない

–「各要素を整合させる上で、づけで利用できるのか？」を考える


–なので、» Javaは、ほとんど関係ありません

» コードの話は出てきません

» どのフレームワークがいいとか出てきません


が良い悪いということを語っても意味がない

「各要素を整合させる上で、HTML5がどういう位置づけで利用できるのか？」を考える

は、ほとんど関係ありません

コードの話は出てきません

どのフレームワークがいいとか出てきません

13



日本



鈴木雄介

2014/2/28


アーキテクチャの変遷アーキテクチャの変遷

15

アーキテクチャの変遷• ユーザーとIT：昔

–サーバに置かれたアプリケーションをクライアントPCを通じて利用する

–ITをもの的に利用していた


App


サーバに置かれたアプリケーションをクライアント

的に利用していた

16

App

アーキテクチャの変遷• ユーザーとIT：今

–複数のデバイスを通じてネットワークの向こう側のサービスを利用する

–ITをサービス的に利用する



複数のデバイスを通じてネットワークの向こう側の

的に利用する

17

サービス

アーキテクチャの変遷• ユーザーとITの関係性について理解する

–昔：クライアントとサーバ

–今：デバイスとサービス

マルチデバイスとマルチサービス


• マルチデバイスとマルチサービス–複数のデバイスを持ち歩く

–複数のサービスを利用する» そのサービスは複数のシステムから成り立っている

アーキテクチャの変遷の関係性について理解する

昔：クライアントとサーバ

今：デバイスとサービス

マルチデバイスとマルチサービスマルチデバイスとマルチサービス複数のデバイスを持ち歩く

複数のサービスを利用するそのサービスは複数のシステムから成り立っている

18

アーキテクチャの変遷• 基本的な戦略

–統合と分散» 認証認可やインフラは統合

» 機能は分散

–疎結合


–疎結合» 疎結合な相互接続

» 標準的なI/F（HTTPとURI

–サービス化» XaaS、API


認証認可やインフラは統合

サービス

機能

機能

機能

統合基盤

URI）

19

サービス

アーキテクチャの変遷• 余談：今後の変化

–IoT（Internet of Things/» ウェラブルや組込みなどデバイスは広がる

» ITのトリガーがストリーミング型

» 判断基準の外部化


» 判断基準の外部化


Internet of Things/もののインターネット）ウェラブルや組込みなどデバイスは広がる

のトリガーがストリーミング型/イベント型

20


HTML5の可能性

21

HTML5の可能性• HTMLの歴史

–HTML（HyeperText Markup Language» ウェブ上の文書を記述するためのマークアップ言語

» ブラウザ！

–Ajax（Asynchronous JavaScript + XML


–Ajax（Asynchronous JavaScript + XML» 「発見」だった（Google Maps

» Prototype($/クラス/DOM) ト）

–HTML5» RIA(Flash)の代替としての

Markup Language）ウェブ上の文書を記述するためのマークアップ言語

Asynchronous JavaScript + XML）Asynchronous JavaScript + XML）Google Maps）

/DOM) 、jQuery(CSSセレクタ/イベン

の代替としてのSPA

22

• Ajax–サーバサイドMVCを前提にビューを一部書き換える

–パーツとしての機能

HTML5の可能性


HTMLCSS

Ajaxパーツ

•ページの場合は•Ajax

を前提にビューを一部書き換える

23

ｺﾝﾛｰﾗｰロジック

ビュー

ページの場合はJSPAjaxの場合はJSON/XMLシリアライザ

ﾓﾃﾞﾙ

• SPA（Single-page Application–サーバとは独立して動作し、クライアント内でも

MVCを持つ

–単独の“アプリケーション

HTML5の可能性


ｺﾝﾛｰﾗｰ

ビュー

ﾓﾃﾞﾙ

page Application）サーバとは独立して動作し、クライアント内でも

アプリケーション”として構築される

24

ｺﾝﾛｰﾗｰロジック

JSONｼﾘｱﾗｲｻﾞ

ﾓﾃﾞﾙ

HTML5の可能性• アプリケーションとして必要な開発環境

–フレームワーク（JS/CSS» Backborn、Angular、Sencha

» CoffeeScript、TypeScript

» Compass、less、stylus …


» Compass、less、stylus …

–構成管理ツール» grunt、bower …

–IDE» …

アプリケーションとして必要な開発環境JS/CSS）

Sencha…

TypeScript …

stylus …stylus …

25

HTML5の可能性• 基本戦略に合致する

–HTTP/API前提

–あらゆるデバイスにブラウザ

–既存技術の応用

–今後も標準化は進む


–今後も標準化は進む

–SPAには期待できる！» でも、まだまだリスクがある

あらゆるデバイスにブラウザ

サービス

機能

機能

機能

統合基盤

でも、まだまだリスクがある

26

サービス


HTML5の注意点

27

HTML5の注意点• 「ただしイケメンに限る」問題

–ブラウザ非互換» 別名：IE6問題

–スプレッドシート» 別名：Google Spreadsheet


» 別名：Google Spreadsheet▸ ECならAmazon、オークションなら

–生産性» 別名：HTMLとJavaScript

» ガチでアプリケーションを作らないといけない▸ Javaの初期と同じ。IDEによる非生産性を考慮する

「ただしイケメンに限る」問題

Spreadsheet問題Spreadsheet問題オークションならYahoo…

JavaScriptだから簡単でしょ問題

ガチでアプリケーションを作らないといけないによる非生産性を考慮する

28

HTML5の注意点• 方法論の誤解

–似ているからといって同一視しない» “インタラクティブなホームページ

» WebアプリケーションとSPA


–例» UI/UX

▸ IAだけの視点では限界がある。

» レスポンシブ/マルチデバイス対応▸ 画面サイズと配置は業務影響に直結する

似ているからといって同一視しないインタラクティブなホームページ”と”アプリケーション”

SPA

視点では限界がある。”業務”の複雑さを舐めてはいけない

マルチデバイス対応画面サイズと配置は業務影響に直結する

29

HTML5の注意点• 既存の手法とのミスマッチ

–既存のエンジニアでは知識が足りない» jQuery≠SPA

–既存のミドルウェアがHTML5» セキュリティ、認証認可


» セキュリティ、認証認可

※基本的には既存のインフラ環境には適合しているはずなので注意してみればいいレベル

既存の手法とのミスマッチ既存のエンジニアでは知識が足りない

HTML5非対応

基本的には既存のインフラ環境には適合しているはずなので注意してみればいいレベル

30

HTML5の注意点• 基本的には混乱期です

–Javaの初期もこんなんでした» 段々と収斂をしていくけど、デファクトスタンダードが美

しいわけではない▸ 別名：Struts問題


▸ 別名：Struts問題

▸ もっとも売れているラーメンが美味しいのか？

» 様々な情報が出ては消えていく

» 安直な飛び付きはダメ絶対▸ そんなに”うまい話”があるはずがない

–自分の舌で確かめてください

基本的には混乱期ですの初期もこんなんでした

段々と収斂をしていくけど、デファクトスタンダードが美

もっとも売れているラーメンが美味しいのか？

様々な情報が出ては消えていく

安直な飛び付きはダメ絶対があるはずがない

自分の舌で確かめてください

31


エンタープライズでの適用エンタープライズでの適用

32

エンタープライズでの適用• 適用の基本方針

–「技術に無理をさせない」» 「それ○ ○でもできるよ！」は危険

» 技術の成り立ちと経緯を知り、最適な領域を理解する

–HTML5


–HTML5» 最初は「文書のマークアップ言語」なので厳密性に欠けて

いるし、構造化は苦手

» Web/HTTPが前提であり、ブラウザ内で動作する

» オープンで使いやすい技術であり、複雑なことを複雑に管理させるべきではない


「技術に無理をさせない」○でもできるよ！」は危険

技術の成り立ちと経緯を知り、最適な領域を理解する

最初は「文書のマークアップ言語」なので厳密性に欠けて

が前提であり、ブラウザ内で動作する

オープンで使いやすい技術であり、複雑なことを複雑に管

33

エンタープライズでの適用• 非推奨

–複雑な業務アプリ» UI的な使い勝手には注意する

» 大量データをぐりぐり▸ ローカル検索やスプレッドシート


▸ ローカル検索やスプレッドシート

▸ JavaVMが遅いと同じ話

» そもそもコード量的な難しさ

–ネイティブ連携» ローカルファイル、デバイス間通信


的な使い勝手には注意する

ローカル検索やスプレッドシートローカル検索やスプレッドシート

そもそもコード量的な難しさ

ローカルファイル、デバイス間通信

34

エンタープライズでの適用• 推奨

–サブシステム的な扱い» メインの業務システムは既存のものを活用し、外部や小さ

めなデバイスで利用する

–例：


–例：

.Netｸﾗｲｱﾝﾄ

Javaサーバ

様々な機器


メインの業務システムは既存のものを活用し、外部や小さ

35

HTML5ｸﾗｲｱﾝﾄ

・ビュワー的・限定的な機能


まとめ

36

まとめ• HTML5:AjaxからSPAへ

–「ページの部分」から「アプリケーション」へ

–エンタープライズの基本戦略には適合している» 統合と分散

» 疎結合


» 疎結合

» サービス化

–一方で混乱期ならではの課題もある» 「ただしイケメンに限る」

» 方法論の混乱

へ「ページの部分」から「アプリケーション」へ

エンタープライズの基本戦略には適合している

一方で混乱期ならではの課題もある「ただしイケメンに限る」

37

まとめ• エンタープライズでの活用

–すぐにでも活用できる場所はある

–でも、全てを置き換えるわけでもない

–将来においても全ては置き換えない» 「銀の弾丸は存在しない」と何度言えば


» 「銀の弾丸は存在しない」と何度言えば

エンタープライズでの活用すぐにでも活用できる場所はある

でも、全てを置き換えるわけでもない

将来においても全ては置き換えない「銀の弾丸は存在しない」と何度言えば…「銀の弾丸は存在しない」と何度言えば…

38

まとめ• アーキテクトの視点から

–テクノロジー単体ではなく「良いために、どのように適用できるか」を考える



依存する

影響する

アーキテクトの視点からHTML5を捉えるテクノロジー単体ではなく「良いITサービスを作るために、どのように適用できるか」を考える

39


依存する

影響する



日本



鈴木雄介

2014/2/28

Technology

JavaエンタープライズアーキテクチャにおけるHTML5 - Enterprise ☓ HTML5 Web Application Conference 2014