BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース SOAの文法 - サービスは動詞か名詞か?

SOAの文法 - サービスは動詞か名詞か?

ブックマーク

原文(投稿日:2009/10/21)へのリンク

Jason Bloomberg氏の最近の投稿 - サービスは動詞か名詞か? - では、サービスは動詞を表現すべきものか、それとも名詞を表現すべきものか、が議論されている。

サービスをどちらのやり方で設計することも可能である。例えば、エンティティサービス、すなわちビジネスエンティティを表現するものとして設計することもできる一方、タスクサービス、つまりあるプロセスにおけるいくつかのステップ、言い換えると動詞、を実装する特定のアクションとして表現することもできる。どちらのアプローチがよいのだろうか?

Jason氏は"名詞"タイプのサービスと"動詞"タイプのサービスの違いを説明するために、審理中の保険契約を承認するサービスを例に使っている。

...オブジェクト指向のアプローチに従うと、いくつかの操作を伴った保険契約オブジェクトを持つことになるだろう。そのオブジェクトは、次のような擬似コードで表されるような保険契約を承認する操作を含む:

myPolicy = new Policy (); ... successOrFailure = myPolicy.approve ();

...確かに、エンティティサービスとしてPolicy Serviceを作成し、それがおおよそ上記の例のように動く承認操作を持つようにすることも可能である。が、1つ基本的な違いがある。サービスは基本的にステートレスであり、インスタンス化するものではない。まず、エンティティサービスがどのようにこの同じ機能性の問題に取り組むかについての擬似コードは以下のようになる:

request to create new policy, specifying create policy operation --> Policy Service --> response with policy number 12345

request to approve policy 12345, specifying approve policy operation --> Policy Service --> response with success or failure

これはサービスを設計するオブジェクト指向のプラクティスを取り入れた典型的なアプローチであるが、Jason氏は以下のことを指摘している。

...上記のエンティティサービスと同様の機能性を提供す別のやり方がある。そこでは、サービスは名詞ではなく動詞を表現していて、それをタスクサービスと呼んでいる。次が、この状況についての擬似コードである:

request to create new policy --> createNewPolicy Service --> response with policy number 12345

request to approve policy 12345 -- > approvePolicy Service --> response with success or failure

この例では、タスクサービスはいかなる操作も持っていないが、むしろそれぞれのサービスの機能性はサービスの文脈から理解できる。そもそも、approvePolicy Serviceが、契約を承認する以外の何かをすることなどあるだろうか?

Jason氏の意見では:

エンティティサービスとタスクサービスの両方によって、アーキテクトが2つの点、一方はレガシーの可能性、もう一方の柔軟なプロセスの要求、を線で結ぶことができるようになる ... エンティティサービスは...基本的なレガシーの可能性を抽象化し、... タスクサービスは基本的なエンティティサービスに属する個々の操作の抽象を表現し、... プロセスサービスは ... 典型的には、タスクサービスを合成したものである。言い換えると、プロセスサービスは、SOBAに対するインターフェースである。ここで、SOBAとは適切に設計されたタスクサービスの合成であり、プロセスの同形性を表すものである。

Jason氏は自身の投稿を以下のような言葉で締めくくっている:

たいてい同様に、アーキテクトはその自由にできる範囲において、いくつかの選択肢を持っていて、しばしばビジネス上の問題に応じてどの選択肢がが適切かを理解する必要がある。これは、"その仕事のための正しい道具"の一例である。もし、ビジネス上の問題がプロセス中心、つまり、合理化の必要性や、保険契約プロセスの最適化のようなものであれば、タスクサービスの合成としてSOBAを実装することで、プロセスの柔軟性が促進されるであろう。ほかの事例において、例えばコールセンターの画面に顧客情報を統合して表示する、というような例においては、ビジネスの問題がプロセス中心というよりはむしろ情報中心である。このような例では、アーキテクトの焦点はエンティティサービスであり、それは、コールセンターのスタッフは、特定の顧客を扱っているのであり、その顧客と柔軟な方法でやりとりすることができなければならないからだ。

Jason氏は彼の投稿の中で、(何度か)SOAとオブジェクト指向の違いについて記述しようと試みているが、投稿自体が、私たちのオブジェクト指向の経験がいかに大きくSOAの理解に影響を与えているかの証拠になっている。定義から始めよう。ウィキペディアによれば:

  • 名詞:言葉の一部で、格変化し、具体的あるいは抽象的な実体を表す。
  • 動詞:言葉の一部で、格変化はしないが、時制、人称、数により語形変化し、実行されるあるいは経験される活動または過程を表す。

Jason氏の"サービスは基本的にステートレスである"という説明に従えば、サービスはエンティティを表現することはできない。彼の例において、Policyサービスはエンティティサービスではなく、むしろいかなる契約における操作(動詞)をサポートするようなメソッドのコレクションである。これはステートレスセッションBean(J2EE)と同様のものであり、それは名詞であるとは言い難いものであろう。結局のところ、サービスは決して名詞ではなく、動詞か動詞のコレクションであり、Jason氏のいうエンティティサービスとタスクサービスの違いは、そのサービスが外部に公開しているメソッドの量のことである。

この記事に星をつける

おすすめ度
スタイル

BT