InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

WOAガバナンスはSOAガバナンスとは別物である

作者 Mark Little , 翻訳者 菅野 裕 投稿日 2008年9月2日

セクション
設計/アーキテクチャ,
エンタープライズ・アーキテクチャ
トピック
ガバナンス ,
SOA ,
SOAプラットフォーム ,
REST
「SOA、SOA 2.0、ROA、WOA、いったい全体ひとつの略語でどこまで行くことか?」(参考記事)の議論をものともせず、Dan Foody氏(リンク)は最近の記事で(リンク)、Webベースアーキテクチャーのためのガバナンスについて語った。
よく、(企業のトップダウンアプローチによる)SOA自体の複雑さ、すなわち、形式的なSOAガバナンスの指導力を必要とすることについて語られることがあります。実際、形式的なSOAガバナンスがなしには、簡単に間違ったことを犯しやすく、SOAを成功させることは難しいでしょう。

彼の見解では、WOAはSOAの複雑さの多くを避けることができる。複雑なツールやWS-*アーキテクチャを必要としないからだ。(SOAとWS-*を同一視するのを多くの人が嫌っている(参考記事・英語)ことを、Dan氏も知っていると考えるべきでしょう。)もちろん、WS-*を必要とする(参考記事・英語)複雑なアプリケーションを実装する場合、REST(すなわち、WOA)は必ずしもシンプルではない、という議論もある(参考記事・英語)。ただ、今回はそれらの議論は置いておいて、Dan氏の肝心の問いである「結局、WOAになってもガバナンスは必要なのか?」にフォーカスしよう。

それに対する回答は、おそらく「必要」でしょう(あなたはエンタープライズ・アーキテクトですか?ここではまだ期待しないように)。しかし、私が考える「WOAガバナンス」のアプローチは、SOAガバナンスのものとは根本的に異なっています(オーケー、エンタープライズ・アーキテクトはここからしっかり聞いてください)。

その根拠は?従来の典型的なSOAでは、エンタープライズ・アーキテクトは、サービスの供給者と消費者の相互作用を管理するルールの設定をしていた。

このやり方は、組織の体制を見たときに、すべての人が結局ひとりの人に報告するような企業ではうまく機能します。

Webベースのアーキテクチャの場合でも、従来のSOAガバナンスのアプローチに従えば、サービスを相互作用させるために、これまでと同様すべてのポリシーを設定する役割を担う「インターネット・エンタープライズ・アーキテクト」をたてることになるだろう。

実に単純です。「インターネット・エンタープライズ・アーキテクトをたてる」という点以外は。これには注意が必要です。結局、SOAガバナンスのトップダウンアプローチは、WOAにとっては完全に使いものになりません。

では、どんなアプローチならうまく機能するのか?Dan氏は、WebベースやSOAPベースといった、どんなインフラを必要とするかに関わらず、ガバナンスには基本的な部分があると指摘する。たとえば、

サービスの供給者は、どうやったらより簡単に顧客を集め、そして顧客を(頻繁なサービスの変更のあいだ中)幸せにさせることができるのでしょうか?どうやったらサービスの消費者がそのサービスの提供者への信用し、信頼を築きあげることができるのでしょうか(ここでの信頼とは、「検証した上で信頼する」ということです)?

結局WOAが本当に成功するためには、SOAガバナンスの持つ目標の多くを必要とする。しかし、Dan氏の言う「根本的に異なる方法」で。これは、REST アーキテクチャに不足しているものを意味するのだろうか?WOAの単純さを損なうことなく、正しいガバナンスを加えることができるだろうか?

原文はこちらです:http://www.infoq.com/news/2008/08/woa-governance

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。