My Family, My Treasure, My Life

My Family,
My Treasure,
My Life

My Family

Best Shot Album

Since '02.08.03

Column Index

新しいSOAの実装方法「クライアント型SOA」のすすめ
2005/8/29-2006/5/31

クライアント型SOAの設計方法と開発方法

はじめに

   前回ではクライアント型SOAの概念について説明しました。読者の方々から多くのご評価とコメントをいただき、大変ありがたく感じています。またその反響の大きさから、「クライアント型SOA」への期待を改めて認識すると共に、この新しい手法を効果的なソリューションとして様々な方に使っていただきたく、今後もクライアント型SOAの啓蒙活動に尽力いたします。

   今回は実践編として、「クライアント型SOAの設計方法と開発方法」の事例を中心に話を進めていきます。すでに通常のSOAの知識・経験がある方はSOAと「クライアント型SOA」を比較しながら本連載を読み進めて下さい。

   またSOAに関して深い知識がない方でも、「クライアント型SOA」はサーバとクライアントというシステムを業務に当て込んでいくシステムの形ですので、自身の基幹システムの設計・構築シーンと比較しながら読み進めていただければ、「クライアント型SOA」の特徴と適用ケースがわかるかと思います。

クライアント型SOAを実現する「IdbA」

まずは、クライアント型SOAを実現する「IdbA」について簡単に触れてみます。IdbAはクライアント側とサーバ側のアプリケーションを厳密かつ容易にコンポーネント化（カプセレーション）ができます。これによって、C/Sシステムの表現力・操作性とWeb系システムの運用の容易性、そしてRimless Computingならではの情報と機能を融合した柔軟性のあるシステムを構築することができます（図1）。

図1：IdbA概念図

IdbAの特長は表1の通りです。

Javaクラスで実装されたオートコンポーネントの実行環境
オートコンポーネントはIdbA上で相互に接続・情報連携が可能
オートコンポーネントを送受信することによって情報・機能を送受信することが可能

表1：IdbAの特徴

また、IdbAはクライアント型SOAの実装を効率化すべく、表2の機能強化をはかっています。

SOAPクライアント: 接続先のサーバとSOAPでやり取りできるように、SOAPの作成と読み取りができるようになります
簡易版BPML: ビジネスプロセスのモデル化を極力簡易に行うべく、テンプレートでの作成が可能／コンポーネントの簡易作成機能／コンポーネントのつながりの視覚化を実現する簡易版BPMLの機能が使えるようになります
DataMappingツール: 異なったシステム間でのデータの整合性を保つべく、データ変換を行います

表2：IdbAの今後の実装機能

「クライアント型SOA」の適用シーン

   前回で説明した通り、「クライアント型SOA」の特長はまさにクイック・アンド・スモールスタートと柔軟性です。最近の市場を見渡せばスモールスタートという言葉はよく聞きます。しかしながら、皆様の身近にあるシステムで考えた場合、スモールスタートとはどれくらいの期間・規模をさしているのでしょうか？

   システムインテグレーターの方々から提案を受けると、おそらく現状のSOAでは、関連する基幹システムを連携させた全体システム像から個別の構築段階を切りだし、「まずはこの部分を作りましょう。そして次はこの部分を…」といった形で、システムの最終全体像に向かって、段階的な構築を提案している（受けている）ケースが多いのではないでしょうか？

   本来、利用者が求めている「スモールスタート」とは、コスト的にも時間的にも小さな投資でシステムを構築したうえで、今後の柔軟性をも実現するシステム構築スタイルを期待して「スモールスタート」という言葉を使っているはずです。ITを取り巻く市場展開は非常に速く、それに起因して、システム投資から効果測定期間は非常に短くなってきています。

図2：スモールスタートの本当の意味は？

   従来のSOAではサービスを機軸にシステムを設計しましたが、サーバ型のシステム連携によるソリューションしかなかったため、各サーバを管轄している部門をまたがったシステム構築になり、必然的にトップダウン型のシステム構築にならざるをえなかったのです。その結果として時間とコストをかけることになり、クイックスタートができないケースに陥っていました。

   このシステム構築手法のデメリットである「非柔軟性」と「時間とコストの逼迫」を改善したアーキテクチャ（開発手法といってもいいです）が「クライアント型SOA」です。つまり「クライアント型SOA」の適用シーンとは、単一部門内の現場レベルで、システム要件を短期間でまとめる必要があるようなシステム構築シーンが最適であるといえます。

   「クライアント型SOA」であれば他部門はもちろん自部門のサーバに手を加えることなく、純粋に自部門管轄のクライアントのみのシステム構築だけで対応できるため、部門間調整をする必要がなく、必然的にスモール・アンド・クイックスタートが実現できるのです。

図3：クライアント型SOAの強さとは

IdbAを使用した「クライアント型SOA」であればIdbAのカプセリング技術により、システムがブロック化しているため、そのブロックの組み合わせにより、部門間連携による全社連携システムの構築も低コストでの実現が可能となります。

図4：部門システムから全社システムへ

