カタカタブログ

SIerで働くITエンジニアがカタカタした記録を残す技術ブログ。Java, Oracle Database, Linuxが中心です。たまに数学やデータ分析なども。

Java Day Tokyo 2015に行ってきました

Java

今日は4月上旬なのに真冬並の寒さという中、東京国際フォーラムで開催された、Java Day Tokyo 2015に参加してきました。Javaのイベントに参加するのは初めてだったのですが、詳しく知りたいと思っていたJava EE周りの最新動向や方法論について、いろいろ知ることができてとても有意義でした。とりあえず参加したセッションについてのメモや雑感を簡単にまとめます。

オープニング

Oracle社によるJavaクラウドサービスとして、「JAVA CLOUD SERVICE」なるものが展開されるよう。後でJava Cloud Serviceの概要を調べてみたところ、クラウド上でWebLogicサーバを建てられるサービスとのこと。

Key Note

何人かでスピーカーを交代しながら、Javaの展望やデモなどを披露。デモは組み込み系のものが多かった印象。以下、簡単なメモ。

Java8について

JDK8の目新しいところ。

  • Lambda - Java言語、Javaライブラリ、プログラミングモデルの進歩
  • Streams - パフォーマンス改善(fork/join)
  • Security

Demo - Aldebaran

PepperをJavaで動かすデモ。あいさつや簡単や動作コンポーネント化されており、専用(?)の開発ツールではコンポーネントを線でつなぐだけでPepperが「動く」 -> 「あいさつする」という動作を披露。

f:id:osn_th:20150408100352j:plain

Java SE 9

Java SE 9のEarly Access buildsが利用可能になった。
https://jdk9.java.net/

Demo - Yoneyama Manabu むずかしいをかんたんに ( ルネサス エレクトロニクス株式会社)

IoT(Internet of Things)市場は急成長している。
ルネサスは、ゲートウェイとセンサーの通信を簡単にしたい。
現状は、センサーが膨大なデータを送信し、ビッグデータによる解析や大規模ストレージを必要とする課題がある。
これを、センサー(ノード)側でデータを処理し、価値ある小さなデータとして送信するようにする。
ノード側を高機能化し、Java MEで動くようにした。

RZ/A1シリーズという汎用デバイスを使ったデモ。外付け部品なしで簡単にものを作れるらしい。
例えば、バスに取り付けて、バスがバス停ごとにそのときの遅れや乗客数や気温をツイートしたり、渋滞遭遇時にもそれをツイートしたりする。社会が便利になる。

Demo - Jasper Potts

自動車にiPadのようなタッチデバイスをつけて様々な情報を表示するなど。

Java EE

Java EE 7の新しい点として、HTML5, JSON, WebSockets, JAX-RSと行った新技術への対応や、アノテーションベースの開発容易化などが挙げられる。
GlassFish Server Open Source Edition 4.1がリリースされ、Java EEのアプリケーションサーバも進歩している。
Java EE 8も進めている。

Demo - Oracle Cloud: Java Cloud Service

クラウド上でWebLogic12cが使える。Oracle Coherenceも使えるので、クラウド上のキャッシュメモリ機構も利用できる。

Javaへの新たな取り組み

3名のパネリストからそれぞれの取り組みについての話。

楽天 JCP(Java Community Porcess)参加 - 仲宗根さん

楽天のミッションクリティカルなサービスはJavaで出来ている。
JSFだと要件を満たせないことがまだまだある。
楽天のメンバーがJSF 2.3の策定に貢献: @PageScoped, @TemplateScoped追加

日本Javaユーザーグループ

ナイトセミナー(月1), 週末ハンズオン(半日、一日ハンズオン), 国際会議への参加など
JJUG CCC 2015 Sprint 4/11

関西Javaエンジニアの会(関ジャバ) JUGに参加しよう

NetBeansとGlassFishではじめるJava EE 7ハンズオンラボ

以下の2機能を使ったJavaハンズオン。

  • Java API for WebSocket
  • jBatch

IT課題の解決に向けたJava EEセントリックな開発標準化の勘所

大橋勝之

企業におけるITの課題とこれまでの取り組み

・課題

  • アプリ開発生産性があがらない、品質が安定しない
  • アプリ運用管理に手間とお金がかかる
  • 技術者育成が進まない

J2EE時代の開発標準化

2000年代初頭、各社の独自フレームワーク(いわゆる俺々フレームワーク)が乱立した。
J2EEの機能不足をサードパーティ製のフレームワークで補うため。
それを、フレームワーク担当チームが標準化とメンテを手厚く対応してきた。

現在、独自フレームワークを使った標準化が難しくなってきた。
ユーザ企業と開発ベンダがそれぞれ持つフレームワークのミスマッチ。
フレームワーク担当チームのオペレーションコストが大きい。

