[Java] Opening Up Java EE

原文はこちら。
https://blogs.oracle.com/theaquarium/opening-up-java-ee

Java EE 8は進捗しており、仕様はほぼ完成し、今年夏にリファレンス実装を提供する予定です。Java EE 8の提供とJavaOne 2017カンファレンスが近づくにつれ、変化する業界や技術の要求に対応するため、Java EEをどのように開発すべきかを再考する機会があると考えています。

Java EEは、非常に成功しています。互換実装による競争があり、個々のテクノロジが幅広く採用され、フレームワークやツールの巨大なエコシステムができあがっており、無数のアプリケーションがエンタープライズとエンドユーザーに価値をもたらしています。しかし、Java EEコミュニティの参加によりオープンソースでJava EEは開発されていますが、他のオープンソースコミュニティと比較して、プロセスがアジャイルでなく、柔軟性がなく、オープンでないように見られることが多々あり、改善したいと考えています。

現在Java EE 8リリース後にJava EE開発プロセスをどのように改善することができるかについて議論しています。Java EEテクノロジーをオープンソース・ファウンデーションに移行することが正しい次の一手であり、よりアジャイルなプロセスを採用し、より柔軟なライセンス供与の実行や、ガバナンスプロセスの変更を実施できると考えています。私たちはコミュニティ、ライセンシー、そしていくつかの移行先のファウンデーション候補と共に、Java EEをこの方向に進めることができるかどうかを見極めるためにこの可能性を模索する計画です。

我々は、開発者、エンドユーザー、顧客、技術消費者、技術貢献者、パートナー、ライセンシーに対する継続的な義務を果たす腹づもりですし、既存のJava EE実装とJava EE 8の将来の実装をサポートする予定です。今後もJava EEテクノロジの進化に引き続き参加していきます。しかし、我々は、プラットフォーム・リードとして単一ベンダーに依存しない、よりオープンなプロセスによって、より多くの方々の参加と革新を促し、コミュニティにとって最善の利益になると考えています。

この方向性に対する意見やコメントをご希望の場合は、 feedback@javaee.groups.io までご連絡ください。このアプローチを詳細検討していくにつれて適宜最新情報を提供していきます。

この方針によるWebLogic Serverへの影響については、以下のエントリをご覧ください。
WebLogic Server and Opening Up Java EE
https://blogs.oracle.com/weblogicserver/weblogic-server-and-opening-up-java-eehttps://orablogs-jp.blogspot.jp/2017/08/weblogic-server-and-opening-up-java-ee.html

Safe Harbor Statement

The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

[Java, WLS] WebLogic Server and Opening Up Java EE

原文はこちら。
https://blogs.oracle.com/weblogicserver/weblogic-server-and-opening-up-java-ee

Oracleは先ほど、Java EE 8リリース後、Java Enterprise Edition (Java EE) テクノロジーをオープンソースファウンデーションに移行することを検討していると発表しました。
Opening Up Java EE
https://blogs.oracle.com/theaquarium/opening-up-java-ee
これは、よりアジャイルなプロセスの採用、柔軟なライセンス供与の実行、ガバナンスプロセスを変更して業界やテクノロジーの需要・要望に対してレスポンスをあげることを意図しています。この領域で進展があれば最新情報をご提供する予定です。

WebLogic ServerはJava EE標準をサポートしているため、WebLogic Serverをご利用の皆様は、この発表が自分たちにどのような意味があるのかと思ってらっしゃるかもしれません。端的に言うと、直近の影響はありません。引き続き我々は既存のWebLogic Serverリリースをサポートし続けますし、WebLogic ServerベースのOracle Cloud Serviceを提供し続けます。そして、将来WebLogic Serverの新リリースを提供する予定です。

WebLogic Serverご利用のお客様の中には、現在古い製品バージョン、例えば10.3.x (Java EE 5) や 12.1.x (Java EE 6) をお使いの方もいらっしゃいますが、こうしたお客様も引き続きサポートしていきます。また、より新しいWebLogic ServerやJava EEバージョンへのアップグレードパスが用意されています。

WebLogic Serverのお客様の中には、以前のブログエントリで説明した差別化機能を備えた、WebLogic Server 12.2.1.X(Java EE 7)を採用されていらっしゃいます。
Announcing Oracle WebLogic Server 12.2.1
https://blogs.oracle.com/weblogicserver/announcing-oracle-weblogic-server-1221
https://orablogs-jp.blogspot.jp/2015/10/announcing-oracle-weblogic-server-1221.html
近い将来、新しい12.2.1.XパッチセットリリースであるWebLogic Server 12.2.1.3をリリースする予定です。これについての詳しい情報はしばしお待ちください。

Java Cloud Serviceやその他のPaaSやSaaS製品を通じて、Oracle CloudでWebLogic Serverを引き続き活用していきます。
Oracle Java Cloud Service
https://cloud.oracle.com/ja_JP/java
また、Kubernetes/Dockerクラウド環境でWebLogic Serverを実行するための新しい統合機能にも投資しています。

最後に、我々は来年(2018年)、Java EE 8の新機能(HTTP/2のサポートやJSON processingやRESTサポートの改善を含む)をサポートするWebLogic Serverの新リリースを計画しています。Java EE 8の新機能の詳細情報は、以下のブログをご覧ください。
The Aquarium
https://blogs.oracle.com/theaquarium/
まとめますと、WebLogic Serverのお客様は、これからもご利用いただけますし、我々はWebLogic Serverをサポートしてきたという実績もあります。Java EE 8以降の将来のJava EEテクノロジの進化に基づいた、将来の潜在的なリリースに関しては、我々がコミュニティとしての進め方に依存していますが、Oracleがサポートしつつ、これらのテクノロジーがコミュニティ主導で堅牢な進化となることを願っています。このトピックについては今後アップデートがありましたらお知らせします。

