[Cloud, Network] Innovation in Edge Services: The Oracle Cloud Infrastructure Edge Network

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/innovation-in-edge-services-the-oracle-cloud-infrastructure-edge-network


クラウドへの移行は企業組織にとって不可欠なものになっていますが、この移行には大きな懸念が伴います。Oracleは、volatilityからセキュリティにわたるコンポーネントが、クラウド・フレームワークの成功のために重要であることを認識しており、Edge Serviceと同時に機能するOracle Cloud Infrastructureはこのことを特に念頭において、設計されています。

エッジはイノベーションが起こる場所です。例えばOracle Cloud Infrastructure Edge Compute Networkは、40箇所にある大容量のエッジ・コンピューティングから構成されており、このコンピューティングリソースはオンプレミス・ハードウェアのベアメタルのパフォーマンスとガバナンス管理とクラウドのアジリティとコスト効率が組み合わさったものです。
Read the RedMonk report on getting the most for your IaaS dollar
https://blogs.oracle.com/cloud-infrastructure/read-the-redmonk-report-on-getting-the-most-for-your-iaas-dollar 
Oracle Dyn Web Application Security platformは、クラウドベースの大容量のDDoS攻撃からの防御プラットフォームと、DNS、そしてデータインテリジェンス製品では既にEdge Compute Networkを利用しています。
DDoS Protection for Websites and Applications
https://dyn.com/ddos-protection/

Why an Edge Compute Network?

Oracle Cloud Infrastructure Edge Compute Networkは、グローバルに分散されたコンピューティング容量ネットワークで、これを使い中央集中型クラウド・リポジトリにプッシュされる前にデータを格納および処理します。企業の中央ネットワークにデータを送信せずにデータをソースに近づけるため、この方法はレイテンシを減らし、強力なセキュリティを保つ上で理想的です。

多くのアプリケーションとサービスは、エッジで動作するように設計されており、アクセスされたデバイスからのコンピューティングと、最も近いクラウドサーバー上のワークロードを活用しています。今日、ビジネス上重要な機能を実現するためには、どこにでもいる必要があります。コアネットワークの能力を計算能力が上回るにつれて、組織はビジネスロジックを処理するエッジサービス、サーバー、およびデバイス自体にますます頼るようになります。 さらに、接続エンドポイントの数は指数関数的に増加しており、複雑なデータフローに対応するために帯域幅が増加しています。

What Are Edge Services?

Oracleは、Oracle Cloud Cloud Edge Edge Compute Networkを通じてEdge Servicesをセキュアに提供します。エッジサービスは、ソース側で分析とデータ収集を可能にします。組織のネットワークの集中ノード上でそのデータをルーティングするのではありません。ネットワークの回復力(Resiliency)とセキュリティの観点からは、サービスに潜在的に影響を与える可能性のある悪意のあるデータは、ビジネス上重要なインフラストラクチャに到達する前にエッジで処理され緩和されることを意味します。

Oracleのエッジサービスには、Webアプリケーション・セキュリティ、DDoS攻撃からの防御、およびDNSのソリューションが含まれています。

主要機能は以下の通りです。
  • 一貫したパフォーマンス:アプリケーションとデジタル資産の信頼できるパフォーマンスのため、世界中でDNSクエリに30ミリ秒未満で応答、DNSレコードを1分以内に伝播します。
  • 膨大なインターネットデータと経験:毎日240億以上のデータポイントを収集するのに利用する600以上の収集ポイントを利用し、インターネット制御プレーンを介して位置情報によって低遅延かつインテリジェントにユーザートラフィックをルーティングします。
  • 実証済みの信頼性とセキュリティ:複数の大陸に戦略的に配置された複数のデータセンターのグローバルエニーキャストネットワークで、冗長なインターネットトランジットプロバイダを活用して究極の回復性とDDoS攻撃からの保護を実現します。
    What is DDoS Attack?
    https://dyn.com/blog/what-is-a-ddos-attack/
  • セキュリティを管理:Webアプリケーションファイアウォール(WAF)、ボット管理、マルウェア保護、およびAPIセキュリティソリューションを備えたグローバルサイバーセキュリティ専門家チームがWebアプリケーションセキュリティスイートを24時間365日常に管理します。
    What is Web Application Firewall (WAF)?
    https://dyn.com/blog/what-is-web-application-firewall-waf/
Internet of Thingsがますます成長し、より多くのアプリケーションとサービスがエッジで動作すると考えていますが、このためには、信頼性が高く、一貫して高性能の革新的なエッジセキュリティサービスがこれまで以上に不可欠です。