オープンソース製品へのロックインのリスク

※オープンソース製品のリスクではない。ロックインすることへのリスク。

  • ベース技術の陳腐化による開発生産性低下
  • プロジェクトのEOLやセキュリティ脆弱性問題対応コスト
  • バージョンアップ時の動作検証等の追加工数発生

例: StrutsのようなEOLのオープンソース製品

Java EEセントリックな開発標準化

サードパーティ製フレームワークを使わず、進化したJava EEを素で使う構成へシフトする。

Java EE 7

多くの企業が開発の内製化を意識
バッチ処理APIを標準メインフレームのダウンサイジング促進
Java EE7商用アプリケーションサーバが出揃う見通し

開発標準化でJava EEをうまくつかう勘所

・Java EEは「標準」と「後方互換性」を利用する。バージョンアップしても安心して使えるので、サードパーティ製のようなバージョンアップリスクがない。

・Java EEのプラットフォーム上でアーキ均質化
プレゼンテーション層、ビジネスロジック層、インテグレーション層

・サードパーティ製品は疎結合にしてロックインを回避
利用を局所化して疎結合

・Java EE標準アーキテクチャ
JSF -> Backing Bean(POJO / CDI) -> Business Logic(EJB/JTA) -> JPA

各コンポーネントの作りをパターン化して再利用し、もう一段踏み込んで標準化する

コンポーネントの設計パターンを整備し、ガイドとカタログを作る
パターンの再利用によって、構成を均質化し、実装時の技術的リスクを緩和
パターン名を利用したコミュニケーションにより、プロジェクト関係者でのアーキテクチャ理解の促進

  • View Scoped Backing Beanパターン: 画面とバッキングビーンが1:1

アクションベースのFWに慣れた人が好む

  • Session Scoped Backing Beanパターン: JSFのスコープを利用
  • Conversation Scoped Backing Beanパターン: @ConversationScopedを使ってスコープを明示的に制御

・開発フレームワーク
標準アーキガイド、開発ガイドの整備。


f:id:osn_th:20150408153821j:plain

エンタープライズ・アーキテクチャの選択について

鈴木雄介(グロースエキスパートナーズ株式会社)
JJUG会長

アーキテクチャとは何か？
どうやって選択したらよいのか？どういう観点で考えるべきか？

アーキテクチャとは

・システムの「分け方と組合せ方」を定義したもの。システムのミッションに従い、制約や環境を前提しながら、複数の利害関係者の関心ごとを整合させる。
簡単にいうと、「システム全体のバランスを取る」こと。

・アーキテクチャの成果とは
システムの構造とプロセスの決定
構造: システムの機能がどのように分解するか
プロセス: それらの要素をどのように組み立てるか

これにリソースとスケジュールを加味するとWBS(ガントチャート)になる

・エンタープライズ・アーキテクチャとは
企業システムを対象

  • 利害関係者が多い
  • 連携先システムが多い(レガシー)
  • 急激に変化できない/しない (社会基盤としての責務)
  • 現状維持(踏襲)が重要(「現行踏襲」の罠)
  • 様々なシステム(B2B, B2C, B2Eなど)
  • 様々なルール(内部統制、セキュリティ、法制度など)

・なぜアーキテクチャを定義するか
アーキテクチャが全てのスタート
プロジェクトマネジメントはアーキテクチャを前提とした実行段階における「計画、実行、計測、調整」の営み

最初に全て「固定的に決める」必要はない。「選択肢を残す決定」はできる。

アーキテクチャ選択の観点

様々な観点でバランスを取る作業。3つの観点を本日は紹介。
  • ITサービス運営
  • 品質
  • 技術
ITサービス運営の必要性

「アプリケーションを作る」から、「ITサービスを運営する」へ
決めた仕様に従って開発し、プロジェクトが終了するまでの活動から

  • > 利用者からフィードバックを受け、終わることのない持続的な活動へ
ITサービス運営モデル

「構造」+「プロセス」 -> 「機能」-> 「ITサービス」の要素と、
「開発」、「業務」、「企画」など、各利害関係をモデル化。

より「ITサービス運用」を意識したアーキテクチャ設計になっていく必要がある

ユーザが利用することで評価される

IT/ソフトウェア品質特性

品質とは

  • 多面的で一つのパラメータでは制御できない
  • いくつかの観点でバランスをとりながら
経産省のソフトウェアの品質メトリクスセット

品質特性同士が打ち消し合う場合もある。安易な両立は避けるべき。
コストの観点では保守性が重要。
互換性はあらゆるシーンで重要(標準準拠)
エンタープライズでは信頼性とセキュリティが重要

技術

共有と固有のバランス

  • 共有された資源を最大限に活用する
  • 固有ドメインの特性を最大限に発揮する
マイクロサービス

