2016年のJava EEとマイクロサービスは？

2016年も少し過ぎたので，そろそろ昨年末に立てられた今年１年の予想を見直してみるのもよいだろう。昨年12月，C2B2のSteve Millidge氏は，2016年はJava EEとマイクロサービスの年になると予想をした。この予想は，まったく同じ話題を取り上げたJavaOneでの氏自身のセッションをある程度踏まえたものだ。さらにPayaraの共同創設者でもある氏には，Java EE開発者のマイクロサービスへの関心を喚起したいという目的もあるだろう。講演や以前の記事で紹介したように，氏は，SOAとマイクロサービスの差異を極めて小さいと考えていて，ビデオでも次のように述べている。

“マイクロサービスとSOAに違いはありません。マイクロサービスもSOAです。”

当然のことながら，氏の立場や現在のビジネスを理由とした反対意見もある。それは否定し難いものだ。しかしながら，マイクロサービスがまだ揺籃期にあった2014年にAdam Bien氏が，完全なJava EEマイクロサービスに関する記事をすでに書いている。

[...] 完全なJavaEEマイクロサービスは，単一の[エンティティコントロール境界を持った]コンポーネントとしてWARに格納され，ひとつのサーバないしドメインにデプロイされます。この形式であれば，コンポーネント(つまりマイクロサービス)を個別に，独立してリリースないしデプロイすることができます。WAR間で直接メソッドをコールすることはできません。WARが相互通信するためにはJAX-RSなどを使わなくてはならないのです。

昨年末のMarkus Eisele氏とのインタビューで，マイクロサービスやDevOps, Java EEなどについて聞いた時，氏は，マイクロサービスの普及においてJava EEが重要な役割を果たすという自論を話してくれた。Java EEでマイクロサービスを記述するというアプローチは，TomEEやWildFly-Swarmなど，他にも数多くある。そのひとつが，Java EEマイクロサービスのフレームワークとしてJavaOne 2015でDuke’s Choice Awardを獲得したKumuluzEEだ。共同創設者のMatjaz Juric氏が次のように説明する。

KumuluzEEは，標準Java APIを使用した始めてのマイクロサービス用フレームワークです。マイクロサービスアーキテクチャでは，アプリケーションを複数のサービスとして開発し，独立してデプロイ可能とすることに注目します。JavaEEによる真のマイクロサービスアーキテクチャは，デプロイとコンフィギュレーションを自動化するフレームワークなしで実現することはできません。

マイクロサービスとJava EEの関係を見る上でいくつかの例を確認してみると，ある興味深い事実に気付く。その例の中には，従来のJava EEの領域に収まっていないものがいくつも含まれているのだ。例えば2014年にAlex Soto氏は，Java EEとRxJavaによるアプローチの素晴らしさを論じている。しかしながら，Java EEを使うことでマイクロサービスを包含することができる，とすべての人たちが考えているのではない。Rick Hightower氏の意見はこうだ。

WARファイルをJava EEコンテナにデプロイしているのならば，それは多分マイクロサービスのデプロイメントではありません。複数のWARファイルあるいはEARファイルがあるのならば，それは間違いなくマイクロサービスではありません。AMIあるいはdockerコンテナとしてサービスをデプロイしていて，mainメソッドがあるのならば，あなたはマイクロサービスを開発している可能性があります。

マイクロサービスがSOAと同じだということも，氏は信じていない。

実際には，多くの面で正反対です。例えばSOAでよく利用されるWSDLは，強い型付によってエンドポイントを厳密に定義する方法です。WSDLとXMLによるスキーマは，XMLのXをすべて取り去ってしまうのです。

SOAとWebサービスとの関連性の低さについては，当然のことながら，これまで何度も議論されてきた。しかしながら，氏を含む一部の人々はJava EEを，マイクロサービス開発の基盤とするにはあまりにも肥大化していて扱いにくいと考えている。Jeppe Cramon氏は，Java EEには他にも基盤として不足して欠いる基本的側面がある，という考えだ。

例えば，1クラス=1サービスというルールでモデリングされたスモールないしマイクロサービスと(同期)双方向通信，という組み合わせは，私たちを1990年代のCorbaとJ2EEと分散オブジェクトの世界に引き戻すものです。新世代の開発者たちは，残念ながら分散オブジェクトを経験していないため，この考えがどれほど不都合なのかを理解できないようなのです。こうして歴史は繰り返そうとしています。RIMあるいはIIOPからHTTPというように，技術が新しくなっただけなのです。

仮にもし，マイクロサービスとSOAに密接な関係があるのならば，マイクロサービスにもSOAと同じように，技術を選ばない方法でアプローチすることが可能なはずだ。そう思わないだろうか？果たして2016年はマイクロサービスとJava EEの年になるだろうか？マイクロサービスにおいてJava EEの役割が本当にあるならば，どのようなものなのだろう？