開発バラバラ事情

一昔まえ前ではC/S（クライアント／サーバー型）と言われた処理が主流でしたがいまではほとんど見なくなってきましたね。今日は多層処理についてお話したいと思います。

時代の変化

すべてはインターネットの普及から始まっています。社内ネットワーク（イントラネット）であらゆる業務を行っていたことは外部とのデータ交換も定形手順で交換していました。JCA手順や全銀手順、HULFTなどの通信ソフトもその一つでしょう。使えるポートもセキュリティもそんなに気を使わなかったのに最近ではグローバルネットが当たり前で使えるポートも限られる。どんどんセキュリティ要求が高くなる。それもそれもインターネットが当たり前になり、高速になり、安価になった結果なのかもしれません。なんて時代だ！

昔から開発している人

サーバーでデータを一元管理できるだけでもすごく便利ですよね。データをそこに取りに行けばなんでもある。とりあえずデータを取ってきてあとはクライアントでゴリゴリゴリゴリ。一覧表示したりグラフにしたり印刷したり。そういったロジックを記述するのがプログラミングだったな～。特にデータ取得を高速化したり、ソートのロジック変えてみたりしてね。
データベースで管理するようになってからデータの取得の高速化はSQL文の書き方やモデリングに変わり、ソートなんてろくすぽロジック書かないし。ロジック＝SQL文って感じですよね。クライアントアプリでSQL文をカリカリ書いてるもんだから同じような処理があってもまた新たに記述したりして。ロジックが分散するので不具合もたくさん発生していました。一箇所直しても他は直らないなんて当たり前だったのではないでしょうか。

魔法の80番ポート

SQLサーバーだと1433番というポートを使っていますが、処理によっていろんなポートを使って通信しています。ところが「セキュリティポリシー」というものがこういったいろんなポートを使わせてくれなくなってしまったのです。よくわからないポートは使用禁止。外部から攻撃を受けそうなものは停止。ブロックできるところだけでしか開けちゃダメ。ってことで80番や443番ポートしか開けてくれないんです。これはHTTPとHTTPSというポートでWEBブラウジングするためのポートですね。いまではこのポートを駆使してシステムって作られているんです。

処理を分割して対応

80番ポート（HTTP）で処理できる命令はやっぱりHTTPの命令な訳でどうやってデータベースからデータを取ってくるのか？
それが本題の「粒度」に関連してきます。そのままデータを取ってくることは出来ませんので、HTTPのPOST命令を使って「データをちょうだい」って命令します。命令を受け取ったWEBサーバーが実際にSQL文などを発行してデータベースからデータを取得します。でもデータベースの取得したものをそのままクライアントに受け渡せないので、JSONやXMLなどの形式に変換してクライアントに受渡しているのです。
これが処理の分割といって、このリクエスト単位を「粒度」って言っています。
単純にデータベースのマスタ情報であれば、テーブル単位＝粒度になるのだと思うのですが、幾つものマスタから情報を取得して作成される伝票データのようなトランザクションデータはテーブル単位というわけにはいきません。僕的にはこの「粒度」は処理単位に設計しています。

処理の単位

処理って何かなというと、画面単位だと考えていただくと良いと思います。ボタンを押したらその画面に表示する情報をリクエストしクライアントに受け渡す。更新するときは更新する内容をリクエストし、更新に必要な計算はサーバーで行って付随する必要な情報もサーバーで補完してデータベースに更新します。こうすることでロジックの分散を防ぐわけです。処理は分割するのにロジックは分割したくない。ロジックを分割すると不具合も分割されます。分割されるってことは増えるってことですね。（笑）

最近よかったって思います

WEBサーバー側とクライアントの表示部分と両方開発しなくてはいけないので面倒だと思っていましたが、気がつけば良いことも多い。なんといっても使いまわせる。パソコンだけじゃなくて、タブレット用やスマホのアプリにも流用できるんです。その時にはWEBサーバー側は作る必要がないことも多い。クライアント側だけ作れば良いってことですね。色んな物を分割することで手間は増えるけど時間的なスピード感も求められています。分割したことで顧客に提供するモノも分割することができるようになったのは良かったことなのではないでしょうか。

こうなったらもっと分割してみたらいいのかな？
物事には限度があります。細かく分ければ良いってわけではなく適切に分けることが重要なんですね。
みなさんも仕事を分割してみてはいかがでしょうか？