BT

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

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル Spring Integration事始め

Spring Integration事始め

ブックマーク

原文(投稿日:2009/1/20)へのリンク

なぜSpring Integrationか

Spring IntegrationはSpring Frameworkの開発者たちによるエンタープライズ・アプリケーション統合向けに調整されたAPIである。アプリケーション統合ということでは"ソリューション"に事欠きません。ハード・コーディングされたJavaクライアント、多くのESB、さらにはメッセージ・キューのような古典的なアプリケーション統合技術があります。Spring Integrationはどの場合にも通用する改善策を、時には劇的な方法で提供します。Spring Integrationはとても軽快で簡単にテストすることができます。使い始めるのにあたってほとんど障壁はなく、概念的にはどの"自分で書いてみよう"という方法よりもシンプルです。長い目で見ると柔軟で快適です。自分で作成しようという衝動は抑えられるでしょう。Spring IntegrationはEJB、RMI、そしてJMSといった標準技術と共に使うことができ、複雑なソリューションを一ヶ所にまとめることでそれらを強化することも出来ます。これによってそのような技術をかなり簡単に使えるようになります。Spring Integrationはとても軽快(あなたのアプリケーションをSpring Integration上にデプロイする必要はありません、Spring Integrationをあなたのアプリケーションと一緒にサーバにデプロイすればいいのです)で開発のライフサイクルに主眼を置いているので(設定を容易にするためのXMLスキーマ、POJOと親和性の高いAPI、そしてSpring FrameworkやJEEとの強力な統合)、その他のESBと比べてSpring Integrationがよく出来ていることに気が付くでしょう。

Spring Integrationはそれ自身とても強力ですが、Springフレームワークの恩恵を受けていることは否めません。例えば設定ファイルの形式はSpringのものそのものなのでbeanのインスタンス生成処理の手間を取り去ってくれます。Spring Integrationを使うとちょっとした魔法によってXMLファイルの設定によって行われていたことを全て行うmain(String[] args)メソッドを書けるようになります。Spring IntegrationによるRPCやメッセージのサポートのほとんどがSpringフレームワークの上に構築されているものです。Spring Integrationの設定ファイル上の全てが標準的なSpringアプリケーション・コンテキストに対応しているので、依存性注入(DI)や標準的なSpringのbeanに実行時の振る舞いを織り込む(AOP)ことが出来ます。SPりんg Integrationではアプリケーション・コンテキストはバスとして扱われます。これによって例えばアプリケーション・コンテキストのイベントに合わせたソリューションの提供を可能にします。また、これは“実行時”という状態がないことを意味しています。というのもアプリケーション・コンテキストがある限りバスが存在しているからです。

背景

エンタープライズ・アプリケーション統合(EAI)はアプリケーション間でデータとサービスを統合するための技術です。扱う問題は無数にあり、そのためのソリューションもほぼ無限と言えるぐらいにあります。技術者はこれらのソリューションの開発に何十年も費やして来ました。私たちがそれらの中からベスト・プラクティスと呼べるものを定義し分類するようになったのは、つい最近のことです。

近年のEAIパターンはたいていGregor Hohpe氏ほかによるEnterprise Integration Patterns [1]に拠るものです。この本では多くの統合ソリューションに共通する統合のパターンを分類し解説しています。Hohpe氏ほかでは4種類の統合方法を挙げています。:

  1. ファイル転送:2つのシステムが相手のシステムに処理してメッセージを内容に持つファイルを提供します。ディレクトリやFTPディレクトリをポーリングしてあるファイルを処理するというのがこの例です。
  2. データベース共有:2つのシステムがデータを取得するために同じデータベースへクエリを投げます。共通のテーブルを共有するエンティティ・クラス(JPA、Hibernateなど)を含む2つのEARをデプロイするのがこの例です。
  3. リモート・プロシージャ・コール:2つのシステムが共に相手から呼び出し可能なサービスを公開する方法です。EJBサービス、SOAP、そしてRESTサービスなどが例です。
  4. メッセージング:2つのシステムが共通のメッセージング・システムに接続しメッセージを使ってデータ交換や振る舞いを実行します。よく知られたJMSのハブ・スポーク型アーキテクチャがこの例になります。

