新しい WSO2のホワイトペーパーである "Practical SOA for the Solution Architect" は、SOAを以下のように位置づけている。
... 情報時代が幕開けして以来、今日最も重要な意味を持つ常識の領域である。
これを念頭において、ペーパーが試みようとしているのは、
...容易に理解でき、直ぐに適用できるSOAを使うための実践的アプローチを提供することである。それはまた、ベンダー中立で、普遍的に適用できる概念とどのベンダーの製品にもありそうな論理的コンポーネントを扱っている。
ペーパーは、ソリューションアーキテクト（Solution Architect）の最も重要な2つの側面に焦点を当てている。
- 技術レベルでは、 ソリューションアーキテクトは、仕事に必要な適切なツールを理解する必要がある。
- データレベルでは、システム間の不要な依存関係をいかに減らすか、あるいは無くすかを知る必要がある。
技術（ツール）層では、3つの中心的なSOA技術コンポーネントが一番頻繁に使われる。ペーパーによると、
- サービスコンテナ
- ブローカー
- プロセスコーディネータ
既存と予定の機能コンポーネントを一緒にして、完璧なビジネスソリューションを作成するために、 ソリューションアーキテクトが必要なこれらのコンポーネントは、以下のように使われるべきである。
- サービスコンテナは、ソリューションの一部として実装された新しいサービスを収納するプラットフォームである
- サービスブローカーは、既存のエンタープライズアプリケーションの機能をサービスとして公開できるようにするツールである。既存機能のアダプター／変換役／仲介役が合わさったサービスを提供する
- プロセスコーディネータは、ビジネスプロセスを実装したり、サービスの実行を一緒にするために使われる。
ペーパーによると、これら3つの他に、SOAの実装で共通に使われるコンポーネントには次のようなものがある。ルールエンジン、データアクセスツール、レジストリ／レポジトリツール、管理と監視ツール、統制ツール、カスタムイベント プロセシング、プレゼンテーションサポートなど。
ペーパーは更に、単に正しい技術的なコンポーネントを選ぶだけでは、SOAの成功を確実にするには充分でない、と説明している。
我々は、適当なSOA技術コンポーネントを使うことで得られた利益を、密結合のデータ設計によって、打ち消されないように保証する必要がある。
疎データ結合のSOA設計を達成するために従うべき以下の4つのルールが記されている。
- 暗黙のデータを認識し、明示的にする - システム内で起きた変化を隠して、契約を常に厳守することを単に保証することによって、他を隠蔽する。
- システム間の不要な依存関係を取り除く - 意味のない依存関係を取り除くようにすべきである。
- ドメインデータとメッセージデータを疎結合に保つ - これを達成するには、データ生成や導出ではなく、データマッピングを使う。
- 全組織を跨ぐのではなく、論理的なドメイン内で語彙を標準化する - 企業全体を跨いで語彙を標準化するのは、「海を沸騰させようとする」ようなものである。
ペーパーはまた、銀行や保険業界からいくつかの例を提供して、記述した概念の実際の適用を説明している。
以下のように結論づけている。
これらの単純であるが強力な考えは、効果的なSOA設計に重要なことであり、あなたは今や、自分のスキルのレパートリーにこれらの概念的なツールを加えたことになる。これらのツールを使えば、あなたの次のプロジェクトにしっかり取り組むことができ、SOAの原理に従ったソリューションを直感的に設計できるようになる。
ホワイトペーパーの結論とそれが定義している原理の重要性に賛成しないのは難しいが、既存のSOAの発表と比べて、本当に何か新しいものをもたらしているわけではない。技術側で、基本的に言っているのは、サービスコンテナを利用してゼロから作るか、アダプター／変換役／仲介役パターンを通して、既存のレガシーアプリケーションを公開することで作れるサービスの実行は、ビジネスプロセスによって統合されるべきである、ということである。この同じ技術的ソリューションは、近年のESBの基礎である。データ側では、「教科書的な」エンタープライズデータモデルのアイデアは、15年前にEAIによって紹介され、多くのSOAの実装で広く採用された。暗黙から明示への変換と不要な依存関係の除去に関しては、これらは既存のサービスデザインパターンに直接関係しており、サービスの疎結合とよく定義されたインターフェースの背後にサービスの実装を隠すことである。
一方、これらの原理をSOAの実践者が思い起こすことは、常に有用である。