1 Copyright© 2013, Oracle Corporation Japan, all rights reserved.otndnld.oracle.co.jp/ondemand/javaday/C-2.pdf · 2013-05-17 · 動的言語日本のエンタープライズ開発の危機

1 Copyright© 2013, Oracle Corporation Japan, all rights reserved.

エスケイプ・フロム・レガシーJ2EE

大橋　勝之日本オラクル株式会社コンサルティングサービス


以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。


大橋　勝之

[email protected]

日本オラクル株式会社コンサルティングサービス統括

自己紹介

  1998年からサン･マイクロシステムズ Sun Java CenterでJavaコンサルティングを担当

  2010年6月に日本オラクルコンサルティングサービスへ移り活動を継続

  2001年、2002年、2012年 JavaOne Japan スピーカ


アジェンダ

 イントロダクション

  DRY化促進で運用維持コストを削減

  JSFでコンポーネントベースな開発

 CDIでコンポーネント間を疎結合化

 まとめ


イントロダクション


J2EEはJava EEへ進化し、開発の容易化を実現

JPE プロジェクト

J2EE 1.2

J2EE 1.3

J2EE 1.4

Java EE 5

Java EE 6

Java EE 7

Java EE 8

Servlet, JSP, EJB, JMS RMI/IIOP

CMP, コネクタアーキテクチャ

Webサービス管理/開発、非同期コネクタ

容易な開発, アノテーション, EJB 3.0, JPA, Webサービスのアップデート

プルーニング, 拡張性, 容易な開発, CDI, EJB 3.1, Servlet 3.0,

MAY 1998 DEC 1999 SEP 2001 NOV 2003 MAY 2006 DEC 2009 Spring 2013 Spring 2015

クラウド

堅牢性

Webサービス

容易な開発

柔軟性

エンタープライズ Javaプラットフォーム

バッチ処理、 JAX-RS 2.0, JSON, HTML5対応, WebSocket

更なる開発生産性向上

PaaS対応、マルチテナント

新しい技術や考え方を標準仕様として取込み

AOP

CoC DI


J2EEはJava EEへ進化したが、日本のエンタープライズ開発の現場はあまり変わっていない

 依然としてJ2EEが主流

 独自の開発スタイル/アーキテクチャ

 変化を嫌い固定的/塩漬け

 人海戦術、残業/休日出勤

 再発明(Reinvention)、独自実装へのこだわり

 オーバーエンジニアリング


日本のエンタープライズ開発は一部の優秀な技術者によって支えられている

マネージャ

優秀な技術者

技術者

協力会社

時代遅れな技術/考え方による旧態依然なガバナンス

新しい技術/考え方への興味やエンジニア個人としての価値向上


時代遅れなガバナンスを嫌い、エンタープライズ開発の現場から優秀なエンジニアの流出が増加

マネージャ

技術者

エンタープライズJavaはおもしろくない…

 コンシューマ系

 ゲーム

 SaaS

 動的言語

日本のエンタープライズ開発の危機

リーダ不足

なかなか進まない技術者育成

J2EE時代の知識/経験ベースの思考の継続

ドロップアウト予備軍化


Java EEで日本のエンタープライズ開発の状況を変えよう

① システム開発のガバナンス強化 ② 技術者の仕事満足度向上による

　　社内定着と作業品質向上

–  最新標準技術のスキル習得による技術者個人としての価値向上

–  開発容易化による残業/休日出勤の

削減

③ 社内技術者のスキル向上

　　の容易化

–  必要なスキル範囲の適正化

–  外部リソース上の教材や技術情報/ノウハウの利用

④ 外部からの技術者調達

　　の容易化 –  Java EE標準技術

ベースのスキル要件

–  新規ベンダ参入の容易化

–  開発/運用維持コストの更なる削減

–  開発上の技術リスク低減

–  標準技術に準拠したアーキテクチャ均質化

①

②

③ ④


エンタープライズ開発でJava EEのメリットを活用するための3つのポイント

 DRYの促進で運用維持コストを削減

 JSFでコンポーネントベースな開発

 CDIでコンポーネント間を疎結合化


ポイント１： DRYの促進で運用維持コストを削減


既存のJ2EEアプリケーションはJava EE環境でも動作可能

H/W

OS

Java VM (Java SE)

業務フレームワーク

ＡＰサーバ（Java EE）

サードパーティ製 J2EEフレームワーク

業務アプリケーション J2EEベースの

既存アプリ

•  アプリケーション資産の保護はJavaのメリットのひとつ

•  新しいプラットフォーム上で実行することで性能向上も期待できる


最新のJava EEではWebフレームワーク機能が標準提供される

JPE プロジェクト

J2EE 1.2

J2EE 1.3

J2EE 1.4

Java EE 5

Java EE 6

Java EE 7

Java EE 8

