Seam vs Spring

Seam Spring Framework アーキテクトの仕事

私自身仕事でSeamを使って開発をした経験はないのですが、今回技術調査をして簡単なアプリケーションを作ってみた感想としては、「考え方に慣れるとかなり便利であり、適合する案件ならば是非積極的に使ってみたい」というよい印象を持ちました。Seamは一般的に以下のようなプロジェクトに適合すると思っています。

  • JSF、EJB3、JPAなどJavaEE 5仕様の積極利用が会社標準として推奨されている場合
  • 既存のC/S系のデータエントリーシステムをWeb化するような場合
  • 社内システムでユーザー数に対するスケーラビリティがあまり重要でない場合
  • 業務要件的にjBPMやDroolsなどJBossの業務フローやルールエンジンと組み合わせるのが有効な場合
  • データを1件〜数件単位で更新するような場合（ORMが適する場合）

ただし、Seamの弱点としては以下のような点が気になります。

  • JavaEE仕様に依存しているためバージョンアップの影響が大きい。（JavaEE 6を視野に入れると将来性に問題がある。）
  • 日本語化対応などを含めて開発ツールの品質があまりよくない
  • バッチ処理中心のシステムには向かない
  • レガシーDBスキーマやストアドプロシージャ中心の業務ロジックが存在する場合はそもそもJPAが適合しない
  • ステートフルアーキテクチャーゆえスケールアップや耐障害性向上が難しい傾向があると思う
  • ステートレスなサービスを組み合わせる大規模な分散アプリケーションの設計には向かない（EJBやSpringとの組み合わせで不可能ではない）
  • アクションベースのMVCフレームワークが適するような対外Webサイトの構築には向かない

守備範囲としてはiBatisやSpring MVCなどより広範なフレームワークの組み合わせが可能なSpringの方に分があり、またプラットフォームに対する可搬性の高さからも一般的にはSpringの方が無難な気がします。ただし、Seamが適合するケースではコード量の大幅削減など生産性を大きく向上させられる可能性があると思います。