エンタープライズJavaセミナー2015

日時：2015/02/05（木）13:30-17:00
会場：オラクル青山センター
主催：日本オラクル株式会社

所感

Javaは業務で使わない（制約がない）ので、基本JavaSE8の実装ばかりしているが、JavaSE7以前で並列実装を行うとここまで複雑なのかと仰天した。
http://image.slidesharecdn.com/javase8-for-enterprisejava2015-150205025509-conversion-gate01/95/java-se-8-lambda-stream-api-overview-from-history-34-638.jpg?cb=1423193055
また、他社の社内フレームワークのリプレース話を聞ける機会は少ないので、非常に興味深かった。
WebLogicがDocker対応するなどの初出情報もあり、多くの知見を得ることができた。
Java Day Tokyo 2015も楽しみ！！

概要

プロマネ、アーキテクトのためのJavaSE8活用法
JavaSE8でJavaのコーディングはパラダイム・シフトを起こす。
しかし、それによってJavaアプリは可読性、保守性、パフォーマンス全てで大きな利益を享受することができる。
Brian Goetz Javaアーキテクト曰く、
「プロジェクトでLambda式を利用しない場合も、Javaコードをレビューするためにラムダ式を学ぶ必要がある。
また、コアライブラリに対しても大幅に機能が追加されるため、その機能についても学ぶ必要がある。
しかし、Lambda式とStreamAPIによる生産性と表現力の向上は、これらのコストを補って余りあるはずです。」

http://www.oracle.co.jp/jdt2015
Java Day Tokyo 2015 今年国内最大のJavaのイベント。会場、セッション全て拡大している。

JavaEE活用最前線：あのプロジェクトがJavaEE 7を採用した理由～新しい技術を上手に導入する勘所
J2EE時代は業務アプリケーションとJ2EEの間に重厚なフレームワークを挟んでいた。
フレームワークを挟むのは、フレームワークチームがJ2EEのAPIさえもラップし、トップダウン（中央統制）式にアプリをコントロールしていたから。
しかし、JavaEE7になってだいぶ機能は充実してきた。
バッチ処理APIなども実装され、メインフレームからの移行障壁も低くなってきた。
OSSを利用するとEOL問題、バージョン管理などが複雑になってくる。
JavaEE7ベースならば、標準技術であり、長期サポートが見込める。

JavaEE7を効果的に導入を進めるには３つのポイントがある。

進化したJavaEE標準技術を中心にすえ、不足するものだけを補う
J2EEの古い設計・実装の考え方を無理やりJava EEへ持ち込まない
プラットフォーム/ミドルウェア層を含めてアーキテクチャを検討

エンタープライズJavaのためのプラットフォーム WebLogicとJavaCloud最新情報
WebLogicServerは15年内リリース予定の12cR2でJavaEE7を完全サポート予定。
また、Docker上の稼働もサポートする予定。

githubでWebLogic ServerをDocker上で稼働するデモを配布している。
https://github.com/oracle/docker
DockerHubではOracle Linuxのイメージを公開している。
https://registry.hub.docker.com/_/oraclelinux/

Oracleはクラウド戦略としてオンプレでも同じ製品、同じアーキテクチャ、同じ標準技術を利用可能にすることで優れた移行性を持たせる。
異なる技術要件やビジネス要件の両立、ハイブリットクラウドの実現を目指す。

以下、セッションごとの詳細。

プロマネ、アーキテクトのためのJavaSE8活用法

日本オラクル株式会社 Java エバンジェリスト
寺田佳央氏

プロマネの考え
プロジェクトが成功すればよい。成功のためならば技術が古くてもいい。新しい技術の適用はリスクが付きまとう。

アーキテクトの考え
正しいアーキテクチャを選定する。必要に応じて新技術のチャレンジすることは考える。しかし教育コストに対する不安もある。

Java8に移行すべきか？
→当然すべき。パフォーマンス、（学習している人にとっては）可読性、保守性全てが向上する。

Java SE8 のパラダイム・シフト

Lambda式やストリームAPIが追加された今、
JavaSE8をしっかり学習しないとコードレビューすらできなくなる。

なぜJavaSE8に移行すべきなのか

例えばパフォーマンス問題。
ボトルネックの要因は様々あるが、例えばシステム（マルチコア）を効果的に利用しているのか。
使いこなせるような設計、プログラミングをしているのか？Javaのせいなのか？

JDK1.5以降(でConcurrencyUtilを正しく)を使っていれば、CPUのコアを簡単に全て使い切ることができる。

Lambda式導入の背景

