BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Opinion:SOAの設計時 - テイストこそが重要

Opinion:SOAの設計時 - テイストこそが重要

ブックマーク
良いSOAを構成する部品を組み立てるということになると、「テイストこそが最重要である」(source)とDan Creswell氏は主張している。Dan氏は、分散サービスのテクノロジースタックを選択することやサービス「ユニット」のレイヤー方法などは、実行可 能だと主張している者もいるようだが、SOAへのcookieカッターアプローチを取るのこととは対照的に、多くのガイドラインを検討するのと同様にテイ ストの問題でもあると言う。Dan氏は、SOAについて独自のガイドラインを定めている。

Dan氏によると以下のとおりである。

アーキテクチャー(および開発の大部分)は、決まった規則、cookieカッタースタイルで実行され、パターンおよびテクノロジーのカタログを取得し、それらを適用して、作業が完了する、と信じたい。こうした流れは最終的には、 ESBをデプロイすることで、システムをSOAにすることができる。

すばらしいアーキテクチャデータでさえも、データの依存関係は避けられないし、コードやデータを垂直にレイヤリングして、サービス「ユニット」をデータで 直接依存関係を結ばれることから、チェーンの上位で分離することを提案している。このレイヤリング形式には独特の欠点がある。なぜならば、ロケーションに とらわれないことと、上位サービスユニットへの同期呼び出しを前提としているからである。こうした前提に関する問題を避けるために、「対話のために依存が 使用するネットワークエンドポイント経由でアクセスされる、独自のプロセス内で各ユニットをデプロイする」ことを提案している。そのようなデプロイメント は、sharding、平行スケーリングおよびロードバランシングのようなテクニックを使用することでランタイムパフォーマンスに利点をもたらし、またこ れらのユニットをテストしたり、ホットパッチするという観点からみると保守容易性にも利点をもたらす。また、チームが「他の開発作業とは単独に作業をする ので、開発過程で衝突が少なくなる」。

コードやデータをレイヤリングしたり、分散アーキテクチャを選択したり、設計の選択に関する整合性の問題について考えるべき注記や、「分散コンピューティングについての誤った考え(source)を考慮」することをまとめた一連のガイドラインを提案している。

  1. 整合性、可用性および分断(CAP)(source)要求の類似点の検討
  2. データアクセスローカリティ
  3. データ関係
  4. 管轄要求
  5. 役割および責務(OOより粗いレベル)
  6. 機能(たとえば、推奨)
  7. ビジネスプロセス
  8. ビジネスプロセス全体の構成要素

... そして最後に「たいていのシステムは、大いに価値がある1つの決まったアプローチやテイストや本能的直感(source)ではなく、こうしたガイドラインの組み合わせを要求する傾向にある」と述べて結んでいる。併せて元の投稿記事(source)も参照したい。

原文はこちらです:http://www.infoq.com/news/2008/06/taste-driven-soa

この記事に星をつける

おすすめ度
スタイル

BT