この形こそが、スモール・アンド・クイックスタートを実現し、さらにシステム拡張をも柔軟に実現する理想的なシステム構築スタイルであると考えています。

クライアント型SOAの設計・開発時のポイント

それでは次に、クライアント型SOAの設計と開発時のポイントを説明します。ここでは設計手法と開発手法が理解しやすいように、経営支援システムの例をもちいます。このシステムの想定条件は表3の通りです。

スピード経営実現のための「システム処理作業のスピードアップ」と「リアルタイムな経営判断材料の抽出」をシステム構築の目的とする
連携対象システムは会計システムとSFA（営業支援システム）

表3：経営支援システムの例

クライアント型SOA設計のポイント

   まず、システム設計の手順を説明します。ポイントはいかにサービス・オリエンテッドなシステムを設計するかであり、そのためにシステム設計の権限を利用者に委譲して進めているところがポイントになります。

   クライアント型SOAとはサービス・オリエンテッドなアーキテクチャであるため、システム設計時はシステム的なことを意識せずに、純粋にビジネス的なフローを作ることに心がけます。つまり、現場で利用者が既存のシステム上だけではなく、システム以外でどのような作業をやっているかをも含めたすべての作業を記述し、単純作業をシステム化するようなイメージでシステムを設計します。

   また、システム設計は最終フローではじめて出てきます。

1. システム利用者カテゴリの設定: このシステムに携わる利用者のカテゴリを下記の通りに設定します
2. システム利用者カテゴリに属する実作業者のリーダーを選出する: このリーダーは組織の統率者としてのリーダーよりも、実際に一番システムに触れている人を選出するほうが効果的です
3.処理内容の確認: 2のリーダーを中心にシステム利用者カテゴリごとに、クライアント側では何の処理をするか内容を確認します
4. サーバーとのI/F策定および処理内容などのクライアント・システム要件の確認: 下記のように、既存サーバーとのI/Fの確認と処理内容の確認を行います
5. システム設計を行う: クライアントの内部システム設計（柔軟性を保つためのコンポーネント設計）を行います

表4：システム設計のフロー

クライアント型SOAはシステム開発の範疇をクライアント側だけに限定することにより、システム設計に携わる人数を最小限にし、意思決定およびプロジェクトを迅速化します。

また、当然ですが、クライアント側だけの開発になるため、システム構築コストと時間は圧倒的に少なくなります。これにより、スモール・アンド・クイックスタートを実現できると考えています。

クライアント型SOA開発のポイント

クライアント型SOAの開発ポイントは1も2もなく、システムの部品化です。スモール・アンド・クイックスタートを実現したシステムは柔軟性を加味することにより、その価値は飛躍的に高まります。このシステムの部品化はできる限り、小さな単位でコンポーネント化し、このコンポーネントの交換だけで、メンテナンス性の向上と、柔軟性を高めます。詳しくは「IdbAで構築する生産性が高いリッチクライアント」を参照下さい。

オリエント貿易のクライアント型SOAの実装事例

クライアント型SOAの実装例として、オリエント貿易の事例を紹介いたします。

システム案件の背景

商品先物取引大手のオリエント貿易株式会社は、ネットトレードに創世記から参画している先進的な企業です。オリエント貿易はネットトレード部門で1万人の新規顧客と100億円の預かり高を獲得するべく、オリエントアグリゲーションサービスを含めたサービス展開を拡充しています。

同社のホームトレードサービス「浪漫飛行」の急激な利用者増と、顧客ニーズの変化に対応するために、柔軟かつ短期間での開発が求められた同システムでは、クライアント型SOAを採用しました。クライアント型SOAの実装により従来のサーバ型と比較して1/3の期間と開発コストで機能更新に柔軟なアグリゲーションサービスを構築できました。

アグリゲーションサービスとは
インターネット上で銀行口座、証券口座などのアカウント（口座）の管理・運営を一元的かつ一括で行うサービスです。近年、金融サービス企業では顧客サービスレベルの向上のため、本サービスを採用するニーズが高まってきています。

サーバ型とクライアント型SOAの比較

システムの検討時には従来工法のサーバ型でのシステム構築を検討されていました。しかしながら、従来のサーバ間接続のシステムでは表5のようなデメリットがあることがわかり、クライアント型SOAをベースにアグリゲーションサービス・システムを構築いたしました。

利用者のアクセスが集中するため、中央に大規模なサーバシステムの構築が必要となり、コストが逼迫する
サーバ間接続の場合、接続先の金融サービス他社との交渉が必要となり、交渉・システム開発などに多大な時間を要する
サーバ型のシステム構成の場合、利用者が所持する他の金融サービスの口座情報（ID、パスワードなども含む）を同社が管理しなくてはならないため、個人情報の観点から非常に高いリスクを負うことになる

表5：サーバー間接続によるシステムのデメリット

