第85回 JavaEE 読書会に参加してきました

javaee


第85回 JavaEE 読書会に参加してきました。
Enterprise Integration Patternsという本の読書会です。

進め方

  • 全体をざっくり
  • 詳細を議論
    • 詳細議論までいけると better

トピック

JBoss ESB (SwitchYard)のデモ

解説
  • JBoss は高速化しています！
    • 並列化が効いてます
  • quickstart にいろいろはいってます
    • camel-jms-binding をデモします
    • シンプルなパイプ・フィルターパターンの例です
  • switchyard.xml
    • ESB の設定を書くところ
    • EIP でいうルーティングなどは Apache Camel に移譲してます
  • Queue からコンポーネントに渡す、という定義になっている
    • コンポーネントを実装している Bean の method binding はどうやっている?
      • Bean にメソッドが1つしか無ければそれが適用されるが、2つ以上あるなら設定が必要
      • 型安全とか考えないのが ESB なので ClassCastException が出たり
      • 静的チェックが出来ないので runtime でのテストが重要
  • デプロイ
    • build すると META-INF/switchyard.xml に置いた jar ができる
    • deploy ディレクトリに置けばロードされる
    • switchyard の管理 UI から確認できる
図解するとこんな感じ(ホワイトボードに描いてもらったらこうなりました)


質疑とか
    • AP サーバから Web Service へのリクエストをキューイングするとかに使えるのかなと
    • メッセージのバリデーションとかはクライアントはやらないものですか?
      • クライアント側でもやればいいですし
      • switchyard は宣言的なバリデーションをするとかの仕組みがある
      • ESB 的には検証サービスをルーティングするとかも
    • キューイングサービス自体には検証する責務を置くべきじゃないのかなとか
      • JMS の考え方としてはとりあえず放り込んじゃえ、というものですが、途中に Web サービス挟んだりすることは可能ですね
      • EIP には「DB はデータを置いておく仕組み、キューやチャンネルはコミュニケーションをするための仕組み」とあるので
    • 個人的にはキューの冗長性を確保する仕組みに興味があります
      • 製品によって考え方とか癖とかがあるので面白い
      • 1台構成で超高性能みたいなのよく見るけど耐障害性とかスケールアウトするような仕組みってあまり聞かないですね
    • MOM と ESB どっちがいいのか?

休憩

二章から

Introduction
    • 星取表になってる、わけじゃないけど、できそう
      • X がつかなければいいんじゃないか、みたいな
    • Application Integration Option を選択するふわっとした観点
File Transfer
  • File Transfer はトランザクションが安定してるのがメリット
  • ロックとか削除とか作りこみを自前でやらないといけないのがデメリット
  • MOM を使えば置き換え可能なもの?
    • 必ずしもそうとは言えない。でっかいファイルを渡すとか
  • 大きな問題:開発者が大変
    • なぜ?:別々のシステムから提供されるデータに矛盾があったときどうするかを決めたりしないといけない
  • HULFT を知らないので SIer 失格であるとか何とか
    • 安心感、取っつきやすさ
  • ここでいうファイルって何？リレーションを含めた完全なデータとかそういうもの？
Shared Database
  • index 問題
    • パフォーマンス的に矛盾してしまうということがある
  • スケールしない問題
  • 統合データベースが適してるユースケースはあるのか?
    • RPC で同じデータベースを参照するような統合、というのはあった
  • MDM(Master Data Management) という考え方
    • 6つくらいの戦略的なパターン
    • 優劣ではなく条件に合ったパターンを
  • マスターデータを持たせる、という話になると困ってしまうのだけど、更新データだけを持たせるなどの考え方は無いのかしら
    • 登録、更新といったイベントのインターフェースを設けるというのはありますね
    • それ、MOM で出来るよ
    • アプリケーションに組まれる仕組みとか
  • メッセージングの枠組みでトランザクション情報をまとめて、というような使い方ってあるんですかね
Remote Procedure Invocation
  • 使います？
    • Web サービスも RPC と考えることができますよね。であれば使います。
    • RESTFull じゃなくて REST風
  • 呼び出し元で発生したタイムアウトをサーバ側がキャンセルできるんでしたっけ？
    • クライアントが完了できなかったトランザクションをサーバ側でコミットしてしまう問題
    • 普通はトランザクションを開始するとかの情報を RMI に渡すよね
    • Web サービスにも Ws-Transaction とかありますし
      • なにそれ派、懐かしい派、CORBA でいいじゃん派
      • 某巨大システムで使われていたとかの情報
    • 注文系の Web サービスは取り消しできないのつらい…
Messaging
  • メッセージングの特性に合わせた改修がどんなシステムにも適用できるかというとそうでもなさそう
    • ルーティング
    • 非同期
  • ヘテロジニアスなシステムにおいてメッセージングを導入すること自体が問題になる
  • Web サービスはみなさんよくお使いですよね?
    • Ws-XXX とか面倒くさいのに
  • メッセージングを全面的に採用システムってあるんですかね?
    • 某社の某システムでは独自実装だったり
  • 学習コストとかよりはプロダクト自体が高価だったとかの問題の方が比重が高かったかと
  • アーキテクチャがイメージできない問題
    • 後半読めばヒントが掴めるのかも…
    • 慣れの問題?
  • File Transfer、Shared Database、Remote Procedure Invocation あたりなら「まぁ、やりましょう」で済みそう
    • メッセージングはちゃんとした設計が必要になりそうで敷居が高い感
Chapter2 まとめ