SOA.NET(2) Small Start SOA
●既存のシステム群が、独自の連携方式でこんがらがっている
既存のシステム群が、独自の連携方式でこんがらがっている状況を図にします。
図1 結合度の高い業務システム
この状態はシステム同士の結合度が高く、どこを変更するにも、多くの箇所に影響が出てきてしまいます。また、データの整合性を保つための方式が十分に考慮されていない状況と考えてください。
この状況から、認証の仕組みを更新することを考えてみます。認証部分は、プロセス通信や、リモート呼び出しなど、いろいろな方法でやっていたとします。
今まで通り、従来の通信に合わせて、既存システムに影響が出ない形で認証のシステムを更新すると、3つのアプリからの通信に対応する必要があります。これでは、今後もすべての方式に対応していかなければいけません。
図 2 認証に関わるアプリ
●通信を一本化する
そんな非効率なことはやめて、通信を一本化するのはどうでしょうか。試しに通信方法をWCFで統一してみます。
図 3 レガシーの一部を移行
実際には、新規認証サービスだけを構築するのではなく、各APと認証の連携部分をWCFに対応させる変更作業が必要になります。その分（各APを修正する）作業が増えますが、システムが少しほぐれているのが感じられます（必要に応じてWFによるサービスオーケストレーションを利用します）。
●少しずつほぐしていく
こうして既存システム群をほぐしていけば、そのあとそれぞれをリファクタリングしたり、新規システムを標準の通信方法でプラグインしたりすることができます。
つまり、今後認証部分やそれを利用するAPを更新するようなことがあっても、統一的な方法で修正することができますし、新しく連携するシステムが現れても標準の方法でアクセスすることができます。
図 4 新規サービスをプラグイン
こうして、少しずつ疎結合な、それでいて必要な連携が可能なシステム群に整理されていくのが理想でしょう。
将来的には、標準に則った既存のサービスと既存パッケージを利用して、無駄のない新規システムの構築ができるようになるといいですね（WFの代わりにBizTalkを使うと、既存パッケージとの連携が充実しているそうです）。
図 5 将来のシステム構成
将来的に、図にある「既存サービス」部分は、グループ会社や他社が提供するものを利用することもできるかもしれません。再利用するサービスは、WS-*に対応していれば、特にWCFである必要はありません。