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

Javaエンタープライズアーキテクチャ
エンタープライズアーキテクチャ
におけるHTML5
日本Javaユーザーグループ
日本
鈴木雄介
2014/2/28

Japan Java User Group

宣伝
• 日本Javaユーザーグループから来ました。
ユーザーグループから来ました。
– http://www.java-users.jp/
users.jp/

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

• 毎月第3水曜付近にナイトセミナー
にナイトセミナー
• 5/18(日）「JJUG CCC 2014 Spring
JJUG
Spring」
– 3月末までセッション公募中！
月末までセッション公募中！


1

自己紹介
• 鈴木雄介

– 日本Javaユーザーグループ会長
ユーザーグループ
– 日本Springユーザー会幹事
– グロースエクスパートナーズ株式会社執行役員
» ビジネスソリューション事業本部本部長

– http://arclamp.hatenablog.com/
– @yusuke_arclamp


2

講演の概要
• HTML5関連技術の進化は目覚ましく、その可能
関連技術の進化は目覚ましく、その可能
性は拡がっています。しかしながら既存技術を
完全に置き換えるほどは成熟していません。
• 本講演では発展期にある
本講演では発展期にあるHTML5をエンタープラ
イズシステムに適用するにあたって考慮すべき
既存資産活用、セキュリティ、複数デバイス対
応、生産性と品質確保などについて、アーキテ
応、生産性と品質確保などについて、
クチャ設計の観点からお話しさせていただきま
クチャ設計の観点から
す。

3

アジェンダ
•
•
•
•
•
•

アーキテクトの視点
アーキテクチャの変遷
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
Intensive Systems（アーキテクチャ記述の推奨プラクティス）

9

ミッション

制約（環境）

システム

ビュー

利害関係者の
関心事

モデルによって記述
ビューポイント
10

• アーキテクチャとは

– システムのミッションに従い、システムのおかれた
制約を前提としながら
– システムに関わる複数の利害関係者の関心事を整合
させ、

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

– ライフサイクル（設計から保守）まで意識した
– システムの分け方と組合せ方のこと


11

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

– アーキテクチャ設計は各要素の関係を考えること
– 構造/構成は結果であり、目的ではない
構成は結果であり、目的ではない
» あくまでも利用価値の実現が最大

影響する
プロセス

構造/構成

提供機能

利用価値

依存する

12

• HTML5への視線

– HTML5が良い悪いということを語っても意味がない
が良い悪いということを語っても意味がない
– 「各要素を整合させる上で、
「各要素を整合させる上で、HTML5がどういう位置
づけで利用できるのか？」を考える
– なので、

» Javaは、ほとんど関係ありません
は、ほとんど関係ありません
» コードの話は出てきません
» どのフレームワークがいいとか出てきません


13



15

• ユーザーとIT：昔

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


16

• ユーザーとIT：今

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

サービス


17

• ユーザーとITの関係性について理解する
の関係性について理解する
– 昔：クライアントとサーバ
– 今：デバイスとサービス

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

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


18

• 基本的な戦略

統合基盤

– 統合と分散

» 認証認可やインフラは統合
» 機能は分散

– 疎結合

» 疎結合な相互接続
» 標準的なI/F（HTTPとURI
URI）

機
能

機
能

機
能

サービス

– サービス化

» XaaS、API


19

• 余談：今後の変化

– IoT（Internet of Things/
Internet
Things/もののインターネット）
» ウェラブルや組込みなどデバイスは広がる
» ITのトリガーがストリーミング型
のトリガーがストリーミング型/イベント型
» 判断基準の外部化


20

HTML5の可能性


21

HTML5の可能性
• HTMLの歴史

– HTML（HyeperText Markup Language
Language）

» ウェブ上の文書を記述するためのマークアップ言語
» ブラウザ！

– Ajax（Asynchronous JavaScript + XML
Asynchronous
XML）

» 「発見」だった（Google Maps
Google Maps）
» Prototype($/クラス/DOM) 、jQuery(CSSセレクタ/イベン
/DOM)
ト）

– HTML5

» RIA(Flash)の代替としての
の代替としてのSPA


22

HTML5の可能性
• Ajax

– サーバサイドMVCを前提にビューを一部書き換える
を前提にビューを一部書き換える
– パーツとしての機能
HTML
CSS
Ajax
パーツ

ｺﾝﾛｰﾗｰ

ロジック

ﾓﾃﾞﾙ
ビュー
•ページの場合は
ページの場合はJSP
•Ajax
Ajaxの場合はJSON/XMLシリアライザ


23

HTML5の可能性
• SPA（Single-page Application
page Application）

– サーバとは独立して動作し、クライアント内でも
MVCを持つ
– 単独の“アプリケーション
アプリケーション”として構築される
ｺﾝﾛｰﾗｰ
ﾓﾃﾞﾙ

ﾓﾃﾞﾙ

ビュー


ｺﾝﾛｰﾗｰ

ロジック

JSON
ｼﾘｱﾗｲｻﾞ

24

HTML5の可能性
• アプリケーションとして必要な開発環境
– フレームワーク（JS/CSS
JS/CSS）

» Backborn、Angular、Sencha
Sencha…
» CoffeeScript、TypeScript …
TypeScript
» Compass、less、stylus …
stylus

– 構成管理ツール

» grunt、bower …

– IDE
»…


25

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

– HTTP/API前提
– あらゆるデバイスにブラウザ
– 既存技術の応用
– 今後も標準化は進む

統合基盤
機
能

機
能

機
能

サービス

– SPAには期待できる！

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


26

HTML5の注意点


27

HTML5の注意点
• 「ただしイケメンに限る」問題
– ブラウザ非互換
» 別名：IE6問題

– スプレッドシート

» 別名：Google Spreadsheet
Spreadsheet問題

▸ ECならAmazon、オークションなら
オークションならYahoo…

– 生産性

» 別名：HTMLとJavaScript
JavaScriptだから簡単でしょ問題
» ガチでアプリケーションを作らないといけない
▸ Javaの初期と同じ。IDEによる非生産性を考慮する
による非生産性を考慮する


28

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

– 似ているからといって同一視しない

» “インタラクティブなホームページ
インタラクティブなホームページ”と”アプリケーション”
» WebアプリケーションとSPA
SPA

–例

» UI/UX

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

» レスポンシブ/マルチデバイス対応
マルチデバイス対応

▸ 画面サイズと配置は業務影響に直結する


29

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

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

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

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


30

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

– Javaの初期もこんなんでした
の初期もこんなんでした

» 段々と収斂をしていくけど、デファクトスタンダードが美
しいわけではない
▸ 別名：Struts問題
▸ もっとも売れているラーメンが美味しいのか？

» 様々な情報が出ては消えていく
» 安直な飛び付きはダメ絶対

▸ そんなに”うまい話”があるはずがない
があるはずがない

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


31



32

• 適用の基本方針

– 「技術に無理をさせない」

» 「それ○ ○でもできるよ！」は危険
» 技術の成り立ちと経緯を知り、最適な領域を理解する

– HTML5

» 最初は「文書のマークアップ言語」なので厳密性に欠けて
いるし、構造化は苦手
» Web/HTTPが前提であり、ブラウザ内で動作する
が前提であり、ブラウザ内で動作する
» オープンで使いやすい技術であり、複雑なことを複雑に管
理させるべきではない


33

• 非推奨

– 複雑な業務アプリ

» UI的な使い勝手には注意する
的な使い勝手には注意する
» 大量データをぐりぐり

▸ ローカル検索やスプレッドシート
▸ JavaVMが遅いと同じ話

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

– ネイティブ連携

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


34

• 推奨

– サブシステム的な扱い

» メインの業務システムは既存のものを活用し、外部や小さ
めなデバイスで利用する

– 例：

Java
サーバ

様々な
機器


.Net
ｸﾗｲｱﾝﾄ

・ビュワー的

HTML5 ・限定的な機能
ｸﾗｲｱﾝﾄ

35

まとめ


36

まとめ
• HTML5:AjaxからSPAへ
へ

– 「ページの部分」から「アプリケーション」へ
– エンタープライズの基本戦略には適合している
» 統合と分散
» 疎結合
» サービス化

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


37

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

– すぐにでも活用できる場所はある
– でも、全てを置き換えるわけでもない
– 将来においても全ては置き換えない

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


38

まとめ
• アーキテクトの視点から
アーキテクトの視点からHTML5を捉える

– テクノロジー単体ではなく「良い
テクノロジー単体ではなく「良いITサービスを作る
ために、どのように適用できるか」を考える
影響する
プロセス

構造/構成

提供機能

利用価値

依存する


39

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

More Related Content

What's hot

Viewers also liked

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

More from Yusuke Suzuki

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