Pivotalは先週のSpringOne2GXカンファレンスで，同社のビッグデータ製品であるSpring XDを完全に再設計し，名称をSpring Cloud Data Flowに改めることを発表した。新しい製品では，実行可能なアプリケーションをモジュールの基盤として使用し，そのオーケストレーションを重視する。最上位レベルのREST APIやシェル，UIはSpring XDのものを使用して後方互換性を確保しているが，それ以下の部分では大きく異なっている。
Spring XDで使用されていたZookeeperベースのランタイムは廃止され，Pivotal Cloud FoundryやLattice，Yarnといった他システムを利用して，マイクロサービスのローンチやスケールアップ，モニタを行うサービスプロバイダインターフェース(SPI)に置き換えられた。従って，例えばLattice用のSPIでは，receptor APIを使用してモジュールのローンチを行う。Cloud Foundry上ではクラウド管理APIが使用される。旧XDのシングルノードのように，プロセス内で動作するローカル実装も用意されている。
“基本的な方針として，上位APIは維持されています”と，Pollack氏はカンファレンスで語った。“ただしその下では，これまでに確認された基本的な制限を克服するために，大幅なアーキテクチャの変更を行っています。”
ここで言及された制限には，スケーリング能力やカナリアデプロイメント，モジュール毎に別々のメモリアロケーションを提供するなどのリソース管理，分散トレースなど，現行のアーキテクチャがサポートしていないものが含まれる。その他，独立したマイクロサービスアプリケーションアーキテクチャがフラットなクラスローダを必要とするのに対して，旧式の親子型クラスローダ階層が使用されているという制限もある。
そのクラスローダの問題を解決するため，既存のインテグレーションとバッチモジュールが，独立型のフラットなクラスローダを備えたSpring Bootアプリにリファクタされた。再設計の結果，ストリームアプリケーションとバッチアプリケーションはともに，それぞれ独立した発展の可能なデータマイクロサービスとして実行可能になった。いずれのモジュールも，Spring Cloud Data Flowの関与がまったくなくても動作する – Javaの -jar がその代用をする – が，データフロー層があれば，プロパティの設定など手間のかかる作業の大部分が不要になる。さまざまな改善の中でもっとも分かりやすいのは，ZookeeperベースのXDコンテナで実行されていた頃と違い，独立したモジュール用のユニットテストが記述可能になったことだ。これによってコミュニティからのコントリビュータの数も増えて，マーケットの立ち上がりに弾みが付くことだろう。
Bootモジュールの下には，Spring Cloud StreamとSpring Cloud Taskという２つのプロジェクトがある。それぞれSpring IntegrationとSpring Batchに，自動構成機能を提供する目的で開発されたものだ。
プログラミングモデルの概要を理解するために，Mark Fisher氏とDave Syer氏が2回目のプレゼンテーションで紹介したインバウンドチャネルアダプタ(Spring Integrationの標準的なアノテーションを使用している)のコードを示す。このアダプタは，既定値ではSpring Integrationによって毎秒コールされる。
@EnableBinding(Source.class)
public class Greeter {
@InboundChannelAdapter(Source.OUTPUT)
public String greet() {
return "hello world";
}
}@EnableBindings(Source.class)アノテーションがクラスパス上にあるバインダ実装を検索し，そのバインダをチャネルアダプタ生成時に利用する。このアノテーションは，インターフェースによってパラメータ化されている。SourceとSink, Processorは提供されているが，独自に定義することも可能だ。次の例は，Sourceそれ自体がメッセージチャネルインターフェースである場合だ。
public interface Source {
@Output("output")
MessageChannel output();
}@Outputアノテーションは出力チャネル(モジュールを出るメッセージ)の確認に，@Inputアノテーションは入力チャネル(モジュールに入るメッセージ)の確認に使用する。チャネル名をパラメータ指定することも可能で，省略時はメソッド名で代用される。
対応するSinkは別プロセスなので，例えば10プロセスを同時に実行するようなことも可能だ。このプロセスは他のミドルウェア統合チャネルを監視して，メッセージが到着するとアクティベートする。
@EnableBinding(Sink.class)
public class Logger {
@ServiceActivator(inputChannel=Sink.INPUT)
public void log(String message) {
System.out.println(message);
}
}これらの部品をつなぎ合わせる役割を持つのがSpring Cloud Data Flowだ。現在はマイルストンリリースが公開されている。