ついに始まるJava EE 7時代のアプリケーション開発

© 2015 IBM Corporation

#devsumiD

ついに始まるJava EE 7時代のアプリケーション開発

2014年 2月 19日日本アイ･ビー･エム株式会社IBMシステムズ・ソフトウェア事業部


#devsumiD

なぜ，いまJava EE 7なのか

2


#devsumiD

Java Enterprise Edition 7 (Java EE 7)

3

一昨年5月に正式版に


#devsumiD

2015年夏

4

Java EE 7 Full Profile対応

WebSphere Application Server

公開予定

詳細は後半で


#devsumiD

国内で普及率の高かったフレームワークの世代交代

Struts 1.x

–2013年 EoL（End of Life）の発表

–2014年脆弱性発見による混乱（CVE-2014-0114）

Seaser2

–主要開発者のプロジェクト離脱により新機能追加の停止–Ajax/HTML5連携やRESTful Webサービス対応の不備

5


#devsumiD

2000年代前半のWebアプリケーション

まだまだ未完成で力不足のJ2EE仕様→多くの「アンチJ2EE技術」の登場

コンテナ上にフレームワークを追加しその上にアプリケーションを構築することが主流に

– Open Sourceフレームワーク

– ベンダー製フレームワーク

– 独自フレームワーク

6


#devsumiD

2015年のWebアプリケーション事情

Java EE提供の各種仕様の機能増強・完成度の向上「標準仕様で十分」

–CDI 1.x ：依存性注入

• HibernateやSeaser2の提供していた機能をとりこみ

–JSF 2.x ：Webアプリケーション・フレームワーク

–JPA 2.x ：O/Rマッピング

• いずれもVersion 1.xから大幅な機能強化

7

→ Java EEへの回帰


#devsumiD

JSF

EL

Java EE 7の標準的なアプリケーション構成

画面デザイン–JSF / EL

外部連携–JAX-RS / WebSocket

8

JAX-RS

WebSocket

CDI .

EJB / JTA

JPA Database

依存性注入・ビジネスロジック

–CDI / EJB / JTA

DB連携・ORマッピング

–JPA


#devsumiD

Java EE 7の三つのゴール

HTML5環境への対応

開発生産性の向上

エンタープライズ・ニーズへの対応

9


#devsumiD

三つのゴールとJava EE仕様群との対応

HTML5環境への対応

– JSR 344: JavaServer Faces (JSF) 2.2

– JSR 353: Java API for JSON Processing (JSONP) 1.0

– JSR 356: Java API for WebSocket 1.0

– JSR 339: Java API for RESTful Web Services (JAX-RS) 2.0

開発生産性の向上

– JSR 345: Enterprise JavaBeans (EJB) 3.2

– JSR 346: Contexts and Dependency Injectionfor Java EE (CDI) 1.1

– JSR 907: Java Transaction API (JTA) 1.2

– JSR 349: Bean Validation 1.1

エンタープライズ・ニーズへの対応

– JSR 343: Java Message Service (JMS) 2.0

– JSR 338: Java Persistence API (JPA) 2.1

– JSR 236: Concurrency Utilities for Java EE 1.0

– JSR 352: Batch Applications for the Java Platform 1.0

10


#devsumiD

WebSocketとは

11


#devsumiD

2014年10月ついに正式勧告となったHTML5

従来のHTML–画面をレンダリングするための規格

HTML5（＋ CSS3 / JavaScript）–アプリケーションを記述するための規格

12


#devsumiD

HTML5環境の新しいアプリケーションスタイル

「サーバーサイドMVC」から「クライアントMVC」へ

13

Web Browser

Application Server

Application

HTTPRequest

HTML/JS

Controller SessionData

ViewBusiness

LogicModel

DomainDomain

Web Browser

Application Server

Application

View

HTML/JS

Controller

DataStore

Model

Model

DomainDomain

RESTful orWebSocket JSON

Business Logic

従来のWebアプリケーション Single Page Application (SPA)


#devsumiD

HTML5におけるクライアント・サーバー連携

通信方法–RESTful （JAX-RS 2.0）

