クライアント型SOAの設計方法と開発方法
柔軟性とメンテナンス性の確保
アグリゲーションサービスを利用する個人投資家の方々は、資金の管理方法も多様化しています。また投資家の方々が所有している銀行、証券会社、クレジット会社の口座の組み合わせパターンも相当な数になることから、表7のシステム開発手法を採用しました。
- クライアント・システムの内部を部品化(コンポーネント化)
- エンドユーザ・コンピューティング・システムを採用
上記のシステム開発手法を採用したことにより、利用者は自分自身が必要としている機能を技術者の手を介することなく、自在に機能の取捨選択ができるようになります。さらに、メンテナンスや機能拡張の観点からも、同社は個別のコンポーネントの開発と更新のみで対応が可能になるため、メンテナンス性を飛躍的に向上させることができるようになりました。
クライアント・システムの内部を下記の通り部品化(コンポーネント化)
本システムにおけるコンポーネント・カテゴリは表8の通りです。このカテゴリ化により、接続先である金融サービス他社のWebサービスがシステム変更した場合や、新しいアグリゲーション機能を追加した場合でも、コンポーネント単位での開発・更新で対応ができるため、メンテナンス性・拡張性を高めることができました。
- 銀行接続コンポーネント
- 証券会社接続コンポーネント
- クレジット会社接続コンポーネント
- 口座処理コンポーネント
- ユーザインターフェイス・コンポーネント
- アグリゲーションシステム基本コンポーネント
エンドユーザ・コンピューティングシステムについて
同システムでは利用者が利用したいソフトウェアの形にアグリゲーションソフトウェアを自在に変更できるように、エンドユーザ・コンピューティング・テクノロジーの1種であるRimless Computing(「IdbAで構築する生産性が高いリッチクライアント」を参照)を実装したIdbAを採用しています。
オリエントアグリゲーションサービスの実際の画面は図7の通りです。画面中央の「取引先一覧」の部分に利用者が必要な口座コンポーネントをドラッグアンドドロップするだけで、各口座へのアクセスが可能になるよう設計しております。また、「オプションメニュー」の部分に利用者が必要とする「口座合算処理」などの資産管理機能コンポーネントをドラッグアンドドロップするだけで、アグリゲーション機能の追加ができるように設計しております。
同社金融ビジネスディビジョンは以下のように、クライアント型SOAおよびIdbA Aggregation Client-typeに対する投資効果の高さを評価しています。
「利用者が増加にあわせてサーバシステムの増設を余儀なくされるサーバ型のアグリゲーションシステムでは、投資の回収期間が長期になり、当社のビジネススタイルには不向き。クライアント型SOAをベースにしたIdbA Aggregation Client-typeであれば、短期間・低コストでのシステム構築ができるだけではなく、利用者が増加してもサーバ側に負担がかかりにくいため、システム投資額を大幅に抑えることができる。また追加開発要件に関してもIdbA上のコンポーネントを追加するだけで対応できるため、顧客ニーズに柔軟なシステムも容易に構築・運営できるため非常に評価している。」
次回について
今回はクライアント型SOAの実践編として、設計・開発時のポイントと実例を紹介いたしましたが、いかがでしたでしょうか?限られたスペースでの解説ということもあり、場合によっては、説明が足りない部分もあったかもしれません。今回の文章をお読みになり、ご不明な点や説明が必要な部分がございましたら、是非コメント欄にご記入下さい。
皆様のご意見を次回に反映させ、より多くの方々にクライアント型SOAの秀逸さを理解いただくべく尽力いたします。今回はBtoCの事例を紹介いたしましたが、次回はBtoBおよび社内システム連携に焦点を当てたケーススタディーを中心にお届けする予定です。是非ご期待下さい。