サービスとオブジェクトの違い （SOA vs OO）
SOAもオブジェクト指向も、ソフトウェアアーキテクチャのスタイル（様式）の1つだ。つまり、それぞれソフトウェアの構造に関するまったく異なるパラダイムを提示している。では、サービス指向における「サービス」と、オブジェクト指向における「オブジェクト」とは、どんな違いがあるのか？
その違いを思うままに挙げてみると、以下の点が思いつく。
● オブジェクトは生成／破棄のライフサイクルをもつが、サービスは「常に既にそこに在る」
● サービスには継承・ポリモーフィズムが無いが、メッセージ交換パターンや契約・ポリシーがある
● オブジェクトは同期的、サービスは同期／非同期両対応
● オブジェクトは構造に注目し、サービスは相互作用に注目する
オブジェクトは生成／破棄のライフサイクルをもつが、サービスは「常に既にそこに在る」
オブジェクトを使うには、まずオブジェクトを生成しなければならない。用の済んだオブジェクトは破棄される。どこかで作成済みのオブジェクトを使い回すこともあるが、それも一度はどこかで生成されたものであるし、ライフサイクルが終了すればやはり破棄される。
一方で、サービスには生成や破棄という概念がない。サービスは無条件に存在し、存在し続ける。
（横道にそれるが、DIコンテナを使ったプログラミングでは、オブジェクトはインジェクト（注入）されてセットされるので、プログラミング上はあたかもオブジェクトが常に存在しているかのような印象になる。DIベースではビジネスロジックをサービスと表現したくなるのは、多分このためだろう）
サービスには継承・ポリモーフィズムが無いが、メッセージ交換パターンや契約・ポリシーがある
オブジェクト指向の基本的なテクニックは継承、ポリモーフィズムだが、サービスにはそういった概念はない（ポリモーフィックなサービスという考え方を導入しようとする人もいるみたいだが）。サービスの構造を作る上で、そのような複雑な仕組みは強力すぎて必要ないからだろう。
その代わりサービスでは、それを利用するための契約や、利用のポリシーといった相互作用に関する部分の取り決めが重要になる。また、サービス同士の組み合わせを考えるときに、サービス間の相互作用にどういったバリエーションがあるか（メッセージ交換パターン）を把握することが重要になる。
オブジェクトは同期的、サービスは同期／非同期両対応
オブジェクト間のメッセージパッシングは、基本的に同期的だ。OOPでは、オブジェクトに送ったメソッドの処理が完了するまで呼び出し元は待機し、結果を受け取ってから処理を再開する。OOPで非同期を無理やりやろうとすると、マルチスレッドを導入したりJMSのようなメッセージングを利用したりと、どんどん複雑になる（最近の並行プログラミングの流行から、アクターモデルのような非同期型のオブジェクトモデルも注目されるようになって来てはいるが、実用には程遠い）。
サービスの場合は、相互作用のパターンとして同期と非同期が初めから考慮されている。RPC（Remote Procedure Call）のような通信パターンを取れば同期的になるし、メッセージングを用いれば非同期になる。
オブジェクトは構造に注目し、サービスは相互作用に注目する
上記の違いを見てきて分かるのは、オブジェクト指向はオブジェクトの「構造」を設計するのに適しており、SOAはサービス間の「相互作用」を設計するのに適しているということだ。ソフトウェアアーキテクチャの研究では、アーキテクチャ構成要素の構造よりも、構成要素間の相互作用の記述が重要になることからもなんとなく推測されるように、視点がマクロになればなるほど、構造の複雑さを捨象して、相互作用に注目することが必要となるのかもしれない。逆にミクロアーキテクチャのレベルで相互作用に注目するのは、少しオーバースペックになる。
つまり、オブジェクトとサービスとの性質の違いは、OOとSOAとが対象とする設計規模の違いをそのまま反映していると言えなくもない。
---
さて、いずれにしろ大事なことは、既に広く認知されている「オブジェクト」という概念と、最近注目を集めだした「サービス」という概念とが本質の部分でどのように異なっているのかを、このように考え続けて理解を深めていくことだと思う。
サービスやSOAを考えるにあたっては、以下のようなリソースが参考になる。
・ OASISのSOA参照モデル
・ "Developing in a Service-oriented World" by Gregor Hohpe
その違いを思うままに挙げてみると、以下の点が思いつく。
● オブジェクトは生成／破棄のライフサイクルをもつが、サービスは「常に既にそこに在る」
● サービスには継承・ポリモーフィズムが無いが、メッセージ交換パターンや契約・ポリシーがある
● オブジェクトは同期的、サービスは同期／非同期両対応
● オブジェクトは構造に注目し、サービスは相互作用に注目する
オブジェクトは生成／破棄のライフサイクルをもつが、サービスは「常に既にそこに在る」
オブジェクトを使うには、まずオブジェクトを生成しなければならない。用の済んだオブジェクトは破棄される。どこかで作成済みのオブジェクトを使い回すこともあるが、それも一度はどこかで生成されたものであるし、ライフサイクルが終了すればやはり破棄される。
一方で、サービスには生成や破棄という概念がない。サービスは無条件に存在し、存在し続ける。
（横道にそれるが、DIコンテナを使ったプログラミングでは、オブジェクトはインジェクト（注入）されてセットされるので、プログラミング上はあたかもオブジェクトが常に存在しているかのような印象になる。DIベースではビジネスロジックをサービスと表現したくなるのは、多分このためだろう）
サービスには継承・ポリモーフィズムが無いが、メッセージ交換パターンや契約・ポリシーがある
オブジェクト指向の基本的なテクニックは継承、ポリモーフィズムだが、サービスにはそういった概念はない（ポリモーフィックなサービスという考え方を導入しようとする人もいるみたいだが）。サービスの構造を作る上で、そのような複雑な仕組みは強力すぎて必要ないからだろう。
その代わりサービスでは、それを利用するための契約や、利用のポリシーといった相互作用に関する部分の取り決めが重要になる。また、サービス同士の組み合わせを考えるときに、サービス間の相互作用にどういったバリエーションがあるか（メッセージ交換パターン）を把握することが重要になる。
オブジェクトは同期的、サービスは同期／非同期両対応
オブジェクト間のメッセージパッシングは、基本的に同期的だ。OOPでは、オブジェクトに送ったメソッドの処理が完了するまで呼び出し元は待機し、結果を受け取ってから処理を再開する。OOPで非同期を無理やりやろうとすると、マルチスレッドを導入したりJMSのようなメッセージングを利用したりと、どんどん複雑になる（最近の並行プログラミングの流行から、アクターモデルのような非同期型のオブジェクトモデルも注目されるようになって来てはいるが、実用には程遠い）。
サービスの場合は、相互作用のパターンとして同期と非同期が初めから考慮されている。RPC（Remote Procedure Call）のような通信パターンを取れば同期的になるし、メッセージングを用いれば非同期になる。
オブジェクトは構造に注目し、サービスは相互作用に注目する
上記の違いを見てきて分かるのは、オブジェクト指向はオブジェクトの「構造」を設計するのに適しており、SOAはサービス間の「相互作用」を設計するのに適しているということだ。ソフトウェアアーキテクチャの研究では、アーキテクチャ構成要素の構造よりも、構成要素間の相互作用の記述が重要になることからもなんとなく推測されるように、視点がマクロになればなるほど、構造の複雑さを捨象して、相互作用に注目することが必要となるのかもしれない。逆にミクロアーキテクチャのレベルで相互作用に注目するのは、少しオーバースペックになる。
つまり、オブジェクトとサービスとの性質の違いは、OOとSOAとが対象とする設計規模の違いをそのまま反映していると言えなくもない。
---
さて、いずれにしろ大事なことは、既に広く認知されている「オブジェクト」という概念と、最近注目を集めだした「サービス」という概念とが本質の部分でどのように異なっているのかを、このように考え続けて理解を深めていくことだと思う。
サービスやSOAを考えるにあたっては、以下のようなリソースが参考になる。
・ OASISのSOA参照モデル
・ "Developing in a Service-oriented World" by Gregor Hohpe