利用者がアクセスするのは接続先の金融サービス他社のWebサービスとなるため、中央に独自のサーバシステムを構築する必要がない（低コストでの実現）
利用者は各金融サービス他社へのWebサービスに対し同社のアグリゲーション・クライアントを通して接続するしくみであるため、各金融サービス他社のサービス約款の範囲で実現できる。よって、各金融サービス他社との交渉、提携などの時間をかける必要がない（一般的な金融サービス企業の約款には利用者が管理しなくてはならない口座情報を原則として第三者に貸与、管理移管することは禁じられています）
利用者が所持する他の金融サービスの口座情報を同社が管理する必要が一切ないため、個人情報保護の観点で非常にリスクが低い

表6：クライアント型SOAによるシステムのメリット

図5：サーバ型との比較

クライアント型SOAの実装により、短期間・低コスト・低リスクでのアグリゲーションサービスを構築することができました。同システムのシステムイメージ図は図6の通りです。

図6：システムイメージ

柔軟性とメンテナンス性の確保

アグリゲーションサービスを利用する個人投資家の方々は、資金の管理方法も多様化しています。また投資家の方々が所有している銀行、証券会社、クレジット会社の口座の組み合わせパターンも相当な数になることから、表7のシステム開発手法を採用しました。

クライアント・システムの内部を部品化（コンポーネント化）
エンドユーザ・コンピューティング・システムを採用

表7：システム開発手法

上記のシステム開発手法を採用したことにより、利用者は自分自身が必要としている機能を技術者の手を介することなく、自在に機能の取捨選択ができるようになります。さらに、メンテナンスや機能拡張の観点からも、同社は個別のコンポーネントの開発と更新のみで対応が可能になるため、メンテナンス性を飛躍的に向上させることができるようになりました。

クライアント・システムの内部を下記の通り部品化（コンポーネント化）

本システムにおけるコンポーネント・カテゴリは表8の通りです。このカテゴリ化により、接続先である金融サービス他社のWebサービスがシステム変更した場合や、新しいアグリゲーション機能を追加した場合でも、コンポーネント単位での開発・更新で対応ができるため、メンテナンス性・拡張性を高めることができました。

銀行接続コンポーネント
証券会社接続コンポーネント
クレジット会社接続コンポーネント
口座処理コンポーネント
ユーザインターフェイス・コンポーネント
アグリゲーションシステム基本コンポーネント

表8：部品（コンポーネント）カテゴリ

エンドユーザ・コンピューティングシステムについて

同システムでは利用者が利用したいソフトウェアの形にアグリゲーションソフトウェアを自在に変更できるように、エンドユーザ・コンピューティング・テクノロジーの1種であるRimless Computing（「IdbAで構築する生産性が高いリッチクライアント」を参照）を実装したIdbAを採用しています。

オリエントアグリゲーションサービスの実際の画面は図7の通りです。画面中央の「取引先一覧」の部分に利用者が必要な口座コンポーネントをドラッグアンドドロップするだけで、各口座へのアクセスが可能になるよう設計しております。また、「オプションメニュー」の部分に利用者が必要とする「口座合算処理」などの資産管理機能コンポーネントをドラッグアンドドロップするだけで、アグリゲーション機能の追加ができるように設計しております。

図7：オリエントアグリゲーション画面
（画像をクリックすると別ウィンドウに拡大図を表示します）

同社金融ビジネスディビジョンは以下のように、クライアント型SOAおよびIdbA Aggregation Client-typeに対する投資効果の高さを評価しています。

「利用者が増加にあわせてサーバシステムの増設を余儀なくされるサーバ型のアグリゲーションシステムでは、投資の回収期間が長期になり、当社のビジネススタイルには不向き。クライアント型SOAをベースにしたIdbA Aggregation Client-typeであれば、短期間・低コストでのシステム構築ができるだけではなく、利用者が増加してもサーバ側に負担がかかりにくいため、システム投資額を大幅に抑えることができる。また追加開発要件に関してもIdbA上のコンポーネントを追加するだけで対応できるため、顧客ニーズに柔軟なシステムも容易に構築・運営できるため非常に評価している。」

次回について

今回はクライアント型SOAの実践編として、設計・開発時のポイントと実例を紹介いたしましたが、いかがでしたでしょうか？限られたスペースでの解説ということもあり、場合によっては、説明が足りない部分もあったかもしれません。今回の文章をお読みになり、ご不明な点や説明が必要な部分がございましたら、是非コメント欄にご記入下さい。

皆様のご意見を次回に反映させ、より多くの方々にクライアント型SOAの秀逸さを理解いただくべく尽力いたします。今回はBtoCの事例を紹介いたしましたが、次回はBtoBおよび社内システム連携に焦点を当てたケーススタディーを中心にお届けする予定です。是非ご期待下さい。

第1回	クライアント型SOAとは
第2回	クライアント型SOAの設計方法と開発方法
第3回	クライアント型SOAの実例
第4回	クライアント型SOAによる官公庁電子申請システム
第5回	クライアント型SOAによるBtoCビジネス向けのシステム
第6回	クライアント型SOAによるスモール&クイックスタート - 最適な投資とは
第7回	ストックビジネスを変えるクライアント型SOA
第8回	クライアント型SOAが実現するBtoBクライアント

このサイトはリンクフリーです。ご自由にどうぞ。