LoginSignup
4
0

More than 5 years have passed since last update.

Camel in Action 2 読書会(第12回)参加メモ

Last updated at Posted at 2018-08-23

Japan Camel User Group が主催している書籍『Camel in Action, 2nd Edition』の読書会参加メモです。
Camel in Action, 2nd Edition

ちなみに、次回(第13回)は9/19(水)開催予定です。

次回だけは Sponsored by Red Hat な特別な回で(といっても毎回 Red Hat がケータリングを出してくれているのですが)、海外から Red Hat エヴァンジェリストの Christina Lin が来て Camel on Cloud について話をしてくれるはず(?)です。

概要

この読書会は去年の9月から始めていて、1年ちかく経ち Part 1〜2 まで読み終わったので、今回は今までの振り返りをしました。読書会は1年ちかく経過していますが、今回も口コミで新しい参加者の方が来られていたのがいいですね。本書は、各章のトピックが毎回違うので、Camel の最低限さえ押さえていれば、途中参加でも大丈夫だと思います。

本書は、第1章に Apache Camel のアーキテクチャ的な概要が書かれていて、実は色々と重要なことが書かれている章なのですが、初見だとインテグレーションフレームワークという特殊性もあり中々頭に入ってきません。なので、実際に Part 2 最後の6章ぐらいまで読み進んで、ある程度 Camel について具体的なイメージが出来てから、再度1章をおさらいする、という読み方がいいと思います。

なお Apache Camel の概要については、@tyamashi_oss さんが書いたこの記事がよくまとまっています。

Camel Exchange

個人的には、Camel を理解する要点はこの Camel Exchange を理解することだと思っています。

Figure 1.7
(書籍より Figure 1.7 抜粋)

Camel においてシステム間の1つの連携を表す「ルート」はこの Exchange と紐付いていて、ルートに1つメッセージが届いて連携が開始すると、この Exchange のインスタンスが1つ作られて、そのルートが終了するまでその同じインスタンスが使われます。もちろん、ルートの中で .to(...) などで別のエンドポイントにメッセージが送られる場合、その送られた先の別ルートではまた新たな Exchange インスタンスが生成されます。

なので、Camel におけるメッセージルーティングの1インスタンスとこの Exchange インスタンスが 1:1 に対応しています。Exchange は(必然的に)少し複雑なモデルになっているので、まずはここを押さえるのが Camel 理解の一歩になると思います。上級編として、Camel のソースコードを読む際もこの Exchange のドメインモデルがそのままソースコードに落とし込まれているので、その理解の上に camel-core のソースコードを読むといいと思います。

Camel コンポーネント

あと、第1章のこの図も改めて見て分かりやすいなと思いました。

c01_13.png
(書籍より Figure 1.13 抜粋)

Camel の大きな魅力は200種類以上の連携コンポーネントがビルトインで用意されていて、世の中の多くのシステムとすでに連携できるようになっていることですが、それでも社内独自のシステムなど、対応していない連携先システムもあります。そういうときにも、Camel はカスタムのコンポーネントを比較的簡単に開発できるようになっています。

カスタムコンポーネントを開発しようとするときに、ある程度 Camel の既存のコンポーネントのソースコードとにらめっこする必要が出てきますが、そのときにこの図が頭にあると理解が非常に早いです。基本的に、Camel コンポーネントはこの Component、Endpoint、Consumer、Producer の4つのクラスで構成されます。そしてそれぞれの関係性が、この図を見れば一目瞭然です。

ちなみに、Camel のカスタムコンポーネントの開発方法は、英語ですがこのブログ記事を読むと分かりやすいです(誰か翻訳しないかな)。

その他

Camel はコントリビュートしやすい

Camel は Apache 参加のプロジェクトの中でもトップクラスのコミット・コントリビュート数で、非常にコミュニティが活発です。つまり、閉鎖的な敷居の高いプロジェクトと違い、Pull req を送ったらマージして貰える可能性が非常に高いです。正しい修正であれば、まずその日のうちにコミッタから何らかの反応をもらえて、早ければ即座に、遅くても数日でマージして貰えます。コントリビュータになれる可能性が非常に高いプロジェクトですので、ぜひ積極的に GitHub から Pull req を送ってみてください。

内部 DSL vs 外部 DSL

細かい点ですが、今回担当者の @tyamashi_oss さんは Camel の Java DSL を「内部 DSL」、XML DSL を「外部 DSL」と言っていましたが、それはちょっと違うと思います。自分の理解では、Camel の DSL はどちらも内部 DSL です。いわゆる外部 DSL というのは、完全に独自の記法で文法が定義され、処理系が実装された DSL のことで、例えば最近でいえば Dockerfile のようなものでしょうか。XML DSL は XML の上に擬似的に言語処理系を構築しているので、やはり内部 DSL です。

Fuse Online

忘れていた。勉強会冒頭で @hfuruichi さんから Red Hat の新サービス Fuse Online の紹介がありました。この読書会は基本的にコミュニティの活動なので、あんまり企業色を出したくないんですが、この Fuse Online は内部で Camel を使っているサービスで、最近少し注目されている(?)iPaaS の一事例の紹介ということで、ぎりぎりセーフかなと。

(興味のある方は、無料で30日トライアルアカウントが作成できます。)

iPaaS というのは、Camel のようなインテグレーションのプラットフォームをクラウド上ですぐに使えるようにしたサービスです。Fuse Online とか、この製品カテゴリが面白いのは、対象ユーザが開発者でなく営業・事務職など一般の人である点です。海外では、シチズン・インテグレータ(Citizen Integrator)などと呼ばれています。

イメージとしては、Excel のマクロが専門のプログラマでなくてもある程度頑張れば書けるように(あと海外ではプログラマでないデータアナリストが SQL をガシガシ書けるといいますね)、業務で使えるシステム間連携の簡単なソリューションを一般の人がプログラマに頼らず GUI で作れるようにしよう、というものです。実際、日本でどれだけニーズがあるのかはまだ分かりません。

一応、同カテゴリの他社サービスを挙げておくと以下のものがあります。

最後に

読書会自体は、第2章の途中あたりまで振り返ったところで今回は終わりました。振り返りとしては、この辺りまででいいと思います。

次回からは、第7章の「Camel と Microservices」の話にようやく入っていくので楽しみです。本書 2nd Edition の目玉が、最新の Camel で強化された、このマイクロサービスまわりのサポートやクラウドの話になっています。

4
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
0