どれか一つの方法がいつも使えるということはなく、これらは本質的に異なるものです。そこでこれらのパターンに基づくソリューションを可能にするような万能なミドルウェアの必要性が生じました。一般的にエンタープライズ・サービス・バス(ESB)と呼ばれるものです。ESBは究極の仲介人で、全ての言語、全てのプロトコルを知っていて、渡されたメッセージの仲介をするものです。

それぞれのアーキテクチャ・スタイルは異なるもので、それぞれ独自の利点があります。JEEの(さらに言えば最近のたいていのプラットフォームでも)標準仕様にはしばしば不足があり、他システムとの統合についてはソリューションが提供されていません。驚くべきことです。いったいどれだけのプロジェクトが運用されているでしょうか - 古いサービスや機能の強化に貢献した、輝かしい新しいプラットフォームに含まれる技術要素がどれだけ少ないことか。

JEE - そしてSpring - はエンタープライズ・プログラミング・モデルを簡単にすることに大きく貢献しました。JEEは一般的なエンタープライズの問題に対するソリューションを標準化し便利にしました。データベース・アクセス、リモート・プロシージャの実行、トランザクション、認証、ディレクトリ・サービスなどです。EAIソリューションはRPCとメッセージングを除いて、JEEでは直接サポートされません。

JMS、REST、そしてSOAPはプラットフォームを選ばない前提ですが、同一のメッセージ・プロトコルを使う必要があります。これは、例えば背後でFTPに配置されたバッチ・ファイルを入出力とするような古いメインフレームのアプリケーションとの統合が要求される場合のソリューションでは不可能なことです。

簡潔に述べると、最近のミドルウェアは一般的な状況はとてもうまく扱えますが、珍しい状況を扱うには不十分なのです。多くの掲示板やメーリング・リストで使われている購読処理について見てみましょう。一般的にユーザがメールを送信するとあるアプリケーションがそのメールを受信し、さらに"購読"という単語を求めてそのメールを解析し、ユーザをメーリング・リストに追加した後で返信を送信します。この場合、まず最初にeメールをポーリングするためにCRONやQuartzを使ってスケジューリングされたアプリケーションのようなものを構築することになるかもしれません。あるいはバッチ・ファイルを求めてFTPをチェックして、(あれば)そのファイルを実行するのかも知れません。これはとても退屈で脆い方法です。

その後すぐに難解な自体が発生します。時が経ちアプリケーションの重要さが増すに連れ、取引先や他のアプリケーション、あるいは他のプラットフォームとの統合が重荷になってきます。それぞれの統合によって新しいポイント・ツー・ポイントのチャンネルがシステムに追加され、それぞれを保守する必要があるのです。結果として、全てのエンドポイント間をそれぞれ統合するためにチャンネルをまとめることが耐えがたいほどの混乱状態を招きます。“スパゲッティ・アーキテクチャ”です。

SpringSource社のSpring Integration[2]はプログラミング・パラダイムを簡略化することで典型的なESBを改善します。

アーキテクチャを整理し強固にする方法

エンタープライズ・アプリケーション統合には多くのパターンがあり、同様にエンドポイントとやり取りするために対応しなければならないプロトコルもたくさんあります。Spring IntegrationはESBのモデルを作る方法を提供します。Springフレームワークを通して使い慣れたのと同じ方法、利便性を持ったソリューションを用意しています。しかし、ESBは単に異なる技術/プロトコル間のメッセージ送信方法のモデルを作成する方法を提供しているだけではありません。

ESBのサービス

多くのESBに共通している点がいくつかあります。その中でも特に重要なのが以下の点です。:

  1. ルーティング:常勤を記したロジックや設定された振り分けルールによってメッセージを振り分ける機能のこと。
  2. メッセージング:メッセージの中身をある形式から別の形式に変換すること。これはあらゆる複雑なソリューションにとって極めて重要な機能です。メッセージングではカノニカル・データ・デモル[3]パターンによってシステムが共通の形式を提供する必要があります。当然のことながら、メッセージ処理もまたESBの重要な一部となります。
  3. 仲介:アダプタとサービスのマッピングのこと。
  4. 複合イベントの処理(CEP):相互に関連付けられた処理の集合としてのバスによってイベントを処理できること。
  5. (サービスの)実行:これが最も明確かもしれません。ESBは各種サービスを使ったり提供したり出来ること。

