[Java] Java 11がリリースされました

まずは、お約束の文言から。
このエントリは個人の見解であり、所属する会社の公式見解ではありません。
Opinions expressed in this blog entry is my personal one and does not represent the official opinion of my employer.
US時間の2018年9月25日、Java 11がリリースされました。新しいリリースサイクルになって最初のLTS(Long Term Support)リリースです。

ダウンロード

OpenJDKのOracleビルド、Oracle JDKは以下からダウンロードできますが、OTNからダウンロードできるOracle JDKはライセンス条項に記載の通り、商用環境では利用できません。(医薬品ではありませんが)よく読んでお使いください。
Oracle Technology Network License Agreement for Oracle Java SE
https://www.oracle.com/technetwork/java/javase/terms/license/javase-license.html
OracleがビルドしたOpenJDK
JDK 11 General-Availability Release
http://jdk.java.net/11/
Oracle JDK
My Oracle Support
https://support.oracle.com
Oracle Software Delivery Cloud
https://edelivery.oracle.com
Oracle Technology Network
https://www.oracle.com/technetwork/java/javase/downloads/index.html

新機能

Early Access Buildをお使いのコミュニティの皆様方がすでに纏めてらっしゃいますが、YouTubeのJavaチャネルにも主要な新機能を説明する動画がUpされています。

Introduction to the Java 11 HTTP Client


Road to the Java 11 HTTP Client


Z Garbage Collector (ZGC)


JEP 323: Local Variable Syntax for Lambda Parameters


Handling Response Data with the Java 11 HTTP Client


Transport Layer Security (TLS) 1.3


費用、セキュリティ修正などの提供

再三にわたって記載してきたのですでに皆様ご存知かと思います。今回で4度目になりますが纏めておきます(他社製品や他社によるOpenJDKビルドに関してはコメントしません)。
  • OracleがビルドしたOpenJDK
    • 開発環境、本番環境を問わず無償利用可能
    • GNU General Public License, version 2 with the Classpath Exception(GPLv2+CE)
    • 機能リリース(Feature Release)のサイクルに従うため、リリース後6ヵ月でEoL
    • 6ヵ月中2回のセキュリティアップデートのリリース(1月と4月、もしくは7月と10月)
    • 製品機能の問合せはコミュニティへ
  • Oracle JDK
    • OTNからダウンロードしたバイナリは、Oracle Technology Network License Agreement for Oracle Java SEの範囲において無償利用可能、それ以外はOracleとのサポート契約が必要
    • Oracle Binary Code License Agreement for the Java SE Platform Products and JavaFX(BCL)
    • LTSリリースのみ、3年ごとにリリース(次回のLTSはJava 17を予定)
    • 年4回のセキュリティアップデートのリリース(1月、4月、7月、10月)
    • サポート期間はOracle Premier Supportのポリシーに従う(5年+3年+Infinite)
    • Javaサポートの契約方法
      • Java SE Advanced/Suite(従来から提供しているもの)もしくはJava SE Subscription
      • Oracle製品やサービスのライセンスを購入されている場合、サポート費用はライセンスサポートに含まれるため、別途契約は不要
      • Oracle CloudでJavaを利用するサービスを使っている場合、サブスクリプション費用にサポート費用が含まれているため、追加費用は不要
是非進化したJavaをお試しください。新機能を試してブログにまとめたり、発表いただいたりしてもらえると非常にうれしく思います。

[Java] Introducing Java SE 11

原文はこちら。
https://blogs.oracle.com/java-platform-group/introducing-java-se-11

どれだけの時間が過ぎたことでしょう。ユーザーにとって活気に満ちた未来が続くことを確実にするため、Oracleは過去数ヶ月の間にJava Platformを進化させるための変更を発表してきました。一部ご紹介しましょう。

Increasing the pace and predictability of delivery

Java 9のリリース以降、Java Platformは6ヶ月のリリースサイクルに移行しました。この結果、開発者は継続的な機能強化に迅速にアクセスできます。
Update and FAQ on the Java SE Release Cadence
https://blogs.oracle.com/java-platform-group/update-and-faq-on-the-java-se-release-cadence
https://orablogs-jp.blogspot.com/2018/05/update-and-faq-on-java-se-release.html
リリースは現在、毎年3月と9月に行われますが、これは数年に一度、数百もの変更を取り入れるのではなく、変更がより正確かつ予測可能なペースで行われることを意味します。

Making Java even more open

開発者の生産性を向上するために、以前は有償ライセンスでのみ利用可能だった商用機能をオープンソース化しました。これにより、Oracle JDKとOracle OpenJDK(つまりOracleがビルドしたOpenJDKバイナリ)リリース間の互換性が大幅に向上しています。以前有償機能だったもののうち、OpenJDKで利用可能なものとして、Application Class Data Sharing、Project ZGC、Java Flight Recorder (JFR)、Java Mission Control (JMC)などがあります。そして最近、OracleはJMCテクノロジーをOpenJDKとOracle JDKの両方のユーザーが利用できるようにするため、別のダウンロードとして提供する計画を発表しました。
Java Mission Control - Now serving OpenJDK binaries too!
https://blogs.oracle.com/java-platform-group/java-mission-control-now-serving-openjdk-binaries-too
https://orablogs-jp.blogspot.com/2018/08/java-mission-control-now-serving.html

Introducing the Java SE Subscription

Oracleは今夏、Java SE Subscriptionを発表しました。
A Quick Summary on the new Java SE Subscription
https://blogs.oracle.com/java-platform-group/a-quick-summary-on-the-new-java-se-subscription
https://orablogs-jp.blogspot.com/2018/06/a-quick-summary-on-new-java-se.html
このモデルは、本番環境でJavaを実行している、世界中の数百万の企業に対するあらゆるJava SEライセンスとサポートへのニーズをカバーするものです。このサブスクリプションは、商用サポートを必要としない開発者および組織が利用可能な長年にわたる無料のOracle OpenJDKを補完します。
Java SE Downloads
https://www.oracle.com/technetwork/java/javase/downloads/index.html
6ヶ月リリースサイクルで最初のFeature Release(機能リリース)であるJava 10から6ヶ月後にOracleはJava 11をリリースしています。

Oracleは、Oracle OpenJDKリリースでGNU General Public License v2, with the Classpath Exception (GPLv2+CPE)を使ってJDKを提供するだけでなく、Oracle製品やサービスの一部としてOracle JDKを利用のお客様やオープンソースソフトウェアを利用したくないお客様のため、商用ライセンスの下でJDKを提供します。これらは、無料と有償の取引条件の組み合わせであるこれまでの "BCL"ライセンスに取って代わるものです。
Oracle JDK Releases for Java 11 and Later
https://blogs.oracle.com/java-platform-group/oracle-jdk-releases-for-java-11-and-later
https://orablogs-jp.blogspot.com/2018/09/oracle-jdk-releases-for-java-11-and.html
つまり、ユーザーがJava 11を自身のニーズにあわせることができる、ということです。
  1. Java 11は長期サポート(LTS)リリースです。つまり、プラットフォームの採用に慎重な、長期サポートを必要とするユーザーは、Java SE Subscriptionを通じてOracle JDKバイナリのライセンスを取得できるため、ユーザーは少なくとも8年間はJava 11 LTSリリースのアップデートを入手できます。サブスクリプションにより、テストならびに動作保証が済んだ、Java SEのパフォーマンス、安定性、およびセキュリティーに関するアップデートをOracleから直接入手できますし、その他の利点として、24時間365日のMy Oracle Support(MOS)へのアクセスと27言語でのサポート、Java SE 8 Desktopの管理、監視、デプロイ機能も利用できます。
  2. 新しい機能拡張に迅速にアクセスしたいユーザーのみなさまは、引き続きOracle OpenJDKリリースを利用できます。Java 9およびJava 10の場合と同様に、このリリースのユーザーは、Oracleが提供する徹底的にテストされた、オープンソースのOpenJDKビルドを入手できます。
Java 11では17個の機能拡張が含まれています。
JDK 11
http://openjdk.java.net/projects/jdk/11/
一部をご紹介しましょう。
  1. JEP 321 - HTTP Client (Standard)
    http://openjdk.java.net/jeps/321
    JDK 110によってJDK 9で導入され、JDK 10で更新されたHTTP Client APIを標準化しました。
  2. JEP 332 - Transport Layer Security (TLS) 1.3
    http://openjdk.java.net/jeps/332
    TLS 1.3はTLSプロトコルの大幅な改良であり、以前のバージョンよりも大幅にセキュリティとパフォーマンスが向上しました。
  3. JEP 328 - Java Flight Recorder (JFR)
    http://openjdk.java.net/jeps/328
    JFRはミッションクリティカルなJavaアプリケーションのトラブルシューティングのための、高性能な実行情報の記録エンジンと低オーバーヘッドのデータ収集フレームワークです。
  4. JEP 333 - Project ZGC
    http://openjdk.java.net/jeps/333
    ZGCは実験的ではあるものの予測可能な低レイテンシのガベージ・コレクタ(GC) で、比較的小さな(数百MB)から非常に大きな(数TB)までの範囲のヒープを処理できます。
  5. JEP 330 – Launch Single-File Source-Code Programs
    http://openjdk.java.net/jeps/330
    Java入門者が感じるJavaの敷居を下げるため、スクリプトや関連する方法からの利用を含む、単一ファイルのJavaソースコードとして提供されるプログラムを実行するようにJavaランチャーを機能強化しました。
Java 11が一般提供されたので、開発は次の6ヶ月先の機能リリース、Java 12(2019年3月出荷予定)に移行しました。現時点では2つの機能拡張が予定されていますが、作業が完了するにつれさらに追加される可能性があります。
JDK 12
http://openjdk.java.net/projects/jdk/12/
世界中で1,200万人の開発者がJavaを実行しており、Javaは、ソフトウェアプログラマが選択するプログラミング言語の第1位であり続けています。また、Java 11が示すように、継続的な計画とエコシステムの関与を通じて、Javaプラットフォームは、クラウドでのモダンな開発と成長に適しています。

[Cloud, Integration] Using a Library in OIC

原文はこちら
https://blogs.oracle.com/integration/using-a-library-in-oic

Introduction

Oracle Integration Cloud(OIC、以下OICと省略)におけるライブラリは、JavaScript関数を含む単一のファイルもしくは複数ファイルをJARの形で束ねたものです。ライブラリは統合の中で利用され、JavaScriptエンジンがサーバで統合フローの中で実行します。

このエントリでは以下の内容について説明します。
  1. 統合の中で利用するにあたって必要とするJavaScript関数に対する要求事項
  2. ライブラリを作成するために適したJavaScriptファイルやJavaScriptファイルのコレクションの作成方法

1. JavaScript function requirements

OICで登録ができ、正しく動作可能なJavaScriptに対する要求事項は以下の通りです。

1.1 Function return values should be named

以下の例を考えます。
function add ( param1, param2 ) {
  return param1 + param2;
}
上記の例は完全にJavaScript関数として正しいのですが、OICのライブラリとして登録できません。その理由は、名前付きの戻り値がないためです。これがないと、ライブラリメタデータ・エディタは関数が戻すパラメータを識別できず、結果として統合のダウンストリームアクティビティにマッピングするためのマッパーで利用できません。

OICで利用するためには、上記関数を変更し、以下のように戻り値のパラメータに名前を付ける必要があります。
function add ( param1, param2 ) {
  var retValue = param1 + param2;
  return retValue;
}
この場合、戻り値のパラメータには retValue という名前が付いています。この変更により、ユーザーは戻り値をダウンストリーム・アクティビティにマッピングできるようになります。

1.2 Inner functions

JavaScript関数が別の関数を内部で定義している場合、OICのライブラリメタデータ・エディタは内部関数を識別しませんので、内部関数用にメタデータを作成しません。関数用のメタデータを作成しない場合にはOICで当該関数を利用できませんが、内部関数はその外側にある関数内で利用することは可能です。
function parseDate(d) {
 function foo(d) {
    if(typeof d === 'string') { 
       return Date.parse(d.replace(/-/g,'/')); 
    }
    if(!(d instanceof Array)) { 
       throw new Error("parseDate: parameter must be arrays of strings"); 
    }
    var ret = [],k;
    for(k=0;k<d.length;k++) { 
       ret[k] = foo(d[k]); 
    }
    return ret;
 }
 var retVal = foo(d);
 return retVal;
}
上記の例の場合、 foo() を関数 parseDate() の中で定義しているため、メタデータUIエディタはfoo()を無視し、外部関数parseDate()のみを構成できますが、関数として問題ないため、parseDate()内でfoo()を利用します。

