[Java] Understanding the Server JRE

原文はこちら。
https://blogs.oracle.com/java-platform-group/understanding-the-server-jre

Java SEダウンロードページには、Java Server Runtime Environment (JRE) 、Server JRE、Java Development Kit (JDK) のダウンロードリンクがあります。
Java SE download Page
http://www.oracle.com/technetwork/java/javase/downloads/index.html
[Glossary]
Java Runtime Environment (JRE)
http://www.oracle.com/technetwork/java/glossary-135216.html#jre
JDK
http://www.oracle.com/technetwork/java/glossary-135216.html#jdk
JREは、デスクトップのJavaアプリケーションを含んだ幅広いJavaプログラムを実行するために使われます。JDKはJava開発者のためのもので、これには先ほど述べたJREと、Javaプログラムの開発、コードの署名、ドキュメントの生成などのために必要なツールが含まれています。JDKはプログラムの監視やデバッグのためのツールも同梱しています。

では、Server JREはどこに収まるのでしょう。一般的なサーバーサイド・アプリケーションの観点から、JREには監視ツールや、実行時にJavaソースコードをコンパイルするアプリケーションの場合、javacはありません。一方、JDKには、システム管理者にとっては、本番環境上では必要としないようなWebブラウザ用のJavaプラグイン、自動更新エージェント、javadocなどの開発ツールといった、追加の機能が含まれています。

Server JREについて:Server JREはサーバーサイド・アプリケーション用に設計されていて、JREおよびJDKから一般的に必要な機能だけを含んでいます。Server JREには専用のインストーラがなく、簡単に使用できるように単純に圧縮されたディレクトリとして提供しています。

Server JREは全てのサーバーアプリケーションで利用できるの?
いいえ、アプリケーションがServer JREで提供しているもの以外の機能を必要としている場合、例えば追加の開発ツールやJavaFXなどが必要であれば、Server JREは当該アプリケーションにとって適切な選択ではないでしょう。

JDKがServer JREのスーパーセットなら、単純にJDKを使えばいいんじゃないの?
不要なコンポーネントを削除することで、潜在的な攻撃対象を減らし、より小さいサイズにすることでストレージやデプロイメントをより速く、より簡単にしています。Linux x64システムでは、Server JRE 8はJDK 8のフルサイズの40%程度のサイズです。

利用しているソフトウェアのベンダーがアプリケーションにJDKが必要と言っているのだけど、そのかわりにServer JREを使うことができるの?
ソフトウェアベンダーに問い合わせてJDKではなくServer JREを利用できるかどうか尋ねてください。実験できるなら、試してみるべきでしょう。アプリケーションを実行するだけであれば、JDKよりもServer JREを常にお奨めします。

Server JREに含まれているものに対して変更を提案できるの?
はい。Server JREの目的は、大部分のサーバー・アプリケーションに必要なツールを提供することですが、全てのサーバー・アプリケーション向けでないのは確かにそうです。常に含めるべきコンポーネントを再評価しています。

通常のOracle Communityチャネルを通じて、是非フィードバックをお寄せください。
Java Runtime Environment (JRE)
https://community.oracle.com/community/java/java_desktop/java_runtime_environment

[misc.] Announcing Oracle Developers on Medium

原文はこちら。
https://blogs.oracle.com/developers/announcing-oracle-developers-on-medium

技術コンテンツを熱心に読んでらっしゃるなら、Mediumに詳細な技術記事を出していることをご存知かと思います。
OracleDevs - Medium
https://medium.com/oracledevs
Oracle Cloudやその他Oracleテクノロジーに関して共有できる優れたコンテンツを有する、文字通り全ての人が、そのすばらしいコンテンツをホストするための専用の場所としてこのMediumを利用できるようにしています。medium.com/oracledevsのコンテンツは、Oracleのエンジニアやプロダクトマネージャ、コンサルタントだけでなく、Oracleテクノロジーを使ってくださる多くの外部開発者からのコンテンツを纏めたものです。

Oracle ACEエキスパート、Java Champion、先日立ち上がったDeveloper Championは自由に参加できます。

Related Content

コンテンツを見逃さないよう、是非すぐにOracleDevsをフォローしてください。先日公開されたAbhisek GuptaAbhinav ShroffDan McGhanらによる興味深い記事が見つかることでしょう。

JFrogのArtifactoryでDeveloper Cloud Serviceを使用する上での洞察、WildFly SwarmでMicroProfileアプリケーションをデプロイする方法、Node.jsアプリケーション用のデータベースサンドボックスを作成する方法、Javaアプリケーション用にRedisをデプロイする方法、Artilleryを使う方法など、手始めに5つの記事が公開されています。是非チェックしてください。

このmedium/OracleDevsに記事を出してコンテンツを広く展開したいと思っている方は、筆者(bruno dot borges at oracle dot com)までメールを送ってください。そのとき、タイトルは [Medium] Story Proposalとしておいてください。なお、公開するためには、Mediumでのユーザー名を忘れずにお知らせください。

[Database] Python cx_Oracle 6.0 RC 2 is on PyPI

原文はこちら。
https://blogs.oracle.com/opal/python-cx_oracle-60-rc-2-is-on-pypi

Python cx_Oracle は、Oracle DatabaseのPythonインターフェースです。
Anthony Tuininga がPython cx_Oracle 6.0のRelease Candidate 2(おそらく最終版)をリリースしました。PyPIからご利用いただけます。
cx_Oracle 6.0rc2
https://pypi.python.org/pypi/cx_Oracle/ 
現在プロダクションリリースに向けて全力を尽くしているので、テストを続けてください。 Issueは、GitHubやメーリングリストで報告することができます。
python-cx_Oracle Issue Tracker
https://github.com/oracle/python-cx_Oracle/issues
Mailing List: cx-oracle-users
https://sourceforge.net/projects/cx-oracle/lists/cx-oracle-users
このプレリリース版をインストールするためには、 '--pre' オプションを使ってください。
python -m pip install cx_Oracle --upgrade --pre
Oracleクライアントライブラリも必要ですが、無償のOracle Instant Clientを使うことができます。
Oracle Instant Client
http://www.oracle.com/technetwork/database/features/instant-client/
ブログの読者の方々がユーザビリティの面で筆者が気に入った部分を知ってもらえるよう、いくつかの変更点を強調したいと思います。
  • 今回のリリースでは、最新のODPI-C Oracle DB抽象化レイヤを採用しています。特に、cx_Oracleのインポート時に'UnicodeDecodeError' という混乱させるWindowsシステムメッセージが出ていた問題が解決しました。これで実際のWindowsエラーメッセージが表示され、根本的な問題点を確認することができます。
  • インストールに関する注意事項は整理されており、ドキュメントの新しいインストールの章に、トラブルシューティングのヒントとともに記載されています。
    cx_Oracle 6 Installation
    http://cx-oracle.readthedocs.io/en/latest/installation.html
  • いくつかの導入サンプルが追加され、サンプルやテストスキーマ作成スクリプトが改善されています。これらのスクリプトは、共通のファイルを参照して資格情報を設定するため、すべてのファイルを編集することなく簡単に試すことができます。
    python-cx_Oracleのsample
    https://github.com/oracle/python-cx_Oracle/tree/master/samples
cx_Oracleのリリースノートは以下からご覧いただけます。フィードバックをお待ちしています。
cx_Oracle Release Notes
http://cx-oracle.readthedocs.io/en/latest/releasenotes.html

[Database] ODPI-C 2.0.0 RC2 is released on GitHub

原文はこちら。
https://blogs.oracle.com/opal/odpi-c-200-rc2-is-released-on-github

ODPI-C 2.0.0 Release Candidate 2がGitHubからご利用頂けるようになりました。
Oracle Database Programming Interface for Drivers and Applications
https://github.com/oracle/odpi
ODPI-Cとは、Oracle Databaseドライバやユーザーアプリケーション向けに、よく使われるOracle Call Interface (OCI) の機能を簡単に利用できるようにするためのCで書かれたオープンソース・ライブラリです。
2.0.0 RC2のリリースノートは以下にあります。
ODPI-C Release notes
https://oracle.github.io/odpi/doc/releasenotes.html
バグ修正とともに、防御的なコーディングの改善やユーザー体験改善に役立つようエラーメッセージの調整を確認できます。これらは小さい修正・改善にみえるかもしれませんが、回復力 (resilience) を追加し、状況が悪化したときにユーザーに対し多くの情報を提供することで、ユーザーの利便性が向上し、問題をより迅速に解決できるようになります。
すべてのテスト担当者に多大なる感謝を申し上げたいます。もちろん、テストは終わりのない仕事です!RC2の新しいODPI-Cの機能テストに加え、Node.jsのnode-oracledbとPython cx_Oracleのテスト担当者は、機能テストとストレステストの作成と実行に忙しく取り組んできました(node-oracledbとcx_Oracleの最新バージョンではODPI-Cを使用しています!)が、いい感じです。
ODPI-Cは最初のProductionリリースに向けて進んでいますので、我々のペースにあわせ、皆さんはアプリケーションをテストしまくってください。

ODPI-Cのissueは以下から報告できます。
ODPI-C Issue Tracker
https://github.com/oracle/odpi/issues

[Database] An Easy Way to Get Graph Config in JSON for Oracle Database

原文はこちら。
https://blogs.oracle.com/bigdataspatialgraph/an-easy-way-to-get-graph-config-in-json-for-oracle-database

プロパティグラフ機能を使うにあたり、グラフの設定を正しく実施しておくことが重要です。通常のグラフ設定には、重要な情報(データベース接続情報、グラフ名、読み取り/利用対象のプロパティなど)が含まれています。
簡単なのは、グラフ設定Javaオブジェクトを提供されているJava APIを使って構築することですが、ユーザーがグラフ設定をJSON形式で生成し、Webアプリケーションを使いたいと思うことがあるかもしれません。以下はOracle Databaseのグラフ設定をJSON形式で取得する簡単な方法です。
まず、組み込みのgroovyを起動します。
[oracle@groovy/]$ sh ./gremlin-opg-rdbms.sh 
続いて、Java APIを使ってgraph configを構築します。
opg-oracledb> cfg =  GraphConfigBuilder.forPropertyGraphRdbms().setJdbcUrl("jdbc:oracle:thin:@127.0.0.1:1521:orcl").setUsername("scott").setPassword("<your_password>").setName("my_graph").setMaxNumConnections(2).setLoadEdgeLabel(false).addVertexProperty("name", PropertyType.STRING, "default_name").addEdgeProperty("cost", PropertyType.DOUBLE, "1000000").build();

==>{"max_num_connections":2,"username":"scott","db_engine":"RDBMS","loading":{"load_edge_label":false},"error_handling":{},"edge_props":[{"name":"cost","default":"1000000","type":"double"}],"vertex_props":[{"name":"name","default":"default_name","type":"string"}],"name":"my_graph","jdbc_url":"jdbc:oracle:thin:@127.0.0.1:1521:orcl","attributes":{},"format":"pg","password":"<your_password>"}
これで、JSONベースのgraph configができあがりです。

[Java] How do I find what's getting promoted to my old generation?

原文はこちら。
https://blogs.oracle.com/poonam/how-do-i-find-whats-getting-promoted-to-my-old-generation

「minor/young GCでold generationに昇格しているものを見つける方法は?」という質問はたびたびいただきます。先頃、アプリケーションに対する様々な入力負荷で、old generationへ昇格されるオブジェクトの種類を知りたいというケースがありました。

少し時間がかかり、かつ面倒なやり方は、-XX:+TraceScavengeオプションを使うことです。これはデバッグバージョンにのみ含まれるオプションなので、このオプションを使用するには、HotSpot JVMのデバッグバージョンをビルドする必要があります。このオプションでは冗長な出力が生成され、young generationコレクションで処理されているすべてのオブジェクトをすべてログに記録します。

