[方式設計編]同一サーバー内のWebサービス呼び出しをしてはいけない
SOA（サービス指向アーキテクチャ）の概念が普及するにつれ，前提となる技術的基盤であるWebサービスのインタフェースを持つシステムが増えてきた。一般的には「在庫を照会する」「入金処理を行う」などの単位で一つのサービスにすることが多い。Webサービスは，既に提供されているサービスを組み合わせてアプリケーションを構築できるという手軽さがあるが，作り方を間違えると性能や信頼性の低いシステムが出来上がってしまう。その典型の一つがこれだ。「同一サーバー内のWebサービス呼び出しをしてはいけない」。 説明を簡単にするために，図1に示す単純なアーキテクチャで稼働するシステムを想定しよう。なお，記載している製品名はあくまで例であり，各分野におけるリファレンス実装もしくはデファクト・スタンダードなものだ。読者の得意な製品に置き換えて読み進めてほしい。 アプリケーションはServletとして実装する Serv
![[方式設計編]同一サーバー内のWebサービス呼び出しをしてはいけない](https://cdn-ak-scissors.b.st-hatena.com/image/square/bed39b5962a5d552c95b6d796db8f55e72d32943/height=288;version=1;width=512/https%3A%2F%2Fxtech.nikkei.com%2Fimages%2Fn%2Fxtech%2F2020%2Fogp_nikkeixtech_hexagon.jpg%3F20220512)
高木浩光＠自宅の日記 - はてなブックマークを禁止する技術的方法, 追記, 追記2 （23日）
■ はてなブックマークを禁止する技術的方法 ある属性を持つ人々にとって、はてなブックマークは、必要な情報源を巡回するための効率的なツールとなっている。もはや「はてブ」されない記事は存在しないのも同然となってしまている人もいるかもしれない。ソーシャルブックマークサービスはなにも「はてな」だけではないのだが、事実上「はてな」が独占状態にあり（少なくとも一部の分野においては）、「はてなブックマーク」でないと情報源となり得ない状況になっている。この状況はアーキテクチャ的に望ましい状態ではないと思うが、しかたない。 そういう中で一つ問題がある。情報セキュリティの話題を追いかけるには「セキュリティ」タグを見ていればよいわけだが、ここに「JVN」のエントリが出てこない。 JVNの認知度が高まらないのにはいろいろな要因があって、JVNのサイトデザインが最悪だ（ユーザビリティを何も考えていない）という問題も
ユメのチカラ: 開発工程を別々に担当してはいけない
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コンセプトプログラミング
