BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Spring Integration 2.0リリース

Spring Integration 2.0リリース

ブックマーク

原文(投稿日:2010/12/06)へのリンク

SpringSourceはSpring Integration 2.0をリリースした。Spring Integration は慣れ親しんだSpringのスタイルを使ってイベント駆動アプリケーションやメッセージ指向アプリケーションを構築するための軽量フレームワークだ。InfoQはこのプロジェクトで指導的な役割を果たしているMark Fisher氏にこの新しいリリースについて話を聞いた。

InfoQ:Spring Integrationとは何ですか。どのような問題を解決するのでしょうか。

Mark Fisher:Spring Integrationはエンタープライズ統合パターンの領域にSpringのプログラミングモデルを導入します。エンタープライズ統合パターンはGregor Hohpe氏とBobby Woolf氏の共著Enterprise Integration Patternsに書かれています。高いレベルから見るとこのフレームワークの機能はふたつに分類できます。ひとつはSpringベースのアプリケーションの内部で利用できる軽量メッセージのためのAPIを提供することです。そして、RoutersSplittersService Activatorsのようなエンタープライズ統合パターンを構成ファイルの定義でサポートします。もうひとつは宣言的に定義されたアダプタを使って外部システムと連携するサポートモジュールを提供します。これらのアダプタはSpring Frameworkのリモーティングやメセージング、スケジューリングのサポートを高いレベルで抽象化します。しかし、Springと同様にSpring Integrationの最大の目的はエンタープライズ統合ソリューションを実現するためのアプリケーション構築にシンプルなモデルを提供することです。そして、関心事の分離をきれいに維持することで、コードをメンテナンスしやすくテストしやすくすることです。

InfoQ: MessageListenerContainerや他のライブラリをそのまま利用するだけではだめですか。

MF: まず、知らない方のために説明しますが、Spring Frameworkの MessageListenerContainerは、JMSをしっかりサポートします。リスナがPOJOでも、mainメソッドから起動するアプリケーションでも、ユニットテストでも、どのような環境で実行されるアプリケーションでも利用できます。このMessageListenerContainerのサポート力がSpring Integrationの主要な着想になっているのは事実です。これと同じようなモデルをより高い抽象レベルで実現しようと決めたのです。JMSのDestinationsのかわりに、私たちは包括的なMessage Channelを定義しました。このチャンネルはローカルの単一プロセス内だけに存在するかもしれません。また、JMSのDestinationsにマップされているChannel Adapterに接続される場合もありますし、そのほかのAPIやプロトコルやトランスポートを扱うこともあります。例えば、Spring AMQPプロジェクトはこれと同じのMessageListenerContainerをRabbitMQのようなAMQPベースのアプリケーションにも適用しています。

なのでSpring Integrationを使えば、JMS Channel Adapterを簡単にAMQP Channel Adapterに置き換えることができます。他に変える必要のあるものはありません。Message Channelも同じままです。メッセージオブジェクトはやり取りをするトランスポートに固有の形式にマップされます。その上、同じ手法が従来のメッセージングソリューションにも勝ります。例えば、ファイルシステム上のディレクトリを"リッスン"したい場合、インバウンドのFile Channel Adapterを追加すれば済みます。自分で構成したトリガに基づいて裏でポーリングしながら、ファイルが現れるたびに、そのファイルがペイロードになっているメッセージオブジェクトを発行します。メール送信を行うメッセージを発行したいのなら、SMTP Channel Adapterを使えばいいでしょう。ウェブサービスを起動したい場合はリクエストを含むメッセージを送信し、レスポンスを含むメッセージを受信すればいいのです。もとの質問に戻りますが、もちろんJavaMailのAPIを直接呼び出すコードを書くこともできますが、Spring Integrationを使えば同じくらい簡単にメッセージの中の要素を構成できます。すべてのアダプタは同じパターンで適用できますので、ソースやターゲットのシステムに対して一貫したスタイルの構成駆動の接続方法を実現できます。つまり、フレームワークがサポートするメッセージ駆動のPOJOの力が他のすべてのアダプタでも利用できるようになるのです。