1.3 Long running functions

JavaScript関数の実行は最大1500msを超えてはいけません。(依存関係を含めて)関数の実行がこの閾値を超過した場合、自動的にサーバがプロセスをKILLし、1500msを超えたためにフローをKILLした旨をログメッセージに書き出します。

1.4 Input parameter types

OICは現在String、Number、Booleanの入力パラメータおよび戻り値のみをデータ型としてサポートしています。JavaScriptが異なるオブジェクト型、例えばArrayやDate型を利用する場合、サポートされているデータ型のいずれかであることを期待される入力パラメータを関数が期待するデータ型に変換する必要があります。以下はArray型の入力を取り扱う例です。

1.4.1 Array Input Type

以下の配列処理の例を考えます。
function myArrayProcessor(myArray) {
 var status = 'FAILED';
 for (i=0; i<myArray.length; i++) {
 
 }
 return status;
}
サポートされるパラメータ型にArrayは含まれていないため、このコードを以下の例のように変更する必要があります。
function myArrayProcessor(myArray) {
 var status = 'FAILED';
 var data = myArray.replace(/'/g, '"');
 myArray = JSON.parse(data);
 for (i=0; i<myArray.length; i++) {
 
 }
 return status;
}
この関数のメタデータを構成する際にはStringとして入力データ型をマークし、統合内の関数を使う際に入力文字列を解析して関数内でArrayに変換します。

2. Creating library using a JavaScript file or multiple files

2.1 Using single JavaScript file

単一のJavaScriptファイルを使ってライブラリを作成するのは簡単ですが、その単一ファイルに全ての依存関係を含める必要があります。関数が別の関数に依存している場合、依存関係のある関数が同一ファイル内に存在していなければなりません。ライブラリ登録時には、統合内で利用するために必要な関数のメタデータのみ編集すればよいのです。もし依存関係を満足するために存在する別の関数を構成する必要はありません。

以下の相互依存関係にあるJavaScript関数の例を考えます。
function funcOne(param1) {
 return param1;
}

function funcTwo(param2){
 return param2
}

function myFunc(param1, param2) {
 var ret = funcOne(param1) + funcTwo(param2);
 return ret;
}
この例では、funcOne() とfuncTwo() を myFunc() が利用しています。このライブラリのメタデータを構成する際には、統合内で利用できるmyFunc()関数のみを構成すればOKです。


2.2 Using multiple JavaScript files

ライブラリを複数のJavaScriptファイルを基にして作成できます。複数ファイルを使う場合、JARファイルの形で全てのファイルを束ねて、JARファイルをライブラリとして登録する必要があります。

例として、EncodeAndDecodeライブラリを考えます。これは、Base64エンコードおよびデコードのスキームを使ってエンコード、デコードを実施するものです。

ライブラリは2個のファイル、Base64.js(Base64エンコードおよびデコードのロジック)とEncrypt.js(Base64.js内の関数に依存するラッパー関数)から構成されています。エンコードとデコードのラッパー関数を統合内で利用します。両ファイルともJARファイルに含まれており、このJARファイルを使ってライブラリを作成します。

上図のように、ライブラリを利用するために、Encrypt.jsファイル内のencode関数とdecode関数のメタデータを構成します。

3. Debugging JavaScript in a library

時間が経つと、JavaScriptライブラリのサイズと複雑さが増す可能性があります。JavaScriptライブラリのデバッグというと、通常はブラウザでのJavaScriptのテストで、問題なく動作することを確認したらライブラリとしてコードをリリースします。しかしこのやり方では、動作しないことがあります。その理由は、ブラウザが最新のJavaScriptバージョンをサポートする新しい実行エンジンで定期的に更新されていること、そして一般にブラウザエンジンは多くのコードエラーを無視するという点でより自由であるのに対し、OIC内のJavaScriptエンジンはより厳格だからです。
J avaScriptコードをデバッグするためには、以下のサンプルコードのようにCXConsole()のインスタンスを利用できます。
function add ( param1, param2 ) {
 var console = new CXConsole();
 var retValue = param1 + param2;
 console.log("# retValue: ", retValue);
 console.warn("# retValue: ", retValue);
 return retValue;
}
上記コードのログメッセージはserver-diagnostic.logファイルに書き込まれます。

[Cloud] Oracle Cloud Infrastructure Terraform Provider Now Supported by HashiCorp

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/oracle-cloud-infrastructure-terraform-provider-now-supported-by-hashicorp

Terraformの公式プロバイダとしてご利用頂ける、Oracle Cloud Infrastructure用のHashiCorp Terraform Providerをすぐにご利用頂けることを発表できうれしく思っています。
Oracle Cloud Infrastructure Provider
https://www.terraform.io/docs/providers/oci/index.html
HashiCorpとのパートナーシップ、そしてInfrastructure-as-Codeの旅でお客様をサポートできることにわくわくしています。

ここ数ヶ月にわたり、TerraFormへ多大な投資をした結果、全てのOracle Cloud Infrastructureリソースに対するTerraformを使ったプロビジョニングをサポートできるようになりました。Oracle Cloud Infrastructure ProviderはTerraform 0.10.1以後との互換性があります。以下はTerraformプロバイダがサポートする主要なリソースです。
  • Block Volumes
  • Compute
  • Container Engine
  • Database
  • File Storage
  • Identity and Access Management (IAM)
  • Load Balancing
  • Networking
  • Object Storage
サポート対象のリソースの詳細リストや使い方などの詳細情報は、以下のURLからどうぞ。
Oracle Cloud Infrastructure Provider
https://www.terraform.io/docs/providers/oci/index.html
TerraformやOracle Cloud Infrastructure providerのことを余りご存知ないお客様は、構成時にterraform initを実行してください。このコマンドでプロバイダを自動的にダウンロードします。

以前のバージョンを利用しており、最新バージョンにアップグレードしたいお客様は、手作業でインストール済みのプロバイダを削除するか、構成ファイルで3.0.0を指定した上で、terraform initを実行する必要があります。詳細は、アップグレードガイドをご覧ください。
Terraform OCI Provider Version 3
https://www.terraform.io/docs/providers/oci/guides/version-3-upgrade.html
Oracle Cloud InfrastructureでComputeインスタンスを作成するEnd-to-Endの例は、以下のサンプルをご覧ください。
Terraform Provider for OCI - Manage instances with multiple attached volumes
https://github.com/terraform-providers/terraform-provider-oci/tree/master/docs/examples/compute/instance
このリリースに続いて、Oracle Cloud Infrastructure用のTerraformモジュールが公式のTerraform Module Registryで公開される予定です。このモジュールを使うと、お客様がよく使われるOracle Cloud Infrastructureの構成の発見、展開が簡単になります。
Terraform Module Registry
https://registry.terraform.io/ 
このリリースに関する詳細は、以下のリソースをチェックしてください。

[.NET, Kubernetes, Docker] Running .NET Core on the Oracle Container Engine for Kubernetes

原文はこちら。
https://blogs.oracle.com/cloudnative/dotnet-core-on-kubernetes

先日、Getting Function'l with Kubernetesイベントの参加者から.NET CoreアプリケーションをKubernetesで実行する件について質問をもらいました。
It's a Wrap! Getting Function'l with Kubernetes
https://blogs.oracle.com/cloudnative/its-a-wrap-getting-functionl-with-kubernetes
「直近では、クラウドネイティブアプリを稼働させることに関して、Windowsと.NETの世界はどうなっているのだろう」と思ったのですが、そのことをKubernetesに関するLinkedIn Learningチュートリアルを撮影したときに思い出しました。「WindowsでMinikubeを使ってKubernetesを実行するのはそれほど難しいことではないが、.NETアプリケーションを実行するのはどうなのだろう?」
Learning Kubernetes
https://www.linkedin.com/learning/learning-kubernetes
時間を掛けてエコシステムを調べました。このエントリでは、Oracle Container Engineでサンプルの.NETアプリケーションを実行する方法を説明します。
Container Engine for Kubernetes
https://cloud.oracle.com/containers/kubernetes-engine
コードに直接触れたい開発者は、以下のURLでコードを確認できます。
Running a dotnet app in Kubernetes
https://github.com/karthequian/dotnet-example
これらのすべてのサンプルをMac上に構築しましたが、どのプラットフォームを選択してもすべて実行できるはずです。何らかの理由で立ち往生した場合は、(原文のコメント欄に)コメントしてください。はまっている問題を再現して調査します。

以前.NETアプリケーションを書いたのは5年以上前なので、Macに必要なものを全てインストールする必要がありました。まず、.NET Core Web APIアプリケーションを作成するために、Microsoftが公開しているシンプルな.NETチュートリアルをはじめました。
.NET Tutorial - Hello World in 10 minutes
https://www.microsoft.com/net/learn/get-started-with-dotnet-tutorial
より多くのエンドポイントやコードを追加することを考えましたが、最終的にはチュートリアルでできあがるコードと同じように、シンプルにしました。読者を.NET REST APIの魔法で混乱させたかったのではなく、Kubernetesプラットフォームでアプリケーションを実行したかったからです。補足として、dotnetコマンドは非常にすばらしいです。開発、ビルド、テストを全て非常にシームレスに実現し、一日中dockerコマンドとkubectlコマンドを実行するクラウドネイティブ開発者にとって直覚的なコマンドです。

必要なもののインストールが終了したら、シンプルなASP.NET Core Web APIアプリケーションを以下のコマンドを使って作成しました。
~$ dotnet new webapi --auth None --no-https
本格的なアプリケーションの場合、機密データを扱っている場合は認証を設定し、httpsも有効にする必要があります。 このコマンドを実行すると、簡単なREST APIを作成する新しいwebappを作成します。以下のような出力が出ます。
~$ dotnet new webapi --auth None --no-https
The template "ASP.NET Core Web API" was created successfully.
Processing post-creation actions...
Running 'dotnet restore' on /Users/karthik/dev/src/github.com/karthequian/dotnet-example/dotnet-example.csproj...
  Restoring packages for /Users/karthik/dev/src/github.com/karthequian/dotnet-example/dotnet-example.csproj...
  Generating MSBuild file /Users/karthik/dev/src/github.com/karthequian/dotnet-example/obj/dotnet-example.csproj.nuget.g.props.
  Generating MSBuild file /Users/karthik/dev/src/github.com/karthequian/dotnet-example/obj/dotnet-example.csproj.nuget.g.targets.
  Restore completed in 1.42 sec for /Users/karthik/dev/src/github.com/karthequian/dotnet-example/dotnet-example.csproj.
Restore succeeded.
すばらしい!これで、この新規作成したアプリケーションを実行するために、 dotnet run をタイプできるようになりました。以下のようにAPIが起動するはずです。
~$ dotnet run
Using launch settings from /Users/karthik/dev/src/github.com/karthequian/dotnet-example/Properties/launchSettings.json...
: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[0]
  User profile is available. Using '/Users/karthik/.aspnet/DataProtection-Keys' as key repository; keys will not be encrypted at rest.
Hosting environment: Development
Content root path: /Users/karthik/dev/src/github.com/karthequian/dotnet-example
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.
テストしたい場合には、エンドポイント /api/values/ を以下のように呼び出すことで可能でした。値リストを取得したら、アプリケーションが期待通りに動作していることがわかります。
~$ curl localhost:5000/api/values/

["value1","value2"]
Macで.NET webappが動作したので、ここからは楽しいこと、dockerizeとkubifyをやっていきましょう。

Docker対応のため、以下のDockerドキュメントにあるガイドラインに従って、.NETアプリケーションのDockerイメージを構築しました。
Create a Dockerfile for an ASP.NET Core application
https://docs.docker.com/engine/examples/dotnetcore/#create-a-dockerfile-for-an-aspnet-core-application
エントリポイントの名前がプロジェクト名だったので、 dotnet-example.dll に変更しました。最終的なDockerfileが以下にあります。
Dockerfile
https://github.com/karthequian/dotnet-example/blob/master/Dockerfile
再実行してcurlでテスト後、このアプリケーションを karthequian/dotnetexample としてDockerストアにプッシュしてありますので、テスト目的でこのサンプルアプリケーションを実行できます。
karthequian/dotnetexample
https://store.docker.com/community/images/karthequian/dotnetexample
最後に、これをKubernetesで実行するため、デプロイメントとサービスを作成しました。
Deployment.yaml
https://github.com/karthequian/dotnet-example/blob/master/Deployment.yaml
このyamlファイルは、ホスト上のポート32000上で実行中のnodePortサービスを使用して、コンテナをデプロイメントとして公開します。利便性のため、Kubernetesでデプロイメントとサービスを実行するために以下のコマンドをタイプしてください。
kubectl apply -f https://raw.githubusercontent.com/karthequian/dotnet-example/master/Deployment.yaml
今回は概念実証(Proof of Concept)としてOracle Container Engineでアプリケーションを実行することにしましたが、任意のKubernetesディストリビューションで動作するはずです。今回はKubernetes 1.9.7クラスタでテストしましたが、最新バージョンとの前方互換性もあります。

以下は実行例です。
~$ kubectl apply -f https://raw.githubusercontent.com/karthequian/dotnet-example/master/Deployment.yaml
deployment "dotnetworld" created
service "dotnetworld" created
 ~$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
dotnetworld 1 1 1 1 20s
 ~$ kubectl get services
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
dotnetworld 10.96.79.93 80:32080/TCP 26s
kubernetes 10.96.0.1 443/TCP 30d
最後に、テストのために、以下に示すようにノードIPとポートに対して再度curlを使ってAPIを呼び出します。
~$ kubectl get services
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
dotnetworld 10.96.79.93 80:32080/TCP 26s
kubernetes 10.96.0.1 443/TCP 30d
 ~/dev/src/github.com/karthequian/dotnet-example$ kubectl get nodes
NAME STATUS AGE VERSION
129.146.123.174 Ready 30d v1.9.7
129.146.133.234 Ready 30d v1.9.7
129.146.162.102 Ready 30d v1.9.7
 ~$ curl 129.146.162.102:32080/api/values
["value1","value2"]
Oracle Container Service for Kubernetesで管理されたKubernetes 1.9.7で動作する、Dockerコンテナ化され、Macでビルドされた.NET Core Webアプリケーションができあがりました。時間がかかりそうに思われるかもしれませんが、およそ1時間で全て完了しており、全く苦労はありませんでした。

問題に遭遇したり、質問があったりする場合には、(以下の原文の)コメント欄からコメントをお寄せいただくか、@iteration1 へのメンション、またはGitHubのリポジトリでIssueを立ててお知らせください。

[Kubernetes, WLS] Voyager/HAProxy as Load Balancer to Weblogic Domains in Kubernetes

原文はこちら。
https://blogs.oracle.com/weblogicserver/voyagerhaproxy-as-load-balancer-to-weblogic-domains-in-kubernetes

Overview

負荷分散は、スケーラブルで復元力のあるアプリケーションを構築するために広く使用されているテクノロジーです。負荷分散の主な機能は、サーバーの監視と、ネットワークトラフィックの複数のサーバー(Webアプリケーション、データベースなど)への分散です。Kubernetesで動作するコンテナ化されたアプリケーションでは、負荷分散も必要です。Oracle WebLogic Server Kubernetes Operator version 1.0で、Voyager/HAProxyのサポートを追加しました。create-weblogic-domain.shスクリプトを拡張してVoyager/HAProxyをすぐに使用できるようにしています。
Oracle Weblogic Server Kubernetes Operator
https://github.com/oracle/weblogic-kubernetes-operator/tree/release/1.0
このスクリプトは、1個のWebLogicドメイン/クラスタのサーバへの負荷分散をサポートしています。このエントリでは、Kubernetesの複数のWebLogicドメインにデプロイされたアプリケーションに対して負荷分散のサポートを拡張するためのVoyager/HAProxyの設定方法を説明します。

Basics of Voyager/HAProxy

HAProxyとVoyagerに詳しくない方は、HAProxyとVoyagerの基本を時間を掛けて学ぶ価値があります。

HAProxyは、TCPおよびHTTPベースのアプリケーション用の可用性の高いロードバランサとプロキシサーバを提供する、無料のオープンソース・ソフトウェアです。(プロセッサ速度とメモリ使用量の面で)高速で効率的であることはよく知られています。HAProxyの初心者ガイドは以下からどうぞ。
HAProxy Starter Guide version 1.9-dev1
http://cbonte.github.io/haproxy-dconv/1.9/intro.html
VoyagerはHAProxyを使うIngressコントローラです(IngressについてはKubernetesのドキュメントを参照してください)。
Ingress
https://kubernetes.io/docs/concepts/services-networking/ingress/
Kubernetesクラスタにインストールすると、VoyagerオペレータはKubernetes IngressリソースとVoyager自身のIngress CRDを監視し、状況に応じてHAProxyインスタンスを自動作成、更新、削除します。 Voyagerオペレータの仕組みを理解するには、voyagerの概要をご覧ください。
Voyager Overview
https://appscode.com/products/voyager/7.1.1/concepts/overview/

Running WebLogic Domains in Kubernetes

wls-operator-quickstartプロジェクトをGitHubからあなたのローカル環境にチェックアウトしてください。このプロジェクトを使うと、最小限の作業でWebLogic Operatorとドメインを設定できます。READMEのPre-Requirementsの章に記載の手順を実行して、ローカル環境を構成してください。
Quick Start of WLS Operator
https://github.com/lilyhe123/wls-operator-quickstart
wls-operator-quickstartプロジェクトとWebLogic Operatorを使用して、Kubernetes上で実行される2つのWebLogicドメインを、それぞれ独自の名前空間に設定します。
  • 'domain1'という名前のドメインは名前空間 'default'で実行され、2個の管理対象サーバ 'domain1-managed-server1'と 'domain1-managed-server2'を含む 'cluster-1'という1個のクラスタを有します。
  • 'domain2'という名前のドメインは名前空間 'test1'で実行され、2個の管理対象サーバ 'domain2-managed-server1'と 'domain2-managed-server2'を含む 'cluster-1'という1個のクラスタを有します。
  • Webアプリケーション 'testwebapp.war' は、domain1とdomain2の両方のクラスタに別々にデプロイされます。このWebアプリケーションには、どちらの管理対象サーバがHTTPリクエストを処理しているかを表示するデフォルトページがあります。
次の手順を実行して、HAProxyの背後にあるWebLogicドメインを準備します。
# change directory to root folder of wls-operator-quickstart
$ cd xxx/wls-operator-quickstart

# Build and deploy weblogic operator
$ ./operator.sh create

# Create domain1. Change value of `loadBalancer` to `NONE` in domain1-inputs.yaml before run.
$ ./domain.sh create

# Create domain2. Change value of `loadBalancer` to `NONE` in domain2-inputs.yaml before run.
$ ./domain.sh create -d domain2 -n test1

# Install Voyager
$ kubectl create namespace voyager
$ curl -fsSL https://raw.githubusercontent.com/appscode/voyager/6.0.0/hack/deploy/voyager.sh \
    | bash -s -- --provider=baremetal --namespace=voyager
以下のようにWebLogicドメインの状態を確認します。
# Check status of domain1
$ kubectl get all
NAME                          READY     STATUS    RESTARTS   AGE
pod/domain1-admin-server      1/1       Running   0          5h
pod/domain1-managed-server1   1/1       Running   0          5h
pod/domain1-managed-server2   1/1       Running   0          5h

NAME                                                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)           AGE
service/domain1-admin-server                        NodePort    10.105.135.58    <none>        7001:30705/TCP    5h
service/domain1-admin-server-extchannel-t3channel   NodePort    10.111.9.15      <none>        30015:30015/TCP   5h
service/domain1-cluster-cluster-1                   ClusterIP   10.108.34.66     <none>        8001/TCP          5h
service/domain1-managed-server1                     ClusterIP   10.107.185.196   <none>        8001/TCP          5h
service/domain1-managed-server2                     ClusterIP   10.96.86.209     <none>        8001/TCP          5h
service/kubernetes                                  ClusterIP   10.96.0.1        <none>        443/TCP           5h

