レイヤーアーキテクチャはSOAでも有効か

SOAにおけるサービスの実装法ではカプセル化の考え方から、どんな実装法でも選択が可能です。
多くの場合は、OOPを使い、インターフェイス定義を使ってクラスを実装するとともに、インターフェイス定義をWSDLで外部に公開します。
あるいは、Contract-Firstで開発する場合には、先に契約を定義して、実装法を後で選択します。
しかし、この場合でも主流の開発言語がOOPであることや、SOAで必要となる他の非機能要求の実現のために必要な機能を提供する実行環境がOOPのフレームワークで提供されているので、OOPが現実的な選択となります。こうしたフレームワークはたいていの場合、スケーラブルなアーキテクチャを想定するあまり、レイヤー構造となっています。たとえば、.NETの場合は、asmxやWCFを選択し、HTTP実行エンジンとしてはWebサーバ（UI層）、データ処理にはデータアクセス層を利用します。

以上の現状から、SOAの実装は、一部のレガシーラッピングを除き、レイヤーアーキテクチャを前提としているといっても過言ではありません。

さて、それではSOAの実行を最適にするアーキテクチャはレイヤーアーキテクチャかと言えるでしょうか？

答えはNoです。

Microsoft社が最初にCOM（Component Object Model）を出したとき、EXE形式のサーバとDLL形式のサーバを提供しました。それぞれ一長一短の特徴を持ちますが、ActiveXと呼ばれるコンポーネント技術が主流になるころには、ソフトウェア部品の提供形式はDLL形式に落ち着きました。
これはコンポーネントをモジュールとして配布しやすい理由もありますが、一番の理由は、僕はインプロセス呼び出しにより、呼び出し性能が優れている点にあると思っています。だだし、COMの場合は、スレッディングモデルという難解なルールがあるので、DLLでの開発は難しかったハンディがありました。

現在の.NETであっても、あるいは、Javaのような別の実行環境であっても、コンポーネントの配布や実行形式はインプロセスが有利なのです。これは、SOAの実装法でも同様です。

SOAのサービスはユースケースの実現と同様にレイヤーアーキテクチャを取るとレイヤー間での呼び出しやデータ転送が発生します。もし、レイヤーがアーキテクチャとしてプロセスをまたぐ物理階層だとしたら、前述のコンポーネントモデルの実績の歴史と矛盾します。あくまで、インプロセスでなければ、歴史が証明している進化と逆行してしまいます。

それでは、現在のSOAの実装法は正しくないのでしょうか。僕は正しいとは思えません。もう1度、SOAのためにレイヤーアーキテクチャではないシンプルなアーキテクチャを作るべきと考えます。今後のシステム開発がSOAを主流と考えるのならば、これは、現在のレイヤーアーキテクチャはもう主流ではないと言えるでしょう。

それではどうすべきでしょうか。ここでは、2つの問題があります。

• SOAPで転送されるメッセージは帳票の一種であって、複数データの組み合わせからなる半構造化データであること。したがって、そのメッセージを受信処理するアプリケーション（コンポーネントや他のサービスを含む）も1つとは限らず、一般には複数からなること。
• サービスによるシステムの分割は、特に更新系の場合、マスターデータの配置の問題を解決する必要があること。"one fact in one place"の原則から論理的に単一箇所で管理すべきマスターデータを、サービスに物理的にどのようにパーティショニングすべきかを考える必要があること。

この2つを同時に解決するための新しい設計法が必要です。
その設計法が有効となる、アーキテクチャを考えていくことになります。

次回に解説したいと思います。