[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の学士号を取得している。