# Verify web app in domain1 via running curl on admin server pod to access the cluster service
$ kubectl -n default exec -it domain1-admin-server -- curl http://domain1-cluster-cluster-1:8001/testwebapp/

# Check status of domain2
$ kubectl -n test1 get all
NAME                          READY     STATUS    RESTARTS   AGE
pod/domain2-admin-server      1/1       Running   0          5h
pod/domain2-managed-server1   1/1       Running   0          5h
pod/domain2-managed-server2   1/1       Running   0          5h

NAME                                                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)           AGE
service/domain2-admin-server                        NodePort    10.97.77.35      <none>        7001:30701/TCP    5h
service/domain2-admin-server-extchannel-t3channel   NodePort    10.98.239.28     <none>        30012:30012/TCP   5h
service/domain2-cluster-cluster-1                   ClusterIP   10.102.228.204   <none>        8001/TCP          5h
service/domain2-managed-server1                     ClusterIP   10.96.59.190     <none>        8001/TCP          5h
service/domain2-managed-server2                     ClusterIP   10.101.102.102   <none>        8001/TCP          5h

# Verify the web app in domain2 via running curl in admin server pod to access the cluster service
$ kubectl -n test1 exec -it domain2-admin-server -- curl http://domain2-cluster-cluster-1:8001/testwebapp/
Kubernetesで両WebLogicドメインが稼働してから、異なるHAProxy機能を使って、2個のWebLogicドメインに帯する単一エントリポイントとしてVoyagerを構成します。

Using Host Name-Based Routing

Ingressリソースファイル 'voyager-host-routing.yaml' を作成します。このファイルにはホスト名ベース・ルーティングを使ったIngressリソースが含まれています。
apiVersion: voyager.appscode.com/v1beta1
kind: Ingress
metadata:
  name: hostname-routing 
  namespace: default
  annotations:
    ingress.appscode.com/type: 'NodePort'
    ingress.appscode.com/stats: 'true'
    ingress.appscode.com/affinity: 'cookie'
spec:
  rules:
  - host: domain1.org
    http:
      nodePort: '30305'
      paths:
      - backend:
          serviceName: domain1-cluster-cluster-1
          servicePort: '8001'
  - host: domain2.org
    http:
      nodePort: '30305'
      paths:
      - backend:
          serviceName: domain2-cluster-cluster-1.test1
          servicePort: '8001'
YAMLファイルを以下のコマンドを使ってデプロイします。
kubectl create -f voyager-host-routing.yaml

Testing Load Balancing with Host Name-Based Routing

ホスト名ベース・ルーティングを行うには、通常はDNSの変更を伴う仮想ホスティングを設定する必要があります。デモ目的のため、curlコマンドを使用して、ホスト名ベース・ルーティングによるロードバランシングをシミュレートします。
# Verify load balancing on domain1
$ curl --silent -H 'host: domain1.org' http://${HOSTNAME}:30305/testwebapp/ | grep InetAddress.hostname
    <li>InetAddress.hostname: domain1-managed-server1
$ curl --silent -H 'host: domain1.org' http://${HOSTNAME}:30305/testwebapp/ | grep InetAddress.hostname
    <li>InetAddress.hostname: domain1-managed-server2

# Verify load balancing on domain2
$ curl --silent -H 'host: domain2.org' http://${HOSTNAME}:30305/testwebapp/ | grep InetAddress.hostname
    <li>InetAddress.hostname: domain2-managed-server1
$ curl --silent -H 'host: domain2.org' http://${HOSTNAME}:30305/testwebapp/ | grep InetAddress.hostname
    <li>InetAddress.hostname: domain2-managed-server2
結果は以下の通りです。
  • ホスト名 'domain1.org' を指定すると、リクエストはdomain1の管理対象サーバで処理される。
  • ホスト名 'domain2.org' を指定すると、リクエストはdomain2の管理対象サーバで処理される。

Using Path-Based Routing and URL Rewriting

この章では、URL書き換えによるパスベース・ルーティングを使用して、ホスト名ベース・ルーティングと同じ動作を実現します。