マルチコアがきっかけ。
最近はノートPCでもマルチコア、サーバは1024コアにもなる。
そのようなHW環境のなかで、並列実装は必須。JavaSE8で並列処理を簡単に実現することが出来る。

ラムダ式とストリームを用いれば余計な中間処理（compare、中間状態を保存する変数）を記述せずに簡潔に実装できる。
排他などの細かい処理はライブラリに任せればよい。並列処理もparalell()するだけ。
コレクションに対する並列処理はJavaSEで導入されたFork/Joinフレームワークが利用できる。
並列処理はコードが多くなるし、バグが混入する可能性が高くなる。
ストリームAPIを使えば、paralellStream()で呼ぶだけ。

しかし、実際の学習コストはどれくらいなのか？
変化にはコストが伴う。ルールを理解してください。
Brian Goetz Javaアーキテクト曰く、
「プロジェクトでLambda式を利用しない場合も、Javaコードをレビューするためにラムダ式を学ぶ必要がある。
また、コアライブラリに対しても大幅に機能が追加されるため、その機能についても学ぶ必要がある。
しかし、Lambda式とStreamAPIによる生産性と表現力の向上は、これらのコストを補って余りあるはずです。」

アップグレードするその他の理由
・JavaSE7の公式アップデートが15年4月で終了。JREもJava8を配布している。
・JVMの改良
・セキュリティの改良。Oracleではセキュリティに特化したクリティカルパッチを年4回配布している。
・パフォーマンスもJava7と比較して40%改善されている。

Java Day Tokyo 2015
http://www.oracle.co.jp/jdt2015
2015年はJava20周年！今年最大のJavaのイベント。昨年より会場、セッション全て拡大しているので、お楽しみに。

JavaEE活用最前線：あのプロジェクトがJavaEE 7を採用した理由～新しい技術を上手に導入する勘所

日本オラクル株式会社
コンサルティングサービス事業統括　テクノロジーコンサルティング統括本部
ITソリューション本部ソリューションアーキテクト部ソリューションマネジャー
大橋勝之氏

企業でのアプリ開発の悩み

開発生産性が低く、品質も安定しない
運用管理に手間とお金がかかる
社内の技術者育成が進まず、リテンションも難しい

今こそアーキテクトが活躍すべき時。
ビジネスサイドの課題にフォーカスしてITを考える。JavaEEという材料をどう料理するかがアーキテクトの腕の見せどころ。

J2EE時代のアプリ構造は業務アプリケーションとJ2EEの間に重厚なフレームワークを挟んでいた。
重厚なサードパーティ製フレームワークを挟むことがなぜ必要だったのか？

J2EEの機能が不足だったから
フレームワークチームが機能をガバナンスするスタイルの標準化

フレームワークを挟むのは、フレームワークチームがJ2EEのAPIさえもラップし、トップダウン（中央統制）式に開発をコントロールしていたから。
しかしJavaEEは進化しているが、企業のフレームワークチームのJavaEEの進化への対応が後手に回っている。

リリース後の活動予算がフレームワークチームにつきにくい
塩漬け利用を続けてるうちに構築したフレームワークが陳腐化する
現場レベルと技術レベルが逆転することもある
Struts問題やEOLもあり、OSSの利用も安泰ではない。

アプリケーションの内製化促進に向けた社内開発体制の整備が急務に
JavaEE7で標準機能となったバッチ処理APIを利用すれば、MFからの移行が促進できる。
JavaEE7対応の商用アプリサーバのリリースが年内にもある。

効果的に導入を進める３つのポイント

進化したJavaEE標準技術を中心にすえ、不足するものだけを補う
J2EE導入時と同じスタンスに立ち戻ってシンプルにシステムを構成
技術者育成、調達の容易化を意識して利用する技術のスコープを適切に保つ

J2EEの古い設計・実装の考え方を無理やりJava EEへ持ち込まない
「慣れているJ2EE時代のやりかた」はJavaEEのメリットを打ち消す効果に
「慣れているから昔（すとらっつ）のやり方のほうが安い」は後々高くつく結果に

プラットフォーム/ミドルウェア層を含めてアーキテクチャを検討
非機能要件の実現にはミドルウェアが提供する運用系の機能を活用し、アプリケーション側で実現すべき機能をシンプル化
アーキテクチャをパターンかしてベスト・プラクティスを共有し、パターンベースのコミュニケーションやスタッフ教育によってノウハウの再利用を促進

お客様事例：JavaEE7を活用するフレームワーク開発プロジェクトの勘所

プロジェクト紹介：背景と目的

