JavaOne2014 2日目メモ (9/29)

JavaOne

2日目。朝は霧が出ていて少し寒いが、日中になると日差しが出て半袖でも良いくらい暑くなる。今日から本格的にセッションの開始。

Java EE 8 [CON3015]

Java EE8のスペックリードであるLinda DeMichielさんによる、Java EE 8の現状の方針を話すセッション。

Java EE 8の大きなテーマは3つ。

  • HTML5/Web層の改善
  • Easy of Development (かんたんに開発) / CDI Alignment
  • モダンインフラへの対応 (クラウド対応)
HTML5/Web層の改善
Easy of Development / CDI Alignment
  • セキュリティインターセプタ
  • コンテナ管理Beanのシンプルな一本化。EJBでしかできない"MDB"をCDIで実行。
  • EJB2.x のクライアント向けビューをプルーニング(オプション化)
    • EJBHomeやEJBObjectなどのEJB2.xがオプション仕様となる
モダンインフラへの対応
  • Java EE Management APIの導入
    • RESTベースのAPIでAPサーバの管理・監視を標準化する　
  • Java EE Security 1.0
    • 現状使いにくいセキュリティ仕様を見直して作り直す

Tutorial: JVM Platform as a Service [TUT3525]

スエーデンのCITERUSという企業の技術者が、2012年にJavaが使えるPaaSを使ったプロジェクトを経験談を交えながら、各PaaSプラットフォームの特徴やデモを示すセッション。

なぜPaaS？
  • 何よりもtime-to-marketの達成がPaaSを使う一番の目的。
  • 過去の事例では、顧客のコアドメインがITと関連が薄く、ITインフラ(サーバとか)を持ってなかったのがPaaS適用を推進した。
dotcloudを使ってみて
  • Java、MongoDB、PostgreSQL、RabbitMQが使いたかったため、テクノロジスタックが合った
  • 実際に運用してみたら色々問題も出てきた
    • ヨーロッパ - アメリカのレイテンシによる性能問題、価格の値上げ改定
  • 結果的にjerasticを使ってサービスを提供しているスエーデン国内のPaaSサービスに移行し、各々の問題に対処した。
どうやってPaaSを選ぶ？
  • 提供されているテクノロジスタック(言語、DB、Webコンテナ等)
  • 成熟しているサービスか？SLAおよび、サポート条件。価格。
  • ロックインされるか？ (例えばGoogle BigtableをPaaSで使う等)
  • 価格は変動する。常に同じだと思わない方が良い。

PaaSは良い面ばかりがフォーカスされがちですが、歴史の浅いサービスだと価格改定が頻繁にあることが想像できてなかったので、良い勉強になりました。

HTTP 2.0 Comes to Java: What Servlet 4.0 Means to You [CON5989]

HTTP2.0(SPDY)の登場に伴い、ServletやJava SE9のAPIへの機能追加について紹介するセッション。まだ JSR369 Servlet4.0 として検討がはじまったところで、いくつかのコード案が紹介されたが写真取れず。

Java SE 9側でのHTTP2.0クライアントのアイディアについては、以下のようなコード例が紹介された。

HttpRequestGroup group = HttpRequestGroup.create();
HttpRequest req = group.createRequest()
    .setRequestMethod("POST")
    .setRequestURI(new URI("http://www.foo.com/a/b"))
    .setRequestBody("param1=1,param2=2")
    .onResponseHeader("X-Foo", (request, name, value) -> {
        System.out.println("receive an X-Foo header")
     })
    .sendRequest()
    .waitForCompletion();

HTTP2.0では、1つのコネクションが1対1でのリクエスト/レスポンスモデルではなく、複数のリクエストが1コネクションで並行して送受信されるため、リクエストのグループ化(HttpRequestGroup)が導入し、その後のリクエスト送信にもメソッドチェーンや、リクエスト応答のヘッダ処理にラムダ式を書いたり、最近のJavaっぽいAPI案となっている。

Modular Architectures Using Microservices [CON6132]

モジュラアーキテクチャの考え方を、クラウド環境でOSGiを使うためにリモート呼び出しなどをサポートするAmdatuを使って実現する方法を紹介したセッション。

まず、amdatuによる実装を示す前に、ソフトウェアをなるべくモジュール化して連携させるモジュラアーキテクチャとマイクロサービスの考え方を紹介した。

モジュラアーキテクチャとは

原則として以下の２つを要件として紹介した。

  • Adaptivility (change ahead)
    • 適応性。ビジネス・環境の変化にソフトウェアの変更が追従できるか。
  • Reuse
    • 再利用。コピペしない。オブジェクト指向もコピペをなるべくなくして、コンポーネントを上手に区切り、なるべくコードを再利用しやすいようにするのが始まりだった。
マイクロサービスとは
  • マーチンファウラ氏のブログの内容を時折引用。
    • 個々のコンポーネントはそれぞれ自分のデータを持つ。小さなサービスごとにデータを分ける。
    • DDDでコンテキスト境界として紹介されている単位
    • 分散サービスの連携においては、トランザクションを使わずにeventual consistency(実質的なxxx)によって現実的な一貫性の保持を目指す
    • サービスは自らのライフサイクルを持つ
    • RESTやメッセージングなどの軽量なコミュニケーション手段を使う
      • 分散サービスの連携に、ESBのような複雑性を持ち込まない
  • 分散システム固有の設計には注意する必要
    • どれか１つが落ちていても、サービスが縮小継続できるように
    • モニタリングに手間が掛かるのは、分散の代償
OSGiについて
  • モジュラアーキテクチャを実現する上で、バージョンの管理とデプロイの分離が必要
  • OSGiでバンドルごとのバージョン管理、デプロイ分離を実現
  • MANIFEST.MFへのexport/import記述により、API実装の詳細を隠してモジュール公開することが可能
Amdatu

リモート分散環境でOSGiを使うためのソフトウェア。OSSとして公開。自分でリモート接続コードを書かなくても、内部的にうまくやってくれてユーザは各OSGiバンドルの開発に集中できるらしい。

まとめると、マイクロサービスの実現例の１つとして、OSGiを使って、リモート分散をAmdatuに使いましたよというセッションでした。

Banking on OpenJDK: How Goldman Sachs Is Using and Contributing to OpenJDK [CON5177]

Goldman Sachs社のOpenJDKへの取り組みに関するセッション。

Goldman SachsとJava
  • 1998年頃からJavaを技術評価として利用開始
  • 2004年から自社コレクションフレームワークを作り始め(githubで公開中)
  • 2013年からOCAにサインして、OpenJDKへのコントリビュートを開始した
  • 190GB以上のヒープを持つシステム、大量の分岐があって、JITコードキャッシュに影響を与える特殊な環境が特徴的。
なぜOpenJDKに力を入れ始めたのか
  • ソースが見れるのが何よりも重要
    • 商用でクラッシュしても解析できる
    • HotSpotの内部で改善できそうな部分を自分たちで見つけることができる
  • パッチを投げることが、自分たちのためにも、コミュニティのためにもなる
どんな風にOpenJDKを使っている
  • トラブルシューティング、新規能の研究・検証に使用
    • JVMTIでアサーションエラーが発生したバグ解析とパッチ作成の事例を紹介
  • 今のところ、プロダクション環境では使っていない

OpenJDKしてのソースが公開により、筆者自身もAPIやHotspotでのトラブル時に大変助かっている。Redhat Enterprise Linuxを使っているシステムではOpenJDKがバンドルされていて気軽に使えるので、もっと使われるところが増えると嬉しい。