Ingressリソースファイル 'voyager-path-routing.yaml'を作成します。
apiVersion: voyager.appscode.com/v1beta1
kind: Ingress
metadata:
  name: path-routing
  namespace: default
  annotations:
    ingress.appscode.com/type: 'NodePort'
    ingress.appscode.com/stats: 'true'
    ingress.appscode.com/rewrite-target: "/testwebapp"
spec:
  rules:
  - host: '*'
    http:
      nodePort: '30307'
      paths:
      - path: /domain1
        backend:
          serviceName: domain1-cluster-cluster-1
          servicePort: '8001'
      - path: /domain2
        backend:
          serviceName: domain2-cluster-cluster-1.test1
          servicePort: '8001' 
YAMLファイルを以下のコマンドを使ってデプロイします。
kubectl create -f voyager-path-routing.yaml

Verify Load Balancing with Path-Based Routing

負荷分散の結果を検証するため、curlコマンドを使います。別の方法として、Webブラウザから直接URLにアクセスすることもできます。
# Verify load balancing on domain1
$ curl --silent http://${HOSTNAME}:30307/domain1/ | grep InetAddress.hostname
    <li>InetAddress.hostname: domain1-managed-server1
$ curl --silent http://${HOSTNAME}:30307/domain1/ | grep InetAddress.hostname
    <li>InetAddress.hostname: domain1-managed-server2

# Verify load balancing on domain2
$ curl --silent http://${HOSTNAME}:30307/domain2/ | grep InetAddress.hostname
    <li>InetAddress.hostname: domain2-managed-server1
$ curl --silent http://${HOSTNAME}:30307/domain2/ | grep InetAddress.hostname
    <li>InetAddress.hostname: domain2-managed-server2
異なるURLを指定してパスベース・ルーティングによりトラフィックが異なるWebLogicドメインに振り分けられることを確認できます。URL書き換え機能を使えば、最終的に各ドメインの同じコンテキスト・パスを持つWebアプリケーションにアクセスできます。

Cleanup

このエントリの手順を使った演習終了後は、Kubernetesで作成した全てのリソースをクリーンアップしたいと思うことでしょう。
# Cleanup voyager ingress resources
$ kubectl delete -f voyager-host-routing.yaml
$ kubectl delete -f voyager-path-routing.yaml
 
# Uninstall Voyager
$ curl -fsSL https://raw.githubusercontent.com/appscode/voyager/6.0.0/hack/deploy/voyager.sh \
      | bash -s -- --provider=baremetal --namespace=voyager --uninstall --purge

# Delete wls domains and wls operator
$ cd <QUICKSTART_ROOT>
$ ./domain.sh delete --clean-all
$ ./domain.sh delete -d domain2 -n test1 --clean-all
$ ./operator.sh delete

Summary

このエントリでは、Voyagerロードバランサを構成し、WebLogic ServerドメインにデプロイしたTCPベースおよびHTTPベースのアプリケーションのための、可用性の高いリクエストの負荷分散とプロキシサーバ機能を提供する方法を説明しました。このエントリで提供したサンプルでは、Voyagerを複数のWebLogicドメインの前の単一ポイントとして使用する方法を説明しました。ホスト名ベースルーティング、パスベースルーティング、URL書き換えなどのVoyager機能の使用方法を示す例を示しました。このブログが皆様のお役に立つことを願いつつ、是非Kubernetes上のWebLogic環境でVoyagerを使用してみてください。

[Java] End of Public Updates is a Process, not an Event

原文はこちら。
https://blogs.oracle.com/java-platform-group/end-of-public-updates-is-a-process%2c-not-an-event

And so, from hour to hour, we ripe and ripe.
And then, from hour to hour, we rot and rot;
And thereby hangs a tale.


Shakespeare
成功しているソフトウェアプラットフォームとその周辺のエコシステムには、ポジティブなフィードバックサイクルとネガティブなフィードバックサイクルの両方と共生する関係にあります。開発者はプラットフォームを使用して以前では簡単に解決できなかった問題を解決するための製品を構築し、プラットフォームは時間と共に進化し、新しいユースケースに対してもよりフィットするような新機能を提供します。同時に、成功したプラットフォームは、自身のまわりの技術環境の変化に適応するため、あまり使用されていないレガシー機能を廃止したり削除したりしています。

このプロセスは常に動いています。プラットフォームの新バージョンがリリースされると、旧バージョン(の利用)が徐々に減少していくため、プラットフォームプロバイダーは過去ではなく将来に向けて労力を集中できます。

Javaというエコシステムは、10回の主要なプラットフォームの改訂を通じ、このプロセスを何十年にもわたって成功させてきました。長期にわたる強力な下位互換性により、エコシステムに対する投資が保護されます。それと同時に、時間の経過と共にある程度の適応(の作業)は避けられません。そのため、プラットフォームの継続的な成功のためには、既存の投資を保護しながら、大量のエコシステムを最新のリリースに移行する必要があります。

Sun Microsystemsは、これらの2つの目標のバランスをとる戦略を確立しました。それは、一定期間無料の公開アップデートを提供すると共に、異なるニーズを持つユーザーに商業的な長期サポートを提供する、というものです。この戦略によって、あるプラットフォームのバージョンから別のプラットフォームのバージョンに自分のスケジュールで移行したいユーザー、もしくは全く移行したくないユーザーに対して、セキュリティ、パフォーマンス、その他のアップデートを商用ベースで提供しながら、エコシステムの大半がリリースサイクルに無料で追随できます。

Every new beginning comes from some other beginning’s end

Java SE 8は、2014年3月18日にリリースされ、2019年1月にOracle Java SE 8の商用利用者向けのPublic Updateが終了するまで、Oracleはおよそ5年間にわたり無料でPublic Updateを提供してきました。

Oracle Java SE Subscriptionを使うと、商用ユーザーは、拡張機能やクリティカルなパッチを含むOracle Java SE 8のサポートと定期的なアップデートをより長期間にわたって受けることができます。例えば、Java Web Startテクノロジは、少なくとも2025年3月までOracle Java SE 8において商用サポートを継続します。
A Quick Summary on the new Java SE Subscription
https://blogs.oracle.com/java-platform-group/a-quick-summary-on-the-new-java-se-subscription
https://orablogs-jp.blogspot.com/2018/06/a-quick-summary-on-new-java-se.html
Oracle Java SE Roadmap
(日本語)https://www.oracle.com/technetwork/jp/java/eol-135779-ja.html
(英語)http://www.oracle.com/technetwork/java/eol-135779.html
Oracle Java SE 8のすべてのユーザーが商用使用するわけではありません。ある人はゲームをしたり、またある人は消費者向け生産性アプリケーションを実行したりするのに使っています。Oracleは、少なくとも2020年12月まで個人ユーザー向けのOracle Java SE 8のパブリック・アップデートを無料で提供します。その間、個人ユーザーはアプリケーション・プロバイダに連絡し、アプリケーションを最新バージョンのJavaに移行するよう提言したり、代わりのアプリケーションに切り替えたりしてください。
Java Client Roadmap Update
http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf

Upgrade to JDK 10

Oracle Java SE 8から最短のアップグレードパスは(現時点では)JDK 10です。アプリケーション開発者向けの説明は、「Oracle JDK 10移行ガイド」を参照ください。
Oracle JDK 移行ガイド リリース10
https://docs.oracle.com/javase/jp/10/migrate/toc.htm
Oracle JDK Migration Guide Release 10
https://docs.oracle.com/javase/10/migrate/toc.htm
Oracle JRockitからの移行ユーザー向けの説明もございます。
JRockitからHotSpotへの移行ガイド リリース10
https://docs.oracle.com/javase/jp/10/jrockit-hotspot/toc.htm
JRockit to HotSpot Migration Guide Release 10
https://docs.oracle.com/javase/10/jrockit-hotspot/toc.htm
このエントリの執筆時点における、Oracleからダウンロード可能な最新のJavaリリースはJDK 10.0.2です。 これはセキュリティベースライン、つまり、最新のOracle Critical Patch Updateで説明されているセキュリティ脆弱性に対する修正が含まれています。
Java SE Downloads
http://www.oracle.com/technetwork/java/javase/downloads/index.html
JDK 10.0.2 Release Notes
http://www.oracle.com/technetwork/java/javase/10-0-2-relnotes-4477557.html

Upgrade to JDK 11

JDK 10は2018年9月下旬にEoLを迎えます。以後のOracle Java SE 8からのアップグレードパスはJDK 11です。Oracle Java SE 11は長期サポート(LTS)リリースであり、 6カ月サイクルになってからのはじめてのリリースです。そのため、Java SE 12リリース後も、Oracle Premier Supportと定期的なアップデートリリースがOracleのお客様に対し提供されます。これにより、Oracle Java SE 11はISVや他の商用ユーザーにとって魅力的な移行ターゲットになります。

JDK 11はまだリリースされていないため、JDK 11を移行先としている開発者の方々は、Java SE 8からの移行作業として、まずJDK 10でアプリケーションを正常に動作させることから開始することを推奨します。以前より速い半年ごとのリリースサイクルゆえに、JDK 10とJDK 11の間の変更の数は、JDK 8とJDK 10の間の変更の数よりはるかに少ないからです。
Fast Forward To 11
https://blogs.oracle.com/java-platform-group/fast-forward-to-11-v2https://orablogs-jp.blogspot.com/2018/09/fast-forward-to-11.html
アプリケーションがJDK 10で問題なく動作したら、開発者はJDK 11リリース候補版ビルドでテストをし、今月待つにリリースされたときにJDK 11への移行準備が完了するようにしてください。
JDK 11 Early-Access Builds
http://jdk.java.net/11/

Upgrade to JDK 12

アプリケーションをOracle Java SE 8からJDK 12に直接移行したい開発者は、同じ移行モデルに従う必要があります。つまり、まずはセキュリティベースラインでの最新のリリース、つまり現在のJDK 10.0.2への移行作業に力を注ぎ、その後アプリケーションが正常に動作したら、最新のJDK 11リリースへの段階的移行に進みます。

アプリケーションがJDK 11で正常に動作したら、開発者はJDK 12 Early Accessビルドでテストを開始してください。
JDK 12 Early-Access Builds
http://jdk.java.net/12/
OracleはJDK 12 Early Accessビルドをクラスパス例外付きGNU General Public Licenseバージョン2の下で定期的に公開しています。
GNU General Public License, version 2, with the Classpath Exception
http://openjdk.java.net/legal/gplv2+ce.html
これらのビルドを使用すると、開発者は新しいJDK 12の機能を評価できるのと共に、既存の機能に対する変更が自社のアプリケーションに及ぼす影響をテストできます。
JDK 12
http://openjdk.java.net/projects/jdk/12/
JDK 12 Early-Access Release Notes
http://jdk.java.net/12/release-notes

Staying with OpenJDK 8 after January 2019

現時点で、OracleのエンジニアはOpenJDKコミュニティのOpenJDK 8アップデートのメンテナンス作業の大半を4年半以上引っ張ってきました。
JDK 8 Update Releases
http://openjdk.java.net/projects/jdk8u/
少なくとも2019年1月まで継続していきますが、その後は、これまでのOpenJDK 6やOpenJDK 7 Updatesの場合と同様、OracleからのコントリビュータはOpenJDKコミュニティにおける彼らの労力をOpenJDK 8 Updatesから現在のJDKリリースに集中させる可能性があります。
[8u-communication] Oracle's plans to contribute to JDK 8 Updates Project in OpenJDK after Java SE 8 End of Public Updates
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-March/007341.html
これまでのように、適切なパーティーが2019年1月以降OpenJDK 8 Updatesのメンテナンスを継続する場合には、OpenJDKコミュニティにおいて最善の移行方法について議論する予定です。

そのため、Oracleエンジニアの移動後にOpenJDK 8を使用し続けたいユーザーは、2019年1月までにプロジェクトのメーリングリスト(jdk8u-dev)に登録した上で、引き続きメンテナンスしてくれるコントリビュータと、ご自身の期待や計画について議論をして、その時点でのOpenJDK 8で利用可能なサポートの範囲をよりよく理解してください。
jdk8u-dev -- Technical discussion related to the JDK 8 Updates Project
http://mail.openjdk.java.net/mailman/listinfo/jdk8u-dev

[Integration, Cloud] Enabling the Future Today - Feature Flags in Oracle Integration Cloud

原文はこちら。
https://blogs.oracle.com/integration/enabling-the-future-today-feature-flags-in-oracle-integration-cloud

