私は新しいプロジェクト チームに移動し、コードベースを調べているときに、チームが多数のローカル Web サービスを作成し、同じアプリケーション内の他の Web ページでサーバー コードによって呼び出されることを発見しました。
ローカル Web サービスは、クライアントまたは他の個別のアプリケーションからアクセスするものだと思っていたので、このアーキテクチャにはやや困惑しています。
しかし、私たちのアプリケーションの他のサーバー コードからローカル Web サービスと通信することによって、メッセージを XML/Soap にラップし、html スタックを介してサービスに戻り、再び戻るという困難を経験しているように思えます。かなりの時間が追加され、アプリケーションの速度が低下します。
これに関する私の懸念を新しい同僚に伝えましたが、少し議論がありました. 他の人がこのアプローチについてどう思っているのか疑問に思ったのですが、心配するのは正しいですか?
ありがとう
ミッキー
ローカル Web サービスを使用することは悪いことではありません。特定のアプリケーションのモジュール化 (結合の増加、結合の減少) を高めることができます。ターゲット コードを Web サービスに移動することは、共有ライブラリ (DLL、.so など) を作成するようなものと考えることができ、さまざまなプロセスから簡単に呼び出すことができるという重要な利点があります。これは、RPC や DCOM を取得して頭痛を軽減するようなものです。呼び出し規則を明確にしておく限り、ほぼすべてが Web サービス呼び出しで構成されるアプリケーションを作成しても問題はありません。マッシュアップの応用版です。
現在、夜の Web サービスは 1 つのクライアントから呼び出されますが、将来的には別のクライアントが呼び出される可能性があります。その観点から、私はアプリケーション パーティションがアーキテクチャ的に意味があるかどうかについてもっと関心があります。つまり、それは適切な関心の分離ですか? もちろん、パフォーマンスは別の考慮事項です。
チームがアプリケーション内で Web サービス呼び出しを実装したことに少し驚いたのは正しいと思います。なぜオーバーヘッドを支払うのでしょうか?
ただし、本当の問題は、必ずしも Web サービスの呼び出しではありません。これは正当な手法です。より大きな問題は、あなたの責任分担にある可能性があります。Web サービス ハンドラーは、標準ページの UI に似ています。つまり、外部との対話を処理します。受け取った引数をビジネス ロジック オブジェクトに渡す必要があります。
個別のビジネス ロジック オブジェクトの利点は多岐にわたります。最も顕著なのは、単体テストが容易になることと、コード内から同じ関数を直接呼び出すことができることです。したがって、Web サービス呼び出しのオーバーヘッドが発生するのではなく、ロジックを Web サービスからビジネス ロジック オブジェクトにリファクタリングし、オブジェクトを直接呼び出す必要があります。