•HTTPの原則にしたがった簡潔なシステム間連携の設計手法

–WebSocket （WebSocket 1.0）•ブラウザとWebサーバーの間で

双方向通信を可能にする通信プロトコル

データ型–JSON：JavaScript Object Notation（JSONP 1.0）• JavaScriptのオブジェクトとして

そのままパースできるテキスト形式のデータ表記法

14

Web Browser

Application Server

Application

View

HTML/JS

Controller

DataStore

Model

Model

DomainDomain

RESTful orWeb Socket

JSON

Business Logic


#devsumiD

新しい双方向通信：WebSocket

WebSocketを使用すると双方向通信を自然な形で実現–HTTPで通信を開始して，Protocol SwitchingによりWebSocketに移行

–サーバー側からもクライアント側からもメッセージを送信可能

15


#devsumiD

既存技術との比較

Ajax–定期的にポーリング–最大でポーリング間隔のタイムラグが発生する

–あまりポーリング間隔を短くするとサーバーに負荷が

16

Comet–イベントが発生するまで応答を遅延させる

–クライアントからのイベント通知には不向き

HTML

JS

クライアントサーバー

CSS

Data#2

Data#1画面遷移

Dataなし

Data#3

HTML

JS

クライアントサーバー

CSSData#1画面遷移

イベント発生

待機

イベント発生

待機

Data#2

Data#3


#devsumiD

WebSocket プロトコルの現状

プロトコルはIETF / RFCで標準化– 2010年2月 draft-hixie-thewebsocketprotocol-75

– 2010年5月 draft-ietf-hybi-thewebsocketprotocol-00



– 2011年12月 RFC 6455 "The WebSocket Protocol"

W3CでJavaScript APIを仕様化– 2009年4月 First Public Draft

– 2009年10月〜2012年8月 Working Draft

– 2012年9月 W3C Candidate Recommendation

17


#devsumiD

ブラウザの対応状況

18

モダンなブラウザの大部分がサポート

MSIE10 (2013/2) 〜

Chrome16 (2011/12) 〜

Firefox11 (2012/3) 〜

Safari6 (2012/7) 〜

iOS6.0 (2012/9) 〜

Android4.4 (2013/10) 〜


#devsumiD

対応ブラウザのシェア

19

７0%以上のブラウザがWebSocketに対応

出典：NetMarketShare.com Market Share Reports October, 2014


#devsumiD

Java EE 7でのWebSocketアプリ開発

20


#devsumiD

JSR 356: Java API for WebSocket 1.0

JavaでWebSocket通信を実装するためのAPI

クライアントとサーバーの両方をサポート

Java SE環境での実行も考慮された仕様

アノテーションをベースとしたモダンなプログラミングスタイル

Encoder / Decoderにより扱うデータ型を柔軟に制御

21


#devsumiD

Endpoint：ServerEndpointとClientEndpoint

WebSocket通信の両端となるEndpointの作成が必須–WebSocket通信の開始・終了・エラー発生とメッセージ受信をトリガーにEndpointのメソッドが呼び出される

クライアントはブラウザで実装することが多いので，多くの場合Java EEではサーバー側のEndpointを実装する

22

ClientEndpoint ServerEndpoint

Session @OnMessage

public void message(... )

@OnOpen

public void open(... )

@OnClose

public void close(... )

@OnMessage

public void message(... )

@OnError

public void error(... )


#devsumiD

Endpointの作成

二つの実装方法–アノテーションをつけたPOJO

•@javax.websocket.server.ServerEndpoint•@javax.websocket.ClientEndpoint

–javax.websocket.Endpointを継承したクラス

アノテーションベースのPOJOで実装するほうが簡単

23


#devsumiD

アノテーションによるEndpoint実装の例

24

@ServerEndpoint("/echo")public class EchoServiceEndpoint{

Session currentSession = null;

//接続がオープンしたとき@OnOpenpublic void onOpen(Session session, EndpointConfig ec) {

currentSession = session;}

//メッセージを受信したとき@OnMessagepublic void receiveMessage(String msg) throws IOException {

//メッセージをクライアントに送信するcurrentSession.getBasicRemote().sendText("Hello" + msg);

}