Enabling the Future Today

Integration Cloud内で、全てのお客様に全面開放せずに新機能のトライアルを実現するモデルに移行しつつあります。(クラウドなので)全てのお客様が同じコードベースを実行しているわけですが、機能フラグによって特定のインスタンスで利用可能なものを管理・制御しています。そのようなことをやっている理由はいくつかあります。
  • ユーザーベース全体にロールアウトする前に新機能のフィードバックを得たい
  • 管理された方法で「野放し」にして新機能をテストしたい
  • 予期せぬ問題が発生する可能性のある新機能をロールバックできるようにしたい

How It Works

各新機能に対し、その利用可否を制御するために使うフラグがあります。例えば、小さなフットプリントのOICエージェントのフラグはoic.adapters.connectivity-agent.light-weight-agentでした。このフラグが特定のOICインスタンスで有効になっている場合、軽量の接続エージェントをダウンロードできます。同じコードを実行しているけれどもフラグがOffの他のOICインスタンスでは、新しいエージェントは提供されません。

中央のシステムからフラグを制御しています。Oracleの開発チームやオペレーションチームがリアルタイムで更新できます。つまり、機能フラグは非常に迅速にOnにでき、問題が発生した場合は無効にすることもできます。

Feature Flag Lifecycle

機能フラグには下図のようなライフサイクルがあります。


各ステージについて以下で説明します。

Internal Only

現在利用できないインスタンスでプロダクションマネージャーが機能のデモをするのをご覧になったことがあるかと思います。もしProduction環境のPodを使っている場合、これらのPodは社内ユーザーのみが利用可能なものである可能性があります。これは、お客様向けに利用可能にする前に内部的に試している状態です。内部的にこの機能の評価に問題がなければ、選ばれたお客様とこの機能を共有し、この機能をFeature Controlledフェーズに移行できる状態に到達します。この段階での変更はコードの変更は不要で、内部の承認プロセスで機能を有効にするだけです。

Feature Controlled

機能がFeature Controlledフェーズに到達すると、お客様はお使いのOICインスタンスでフラグを有効にするようにリクエストできます。承認された場合、リクエストされたインスタンスのフラグが有効に設定され、数分以内に機能が使用可能になります。この場合も、お客様のインスタンスにおけるコードの変更はなく、中央の機能フラグサーバでフラグステータスを無効から有効に変更するだけです。

Feature Controlled General Availability

機能の安定性に問題がないと確認できれば、すべてのインスタンスに対して機能を有効化します。 この場合もコードの変更は不要です。特定のお客様で問題が発生した場合、その機能を無効にするか、ロールバックすることができるように、フラグをそのまま残しています。これは、機能の内部ユーザーやアーリーアダプタが遭遇しなかった問題が発生した場合の安全策です。

General Availability

最終的に、機能制御フラグが削除されます。これはエンドユーザーに影響はありません。コードパスをきれいに保ち、新しい機能で廃止された未使用のコードを削除できます。エンドユーザーはこの前後で差異を見つけることはできないでしょう。そのため、コードベースをきれいに保つ方法を説明するためだけと言及しておきます。

What Flags are Available?

以下の機能フラグが現在Feature Controlledフェーズで利用できるものです。これらの機能についてブログエントリで取り上げていく予定にしており、今後、機能の詳細を説明するブログエントリで詳細な説明をしていきます。新機能を追加すると、このエントリを更新していきます(以下は2018/09/13現在の内容です)。
Feature Flag NameDescriptionDetailed Explanation
oic.ics.console.diagnostics.oracle-litmus-support自動テストにおけるLitmusのサポートHow to use Litmus to create OIC Integration unit tests automatically and run them to catch regressions
https://blogs.oracle.com/integration/how-to-use-litmus-to-create-oic-integration-unit-tests-automatically-and-run-them-to-catch-regressions
https://orablogs-jp.blogspot.com/2018/09/how-to-use-litmus-to-create-oic.html
oic.adapter.connectivity-agent.ha接続エージェントのHAサポート
oic.ics.console.integration.throw-action統合にエラーをスローできる機能
oic.ics.console.integration.nested-try-scopes入れ子のスコープを作成できる機能
oic.cloudadapter.adapters.oraclehcmtbeTaleo Business Edition (TBE) Adapter
oic.cloudadapter.adapter.rightnow.mtom.uploadRightnowでMTOMとしてファイルをアップロードできる機能
oic.ics.mapper.jetmap-enablement新しいJet UI ベースのマッパー
oic.cloudadapter.adapters.epmOracle Enterprise Performance Management Adapter (EPM Adapter)
oic.insight.consoles.instanceprogressInsightインスタンスの詳細ページの異なる表示をサポート
oic.cloudadapter.adapter.utilities.wsdluploadUtilities adapterのインバウンド用にWSDLをアップロードできる機能
oic.ics.console.integration.layout擬似コードスタイル・レイアウトとして統合を表示
oic.ics.console.schedule.parameter-override-supportスケジュールパラメータのオーバーライドOverriding Schedule Parameters
https://blogs.oracle.com/integration/overriding-schedule-parameters
https://orablogs-jp.blogspot.com/2018/09/overriding-schedule-parameters.html

How to Request a Feature Flag

お客様のいずれかの環境で機能フラグを有効にするには、My Oracle Supportからサービスリクエスト(SR)を発行してリクエストする必要があります。
My Oracle Support
https://support.oracle.com
SRに以下の情報を記入してください。
  • 有効化したい機能フラグの名前
  • OICインスタンスのURL
  • OICインスタンスのバージョン情報ダイアログに記載の以下の情報

    • バージョン (例) 18.3.3.0.0 (180823.1018.14180)
    • データベース・スキーマのバージョン (例) 18.08.16
    • サービス・インスタンス (例) myinstance
    • アイデンティティ・ドメイン (例) idcs-xxxxxxxxxxxxxxx
    • サービスタイプ (例) Autonomous - 2
  • 有効化が必要な理由
    • 理由とユースケースを説明する(自由形式)
リクエストは承認のためにプロダクトマネージャーに提出されます。承認されると、リクエストが転送されて、要求された環境で機能が有効になります。

Caveats

機能にはいくつかの欠陥が残っている可能性があるため、Controlled Availabilityの状態です。一般提供に先んじて機能フラグで制御された機能を利用することにより、新機能のアーリーアダプターであることを意味していること、スムーズにご利用いただけるよう最善を尽くしていますが、問題にぶち当たる可能性があることにご注意ください。一般提供の前に、機能フラグで有効化している機能を変更しなければならない場合があります。ただ、これだけは知っておいて欲しいのですが、機能フラグを使用することで、当該機能を一般提供する前に、その機能を利用してメリットがあるユーザーに新機能をリリースすることができます。 この方法が、お客様とOracleの両者にとって良い、Win-Winな状態であると考えています。

Previous Flags Now Generally Available

以下は、制御対象の機能がOracle Integration Cloudのすべてのインスタンスで使用可能になったために使用されなくなったフラグです。User ManagedのOracle Integration Cloudを使用している場合、これらの機能を使用するためには、最新のリリースにアップグレードする必要があることに注意してください。
Feature Flag NameDescriptionDetailed Explanation
oic.cloudadapter.adapter.hcm.dataExtractHCM AdapterでのData ExtractConfiguring the Extract Bulk Data Option in an Integration
https://docs.oracle.com/en/cloud/paas/integration-cloud/hcm-adapter/sample-integration-flow-demonstrate-extract-bulk-data-option.html
oic.adapters.hcm-cloud.atom-feed-supportHCM AdapterでのAtom FeedのサポートSubscribing to Atom Feeds in a Scheduled Integration
https://docs.oracle.com/en/cloud/paas/integration-cloud/hcm-adapter/subscribing-atom-feeds-scheduled-integration.html
oic.adapters.connectivity-agent.light-weight-agent軽量な接続性エージェントManaging the Agent Group and the On-Premises Connectivity Agent
https://docs.oracle.com/en/cloud/paas/integration-cloud/integrations-user/managing-agent-groups-and-connectivity-agent.html
oic.cloudadapter.adapter.rightnow.queryCSV.ValidationRightnow adapterでの QueryCSVの検証Specifying QueryCSV Statements when Configuring the Oracle RightNow Cloud Adapter as an Invoke
https://docs.oracle.com/en/cloud/paas/integration-cloud/rightnow-adapter/using-query-csv-invoke-oracle-rightnow-cloud-adapter.html
oic.cloudadapter.adapter.database.batchSelectOracle Database
Adapterを使った、表に対する操作(Select、 Mergeの機能強化)
oic.cloudadapter.adapter.database.batchInsertUpdateOracle Database
Adapterを使った、表に対する操作(Insert、 Updateの機能強化)
oic.cloudadapter.adapters.dbaasdatabaseOracle DBaaS Adapterを使った、表に対する操作(Insert、 Update、Merge、Selectの機能強化)
oic.cloudadapter.adapter.rightnow.noSchema
oic.cloudadapter.adapter.rest.oauth10aPolicyREST AdapterでのOAuthのサポート(OAuth2ではない)
oic.cloudadapter.adapter.rightnow.fileDownloadRightnow (Service Cloud) Adapterでのファイルダウンロード
oic.ics.console.integration.inline-menuドラッグ&ドロップではなく、キャンバスからアクション/トリガー/呼び出しをインラインで追加できるようにする
oic.cloudadapter.adapters.rest_opaOracle Policy Automation Adapter
oic.ics.mapper.encode-decode-on-filesファイルのBase64 Encode/Decode
oic.cloudadapter.adapter.soap.enableMtomSOAP AdapterでのMTOMのサポート
oic.ics.console.connection.soap.uploadzipSOAP AdapterでのZipファイルのアップロード

[Integration, Cloud] Overriding Schedule Parameters

原文はこちら。
https://blogs.oracle.com/integration/overriding-schedule-parameters

A quick recap on schedule parameters

Schedule Parameter(スケジュール・パラメータ)機能は、Scheduled Orchestration Integrations(スケジュールされたオーケストレーション統合)のスカラー変数の追加をサポートします。これらのパラメータ値は、特定の統合のスケジュール実行にわたって使用でき、Assign(割り当て)などのダウンストリームアクションを使って上書きできます。1個の統合に対し、最大5個のスケジュールパラメータを定義できます。

スケジュール・パラメータを使用すると、スケジュール・パラメータで以下のような要件に対応できます。
  1. データの重複処理を避けるため、スケジュールされた統合の最終実行時間(位置)を維持したい
  2. 特定のディレクトリやエリア、リージョン向けの情報を処理したい
上記の通り、スケジュール・パラメータはAssignを使ってオーケストレーション内で更新できます。

この機能の詳細は以下のドキュメントをご覧ください。
Oracle® Cloud
Using Oracle Integration Cloud Service
Creating Parameters in Scheduled Integrations
https://docs.oracle.com/en/cloud/paas/integration-cloud-service/icsug/creating-scheduled-integrations.html#GUID-219DF3E8-2753-435F-9A46-518989A290A8

How to override schedule parameters

現時点では、異なるパラメータ値を持つ(スケジュールパラメータを含む)スケジュールされた統合をユーザが呼び出そうとする場合、統合を非アクティブ化して新しいデフォルト値を設定し、再度アクティブ化する必要があります。

スケジュールパラメータのオーバーライド機能を有効にすると、ユーザーは、非アクティブ化せずに統合を呼び出しながらパラメータ値を指定できます。この機能は、以下の機能フラグで制御されています。
oic.ics.console.schedule.parameter-override-support
この機能を有効化すると、スケジュールパラメータが定義された統合でユーザーが[Submit Now](今すぐ送信)または[Start Schedule](スケジュールを開始)をクリックすると、ポップアップが表示され、ユーザーはパラメータのDefault Value(デフォルト値)とCurrent Value(現在値)を表示し、必要に応じてNew Value(新しい値)を入力してCurrent ValueやDefault Valueを上書きできます。

New Valueはオプションです。新規設定する値を指定しない場合、次回の実行時にはCurrent Valueを使います。Current Valueも設定がない場合、Default Valueを使います。

統合がAssignを使ってこれらのスケジュールパラメータの値を更新すると、更新された値が保存され、次回実行時のCurrent Valueとして利用されます。