サービスによってシステムを構成する

  • サービス同士はAPIによって連携
  • サービス同士は独立した構造とプロセスを持つ
  • サービスは独自のライフサイクルを持つ
  • サービスは個別のドメインに従う

あまりにも独立させるとスケールしない

選択の実践

ECサイト: エンタープライズ的なありながらWeb的

ECサイトに必要な機能

  • 商品管理
  • コンテンツ管理
  • 商品検索
  • 商品購買
  • 受注管理
選択の覚悟

アーキテクトは「正解がない」から覚悟が必要となる

  • 最大公約数を目指す
  • 銀の弾丸はない
  • 妥協せず、諦める

Java EE 7適用のための7つのポイント

岩崎浩文 (楽天株式会社)

1. アプリケーションサーバどうするか

GlassFish, WebSphere, WebLogic, WildFly, ...

商用vsフリー

2. IDEどうするか。Mavenをうまく使う。

IDE
  • NetBeans
  • IntelliJ IDEA
  • Eclipse

日本だとEclipseが圧倒的に人気だが、海外だと三つ巴。

ビルドツール
  • Maven : pom.xmlで依存ライブラリをインターネットからダウンロードする。複雑なことは苦手。IDEは標準サポート。
  • Gradle : build.grandleでライブラリをインターネットからダウンロードする。複雑なこともスクリプト書きやすい。IDEはプラグインサポート。
  • (antはそろそろやめる)

pom.xmlがあればIDEがプロジェクトをインポートしてくれるので、MavenベースならIDEに依存しなくてオススメ。

3. JSFをフロントエンドに使う

PrimeFacesで追加コンポーネントがたくさんある
view-based
画面とバッキングビーンが1:1

一方、Apache Struts
view -> Action -> view2

StrutsはJSPを使っているので、修正しても再デプロイしないとサーバには反映されない。
JSFはFaceletであり、逐次解釈なので、修正するとリロードで反映。

JSF2.2のHTML Friendlyタグを使う : HTMLタグに追加ネームスペースの属性を指定するだけでよい。
これまでのでなく、

4. EJBをバックエンドに使う

EJB: Java EEのコアコンポーネント

EJBの標準機能
  • リモート呼び出しできる: RMI-IIOP, SOAP, REST, WebSocket(Java EE7から)
  • 自動トランザクション管理: メソッド単位でbegin, commit
  • インスタンスプーリング: アプリケーションサーバ起動時にインスタンスを初期化。EJBインスタンスをプーリングしている。
  • セキュリティ管理: EJBの呼ばれる元を管理
EJB 3
  • アノテーションベースPOJO: @Stateless
  • インジェクション導入: @EJB, @Inject
  • エンティティBean -> JPA : JPAはHibernateを標準化したもの
  • デプロイメント記述子は必須ではなくなった (アノテーションを上書きできる)
  • Embedded EJB Container for Testing : コマンドベースでテストのためのEJBコンテナが起動でき、テストできるようになった (WebLogicのEmbedded EJB Containerとか)。
バッチをJavaで書くとどうすればよい？３つの選択肢。
  • EJBを使い、EJBを外(JP1など)からリモート呼び出しする
  • Java Batch Frameworkを使い、外から実行(Sprint batchが標準化されたものだがタイマー起動とかない): 今は使わないほうがよさそう。
  • Java EE Serverを使わず、POJOで全て書く。: 非推奨

Java EE 7 specはJava SE 8は考慮していないので、ラムダは使わない。

5. リモート接続

  • RMI-IIOP : クリティカルな要件にはおすすめ。XAがサポートされる唯一の通信。@Remote
  • WebSocket : 軽量な要件におすすめ。HTTPではなく、一度セッションを確立するとずっと保持し双方向に通信する。@ServerEndPoint
  • SOAP: 開発はほとんど止まった。使うべきではない。
  • REST: マーシャリング・アンマーシャリングのサポートがなく、WebSocketより遅いのでいまいち。

6. JPA

Hibernateから標準化されたORマッパー
NetBeansだと、テーブルからJPAエンティティ、JPA DAOまで自動生成できる。

クエリの書き方

  • JPQL: SQLライクな文を書く
  • LINQ: メソッド呼び出しでクエリを組み立てる

トランザクション処理: EJB内でJDBC接続を買ってにしてはいけない。WebLogicサポート外。
JPAはEJBの中で使うべき。自動トランザクションに参加してくれるので、例外でロールバックとか明示的に書く必要がない。

7. Java EE 8

CDI2.0, JSON-Bあたりがおすすめ。
標準APIを使うのがおすすめ。

今後は廃止される仕様もある。
EJBはどうなるかわからない。CDIに統合されるかも？

その他

JavaマスコットキャクターのDukeが歩きまわってました。
f:id:osn_th:20150408182920j:plain