【EC開発体験記-サービス志向-】 疎結合で真価を発揮

以下は「Webサービスによる非集中化プログラミングモデル」、懐かしいけどちょっと恥ずかしい自分の論文（ProVision掲載 2000年）からの引用。

　非集中化プログラミングモデルでは、サービス提供者の責任範囲を、インターフェース定義に従って「あるリクエストに対して処理する、あるいはメッセージとしてレスポンスを返す」ことだけに限定しており、サービス提供者は、全体がどのようなアプリケーションで、どのように利用されているかを関知しません。このように、責任が明確になることで独立性が高まり、また、管理の隠蔽という性質から、プログラム変更などでシステム全体に及ぼす影響を最小限にできます。

今のSOAのエバンジェリストに読ませたら鼻で笑われそうな内容だが、当時はこれでも脚光を浴びた（と本人は思っている）わざわざ自分の論文を引用したのは、それを自慢したいからではなく、１年かけて実際にECサイトを構築し、サービス志向設計を経験していかに重要で効果的かを知ることができたこと、また、SOAを活用したすばらしいシステムであることを自慢したいだけなのだ。（結局自慢かよ・・・）

否定の７
「７．サブシステム間を密に結合させない（サービスだけで繋ぐ）」

言語の記事でも触れたが、私たちのECシステムでは、PHPとJavaの両方を使っている。PHPが主にリクエスター、Javaが主にプロバイダーだ。実は、PHPの開発者はJavaを知らないし、Javaの開発者はPHPを知らない。共通スキルはMySQLとLinuxだけだ。一昔前であれば考えられなかったチーム編成なんじゃなかろうか。お互いを干渉しない。干渉しようと思ってもできない。結果、自然と自分の責任範囲に集中することになる。これで本当の意味でサブシステム化が可能となる。私はサブシステム化する目的の一つは並行開発にあると考えている。密結合では実質的に無理な状況であった並行開発を、サービス志向であれば可能にできる。「完全なる隠蔽」によりシステム全体に及ぼす影響を最小限にできるため、分業・並行開発ができるようになるのだ。実際にはそうなっていないStrutsプロジェクトを見ると哀れみの念さえ憶える。（言い過ぎか・・）ただし、何から何まですべてサービス化するのは冗長になりすぎるのでやめた方がよい。うまく設計しないと、パフォーマンスが悪くなったり、不安定になったりする場合があるので注意が必要だ。システムはシンプルに作るのが一番である。お金をかけた分、それに見合うコード量を要求する客はまずいないし、シンプルでかつ品質が良ければ結構なことだ。なので、必要ないところは極力サービス化しないようにすべきだろう。おすすめは、サブシステム間の接続点でのみ使用すること。また、入力後のデータ参照は自由に行ってよいが、入力の時点では、あらゆる「狂ったデータ」にも耐えられるように厳しく設計すべきだろう。それに、入力の接続点は唯一にした方がいい。

今回のシステムでいうと、受注サブシステムへの入力は、インターネットサイトからのWeb受注以外に、コールセンターにおける電話受注がある。電話受注ではPHP画面から受注テーブルに直接SQLのINSERTを実行しており、一方のWeb受注ではサービスプロバイダー経由で受注テーブルに入るようにしている。このようになったのはインターネットサイトを電話受注システムより後に構築したからだ。結果的に入力における接続点は２つ存在することになったのだが、これが大きな不幸を招く結果となった。テーブル設計書や仕様書レベルにはない細かい違いが災いして、入力経路が異なる受注で「狂ったデータ」のような振る舞いを起こすデータがしばしば見られるようになったのだ。このように、２つの接続点があるのは管理上もよろしくないので、ここは思い切って受注プロバイダー1本に統一すべきであった。そうすればデータの信頼性も高くなる。

お気づきかもしれないが、サービスの接続点は厳しくした方がよい、というのは前記事と矛盾することをいっている。わけわからんようになってしまったが、それだけ前記事はチャレンジングであるということで、ご容赦願いただきたい。

＜追記＞
　ちょっと前になるかもしれないが、サービスのインターフェースを厳密にしようという考え方があった。すべてのサービスやそのクローンはWSDLだけで作れるし、それに従えば自由に接続できると考えた。（ダイナミックバインディング）しかし、実際には予測できない「狂ったデータ」に対応できないので、うまくいかないことの方が多い。あらゆる可能性を考慮して厳密に作ろうとするのはそもそも無理がある。今回の２つの接続点の件がいい例だし、前記事のいわんとしているところもここにある。
なので、今の私のなかではエンティティに着目する考え方に大きく傾いている。どういうことかというと、サービスをエンティティとビジネスロジックに分離して、エンティティをプロバイドするという考え方だ。これはRESTに近い。近いうちに詳細は説明するつもりだ。