Servlet, JSP, EJB, JMS RMI/IIOP

CMP, コネクタアーキテクチャ

Webサービス管理/開発、非同期コネクタ

容易な開発, アノテーション, EJB 3.0, JPA, Webサービスのアップデート

プルーニング, 拡張性, 容易な開発, CDI, EJB 3.1, Servlet 3.0,

MAY 1998 DEC 1999 SEP 2001 NOV 2003 MAY 2006 DEC 2009 Spring 2013 Spring 2015

クラウド

堅牢性

Webサービス

容易な開発

柔軟性

エンタープライズ Javaプラットフォーム

バッチ処理、 JAX-RS 2.0, JSON, HTML5対応, WebSocket

更なる開発生産性向上

PaaS対応、マルチテナント

Webフレームワーク


いつまでJ2EEベースのシステム開発を続けるのか？

H/W

OS

Java VM (Java SE)



サードパーティ製 J2EEフレームワーク

業務アプリケーションプラットフォーム更改時の対応コスト増に

つながる要因が多い

•  J2EEフレームワークを含めた検証が必要で、Java EE標準機能との機能重複も多い

•  業務フレームワークは非標準APIベース

•  業務アプリケーションはコード量が多く、テストしにくい構造

機能の重複

非標準API ベースの

業務FW

昔ながらの非効率な作り

定期的なプラットフォーム更改と、そのタイミングでのバージョンアップ


これから開発するシステムはDRY化とJava EE化で運用維持コストの削減が可能

H/W

OS

Java VM (Java SE)



業務アプリケーションメンテナンスが必要なソフトウェア資産を圧縮してコスト削減

Java EEのEoDでコード量を削減

Java EE標準API をベースに実装

Java EE標準機能との重複を排除

※ DRY: Don’t Repeat Yourself


Webアプリケーションのリクエスト処理フロー制御をJava EE標準機能だけで構成

<<Facelet>>

Webページ

<<JPA>>

標準O/R

マッパ－

Database�

<<Facelet>>

テンプレート

<<CSS>>

画面デザイン

標準UI部品

標準バリデータ

コンテナ認証/認可

標準コンバータ

標準ｱﾉﾃｰｼｮﾝ

標準ｱﾉﾃｰｼｮﾝ標準ｱﾉﾃｰｼｮﾝ

JSF <<POJO>>

Backing Bean

<<POJO>>

ビジネスオブジェクト

<<EJB>>

業務処理

共通業務部品（FW）アドオン利用可能な形で共通業務部品を整備


エンタープライズ開発の戦略見直しが重要

 開発基盤として提供すべき機能は何か？

 Java EE標準技術をどう使うか？

–  現時点で利用可能な技術

–  将来的に利用可能になる技術と移行パス

 足りない機能をどう補完するか？

–  Java EE標準に準拠する形で実現可能か？

–  非標準技術の利用が不可避な場合、どう組み入れるか？

 今後の周辺環境の変化にどう対応していくか？

–  開発基盤をどうメンテナンス（機能改修/追加/縮退）していくか？

–  インフラ更改やJava EEのバージョンアップへの対応をどう簡易化するか？


ポイント２：JSFでコンポーネントベースな開発


日本では依然としてアクションベースのレガシーWebフレームワークが主流

 

 Strutsに類似した構成のカスタムフレームワーク

アクション

HTTP リクエスト解析

HTTP レスポンス生成

Strutsから離れられないことがJava EEへの移行の阻害要因のひとつになっている

あるいは


「今のままではいけない」と感じている人は多い

 XML記述が煩雑

 JSPにJavaコードが混入

 テストしにくい

 再利用しにくい

 テンプレート機能が無い

 タグライブラリが使いにくい

 Java EEの新しい機能が使えない

 ガバナンスのための制約事項が多すぎる

 プラットフォームのバージョンアップ対応がたいへん


でも、まだ踏み切れない...

 慣れているから変えたくない

 新しいものを勉強するのは嫌

 開発者が少ない

 コードジェネレータ等のツールが揃っている

 Java EEの事例が少ない

及び腰なSＩが多いのに対し、エンドユーザ側は Java EE利用に積極的な姿勢を見せ始めている

 開発時だけでなく運用維持のコストが問題

 開発のグローバル化への対応


Struts 1は2013年4月にEOLを正式アナウンス

http://struts.apache.org/struts1eol-announcement.html


今こそJSFへの移行の時

山田　太郎

東京都港区・・

名前：

住所：

private String name; private String address;

<< Context Object (Input) >> Employee

<< Backing Bean (Controller) >> EmployeeBean