[Cloud, Network] Interconnecting Clouds with Oracle Cloud Infrastructure

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/interconnecting-clouds-with-oracle-cloud-infrastructure

マルチラウドアーキテクチャでは、複数のクラウドサービスプロバイダを使用します。企業には、複数のクラウドプロバイダーを利用する様々な理由があります。例えば、レジリエンシの提供、災害復旧の計画、パフォーマンスの向上、コストの削減などです。企業があるクラウドプロバイダーから別のクラウドプロバイダーにクラウドリソースを移行する場合、クラウド間のアクセスとネットワーク接続が必要です。Oracle Cloud Infrastructureは、Oracle Cloud Infrastructure仮想クラウド・ネットワーク(VCN)をインターネット、オンプレミス・データ・センター、または他のクラウド・プロバイダに接続するために、インターネット・ゲートウェイ(IGW)やダイナミック・ルーティング・ゲートウェイ(DRG)といったサービス・ゲートウェイ・オプションを提供しています。
このエントリでは、Oracle Cloudへのネットワーク接続を一般的に計画する上で役立つよう、現在利用可能な接続サービスのオプションを説明した上で、クラウドプロバイダ間の接続オプションについて説明します。

Connectivity Option Overview

全てのメジャークラウドサービスプロバイダ(CSPs)では、3個のネットワーク接続サービスオプションを提供しています。
  • パブリックインターネット
  • IPSec VPN
  • 専用線接続(Oracleのサービスでは、Oracle Cloud Infrastructure FastConnectと呼んでいます)
ワークロードや転送が必要なデータ量によっては、1個、2個、もしくは3個全てのネットワーク接続サービスオプションを必要とすることがあります。
Max (Mb/s)LatencyJitterCostSecure
Public internet < 10,000 Variable Variable Variable No
IPSec VPN < 250 Variable Variable Variable Yes
FastConnect < 100,000 Predictable Predictable Predictable Yes
  • パブリックインターネットは任意のインターネット接続デバイスからアクセス可能
  • IPSec VPNはセキュアに暗号化されたネットワークで、貴社ネットワークをクラウドに伸長してアクセス可能
  • FastConnectは専用接続でインターネットへの代替接続を提供。このサー椅子は排他的な性質を持つため、信頼性が高く、低レイテンシで、専用の帯域幅を持ち、安全なアクセスを提供する。
FastConnectでは以下の接続モデルを利用できます。
  • Oracleネットワーク・プロバイダや交換パートナによる接続
  • データセンター内の直接ピアリングによる接続
  • 第三者ネットワークからの専用線接続
FastConnect Network Connectivity and Peering Models
https://cloud.oracle.com/en_US/fastconnect/connectivity-modelshttps://cloud.oracle.com/ja_JP/fastconnect/connectivity-models

Connectivity Option Details

以下は以下は最適な接続オプションです。速度、コスト、および時間に基づいて選択肢を比較するには、Choosing Your Connectivity Optionをご覧ください。

Option 1: Connecting via an IPSec VPN

IPSec VPNでは、データ・トラフィックを暗号化してセキュリティを強化しています。VPNで実現可能な帯域幅は250 Mbpsに制限されていますので、転送データの総量と必要な転送レートに応じて、複数のVPNトンネルが必要になる場合があります。
Oracle Cloud Infrastructureと他のクラウド・プロバイダ間のセキュアな接続を作成するための詳細手順は、以下のドキュメントをご覧ください。
Access to Other Clouds with Libreswan
https://docs.cloud.oracle.com/iaas/Content/Network/Concepts/libreswan.htm?tocpath=Services%7CNetworking%7C_____14

Option 2: Connecting via a Cloud Exchange

クラウド交換プロバイダー(Exchange Provider)は、オンプレミスと交換プロバイダー間の同じ専用物理接続を使って、大規模なクラウドプロバイダーのエコシステムに接続を提供できます。利用可能なプロバイダには、Megaport、Equinix、Digital Realtyなどがあります。
クラウド間のルーティングには、以下の方法があります。
  • Megaport Cloud Router(MCR)のような、交換プロバイダが提供する仮想ルータサービスの利用
  • 物理カスタマーエッジ(CE)デバイスを交換プロバイダにコロケート