別の方法もあります。ヒープダンプからこの情報を抽出することができます。-XX:+PrintHeapAtGCオプションを付けて、収集されたヒープ境界情報とペアのminor GCの後に収集されたヒープダンプを使うと、old generationで重なっているオブジェクトを見つけることができます。

では、簡単な例を使ってどうやって実現するのかを見ていきましょう。ちょっとしたJavaプログラムを以下のオプションを付けて実行しました。
java -Xmx100m -XX:NewSize=10m -XX:+PrintGCDetails -XX:+HeapDumpBeforeFullGC -XX:+PrintHeapAtGC MemoryEater
4回のyoung generationのGCの後、old generationが一杯になって、Full GCが呼び出されました。この時点で、ヒープダンプが生成されたので、このヒープダンプを分析し、4回目のminor GCで何がold generationに昇格したのかを分析しましょう。

GCログによると、4回目のGC前後でのヒープの利用状況の詳細は以下の通りです。
{Heap before GC invocations=4 (full 0):
 PSYoungGen      total 17408K, used 17392K [0x00000000fdf00000, 0x0000000100000000, 0x0000000100000000)
  eden space 16384K, 100% used [0x00000000fdf00000,0x00000000fef00000,0x00000000fef00000)
  from space 1024K, 98% used [0x00000000fef00000,0x00000000feffc010,0x00000000ff000000)
  to   space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
 ParOldGen       total 68608K, used 34096K [0x00000000f9c00000, 0x00000000fdf00000, 0x00000000fdf00000)
  object space 68608K, 49% used [0x00000000f9c00000,0x00000000fbd4c000,0x00000000fdf00000)
 Metaspace       used 2612K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 285K, capacity 386K, committed 512K, reserved 1048576K

[GC (Allocation Failure) [PSYoungGen: 17392K->1024K(32768K)] 51488K->52816K(101376K), 0.0101398 secs] [Times: user=0.00 sys=0.00, real=0.00

Heap after GC invocations=4 (full 0):
 PSYoungGen      total 32768K, used 1024K [0x00000000fdf00000, 0x0000000100000000, 0x0000000100000000)
  eden space 31744K, 0% used [0x00000000fdf00000,0x00000000fdf00000,0x00000000ffe00000)
  from space 1024K, 100% used [0x00000000fff00000,0x0000000100000000,0x0000000100000000)
  to   space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)
 ParOldGen       total 68608K, used 51792K [0x00000000f9c00000, 0x00000000fdf00000, 0x00000000fdf00000)
  object space 68608K, 75% used [0x00000000f9c00000,0x00000000fce94050,0x00000000fdf00000)
 Metaspace       used 2612K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 285K, capacity 386K, committed 512K, reserved 1048576K
}

Heap Dump (before full gc): Dumping heap to java_pid31684.hprof ...
ParOldGenの'object space'の使用量の変化に着目してください。

では、Eclipse Memory Analyzer(MAT)でヒープ・ダンプ(java_pid31684.hprof)を開きましょう。でもその前に、MATがヒープダンプをロードする際に 'Keep unreachable objects' (到達不能なオブジェクトを保持)するようにMATを設定する必要があります。こうすることで、現在到達不能になっている可能性があるがJavaヒープに存在するオブジェクトも、ツールで説明および表示します。この設定を有効にするには、Window-> Preferences-> Memory Analyzerを選択します。


MATでヒープダンプを開いた後、ヒープのヒストグラムを確認しましょう。

このヒストグラムから、Javaヒープの中で最も多くの領域をbyte[]が占めていることがわかりますが、これらのbyte[]が存在する世代については何もわかりません。

上記のGCログから、old generationの開始アドレスが 0x00000000f9c00000 だったことがわかります。4回目のminor GCの前に、old generationは 0x00000000fbd4c000 まで使われ、GCの後、old generationは 0x00000000fce94050 に達しています。これはつまり、GC #4で昇格したオブジェクトが0x00000000fbd4c000 から 0x00000000fce94050 のアドレス範囲にコピーされた、ということです。以下のクエリのような式を使って、アドレス幅0x00000000fbd4c000 から 0x00000000fce94050 の範囲でold generationに存在するオブジェクトを確認することができます。
SELECT * FROM INSTANCEOF java.lang.Object t WHERE (toHex(t.@objectAddress) >= "0xfbd4c000" AND toHex(t.@objectAddress) <= "0xfce94050")

フィルタを追加して、特定のタイプのインスタンスの昇格した個数も確認できます。例えば、byte[] のフィルタを付けると、15,407個のbyte[]インスタンスが4回目のminor GCで昇格したことがわかります。

こうした簡単な手順で、old generationに何が存在するのか、young generationのサイズもしくはそれともsurvivor領域を調整し、昇格を避ける、もしくは最小限にする必要があるかどうかという点について、公正な考えを得ることができます。

[Java] HotSpot JVM throwing OOM even when there is memory available

https://blogs.oracle.com/poonam/hotspot-jvm-throwing-oom-even-when-there-is-memory-available-v2