ティージー情報ネットワーク。東京ガスグループのSI企業。
東京ガス内には社内システムが約180システムほど存在する。14年度からシステムのリプレース開始。
リプレース前にシステム全体の開発基板となる自社開発JavaEE7対応フレームワークの開発が開始。

現行フレームワークの課題

現行フレームワークで利用しているOSS(Struts、iBATIS)のサポートが終了している。
多くのライブラリを利用しているので、OSSのバージョンアップも大変。
独自フレームワークは学習コストが高い
提供された部品で何ができるのかわかりにくい
部品化されているものを利用するため、制約が多い。

現場の課題
社内で10年に一度のフレームワーク移管のチャンスをどう活かすか
悩ませない・迷わせない・停滞させないシステム開発・運用を実現したい
それにより内製アプリのライフサイクル全体のコストを削減する。

新フレームワークではJavaEE7ベースで実現。標準技術であり、長期サポートが見込めるから。
フレームワーク部品をJavaEE7へ焼き直すのではなく、TGフレームワークの課題・要件を改めて見直した。

仕様書のカイゼン
提供構成のカイゼン。共通部分はモジュールとして提供。実装も提示（ログインAPIとログイン画面など）
ガイドのカイゼン
資源管理のカイゼン。自動テスト・CI環境など。
開発サポート範囲の拡大。設計～開発だけではなく、環境導入から運用までサポートするのが目標

JavaEE7先行がゆえの悩み
対応する製品のリリースとフレームワークのリリースタイミングが近く、
アプリサーバがリリースされていない中での品質担保する必要がある。
そのため、開発・テストを実施するアプリサーバと実行環境は別々にして解決。
目的別にテストを複数回に分けて、実施（繰り返しテストはCI、自動化）

技術情報が少ない点は、アプリケーションベンダーコンサルを利用。
セカンドオピニオンとして、異なるベンダーコンサルを利用することも有効。

エンタープライズJavaのためのプラットフォーム　WebLogicとJavaCloud最新情報

日本オラクル株式会社
Fusion Middleware事業統括ビジネス推進本部製品戦略部
シニアマネージャー新井庸介氏

Java Flight Recorder
WebLogicServerとJava Flight Recorderがあれば、障害対応を強力に支援。
アプリケーションの改変不要。利用アプリサーバ、ミドルウェアを選ばない。
サポート連携もしやすい。サポートエンジニアとフィールドエンジニアの間で必要なデータのやりとりを減らせる。
JFRファイルにほぼ全ての情報が詰まっているので、GCもダンプも必要ない。

Java Flight RecorderとWebLogicサーバを連携することでさらに情報を取得できる。
ウェブロジックと連携すれば、JDBCやJavaEE、WebLogic層の情報も取得できる。

Mission ControlにはWebLogic連携専用の画面もある。WebLogicの情報をより簡易に見れる画面。

Web Logic serverとJavaEE7
12cはJavaEE7の一部に対応。JPA2.1 JAX-RS 2.0 Java API for JSON 1.0, Java API for websocket 1.0
12cR2では全てのAPIに対応する予定。

Web Logic Serverとクラウド
大手ベンダーからDockerサポート表明が相次いでいる
Web Logic ServerもDockerコンテナ上での稼働をサポートする予定。
Spec
Docker 1.3.2-
OS Oracle Linux 6 with 3.8.13-
Web Logic Server 12.1.3-

githubでもWeb LogicをDocker上で稼働するデモを配布している。
https://github.com/oracle/docker
DockerHubではOracle Linuxのイメージを公開している。
https://registry.hub.docker.com/_/oraclelinux/

マルチテナント
従来はアプリに対して、アプリサーバ、JVVMが1:1ペアになっている。
Weblogicのマルチテナント機能では、一組のJVM、アプリサーバを複数アプリで共有できるようになる。
アプリケーションごとに利用可能領域などを区分けできるようになる。
ヒープ、CPU時間、ファイルディスクリプタなどをコンテナごとに割り振る。
集約率、管理性の向上が期待でき、アプリが増えてもJavaのプロセスは少ないまま。
アプリ、アクセス制限、利用可能領域などのテナントへの設定情報を一つのパッケージングとして他のサーバに移管できるようにする。

オラクルのクラウド戦略

クラウドでもオンプレでも同じ製品、同じアーキテクチャ、同じ標準技術を利用可能にすることで優れた移行性を持たせる
異なる技術要件やビジネス要件の両立、ハイブリットクラウドの実現を目指す。

エンタープライズJavaセミナー2015に参加してきました

所感

概要