一般的にESBは上記のサービスに対するロギング、監査、認可(セキュリティ)、そして管理といった機構を用意しています。

あなたが求めるものがそれほど複雑でなくてもESBは多くの価値を提供します。既にJEEプラットフォームが提供しているものとESBが提供してくれるものを比較するだけの価値があります。下表はESBとJEEっぽいソリューションが適した一般的な用途について比較したものです。

 

ESB

伝統的なJEEミドルウェア

メッセージ・キュー

XMLによる設定が可能で、通常使う全てのメッセージ処理パターンをサポートします。

例えばSpring JMSサポートではあまり多くのことはしません。

RPC

ほとんどのRPCサービスを呼び出すこと、提供すること、そして分離することが出来ます。

同様な無限の可能性があるが、標準的な方法がありません。

混成システムの統合

ESBは呼び出し時の扱いにくい部分を隔離し、標準化して、異なるメッセージとして送信します。

JEEはいくつかの少ない用途にだけ対応する。その解決策は複雑だけど速いものになりがちです。SOAPメッセージをFTPへ送信する場合、バッチ・ファイルがEJBに記録を取っておく場合、どちらの場合もJEEは解決策の半分しか提供しません。

Security

よくサポートしています。

よくサポートしています。

古いメインフレーム・システム

バッチ・ファイルを含め、JEEがサポートしている全ての相互通信方法を強力にサポートします。

例えばSOAPをフロント・エンドに配置でもしていない限り、JEEはCORBAよりも古いシステムはサポートしていません。

柔軟なルーティング

振り分けの判断は対応する全てのコンポーネントに対して可能な限り遅らせることが出来ます。

JMS、EJBなどはそれぞれが異なる設定方法で可用性と振り分け方法を指定する必要があります。“大局的な観点”を持つことが出来ません。

標準的でない要求に対する統合の容易さ

比較的簡単です。とりわけSpring Integrationは全てがPOJOでアプリケーション・サーバと統合されないので簡単です。逆を言うと、採用した方法が全てのESBで標準的に使えるとは限りません。

JCA[4]や、BEAのTuxedoのようなシステムに対する深い知識が必要です。(結果は様々でしょうが、)選択した方法は全てのJEEサーバが標準的に対応しているでしょう。

 

一般的な方法

Spring Integrationはまだ新しく、簡単に完成したものではありません。Mule[6]はとても有名なESBでよく見ておく価値があります。Muleは最も思想を共有していて、提供するソリューションの柔軟性の観点では最も印象的なレパートリーがあります。オープン・ソースの拡張機能がMuleForgeから入手できるので、ほとんど全ての問題に対して意義ある選択肢を提供していることになります。Muleは標準的なサーバです。ソリューションはMuleの上にデプロイされ、実行されます。さらにMavenプラグ・インによって開発のライフサイクルが容易になります。

ServiceMix[8]もまた多くの思想を共有しています。ServiceMixは元来Java Business Integration(JBI; JSR 208 [9])の仕様に基づいて作られています。JBIはESBを構築するためのJCP仕様です。ServiceMixはJBI準拠のためにMuleほどの柔軟性がありませんが、徐々に変わってきています。ServiceMixのコンテナはOSGI基盤に移行しつつあります。

存在している全てのESBを調べ尽くした訳ではないですが、機会があれば他のESBについて学習するのもいいでしょう。中には立派なものもあれば、研究する価値のあるものもあるでしょう。

Spring Integrationは備えている機能性が素晴らしく、それらの機能を使うのもとても簡単です。Spring Integrationを使った開発方法も賞賛に値するものです。もしあなたがPOJOやテストを重視したフレームワークに慣れ親しんでいるのでしたら、このフレームワークはまさにぴったりのものです。望むのならインタフェースや一般的なフレームワークのクラスを使うことも出来ますし、POJOやドメイン・モデルに処理を記述したりその両方を混ぜて使うことも出来ます。この記事で紹介するソリューションでは、何をしているのかハッキリさせるのと一貫性を保つためにフレームワークのクラスを使うことにしました。過剰な仕掛けは、初期の生産性を向上させるものの、時に混乱を招くこともあります。