//接続がクローズしたとき@OnClosepublic void onClose(Session session, CloseReason reason) { ・・・ }

//接続エラーが発生したとき@OnErrorpublic void onError(Throwable t) {・・・ }

}


#devsumiD

JVMJVM

Endpointのインスタンス

EndpointのインスタンスはWebSocketのセッションごとに別個に作成される

–Servletのインスタンスが，サーバーに一つ作成されて複数のリクエスト・セッションで共有されるのと対照的

25

Endpointインスタンス

Servletインスタンス


#devsumiD

Endpointのコーディング（１）

セッションの情報をインスタンス変数に保存できる–多くの場合，javax.websocket.Sessionの保存は必須

「時間のかかる初期化処理」はEndpoint毎には書かない–@Singletonの@EJBなどに実装しておいて呼び出す

26

@ServerEndpoint(value = "/echo")public class EchoServiceEndpoing {

private Session currentSession;@OnOpenpublic void onOpen(Session session, EndpointConfig ec) {

currentSession = session;


#devsumiD

Endpointのコーディング（２）

マルチスレッドを考える必要はない

–それぞれのインスタンスの@OnOpenメソッドなどが複数スレッドから同時に呼ばれることはない

–ただし複数のEndpoint / Sessionにまたがる処理では，状況に応じて排他制御が必要

27


#devsumiD

ピアへのメッセージの送信

SessionからRemoteEndpointを取得して使用する

RemoteEndpointは，2種類–RemoteEndpoint.Async 非同期通信–RemoteEndpoint.Basic 同期通信

Sessionは他のスレッドで稼働しているServlet / EJBからも利用可能

–複数スレッドから一つのSessionを同時に利用することは避ける

28

if (session.isOpen())session.getBasicRemote().sendText(msg);


#devsumiD

HTTPヘッダ・HttpSessionへのアクセス

ConfiguratorのmodifyHandshakeメソッドを利用する–HandshakeRequestからHTTPヘッダやHttpSessionが取得できる

@ServerEndpoint / @ClientEndpoint に追記

29

import javax.websocket.server.ServerEndpointConfig.Configurator;

public class ChatConfig extends Configurator {@Overridepublic void modifyHandshake(ServerEndpointConfig sec,

HandshakeRequest req,HandshakeResponse resp) {

@ServerEndpoint(value = "/chat", configurator = ChatConfig.class)public class ChatService {


#devsumiD

ConfiguratorからEndpointへの情報伝達

EndpointConfigのUserPropertiesを利用する

30

public void modifyHandshake(ServerEndpointConfig config,HandshakeRequest request, HandshakeResponse response) {

HttpSession session = (HttpSession)request.getHttpSession();Map<String,Object> userProps = config.getUserProperties();userProps.put("MyID",

(session != null)? session.getAttribute("MyID") : "No ID");

@OnOpenpublic void onOpen(Session session, EndpointConfig config) {

Map<String,Object> userProps = config.getUserProperties();String myID = (String)userProps.get("MyID");

Configurator

Endpoint


#devsumiD

ConfiguratorやEndpointでHttpSessionを書き換えない

HandshakeRequestからHttpSessionは取得できるが，

Attributeのセット・更新・削除は危険–分散環境では，HttpSessionの内容は複数サーバー間で共有される

–多くのアプリケーションサーバーでは，サーバー間の

HttpSession情報の更新はリクエスト処理が完了した時に実行

–WebSocketでは，セッションが短時間で終了しない

→ 変更内容が他のサーバーになかなか伝搬しない

Configuratorでは，

HttpSessionから読み取りのみをおこなうのが安全

31


#devsumiD

さらに詳細に知りたい場合は

IBM developerWorksでWebSocketを検索

32

Java EE 7 アプリケーション設計ガイド – WebSocket編http://www.ibm.com/developerworks/jp/websphere/library/was/javaee7_appguide/1.html


#devsumiD

CDI 1.2

33


#devsumiD

開発生産性の向上：CDI

依存性注入（DI）の標準仕様：Context and Dependency Injection（CDI）

34

@ApplicationScopedpublic class HelloServiceImpl implements HelloService {

public void sayHello() {System.out.println("Hello!");

} }

public class HelloWorld extends HttpServlet { @Inject HelloService service;


#devsumiD

CDIの使用例（１）

外部接続のパラメーターのハードコーディングの防止

–ネーミングサービス利用からアノテーション指定へ

コンポーネント間の依存性の除去

–モックやスタブを利用したテストが容易に

35

@InjectService s;

実際のサービス実装

テスト用のスタブ

業務DB

ダミーデータ

本番環境でインジェクション

テスト環境でインジェクション


#devsumiD

CDIの使用例（２）

コンテナによるライフサイクルの管理

– リクエスト内の各種コンポーネント間の情報共有・キャッシュ

– セッション情報・アプリケーション構成情報などの保持

インターセプターによるアスペクトの注入

– ロギング・監査処理などの動的な追加

36

ServletEJB lite

JSP

Ojb Ojb Ojb

@RequestScoped のオブジェクト

Local呼び出し

呼び出し

注入注入注入リクエストごとに固有のオブジェクトが生成されて注入される

同一同一


#devsumiD

CDIの歴史

Context and Dependency Injection 1.0 (Java EE 6)–最初の仕様

Context and Dependency Injection 1.1 (Java EE 7)–Bean-Discovery-Modeの追加

Context and Dependency Injection 1.2–1.1のメンテナンス・リリース

Context and Dependency Injection 2.0–2016年を目標に策定中の次期リリース

37


#devsumiD

WebSphereの使用している実装

CDI 1.0 （WAS V8.x）–Apache Open WebBeans

CDI 1.2 （WAS V9.x）–JBoss Weld（参照実装）

38


#devsumiD

CDIでインジェクション可能な場所

コンテナ管理Beanに対してインジェクション可能–サーブレットクラス–サーブレット・フィルター–サーブレット・ライフサイクル・リスナー

–EJB Session Bean–JAX-RS/WebSocketエンドポイント

–CDIでインジェクションされるクラス

39

Servlet

注入注入


#devsumiD

CDIでインジェクション可能なBean

CDI 1.0

–beans.xmlが含まれるアーカイブの全てのクラス

CDI 1.1/1.2

–beans.xmlで指定されたBean-Discovery-Modeによって変化• all

• annotated

• none

–beans.xmlが存在していないアーカイブ

•カオス・・・

40

CDIを使用する場合は，beans.xmlを使用してBean-Discovery-Modeを指定しましょう

<?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee

http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"bean-discovery-mode="annotated">

</beans>


#devsumiD

Bean-Discovery-Mode

アーカイブに含まれるbeans.xmlによって指定される

all

–（@Ventedアノテーションが指定されたもの以外）

アーカイブ内の全てのクラスがインジェクションの対象となる

annotated （デフォルト，かつ強く推奨）

–Bean定義アノテーションが指定されたもの

（スコープアノテーションが指定されたもの）が

インジェクション対象となる

none

–アーカイブ内のクラスはインジェクションの対象とならない

41


#devsumiD

Bean-Discovery-Modeによる恩恵

CDI 1.0では，

アーカイブに大量のクラス（数万〜）が入っていると・・・

–全てのクラスがCDIコンテナの管理下に

–起動時間の遅延

–Javaヒープの大量使用

CDI 1.1以降では，

–Bean定義されたクラスが多くなければ問題なく使用可能

42


#devsumiD

Bean定義アノテーション

インジェクションされるBeanのスコープを定義する

–@RequestScoped

リクエストごとに異なるインスタンス

–@ConversationScoped

（JSFなどの）会話処理ごとに異なるインスタンス

–@SessionScoped

セッションごとに異なるインスタンス

–@ApplicationScoped

アプリケーション全体で単一のインスタンス

–@Dependent

インジェクション先と同一のスコープ

デフォルトのannotatedモードでは，

スコープアノテーションを使用するとインジェクション対象となる

@Singletonはインジェクション対象とならなくなりました

43


#devsumiD

インジェクション対象となるクラスの実装方法

デフォルトコンストラクタが必要です

@SessionScoped指定されたクラスは

java.io.Serializableを実装している必要があります

DI候補が複数ある状況では型解決を実装する必要があります

–静的な型解決 @Qualifier

–動的な型解決 @Produce

44

@Qualifier @Retention(RUNTIME)

@Target({FIELD, TYPE, METHOD, PARAMETER})

public @interface DB2 {}

@Qualifier @Retention(RUNTIME)

@Target({FIELD, TYPE, METHOD, PARAMETER})

public @interface Oracle {}


#devsumiD

Libertyプロファイル

45


#devsumiD

46

Libertyプロファイルの特長

WAS V8.5.5 Liberty & WDT

自動化ツールとの連携多くのOSSツールに無償でプラグインを提供

Unzipによる導入とデプロイパッケージをしたサーバー + アプリ + 構成情報をUnzipでデプロイ可能

簡単な構成と動的変更最低限必要な構成ファイルはserver.xmlひとつだけデフォルトベースで簡単構成構成変更は再起動なしに反映

軽量ランタイムメモリー使用量が小さい: 60MB程度～ディスク使用量も100MB以下

起動が速い起動時間: 5秒程度

統合ツール（WDT)高機能なEclipse用の連携ツールを無償で提供Eclipseから簡単に使用可能

Web Profile準拠Java EE 6のWeb Profile標準に準拠したアプリを完全サポートJAX-WS, JAX-RS, JMSもサポート


#devsumiD

47

必要な機能（Feature）だけを組み合わせて利用

Java EEなどの標準仕様に定義されたAPIやサーバーが提供する多くの機能のうち

Servlet JSP JSF SSL

JAX-RS JSON JPA

JAX-WS JAX-B JDBC JTA

JMS CDI JNDI

EJB lite EJB MDB Blueprint WAB

ユーザーが必要な機能だけを自由に組み合わせることができる

Servlet JSP JSF SSL

JAX-RS JSON JPA

JAX-WS JAX-B JDBC JTA

JMS CDI JNDI

EJB lite EJB MDB Blueprint WAB


#devsumiD

API・サーバー機能をFeatureとして定義

48

• 必要なものだけを構成– 設定されたものだけがメモリにロード・初期化される

→ 最小限の起動時間・メモリー使用

ServletJSPJDBCSSL

JAX-RS

sessionDatabase

<featureManager><feature>jsp-2.2</feature><feature>jdbc-4.0</feature><feature>jaxrs-1.1</feature><feature>sessionDatabase-1.0</feature><feature>ssl-1.0</feature>

</featureManager>

構成ファイル server.xml 依存関係も自動的に解決

JSON


#devsumiD

新しいFeatureを，順次Liberty Repositoryで提供

Liberty Repositoryで新しいFeatureを入手可能

–Java EE 7を構成する

仕様も順次公開中

–GUI管理画面や

ｚ/OS Connectなど

featureManagerコマンドで

ランタイム環境に直接

ダウンロード・組み込みが

可能

49

https://developer.ibm.com/wasdev/downloads/


#devsumiD

ゼロ・マイグレーション

新しい仕様のバージョンに対応するフィーチャーが

追加されても，従来のバージョンも提供されます

–例）現在はServlet 3.1フィーチャーが提供されていますが，

Servlet 3.0フィーチャーも引き続き利用できます

アプリケーションで新仕様が必要なければ

従来のフィーチャーをそのまま利用可能–ただし，

対応するJDKのバージョンは変更される可能性があります

50

servlet-3.0 servlet-3.1


#devsumiD

WebSphere Application Server Liberty Beta

• 2013年11月： Alpha• 2014年2月: Alpha (February update)• 2014年3月: Beta (March 2014)

• WebSocket 1.1, EJB lite 3.2, Java EE Concurrency Utilities 1.0，JCA 1.6• 2014年4月: April Beta

• Servlet 3.1, EJB 3.2 (local)• 2014年5月: May Beta

• JMS 2.0, JPA 2.1, JSON-P 1.0, Bean Validation 1.1• 2014年6月： June/July Beta

• WebRTC，CouchDB• 2014年7月： July/August Beta• 2014年8月： August/September Beta

• JAX-RS 2.0• 2014年9月： September Beta

• Java Batch 1.0• 2014年10月： October Beta• 2014年11月： November Beta

• SIP Servlet 1.1，JDBC 4.1，• 2014年12月： December Beta• 2015年1月： January Beta• 2015年2月： February Beta

• CDI 1.2，JSP 2.3，EL 3.0，Java EE Application Client，JASPIC 1.1，JACC 1.5，JCA 1.7，JavaMail

51


#devsumiD

52

2015年2月末現在のβの提供状況

•Enterprise JavaBeans (EJB) 3.2

•Java Message Service (JMS) API 2.0

•Java EE Connector Architecture (JCA) 1.7

•Concurrency Utilities for Java EE 1.0

•JavaMail 1.4

•Java Batch 1.0

•Web Services for Java EE 1.3

•Java API for XML-Based Web Services (JAX-WS) 2.2

•Java Architecture for XML Binding (JAXB) 2.2

•Web Services Metadata for the Java Platform 2.1

•Java Authorization Service Provider

Contract for Containers (JACC) 1.4

•Java Authentication Service Provider

Interface for Containers (JASPIC) 1.0

•Java EE Management 1.1

Web Profile

•Java Servlet 3.1

•JavaServer Pages (JSP) 2.3

and Expression Language (EL) 3.0

•Standard Tag Library for JavaServer Pages (JSTL) 1.2

•JavaServer Faces (JSF) 2.2

•Debugging Support for Other Languages 1.0

•Java API for RESTful Web Services (JAX-RS) 2.0

•Java API for WebSocket (WebSocket) 1.0

•Java API for JSON Processing (JSON-P) 1.0

•Common Annotations for the Java Platform 1.2

•Contexts and Dependency Injection

for the Java EE Platform 1.2

•Dependency Injection for Java 1.0

•Enterprise JavaBeans 3.2 (EJB Lite)

•Java Persistence API 2.1

•Java Transaction API (JTA) 1.2

•Bean Validation 1.1

Java EE full Profile

正式版として利用可能 Betaを提供中


#devsumiD

でも，お高いんでしょう？

"WebSphere Application Server for everyone"https://developer.ibm.com/wasdev/docs/websphere-application-server-everyone/

3月出荷予定のWAS V8.5.5.5より

Libertyプロファイルの本番使用が無料に！！！–Javaヒープの総量が2Gに制限

•「2G×1 JVM」「1G×2 JVMs」や「512M×4 JVMs」など

–クラウドでもオンプレミスでも使用可能

–Liberty Repositoryで提供されている

Java EE＋αの機能の全てが利用可能

–サポートは公開Forumなどを使用

53


#devsumiD

もちろん製品の購入もできます

WebSphere Application Server Liberty Core– Java EE Web Profileの機能を使用可能

WebSphere Application Server– Java EE Full Profileの機能を使用可能（予定）

– 従来から提供されているランタイムも併せて使用可能

WebSphere Application Server Network Deployment– Java EE Full Profileの機能を使用可能（予定）

– 従来から提供されているランタイムも併せて使用可能

– クラスター環境の統合管理が可能

• 従来から提供されているNDセルによる統合管理

• Liberty Collectiveによる統合管理

54


#devsumiD

製品購入のメリット

Javaヒープやインスタンス数を無制限に使用可能

日本語スタッフによる電話で障害サポートを提供（回数無制限）

関連ソフトもサポート付きで提供–IBM Java SDK（Linux/Windows/AIX/IBM i/zOS）–IBM HTTP Server–セッション共有用のDBMS

55


#devsumiD

まとめ

いよいよ2015年から，Java EE 7を業務で使用できるようになります

Java EE 7では，モダンな業務フレームワークに必要な多くの機能が提供されています

–JPA / JSF / CDI / JAX-RS / WebSocket / etc.

IBMのJava EE実行環境であるWebSphere Application Serverは新しいランタイムとしてLibertyプロファイルを提供

–Java EE 7アプリケーションを実行する最適な環境です

56

Software

ついに始まるJava EE 7時代のアプリケーション開発