3

Web サービスを既存のアーキテクチャーに導入することによって Web アプリケーションを拡張する場合、またはその逆の場合に、開発者が考えられるアーキテクチャーはありますか? このコンテキストでの主な懸念事項は、データの整合性とセキュリティです。

次の図は、開発者が考えられる 2 つのアプローチを示しています。

シナリオ 1

このアーキテクチャは、すべてのリクエストが個々のサービス層によって処理される必要があることを示しています。したがって、サービス層のみがデータベースと通信し、Web アプリケーションとゲートウェイの両方の要求を満たすことができます。

シナリオ 2

2 番目のアプローチは、Web アプリケーションが DB と直接通信していることを示しています。たとえば、管理者ポータル。その間、DB と通信する外部 Web サービスも存在する可能性があります。このアプローチは、データ整合性違反のシナリオにつながる可能性があります。ただし、既存の Web アプリケーションをリファクタリングして開発者側から Web サービスを呼び出すよりも、外部 Web サービスを導入する方が簡単な場合があります。したがって、Web アプリケーションとゲートウェイの両方を単一の Web サービス レイヤーで処理する代わりに、外部 Web サービスと別の Web アプリケーションを使用することで、長期的な結果について妥協することはできます。これに関する合理的なコメントをいただければ幸いです。

4

3 に答える 3

1

私はいくつかのプロジェクトでこの質問に答えなければなりませんでした。あなたが言及していない3番目のオプションがありますが、これは私のお気に入りです。

オプション 1 - 「永続性およびビジネス ロジック レイヤーとしての Web サービス」の問題は、多くの追加の可動部分が設計に導入されることです。これらの可動部分は高価です。より多くのコードを記述、テスト、および維持する必要があり、多くの場合、Web サービスから独自のアプリケーションを実行するために必要なサービスは、サード パーティの開発者にとって意味のあるものではありません。また、潜在的に重大なパフォーマンスとスケーラビリティのリスクを導入しています。データベースを呼び出す Web サービスを呼び出すと、データベースを呼び出すだけよりもかなり遅くなります。

2 番目のオプション (Web アプリとサービス レイヤー全体でビジネス ロジックを複製する) には、複製に関するすべての問題があります。

私が好むオプションは、ビジネス ロジック レイヤーを別のコンポーネントとして開発し、それを Web アプリと Web サービスの両方で使用することです。各アプリケーションはコンポーネントをライブラリとして使用します。これは、「ライブラリ」チームと「アプリ」チームという別々のチームを持つ必要があることを意味しますが、重複を避け、Web ページをレンダリングする必要があるたびに多数の Web サービスを呼び出すことを回避します。

ビジネス ロジック レイヤーは、データベースの一貫性を確保し、トランザクションを管理するなど、永続性を担当します。ビジネス ロジック レイヤーは Web アプリと Web サービスの両方で共有されるため、このロジックは 1 つのコード ベースに集約され、理想的にはアプリに対して完全に透過的になります。

Web サービスが行うことははるかに少なくなりました。彼らの仕事は、着信リクエストを処理し、それらをビジネス ロジック コンポーネントのメソッド呼び出しに変換し、適切な形式 (XML、JSON) で応答データを返すことです。「粗粒度」のサービス要求を提供し、それらをいくつかのより粒度の細かいビジネス ロジック メソッドにマッピングする場合があります。認証、承認、リクエストのスロットリングなどを処理する場合があります。実際のビジネス ロジックは処理しません。

于 2013-05-29T13:10:17.540 に答える
1

すべてにアクセスできる API を構築できます。つまり、Web アプリケーションは、Ajax/WebSocket を使用して REST/RPC API を介して動作する可能性があります。

すべてが API を通過するため、データの整合性は常に強制されるべきではありません。また、クライアント、API、およびデータベースから明確に分離されます。

これにより、システムの他の部分を壊すことなく、データベースを他のものに置き換えることができます。

于 2013-05-29T09:48:52.613 に答える