使用を開始する

エンタープライズ・アプリケーション統合に関する速成講座

ほんの些細なアプリケーションの構築を通して開発のサイクルについて実例を見せようと思います。この例は理解できるように十分に簡単なものですが、がっかりするほど不自然なものではありません。さらに、それは手にしたくなるようなクールなツールです。その要求仕様は、ある決められたメール・アドレス宛にブログの内容をメール送信すると、その内容をブログとして投稿してくれるというものです。この機能の作成にはいくつかの意義があります。

(Google社のブログ・サービスである)Blogger[10]には既にこの機能が搭載されています。しかし、私はApache Rollerで自分のブログを公開していますので、この例のようなソリューションを使いたいと思います。ブログに書き込む気力が湧かないのは“書き込み”モードになる時間がないことによる副作用だと思います。Rollerはユーザにログインしてからブログのエントリを作成することを強要します。これはとても面倒なことです。WYSIWYGエディタと格闘しなければならないとしたら尚更です。もう一つこのようなソリューションを開発する一番の理由は、この例では可能な限り少ないパーツで簡単なシステム統合を提供できるということです。この記事で取り扱うだけの根拠があるということです。例には不自然な点もありますが、実用的なものでもあります。

システム統合をするのはとても簡単です。そして、“IDE”としては紙切れと鉛筆が最適でしょう。多くのツールで図を描くことが出来ます。描いた図を好みのESBの設定用の書式やツールに合わせて変換するのは簡単なことです。ESBは同じ“専門用語”を使います。一つのツールやESBを知ることよりもこの“専門用語”を知ることの方がより重要になります。

まずは復習としてESBに関する初歩的な定義を見てみましょう。メッセージとは、あるエンドポイントに関連付けられた送信内容のことです。エンドポイントとはチャンネルの終端のことで、チャンネルとは2つのエンドポイント間の特定の接続のことです。しばしば、メッセージはメッセージング・システムからそのメッセージング・システムのことを理解しないアプリケーション宛に送信されます。また逆もしかりで、メッセージング・システムのことを理解しないままにアプリケーションがデータを提供することもあります。これらの問題に対処するには、チャンネル・アダプタが必要になります。

まさにこの部分です。今回のソリューションについて語るにはこれらの事柄を知る必要があるのです。他の事柄はこれらの事柄から派生したか、これらの上に成り立つ仕様なのです。そうでなければ統合パターンに基づくもので、統合そのものに関することではないはずです。

Spring Integrationの概要

Spring IntegrationのアプリケーションはSpringのスキーマを使って設定されたシンプルなJavaのプログラムです。必要であれば通常のSpringの設定方法で全てを設定できますし、スキーマを使わない方法もあります。SpringでAOPを使ったトランザクションの設定を行うのにスキーマを使うと簡単であるのと同じように、スキーマによって設定は簡単になります。Spring Integrationは(統合という分野における)一般的な概念に対する使いやすいスキーマと同様に、eメールやファイル向けのアダプタに特化した設定方法も提供しています。

Spring Integrationのアプリケーションはチャンネル間を通過してきたメッセージという概念を扱います。メッセージの寿命はあるエンドポイントから始まり、一般的にはアダプタがそれを迎えます。メッセージは処理を行うパイプラインを通過するに連れ、変換され、他のチャンネルに転送され、分割され、応答もしくは破棄されて不通メッセージのチャンネルに送られます。これらは全てバスの中で行われることです。もしSpring Integrationのインタフェースを使ってプログラミングをするとしたら - 一貫性と透明性を可能な限り確保するために、たいていはそうしますが - 図1に示すMessageオブジェクトを扱うことになるでしょう。

image1

Messageクラスは処理対象となるメッセージの中身をラップしたものです。メッセージの中身やヘッダにアクセスしそれをキャストしたり、内容を調査したり変更するための便利なクラスになります。Spring IntegrationはMessageインタフェースを使うことを強要しません。作成するアプリケーションでは扱うメッセージと同じ型のパラメータを受け取るメソッドを公開することになるでしょう。例えば、ファイル用のアダプタ(ファイル・システム上で選択されたファイルをファイル・システム上から送信することが出来るアダプタ)から送られてくるメッセージはjava.io.Fileクラスのインスタンスとして送られることになるでしょう。