InfoQ: 他のフレームワークを通して利用するのはどうですか。

MF: Spring IntegrationはSpringプラットフォームの第一級のメンバです。Spring frameworkの上に構築されていますし、Springのコンポーネントモデルを再利用し、SpringやSpring Web ServicesやSpring Securityの他のプロジェクトが提供する多くの抽象化の恩恵を受けています。APIを探したいなら、コードをチェックアウトして探せばいいだけです。オープンソースですから。そうすれば、Springの評判を上げた読みやすさとシンプルさがSpring Integrationにもあることに気付いてもらえると思います。私の考えでは、最も重要な特徴は実際のAPIの設計ではなく、すでにSpringを利用していればSpring Integrationを導入しても一貫性が保てるということです。Springでどのようにトランザクションを構成すればいいのか知っていれば、Spring Integrationにも同じ構成を適用できます。ライフサイクル管理やスレッド管理、タスクスケジューリングや監視、JMX経由の管理なども同様です。また、SpringのJMSサポートやウェブサービスのサポート、RestTemplateJdbcTemplate、Mail Senderなどの上にすべてのアダプタが揃っています。Springでこれらの抽象サービスを使ったことがあれば、テンプレートパターンとストラテジパターンが共通で使われていることに気付くでしょう。Springの開発者であればこれと同じインターフェイスを知っているか、ひょっとしたら実装したことがあるかもしれません。これがSpring Integrationでも使われています。JMS MessageConverterやJMS DestinationResolverHttpMessageConverter、JDBC RowMapperなど他にもたくさんあります。ですので、質問に答えるとすれば、他のフレームワークをSpringに統合するのはある程度可能ですが、AOPSpringのApplicationContextからBeansを探したり、Springの依存注入やAOPサポートを享受するには限界があります。再利用性や一貫性の度合いについては話になりません。SpringのPlatformTransactionManager TaskExecutorの実装を当てにしたいのなら、Spring Integrationは全く同じストラテジをすでに利用しています。フレームワークを通じて同じ程度の再利用性を享受できることが分かったらSpringのユーザは喜ぶでしょう。学習曲線も平になります。他のフレームワークを使う場合は、そのフレームワークの中核部分とSpringが直接依存するのは避けるでしょう。Spring Integrationは中核にSpringがあります。これが私たちがこのプロジェクトを作った主な理由なのです。

InfoQ:Spring IntegrationはESBですか。

MF: 違います。Spring Integrationはフレームワークです。しかし、ESBだと思われてしまうような問題解決も可能です。明らかな違いはSpring Integrationはこれ自体では"サーバ"ではないことです。むしろ、Spring Integrationアプリケーションは普通のSpringアプリケーションに、サーバとして実行できるようにいくつかの"Beans"が追加されたものです。個人的には、メッセージングが適しているところにRPCモデルを持ち込もうとして何年もつらい思いに耐えてきたと思います。私たちは通常、Spring Integrationを"組み込みメッセージバス"と説明しています。というのは、すべてのコンポーネントがSpring管理のオブジェクトなので、Springアプリケーションが実行できるところではどこでも利用できるからです。また、より開発者が扱いやすい、ESBに代替になることも意図しています。Spring IntegrationはSpringのイディオムを再利用していますので、多くの開発者は既に知っていますし理解されていますので、学習曲線も比較的平になります。Spring Integrationの必要なJARインクルードして、構成にコンポーネントを定義すればいいのです。

InfoQ: Springの中核のフレームワークや他のSpringプラットフォームのプロジェクトとSpring Integrationの関係はどうでしょうか。