当該統合において、Submit NowとStart Scheduleユースケース用のスケジュールパラメータ値は共有されません。

したがって、ユーザがSubmit Now操作の一環で新しいスケジュールパラメータ値を定義した場合、その値はその後のすべてのSubmit Now操作のCurrent Valueとして保存され、表示されます。Start Scheduleのパラメータ値の保存内容に影響を与えることはありません。

[Cloud] General Availability of Virtual Machines with NVIDIA GPUs on Oracle Cloud Infrastructure

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/general-availability-of-virtual-machines-with-nvidia-gpus-on-oracle-cloud-infrastructure

数週間前、ドイツのISC High Performance 2018というコンファレンスで、NVIDIA Tesla Volta GPU付き仮想マシンインスタンスのプレビュー提供を発表しました。
Oracle’s Continued HPC Investments at ISC High Performance 2018
https://blogs.oracle.com/cloud-infrastructure/oracle-continued-hpc-investments-at-isc-high-performance-2018
お客様は、エンジニアリング・シミュレーションや医学研究から、TensorFlowなどのフレームワークを使用した機械学習トレーニングなどの最新のワークロードまでのさまざまな用途にOracle Cloud InfrastructureのGPUを活用されています。
Oracle Cloud Infrastructure - High Performance Computing
https://cloud.oracle.com/iaas/hpc
今週東京で開催されるNVIDIAのGPU Technology Conferenceに参加しますが、そのまさにこの週、London(UK)およびAshburn(US)リージョンでNVIDIA Tesla Volta V100 GPU搭載の仮想マシンの一般提供いたしました。この発表ができることに興奮しています。ログインすると、通常のOracle Cloud Infrastructureのインスタンスを立ち上げるのと全く同じ方法でこれらのインスタンスを起動できます。

これらの仮想マシンは、今年早々に導入されたベアメタルComputeインスタンスに参加しており、DNNトレーニングなどの非常に計算集約型で高速化されたワークロードや、GROMACSやNAMDなどの従来の高性能コンピューティング(HPC)アプリケーションを実行するサーバー全体を提供します。

最後に、新しいコスト効果の高いGPUオプションとして、Pascal世代のGPUインスタンスがAshburn(US)とFrankfurt(ドイツ)リージョンの仮想マシンで利用できるようになりました。誰にとってもうれしいものがここにあります。

Instance ShapeGPU TypeGPU(s)Core(s)Memory (GB)InterconnectPrice (GPU/Hr)
BM.GPU3.8Tesla V100 (SXM2)852768P2P over NVLINK$2.25
VM.GPU3.4Tesla V100 (SXM2)424356P2P over NVLINK$2.25
VM.GPU3.2Tesla V100 (SXM2)212178P2P over NVLINK$2.25
VM.GPU3.1Tesla V100 (SXM2)1686N/A$2.25
BM.GPU2.2Tesla P100228192N/A$1.275
VM.GPU2.1Tesla P100112104N/A$1.275

また、NVIDIA GPU Cloudを使うと、事前設定済みのイメージをNGCの資格情報とともにデプロイするだけで、HPCアプリケーションやAIアプリケーションのコンテナを起動できます。詳しい手順については以下のURLもしくはGPU製品のページをご覧ください。
Using NVIDIA GPU Cloud with Oracle Cloud Infrastructure
https://docs.cloud.oracle.com/iaas/Content/Compute/References/ngcimage.htm
NVIDIA & Oracle Cloud Infrastructure GPU Cloud Platform
https://cloud.oracle.com/iaas/gpu
最後に、今週のNVIDIAのGTC Conferenceの展示ホールにお越しになってOracle Cloud Infrastructureについてエンジニアリングチームと会話いただけます。また、9月13日午後12時10分開始のブレイクアウトセッションで詳細を知っていただくこともできます。是非お越しください。
GTC Japan 2018
https://www.nvidia.com/ja-jp/gtc/
Advantages of a Bare-Metal Cloud for GPU Workloads
https://www.nvidia.com/ja-jp/gtc/sessions/?sid=2018-1105

[Java] Oracle JDK Releases for Java 11 and Later

原文はこちら。
https://blogs.oracle.com/java-platform-group/oracle-jdk-releases-for-java-11-and-later

Exec Summary

Starting with Java 11から、Oracleはクラスパス例外付きGNU General Public License v2(GPLv2+CPE)と、Oracle製品やサービスの一部としてのOracle JDKで使用したり、オープンソースソフトウェアの利用したくなかったりする方向けに商用ライセンス、その両方でJDKを提供します。
GNU General Public License, version 2, with the Classpath Exception
http://openjdk.java.net/legal/gplv2+ce.html
オープンソースライセンスと商用ライセンスを組み合わせることで、フリーのライセンスと有料の商用ライセンスを組み合わせたこれまでの"BCL"ライセンスを置き換えます。
Oracle Binary Code License Agreement for the Java SE Platform Products and JavaFX
https://java.com/license
各ライセンスごとに異なるビルドが用意されていますが、これらのビルドは、表装とパッケージが異なるとはいえ、機能的に同じです。詳細は後述します。

From the BCL to the GPL

Binary Code License for Oracle Java SE technologies(BCL)は、10年以上も前からOracle Java SEテクノロジの主要なライセンスとなっています。
Oracle Binary Code License Agreement for the Java SE Platform Products and JavaFX
https://java.com/license
BCLは、特定の条件下でライセンス料なしでの使用を許可します。今後の作業を簡素化するために、OracleはLinuxプラットフォームと同じライセンス・モデルを使用し、Java 9のオープンソースのOpenJDKビルドの提供を開始しました。
Java Development Kit builds, from Oracle
http://jdk.java.net/
Oracle Java SEバイナリを無料で入手することに慣れている場合は、 jdk.java.net で入手可能なOracleのOpenJDKビルドをそのまま使用してください。Oracle Java SEバイナリをOracleの製品またはサービスの一部として使用している場合は、My Oracle Support(MOS)およびその他の場所からOracle JDKリリースを引き続き入手できます。
My Oracle Support
https://support.oracle.com

Functionally identical and interchangeable...

OracleのBCLライセンスJDKには、これまでOpenJDKビルドでは利用できなかった「商用機能」が含まれていました。しかし昨年、約束通りOracleはOpenJDKコミュニティに次のような機能を寄贈しました。
Accelerating the JDK release cadence
http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
したがって、Java 11以後はOracle JDKビルドとOpenJDKビルドは本質的に同じです。
OpenJDK
http://jdk.java.net/

...yet with some cosmetic and packaging differences

OpenJDKコントリビュータと議論する時間が必要ゆえに、意図的で表装的な違いが残っています。
  • Oracle JDK 11では、-XX:+UnlockCommercialFeaturesオプションを使用すると警告が発行されますが、OpenJDKビルドではこのオプションでエラーが発生します。このオプションはOpenJDKの一部ではないためです。OpenJDKには商用機能がないため、このオプションを追加することは意味がありません。Oracle JDK 10およびそれ以前のリリースのユーザーがOracle JDK 11以降に移行しやすくするためにこの違いが残ります。
  • Oracle JDK 11を構成し、Oracleの別の商用製品であるAdvanced Management Consoleに使用状況のログ・データを提供することができます。
    Advanced Management Console
    https://www.oracle.com/technetwork/java/javaseproducts/advanced-mgmt/advancedmanagementconsole-2254207.html
    可能性があれば、他のOpenJDKコントリビュータ協力して、将来のリリースでOpenJDKでこのような使用データがどのように役立つかについて議論する予定です。主として、上記を決定するまで、Oracleのお客様に一貫した経験を提供するために、この違いが残っています。
  • javac --releaseコマンドは、Java 9とJava 10では動作が異なります。これらのリリースでは、Oracle JDKには対応するOpenJDKリリースにはない追加のモジュールが含まれていたためです。
    • javafx.base
    • javafx.controls
    • javafx.fxml
    • javafx.graphics
    • javafx.media
    • javafx.web
    • java.jnlp
    • jdk.jfr
    • jdk.management.cmm
    • jdk.management.jfr
    • jdk.management.resource
    • jdk.packager.services
    • jdk.snmp
    特定の種類のレガシー用途のための一貫したエクスペリエンスを提供するために、この違いが残ります。これらのモジュールはOpenJFXの一部として別途入手可能であったり、Flight RecorderのようなOracleがOpenJDKに寄贈したOpenJDK(Flight Recorderなど)に提供された商用機能のためにOpenJDKとOracle JDKの両方にあったり、JNLPなどのようにOracle JDKから削除されていたりします。
    OpenJFX Project
    http://openjdk.java.net/projects/openjfx/
  • サポートチームは存在する可能性のある問題を診断できるよう、java --versionjava -fullversionコマンドの出力結果は、OpenJDKビルドとOracle JDKで異なります。具体的には、Oracle JDK 11ビルドでjava --versionを実行すると以下のような出力が得られます。
  • java 11 2018-09-25
    
    Java(TM) SE Runtime Environment 18.9 (build 11+28)
    
    Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode)
    
    OpenJDK 11ビルドの場合は以下の通りです。
    openjdk version "11" 2018-09-25
    
    OpenJDK Runtime Environment 18.9 (build 11+28)
    
    OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
    
  • Oracle JDKでは、サード・パーティの暗号化プロバイダを既知の証明書で常に署名する必要があります。OpenJDKの暗号化フレームワークにはオープンな暗号化インタフェースがあります。つまり、利用可能なプロバイダを制限しません。Oracle JDK 11は引き続き有効な署名を必要とし、Oracle OpenJDKビルドは引き続き有効な署名または署名されていない第三者の暗号化プロバイダの使用を許可します。
    Java Platform, Standard Edition Security Developer’s Guide
    Sign Your JAR File, If Necessary
    https://docs.oracle.com/javase/10/security/howtoimplaprovider.htm#JSSEC-GUID-2D4432F9-1C3C-4A91-8612-2B2840188B36
  • 過去のデスクトップユースと調和する体験のため、Oracle JDK 11には引き続きインストーラ、ブランディング、およびJREパッケージが含まれる予定です。Oracle OpenJDKのビルドは現在、zipおよびtar.gzファイルで提供していますが、代替の配布フォーマットは現在検討中です。

What should we call them?

理想的には、状況に応じて、GPLまたは商用ライセンスのもとで、すべてのOracle JDKビルドを「Oracle JDK」と呼びますが、残っている小さな相違点が残っている歴史的な理由から、OracleのOpenJDKビルドとOracle JDKを分けて表現します。

[Java] Helidon Takes Flight

Thanks for giving Japanese translation permission to me, Dmitry!
原文はこちら。
https://dmitrykornilov.net/2018/09/07/helidon-takes-flight/
https://medium.com/oracledevs/helidon-takes-flight-fb7e9e390e9c

今日は素晴らしい日です。本日、新しいJavaのマイクロサービス・フレームワーク、そしてMicroProfileファミリの新しいメンバーをご紹介します。Oracleの新しいJavaのオープンソース・マイクロサービス・フレームワークであるProject Helidonです。
Project Helidon - Lightweight. Fast. Crafted for Microservices.
https://helidon.io
Helidonは ギリシア語でつばめ(swallow)を意味します。Wikipediaによると、細長い、合理化されたボディーと長い尖った羽根があり、素晴らしい操縦性と非常に効率的な飛行が可能な鳥だそうです。雲(Cloud)の中を飛び回るのに最適ですね。

Overview

Helidon Projectのの作業は以前からやっていました。クラウドの世界に入り、クラウドサービスの作成にあたってマイクロサービスアーキテクチャが非常に人気を博し始めたとき、私たちは開発体験(Developer Experience)も変える必要があることを認識しました。Java EEを使用してマイクロサービスを構築することもできます。ですが、マイクロサービス構築のためにはフレームワークを一から設計したほうがよい、と考えました。アプリケーションサーバを必要とせず、Java SEアプリケーションで使用できる軽量のライブラリセットを作成したかったのです。これらのライブラリはそれぞれ個別に利用することもできますが、組み合わせて利用すると、マイクロサービスを作成するために開発者が必要とする基盤(構成、セキュリティ、Webサーバ)を提供してくれます。