Safe Harbor Statement

The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

[Docker, Database] MySQL Enterprise Edition Now in Docker Store!

原文はこちら。
https://blogs.oracle.com/mysql/mysql-enterprise-edition-now-in-docker-store

MySQL Community Editionの公式Dockerイメージに加え、MySQL Enterprise Editionも公式のDockerイメージがDocker Storeでご利用いただけるようになったことを発表でき、うれしく思っています。
MySQL Community Edition
https://hub.docker.com/r/mysql/
MySQL Server Enterprise Edition
https://store.docker.com/images/mysql-enterprise-server
Docker Store
https://docs.docker.com/docker-store/
これで簡単にMySQL Community EditionやMySQL Enterprise EditionでDockerのパワーを利用できます。
MySQL Community Edition
https://www.mysql.com/products/community/
MySQL Enterprise Edition
https://www.mysql.com/products/enterprise/

What Does All of This Mean?

まず、このニュースをもう少し理解するのに役立ついくつかのコンテキストと一般的な情報を説明します。Dockerはとは以下のソフトウェアコンポーネントを含むコンテナプラットフォームです。
What is Docker?
https://www.docker.com/what-docker
What is a Container
https://www.docker.com/what-container
Dockerを使ったコンテナイメージの使用(プルおよびプッシュ)は、デフォルトでDockerのパブリックコンテナレジストリを使用し、これらのレジストリへのアクセスは、作成したユーザーアカウント(Docker ID)で管理されます。このDocker IDでログインし、クライアントマシンでパブリックレジストリにアクセスするための認証トークンを保持します。
Docker Registry
https://docs.docker.com/registry/#what-it-is
Docker ID accounts
https://docs.docker.com/docker-id/
docker login
https://docs.docker.com/engine/reference/commandline/login/
Dockerは、独立した2個のパブリックレジストリを提供します。
  • Docker Hubまたは "Docker Registry"
    FOSS/Communityコンテナのレジストリで、Docker CLIがデフォルトで使用するものです。以下はコマンドの例です。
    docker run -itd mysql/mysql-server
  • Docker Storeまたは "Docker Trusted Registry"
    エンタープライズおよび商用コンテナのレジストリです。

    So How Would I Use The MySQL EE Container Then?

    最初に、Docker Store、もしくはMySQL Enterprise EditionイメージをサブスクライブしてDocker Trusted Registry内で自身のDocker IDでのコンテナへのアクセスを許可します。その後、(BringYourOwnLicenseモデルなので)前払いは不要であるため、単に”proceeding to checkout”をクリックして手続きを進めます。必要な情報を指定すると、コンテンツとコンテナへのアクセスが登録・承認済みされ、Docker IDに関連付けられます。
    これでアクセスが承認されたので、以下のdockerコマンドを実行してMySQL Enterprise Editionを起動、利用できます。
    docker run -itd store/oracle/mysql-enterprise-server:5.7
    最後に、Docker Storeで認可・サブスクライブ済みのコンテンツを以下のURLで確認できます。
    https://store.docker.com/profiles/{DockerID}/content 
    さらに、docker imagesコマンドを使って、自身のホスト上で利用可能なローカルイメージを確認できます。
    docker images
    http://docs.docker.com/engine/reference/commandline/images/

    Summary

    Dockerの機能と柔軟性をMySQL Enterpriseと組み合わせることができ、嬉しく思います。Docker上でMySQL Enterprise Editionを使い始めるにあたって、正確に理解できる手助けができていればよいのですが、ご不明な点がございましたら、お気軽にお問い合わせください。原文にコメントを残したり、Twitterでメンションいただいたり、バグを報告したり、My Oracle Supportでサポートチケットを発行したりしてください。
    MySQL Bugs
    https://bugs.mysql.com/
    My Oracle Support
    http://support.oracle.com/
    毎度のことながら、MySQLをご利用いただきありがとうございます!

    [Database] News about the new Oracle Database Release Schedule

    原文はこちら。
    https://mikedietrichde.com/2017/08/09/news-new-oracle-database-release-schedule/

    旧リリース番号体系
    新たなOracle Databaseリリーススケジュールに関するニュースです。Oracleは先頃、リリース情報を含むMOSドキュメント 742060.1を更新しました。
    Release Schedule of Current Database Releases (Doc ID 742060.1)
    https://support.oracle.com/rs?type=doc&id=742060.1
    数週間前、PSU(Patch Set Update)やBP(Bundle Patch)は、Oracle Database 12cR2以後ではRURs(Release Update Revisions)やRU(Release Updates)に変更されました。
    Release Update and Release Update Revisions for Database Proactive Patch Program (Doc ID 2285040.1)
    https://support.oracle.com/rs?type=doc&id=2285040.1
    そして今回、MOSドキュメント742060.1も更新されました。

    News about the new Oracle Database Release Schedule

    このMOSドキュメントによると、以下のようです。
    Release 12.2: New releases will be annual and the version will be the last two digits of the release year. The release originally planned as 12.2.0.2 will now be release 18.
    (新リリースは年次リリースになり、バージョンはリリース年の西暦末尾2桁になる予定です。12.2.0.2として当初予定されていたリリースは、リリース18になる予定です。)
    詳細情報ならびにサポートスケジュールに関する説明はMOSドキュメント742060.1をご覧ください。
    Instead of Patch Sets, Patch Set Updates, and Database Bundle Patches, the new releases will be maintained with Release Updates (RU) and Release Update Revisions (RUR).
    (Patch Set、Patch Set Update、Database Bundle Patchのかわりに、Release Updates (RU)とRelease Update Revisions (RUR)を使って新リリースをメンテナンスする予定です。)
    詳細はMOSドキュメント2285040.1をご覧ください。

    Further Information

    以下のエントリもご覧ください。
    More Information about RU and RUR patches for Oracle 12.2
    https://mikedietrichde.com/2017/07/19/information-ru-rur-oracle-12-2/

    [Database] What’s the Difference, and When to Use, the Various Types of Data Compression

    原文はこちら。
    https://blogs.oracle.com/dbstorage/what%E2%80%99s-the-difference%2c-and-when-to-use%2c-the-various-types-of-data-compression

    このエントリでは、種々のデータ圧縮方式について説明し、その違いと利用に適した状況をお伝えします。

    このエントリ以前にこのトピックに触れましたが、先頃Oracle Databaseのドキュメントで下表を見かけたので、この情報を踏まえて、皆様に情報をお伝えしたいと考えています。

    Data Compression Methods

    Oracle® Database管理者ガイド 12cリリース2 (12.2)
    表圧縮方法
    http://docs.oracle.com/cd/E82638_01/ADMIN/managing-tables.htm#GUID-ED833867-4B7F-442E-A70C-9C19DAA8F445__BABEEFHI
    Oracle® Database Administrator’s Guide 12c Release 2 (12.2)
    Table Compression Methods
    http://docs.oracle.com/database/122/ADMIN/managing-tables.htm#GUID-ED833867-4B7F-442E-A70C-9C19DAA8F445__BABEEFHI


    Basic Table Compression(基本表圧縮)

    Basic Table Compressionに詳しくない場合、おさえておくべき重要な点は、データ圧縮機能が無料で利用でき、Oracle Database Enterprise Editionに含まれている、という点です。10年以上前、Oracle Database 9i Release 2でBasic Table Compressionが導入されました。ただこの機能では、バルク・ロード操作を使用してロードされたデータは圧縮されますが、DML操作(INSERTまたはUPDATE)によって追加/変更されるデータは圧縮されません。そのため、Basic Table Compressionを使っている表やパーティション上でINSERTやUPDATEを実行している場合、変更内容を圧縮するには、その表やパーティションを再圧縮する必要があります。

    USAGE:

    Basic Table CompressionはOLTPアプリケーション向きではありません。その代わり、データをバルクロード操作でロードし、ほとんど(もしくは全く)変更されないような、専ら読み取りのみのデータウェアハウスアプリケーションに最適です。

    Advanced Row Compression(高度な行圧縮)

    Oracle Database 11g Release 1でOLTP Table Compression、Oracle Database 12cでAdvanced Row Compression(高度な行圧縮)と呼ばれる機能が導入されました。Advanced Row Compressionは、Basic Table Compressionと同じアルゴリズムを使用するAdvanced Compressionのデータ圧縮機能ですが、Advanced Row CompressionではINSERTやUPDATEなどの従来のDMLを含むすべてのタイプのデータ操作操作中にデータ圧縮を維持するという点がBasic Table Compressionと異なります。

    Advanced Row Compressionでは、複数の列にまたがってもデータベースブロック内の重複値を排除するように設計された圧縮アルゴリズムを使用します。 特定の環境で達成される圧縮率(Basic Table Compressionの場合も同様です)は、圧縮対象のデータ、具体的にはデータのカーディナリティに依存します。一般に、Advanced Row Compression(Basic Table Compressionでも同様の圧縮率です)を使用することで、2倍から4倍の圧縮率でストレージ使用量を減らすことが期待できます。つまり、データが圧縮されていない場合、使用する領域は、圧縮されたデータの容量の2〜4倍になります。

    USAGE

    Advanced Row Compressionは、OLTPおよびデータウェアハウスアプリケーションの両方を対象にしています。

    Hybrid Columnar Compression(ハイブリッド列圧縮)

    Basic Table CompressionやAdvanced Row Compressionとは異なり、OracleのHybrid Columnar Compressionテクノロジーでは、行と列の両方のメソッドを組み合わせてデータを格納します。このハイブリッドアプローチによって、純粋な列形式のパフォーマンス不足を回避しつつ、Columnar Storageの圧縮の利点を達成します。圧縮単位(CU)と呼ばれる論理構造を使用して、ハイブリッド列圧縮された一連の行(a set of hybrid columnar compressed rows)を格納します。データがロードされると、一連の行の列の値がグループ化され、圧縮されます。一連の行の列データが圧縮された後、圧縮単位に格納されます。Hybrid Columnar Compressionでストレージを最大限に節約するためには、データウェアハウスのバルクロード(ダイレクトパス)の技術を使用して、データをロードする必要があります。よく使われるバルクロードの操作の例には以下のようなものがあります。
    • APPENDヒント句を使ったInsert文
    • パラレルDML
    • ダイレクトパスSQL*Loader
    • Create Table as Select(CTAS)
    一般に、Hybrid Columnar Compressionを使うと、6倍から15倍以上の圧縮率でストレージの使用量を削減できます。

    USAGE

    Oracle Database 12c Release 2以前では、Hybrid Columnar Compression(HCC)はOLTPアプリケーションを対象にしておらず、そのかわりに、バルクロード操作を使ってデータをロードし、変更しない(もしくはほぼ変更しない)ようなデータウェアハウスアプリケーション(もっぱら読み取り)に最適なものでした。HCCで圧縮されたデータを、UPDATEやINSERTといった通常のデータ操作言語(DML)を使った操作で変更することはできますが、HCCで圧縮はDML操作をしない、もしくはほとんど操作しないアプリケーションに適しています。頻繁にUPDATEやINSERT操作を表やパーティションに対して予定している場合、そういったデータに対しては、Advanced Row Compression(Oracle Advanced Compressionの機能)が適しています。(Hybrid Columnar Compressionを利用している場合)DMLを使ってINSERT/UPDATEされたデータであれば通常、圧縮率が2倍から4倍にまで低下します。
    12cR2では新たに、PL/SQLやOracle Call Interface(OCI)といったプログラムでAPPENDヒント句や配列の挿入を行わなくても、SQL INSERT ... SELECT文の新しいデータをHybrid Columnar Compressionで自動的に圧縮します。12cR2以前では、こうした操作でHybrid Columnar Compressionの圧縮レベルが低下しましたが、最新リリースでは、圧縮レベルは変わりません。
    「Warehouse」と「Archive」圧縮の違いについては、下記のHybrid Columnar Compressionのホワイトペーパーで説明しています。

    今のところ、データベースストレージ最適化については、後続のブログエントリで続けていきます。NuremburgでのDOAG 2017(2017年11月)に行く予定がある場合は、データと索引圧縮に関する私のセッションにお立ち寄りください。詳細は後ほどお知らせします。

    More information:

    Advanced Row Compressionのホワイトペーパー(英語)
    http://www.oracle.com/technetwork/database/options/compression/advanced-compression-wp-12c-1896128.pdf
    Hybrid Columnar Compressionのホワイトペーパー(英語)
    http://www.oracle.com/technetwork/database/database-technologies/performance/hybridcolumnarcompression-oow2010-200703.pdf

    [Linux] Oracle Linux 7 Update 4 General Availability

    原文はこちら。
    https://blogs.oracle.com/linux/oracle-linux-7-update-4-general-availability-v2

    Oracleはx86-64サーバ向けOracle Linux Update 4の一般提供(General Availability)を発表できてうれしく思っています。
    Oracle Linux OSはクラウドのためのオープンな基盤で、Oracle Databaseだけでなく、多くのパブリックおよびプライベート・クラウドのサードパーティアプリケーションのような、エンタープライズ・ワークロードを使用して開発され、幅広くテストされています。Oracle Linuxはオープンソースであり、標準的なテクノロジやツール、機能を備えていますが、Oracleはこのリリースを拡張し、パフォーマンスを重視した本番環境でのワークロードのための、完全に統合されかつサポート対象となるプラットフォームを提供します。Red Hat Compatible Kernel(RHCK)に加えて、Oracle Linux(UEK)用に最適化されたUnbreakable Enterprise Kernelを提供します。UEKは、スケーラビリティの高いOracle Database、アプリケーション、およびOracle Engineered Systemsをサポートするために開発されました。
    Unbreakable Enterprise Kernel for Oracle Linux
    http://www.oracle.com/technetwork/server-storage/linux/technologies/uek-overview-2043074.html
    Oracleは、柔軟で費用効果の高いLinuxサポートを提供します。また、アップデートやソフトウェアリリースは無料でダウンロードして配布することができます。
    Oracle Linux 7 Update 4のリリースで、Oracle Linuxの実績あるエンタープライズおよびクラウド機能を引き続き足場とします。これにより、今日のために最適化し、明日への準備を可能にします。

    What's New

    このアップデートに含まれるOracle Linux 7の機能強化はいくつかの領域(セキュリティ、クラウドおよびコンテナ環境のサポート、パフォーマンス)にわたります。

    Security

    Oracle Linux 7 Update 4では引き続き以下の新機能を加えてセキュリティを強化しています。
    • UEFI Secure Boot
    • Secure BootモードのシステムはOracleが署名済みのブートローダやカーネルのみをロードします。Oracleは kernel と grub2 パッケージを更新し、これらのパッケージを正しいExtended Validation (EV) 証明書を使って署名済みです。EV証明書はshimバイナリにコンパイルされており、Microsoftによって署名されています。
    • openSSH now uses SHA-2
    • このリリースで使用される公開鍵署名のアルゴリズムは、デフォルトでSHA-2です。 SHA-1 は後方互換性のために利用可能です。
    • payload_gpgcheck option to yum
    • インストール時のセキュリティを強化します。新たなpayload_gpgcheckオプションを使うと、yum で インストール時のセキュリティを強化します。 新しいpayload_gpgcheckオプションを使用すると、yumはパッケージのペイロードセクションでGNU Privacy Guard (GPG) 署名の確認を実行できます。この機能により、パッケージのインストール時にセキュリティと整合性が強化されます。
    • New NBDE security packages
    • NBDEを使うと、物理マシンのハードドライブルートボリュームを暗号化できます。システム再起動時に手作業でパスワードを入れる必要はありません。
    • New usbguard package
    • USBGuardソフトウェアフレームワークは、デバイス属性に基づいた基本的なホワイトリストおよびブラックリスト機能を実装することにより、侵入型USBデバイスに対するシステム保護を提供します。

    Cloud and Containers Enhancements

    Oracle Linux 7 Update 4はお客様のクラウドおよびコンテナの展開を継続的に強化しています。
    • Btrfs
    • Btrfsはクラウドのコンテナをサポートする理想的なファイルシステムです。Oracle Linux 7と Unbreakable Enterprise Kernel Release 4でBtrfsを引き続きサポートならびに強化していきますので、コンテナをクラウドへ展開するために継続してBtrfsをご利用いただけます。
    • User Namespace
    • コンテナユーザーはグローバルレベルで同じ権限を取得できません。基礎となるOSの名前空間からコンテナ名前空間を分離することにより、コンテナユーザーはグローバルレベルで同じ権限を取得できないようにします。
    • Spacewalk
    • Oracle Linux 7 Update 4では、Spacewalkサーバーに登録する前に、SpaceKalkクライアントをインストールする必要がないため、SpacewalkのインストールおよびシステムのSpacewalkへの追加がさらに簡単になっています。

    Performance Enhancements

    Oracle Linux 7 Update 4は、エンタープライズ環境でのパフォーマンスですでに実証済みのリーダーシップを引き続き向上していきます。注目すべき変更点は次のとおりです。
    • Improved operating system scalability and performance
    • ticket spinlockをqueued spinlockに置き換えました。これにより、競合時のスケーラビリティ向上ならびにパフォーマンス全体が向上しています。
    • Addition of http-parser performance package
    • http-parserは高性能Webアプリケーション用に設計されており、バッファリング、システムコール、および割り込みを排除します。
    • Addition of libfastjson package
    • libfastjsonは限定機能セットJSONライブラリで、json-cと比較して、大幅にパフォーマンスが改善されています。

    Compatibility

    Oracle Linuxは、Red Hat Enterprise Linux(RHEL)とのユーザー空間の互換性を維持します。なお、OSの基礎となるカーネル・バージョンには依存しません。ユーザスペース内の既存のアプリケーションは、Unbreakable Enterprise Kernel Release 4(UEK R4)で修正せずに実行でき、RHEL認定アプリケーションの再認証は不要です。
    Oracle Linux 7 Update 4では以下のカーネルパッケージを同梱しています。
    • kernel-3.10.0-693.el7
    • Red Hat Compatible Kernel (RHCK)
    • kernel-uek-4.1.12-94.3.9.el7uek
    • Unbreakable Enterprise Kernel Release 4 update 4 (UEK R4u4) (デフォルトのカーネル)。
    同梱カーネルのソースコードは、初期リリース後、public gitソースコードリポジトリからご利用いただけます。
    Oracle Unbreakable Enterprise Kernel
    https://oss.oracle.com/git/?p=linux-uek.git

    More Information

    Oracle Linux 7 Update 4の上記で紹介した新機能ならびにその他の新機能や変更点の詳細については、Oracle Linux Product Documentation Libraryのリリースノートを参照してください。
    Oracle® Linux Release Notes for Oracle Linux 7 Update 4
    http://docs.oracle.com/cd/E52668_01/E88149/html/index.html
    Oracle Linuxは無料でダウンロード、使用、配布することができ、アップデートやエラッタは自由に利用できます。一部のアップデートには、Oracle Linux Premier/Extended Supportが必要な場合があります。
    Oracle Linux
    https://www.oracle.com/linux/index.html
    Free Updates and Errata for Oracle Linux
    https://blogs.oracle.com/linux/free-updates-and-errata-for-oracle-linux
    Oracle Linux and Oracle VM Support Policies
    http://www.oracle.com/us/support/library/enterprise-linux-support-policies-069172.pdf
    サポートについては、サポート契約が必要なシステムを決定できるため、Oracle Linuxは、開発、テスト、および本番環境に最適です。すべてのシステムを最新かつ安全に保ちながら、サポート対象範囲をシステムごとに個別に最適なものに決めることができます。
    Oracle Linux Support
    https://www.oracle.com/linux/support/index.html
    Oracle Linux Premier Supportをご利用のお客様は、Ceph Storage、Oracle Linuxソフトウェア・コレクション、Oracle OpenStack、Oracle Kspliceを使用してのカーネルの無停止アップデートといった、追加Linuxプログラムもサポートされます。
    Oracle OpenStack Release 3
    http://www.oracle.com/technetwork/server-storage/openstack/linux/documentation/datasheet-oracle-openstack-2296038.pdf
    Oracle Ksplice
    http://www.oracle.com/us/technologies/linux/ksplice-datasheet-487388.pdf

    Resources

    [Java] JVM Language Summit 2017に参加しました

    7月31日から8月2日にかけてOracle Santa Clara Campusで開催されたJVM Language Summit(以下、JVMLS)に参加しました。

    JavaOneが、今現在もしくは近い将来のテクノロジー、プロジェクト事例などを紹介する、どちらかと言えばユーザーサイドの開発者寄りのイベントであるのに対し、JVMLSはJavaをはじめとするJVMで動作する言語の実装の詳細や将来の実装方針などを説明する、技術的にかなりコアな内容を取り扱うイベントです。参加者はOracleをはじめとして、Facebook、Google、IBM、AWS、Alibaba、その他Expert GroupメンバーやOpenJDK開発者が参加していました。

    # 昨年のJavaOneで "I'm your father." の台詞を(台本持ちながら)言ったあの方も参加登録されていましたが、来場はされていなかったようです。

    会場は、Santa Clara CampusのOracle Auditoriumでした。


    セッションについて

    Workshopを除き、YouTubeに公開されています。


    セッションの内容は、「おおっ、それ早く実装してちょうだい」と思わされるもの、「いや、それ自己満足の世界じゃないか」ってもの、キワモノまで玉石混交でしたが、色々な意味を含めて、知的好奇心を満たすのに十分に濃い内容であったといえます。
    個人的には、Graal、Pattern Matchingの話は興味深かったですね。その他、キワモノ好きにはたまらない内容でした。

    JVMV8について語ったJim Laskey(NashornのTech Lead)は、セッション内で以下のようなことを言ってました。
    「NashornはJavaScriptの形でJavaのアーティファクトにアクセスすることを目的に作成したんだけど、利用者からは、JVMでJavaScript、特にNode.jsなどを動かすことを期待されたんだよね」
    「過去には確かに頑張ったんだけど、(Avatar.jsってのもあったけど、お蔵入りになって)やっぱりだめだった」
    「V8やSpiderMonkeyは着実に進化していて、それに追随するの結構つらいのよ」
    「だから、V8をJVMから操作できるようにしたらええんちゃうの、って思って、JVMV8ってのを作ってみたわけよ」
    # いやいや、J2V8ってのがあるんで、何を今更、という感じはしましたし、Graalでもいいのでは、と心の中でツッコミを入れましたが。

    「来年はJVMLSに参加してみたい!」と思ってらっしゃる方に

    • 基本的に現在リリースされているものや近い将来(今回の場合で言えばJDK 9)に対する情報は出てこないので、そういう情報を知りたい場合にはJavaOneのほうがいいでしょう
    • JDKやJVMの深いところまで知っていると、話についていけるので楽しめるでしょう
    • 実験的なプロジェクト(例えばGraalとか)に興味がある人には面白いでしょう
    • Workshopは日本で言うところのHands-onではなく、Discussionなので、話を聞いているだけよりは質問を投げかけられるほうが楽しいでしょう

    食事、宿泊、フライトについて

    • 食事は朝、昼と出ます。味は個人の好みがあるので何とも言えませんが、JavaOneのようなことはありません。今年は2日目の夜にイタリアンレストランでDinnerでしたので、食事代はあまりかからずにすみました。
    • 最寄りのホテルは、Hyatt House Santa Claraです。Oracle Campusまで徒歩で行けます。
    • Hyatt House Santa Claraに泊まった場合、Safewayというスーパーマーケットが近くにあるので買い物には困りません(食料品がアメリカサイズなのはご愛敬)。
    • 空港(San Jose International Airport)からは5マイル弱なので、ホテルに送迎を依頼できます。もちろんUberやレンタカーでもOKです。
    • フライトは、2017/08/02現在ANAの直行便があります。この時期は乗り継ぎ便でも直行便よりお値段が高くなることがありますので、行くと決めたらさくっと予約されることをお奨めします。

    その他

    • 今年はAlibabaの方が発表していたので、いずれ日本の誰かが発表される日が来ることを願っています(個人的には、全てにAliという頭文字が付くのがどこかの会社と同じように思えてなりませんでした)。
    • 屋外はいかにも夏な陽射しですが、会場は例によってエアコン効きまくっているので、上着必須です。OpenWorldやJavaOneの会場と同じぐらいのエアコンの効き具合と思っていただければ。
    • 参加の記念品に、Project Jigsawにかけてジグソーパズルを頂きました。

    [Java] Java EE 8 - July recap

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

    通常は夏になると原則するものですが、この直近の数週間はJava EE 8にとって重要でした。ここでは、先月のJava EE 8プラットフォームの進捗状況を簡単にまとめます。
    Java EE 8 July stats
    7月、JSON-B (JSR 367) がファイナルを迎えました。
    JSR-000367 JavaTM API for JSON Binding (JSON-B)
    https://jcp.org/aboutJava/communityprocess/final/jsr367/index.html
    これはつまり、ここまでで4個のJava EE 8関連のAPIが最終化されたことを意味します。CDI 2.0 (JSR 365)、JSF 2.3 (JSR 372)、JSON-P 1.1 (JSR 374)、そしてJSON-B (JSR 367)です。
    JSR 365: Contexts and Dependency Injection for JavaTM 2.0
    https://jcp.org/en/jsr/detail?id=365
    JSR 372: JavaServer Faces (JSF 2.3) Specification.
    https://jcp.org/en/jsr/detail?id=372
    JSR 374: JavaTM API for JSON Processing 1.1
    https://jcp.org/en/jsr/detail?id=374
    JSR 367: JavaTM API for JSON Binding (JSON-B)
    https://jcp.org/en/jsr/detail?id=367
    なお、Maintenance ReleaseでアップデートされたAPI(例えば、JPA 2.2も最終化されましたが)は除いています。
    Java Persistence API specification
    https://github.com/javaee/jpa-spec
    Servlet 4.0 (JSR 369) はProposed Final Draft期間を終え、まもなくProposed Final Draftの投票に入ります。
    JSR 369: JavaTM Servlet 4.0 Specification
    https://jcp.org/en/jsr/detail?id=369
    JAX-RS 2.1(JSR 370)とBean Validation 2.0(JSR 380)では、両方の仕様がProposed Final Draftの期間を過ぎ、両者とも7月のFinal Approval Ballotは満場一致で通過したため、少し早くなりました。
    JSR 370: JavaTM API for RESTful Web Services (JAX-RS 2.1) Specification
    https://jcp.org/en/jsr/detail?id=370
    JSR 380: Bean Validation 2.0
    https://jcp.org/en/jsr/detail?id=380
    結果は以下からご覧いただけます。
    JSR #370: JavaTM API for RESTful Web Services (JAX-RS 2.1) Specification Final Approval Ballot
    https://jcp.org/en/jsr/results?id=6031
    JSR #380: Bean Validation 2.0 Final Approval Ballot
    https://jcp.org/en/jsr/results?id=6033
    JAX-RSおよびBean ValidationのExperts Groupsのみなさん、おめでとうございます!

    7月、Java EE 8 Expert Groupは自身のProposed Final Draftを公開し、Final Approval Ballotに入るため、Final DraftをJCPに速やかに提出します。
    JSR-000366 JavaTM Platform, Enterprise Edition 8
    https://jcp.org/aboutJava/communityprocess/pfd/jsr366/index.html
    Java EE 8 Platform and Web Profile Final Draft specs
    https://javaee.groups.io/g/javaee-spec/messages?start=8:2017:-120
    7月中旬、Security API for Java EE (JSR 375) Expert GroupがProposed Final Draftをリリースし、活発に技術詳細の最終化に取り組んでいます。
    JSR 375: JavaTM EE Security API
    https://jcp.org/en/jsr/detail?id=375
    JSR-000375 JavaTM EE Security API
    https://jcp.org/aboutJava/communityprocess/pfd/jsr375/index.html
    javaee-security-spec Topics
    https://javaee.groups.io/g/javaee-security-spec/topics
    Java EE 8プラットフォームの最終化に近づいていますので、GlassFish 5 Promotionプロセスも加速してきました。ゴールは現在1週間に2個のGlassFish 5 Promoted Buildをリリースすることです。
    Twice a week GlassFish promotions in coming weeks
    https://javaee.groups.io/g/glassfish/topic/twice_a_week_glassfish/5571976?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,5571976
    GlassFishについてお話すると、リポジトリの星(Star)の数はまだ比較的少ない状況です。
    The Open Source Java EE Reference Implementation
    https://github.com/javaee/glassfish
    これは、GlassFishのリポジトリが比較的若いという事実が説明する通りですが、GlassFish 5の最終版に徐々にしかし確実に近づくにつれ、その数が増えてもいいでしょう。そんなわけで、GlassFishをお使いの際は、GitHubでStarを是非付けてください。 この小さいながらも素晴らしい認識はワンクリックでOKです。

    [Java] Java Advanced Management Console 2.7

    原文はこちら。
    https://blogs.oracle.com/java-platform-group/java-advanced-management-console-27

    Java Platform Groupは、2017年7月18日、Java Advanced Management Console 2.7 (AMC) のリリースを発表できうれしく思っています。
    Advanced Management Console
    http://www.oracle.com/technetwork/java/javaseproducts/advanced-mgmt/index.html
    AMCはOracle Java SE Advancedに含まれるもので、システム管理者にエンタープライズでのJavaの管理をより強力かつ簡単に実現する機能を提供します。
    Oracle Java SE Advanced & Suite Products
    http://www.oracle.com/technetwork/java/javaseproducts/overview/index.html
    AMCの最も重要な機能をいくつかご紹介しましょう。

    Java Usage Tracking(Java利用状況の追跡)
    AMCはJavaの利用状況の追跡機能を使い、エンタープライズでのJavaアプリケーションならびにそのアプリケーションを実行するために使用しているJava Runtime Environment (JRE) の利用について完全なインサイトを得ることができます。AMCにはMicrosoft WindowsおよびmacOSシステム用のエージェントがあり、このエージェントを使って全ての利用可能なJREを発見し、自動的に利用状況の追跡を有効化します。サポート対象のJREは、1.4.2_35以後、5u33以後、6u25以後、そして7と8の全てのバージョンです。AMCエージェントは各管理対象のデスクトップで動作し、利用可能なJREに関する情報を収集します。AMCサーバは、この情報を使って、ベースラインを下回るJREや利用可能なJREの総数、バージョン、各デスクトップで利用可能なデプロイメント・ルールセットの詳細をレポートします。
    Java Platform, Standard Edition Usage Tracker Overview
    Output of Usage Tracker
    https://docs.oracle.com/javacomponents/usage-tracker/overview/toc.htm#A1012444

    Deployment Rule Set Management(デプロイメント・ルールセットの管理)
    デプロイメント・ルールセットを使うと、組織でJava AppletsやWeb Startアプリケーションを実行するために利用するJREのバージョンを集中定義および管理して、そういったアプリケーションを管理することができます。AMCを使ってデプロイメント・ルールセット(DRS:Deployment Rule Sets)を作成、構成し、デスクトップに対して配布することができます。管理者はデプロイメント・ルールセットを使って、既知ならびに安全なプログラムだけが利用可能な特定のJavaバージョンを構成し、アプリケーションのブラックリストやホワイトリストをメンテナンスすることができます。
    Java SE Advanced Management Console User's Guide
    Deployment Rule Sets Overview
    https://docs.oracle.com/javacomponents/advanced-management-console-1/user-guide/rule_sets.htm#JSAMU153

    Java Installer Customization(Javaインストーラのカスタマイズ)
    AMCを使って、管理者はJREのインストーラ・パッケージ(Microsoft Windows用のMSI、macOS用のPKG)をセットアップできます。こうしたカスタマイズされたインストーラを使って、システム管理者はエンタープライズにある全てのデスクトップに対し、JREのインストールを自動化、整合性を確保できます。管理者は、AMCを使って、カスタムのインストール前後で実行するスクリプトやデフォルトのインストール先などを定義することで、構成ファイルやカスタムインストーラを作成することができます。

    JRE Management (JREの管理)
    管理者は、AMCエージェントからJREバージョン情報を入手することで、古いJREをリモートからアンインストールしたり、カスタムMSI/PKGインストーラを選択したデスクトップにプッシュすることもできます。

    AMC 2.7には、エンタープライズにおけるJavaの監視と管理を強化するためのいくつかの機能拡張と修正が含まれています。それらのいくつかをご紹介します。
    • エンタープライズJavaインストーラではないインストーラをサポートしました。これにより、カスタマイズ不可能なJREをデスクトップにインストールできます(Microsoft WindowsのEXEインストーラとMacOSのDMGインストーラ)。
    • 動的に変更されたデスクトップグループを自動的に更新するようになりました。さらに、AMC 2.7では、個々のIPアドレスではなく、IPアドレスの範囲でデスクトップグループを作成することもできます。
      Java Platform, Standard Edition Advanced Management Console User's Guide 2.7
      Creating a Desktop Group
      https://docs.oracle.com/javacomponents/advanced-management-console-2/user-guide/desktop-groups-configuration.htm#JSAMV-GUID-B5523FA2-F8AC-4620-A1B8-3AA03CA2F0FE
    • AMC 2.7エージェントは管理対象のデスクトップでJava SE 9を検出できるようになりました。ユーザーは管理対象デスクトップ上でJava SE 9のインストールを検索したり、コンソールでJava SE 9上で動作するアプリケーションを検索したりすることもできます (Java SE 9を実行するOracle WebLogic Server上にAMCをデプロイできません)。
    • コンテナ・ベースのユーザー認証を使うと、Oracle WebLogic Serverでユーザー認証を構成し、AMCでそれを活用できます。
    • 以下の管理機能が改善されました
      • 管理対象のデスクトップで追跡対象とするJREを選択できるようになりました(Webで有効化されているJRE、全てのスタンドアロンJRE、全てのJRE。プライベートJREを含む)
      • 管理者が管理対象のデスクトップでエージェントのアップデート方法を選択できるようにするため、自動エージェントアップデートの停止できるようになりました
      • 管理者が管理対象のデスクトップでJREのインストールやアンインストールを管理出来るようにするため、Javaの自動更新を停止できるようになりました
      • 失敗したJUTレコードのファイルエクスポート・オプションが追加されました
    新機能や制限事項、既知の問題の詳細は、以下のリリースノートをご覧ください。
    Advanced Management Console 2.7 Release Notes
    http://www.oracle.com/technetwork/java/javaseproducts/documentation/default-3667236.html

    [Java] Understanding the Server JRE

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

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

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

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

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

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

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

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

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

    [misc.] Announcing Oracle Developers on Medium

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

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

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

    Related Content

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

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

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

    [Database] Python cx_Oracle 6.0 RC 2 is on PyPI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    GCログによると、4回目のGC前後でのヒープの利用状況の詳細は以下の通りです。
    {Heap before GC invocations=4 (full 0):
     PSYoungGen      total 17408K, used 17392K [0x00000000fdf00000, 0x0000000100000000, 0x0000000100000000)
      eden space 16384K, 100% used [0x00000000fdf00000,0x00000000fef00000,0x00000000fef00000)
      from space 1024K, 98% used [0x00000000fef00000,0x00000000feffc010,0x00000000ff000000)
      to   space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
     ParOldGen       total 68608K, used 34096K [0x00000000f9c00000, 0x00000000fdf00000, 0x00000000fdf00000)
      object space 68608K, 49% used [0x00000000f9c00000,0x00000000fbd4c000,0x00000000fdf00000)
     Metaspace       used 2612K, capacity 4486K, committed 4864K, reserved 1056768K
      class space    used 285K, capacity 386K, committed 512K, reserved 1048576K
    
    [GC (Allocation Failure) [PSYoungGen: 17392K->1024K(32768K)] 51488K->52816K(101376K), 0.0101398 secs] [Times: user=0.00 sys=0.00, real=0.00
    
    Heap after GC invocations=4 (full 0):
     PSYoungGen      total 32768K, used 1024K [0x00000000fdf00000, 0x0000000100000000, 0x0000000100000000)
      eden space 31744K, 0% used [0x00000000fdf00000,0x00000000fdf00000,0x00000000ffe00000)
      from space 1024K, 100% used [0x00000000fff00000,0x0000000100000000,0x0000000100000000)
      to   space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)
     ParOldGen       total 68608K, used 51792K [0x00000000f9c00000, 0x00000000fdf00000, 0x00000000fdf00000)
      object space 68608K, 75% used [0x00000000f9c00000,0x00000000fce94050,0x00000000fdf00000)
     Metaspace       used 2612K, capacity 4486K, committed 4864K, reserved 1056768K
      class space    used 285K, capacity 386K, committed 512K, reserved 1048576K
    }
    
    Heap Dump (before full gc): Dumping heap to java_pid31684.hprof ...
    
    ParOldGenの'object space'の使用量の変化に着目してください。

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


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

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

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

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

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

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

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

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

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

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

    [WLS] Using REST to Create an AGL Data Source

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

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

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

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

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

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

    Conclusion

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

    References:

    About the Author

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

    [Java] Get Ready for Java 9

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

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

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

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

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

    [Java] Looking at JDK 9 with Categories

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

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

    Behind the scene
    New Standards
    New Functionality
    Housekeeping
    Specialized
    New Standards

    [Java] New Java Magazine Issue: Inside Java 9

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

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

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

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

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

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


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


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

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

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

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

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

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

    3rd-Generation API Platform

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

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

      The End of "Fat" Middleware

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


      API Capability Model

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

      Conclusion

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

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

      About the Author

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