MF: Spring Integrationは他の多くのSpringSourceプロジェクトを利用して構築されています。Spring Web Servicesを使ってウェブサービスをサポートしますし、セキュリティについてはSpring Securityを使います。Spring IntegrationとSpring Batchの相性は抜群で、Scatter/GatherのようなEIPパターンをうまく利用したイベント駆動型の処理やバッチジョブを構築できます。Spring BlazeDS Integrationプロジェクトを利用すれば、サーバサイドFlexアプリケーションとやり取りするSpring Integration Message Channelsのサポートも享受できます。この2.0リリースでこれらのことが実現できるようになりました。ツールのサポートについては、最新のSpringSource Tool SuiteはSpring Integrationのメッセージを扱える素晴らしいビジュアルエディタが既に搭載されています。さらに新しいプロジェクトにも機能を構築しています。例えば、サンドボックス内でSpring AMQPを使ったAMQPのサポートやSpring Gemfireを使ったGemfireのサポートを構築しています。また、サンドボックス内にはAlfresco Activitiプロジェクトと統合するためのワークフローゲートウェイもあります。Alfresco ActivitiプロジェクトはApacheライセンス2で公開されているBPMN 2の実装です。また、Spring Rooのアドオンをふたつ作成しています。ひとつはSpring Integrationのアプリケーションを構築するためのもので、もうひとつはSpring Integrationのアダプタプロジェクトを作成するためのものです。

InfoQ: 1.0を使っている場合、2.0にアップグレードするのはどうですか。大きな新機能はなんでしょう。

MF: まず、Spring 3.0の新しい強力な機能の利点を使っています。一番分かりやすいのは多くのコンポーネントでSpring Expression Languageが利用できるようになったことでしょう。例えば、トランスフォーメーションやルーティングのロジックが式で捉えられるくらい単純なら、そのロジックのためにPOJOを定義する必要すらありません。同じように、中核となるEIPコンポーネントではGroovyが使えます。また、Spring 3.0の機能にはTaskSchedulersで利用されているトリガストラテジがあります。さらに、POJO中心のモデルをさらに押し進めるための機能として、アノテーションベースのAOP駆動のメッセージ発行機構があります。これはフレームワークに直接依存することなくどのようなメソッドでも実行できる仕組みの副産物としてできたメッセージ発行機構です。Spring Integration 2.0は、多くのエンタープライズ統合パターンをサポートします。Message HistoryMessage StoreClaim Checkなどです。このなかではMessage Storeが便利でしょう。データベースかGemfireのような分散キャッシュを利用した状態を持つAggregatorsをストレージの選択肢として提供するからです。さらにMessage StoreはClaim Checkを支援します。中核部分以外にも多くの新しいアダプタを追加しました。TCP、UDP、JDBC、FTP、SFTP、XMPP、RSS、そしてTwitter向けのアダプタもあります。

InfoQ: 質問やフィードバックがある場合は、どのようにコードやフォーラム、JIRAにアクセスすればいいのでしょう。

MF: ホームページはhttp://www.springsource.org/spring-integrationです。ここを見ればすべての関連するページへのリンクが見つかります。ディストリビューションのダウンロード、Maven POMの構成方法、ソースコードからの構築方法、マニュアルへのアクセス方法、報告された問題、質問の投稿場所などが見つかるでしょう。それ以外にSpring Integrationに関するブログや記事も見つかります。

InfoQ: SI 3にはすぐに取りかかりますか。イテレーションはどのくらいの間隔だと思えばいいのでしょうか。例えば、Spring 3.1はもうすぐ発表されるようですが、それに合わせてアップデートする予定ですか。

MF: 次のリリースはSpring 3.1を使う予定です。来年の前半になるでしょう。サンドボックス内の多くの機能が来年のリリースに盛り込まれるでしょう。Spring 3.1だけではありません。サンドバックス内の多くのモジュールがSpringプラットフォームに比較的新しく追加された機能の上に構築されます。このプラットフォームは来年の前半に最初のGAリリースが行われる予定です。例えば、Spring AMQPをそのまま利用したChannel Adaptersがあります。Spring GemFireをそのまま利用したアダプタやMessage Storeの実装もあります。その他にも興味深いエクステンションが実装中です。さまざまな"NoSQL"データストアのサポートやソーシャルメディア、モバイルプラットフォームなどのサポートです。Spring Integrationを使った高いレベルでのサポートを提供するのが合理的な分野であれば何でもサポートされると期待していただいてかまいません。

この記事に星をつける

おすすめ度
スタイル

BT