サービスのラッピングと疎結合の話
こんばんは！わしです。
今日はプログラミング設計の話です。
ザザンっと、今回はサービスのラッピングと疎結合って話の２本立てです。
まずはサービスのラッピングの話です。
サービスのラッピング
上の例では、Amazonの商品情報を取得するサービスItemLookupを利用しているのですが、
ま、結合部分（ロリポップ）はAPIの定義です。
それを利用しているサービスってシンプルなシステムです。
結果はGETでISBNを指定することで商品情報をJSON形式で返します。
何でこんなシンプルな構成をサービスで切っているんだ？などと言う人が多いでしょう
WebシステムならjQueryでAmazon結果のXMLを出力すれば良いんじゃ？
とか思うでしょうが、ポイントはAmazonの接続情報ですわ。必要な情報は先日の記事で書きましたとおり
- Associate Tag
- Access Key ID
- Secret Access Key
AWSECommerceServiceを使う方法(2016/08/29)
盗まれても再発行すれば良いとは思いますが、こいつらを隠蔽したいのです！
そして、使いやすいシンプルなテストでやりたいってのがラッピングの意義です。
今回は１つのサービスを例に挙げましたが、これから書籍情報でしたら 国立国会図書館、紀伊國屋、GoogleBookなど（他にも多数存在）
これらに対応をする場合には、AWSECommerceServiceへのロリポップを増やして提供サービスは同じ、結果だけ増えると出来るわけです。
カスタマイズ性も上がりますし、テストも簡単になりますので、こういったシステムってのは使い勝手が良いですよ。
疎結合の話
先の話に近いのですが、疎結合ってのは、こういったシステムをロリポップでぐるぐるさせるのがポイントです。
提供サービスから要求サービス、可能な限り単純に行うことでシステムが簡略化可能になっております。
現在開発中の書庫管理システムにおいても、できる限り疎結合で開発しております。
Amazonからの書籍情報機能。至ってはデータベースへのI/Oまでjson形式の提供・要求で行っております。
何故そうするか？
答えは単純json生成の処理にサーバ内部の処理を行わせ、画面描写部分をHTMLとJavaScriptと完全に分離することが可能になります。
セキュリティ的には？と考える人もいます。※ GETにて要求、更新系はPOSTとしております。
その辺は… また今度書きます ノウハウ詰まりすぎてまとめきれませんPOSTだけが問題って事
疎結合で生成する事の良いところは、大量の疎結合部品が他のプロジェクトへ流用可能ってことですな。
先の例で、書籍商品のみ(Amazonの内部設計で商品種別は固定されます)なのをDVDなどの映像商品とすることにより
DVD収納庫システムとか作る時にそのまま流用できます。（内部にパラメタを付ける必要はありますが）
ま、AgileとかAspectとかちょっぴり愉快な考え方にも似ているけれども、師匠のエロ格好いいデザイン絵（ポンチ絵）が思いついた話ですけどね。
もうちょっと書いとくと
[ブラウザ]-–-()-[json]-[プログラム]-()-[外部サービス]
とか思うと良いかな。
あくまでもプログラムは外部サービスの提供サービスを実現して、下位への提供サービスを実装するのであって言語などには依存しない。
もし言語を変更する場合にも極力単純な構成となるので変更は可能となる。
また、システム全体で多言語が混在すると言った構成も可能となり、適材適所言語を変えてパフォーマンスの向上が狙える。
と、まじめっぽい話をうだうだ書いてみました。
とりあえず、地球が少しだけ単純な構成になりました。