簡単な統合の例を見てみましょう。あるメール・アドレス宛に配信されたeメールを変換し、ブログに公開する例です。

この例の設定はsrc/main/resources/integrationContext.xmlにあります。ソース・コード全体はこちら(ZIP)からダウンロード出来ます。設定ファイルを見ると、まず最初の部分は普通です。XMLの最初の部分にあるのは設定ファイル内の変数をプロパティ・ファイルの内容に置換する責務を持ったBeanです。続いてこの統合例で使う簡単なサービスを含む、別のSpringファイルをインポートしています。特に興味深い点はありません。

その後、興味深い部分がはじまります。4つのBeanが立て続けに宣言されています。Service Activator(サービスを活性化するBean:newBlogPublishingServiceActivator)、Transformer(メッセージを変換するBean:emailToBlogTransformer)、Handler(メッセージを処理するBean:outboundBlogPostHandler)、そしてFilter(メッセージのフィルタリングを行うBean:emailsInFilterAgainstWhitelist)です。これらのBeanは後続の設定で使われます。

実際の統合に関する設定ファイルはpoller要素から始まります。これはデフォルトのドキュメント・ポーラーです。ポーラーというのは読んで字の如く、変更を確認するために異なるエンドポイントをポーリングして、もし何かしらの変更を検知したらアダプタにイベントとしてその変更の対応をさせるためのメカニズムです。ここではSpring Integration全体の設定として一つのデフォルトのポーラーを設定しています。その方が繰り返し定義するよりも簡単だからです。図2を見て下さい。

image2

続く3つの要素は3つのチャンネルを宣言したものです。何の意味があるのでしょう?単にチャンネルに名前を付けているだけです。エンドポイントやアダプタのないチャンネルは無意味です。図3を見て下さい。

image3

次の行でeメール・アダプタの設定をしています。このeメール・アダプタはシステムに送られてくるeメールを監視し、それらを上で宣言したemailsInと名付けられたチャンネルに引き渡します。知っての通りeメール・システムはメールを受信した際にブロードキャストをしません。(例えば、Spring IntegrationもサポートしているIMAP IDLEのような)例外もありますが、通常は新しいメールを確認するためにメール・アカウントをオーリングする仕組みが必要です。新しいメッセージがあると、1通ずつ読み取りプロセスを処理するパイプラインの次のコンポーネントに渡します。図4を見て下さい。

image4

メッセージは今emailsInのチャンネルにあり、チャンネルにある次のコンポーネント、Transformer beanを目指しています。Transformerは渡されたものを受け取りなんとか(この後もう少し説明します)変換した後で後続の処理に送信します。この例ではTransformerはMimeMessage型の内容を含むMessageクラスを受け取ります。ここでMimeMessageはBlogPost型のオブジェクトを生成するのに使います。BlogPostはこのシステム固有のドメイン・クラスです。ここではDTOとして使いますが、どこから来たものであるかは関係ないということをはっきりさせておく必要があります。必要であれば任意のドメインで使うことが出来ます。transformer要素の最適な使い方は、メッセージの形式をあなたのシステムに適した形式に変換するという使い方になります。これは(上述の)カノニカル・データ・パターンを適用したものです。

結果であるBlogPostは元々のメッセージからヘッダを引き継いだ新たなメッセージにラップされます。ヘッダは期待通りのものです。リクエストに固有の値を保持し、メタ・データを追加して送信することが出来ます。例えば、内部的にはSpring Integration Busが全てのメッセージにIDを割り当てています。このIDはヘッダの値として公開されていて使うことが出来ます。IDはユニークになることが保証されています。

この後メッセージはFilterであるemailsFilterAgainstWhitelistに送信されます。このFilterはsenderプロパティに設定された値に対して応答を返します。これはあなたが自分のブログまでの経路にスパムを送りつけないことを保証するための仕組みです。この例は、ソリューション全体と同様にものすごく単純な例です。Spring SecurityやLDAPに問い合わせたりするようなもっと優れた方法が考えられると思います。図5を見て下さい。

