サービス分割

文書管理システムを SOA を用いて構築するには、まずシステムを構成するサービスを括り出す必要があります。

サービスを括り出すためのアプローチとしては、大きく分けて

• トップダウンアプローチ
• ボトムアップアプローチ

の二つがあります。

トップダウンアプローチは、業務プロセス分析やモデリングの結果などを元にして、企業・組織としてのビジネスプロセス全体のあるべき姿をとらえ、それを構成するようなサービスを定義していくという大がかりな方法です。 これに対してボトムアップアップアプローチは、既存のアプリケーションやデータに着目してサービスを抽出しようという方法です。

今回は構築対象が文書管理システムという特定のものなので、ボトムアップアプローチを適用しました。

実際にサービスを括り出すにあたっては、いくつか注意しなくてはならない点があります。 その前にまず SOA やサービス化の目的について確認しておきます。

SOA において、システムをサービスに切り分けるのは次のような目的があります。

• 再利用
  • そのサービスを他のシステムやアプリケーションからも利用するため
• 素早い変更
  • ビジネスや業務の変更に合わせてサービスを組み変えられるようにするため
  • 他のサービスに影響を与えることなく、あるサービスだけを変更できるようにするため

サービスの括り出しはこの目的に沿ったものでなければなりません。具体的には次のような注意をする必要があります。

• 相互依存性の排除
  例えば複数のサービスが同一データ (データベースの同一テーブルなど) に直接アクセスするようになっていると、両者は相互に依存してしまいます。これでは「他のサービスに影響を与えることなく、あるサービスを変更できる」ようにはなりません。
• ビジネス機能の実現
  ビジネスプロセスをあまりに細かくサービスに分解してしまうとかえって扱いにくく、再利用しにくくなります。また相互依存する可能性も大きくなります。ではどのような大きさがよいのか、というのは一概にはいえませんが、ある特定のビジネス機能を実現するかたまり、程度にするのがよいといわれています。
• 再利用性
  SOA でいうところの再利用性は「何も手を加えずにそのままの形で」他のアプリケーションやシステムからも利用できる、ということです。いちいち手を加えないと再利用できないようでは素早い変更はできません。ですから、あるサービスに対してより汎用的な基本サービスを考えることができる場合には、基本サービスをまず一つサービスとして括りだし、その基本サービスを利用する形で目的のサービスを作ると再利用性が高まることがあります。

上記の注意を念頭に、文書管理システムのサービスを括り出しました。

先に書いたように、今回はボトムアップアプローチをとりましたが、このアプローチではデータや既存のアプリケーションに着目してサービスを括り出します。今回の文書管理システムは新規のシステムなので既存のアプリケーションはありませんし、扱うものも「文書」というデータです。したがってデータに着目しました。

このシステムが扱うデータは、大きく次の2種類あります。

1. 文書、およびそれに付随する管理情報
2. ユーザに関する情報 (認証情報など)

ということで、まず文書とそれに関連する管理情報を扱う機能を一つのサービスとして括り出します。具体的な機能としては文書の登録や検索、更新といったものがあります。これらを別々のサービスにしてしまうと相互依存関係になってしまいます。

次にユーザ情報ですが、これに関しては、ユーザ情報を取得する基本的なサービスと、それを利用する認証サービスなどの応用サービスに分けました。基本サービスを別にしたことで、将来 SOA による構成を他システムまで広げた時の再利用性が高まると考えられるからです。

さて、データに着目してサービスを括り出したのですが、実際には直接データと結び付いていない機能というものがあり、これらもサービス化する必要があります。今回のシステムでいえば、定期的に文書の承認状態を調べ、必要な通知を行うというバッチ処理のような機能があります。これはサービスとしてではなく、独立したアプリケーションとして作成することも可能です。しかし、サービス化しておけば BPEL を用いて自動実行したり、また必要があれば通常のサービス呼出によって GUI から実行させるようなことも簡単にできるので、サービスとして実装することにしました。

とまあ、文書管理システムのサービスの括り出しについてざっと書いてきましたが、実は今回サービスの設計を進めていくにあたって、問題が一つありました。 それはユーザインタフェース(画面)に関するもので、一言でいってしまうと「画面はサービスに含まれるのか?」ということです。

ご存知のようにSOAでは再利用を重視しています。しかもその再利用は、プログラムの一部を流用する、というようなものではなく、サービスをまるごと そのままの形で他からも利用する、という意味での再利用です。そのように考えると、ある機能(ビジネスロジック)とそれを扱うための画面を組み合わせてサービスと考える、ということもできそうな気がします。 逆に画面とビジネスロジックを分けてしまってビジネスロジックだけをサービスにしてしまうと、サービスの再利用にあたっていちいち画面を作らなければならない、ということになります。

とはいえ、やはり画面とビジネスロジックは分けて、ビジネスロジックの部分をサービスにすべきです。ロジックに画面がくっついていると、複数のロジックを 組み合わせるようなアプリケーションが作りにくいという技術的な問題も大きいのですが、それ以外にも再利用を進める上での障害があります。

• マルチチャンネルアクセス
  同一の機能をPC(ブラウザ)、携帯、リッチクライアントといった異なるデバイスを通して利用することを考えてみてください。この場合、ユーザインタフェースは利用する機器で異なるので、画面とロジックが分離されていないと再利用ができません。
• 自動化
  人間の手を介さないような自動処理をさせるにはユーザインタフェースとロジックは分離しておかなければなりません。また、複数の機能を組み合わせて使いたいという場合にも、ユーザインタフェースが邪魔になることがあります。
• ユーザインタフェースの流動性
  ユーザインタフェースは一般にビジネスロジックに比べると変更される可能性が高く、特に最近は AJAX などの技法でより使いやすいユーザインタフェースに変えることがよくあります。また再利用の時にロジックはそのまま使うが画面は変更したいということも多いでしょう。

SOAで既存のアプリケーションを統合し、あるアプリケーションでの処理の結果が別のアプリケーションの処理のきっかけになるというようなワークフロー的な使い方の場合には画面とロジックが一体のままでもよいでしょうが、一般的には画面とロジックは分離すべきだと思います。