public String register(Employee o) { result = service.register(o); return "success";

 コンポーネントベースのフレームワークで開発生産性を大幅に向上

–  画面にUI部品を配置し、Javaクラスのフィールド/メソッドをマッピング

–  煩わしいHTTPリクエスト処理の実装が不要で開発/テストが容易

–  コンポーネントの再利用が容易

"#{employee.name}"

"#{employee.address}"

"#{employeeBean .register(employee)}"


JSFはWebフレームワークとして必要な機能を標準提供

～JSF 2.1 （Java EE6）

–  マネージド・ビーン (w/CDI)

–  ナビゲーション

–  JSFタグ

–  Faceletsとテンプレート

–  JSFイベント

–  コンバータとバリデータ (w/Bean Validation)

–  コンポジット・コンポーネント

–  AJAXサポート

–  カスタム・コンポーネント

JSF 2.2 （Java EE7）

–  Faces flow

–  HTML5タグ対応

–  CSRF保護

–  ファイルアップロード

–  ステートレス・ビュー


大規模なスケーラビリティが必要な場合にはJAX-RSでアクションベースに処理を実装

<<JPA>>

標準O/R

マッパ－

Database�

標準バリデータ

コンテナ認証/認可



スマートフォン/ タブレット等

REST

バックエンドは

JSFと共用可能


シングルページアプリケーション

<<POJO>>

ビジネス

オブジェクト

<<EJB>>

業務処理

<<POJO>>

REST

エンドポイント


ポイント３：CDIでコンポーネント間を疎結合化


CDIを利用するメリット

 CDIはJava EE標準のDI機能

 コンポーネント化を促進

–  バグの局所化

–  テストの容易化

–  コンポーネント単位の置き換え

 タイプセーフなインジェクション

–  コンパイル時にエラー検出が可能

 拡張モジュールSPIで機能追加が可能


CDIでフレームワーク実装への依存を弱める

Java EE

業務アプリケーション

フレームワーク部品

サードパーティコンポーネント

APIは維持しつつ、Java EEや周辺技術の進化に応じて実装を変更

Java EE標準APIで互換性は担保される

inject

 業務アプリケーションへフレームワーク部品をインジェクト


（例）ロガーのインジェクト

<<業務アプリ>>

@Inject Logger logger

<<interface>> Logger

ToBe LoggerImpl

java.util.logging 3rd Party

Components

<<producer>> Logger

Producer

AsIs LoggerImpl

<<implements>>

<<calls>> <<calls>>

inject <<creates>>

@Produces Logger getLogger(InjectionPoint ip) { // ロガーインスタンスをリターン }

注入するロガー実装をプロデューサが制御


スコープとコンテキスト

 インジェクトされるインスタンスはコンテキストで管理

–  スコープで最初のインジェクト時に生成され、スコープの終わりで解放

–  同一のスコープ内であれば同じインスタンスが注入される

–  スコープ内でインスタンスを持ち回る必要がない

 CDIのビルトインスコープ

–  @RequestScoped

–  @SessionScoped

–  @ApplicationScoped

–  @ConversationScoped

–  @Dependent 同一のインスタンス

inject

(例)リクエストスコープ

@Request Scoped


CDIイベントを利用したコンポーネント間連携

業務アプリケーション

<<イベント>> MyEvent



<<fires>>

<<fires>>

<<observes>>

public void eventReceived(@Observes MyEvent event) { // イベント処理を記述 }

FW部品間の連携

業務アプリとFW部品間の連携

利用例

  監視情報のイベント送出

  FW部品のパラメータ動的変更


CDIを利用したインスタンスの動的取得

@Inject

Instance<ConfigLoader> configLoaders;

// ConfigLoaderインタフェースを実装する

//全てのクラスのインスタンスがインジェクトされる

for (ConfigLoader loader: configLoaders) {

// 各ConfigLoaderインスタンスに対する処理

}

java.enterprise.inject. Instance

<<interface>> ConfigLoader

Common ConfigLoader

Application ConfigLoader

<<implements>>

<<uses>>


まとめ


今日お話ししたこと

 Java EEでエンタープライズ開発の現場を変えよう

–  システム開発のガバナンス強化

–  技術者の仕事満足度向上による社内定着と作業品質向上

–  社内技術者のスキル向上の容易化

–  外部からの技術者調達の容易化

 まずは３つのポイントから

–  DRYの促進で運用維持コストを削減

–  JSFでコンポーネントベースな開発

–  CDIでコンポーネント間を疎結合化

そして次のステップへ…


みなさんへのお願い

来年のイベントでは

「みなさんのJava EE導入事例」の

発表をぜひ！


Q&A



Documents

1 Copyright© 2013, Oracle Corporation Japan, all rights reserved.otndnld.oracle.co.jp/ondemand/javaday/C-2.pdf · 2013-05-17 · 動的言語 日本のエンタープライズ 開発の危機

1 Copyright© 2013, Oracle Corporation Japan, all rights reserved.otndnld.oracle.co.jp/ondemand/javaday/C-2.pdf · 2013-05-17 · 動的言語日本のエンタープライズ開発の危機