変化対象に応じたオートコンポーネントの粒度

オートコンポーネント化に際して、サービスと機能の範囲が限定されることはありませんが、オートコンポーネントの粒度には注意する必要があります。粒度が細かくなると設計・実装の難度があがり、粒度が大きいと保守性が落ちます。

そのためオートコンポーネントの粒度は、変化が予測される部分に応じて設計する必要があります。今回の事例では、ECモールの機能をまとめて1つのオートコンポーネントとしていますが、それぞれの場合に対応して内部の通信部分のみをオートコンポーネントとすれば、その単位での保守・配信も可能になります。

図3：サービスの粒度

クライアント型SOA構築時のデータ設計

複数の担当者でデータを共有して利用するということから、データベースを導入するために社内にサーバを設置し、開発の初期段階でデータ分析を行いました。

ここで問題となったのはクライアント型SOAとして実装した場合、IdbAの拡張性をどのように活かすかということです。XMLデータベースやオブジェクト指向型データベースなどの技術も検討しましたが、パフォーマンスと開発メンバーの実績からRDBを採用しました。RDBは「まずデータありき」の世界であり、IdbAの自動配信機能で新たなサービスを導入した場合、新たなテーブルやフィールドを自動で作成することはできません。

そのため拡張が予想されるシステムには、柔軟に利用できるテーブル設計を考える必要がありました。場合によっては、当面不用と思われる領域を用意して将来の拡張に備えるといったことや、テーブルに曖昧なフィールドを定義（利用上での）しておくといった対応をとりました。

図4：クライアント型SOA構築時のデータ設計

ユーザインターフェースのバランス

ユーザインターフェースはお客さまからの要望もしくはこちらからの提案により作成しました。オートコンポーネントがユーザインターフェースを保持している場合もあり、統合して出力した際の全体のバランスを調整する必要がありました。
実装はSwingベースで作り込みができるという利点がありますが、時間がかかってしまう場合もありました。IdbA次期バージョンでは拡張したSwingコンポーネントの提供、VisualEditorなどの連携により生産性を向上させていく予定です。