image5

XML設定ファイルの最後の部分はservice-activator要素で、渡されるものとそれを処理するものを設定します。このケースでは、newBlogPublishingServiceActivatorというIDで定義されたBeanのpublishIncomingBlogEntryメソッドを呼び出すようにSpring Integrationに教えいています。このメソッドは実際のメッセージの中身を受け取り、ブログのエントリとして公開するサービスへそれを送信します。

これで終わりです。たくさんあったように思えるかもしれませんが、実質XMLの中の4節に過ぎません。チャンネルの定義は例を分りやすくするためのものです。poller要素はたった一度定義すれば同じコンテキスト上の全てのものがデフォルトのポーラーを使うことが出来ます。

考えられる拡張

私たちは3つのチャンネルと4つのコンポーネントを定義しました。このソリューションを構成するコンポーネントを設計する際、それらが他の統合ソリューションで再利用できるようにしました。この統合で示したフローは今回の例に限定されるものではありません。上記のTransformer、Filter、そしてService Activatorさえもより複雑な統合で再利用出来るかも知れないのです。リファクタリングが必要なのはSpring IntegrationのXMLファイルだけでしょう。多くの可能性があります。これこそが良く出来たESBの仕組みなのです。フローの設計と設定を可能な限り遅らせるということです。

この先どのようなソリューションをとればいいのかは簡単に想像出来ます。この後にはいくつかの機能追加が考えられます。

  1. jBPM([12])を使ってこのシステムに監査のワークフローのようなものを追加してみましょう。仮にこのソリューションにビジネス・プロセス・マネジメント(BPM)の機能を追加したくなったとします。例えばメッセージを受信したら編集者が承認するまでそのメッセージをキューに溜めておくようなものです。編集のプロセスは必要であればワークフロー・エンジンの内部で処理することも出来ます。そして最後のブログのコンテンツが承認されると編集者は最終的なエントリに、相関関係を示すIDとして使うためのある種のキーワードや確認のための情報を付加して、同じアドレス宛に送信することも出来ます。このIDは統合ソリューションを完結するのに使われます。エントリの更新に役立つでしょう。[13]を参照して下さい。
  2. ブログを“マルチ・キャスト”するためにSpring Integrationを使ってみましょう。勿論、既にブログは公開されています。ただしここにはまだ別の問題が潜んでいます。それは昔からあるこの哲学的な問答で表現されます。「RSSフィードが更新されたとして、それを誰も購読していないとしたら、果たして本当に更新されていると判断できるのだろうか?」。言い換えてしまっているかも知れません。ブログのタイトルはTwitterを通して紹介出来るかも知れませんし、Recipient List(受信者リスト)パターン[16]を使ってブログ集約サイト([14], [15]など)に通知を送るようなことが出来るかも知れません。
  3. Filterの例を修正して実際の認証サービスを使えるように認証機能を追加してみましょう。LDAPやSpring Securityを使うかもしれません。
  4. ブログのエントリを公開する方法をeメール以外にも追加する。FTP、WebDav、ファイル・システム(設定ファイル内のeメール用のアダプタについて記述した行の下にファイル・ディレクトリ用のアダプタに関する設定をコメント・アウトしておきました。)、などが入力として考えられます。さらに発展させてモバイル・クライアントからのSMS(ショート・メッセージ・サービス)による入力も考えられます。(勿論、私はいったい何人の人が携帯電話からブログに書き込んでいるのか知りませんし、あなたも知らないでしょう。やってみなければ分からないでしょう)。この機能はまだサポートされていませんが、Spring Integrationのソース・コードを凝視してみれば独自のアダプタは簡単に開発できることが分かります。SMSLib[17]のようなものを使うといいかも知れません。

Spring Integrationに欠けている部分

