InfoQ

InfoQ

News

マイブックマーク

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

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

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

SOAはWOAを受け入れる?

作者 Mark Little , 翻訳者 編集部 投稿日 2008年9月12日

セクション
設計/アーキテクチャ,
エンタープライズ・アーキテクチャ
トピック
REST ,
Webサービス ,
SOA ,
SOAプラットフォーム
最初にWOAという用語を作り出した人びとの中の1人(リンク)であるDion Hinchcliffe氏(リンク)が、議論(参考記事)にさらに寄与し(リンク)、実際にWOAは、現在のSOA実装がおこなっていることや、ともかくおこなっていると考えられているこ ととそれほど遠くないかどうかについて話している。以下のように述べている。
個人的にはいわゆる、この軽量の次世代Webに調整されたSOAに捕らわれてはいませんが、WOAはこれまで見てきた中で最高の名称です。
Dion氏の定義では、WOAはSOAPやRESTベースのアプローチを調整するだけではない。実際、WOAはRESTと同義ではない。
WOAはWWWの設計によって駆り立てられるすべてのアーキテクチャ上の問題を含んでいます。ここで指摘したいのは、オープンWeb APIの台頭(リンク)、パッケージ化サービス消費ミニアプリケーション(Webの世界では、別名ウィジェットやガジェット(リンク))、JSONの誕生、ブラウザベースの マッシュアップ(リンク)、最近のセマンティックWebの復活などを含むアーキテクチャが今後も引き続き洗練されていくということです。
WOAに反対する議論の多くがSOAコミュニティによって推進されている。SOAコミュニティは保護主義であり、SOAビジネスを根本的に変えてしまうものを恐れている、と氏は考えている。
実際には脅威などまったくないと思います。WOAを成功に導くということになると、ガバナンスや職能上の枠を超えたビジネスアーキテクチャの調整などのSOAイニシアチブが実施しているほとんどのトップダウンアクティビティーは、まさに適切です。
Dion氏によると、WOAはアーキテクチャのスタイルであり、SOAを補完するものである。それだけではない。David Linthicum氏(リンク)は、その問題について以下のように述べている。
企業はコンテンツ、インターネット提供によるAPIおよびWebサービスを含むWebリソースを使用することで、本質的に最小の抵抗のパスがSOAを構築 することになることを見出しています。一度WOAで成功を見ると、ファイアウォールやSOAでも同様のパターンが現れてきます。インターネット/Webシ ステムがうまくいった後に、イントラネットアプリケーションが急増したのと同様です。
従来のSOAを見ると多くの利点を提供しているとDion氏は言う。 「それほど高額ではなく、使用上の時間の消費が少ない改善されたサービス消費モデルや、情報の検索や使用および分析を促進するリンクアーキテクチャのすさ まじいパワーを解放するサービス消費モデル」などがそうである。SOAを実装するための他の技法に比べると始めるのは簡単である。Roger Smith氏(リンク)は、以下のように述べる。
ますます多くの企業が、草の根運動で生まれた可視性がより低いWeb指向のアーキテクチャ(WOA)開発が、サービス指向アーキテクチャへのより良い手段であることを発見しています。
Dion氏は、本質的に分散されたWOAと比較すると、分散SOAが無視されていると続けて述べ、シンジケートや「低インピーダンスWebサービス」など の技法を提供している。その上、JEEや.NETなどの人気のある開発インフラはJSR 311(リンク)やWCF(リンク)などのアプローチを通じてWOA(または少なくともREST)を採用している。これはその他のSOAアプローチ(Webサービスなど)の失 敗が原因なのか、それとも単にフリーサイズで間に合うことが滅多にないこと(リンク)が理由なのかが、未だにはっきりしない。しかしながら、WOAはこれで安泰(リンク)というわけではない。Dion氏が指摘するように、少なくとも初めは導入を困難にさせるWOAの利用方法に、ビジネスによって基本的な相違がある。それには Web上における情報の検索可能性(PRは、毎回Googleのキャッシュが検索することを確認)(リンク)および本質的にAPIがパートナーに開放されていて、適 切なデータを安全かつ確実に公表できるようにしているという事実がある。
多くのビジネスが迅速にWOAへ向けた活動をしている中で、制御の遷移、開放の増加、アーキテクチャについての考え方の相違、無数のセキュリティ問題やガバナンスにまつわる懸念がその阻害要因になる可能性が高い。

しかし、Dion氏をはじめとする人びとがSOAの未来はWOAであると強く信じていることは明らかである。今年や来年にそうなろうとも、WOAははずみをつけている。既存のSOAはそれを受け入れるか、道を譲る必要がある。

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

特集コンテンツ一覧

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 のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。