下表は、仮想ルータサービスを使用する場合と、物理ルータを交換プロバイダにコロケートする場合の長所と短所を示しています。
Pros Cons
仮想ルータサービスの利用
  • デプロイが簡単
  • オンデマンドで帯域幅を設定可能
  • デプロイ、メンテナンスのコストが安価
  • ルーティング変更を行う柔軟性は、クラウド交換(プロバイダ)のサポートの範囲内に制限
  • パブリックIP通信は利用不可

  • 専用物理ルータの利用
  • ルーティング機能の管理に柔軟性がある
  • ハードウェアの選択の自由度
  • デプロイに時間がかかる
  • スケールの制限
  • ハードウェアメンテナンスとそれに関連するコストが必要
  • このブログエントリは、パートナーに依存しないアプローチで最適な接続オプションを提供することを目的としていますが、デプロイが簡単で仮想ルータサービスを提供するという理由で、Megaport Cloud Router(MCR)を使い、クラウドプロバイダ接続としてAmazon Web Services (AWS)を使う例を紹介します。なお、Megaportは、AzureやGoogle Cloud Platformなどの多くのクラウドプロバイダーとの接続をサポートしています。

    接続の設定にあたって、以下の手順を踏みます。
    1. Oracle Cloud Infrastructure Consoleを使い、MegaportとFastConnectを接続
    2. AWS consoleを使い、MegaportとAWS Direct Connectを接続
    3. MCRを作成
      1. MCRからFastConnectへのVirtual Cross Connect (VXC) 接続を作成
      2. MCRから接続先のクラウド・プロバイダ(例えばAWS Direct Connect)へのVXC接続を作成

    After you set up FastConnect、MCRとクラウドプロバイダーとの接続(例えばAWS Direct ConnectやAzure ExpressRoute、Google Cloud Platform)の設定後、プライベートIPアドレスでリソースにアクセスでき、トラフィックは広帯域、低レイテンシの接続を通ります。

    Choosing Your Connectivity Option

    以下に示すハイレベルの情報を基にして、接続を選択してください。しかしながら、最善の接続はユースケースによって様々です。AWS Direct Connectを例にして情報をまとめます。

    (訳注)AWS Direct Connectは2018年9月19日現在の情報です。

    Speed

    • FastConnectは1Gと10Gのポート速度から選択できます。
    • Direct Connectは50M、100M、200M、300M、400M、500M、1G、10Gのポート速度から選択できます。
    • IPSec VPNの速度はほとんどの場合、500Mb/sが上限です。

    Cost

    • Oracle FastConnectでは、単位時間あたりの利用ポートの料金を請求します(データ転送料金はかかりません)。 詳細は以下を参照ください。
      Fast Connect Pricing
      https://cloud.oracle.com/en_US/fastconnect/pricing
      https://cloud.oracle.com/ja_JP/fastconnect/pricing
    • Oracle IPSec VPNサービスは、インバウンド・データ転送への課金はなく、アウトバウンド・データ転送は10TBまでは無料、それ以上の場合はわずかな料金が発生します。詳細は以下を参照ください。
      Cloud Networking Pricing
      https://cloud.oracle.com/networking/pricing
      https://cloud.oracle.com/ja_JP/networking/pricing
    • AWSの場合、ポート料金とデータ転送料金が必要です。インバウンドデータは課金対象ではありませんが、アウトバウンドデータは課金対象です。詳細については、Amazon Direct Connectの価格設定を参照ください。
      AWS Direct Connect の料金
      https://aws.amazon.com/jp/directconnect/pricing/
    • Megaportの価格は、MCR作成時に選択したレート制限に基づきます。利用可能なオプションは、100 Mbps、500 Mbps、1,2,3,4,5 Gbpsです。MCRのデプロイ先と接続を展開する場所と接続が展開されている地域に基づいて、課金レート(月額)がデプロイ時に表示されます。

    Time

    データ転送時間は、各ホップでの速度選択に依存します。専用線接続とIPSec VPNを比較すると、専用線接続では、閉域網を使用しており、IPSec-VPNと比較して信頼性が高く一貫性があるため、転送時間の大幅なぶれはありません。
    下表は、帯域幅に基づいた、AWSからOracle Cloud Infrastructureへのデータ転送時間の仮想的なコストシナリオです。


    Data (TB)
    10 100 1,000 10,000
    Rate Gb/s 1 22h13m12s 9d6h13m12s 92d14h13m12s 925d22h13m12s
    10 2h13m12s 22h13m12s 9d6h13m12s 92d14h13m12s
    100 13m12s 2h13m12s 22h13m12s 9d6h13m12s

    Summary

    この記事では、一般的に使用可能なクラウド間接続の選択肢と、Oracle Cloud Infrastructureでマルチ・クラウド・アクセスを実装する方法について説明しました。この中で、接続パスの定義に役立つハイレベルのインジケータを提供し、ユースケースに最適な接続を選択するのに役立つよう、使用可能な接続オプションを比較しました。接続の詳細情報と詳細手順は、以下のホワイトペーパーをご覧ください。
    Migrating Oracle Databases from Amazon Web Services to Oracle Cloud Infrastructure Database
    https://cloud.oracle.com/iaas/whitepapers/database_migration_aws_to_oci_database.pdf

    [Cloud, Security] Announcing Oracle Cloud Infrastructure Key Management

    原文はこちら。
    https://blogs.oracle.com/cloud-infrastructure/announcing-oracle-cloud-infrastructure-key-management

    このエントリはUlf Schoo(a consulting member of the technical staff on the Oracle Cloud Infrastructure team)の寄稿によるものです。

    Oracle Cloud Infrastructureをお使いのお客様は、Oracleが安全に格納および管理する暗号鍵によりデータが保護されることを認識して、クラウドにワークロードを移してこられましたが、とりわけ規制対象の業界を担当するお客様の中には、セキュリティガバナンス、法令遵守、データ格納場所での均質のデータ暗号化の検証をOracleに依頼されることがあります。

    本日からすべてのOracle Cloud Infrastructureリージョンのお客様は、Oracle Cloud Infrastructure Key Managementをご利用いただけます。Key Managementとは、管理する鍵を使ってデータを暗号化できるようにするマネージドサービスです。

    Key Managementは、FIPS 140-2 Level 3認定ハードウェアセキュリティモジュール(HSM)を使用して鍵のセキュリティを保護する鍵保管庫(key vaults)にあなたの鍵を永続的に保管します。コンソール、API、またはCLIを使用してKey Managementサービスにアクセスし、Advanced Encryption Standard(AES)対称鍵の作成、利用、ローテーション、有効化、無効化の操作ができます。マネージドサービスなので、Key Managementを使ってデータ暗号化のニーズに注力できます。HSMや鍵管理ソフトウェアやアプライアンスの調達、プロビジョニング、設定、更新、保守のことを心配する必要はありません。

    Oracle Cloud Infrastructureのブロック・ボリューム、Oracle Cloud InfrastructureのCompute bootボリューム、Oracle Cloud Infrastructure Object Storageと統合されているので、管理する鍵を使ったデータの暗号化は簡単で、ブロック・ボリュームやバケット作成もしくは更新時にKey Managementサービスから鍵を選択するだけです。
    OCI Block Storage
    https://cloud.oracle.com/storage/block-volume/features
    OCI Compute
    https://cloud.oracle.com/compute
    OCI Object Storage
    https://cloud.oracle.com/en_US/storage/object-storage/features
    Key Managementの鍵を使ったBlock Volume作成の例
    Block Volumeに以前割り当てた鍵の編集や割り当て解除
    Oracle Cloud Infrastructure Identity & Access Management (IAM) や Oracle Cloud Infrastructure Audit と統合されているため、個々の鍵やkey vaultsnの権限を管理したり、ライフサイクルを監視できます。
    Key Managementを使ったBlock VolumeとBoot Volumeの暗号化の有効化
    ドキュメントやFAQをご覧になって、Oracle Cloud Infrastructure Key Managementの使い方を学んでください。
    Overview of Key Management
    https://docs.cloud.oracle.com/iaas/Content/KeyManagement/Concepts/keyoverview.htmOracle Cloud Infrastructure Key Management FAQ
    https://cloud.oracle.com/cloud-security/kms/faq

    [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

    ドキュメント

    以下からアクセスできます(英語)。
    JDK 11 Documentation
    https://docs.oracle.com/en/java/javase/11/ 
    Booksから辿ると各ドキュメントに到達しやすいかもしれません。
    JDK 11 Documentation - Books
    https://docs.oracle.com/en/java/javase/11/books.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 Supportのポリシーに従う(Premier 5年、Extended 3年の少なくとも8年間はアップデートリリースを提供)
        Lifetime Support Policy
        https://www.oracle.com/jp/support/lifetime-support/index.html
      • 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をお使いであれば、皆様の負担も軽減されるでしょう。お使いにならない場合は、こうした連携機能はオプションです。

    Landscape


    マイクロサービスを作成するための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は別バイナリでリリース