「まだ利用可能なメモリはたんまりあるのに、「Javaアプリケーションでヒープを使い果たすのだけど。」という質問を最近もらいました。質問の詳細は、 「-Xmx1600m を指定してアプリケーションを実行しているんだけれども、ログには1600mbを完全に使っていないのにメモリを使い果たしている、と出ている」というものです。
2017-03-21T13:15:39.478+0000: 289274.599: [Full GC [PSYoungGen: 338944K->0K(425472K)] [ParOldGen: 1092073K->1055276K(1092096K)] 1431017K->1055276K(1517568K) [PSPermGen: 493920K->493889K(494592K)], 1.1709840 secs] [Times: user=5.06 sys=0.00, real=1.18 secs]
...
2017-03-21T13:19:50.517+0000: 289525.638: [Full GC [PSYoungGen: 322035K->0K(364544K)] [ParOldGen: 1092088K->1091814K(1092096K)] 1414124K->1091814K(1456640K) [PSPermGen: 494764K->494163K(495104K)], 2.5423990 secs] [Times: user=15.30 sys=0.00, real=2.54 secs]
ヒープは最大で1517568Kにまで達することがあったり、1456640Kでとどまる時もあります。なぜ`1600mb全てを使わないのでしょうか。
そうですね、端的に言うと、説明されていない領域がSurvivor領域の一つにあるということです。
説明を加えた答えは、Young世代はEdenと2個のSurvivor領域、FromとToから構成されています。これらのうち、EdenとFrom領域からのみメモリ割り当てが可能です。Toは生存オブジェクトをコピーするために使えるよう余裕を残してあって、Young世代のキャパシティをレポートする場合に省略されます。

では別の例を見てみましょう。ここでは、たくさんの領域を割当て、Javaのヒープを使い果たすようなシンプルなプログラムを実行します。以下のオプションを付けてこのプログラムを実行します。
java -XX:+PrintGCDetails -Xmx60m -XX:MaxNewSize=20m TestProgram
......
[Full GC (Ergonomics) [PSYoungGen: 15360K->15360K(17920K)] [ParOldGen: 40464K->40464K(40960K)] 55824K->55824K(58880K), [Metaspace: 2723K->2723K(1056768K)], 0.1519409 secs] [Times: user=0.50 sys=0.00, real=0.15 secs]
[Full GC (Ergonomics) [PSYoungGen: 15360K->15360K(17920K)] [ParOldGen: 40465K->40465K(40960K)] 55825K->55825K(58880K), [Metaspace: 2723K->2723K(1056768K)], 0.1196922 secs] [Times: user=0.41 sys=0.00, real=0.12 secs]
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
        at TestProgram.main(TestProgram.java:15)[Full GC (Ergonomics) [PSYoungGen: 15360K->0K(17920K)] [ParOldGen: 40468K->324K(30720K)] 55828K->324K(48640K), [Metaspace: 2748K->2748K(1056768K)], 0.0072977 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
ヒープサイズを60MBとして構成しましたが、トータルのJavaヒープのキャパシティは、上記ログを見ると58880Kしかありません(YoungGen:17920K + OldGen:40960K = Total:58880K)。60*1024K-58880K = 2560K分はどこにいったのでしょう。

では、ヒープ利用の詳細を見てみましょう。
Heap
 PSYoungGen      total 17920K, used 307K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
  eden space 15360K, 2% used [0x00000000fec00000,0x00000000fec4ce70,0x00000000ffb00000)
  from space 2560K, 0% used [0x00000000ffb00000,0x00000000ffb00000,0x00000000ffd80000)
  to   space 2560K, 0% used [0x00000000ffd80000,0x00000000ffd80000,0x0000000100000000)
 ParOldGen       total 30720K, used 324K [0x00000000fc400000, 0x00000000fe200000, 0x00000000fec00000)
  object space 30720K, 1% used [0x00000000fc400000,0x00000000fc4511e0,0x00000000fe200000)
 Metaspace       used 2755K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 301K, capacity 386K, committed 512K, reserved 1048576K 
Capacity of PSYoungGen:17920K = eden:15360K + from:2560K
ToのSurvivor領域が含まれていないことがわかりますね。

[WLS] Using REST to Create an AGL Data Source

原文はこちら。
https://blogs.oracle.com/weblogicserver/using-rest-to-create-an-agl-data-source

最近お客様から尋ねられる質問は、Active GridLink (AGL) データソースをWebLogic ServerのRESTful APIを使って作成する方法です。
まず、WebLogic Server 12.1.3で提供されるAPIでは作成できません。WebLogic Server 12.2.1で提供を開始した新しいAPIだと、ずっと完全な機能を提供しています。これらのAPIはManaged Beansをミラーしており、WLSTを使うかのように利用できます。
下記のShell ScriptはActive GridLinkデータソースを最小限のパラメータで作成するもので、必要に応じてパラメータを追加できます。その他注意点は以下の通りです。
  • WebLogic Server 12.2.1で新たに登場したデータソースタイプを明示的に指定しています。
  • AGLの場合長形式のURLを使う必要があります。
  • test-connections-on-reserve(予約時の接続のテスト)で利用するために"ISVALID"を使うSQLクエリを設定することを推奨します。
  • 自動ONSを使ってONSノードリストを指定しない前提にしています。
  • FAN-enabled(FANの有効化)を明示的に指定する必要があります。
host=localhost
port=7001
user=weblogic
passwd=welcome1
editurl=http://${host}:${port}/management/weblogic/latest/edit
c="curl -v --user ${user}:${pass} -H X-Requested-By:MyClient -H Accept:application/json -H Content-Type:application/json"
name="JDBCGridLinkDataSource"
$c -d "{}" -X POST "${editurl}/changeManager/startEdit"
$c -d "{
    'name': '${name}',
    'targets': [ { identity: [ 'servers', 'myserver' ] } ],
}" \
-X POST "${editurl}/JDBCSystemResources?saveChanges=false"
$c -d "{
    'name': '${name}',
    'datasourceType': 'AGL',
}" \
-X POST "${editurl}/JDBCSystemResources/${name}/JDBCResource"
$c -d "{
        'JNDINames': [ 'jndiName' ]
}" \
-X POST "${editurl}/JDBCSystemResources/${name}/JDBCResource/JDBCDataSourceParams"
$c -d "{
        'password': 'dbpassword',
        'driverName': 'oracle.jdbc.OracleDriver',
        'url':  'jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=dbhost)(PORT=dbport))(CONNECT_DATA=(SERVICE_NAME=dbservice)))',
}" \
-X POST "${editurl}/JDBCSystemResources/${name}/JDBCResource/JDBCDriverParams"
$c -d "{
        name: 'user',
        value: 'dbuser'
}" \
-X POST "${editurl}/JDBCSystemResources/${name}/JDBCResource/JDBCDriverParams/properties/properties"
$c -d "{
        'testTableName': 'SQL ISVALID'
}" \
-X POST "${editurl}/JDBCSystemResources/${name}/JDBCResource/JDBCConnectionPoolParams"
$c -d "{
        "fanEnabled":true,
        "testConnectionsOnReserve":true
}" \
-X POST "${editurl}/JDBCSystemResources/${name}/JDBCResource/JDBCOracleParams"

$c -d "{}" \
 -X POST "${editurl}/changeManager/activate"
(訳注)
上記設定例は最小限のパラメータを使ったActive GridLinkデータソースの作成方法ですが、実際には以下のように設定を追加・変更されることを推奨します。

  1. test-connections-on-reserve(予約時の接続のテスト)で、原文ではISVALIDを使うように記載していますが、DUAL表を使う方法でも可です(以前のWebLogic Serverでは実際にDUAL表へのアクセスが設定されていました)
  2. {URL}/JDBCSystemResources/${name}/JDBCResource/JDBCConnectionPoolParams へのPOSTでは、最小・最大接続数の指定のみならず、testConnectionsOnReserveを明示的にTrueにすることを推奨します(@yamadamnさんありがとうございます)。

[Cloud, Integration] Registries: Use Cases for API Management and Microservices

原文はこちら。
http://www.oracle.com/technetwork/articles/soa/wilkins-api-mgmt-3796702.html

マイクロサービスと新しい第3世代API Managementのケイパビリティは、技術者にとって非常に自然なものです。(マイクロ)サービスが1つの機能のための実行ロジックを提供し、第3世代API Managementは、各サービス、潜在的に(マイクロ)サービス間での外部への公開を制御する手段を提供します。Luis Weirの3rd-Generation API Managementの記事では、API Management機能の進化と、第3世代API ManagementがどのようにAPI Managementを(マイクロ)サービスとうまくかみ合うのかを説明しています。
3rd-Generation API Management: From Proxies to Micro-Gateways
http://www.oracle.com/technetwork/articles/soa/weir-3rd-gen-api-mgmt-3787102.html
https://orablogs-jp.blogspot.jp/2017/07/3rd-generation-api-management-from.html
この記事では、(マイクロ)サービス環境におけるレジストリの役割、そして最終的にはAPI Managementとの関係について見ていきます。具体的なソリューションについて深く掘り下げることはしませんが、よく知られているレジストリのいくつかを参照し、さらに深く掘り下げていくためのリンクを提供します。
マイクロサービスを(マイクロ)サービスと呼んでいることにお気づきかと思います。これは非常に熟考した結果で、論争が起こる可能性があります。マイクロサービスは通常、DockerやTomcatなどの軽量アプリケーションコンテナなどの特定のテクノロジーに関連付けられていますが、マイクロサービスの純粋主義者であれば、(SOAの場合と同様に)テクノロジーではなく、設計のパラダイムと原則について考える必要があります。幸運にも非常に見識があるサービス組織や、ただ幸運なサービス組織で働いていない場合、必要な意思決定と制約はすなわち実用的な決定をする必要があるため、こうした観点を持ちながら取り組まなければならないことが多々あります。WebLogicのライセンスに多額の投資をした組織にとって、その投資をあきらめるというのは穏やかな話ではありませんが、このことがすなわちマイクロサービスアプローチを採用できないことを意味してるわけではありません。とはいえ、(マイクロ)サービスアーキテクチャを採用する場合に、WebLogicを利用することで発生しうるリスクを軽減する必要があります。第2に、レジストリの概念はマイクロサービスに固有のものではありません。実際、これらのソリューションの中には、例えばBig Data/Hadoopなどのソリューションに由来するものがあります。
Gartnerはマイクロサービスの観点でミニアプリまたはマイクロアプリについて話を始めており、これは私の伝えたい点を強調するものです。この本質はマイクロサービスの原則のより実用的な適用方法です。すべての組織が(NetflixやUberといった)マイクロサービスのポスターチャイルドたちのように、ハイパースケールやsuper elasticityを必要としているわけではありませんが、サービスのアドレス指定を容易に管理できる手段が必要です。
レジストリの役割を理解するためには、一歩戻ってマイクロサービスを支える思想を理解する必要があります。 そんなわけで、まとめてみましょう。
  • スケールとElasticity。つまり、マイクロサービスは機能の小さなピースであるため、そのサービスだけのための環境で要求を満たすためのサービスインスタンスの追加が簡単である必要があります。スケールには、インスタンス数の削減が含まれる場合があります。
  • ソリューションは多くのデプロイ済みマイクロサービスから構成されるため、どのピースもサービスコントラクトを超えて別のサービスの存在を想定するべきではありません。ピースが離散的にデプロイされているため、別のサービスの物理的な存在場所はわかりません。この分離があることで、ソリューション全体をモノリスにデプロイするのではなく、サービスの変更や追加、デプロイを独立して実施することができます。
まず第一に、この2点からだけでも、暗黙的であれ明示的であれ、サービス・インスタンスの場所を知る必要があることがわかりますし、利用可能なキャパシティを把握するためにも、インスタンスの個数を知る必要があります。さらに、ロードバランサが必要です。マイクロサービスは独立してデプロイされるため、ロードバランサが確認可能な全てのサーバの同じポートでマイクロサービスが実行されていない可能性をあることを心に留めておくことが重要です。(もちろん)全てのサーバでマイクロサービスが同じポートで動作するようにデプロイできますが、その場合、実質的にすべてのサービスをモノリスとして扱うことになります。それではロードバランサとルーティングの問題に戻りましょう。
レジストリの役割は、名前が示すように、どのサービスがどこに存在するかといった登録情報を保持することです。新しいマイクロサービスが起動すると、最初のアクションの1つは、レジストリにその存在を宣言することです。この後、各サービスはレジストリと連携して、シャットダウン時または予期せず終了した時に、確実にレジストリが検出するようにする必要があります。
wilkins-api-mgmt-fig001
この図から、次の2個の疑問が湧いてきます。
  1. レジストリはSPOF(単一障害点)にならないのか?
  2. レジストリの場所を知る方法は?
最も好ましくないのは、我々が達成しようとしている目標を損なう可能性のある、レジストリが単一障害点になることですが、幸運なことに、利用可能なすべてのレジストリには、情報を共同して共有する手段が組み込まれています。さまざまなレジストリ実装で採用されているいくつかの共通戦略があります。
マイクロサービスが事前定義済みアドレス(理想的にはDNSベースまたは仮想IP)のリストを持つ場合、2点目は対処できます。つまり、マイクロサービスはそのリストを使って動作し、応答するまでレジストリへの接続を試行します。この連携ノード探索モデルはかなり一般的で、例えばActiveMQメッセージブローカでは、クラスタ内で動作する場合にこのようにしています。最後の方法は、通信を開始するという点で、ネットワークブロードキャストを使用することです。多くのサービスが開始されると、多くのネットワークトラフィックが発生する可能性があるため、この方法はイケていませんが、CORBAブローカの中にはこのアプローチを採用していたものがあります。
ここまでで、自身をレジストリに登録し、存在を維持する方法がわかりましたが、これでは問題の半分が解決したに過ぎません。実際には、この情報の利用方法を理解し、全てのワークロードがすべてのインスタンスに分散され、マイクロサービスがワークロードを実際にマイクロサービスが存在する場所にネットワークインフラストラクチャがルーティングする必要があります。レジストリの使用にあたり2つのコアモデルがあります。
  1. クライアントサイド・レジストリの場合、マイクロサービスがレジストリのことを知っていて、インスタンスを見つけて呼び出し、必要なサービスのアドレスを取得します。
    クライアントはしばらくの間、参照をキャッシュできます。これはもちろん、インスタンス間のロードバランシングが問題になる可能性があり、新しいサービスインスタンスを起動するだけですぐに負荷が分散されるわけではありません。この方法のよい点は、グローバルな分散シナリオでは、DNSの操作をせずに、最も近い場所でマイクロサービスをすぐにインスタンス化する方法を見つける可能性が高いということです。このモデルは、EurekaフレームワークでNetflixがサポートしています。
wilkins-api-mgmt-fig003
  1. 続いて、サーバサイド・レジストリの場合、これらのレジストリは通常ロードバランサやその他のネットワーク基盤の背後に隠れています。このレジストリはロードバランサと関係があります。
    1. レジストリがロードバランサにマイクロサービスの場所を伝え、最善の方法で負荷分散するようロードバランサを構成します。
    2. ロードバランサは黙ってレジストリを呼び出し、特定のサービスで使用するアドレスを要求します。
      このサーバーサイド・アプローチは多くの点でマイクロサービスの道理を反映しています。つまり、1つだけをうまくやる、というものです。ロードバランサはロードバランシングを行い、レジストリは単に登録情報を管理し、マイクロサービスは要求がどのように処理されるかはまったく気にしません。それは別のマイクロサービスがやるのか、モノリスがやるのかも気にしません。
      この方法はパフォーマンスの低下を犠牲にしており、その実現は特定の製品(NetScalerやF5 BigIPなど)に依存しています。
wilkins-api-mgmt-fig005
全くの新規構築で、レガシーなモノリスを取り扱う必要がない場合や、ネットワークインフラストラクチャではなくアプリケーションドメイン内でルーティング管理を維持したい場合は、クライアントサイド・モデルが理想的です。マイクロサービスがモノリスとなる可能性のある他の要素と混在する場合や、最適なルーティングを実現するためにDNSなどのネットワークインフラストラクチャ要素を活用したい場合は、サーバ・サイド・モデルのほうがよいかもしれません。DNSとネットワークルーティングによって違いを隠蔽することができます。しかし、代替オプションがあります。それは、モノリスのエンドポイントを登録し、モノリスのハートビートを偽装するプロキシコンポーネントを立てるというものです(下図)。
wilkins-api-mgmt-fig007
クライアントサイド・モデルの場合、ロードバランシングをゲートウェイと組み合わせる必要があるため、SkyDNSやEurekaなどのソリューションが実質的にAPIロードバランサになりました(以後の進化と区別するため、このモデルを第1世代と呼んでいます)。
これまでは、厳密に管理された、あるいは閉鎖されたマイクロサービスのエコシステム、つまりアクセス管理、スロットリング、セキュリティ、収益化などに焦点を当てる必要のない環境だけを考慮してきましたが、こうした点が課題になると、すぐにファイアウォールまたはそれ以上のAPIゲートウェイを導入する必要があります。
APIゲートウェイでクライアントサイド・レジストリ・モデルを採用する場合、ゲートウェイの配置方法を非常に慎重に検討する必要があります。さもないと、サービスが簡単にゲートウェイの無視や、ゲートウェイのバイパスが簡単にできてしまうからです。これは、次の図に示すように、実行状況の把握および管理の観点でゲートウェイが提供するメリットが失われる可能性があることを意味します。
wilkins-api-mgmt-fig009
サーバーサイド・レジストリの場合、よりシンプルになります。下図のように、ゲートウェイはロードバランサのそばにあればいいのです。
wilkins-api-mgmt-fig011
これにより、第2世代のAPIロードバランサと言えるものに到達しました。このアプローチでは、ロード・バランシングとレジストリを単一のコンポーネントだけでなく、ゲートウェイの特性もマージするという考え方が採用されています。これは、ネットワークインフラストラクチャソリューションの進化と似ています。これはかつてはファイアウォールまたはロードバランサのいずれかでしたが、現在は複合ソリューション(Composite Solution)です。
レジストリやロードバランサとゲートウェイ間の通信にかかるパフォーマンスコストのオーバーヘッドがなくなり、環境はマイクロサービスの観点で非常に簡単になります。
実際のところ、第2世代のAPIロードバランサとして説明したものは、この記事の冒頭で触れたLuis Weirの記事にあるように、実は第3世代のAPI管理ソリューションの一部です。
wilkins-api-mgmt-fig013
いくつかの議論でこのアプローチに楯突いてくることがあります。
  • 「ハイブリッドソリューションは、(サービスは一つだけを実施し、それをうまくやるべき、という点に反する、という意味で)最高のレジストリソリューションや最高のロードバランサを得る可能性が低い」と、マイクロサービス純真主義者たちは異議を唱える可能性があります。ハイブリッド・ソリューションには、よいロードバランサ(F5 BigIPやNetScalerのことを思い出してください)の洗練性や、レジストリのシンプルさ、議論の余地はあるかもしれませんがレジストリの信頼性がほぼないためです。
  • レジストリは、純粋なロードバランサよりもかなり重い(したがってスループットが低い)と主張してくる可能性もあります。
このソリューションが組織の主要なIP(知的財産)になるか、またはジャイアントキラー製品やオープンソースフレームワークを使用して市場に参入しない限り、NetScalerとF5キットの最適化を上回ることはうまくいかないでしょう。しかし、いくつかの領域でオーバーヘッドを取り除くことで、うまくいく可能性があります。以下の点を検討してください。
  • マイクロサービスはレジストリとの通信のオーバーヘッドがない
  • サービスからサービスへのコールがAPIロードバランサ(API Manager)を経由するため、ハートビートのオーバーヘッドを削減する。サービスからの応答を受信するたびにハートビートのクロックをリセットできる。
  • ロードバランサとレジストリ間の調整はインメモリでのアクティビティで、負荷分散が回復するにつれて、レジストリは本質的に復元する。
  • ロードバランサの高性能メカニズムは、レジストリロジックによって悪用される可能性がある。さらに、起動時、終了時にAPIロードバランサに信号を送るだけで済む(別のAPIを呼び出すことはWebのアドレスを呼び出すようなものである)ため、サービスは(特にクライアントサイドでの)フレームワークをあまり必要としない。
スループットについて言えば、潜在的なコストはありますが、ゲートウェイ機能がポリシー駆動型で、コストがポリシーの複雑さと同じくらい高く、APIへの外部呼び出しのポリシーと内部APIのポリシーを分離できる場合、一方ではセキュリティにより敏感に、他方はそうでないように負荷を調整することができます。
では、第2世代のAPIロードバランサが良いアイデアなら、なぜそれはまだ存在しないのでしょうか?私たちの答えは、ゲートウェイがまだ成熟の途上であるという事実に行き着きます。ゲートウェイソリューションの中には軽量ESBに移行しているものがあります(私は以前に概説された議論に同意します)し、これはThoughtWorks Tech Radarのポジションに反映されています。
Overambitious API gateways (ThoughtWorks TECHNOLOGY RADER)
https://www.thoughtworks.com/radar/platforms/overambitious-api-gateways
しかし、このようなニーズの方向に向かう構想が確認されています。レジストリから見えるAPIの作成を簡単にするためのFeignのメカニズムを考えてください。APIの第4世代(全てがAPI)に向かうにつれ、その時点ではAPIが普及しているため、第2世代のAPIロードバランサの必要性が高まるでしょう。別の見方をすれば、第3世代のAPI Managementはその中に負荷分散機能を取り込んでいます。

Conclusion

Oracle PaaSの中でもAPI Platform Cloud Serviceはまだ若いサービスゆえに、主要な要求を反映する機能の提供が継続中です。しかし、API Platform Cloud ServiceにはSDKを使って機能を提供する手段がありますし、API Platformのゲートウェイエンジン部分は非常にスケーラブルであるとともに、通信業界由来の基礎部分を有しているため、本質的に高パフォーマンスです。OracleのApplication Container Cloudは現時点で、第1世代のAPIロードバランサ機能をそのプラットフォーム内に有していますが、将来主要な差別化要因として第2世代モデルを採用する可能性があるでしょう。別の可能性として、お客様が両サービスを採用する場合には、ACCSは負荷分散機能を持つAPI Platform Cloud Serviceを利用するように切り替えることができるようになるかもしれません。

References:

About the Author

Oracle ACE AssociateのPhil WilkinsはiPaaS、ミドルウェアやOracleテクノロジーを専門とするCapgeminiのSenior Consultantで、Implementing Oracle Integration Cloud Service (2017, Packt) の共著者であり、OTNやUKOUG Oracle Scene、その他の出版物に対して多数寄稿している。

[Java] Get Ready for Java 9

原文はこちら。
https://blogs.oracle.com/java/get-ready-jdk9

Java 9は、今日のモノリスなJava SEプラットフォームから離れ、モジュラーシステムを導入します。下位互換性は主要な優先事項の1つであり、OracleエンジニアリングチームはJava 9へのスムーズな移行に取り組んできましたが、以下に示す、理解する必要がある重要な変更がいくつかあります。この情報を知っておくと、Java 9リリースへの準備にも役立ちます。
JDK 9
http://openjdk.java.net/projects/jdk9/
一般的な互換性ポリシーによれば、サポートされているAPIを事前の通知で削除できます。JEP 277(Enhanced Deprecation)では、通知のプロセス、APIの状態と意図された取り扱い、およびアプリケーションにおける非推奨APIの静的使用分析ツールについて説明しています。
JEP 277: Enhanced Deprecation
http://openjdk.java.net/jeps/277
JEP 260(Encapsulate Most Internal APIs)では、ほとんどのInternal APIはデフォルトでアクセスできないものの、いくつかの重要かつ幅広く使われているInternal APIは、当該APIの機能の全てもしくはそのほとんどに対応するサポート対象の代替APIができるまではアクセスできます。
JEP 260: Encapsulate Most Internal APIs
http://openjdk.java.net/jeps/260
一般的なルールとして、サポートされていないAPI(ほとんどの場合、sun.misc.Unsafeのようなsun.* API)を使うべきではありません。こうしたAPIはOracle JDKチームが利用するためのものです。Mark Reinholdが以下の動画(JVM Language Summit 2015)でsun.misc.Unsafeについて説明しています。

以下の重要なInternal APIがJDK 9でもアクセス可能にするよう提案されています。
  • sun.misc.{Signal,SignalHandler}
  • sun.misc.Unsafe (このクラスのメソッドの多くの機能はJEP 193(Variable Handles)で利用可能)
  • sun.reflect.Reflection::getCallerClass(int) (このメソッドの機能はJEP 259(Stack-Walking API)で標準的な形で提供される可能性がある)
  • sun.reflect.ReflectionFactory.newConstructorForSerialization
上記の重要なInternal APIは、jdk.unsupportedという名前のJDK固有のモジュールに配置され、パッケージがエクスポート(公開)されます。詳細はJEP 260をご覧ください。
JEP 260: Encapsulate Most Internal APIs
http://openjdk.java.net/jeps/260
プログラムでどのJDK Internal APIを使用しているかどうかを知るにはどうすればよいでしょうか。ソースコードにアクセスできる場合は、ソースコード内のパッケージ名からそれらのAPIを識別できます。場合によっては、これらのAPIの1つに依存するサードパーティライブラリを使用している可能性があるため、これは難題です。これらのAPIを特定するには、JDK 8で導入されたjdeps(Java依存性分析ツール)を使用できます。
Java Dependency Analysis Tool
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
JDK 9の早期アクセスリリースで使用できるJdepsの改良バージョンを使用する必要があります。Maven用のプラグインもあります。

jdepsコマンドを使うと、Javaクラスファイルのパッケージレベルもしくはクラスレベルの依存性がわかります。入力クラスが.classファイルへのパス名、ディレクトリ、JARファイル、もしくは全てのクラスファイルへの完全修飾クラス名にすることができます。

デフォルトで、-classpath オプションと入力ファイルで指定された全てのクラスを分析します。-jdkinternalsを使って、internal APIにフラグを立てる必要があります。詳しくは、jdepsのメインページをご覧ください。
jdeps
http://docs.oracle.com/javase/8/docs/technotes/tools/unix/jdeps.html
ツールを使うと、変更すべきJDK internal APIだけでなく、利用可能であれば置換先の提示もしてくれます。JDK internal APIの置き換え先の全リストは以下のURLからご覧いただけます。
Java Dependency Analysis Tool
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
Key links:

[Java] Looking at JDK 9 with Categories

原文はこちら。
https://blogs.oracle.com/java/jdk-9-categories

JDK 9での変更を探す上で役立つよう、新機能を6個のカテゴリに分類できます。これらのカテゴリ分けで、新機能、コードやプロセスの変更が必要なもの、JDK 9でデフォルトになっているもの、機能改善されたAPI、削除されたものを理解しやすくなっています。新機能はJDK 9早期アクセス版でお使いいただけます。すぐにダウンロードして機能をテストできます。
JDK 9 Early-Access Builds
http://jdk9.java.net/download
カテゴリを以下のように明確に定義しています。
  • Behind the scenes:
    JDK 9でデフォルトの機能。コードの変更や新しいツールの利用は不要。JDK 9でのみ動作。
  • New functionality:
    コードの変更や新しいツールを使って入手する必要のある機能。
  • Specialized:
    変更が必要な新機能。これらのAPIは非常に高度なユースケースのためのもの。
  • New standards:
    JDK 9で新しい業界標準を使うもの。
  • Housekeeping:
    既存ライブラリへの改善や内部コードの変更、将来の改善のための作業に関するもの。
  • Gone:
    JDK 8では利用可能な機能でも、JDK 9では利用できなくなるもの。
全機能のリストはJDK 9のWebサイトにあります。
JDK 9
http://openjdk.java.net/projects/jdk9/
以下に開発者として知っておいて欲しいライブラリを列挙しています。このページの下にある図もご覧ください。

Behind the scene
New Standards
New Functionality
Housekeeping
Specialized
New Standards

[Java] New Java Magazine Issue: Inside Java 9

原文はこちら。
https://blogs.oracle.com/java/java-magazine-inside-java-9

このJava Magazineの最新号では、トピックは1個だけ、つまり新しいJDK 9での、Java Platform Module System (JPMS、Project Jigsaw)以外のメリットを特集しています。
Java Magazine, July/August 2017
http://www.javamagazine.mozaicreader.com/JulyAug2017#&pageSet=0&page=0&contentItem=0
Java Magazineは次の号でもJava 9の、特に新しいモジュールアーキテクチャとそのベストな使い方を特集する予定です。

今号の記事で説明しているように、モジュール以外にJava 9にはたくさんの利点があります。language and platformチームが数多くの便利な新機能を作成しました。これらはJavaプログラミングをより簡潔かつ楽しいものにします。Simon Ritterの記事(p.11)では、こうした多くの有用な追加機能の概要を紹介しています。
Nine New Developer Features in JDK 9
http://www.javamagazine.mozaicreader.com/JulyAug2017#&pageSet=11&page=0&contentItem=0
彼の記事はCollections、Streams、iteratorsの新機能の詳細な検討(21ページ)によって補完されています。
Java 9 Core Library Updates : Collections and Streams
http://www.javamagazine.mozaicreader.com/JulyAug2017#&pageSet=21&page=0&contentItem=0
Trisha Geeは、モジュールを使っていない場合に、Java 8のコードをJava 9でコンパイルし実行する方法を説明しています(p.17)。
Migrating from Java 8 to Java 9
http://www.javamagazine.mozaicreader.com/JulyAug2017#&pageSet=17&page=0&contentItem=0
Java 9のコードを実行する方法として、もう一つ、このリリースにバンドルされている、JShellという新しいREPL(read-evaluate-print loop)の利用があります。JShellの入門記事で基礎部分を説明しています(p.28)。
JShell: Read-Evaluate-Print Loop for the Java Platform
http://www.javamagazine.mozaicreader.com/JulyAug2017#&pageSet=28&page=0&contentItem=0
さらに、HTTP/2に関する記事(p.39)ではJShellの使い方の別の例を紹介しています。HTTP/2テクノロジーはネットワークプログラミングを簡単にしてくれるもので、これはJava 9で導入された新たなインキュベータ・システムの一つであり、将来のリリースでバンドルされる可能性のあるテクノロジを開発者に提供します。HTTPを普段からお使いの場合は、この記事を詳しくご覧ください。
Working with the New HTTP/2 Client
http://www.javamagazine.mozaicreader.com/JulyAug2017#&pageSet=39&page=0
(訳注)
上記記事のコードをそっくりそのままJShellに入力するとエラーが出ます。例えば、p.40のコードは以下のようになっていますが、これだと先頭に.が入っていて、JShellが前の行で文が終わると判断してしまうからです(もちろんJShellを使わない場合は問題ありません)。
HttpClient client = HttpClient.newBuilder()
    .followRedirects(HttpClient.Redirect.ALWAYS)
    .build();
System.out.println(client.version());
URI uri = new URI("http://www.oracle.com");
HttpRequest request = HttpRequest
    .newBuilder()
    .uri(uri)
    .GET()
    .build(); 
もしJShellで写経される場合には、以下のように、行末に.をおいてください。
HttpClient client = HttpClient.newBuilder().
    followRedirects(HttpClient.Redirect.ALWAYS).
    build();
System.out.println(client.version());
URI uri = new URI("http://www.oracle.com");
HttpRequest request = HttpRequest.
    newBuilder().
    uri(uri).
    GET().
    build();
NashornはJDKの組み込みのJavaScriptエンジンです(p.34)。
Nashorn JavaScript Engine in JDK 9
http://www.javamagazine.mozaicreader.com/JulyAug2017/Twitter#&pageSet=34&page=0&contentItem=0
Nashornは、JavaScriptとJavaをシームレスに実行することを主目的としています。Java 9では、ほとんどのECMAScript 6の機能をサポートします。

こうした記事の他にも、いつものLanguageクイズやイベントカレンダー、編集者への手紙があります。

[Cloud] Oracle Application Container Cloud ServiceでJava SE 9やJava EE 7が利用可能に

タイトルのまんまなのですが、先頃の更新で、Oracle Application Container Cloud Serviceでご利用いただけるプラットフォームにJava EE 7が追加されました。


で、Java EEを選ぶと、Java EE 7のアプリケーションをデプロイ・実行できるようです。


Java SEを選ぶと、こちらではJava SEのバージョンで7、8だけでなく9も選ぶことができます(当然ですが、Java SE 9はEarly Accessです)。

[Java] JDK 8u141, 7u151, and 6u161 Released!

四半期毎のCritical Patch Updateの一環で、JDK 8u141、7u151、6u161がご利用いただけるようになりました。最新のJDKリリースはJava SEダウンロードのページからダウンロードできます(訳注:7u151、6u161はサポート契約されている方のみご利用いただけます)。
Java SE Downloads
http://www.oracle.com/technetwork/java/javase/downloads/index.html
機能情報やこれらのリリースに含まれる修正に関する情報は、以下のリリースノートをご覧ください。

[Cloud, Integration] 3rd-Generation API Management: From Proxies to Micro-Gateways

原文はこちら。
http://www.oracle.com/technetwork/articles/soa/weir-3rd-gen-api-mgmt-3787102.html

今日、digital disruptorsに支配された市場で競争力を維持するためには、革新し、ビジネスの機敏性とスピードを向上させる必要があります。
Who are the digital disruptors redefining entire industries? (2015, TechRadar)
http://www.techradar.com/news/world-of-tech/who-are-the-digital-disruptors-redefining-entire-industries-1298171
このため、あらゆる規模の組織は、TCOを削減する手段としてだけでなく、digital transformationと顧客中心主義を実現する手段としてクラウド(SaaS、PaaS、IaaS)を採用しています。
The NIST Definition of Cloud Computing(2011, National Institute of Standards and Technology)
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf 
しかしながら、クラウドへの移行は1つのクラウドを意味しません。調査から、組織は全てを一つのクラウドベンダーに任せるのではなく、マルチクラウド戦略を選択していることが透けて見えます。
The future isn't cloud. It's multi-cloud (2017, Network World)
http://www.networkworld.com/article/3165326/cloud-computing/the-future-isnt-cloud-its-multi-cloud.html
クラウドの採用に対するこのbest-of-breedアプローチは、ERPのようなオンプレミスのモノリシックシステムやその他のオンプレミスアプリケーションを、個別のSaaSアプリケーションやPaaSと統合もしくはPaaSで拡張されたものとして、クラウドで再実装することを意味します。
Definition: monolithic architecture (TechTarget WhatIs)
http://whatis.techtarget.com/definition/monolithic-architecture
Figure 1 - Cloud transformation
クラウドに同等のものがないか、または単に要件を満たしていないオンプレミスアプリケーションの場合、多くの組織ではクラウドでのアプリケーション開発も選択しています。
Developing cloud applications in the new IT era (TechTarget)
http://searchcloudcomputing.techtarget.com/essentialguide/Developing-cloud-applications-in-the-new-IT-era
マイクロサービス・アーキテクチャがクラウド・ネイティブアプリケーション実装のためのアーキテクチャスタイルとして優勢になってきましたが、こうするために、モノリスをより小さなピースに分割して各々のピースがbusiness capabilityを表すようにした上で、完全に疎結合なサービス(マイクロサービス)として実装します。この実装は通常PaaSで実施します。
A Word About Microservice Architectures and SOA (SOA4U Tech Blog)
http://www.soa4u.co.uk/2015/04/a-word-about-microservice-architectures.html
Open Modern Software Architecture (OMESA) GitHub Repository
http://omesa.io/
weir-3rd-gen-api-mgmt-fig02
Figure 2 - Cloud native application development
クラウドの採用が進むにつれて、(異なるベンダーの)さまざまなSaaSやPaaSアプリケーションだけでなく、多くのオンプレミスのシステム全体で情報が必然的にますます統合されるようになります。
digital transformationを実現するためには、まず既存の(オンプレミス)ITシステムを調整または強化するか(おそらくはクラウドで)モダンなITシステムに置き換えようと試みる必要があります。そうすることで、製品とサービスを複数のチャネル(ウェブ、モバイルアプリ、キオスク、パートナーのオンラインストア、ボットなど)でデジタルの形で提供できます。
Digital transformationの結果、異なるデバイスとのやりとりによって提供されるシームレスなつながりを通じて、ビジネスプロセスを実行できるようになり、労働者の生産性を高めます。
また、関連するビジネスデータへのオンデマンドアクセスを提供し、ビジネストランザクションを電子的に実行する手段を提供することによって、組織のパートナーエコシステムを強化します。
しかし、中核となるビジネス情報資産へのアクセスが利用できなければ上記の事柄は実現できませんし、その状態で情報が統合されると、アクセスが大きな問題になる可能性があります。
Integration platform as a service (iPaaS)ソリューションがこの問題に対処します。
iPaaS. What is it exactly? is it on-premise software running on IaaS? (SOA4U Tech Blog)
http://www.soa4u.co.uk/2017/03/ipaas-what-is-it-exactly-is-it-on.html
iPaaSのセールスポイントは、クラウドおよび/またはオンプレミスのシステムに接続し、必要なアクセスを提供できるという点です。堅牢なiPaaSプラットフォームは、RESTfulアプリケーションプログラミングインターフェイス(別名Web API)を使って情報へのシームレスなアクセスを提供するために、クラウドおよび/またはオンプレミスアプリケーションに接続できる必要があります。
Representational state transfer (REST) (Wikipedia)
https://en.wikipedia.org/wiki/Representational_state_transfer
情報への標準的で一貫した安全なアクセスを提供する手段としてのAPIの使用により、マルチチャネルアプリケーションは必要なときに必要な資産を利用できます。
Figure 3 - iPaaS solution with API management capabilities
しかし、iPaaSソリューションが堅牢な第3世代のAPIプラットフォーム機能を提供しない限り、前述のニーズに対処するのは難しいでしょう。APIはできるだけ情報源に近くあるべきで、そうでなければ、ネットワークの待ち時間や他のネットワークの問題(予期しない停止など)に起因し、遅延応答などの問題が発生する可能性があります。情報が複数のクラウドとオンプレミスシステムに分散されている場合は、APIが必須です。

3rd-Generation API Platform

クラウドが採用され、情報が地理的に分散するにつれて、アクセスがますます重要になります。 接続性を提供するVPNを確立することは、早晩実現困難になります。SaaSベンダーはデータベースへの直接アクセスを提供しないため、多くの場合、問題を解決できないからです。代わりに、情報にアクセスするための唯一の手段としてAPIが提供されます。
現時点では、第2世代のAPIプラットフォーム(基本的にESBやAPI管理機能を強化したXMLアプライアンス)では能力不足で、クラウドの採用とdigital transformationから生じる最新の要件を満たすことは難しいのです。
weir-3rd-gen-api-mgmt-fig04
Figure 4 - 3rd-generation APIs everywhere
Figure 4で記載しているように、クラウドの採用とdigital transformationのイニシアチブが成功するために必要な機能を提供するために、より洗練された第3世代のAPIプラットフォームが必要です。これは、モノリシックアーキテクチャという技術的な荷物を持たず、以下の要素を備えています。

  • うんざりするようなオペレーションや膨大なコストをかけずに、(任意のベンダーのクラウドやオンプレミスでも)APIを実装できる
  • 開発者コ​​ミュニティに、セルフサービスの開発者ポータルを介してAPIを発見して利用登録させることができる
  • エンドツーエンドのAPI開発ライフサイクルとAPI-firstのためのシームレスなツールを提供するため、開発者はAPIの設計、作成、テストに必要なツールを手に入れることができる
  • 情報所有者に対し、誰にどのように所有アセットにアクセスするかを決定させることによって、情報所有者に情報の完全な可視性とコントロールを提供できる
  • すべての主要な脅威(すなわち、OWASPトップ10)から情報資産を保護する強力なセキュリティを提供できる
  • 軽量、アプライアンス/ESBは不要で、マイクロサービスアーキテクチャに適している
  • Elasticである(容易にスケールできる)
  • ゲートウェイやAPIの個数およびその配置場所に関係なく一元管理できる
  • 統計情報を有意義に使って、運用データを使って監視とトラブルシューティングだけでなくビジネスへの洞察を得ることができる
  • CPUベースのライセンスではなく、サブスクリプションベースである

    The End of "Fat" Middleware

    モノリスをより小さなピースに分割して、SaaSもしくはPaaSで個別のクラウドアプリケーションとして再実装するため、そうしたモノリスに含まれていたビジネスロジックや情報もまた分散します。第1世代、第2世代の統合ミドルウェアで見られた、多くのロジックを含みながらだんだん大きくなっていくという傾向は、まさに破裂するバブルのようによろしくない方向に進んでいます。
    An Ode to Middleware (OpenLegacy Blog)
    http://www.openlegacy.com/blog/an-ode-to-middleware/
    weir-3rd-gen-api-mgmt-fig05
    Figure 5 - Logic distribution in 3rd generation
    第3世代のAPIプラットフォームはAPIプラットフォームは、ソフトウェア・アーキテクチャとソフトウェア開発の変曲点を真に目の当たりにしています。つまり、もはやレイヤー構造でアーキテクチャを表現できない、ということです。これは、異なるアーキテクチャを比較し、その中でどのように情報が流れるかで、評価されるというパラダイムシフトです。
    weir-3rd-gen-api-mgmt-fig06
    Figure 6 - 1st- and 2nd-generation API platforms architectures compared


    API Capability Model

    以下のケイパビリティモデルは、第3世代APIプラットフォームで期待される機能を示したものです。すべての機能がプラットフォームの中核を占めるわけではありませんが、エンドツーエンドのソリューションのために重要と考えられるため、関連する機能が含まれています。個々のケイパビリティを実現するために採用可能なテクノロジーを決定するための、構造化されたフレームワークを提供するため、このようなモデルを利用することを強く推奨します。
    Figure 7 - API capability model
    図からわかるように、API Gatewayは、APIを実行するエンジンであるだけでなく、情報資産へのエントリポイントであり、ポリシーが適用される場所でもあるため、中心的な役割を果たします。APIが情報への入り口であれうば、API Gatewayはまさに扉です。
    このモデルには明示されていませんが、第1世代および第2世代のAPI Gatewayとは異なる第3世代のAPI Gatewayを決定付ける基本的なケイパビリティがあります。
    • 軽量(Lightweight)
      モノリシックでなく、アプライアンスを必要とせず、ESBも不要。軽量で、任意の場所、の展開が非常に簡単。理想的には、コンテナを利用。
    • 自立(Self-sufficient)
      集中管理ユニットからAPI、ポリシー、さらにはシステムパッチを取得することが自らの責任であるべき。
    • マイクロサービス指向(Microservice oriented)
      以下のことが実現できること
      • ステートレス。任意のトランザクションで状態を管理しない。
      • 任意の言語でサービスを実装できる、もしくはテクノロジーを選択できる。
      • 条件に基づいてElasticにGatewayをスケールイン、スケールアウトできる。
      • (Consul、Eurekaなどの)レジストリと統合し、動的にアクティブなサービスエンドポイントやルートをインテリジェントに判断することで、APIのロードバランサを実装できる
      • Gatewayにない機能を提供しないことで、開発者がGatewayにロジックを追加できないようにできる

    Conclusion

    第3世代のAPIプラットフォームは、モダンなアーキテクチャの採用を容易にする機能を提供しています。これにより、企業は新しい製品やサービスを生み出し、迅速かつ安価に提供して、関連性や競争力を維持します。
    GoogleやLinkedIn、AmazonといったDigital Giantsにとって、これは旧聞でしょう。
    Gartner Reveals Top Predictions for IT Organizations and Users in 2017 and Beyond  (2016, Gartner Newsroom)
    http://www.gartner.com/newsroom/id/3482117

    しかしながら、世界の多数の組織にとって、クラウドやDigital Transformation、顧客中心主義への旅路はまだスタートしたばかりです。
    情報や機能を連携する傾向は止まらないでしょう。なぜなら、アナリストは2020年までに接続デバイスの個数が210億に達すると予測しているからです。あらゆる企業は、IoT (Internet of Things) テクノロジーを利用して顧客やパートナーとより密接に関わるため、対話の方法やサービスの提供方法が完全に変わります。
    その結果、クラウドを超えて、数十億のインターネット対応デバイスに管理と接続機能を提供する第4世代のプラットフォームが必要になることでしょう。
    weir-3rd-gen-api-mgmt-fig08
    Figure 8 - 4th generation API platforms

    About the Author

    Oracle ACE DirectorのLuis Weirは、Capgemini UK PLCのChief Architectで、Oracle API Management 12c Implementation (2015, Packt) およびOracle SOA Governance 11g Implementation (2013, Packt) 、数多くの記事やホワイトペーパーの著者の一人でもある。LuisはOracle OpenWorldを含む業界イベントでの登壇も多く、直近では2017年4月20日のOracle Code Londonにも登壇した。LuisはUniversitat Politecnica de Valencia (UPV)でCorporate Networks and Systems Integrationの修士号を取得、Universidad Nueva EspartaでElectronics Engineeringの学士号を取得している。

    [R] Oracle R Distribution 3.3.0 Benchmarks

    原文はこちら。
    https://blogs.oracle.com/r/oracle-r-distribution-330-benchmarks

    先頃、Oracle R Distribution(ORD)バージョン3.3.0のベンチマークをアップデートしました。
    Oracle R Distribution
    http://www.oracle.com/technetwork/database/database-technologies/r/r-distribution/overview/index.html
    ORDはオープンソースのR-3.3.0に基づいており、システムにインストール済みの線形代数パフォーマンスライブラリを動的にロードするためのサポートが追加されています。これには、インテルのMath Kernel Library (MKL)、AMDのACML、およびSun Performance Library for Solarisが含まれており、最適なマルチスレッド算術ルーチンを使用して、関連するR関数の最大パフォーマンスを実現します。

    ベンチマーク結果から、MKLの動的ロードあり、なしの場合における、Oracle R Distribution 3.3.0のパフォーマンスがわかります。コミュニティベースのR-Benchmark-25スクリプトを実行しました。このスクリプトは、より高速な行列演算の恩恵を受ける一連のテストから構成されています。テストは、CPUコアあたり3.07 GHz、47GB RAMの24コアLinuxシステムで実行しました。

    平均すると、Oracle R Distributionは、MKLの動的ロードあり、8スレッドの場合で、Rの内部BLASライブラリ(Netlib)を1スレッドで使用するOracle R Distribution(およびオープンソースR)よりも50倍高速です。行列乗算は、シングルスレッドのRより94倍高速であり、主成分分析は32倍高速です。

    いつものように、ORDは無料でダウンロード、使用、共有でき、OracleのOpen Source Softwareポータルから入手できます。
    Oracle R Distribution
    https://oss.oracle.com/ORD/
    Oracle R Distribution 3.3.0は、今後リリースされるOracle R Enterprise 1.5.1でサポートされる予定です。 インストール手順は、Oracle R Enterprise Installation and Administration Guideを参照してください。リリースを発表する今後のブログエントリをお待ちください。
    Oracle® R Enterprise Installation and Administration Guide Release 1.5.1
    Installing R for Oracle R Enterprise
    https://docs.oracle.com/cd/E83411_01/OREAD/installing-R-for-ORE.htm#OREAD129

    [Java] JDK 9 Language, Tooling and Library Features

    原文はこちら。
    https://blogs.oracle.com/java/jdk-9-language-tooling-libraries

    モジュラリティに加え、JDK 9の主要な新機能として、言語やツール、ライブラリにその他の変更が加わります。JDKエンジニアのJoe Darcyが、「JDK 9 language, tooling and library features」というプレゼンテーションの中で、Java SEプラットフォームへの小さいけれども重要な変更を説明しています。全ての機能改善・強化はモジュールシステムの外部でなされており、全てのJava開発者にとって関係があるものです。

    Java 9のリリースは2017年9月21日に予定されています。現時点では、早期アクセスリリースをテストし、フィードバックできますので、アプリケーションを早期アクセスリリースでテストするよい機会です。ご存知とは思いますが、Java 9でもまだクラスパスをサポートしますので、サポート対象かつ外部利用を想定しているAPIを使っている限り、アプリケーションはJava 9で動作するはずですが、疑わしい場合は、以下のドキュメントをご覧ください。
    Java Platform, Standard Edition Oracle JDK 9 Migration Guide Release 9
    Removed or Changed APIs
    https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-F7696E02-A1FB-4D5A-B1F2-89E7007D4096
    DarcyがJava SEの下位互換性がバイナリ、ソース、および動作の変更に対する互換性をどのように示唆しているかを説明しています。各プラットフォームのリリースにはJava 8の場合と同様互換性ガイドがあります。
    Compatibility Guide for JDK 8
    http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html
    リリース日が近づくにつれ、Java 9互換ガイドが利用可能になります。

    また、以前のリリースで事前に知らせるというJava SEプラットフォームの非推奨プロセスも注目に値します。JDK 9では、JEP 277で@Deprecatedアノテーションを強化し、APIの非推奨状態について、より細かい情報をツールに提供します。JEP 277では、通知プロセス、APIの状態と将来の取り扱いについて詳細に説明し、アプリケーションの非推奨APIの静的な使用を追跡するツールを表示します。
    JEP 277: Enhanced Deprecation
    http://openjdk.java.net/jeps/277


    プロジェクトに最も関連性のある情報を見つけやすくするため、以下でビデオのチャプターを付けておきました。
    Java 9 has new and improved tools:JShell - REPL (12:00)
    https://youtu.be/KQiYlWFvc68?t=12mJava Doc (15:33)
    Java Doc new features: Doclint package filtering,  updated Doclet API and a new Javadoc Search
    https://youtu.be/KQiYlWFvc68?t=15m33sGetting from one JDK release to another (19:23)
    https://youtu.be/KQiYlWFvc68?t=19m27sMulti-release jar files - JEP 238  (24:18)
    https://youtu.be/KQiYlWFvc68?t=24m18s
    Java 9 has new Languages Changes that are not related to modules:Milling Project Coin (25:36)
    https://youtu.be/KQiYlWFvc68?t=25m36s
    Diamond with anonymous classes, take two (32:46)
    https://youtu.be/KQiYlWFvc68?t=32m46sAn underscore is no longer an identifier name (37:40)
    https://youtu.be/KQiYlWFvc68?t=37m40sPrivate interface methods (38:49)
    https://youtu.be/KQiYlWFvc68?t=38m49sDeprecation and imports
    https://youtu.be/KQiYlWFvc68?t=39m40s
    Java 9 has also library updates:New Version-String Scheme (45:15)
    https://youtu.be/KQiYlWFvc68?t=45m15sStrings and string concatenation (45:35)
    https://youtu.be/KQiYlWFvc68?t=45m35sConvenience factory methods for collections (46:17)
    https://youtu.be/KQiYlWFvc68?t=46m17s
    Some of the links mentioned in the presentationJEP 182: Policy for Retiring javac -source and -target Options
    http://openjdk.java.net/jeps/182JEP 247: Compile for Older Platform Versions
    http://openjdk.java.net/jeps/247JEP 277: Enhanced Deprecation
    http://openjdk.java.net/jeps/277JEP 254: Compact Strings
    http://openjdk.java.net/jeps/254JEP 280: Indify String Concatenation
    http://openjdk.java.net/jeps/280
    JDK 9 Early access release:
    http://jdk.java.net/9/Documentation:
    http://docs.oracle.com/javase/9/javase-docs.htm
    Javaの開発の最新情報を入手するため、是非@OpenJDKと@Javaをフォローしてください。

    [Database] Ever Evolving SQL*Plus 12.2.0.1 Adds New Performance Features

    原文はこちら。
    https://blogs.oracle.com/opal/sqlplus-12201-adds-new-performance-features

    # このエントリはLuan Nim (Senior Development Manager, Oracle)によるものです

    SQL*Plus 12.2.0.1 では、パフォーマンスや使い勝手をよくする数多くの機能が導入されました。これらの機能はSETコマンドもしくはコマンドラインから有効化できます。
    Oracle SQL*Plus 12.2.0.1の新機能には以下のようなものがあります。

    (訳注)
    以下のリンクの並びは、SQL*Plus®ユーザーズ・ガイドおよびリファレンス リリース2 (12.2)(日本語)、SQL*Plus® User's Guide and Reference Release 2 (12.2)(英語)の順です。
    ここで説明した新機能が皆様のお役に立つことを願っています。詳細は、以下のドキュメントをご覧ください。
    SQL*Plus®ユーザーズ・ガイドおよびリファレンス リリース2 (12.2)(日本語)
    http://docs.oracle.com/cd/E82638_01/SQPUG/toc.htm
    SQL*Plus® User's Guide and Reference Release 2 (12.2)(英語)
    http://docs.oracle.com/database/122/SQPUG/toc.htm
    SQL、PL/SQL、SQL*Plusについてご質問があれば、適切なOTN Spaceに投稿してください。
    Database Space @ OTN
    https://community.oracle.com/community/database

    [Docker] Hardcore Container Debugging

    原文はこちら。
    https://blogs.oracle.com/developers/hardcore-container-debugging

    オンラインチュートリアルを読んで、アプリケーションをコンテナ化することができました。外部からアプリケーションにアクセスできるようにポートを公開しましたが、接続すると「データベースに接続できません」というエラーページが表示されます。それではデバッグを始めましょう。以下では、コンテナのデバッグの方法や、Oracleがデバッグを容易にするために開発したcrashcartツールに関する情報を説明します。
    CrashCart: sideload binaries into a running container
    https://github.com/oracle/crashcart

    Related content

    Debugging Strategies

    コンテナのデバッグは難しい場合があります。特に、コンテナの内容とその動作方法があいまいな場合は特にそうです。小型のVMのようなコンテナを扱う人もいれば、コンテナ内でsshデーモンを実行して、物事がおかしくになったときにログインできるようにする人もいますし、コンテナの中にたくさんの便利なツールを配置しておき、 docker execを使ってコンテナの中のシェルを取得する人もいます。しかし、ふつうのオペレーションをしている人にとって、状況がよくないときはどうすればよいでしょうか。

    Debugging from the Host

    microontainerを使っている場合、コンテナには一つのアプリケーションおよびその依存性のみが含まれています。
    The Microcontainer Manifesto and the Right Tool for the Job
    https://blogs.oracle.com/developers/the-microcontainer-manifesto
    つまり、デバッグツールやシェルなんかは入っていないので、助けてはくれません。幸運にも、ホストからたくさんデバッグすることができます。あなたの武器のうち最も重要なツールの一つが、nsenterです。Linux Containerは数多くの分離および保護プリミティブの組み合わせですが、その中で理解しておくべきで最も重要なものがnamespace(名前空間)です。名前空間はコンテナ化されたプロセスをシステム上の他のプロセスと分離します。Nsenterを使うと既存の名前空間に入ることができます。
    例えば、コンテナ内のネットワークの問題をデバックしたい、としましょう。まず、コンテナのネットワークの名前空間に入ることになるのですが、入るためには、まずコンテナのプロセスのpidを把握する必要があります。
    PID=docker inspect -f "{{.State.Pid}}" <container-id>
    ネットワークの名前空間のシェルを取得するには、以下のようにpidをnsenterで指定します。
    sudo nsenter -n -p$PID
    名前空間を示すファイルはprocファイルシステム内にあり、直接その場所を使うことができます。
    sudo nsenter -n/proc/$PID/ns/net
    Nsenterは非常に強力なツールで、特にネットワークの問題を取り扱う場合には非常に有用です。ホストにインストールしたこのツールを使い、インターフェースをリストアップやトラフィックのダンプが可能です。コンテナの他の名前空間のほとんどにアクセスする場合、同様の方法で入ることができます。
    ところが、一つだけデバッグが難しいものがあります。それはコンテナのフィルシステムへのアクセスです。全てのツールが存在するホストのmount名前空間へのアクセスを失わなければ、コンテナのmount名前空間に入ることができません。Dockerのバージョンや利用しているfsドライバによって、コンテナのファイルにアクセスする種々の方法があります。かなり簡単な方法の1つは、/proc/$PID/rootを参照することですが、絶対シンボリックリンクが壊れてしまい、2つのビュー間でファイルの場所を手動で翻訳する必要があります。

    Roadblocks to an Ideal Solution

    完璧なソリューションは、必要に応じてコンテナ内にデバッグツールをマウントし、終了時にそれらを削除してセキュリティ上の脆弱性を回避する、というものでしょうが、この考えには2点問題があります。
    1. コンテナ内のものにデバッグツールを載せるだけでは不可能で、それではコンテナのmount名前空間に入るという趣旨にあいません。デバッグツールを非標準の場所に置く必要があります。多くのツールは他のディレクトリにあると動作に支障があります。ライブラリの検索パスに問題があったり、/debugのようなstarter以外のデバッグのような新しい場所にツールをロードする問題があったりします。
    2. ホストからコンテナのmount名前空間にディレクトリをマウントだけ実行することはできません。セキュリティ上の理由から、名前空間間のバインドマウントは許可されていません。新しいボリュームマウントでツールを使い、コンテナを確実に再起動することはできますが、これはつまりデバッグセッションの始めと終わりに再起動することであり、あるシナリオでは非常に混乱する可能性があります。

    Removing the Roadblocks

    まず必要なのは、別の場所にあっても問題ないデバッグツールです。うまく動作するようにするには、binutilsのビルドチェーン全体が非標準の接頭辞でビルドされている必要があります。さらに、ライブラリ依存関係は、コンテナ内のライブラリがデバッグツールと競合せず、問題を引き起こさないよう静的でなければなりません。
    nixという、別の場所でビルドされているかなりクールなパッケージシステムがあることがわかりました。
    Nix : The Purely Functional Package Manager
    https://nixos.org/nix/
    nixを使用すると、私たちのツールで/nixディレクトリを読み込むことができ、コンテナ自体がnixで構築されていない限り、競合はありません。nixで構築されたデバッグコンテナをサポートするために、/dev/crashcart のような別のディレクトリを選択することもできます(rootファイルシステム(/)が読み取り専用であったとしても、devはほぼ常にコンテナ内で書き込み可能なtmpfsなので、/devの前に置くと便利です)。
    2番目の障害をクリアするには、新しいものをコンテナの名前空間にマウントする方法が必要です。このオプションの一つとして、コンテナ作成時にrslave mountを作成するというものがあります。たとえば、dockerのボリュームコマンドを使い、rslave mountをコンテナの名前空間にロードすることができます。
    docker run -v /tmp/mymaster:/dev/crashcart:rslave mycontainer
    これにより、コンテナの /dev/crashcartは、ホスト上の /tmp/mymaster のスレーブ・マウントになります。つまり、/tmp/mymasterにディレクトリをマウントすると、そのディレクトリはコンテナ内の/dev/crashcartに伝播されます。 この手法は、必要に応じてツールのマウントをバインドし、後で削除できることを意味します。続いて、nsenterを使用してmount名前空間に入り、ツールを実行できますが、この方法にはまだ1つの欠点があります。この方法を使うには、開始時に実行するすべてのコンテナに対して特別なボリュームマウントを作成する必要があります。rslave mountを使ってコンテナを実行していない場合は、デバッグのために再起動が必要です。ボリュームを持つコンテナを起動せずにすむ方法があれば素晴らしいとは思いませんか?

    Enter crashcart

    必要に応じてコンテナ内のツールをマウントするために使用できるメソッドがありますが、これにはトリッキーなハックが含まれており、カーネル4.8以降であることが前提で、ユーザー名前空間が使用されていると動作しません。この方法は、コンテナのマウント名前空間内のブロックデバイスをmknodで作成し、mountシステムコールを使ってブロックデバイスをファイルシステムにマウントするというものです。ブロックデバイスを使用するために、バイナリをext3ファイルシステムにパッケージ化し、/dev/loopを使用してループバックブロックデバイスを作成できます。
    まだmknodを使ってファイルを作成しておらず、コンテナ内でマウントしていなければ、この方法を手作業で実施することはほぼ不可能ですので、これを実現するため、Rustで作成したユーティリティのcrashcartを開発しました。crashcartはイメージをコンテナの名前空間にマウントし、nsenterのような方法もしくはdocker execを呼び出すかのいずれかを使って/dev/crashcart/bin/bashを実行します。こうすれば、crashcartイメージに格納された任意のツールにアクセスできます。

    Why Rust?

    以下のエントリでも説明しましたが、Rustを使う理由は全て、crashcartにもあてはまります。
    Building a Container Runtime in Rust
    https://blogs.oracle.com/developers/building-a-container-runtime-in-rust
    https://orablogs-jp.blogspot.jp/2017/07/building-container-runtime-in-rust.html
    crashcartは700行未満のコードでできあがっており、Cで書かれていたとしても、潜在的なセキュリティ上の脆弱性を避けるためにメモリ安全であることは良いことです。 Rustは初心者が読むには少し難しいかもしれませんが、Rustの初心者たちがこのプロジェクトに飛び込んで協力くださることを強く願っています。Rustは魅力的な言語であり、非常に有用な特性を有しています。

    The Future

    crashcartを使うと、今日ユニークな方法でコンテナのデバッグができますが、事態は確実に良くなるでしょう。このツールをコミュニティに提供し、ツールを改善くださることを願っています。テクニックの潜在的な改善に対するいくつかアイデアがあります。
    1. nixを使ってcrashcartイメージをビルドすると、標準のnixパッケージサーバを利用できないため、非常に低速です。新しいロケーションをサポートする代替パッケージサーバが提供される可能性がありますが、別のパッケージャが代替crashcartイメージを作成できるようになることを期待しています。build-image.shスクリプトをプロトタイプと考え、rpmやdebs、その他のディストリビューションからパッケージをインストール可能な代替可能なcrashcartイメージが見られるとすばらしいですね。
    2. このような複雑なシステムコールを必要としないバイナリを簡単にロードするより簡単な方法があるとよいのですが、その方法の一つは、カーネルが名前空間を越えてマウントに対する制限を緩和すること、もう一つは、Dockerがデフォルトでrslave mountを作成することです。これにより、必要に応じてホストからバイナリをより簡単にマウントすることもできるでしょう。

    [Java] Java EE 8 - June recap

    原文はこちら。
    https://blogs.oracle.com/theaquarium/java-ee-8-june-recap

    直近の数週間はJava EE 8の進捗という点で非常に実りのあるものでした。以下で主要なニュースをまとめていきます。
    JSON-B (JSR 367) は無事にFinal Approval Ballotを通過しました。
    JSR 367: JavaTM API for JSON Binding (JSON-B)
    https://jcp.org/en/jsr/detail?id=367
    先頃Maintenance Release Ballotを通過したJSON-P 1.1 (JSR 374)、JSF 2.3 (JSR 372)、JPA 2.2 (JSR 338) に続いて、JSON-BがBallotをパスしたJava EE 8関連仕様の一つになりました。
    JSR 374: JavaTM API for JSON Processing 1.1
    https://jcp.org/en/jsr/detail?id=374
    JSR 372: JavaServer Faces (JSF 2.3) Specification.
    https://jcp.org/en/jsr/detail?id=372
    JSR 338: JavaTM Persistence 2.1
    https://jcp.org/en/jsr/detail?id=338
    6月は、さらにServlet 4.0 (JSR 369)、JAX-RS 2.1 (JSR 370)、Bean Validation 2.0 (JSR 380)がPublic Review Ballotを通過し、Proposed Final Draftを提出しました。
    JSR 369: JavaTM Servlet 4.0 Specification
    https://jcp.org/en/jsr/detail?id=369
    JSR 370: JavaTM API for RESTful Web Services (JAX-RS 2.1) Specification
    https://jcp.org/en/jsr/detail?id=370
    JSR 380: Bean Validation 2.0
    https://jcp.org/en/jsr/detail?id=380
    これら3仕様は現在最終フェーズ、つまり最終化前のProposed Final Draftのフェーズに入っています。
    Security API for Java EEのExpert Group (JSR 375) もPublic Reviewを提出し、現在Public Review Ballot期間が終わろうとしています。Expert GroupはProposed Final Draftを速やかに提出するために仕様をまとめるのに忙しくしています。
    JSR 375: JavaTM EE Security API
    https://jcp.org/en/jsr/detail?id=375
    最後に、Java EE 8 (JSR 366) は、6月にPublic Review Ballotを無事に通過し、Proposed Final Draftに移行する準備が整いました!
    JSR 366: Java Platform, Enterprise Edition 8 (Java EE 8) Specification
    https://jcp.org/en/jsr/detail?id=366
    JSR #366
    Java Platform, Enterprise Edition 8 (Java EE 8) Specification
    Public Review Ballot
    https://jcp.org/en/jsr/results?id=5993

    要するに、Java EE 8仕様がほぼ完成したと言えるでしょう。その結果、仕様関連の作業が順調に進行し、GlassFish 5関連の活動が増加しています。先月、GlassFishのコードベースが再構築されました。
    Structural change in GlassFish code
    https://javaee.groups.io/g/glassfish/topic/structural_change_in/5163659?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,5163659
    さまざまな(Jersey、Yasson、Mojarraなどの)リファレンス実装は既にGlassFish 5に統合されています(JPA 2.2のEclipseLink 2.7.0など)。
    Integrate JPA 2.2-RC1 and EclipseLink 2.7.0-RC1 (#21978)
    https://github.com/javaee/glassfish/issues/21978
    Weld 3の統合では少々手戻りがありましたが、最近GlassFish 5に再統合されました。
    Re: [gf] GlassFish-5.0-b10 is promoted and available for download
    https://javaee.groups.io/g/glassfish/message/45
    Bean Validation 2の統合は現在実施中です。
    First cut: Bean Validation 2.0 Integration (#21962)
    https://github.com/javaee/glassfish/pull/21962
    要約すると、Java EE 8がうまく進んでいると言えるでしょう。

    P.S.
    Dockerをお使いなら、以下の記事をチェックしてください。
    GlassFish Docker Images – Update
    https://blogs.oracle.com/theaquarium/glassfish-docker-images-%E2%80%93-update
    https://orablogs-jp.blogspot.jp/2017/07/glassfish-docker-images-update.html

    [Java] Comments at Java Platform Module System Public Review Reconsideration Ballot

    2017年6月26日(PDT)にJava Platform Module System (JPMS) Public Review Reconsideration Ballotの結果が公開されました。以前の否決を受けての再提出内容に対する投票で、1社の棄権を除いて、全てのECメンバーがYes(賛成)の投票をしました。
    JSR #376 JavaTM Platform Module System Public Review Reconsideration Ballot
    https://jcp.org/en/jsr/results?id=6016
    前回と同じように、JCP Executive Committeeの投票とともに寄せられたコメントを日本語にしてみました(例によって、自明のコメントは日本語化していません)。
    なお、前回の投票結果および付帯コメントは以下にあります。
    JSR #376 JavaTM Platform Module System Public Review Ballot
    https://jcp.org/en/jsr/results?id=5959
    [Java] Comments at Public Review Ballot for JSR 376
    https://orablogs-jp.blogspot.jp/2017/05/comments-at-public-review-ballot-for.html
    On 2017-06-25 Fujitsu Limited voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2017-06-26 SAP SE voted Yes with the following comment:
    SAPは、前回の投票以後、オープンな技術的質問の合意に達し、かつ議論の現在の状態をコミュニティーに伝えるというExpert Groupが費やした相当な努力を拝見し、喜ばしく思っています。私たちは、JPMSが良い方法であり、Java 9でのJSR 376の最終リリースまでだけでなく、将来のJavaのリリースにおけるJPMSの想定されるアップデートや改良に向け、現在のモジュール方式がメンテナンスされることを希望します。
    ------------------------------------------------------------------------------
    On 2017-06-14 Oracle voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2017-06-26 Keil, Werner voted Yes with the following comment:
    ほとんどの主要な懸念点が解決されたり、可及的速やかに解決されることが約束されていることがわかりうれしく思っています。modularityはJavaエコシステムの多くの箇所、より小さなデバイスならびにJava EEのようなより大きなシステムでも、メリットを享受するでしょう。
    ------------------------------------------------------------------------------
    On 2017-06-19 Eclipse Foundation, Inc voted Yes with the following comment:
    EclipseコミュニティはJPMSについて十分な進捗があり、Java言語仕様が承認されるのは当然と確信しています。これを成し遂げた全ての方々に感謝します。
    ------------------------------------------------------------------------------
    On 2017-06-23 Credit Suisse voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2017-06-26 Tomitribe voted Yes with the following comment:
    最初の投票とブログで述べたように、Executive CommitteeとExpert Groupに30日間の間に共通理解を持たせ、明確な結果を得たという、真価を目の当たりにしました。Spec Leadは、結果として生じた大量のフィードバックを処理する優れた仕事をしており、祝福されるべきです。デフォルトで不正なアクセスを許可するなど、いくつかの決定がなされたと信じていますが、明確な警告があればスムーズな移行につながり、モジュール化への動きを促進する圧力になっています。以前の投票を否定的と見なす人もいるでしょうが、JCPプロセスの成功とJava全体の強さのしるしと理解するべきです。
    ------------------------------------------------------------------------------
    On 2017-06-23 JetBrains s.r.o. voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2017-06-23 ARM Limited voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2017-06-13 IBM voted Yes with the following comment:
    IBMはこの改訂されたJPMSについて仕様をProposed Final Draftのフェーズに進めることをサポートします。Spec LeaderのOracleと、JSR 376 Expert Groupのメンバーがこのマイルストーンに達するために時間を割き、よくやってくれたおかげです。

    公開声明に記載の通り、IBMは、仕様に追加された新しい互換機能とエンタープライズ・アプリケーション向けの移行の強化、およびExpert Group間で合意された未解決の問題の処理を評価します。このJPMSは、新しいJava SEプラットフォームアーキテクチャの強力な基盤と考えています。顧客やコミュニティからのフィードバックや経験を基に構築されることを期待しています。
    Building Consensus on JSR 376: Java Platform Module System
    https://developer.ibm.com/javasdk/2017/05/26/building-consensus-jsr-376-java-platform-module-system/
    ------------------------------------------------------------------------------
    On 2017-06-16 Gemalto M2M GmbH voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2017-06-19 V2COM voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2017-06-23 Red Hat voted Abstain with the following comment:
    今回Red HatはAbstain(棄権)します。その理由は、前回の投票以後合意に達したことで、Expert Group内でポジティブな進捗があったと考えていますが、このリリースに対する、30日間の延長期間内に対処できたコミュニティの普及に影響を与える多くの項目が現在の提案に含まれていると考えいます。とはいえ、Java 9のリリースを遅らせたくはありませんし、Spec LeadとExpert Groupが提案した以後のJavaバージョンに対する積極的なスケジュールに満足しています。それは、モジュールシステムに対する実際のフィードバックを得ることがさらにどこを変更すべきかを理解する上で重要と考えているからです。
    Project LeadおよびExpert Groupが、この30日間と同様、引き続き幅広いJavaコミュニティからのフィードバックに対する間口を開き、Javaの進化がOpenJDK以外のユーザーやコミュニティからのデータによって促進されることを期待しています。

    過去30日間に数多くのミーティングを手伝ってくれたExpert Group、OracleのSpec Lead、その他の皆さんに感謝の意を表します。この増加したコラボレーションと、問題の議論と解決への積極的なアプローチは、我々自身とより広いJavaコミュニティが歓迎するものです。
    ------------------------------------------------------------------------------
    On 2017-06-19 Goldman Sachs & Co. voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2017-06-19 NXP Semiconductors voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2017-06-19 Software AG voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2017-06-26 Twitter, Inc. voted Yes with the following comment:
    まず、JPMS仕様を改善するため、過去1ヵ月半にわたるJSR 376 Expert Group(EG)のメンバー全員に感謝の意を表します。ここまでになされた進捗に勇気づけられました。

    改訂されたJSR 376仕様では、いくつかのあいまいな部分(#RestrictedKeywords、#CompilationWithConcealedPackages、および#ResolutionAtCompileTime)が明確になり、いくつかの重要な変更(#ModuleNameInManifestと強力なカプセル化の緩和)が加えられたことをうれしく思っています。また、現在のJPMS仕様がJDK 9の一部としてリリースの準備が整ったことについて、JSR 376 EGメンバーの間で合意が得られていることもうれしく思います。

    コミュニティがJPMSに期待しているメリット(特に#AvoidConcealedPackageConflicts)をすぐに確認できないのは残念に思いますが、最も要求される機能は、多くの議論と適切な評価が必要で、これはJDK 9の時間枠では足りないことを理解しています。私たちは、JPMSの最初のバージョンが、将来のJDKリリースで作業に取りかかり、導入されるこうした機能のよい基礎となることを願っています。
    ------------------------------------------------------------------------------
    On 2017-06-26 SouJava voted Yes with the following comment:
    SouJavaは、最初の投票で私たちがExpert GroupとSpec Leadに寄託した信頼が間違ったものではないことを確認でき、非常に喜んでいます。

    これまでの30〜40日でなされた作業は、提起された問題を解決するための効果的な取り組みでした。この取り組みの期間中に、すべての問題を直ちに対処もしくはロードマップに載せたということで、話を聞いてもらっていると感じました。

    将来のJSRの教訓として、Java言語はJavaエコシステムの基本要素です。 Java言語仕様に関わるJSRは、提案された変更が初期ドラフト(Early Draft)に反映されるよう、非常に注意する必要があります。このようなJavaの基本的な部分を混乱させることは、Javaエコシステム全体にとって非常に有害です。 これらの問題が解決されたことをうれしく思います。

    結局のところ、Spec LeadとExpert Groupが受け取ったすべてのフィードバックをもとに、過去数週間にわたって一緒になって行った作業は、Javaコミュニティが非常に強く、JCPプロセスが非常に重要で機能的であることを証明するものでした。 これを可能にしたすべての人に対し、おめでとうと申し上げます。
    ------------------------------------------------------------------------------
    On 2017-06-13 Intel Corp. voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2017-06-14 MicroDoc voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2017-06-14 London Java Community voted Yes with the following comment:
    LJCはYesを投じます。そして(Spec Leaderとしての)Oracleと、時間を割いて私たちが心配していた仕様の範囲を再定義し明確にしてくれたJSR 376 Expert Groupのメンバーに対する、IBMの謝意をそのまま繰り返します。

    LJCが懸念していた、Javaエコシステムでデファクトのビルドツール/モジュールリポジトリ(Apache Maven)との相互運用性に関する懸念について、コンパイラ非依存の実装(特にejc)を構築することができるのかどうかに懸念がありましたが、対処されました。
    Explanation of our “No” vote on JSR 376 (Java Platform Module System)
    https://londonjavacommunity.wordpress.com/2017/05/09/explanation-of-our-no-vote-on-jsr-376-java-platform-module-system/
    Expert Group間で合意された未解決の問題の処理は本当にうまく取り扱われ、過去1ヶ月間のExpert Groupのミーティングの詳細な議事録に記載されているように、明らかなコラボレーションを見て勇気づけられました。

    今回のJPMSのリリースは、新しいJava SEプラットフォームアーキテクチャの強力な基盤と考えています。Java User Groupのメンバーからのフィードバックと体験を基に構築されることを期待しています。
    ------------------------------------------------------------------------------
    On 2017-06-14 Azul Systems, Inc. voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2017-06-14 Grimstad, Ivar voted Yes with the following comment:
    (前回)Noを投票することになった問題が対処されたことをうれしく思っています。Expert GroupおよびSpec Leadが真剣に懸念を受け止め、その労力を仕様に落とし込んでくれたおかげです。
    ------------------------------------------------------------------------------
    On 2017-06-20 Hazelcast voted Yes with the following comment:
    ポジティブな進捗がこの数週間にわたってあったので、Hazelcast は yes を投票しました。まだ解決していない課題がありますが、こうした課題は小さなもので、JPMSの将来のリリースで対処できると思っています。
    ------------------------------------------------------------------------------
    On 2017-06-22 Hewlett Packard Enterprise voted Yes with no comment.
    ------------------------------------------------------------------------------