MicroProfileを基にした、標準的なマイクロサービスのフレームワークを構築する取り組みはすでにいくつか立ち上がっています。MicroProfileは、Java EE/Jakarta EEコミュニティで非常に人気があり、Java EEと同様の開発体験を提供します。私たちはそのアイデアを気に入っていており、このイニシアティブをサポートしています。HelidonはMicroProfile 1.1を実装していますが、引き続きMicroProfileの新しいバージョンの実装に取り組み、この分野に関連するJakarta EE標準をサポートする予定です。

HelidonはOracleが作成していますので、Oracle Cloudとの役立つ連携機能が含まれていくことに驚かないでください。こうした機能は初期バージョンには含まれていませんが、後々追加される予定です。Helidonはすでに多くのOracle社内プロジェクトで使用されており、Oracle Cloudとの連携機能によって、開発者の負担が大幅に軽減されています。Oracle Cloudをお使いであれば、皆様の負担も軽減されるでしょう。お使いにならない場合は、こうした連携機能はオプションです。

Positioning


マイクロサービスを作成するためのJavaフレームワークは、いくつかのカテゴリに分類されます。 小さいものから並べてみました。
  • Microframeworks
    シンプルで小さな機能セット。
  • [例]Spark、Javalin、Micronautなど
  • MicroProfile
    Java EE開発者にとっては優しいが、やや重い。完全機能を備えたJava EEアプリケーションサーバーの上に構築されているものもある。
    [例]Thorntail (Wildfly Swarm)、OpenLiberty、Payaraなど
  • Full Stack
    Spring Bootのようなフル機能セット
Helidonには2種類あり、それぞれMicroframeworksとMicroProfileという2つのカテゴリをカバーします。アプリケーションでどちらを使うかは開発者次第です。
  • Helidon SE — モダンなリアクティブ・スタイルで開発された、シンプル、機能的で軽量なマイクロフレームワークです。"magic"の注入(訳注:CDIのことを指しています)はありません。特別なランタイムは必要ありません。JDKをランタイムとして使用します。
  • Helidon MP — Java EE/Jakarta EE開発者に優しい開発者体験を提供する、Eclipse Microprofile実装

Architecture

以下はHelidonのハイレベルなアーキテクチャ図です。

  • 緑色の部分が、Helidon SEコンポーネント(Config、Security、RxServer)です。
  • 灰色の部分が、Helidonで使用するJava EE/Jakarta EEコンポーネント(JSON-P、JAX-RS/Jersey、CDI)です。MicroProfileの実装のためにこれらのコンポーネントが必要です。
  • Helidon MPは、Helidon SEコンポーネントの上にある薄いレイヤーです。
  • Oracle Cloudのサービスコンポーネントは赤色の部分で、Helidon SEとHelidon MPの両方で使用されます(訳注:もちろんOracle Cloudとの統合が不要であれば使う必要はありません)。

Usage and Samples

Setup

Helidonを使い始めるなら、MavenプロジェクトをJava 8(もしくはそれ以上のバージョン)で利用し、Helidonのbom-pomを構成するのが最も簡単です。
<dependencyManagement>
   <dependencies>
       <dependency>
           <groupId>io.helidon</groupId>
           <artifactId>helidon-bom</artifactId>
           <version>${helidon-version}</version>
           <type>pom</type>
           <scope>import</scope>
       </dependency>
   </dependencies>
</dependencyManagement>

Helidon SE

Helidon SEは軽量なリアクティブ・マイクロサービスを構築するための基礎となるものです。Hello worldの実装は以下のような感じです。
Routing routing = Routing.builder()
       .get("/hello", (req, res) -> res.send("Hello World"))
       .build();

WebServer.create(routing)
       .start();
このコードで、ランダムな(空き)ポートでWebサーバを起動し、/helloというエンドポイントを公開します。

以下をインポートします。
import io.helidon.webserver.Routing;
import io.helidon.webserver.WebServer;
このサンプルを実行するために必要な依存関係は以下の通りです(bom-pomを使う場合にはバージョンは不要です)。
<dependency>
   <groupId>io.helidon.webserver</groupId>
   <artifactId>helidon-webserver-netty</artifactId>
</dependency>

Adding metrics to SE

Helidon SE用にも、MicroProfile Metricsインタフェースの実装を提供しています(SEにはinjectionが含まれていないため、injectionのサポートはありません)。
// create metric registry
MetricsSupport metricsSupport = MetricsSupport.create();

// get the registry
MetricRegistry registry = RegistryFactory
       .getRegistryFactory()
       .get()
       .getRegistry(MetricRegistry.Type.APPLICATION);

// create a counter
Counter helloCounter = registry.counter("helloCounter");

Routing routing = Routing.builder()
       // register metric support with web server
       .register(metricsSupport)
       .get("/hello", (req, res) -> {
           // increase counter
           helloCounter.inc();
           res.send("Hello World");
       })
       .build();

WebServer.create(routing)
       .start();
ここで、新たな依存関係が必要です。
<dependency>
   <groupId>io.helidon.microprofile.metrics</groupId>
   <artifactId>helidon-metrics-se</artifactId>
</dependency>
新たなエンドポイントが利用可能になっています。
  • /metrics
    全てのメトリック(base、vendor、application)
  • /metrics/application/helloCounter
    hello worldアプリケーションで生成されたメトリック

Helidon MP

Helidon MPは Eclipse Microprofileの実装で、マイクロサービスのランタイムです。

Hello worldでは、呼び出しを計測するためにメトリックを使います。

リクエストを処理するために、JAX-RSリソースクラスを作成する必要があります。
@Path("hello")
@RequestScoped //allows us to use CDI injection
public class HelloWorld {
   @GET
   @Metered
   public String hello() {
       return "Hello World";
   }
}
続いて、このリソースをもつサーバを起動します。
Server.builder()
       .addResourceClass(HelloWorld.class)
       .build()
       .start();
このプロジェクトでCDIインジェクションを呼び出すためsrc/main/resources/META-INF ディレクトリにbeans.xml ファイルを作成する必要があります。
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee                         
                           http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd"
       bean-discovery-mode="annotated">
</beans>
これで、デフォルトのポート(7001)でWebサーバが始動し、/helloというエンドポイントを公開します。

以下のエンドポイントが利用可能です。

Plans

多くの計画があるので、それについては別途記事にできると思っています。

短期的な目標は、HelidonをJavaコミュニティに広めることで、Helidonについて種々のカンファレンスでお話する予定です。Oracle Code One 2018では4つのHelidon関連のセッションを予定しています。また、EclipseCon Europe 2018にもCfPを提出していますし、現地でのJakarta EE/MicroProfile Community Dayにも参加する予定です。スクリーンキャストやYouTube動画といった学習教材も現在進行中です。

技術的観点から、MicroProfileの次期バージョンをすみやかに実装しようと取り組んでいます。また、Oracle GraalVMのサポートに取り組んでいます。これはHelidon SEユーザーのための素晴らしい機能となるでしょう。

いくつかの素敵な機能に取り組んでいますが、今すべてをご覧頂くことはできませんので、しばしお待ちください。準備でき次第、すみやか新しい機能を発表してまいります。

Useful Links

You may find it interesting

  • 元々のプロジェクトの名前はJ4C(Java for Cloud)でした。
  • Helidonチームは2個の小さなチームから構成されており、一つはプラハ(チェコ)、もう一つはUSにあります。
  • Oracle社内で、Helidonを使うプロジェクトが10個以上あります。
  • Helidonのコンポーネントの中には、まだ開発中でオープンソース化されてないものがあります。

[Java] 三度、新しいJavaリリースモデルについて