Spring Integrationは新しく、強力です。Spring Integrationの背後にはSpringSourceがあることが分かるでしょう。そしてどんどん進化して行くことでしょう。しかし、だからといって完璧だと言うことではありません。完璧とは程遠い状況です。アプリケーション統合の分野は決して新しいものではなく、何十年にも渡って考案されたソリューションやアーキテクチャがあります。いくつかのアプリケーション統合では従来からSAPやJDEdwards OneWorldなどと統合するための重厚長大なアダプタを提供しています。Spring Integrationはこれら特殊なケースについては直接対応していません。

Spring Integrationは元々とても多くのアダプタをサポートしていますが、一部でSFTP、HTTPSやAS2といった典型的なアダプタに対応していません。今までのところ、一部のプロプライエタリ製品の方がこのような要求によく対応しています。それらの中には高価なものもありますので、もしかしたらSpring Integrationからサード・パーティ製のライブラリを使うために独自のアダプタを作ろうと思うことがあるかも知れません。関心を持って調べると、Spring Integration用のアダプタを作成するのがあまりに簡単であることにいい意味で驚くでしょう。あなたの求めるソリューションの発想の源泉として、まずはjSch [18]、Jakarta Commons VFS [19]、Jakarta Commons Net [20]などを確認してみましょう。

最後に、Spring Integrationは(今のところ)あなたにとって最適のソリューションではないかも知れません。最適でないのなら気に病むことはありません。この記事で学んだ考え方は他のソリューションにも適応できます。さぁ、恐れずに統合しましょう。

結論

Spring IntegrationはEAIに対するキレイで、簡潔なアプローチを体現していてESBの強力な選択肢となります。近年のESBソリューションは重たく、一部の環境に導入するのが難しくなっています。Spring Integrationは強力で、他とのあつれきの少ない選択肢となっているので統合の際の問題の多くを解決するでしょう。

参考資料

1 "Enterprise Integration Patterns" (リンク)に関するAmazon.comのページ
2 pring Source社のSpring Integration、http://www.springsource.org/spring-integration (リンク)
3 Enterprise Application Integrationのサイトにある"Cannonical Data Model"、http://www.eaipatterns.com/CanonicalDataModel.html (リンク)
4 JCAの仕様、http://java.sun.com/j2ee/connector/ (リンク)
5 BEA Tuxedo、http://www.oracle.com/products/middleware/tuxedo/tuxedo.html (リンク)
6 Muleのホームページ, http://mule.mulesource.org/display/MULE/Home (リンク)
7 Mule用の拡張機能を開発しているMule Forge、http://www.muleforge.org (リンク)
8 Apache ServiceMix, http://servicemix.apache.org/home.html (リンク)
9 JSR 208, Java Business Integration, http://jcp.org/aboutJava/communityprocess/final/jsr208/index.html (リンク)
10 Google社のブログ・サービス、Blogger、https://www.blogger.com/start (リンク)
11 Apache Roller, http://roller.apache.org/ (リンク)
12 JBoss.orgにあるjBPMの情報, http://www.jboss.org/jbossjbpm/ (リンク)
13 Enterprise Application Integrationのサイトにある"Aggregator",http://www.eaipatterns.com/Aggregator.html (リンク)
14 ブログ集約サイトのDzone,http://www.dzone.com (リンク)
15 ブログ集約サイトJavaBlogs, http://www.javablogs.com (リンク)
16 Enterprise Application Integrationのサイトにある"Recipient List", http://www.integrationpatterns.com/RecipientList.html (リンク)
17 JavaのSMS用ライブラリ、 http://smslib.org (リンク)
18 jSch, http://www.jcraft.com/jsch/ (リンク)
19 Apache Commons VFS, http://commons.apache.org/vfs/ (リンク)
20 Jakarta Commons Net, http://commons.apache.org/net/ (リンク)
21 私のブログ, http://www.joshlong.com (リンク)

 

著者について

Josh Long氏はアリゾナ州フェニックス出身のエンタープライズ・アーキテクト、スピーカー、そして誠実な夫です。コードをハッキングしているとき以外は、地元のJavaユーザ・グループかコーヒー・ショップにいます。http://www.joshlong.com (リンク)([21])でブログを公開しており、josh@joshlong.com(メール)からコンタクトをとることが出来ます。and can be reached at . 

ソース・コードはこちらから(ZIP)ダウンロード出来ます。 

この記事に星をつける

おすすめ度
スタイル

BT