0

私は、SOAの使用を強調する将来のIT開発のための戦略を読んでいます。私は、SOAがウェブ上のいくつかの記事から落ちた流行語であることを知っ ています。

プログラマーとして、SOAが他の分散コンピューティングアーキテクチャよりも柔軟であると考えられている理由を理解したいと思います。

  • SOAは、バス上で公開されているサービスに基づいています。ただし、すべてのサービスコンシューマーは、サービスを利用するために、サービスの重要性/セマンティクスを認識している必要があります。したがって、新しいサービスを利用するには、クライアントを変更する必要があります。

    たとえば、グーグルマップが交通情報を公開している場合、私のアプリは何かが公開されていること、どのような形式であるかなどを認識しますが、ルートプランナーがそれらのデータを利用する機能を魔法のように獲得することはありません。

  • SOAは契約に基づいています。契約は、コンピューターによって自動的にチェックできる、明確に定義された（事前、事後）条件以上のものですか？

    （関数が入力をチェックし、ユーザードキュメントに期待する内容を文書化するのと同じように、検証を関数の外に移動するだけです。）

    双方が再び契約を履行しなければならない場合、それはどのように柔軟性を改善しますか？公開されたからといって、データが自動的に満たされるわけではありません。契約が変更された場合は、クライアントも変更する必要があります。

4

1 に答える 1

2

私はあなたの質問で表現された多くのアイデアに同意しません。

私はSOAが流行語ではないと思います。多くの人が売り手に引き取られて、商品の請求書を売った時がありました。その時は終わった。それがあなたの言いたいことなら、私はそれを受け入れます。しかし、SOAは健在です。

私はSOAにバスが必要であることに同意しません。重要なのは、バスではなく、ビジネス上の問題をサービスに分解することです。

顧客がサービスセマンティクスを使用するためにそれらを認識しなければならないというあなたの声明は、すべての分散コンポーネントに当てはまります。

すべての分散コンポーネントは契約に基づいています。インターフェイスは、どのように表現されていても、コントラクトです。「これらのパラメーターを渡してください。この値を返すか、この関数を実行することを約束します。」契約が変更された場合、クライアントも変更する必要があります。これは、独自のコードと分散コンポーネントにも当てはまります。

インターネットの有線プロトコルであるHTTPを使用する分散コンポーネントに基づいているため、SOAが勝者だと思います。シンプルでオープンであり、CORBA、RMI、COMなどの他のテクノロジーに比べて大きな利点です。

これは、より高いレベルの抽象化を表しており、開発者にとって常に良いことです。APIが明確に定義され、安定していれば、複雑さの心配から解放されます。彼らは、ビジネス上の問題にうまく対応するサービスのメニューから選択し、新しいソリューションを作成するためにそれらを調整することに集中できます。

しかし、それに魔法はありません。APIの設計は難しいです。SOAを選択してコントラクトを使用しても、それがうまくいくとは限りません。

「コントラクトファースト」がSOAPサービスを開発するための他のアプローチよりも優れている点の1つは、「ダックタイピング」が可能になることです。スキーマからWSDLを生成する場合は、バックグラウンドでサービスによって使用されるオブジェクトモデルへの変更からユーザーを切り離します。オブジェクトモデルからスキーマとWSDLを生成する場合、この2つは緊密に結合されています。SpringのWebサービスサイトでは、このトピックについてよく議論されています。

于 2013-01-03T10:28:33.940 に答える