これまで長い間(source)SOA（サービス指向アーキテクチャ）とWeb 2.0との関係を作りあげることが考えられてきた。しかしDion Hinchcliffe氏はこう記している(source)。
…この２つの文化の間で異花受粉をさせることは、その潜在的な桁外れの機会があったにもかかわらず、大抵が失敗に終わっている。
一部の人たちがようやくこの２つをアーキテクチャの観点からフィットさせること(source)に目を向け始めた。ある大金融機関で上級アーキテクトを務めるGanesh Prasad氏、コンサルタントのRajat Taneja氏とRhys Frederick氏はこの記事の中(source)でSOFEA（Service Oriented Front End Architecture)とは何かを定義した上で、どのようにSOAとWeb 2.0を関係付けるかについて分析をしている。
この数ヶ月、マッシュアップ用フレームワークによって２つの間に橋渡し(source)が始められ、IBM(サイト・英語)やWSO2(サイト・英語)といった企業の新製品は、RESTfulリソースやWebサービスとWeb 2.0なユーザエクスペリエンスとを結びつけることに最も注力している。
2月5日、Apache Tuscanyプロジェクトでは、各種サービスとWeb 2.0のユーザインターフェースの複合を容易にする(source)ことでSOAとWeb 2.0とを統合する新しい方法を送り出した。
企業連合の分野ではAtom Publishing Protocol（リソースの編集を行うプロトコル）(source)の進展によってある程度び決着が着いている。Atom Publishing ProtocolによってRESTfulなサービスのリソースを外部から扱えるようになる。しかし一部の人々はエンタープライズで広く用いるには限界(source)があると見ている。
またある人はSOAとWeb 2.0の他の面(source)(Wikiやタグ付け、ブログなどのコラボレーションや、検索、広告、ファイル共有）との統合は始まったばかりで、やり尽くされたと呼ぶには程遠い状況だという。
ボストンを拠点としヨーロッパにもオフィスを構えるコンサルティング企業Opators(サイト・英語)は既に先を行っていて、OSS（オープンソースソフトウェア）を利用したWeb 2.0とSOAを組み合わせたソリューション提供にフォーカスして実績を重ねている。
InfoQはOptarosのMarc Osofsky氏とDave Gynn氏に話をきいた。
InfoQ: Web 2.0を企業内にうまく取り入れることについてどのようにお考えですか。
Dave: 私たちはそれを次世代インターネットと呼んでいます。ソーシャルアスペクト、読み書き可能、リッチユーザインターフェース、ネットワーク指向のコンポーネント（従来のモノリシックアプリケーションではなく）。それらが取り入れられ、Web 2.0が広がるのです。
これまではあるページは一つのアプリケーションから送られてきました。しかし今、ユーザは別のサーバから送られてきたページを通してアクセスするようにもなっています。間違いなく関心が寄せられているのはよりシンプルなサービスの類です。RESTインターフェース、それをユーザは将来利用したいと考えているでしょう。Ajaxの登場ではページに対するデータをどう提供するのがいいかを考えるようにりました。そしてJSONフォーマットが生まれたのです。
Marc: サービス提供の点で言えば、Web 2.0テクノロジーのキーになっているのは、ユーザエクスペリエンスとアーキテクチャの両方をいかに最大限にするかということです。普通顧客は自分たちの欲していることを完全には認識していません。Web 2.0テクノロジーによってプロトタイプをすぐに作って顧客へ見せられるので、顧客はそれを判断して新しいアイディアを見つけることができます。このことで私たちも時間と料金が確定したビジネスモデルを行うことができるのです。
Web 2.0とSOAは素晴らしい相乗効果ももたらします。私たちが見てきた他の企業はSOAかWeb 2.0のどちらかだけでしか提供できていませんでしたが、それは私たちよりずっと時間がかかることになるのです。
InfoQ: オープンソース、多くの場合はコンポーネントの再利用ということですが、エンタープライズ業界でどのような影響があったと思いますか。
Dave: 4年前、Optarosの創設者はOSSがISV（独立系ソフトウェアベンダ）からユーザ側へとシフトしていることを認識していました。このシフトはコンサルティング企業にとってのビジネス市場を変えそうでしたし、新たなサービスモデルが必要でした。
私たちが目指すのは顧客が真の差別化要素を生み出せるプロジェクトに対して予算を集中させることです。通常の場合、一つのプロジェクトの80%がコモディティなローコストのコンポーネントで供給でき、20%が顧客向けにカスタマイズされたものです。
オープンソースは新しい再利用モデルをもたらしました。どんな企業でもアプリケーションはたいてい一度しか使われません。そのため一つの企業内だけでは、あるソースコードのコミュニティを生み出すのは非常に難しいのです。
Optarosでは、ESB Mule(サイト・英語)のようなSOAミドルウェアコンポーネント、CMS（コンテンツ管理システム）にはDrupal(サイト・英語)、CRM（顧客関係管理）にはSugarCRMand(サイト・英語)、などあらゆる再利用可能なものを使用します。
InfoQ: Optarosのソリューションの取り組み方やコンポーネントの選択基準について詳しく教えてもらえますか。
Dave: 今のところシステム全体の再利用は目にするものの、特定のサービスの再利用は見かけません。次々に出るアプリケーションによって良いサービスインターフェースは多くなっていますが、サービス自体はまだ見つけるのは難しい状況です。例えば、コンテンツ管理サービスについての議論はありませんよね。ただコンテンツ管理システムの実装にだけ目を向けているのです。
私たちのやり方では、まず製品やコンポーネントの評価を行いますが、これをまったく新しい方法で行っています。判断基準となるマトリックスを使って評価する代わりに、同じ問題を解決しようとしている人がいないか、そしてその人たちがどのようなコンポーネントやシステムを利用しているのかを調べるのです。
例えばある大学が私たちの顧客にいるのですが、その大学がコンテンツ管理システムの導入のために発注をしてきた時、私たちは先方の要求と他のある顧客の要求とを比較しました。そしてその時はSakai(サイト・英語)というオープンソースシステムを利用することにしました。
Marc: Wonderbox(サイト・英語)（OptarosがストアフロントとCRM、バックエンドの統合を行った小売業プロジェクト(source)のケースでは、多くの小売業者に共通する方法を採りました。アセンブリ言語と動的言語、そしてWeb 2.0（RIA、Ajax、ストリーミング）を使ってプラットフォームの再構築を行いました。基盤となるリクエストブローカ（要求を仲介する仕組み）を置いて、顧客のインフラにラッパーを被せてからバックエンドサービスの移行に取り掛かりました。利用したのは全てオープンソースコンポーネントです。BOM （Bills of Materials：部品表）や利用状況・支払のトラッキングはosCommerceとSugarCRMで管理し、全てのサービスの接続にはMule ESBを使いました。
InfoQ: SOAインフラのオープンソースコンポーネントについてはどのようなことがありましたか。
Dave: 私たちの経験からすると、ミドルウェアはベンダー依存しない方がプラスになり、たとえば標準サポートはその方が良かったりします。逆にベンダーのプロトコルでインフラをつなぐと、SOAの要を失ってしまいます。もちろんオープンソースコンポーネントのフリーあるいは非常に安いコストという面もプラスになります。
いずれオープンソースソフトコンポーネントがあらゆるシステムに取り入れられるでしょうが、特定のベンダの場合は必ずしもそうはならないでしょう。
オープンソースソフトウェアの鍵となる利点はプロジェクトの早い段階に現れます。コンセプトの実証をしている段階では仮にオープンソースコンポーネントを使っておいて、ある時点でどこかの製品を買って置き換えるようなことができます。ただ通常、顧客はオープンソースコンポーネントをそのまま使い続けますね。特にESB（Enterprise Service Bus：データ連携の基盤となる技術）の場合はそうです。
サービスが有効に使われることでアプリケーションの異なる部分からメリットを得られた良い例として、SwissCom? Hospitalityというホテル向けの無線プロバイダがあります。フロントエンドはPHPで組んでいます。フロントエンドの開発と修正を受けたのですが、向こうの希望するバックエンドはJavaで書かれ、サードパーティ製のサービス（プロキシとデータキャッシュ）を使っていました。そこで私たちは Webサービスを使ってPHPからTomcatコンテナへの連携を行いました。
Marc: SymphonyやPythonのようなスクリプト言語は規模を変えても有効に働きます。ちょうどこれらのテクノロジーを使ってトラフィックの多いサイトを始めたところなのですが、私たちにとって一番重要なのは、スクリプト言語によってユーザエクスペリエンスのデザイナーと一緒にプロトタイピングを速く行えることです。ちゃんと機能するサイト全体のプロトタイプを作るのに数週間しかかかりません。SOAのブローカとコンテナも非常に成熟していて、この点ではそれほど問題が起きません。SOAの技術全体にエンタープライズクラスの強固さがあるというのが私たちの意見です。
まだ欠けているのはより機能的なコンポーネントです。例えばストアフロントまで含めて値段や製品情報の管理を行える”マーチャントデスクトップ”です。これは多くの場合カスタムコンポーネントです。SaaS（Software as a Service）から見れば、コアなオーダー管理である精算プロセスもまだ欠けている部分のひとつです。このコンポーネントを提供しているソリューションもありますが、そのコンポーネントというのはプレゼンテーション層にがっちり結合されているのです。
WonderBoxの場合、6ヶ月で新しいプラットフォームを設計し実装しました。この納品スピードは重要です。なぜなら小売業界では何か変更するのに6ヶ月か9ヶ月の時間しかもらえないのです。システムはホリデーシーズン（11月末から12月末）には安定稼動してないといけませんし。
InfoQ: Optarosの編み出した方法論と使っているツールについて教えてもらえますか。
Dave: 私たちのやり方ではアジャイルな方法と作業範囲の確定を一つにまとめます。このやり方ではコンポーネントの再利用と組み合わせに重点を置き、カスタムコンポーネントとは距離を置くことになります。私たちはある問題を解決するのに最も適したコンポーネントを特定することにかなり早い段階で重点を置きます。自分たちで書かないといけないコードの量がなるべく少なくなるようにするのです。
開発においてユニークな差別化を行えない時に、それをオープンソースプロジェクトへフィードバックすることがよくあります。例えば私たちはActiveMQ（オープンソースのメッセージブローカ）に強力なデッドレター（到達不能メッセージ）の処理能力がまだなかった頃からActiveMQを使用していました。私たちはActiveMQがデッドレターに対処できるようコーディングし、その機能をActiveMQプロジェクトにもコミットしたのですが、これは顧客にとっても良い事でした。というのは、次のリリースがやってきた時に大規模なアップグレードを行う必要がなく、バグ修正や実行性能の最適化のために余計な時間をかけなくてもすんだからです。このようなことは顧客とオープンソースプロジェクトにとって本当にwin-winな状況ですね。
私たちはできるかぎりオープンソースのツールを使用するようにしていますが、それは顧客に干渉しないためです。