釣りキチプログラマー翔平の備忘録 
はじめに
「実践！インテグレーションパターン」という勉強会に参加したので、
勉強会での内容を気になったポイントに絞ってまとめ、僕の感想や気付きなども書いてみました。
2022/3/22追記
今まで僕が参加した回の
現場から学ぶモデル駆動設計の勉強会での学びや気付きなどについて
まとめ記事を作ってみました。
「実践！インテグレーションパターン」(勉強会)で印象に残ったところや気づきなど
EIPはシステム間でメッセージを非同期に送信するための
パターンランゲージ(送る側から受け取る側までの一連のパターン)。
メリットの１つとして時間的な制約が排除できる点がある。
自分はシステム間連携の方式として、API連携、ファイル連携は経験がありましたが、
メッセージでしかも非同期で連携は聞いたことがありましたが体験したことがありませんでした。
送り先が落ちてても後で立ち上げた時に非同期で受け取れる仕組みがあれば、
時間的な制約が排除できてシステム間の依存関係が緩く柔軟になるということでした。
その仕組みを諸々考慮して作るまでが大変なのでしょうが、、
確かにサブシステムと連携してて非同期でもいいような連携をこの仕組みでやれると、
サブシステムに引きずられてメインシステムが動かないとかもなくなるのでいいなぁと思いました。
マイクロサービスとの親和性もあり、さらに最近ではクラウドでマネージドで簡単に
非同期メッセージがやり取りできるようになってきているので今後は今まで以上の勢いでの
導入が予想されるそうです。(今のうちに話を聞けて良かった、、、)
話を聞くまでは難しすぎてほぼ理解できないかも、、、と思っていましたが
分かりやすく説明頂いたこともあり、勉強会の中でEIPのパターンを色々教えていただきましたが、
そこまで複雑なものはなく、すっと頭に入る内容でした。(EIP初心者でしたがざっくりイメージは掴めました)
また、見せて頂いたApatch CamelのソースはJavaでORマッパーでクエリを書く感じで書けそうだったので、
簡単なものは自分でも直ぐかけそうだなという印象です。
(多分、求められる要件次第でめちゃくちゃ複雑にはなるのでしょうが、、、)
インターネットを通ったメッセージは届かないことがあるということを受け入れる。
その上で、それを検知してて運用でリカバリか、
お金をかけてプログラムで再送する仕組みを作るかは要件次第。
この話は、非同期メッセージに限った話ではなく、僕もいつも顧客や営業たちと議論になる話だなと
思って聞いていました。
年に１回あるかないかの例外的なパターンに対して数百万円かけてわざわざシステム化するんですか？？
検知だけして手運用でリカバリで良くないですか。。。。？みたいな、、
また、インターネットを通ったメッセージは届かないことがあるということを、２人の将軍の例を上げて
分かりやすく解説頂きました。
送る側は送れたかどうか応答が来なければ認識できない。
一方受取り側は応答を返すが、それが届いたどうか
応答の応答が来なければ認識できない。(応答の応答までやると無限に繰り返される)
そんな状況で送信保証をするためには、送る側と受取り側にそれぞれdiskを用意して
送った事実と受け取った事実をそれぞれ記録して、本当に送れたらその記録を消すという仕組みが必要になる。
という説明をして頂きました。
Scalaのコードも見せていただきましたが、、、途中からふわっとしか付いていけず。。。
EIPの考え方は設計に応用できる。
いろんな属性を持った大きなデータを細かく分けて個別に処理してインテグレートしたり・・・
この話は、こういう考えを持ちながらいろんな分野の勉強をすべきだと考えさせられました。
今回の話をEIPの話として捉えるのではなく、EIPの考え方を自分の中で消化して、
他のところでその考え方を活していく。他で応用できないか？？を常に考えながら勉強する。
このような意識を持つことの大切さを学ばせていただきました。
特に僕が印象に残ったのはこの辺りでした。
EIPに興味を持つ良いきっかけになったので、早速週末遊んでみよう・・・