まずは、お約束の文言から。
このエントリは個人の見解であり、所属する会社の公式見解ではありません。
Opinions expressed in this blog entry is my personal one and does not represent the official opinion of my employer.
以前、以下のようなエントリを記載しました。
新しいJavaリリースモデルについて
https://orablogs-jp.blogspot.com/2018/05/misunderstanding-new-java-release-model.html
再度、新しいJavaリリースモデルについて
https://orablogs-jp.blogspot.com/2018/06/new-jdk-release-model-reloaded.html
そして、今月(US時間の2018/9/25)、Java 11がリリースされる予定です。
Fast Forward To 11
https://blogs.oracle.com/java-platform-group/fast-forward-to-11
https://orablogs-jp.blogspot.com/2018/09/fast-forward-to-11.html
とあるメディアによる記事をご覧になった方や、まだまだロジ子の認知度が低いせいで、
「JDKのダウンロードにお金が必要だと?!(ぷんすか」
と誤解(拘泥?狂信的な理解?)されている方が多いと耳にしていますが、ほとんどの方は
「Oracle JDKの場合、Production環境で使うなら有償サポート契約が必要」
「Oracleがビルドし提供するOpenJDKは、コミュニティベースのサポートで、6ヵ月毎のアップデートだけど、Development 、QA環境だけでなく、Production環境でも無償で利用できる」
と理解いただいているかと思います。とはいえ、念のため、再度リリースモデルの変更についてまとめておきます。

日本オラクルやOracle Corporationからの情報は以下にまとまっています。
JDKの新しいリリース・モデルおよび提供ライセンスについて
http://www.oracle.com/technetwork/jp/articles/java/ja-topics/jdk-release-model-4487660-ja.html(日本語)
Oracle Java SE サポート・ロードマップ(執筆時点では2018/6/22更新版が最新)
http://www.oracle.com/technetwork/java/eol-135779-ja.html(日本語)
http://www.oracle.com/technetwork/java/eol-135779.html(英語)
その他、Java Day Tokyo 2018での発表スライドや、以下のスライドをご覧になってご存知の方も多いと思います(まだの方はご一読ください)。
JDKの新しいリリースモデル (Java Day Tokyo 2018)
http://otndnld.oracle.co.jp/ondemand/javaday2018/JSE-3

纏めると、以下の通りです。
注意
以下の内容はOracleが提供する(予定の)JDKについての記述です。OpenJDKベースであったとしても、Red Hatが配布するOpenJDKバイナリ(RHELに同梱されるもの)やAdoptOpenJDK、Zuluが配布するOpenJDKバイナリは、Oracleが配布するものとは異なります。
Oracleがビルドし配布するOpenJDKバイナリ
(GPL+Classpath Exception)
Oracle JDK
(OpenJDKベース、BCL)
対象主に商用サポートや企業向け管理ツールを必要としない人向け主に商用およびサポートが必要なお客様向け
リリース
サイクル
6ヵ月ごとにリリース(3月と9月)
6ヵ月過ぎるとEoL
3年ごとにリリース
Java 11から開始(LTS / Long Term Support)
サポート無償、コミュニティによるサポートサポートは有償(従前よりJava SE AdvancedやJava SE Suiteの形態で有償サポートを提供していました。また、Oracle WebLogic Serverを購入、利用されている場合には、当該Application ServerのサポートにJavaのサポートが含まれています)。
サブスクリプションモデル(Java SE Subscription)としてサポート契約の締結可。 最小契約は年単位(12ヵ月分)。価格などの詳細は、以下のFAQを参照。
Java SE Subscription
http://www.oracle.com/technetwork/jp/java/javaseproducts/overview/index.html(日本語)
http://www.oracle.com/technetwork/java/javaseproducts/overview/index.html(英語)
オラクル Java SE Subscription FAQ
http://www.oracle.com/technetwork/jp/java/javaseproducts/overview/javasesubscriptionfaq-4891443-ja.html(日本語)
http://www.oracle.com/technetwork/java/javaseproducts/overview/javasesubscriptionfaq-4891443.html(英語)
サポートはOracle Lifetime Support Policyに従う。
Premier Support (5年)
Extended Support (3年)
Sustaining Support (無期限)
なお、開発やテスト、試作、デモンストレーション目的であれば、ロイヤリティ・フリーで利用できる予定(OTNでダウンロードできるOracle製品の扱いに類似)。
配布http://jdk.java.net/以下は予定であり、変更の可能性があります。
My Oracle Support
Oracle Software Delivery Cloud (a.k.a e-Delivery)
OTN
セキュリティアップデート6ヵ月の範囲で2回リリース(1、4、7、11月)年4回リリース(1、4、7、11月)
インストーラの有無なし
(Java 10のJDKはWindows、Linux、Macともtar.gz形式で提供、Java 11からはWindows用JDKはzip形式で提供)
あり
JREClient JREは提供なし。自身の環境に合わせてjlinkを使って作成。インストーラにJREを含む
その他
特記事項
JavaFXは同梱されないため、OpenJFXを利用
Java Mission Controlは別バイナリでリリース

[Java] Fast Forward To 11

原文はこちら。
https://blogs.oracle.com/java-platform-group/fast-forward-to-11

Java 11はもうすぐ出てきます。リリース候補版ビルドが以下のURLからダウンロードできます。
JDK 11 Early-Access Builds
http://jdk.java.net/11
ここで新しいリリース・ケイデンスが新しいリリースの採用に及ぼした影響を振り返ります。

Changing the Pace of Change

以前はJavaの新リリースを開発者が採用するまでかなりの時間がかかりました。例えば、Java SE 5.0では、2004年にJavaプログラミング言語に注釈やジェネリックなどの主要な変更が導入されましたが、その後、2006年のJava SE 5.0でテストおよび検証されたEclipse IDEのリリースまで2年かかりました。そうしてようやくEclipseを使用する開発者は、Java SE 5.0を主要なプラットフォームとして本格的に採用することができました。
2004年からの10年でJavaエコシステムに多くの変更がありました。Java SE 8は2014年にリリースされ、Javaプログラミング言語にさらなる大きな変更、すなわちラムダ式をもたらしました。しかし、リリース直後にはJDK 8でテスト、動作検証済みのEclipse、InteliJ IDEAおよびNetBeans IDEの新リリースを開発者が利用できる状態にありました。その結果、開発者はほぼリリース直後にJava SE 8を採用することができたのです。
その当時、Java SE 8がもっとも急速に採用されたリリースになりました。JDK 8のダウンロード数は、JDK 7の初期立ち上げフェーズの同期間に比べて30%以上増加しました。
さらにJDK 8では、ほぼ半年ごとの大規模な更新リリースのパターンを確立しました。 8u20、8u40、および8u60のリリースでは、数百のバグ修正やその他の変更が、複数の新機能と共に提供されました。 JDK 8以前、JDK 6、JDK 7のいずれのアップデートにおいても、数多くのバグ修正やその他の変更が加えられた、大きな個別のアップデートリリースがありました。

Forward to 9

Java SE 9以降の新しい半年ごとのJava SEリリースサイクルで、主要なIDEによる新しいJavaプラットフォームリリースの迅速なサポートのパターンを目の当たりにしてきました。さらに、エコシステム全体で100を超える人気のあるオープンソースのJavaライブラリやツールの開発者とともに、オラクルのエンジニアは新しいリリースの採用にあたっての潜在的な障壁を排除するよう引き続き取り組んでいます。
Quality Outreach report for July 2018
https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+for+July+2018

これにより、人気のある多くのライブラリやツールは、Java 9がリリースされるまでに、あるいはリリース後すみやかにJava 9への対応が整いました。
#WorksFineOnJDK9 on Twitter
https://twitter.com/hashtag/WorksFineOnJDK9
これには、Apache AntApache MavenGradleByteBuddyJUnitjaCoCoApache Luceneなどの人気のあるライブラリ、AkkaSpring FrameworkWildFlyなどの人気のあるフレームワークが含まれていました。
その結果、Java SE 9リリース時のJDK 9のダウンロード数は、JDK 8リリース時よりも10%以上多くなりました。

Fast Forward to 10

JDK 10を使う開発者においても同様のパターンを確認しました。Java SE 10では、Java SE 8の立ち上げ時の同時期でJDK 8よりも20%多いJDKのダウンロード数を確認しました。JDK 9と同様に、人気のあるIDEツールライブラリフレームワークは、新しいJavaリリースのサポートをすみやかに発表しました。

これは、新しいリリースサイクルの主要な側面が驚異的にうまくいっていることを示しています。Java SE 10のローカル変数の型推論のような新しいJava機能が、以前よりもずっと速く多くのJava開発者の手に渡っています。

Onward to 11

以前は、Javaプラットフォームの新リリースごとに、開発に数年かかっており、その過程で何千もの大小の拡張、変更、バグ修正が蓄積されていました。ビルド、リリースまでの時間が長くかかっており、その結果、各リリースの変更が広範囲におよび、習熟するまでに時間がかかっていました。
新しいリリースサイクルでは、各Java機能のリリースは過去に要した時間に比べてわずかの期間で提供されるため、各リリースでの変更範囲はずっと小さくなっています。その結果、内容の変化が以前よりもはるかに少ないため、新リリースへの習熟に要する時間ははるかに短くなります。実際に、これは、Java SE 9とJava SE 10への準備が整った人気のあるツール、ライブラリ、フレームワークの多くがすでにJava SE 11の準備が整っていることからもわかる通りです。
言い換えると、Spring BootSpring FrameworkMockitoByteBuddy、そしてApache CassandraIntelliJ IDEAJenkinsEclipse IDEAtlassianに至るまで、Javaエコシステムの大部分がJava SE 11の準備ができている、もしくはすでにそれをサポートするように取り組んでいると発表しています。
Java Community Process Executive Committeeによる最近の調査で、回答者の半分以上が近い将来にJava SE 11を使用、デプロイすることを検討していることは驚きではありません。
Java Release Adoption survey by JCP
https://jp.surveymonkey.com/results/SM-YR7YQJJJL/
新しいリリースの採用を慎重に検討する必要があるユーザーに向けて、先頃OracleはJava SE Subscriptionを導入しました。
Oracle Java SE Subscription
http://www.oracle.com/technetwork/java/javaseproducts/javasesubscription-data-sheet-4891969.pdf
これは、デスクトップ、サーバー、またはクラウドのデプロイメントに使用するためのJava SEライセンスおよびサポートを含む、シンプルで低コストの月単位のサブスクリプションです。このサブスクリプションで、パフォーマンス、安定性、およびセキュリティーについてテスト済みかつ動作保証済みのJava SEアップデートに対するアクセスをOracleから直接提供します。また、これには24時間365日のMy Oracle Support(MOS)へのアクセス、27言語でのサポート、Java SE 8 Desktop管理・監視、デプロイメント機能などの利点含まれています。
Oracleが提供するJava SE 11は、長期サポート(LTS)リリースです。Java SE Subscriptionを契約いただくと、LTSリリースのアップデートを入手でき、少なくとも8年間は特定のLTSリリースバージョンにとどまることができます。企業組織は、ワークロードを開発から本番環境に移行する際に、任意のタイミングでサブスクリプションに容易に追加できます(訳注:本来ならサブスクリプションを用意に追加できる、のはずですが、原文の通り訳出しています)。
一方、プラットフォームの新規リリースを慎重に採用する必要のないユーザーは、JDK 9やJDK 10の場合と同様に、Oracleが提供するオープンソースの完全にテストされたOpenJDKビルドで、Javaの高速リリースの利点を引き続き享受できます。我々は引き続きJava PlatformをOpenJDKコミュニティと共により速く進化させていきます。
Java Development Kit builds, from Oracle
http://jdk.java.net/
OpenJDK
http://openjdk.java.net/

[Integration, Cloud] How to use Litmus to create OIC Integration unit tests automatically and run them to catch regressions

原文はこちら。
https://blogs.oracle.com/integration/how-to-use-litmus-to-create-oic-integration-unit-tests-automatically-and-run-them-to-catch-regressions

このエントリでは、数クリックで自動的にUnit Testを作成する、Oracle Integration Cloudに追加されたOracle Litmusという新機能が簡単に利用でき、Regression発見のためのテスト実行も簡単である点をご紹介します。Litmusは以下のユースケースをサポートしています。
  • Integration CloudのユーザーがUnit Testを自動作成し、(通常はすでに本番適用する前に作成済みの統合に機能追加しようとして)作成した統合を変更する際に、テストを実行してRegressionを発見できるようにする
  • Integration Cloudの新リリース作業の一環で、Integration CloudのQAチームが製品のRegressionを発見できるようにする
  • お客様がOracleに記録済みのインスタンスを送信し、Oracleで当該インスタンスを再生して問題や不具合の再現できるようにする。全ての依存するエンドポイントや3rdパーティ製のアダプタが社内で利用できず、問題を再現できない可能性があるため、Litmusがなければ難しい。Litmusがあると、エンドポイントがシミュレートされるため、問題再現にあたってエンドポイントは必要ない。

Enabling Litmus

要件ごとに実行される統合を構築し、すべての手動テストを完了した状態で、本番環境に移行できる準備が整っているとしましょう。この時点で、Litmusテストを作成し、それをソースリポジトリにチェックインしたいと思うかもしれません。そうすれば、この統合を後で変更したいときに、Litmusテストを利用してRegressionを検出できるからです。この場合のRegressionは、例えばマッピング時に入り込んだ不具合のためにクライアントに送信しているレスポンスが変わったために失敗するというアサーションです。

以下の手順でLitmusを有効化します。
  • Oracle Litmusを有効化するには、OICの機能フラグを有効化する必要がある。この機能フラグをOnにするには、Oracle Supportに対してService Request (SR) を上げる必要がある。
  • 機能フラグが有効化された後、開発者としてログインする。
  • 統合のページに表示される統合リストから、統合のインラインメニューを開いて、Oracle Litmus > Enable Litmus Recording を選択する。
  • アクティブ化の中でLitmusを有効化することもできる。

Creating a test using Litmus

Litmus有効後、以下の手順で、統合のテストを作成できます。
  • 一度統合を実行して、Litmus Test(記録とも呼ばれます)を作成する。
  • 記録をチェックするには、Oracle Litmus > Recordingsに移動すると、レコーディングが表示される。直近に作成されたものが最初に表示される。
  • 1個の統合に最大5つの記録を作成できる。
  • 入力ペイロードの特定の値に応じて、統合は複数のパスまたは分岐を取ることができるので、異なる入力値を送信して複数のレコーディングを作成することができる。Primary Identifier(プライマリID)列を使用して、各記録を識別できる。

Exporting and Importing a test 

記録作成後、以下の手順で統合のテストをエクスポート、インポートできます。
  • 開発者としてログイン
  • 統合のページに表示される統合リストで統合のインラインメニューで[エクスポート]をクリック
  • Include Litmus Recordingsのチェックボックスにチェックを入れる
  • 記録のインポートを実施するには、右上の[インポート]のボタンをクリック
  • 統合のアーカイブファイル(.iar)を選択し、Include Litmus Recordingsのチェックボックスにチェックを入れる

Playing back a recording

記録作成後、以下の手順で、特定の統合の記録を再生できます。
  • Oracle Litmus > Recordingsに遷移し、再生リストから再生したい記録を識別する。
  • playback(再生)ボタンをクリックすると、以下のメッセージがバナーに表示される。
    "Successfully invoked playback for recording RecordName_7. Please refer Track Instances page to view the Litmus instance details."(記録 RecordName_7の再生の呼び出しに成功しました。Track Instancesページを参照し、Litmusインスタンスの詳細をご覧ください)
  • この時点で記録が非同期で再生されます。次のセクションでテスト実行の状態をチェックします。

Checking the test status

Litmus記録の再生後、以下の手順でテストステータスを確認できます。
  • Monitoring(モニタリング)> Tracking(トラッキング)を選択する。
  • 実行リストからLitmusインスタンスを特定する。Litmusを実行している場合、画像に表示されているようにLitmus Instanceのタグが付く。
  • 同様に上部にTest statusの表示がある。
  • アサーションの詳細を表示するためには、右側のインラインメニューでOracle Litmus Resultをクリックすると、実際のレスポンスとの比較対象の記録として以前保存されたgolden input(期待する結果)を表示する。一致すればテストは成功、そうでなければテストは失敗である。接頭辞の違いを無視するべく、XMLを比較しており、文字列を比較していないことに注意されたい。



Using REST API to automate Litmus

LitmusはREST APIをサポートしているため、Litmusの操作の一部を自動化できます。よく使われるREST操作は、Litmus記録の再生です。詳細については、Litmusのユーザーガイドを参照ください。RESTでサポートされている操作の一部を以下に記します。
  • Litmus記録モードつきでの統合のアクティブ化
  • Litmus記録モードの有効化/無効化
  • (記録の有無に関わらず、統合とパッケージの両方を)インポート
  • (記録の有無にかかわらず)エクスポート
  • Litmus記録されたインスタンスの再生
  • Litmus記録の更新
  • Litmus記録の削除
  • Litmus記録の取得
  • Litmus記録の送信