0

私が計画しているアーキテクチャ

上の図に示すようなアーキテクチャを Web サイト用に設計する予定です。私は Java でコア プラットフォームを構築しています。これは、DB やその他の高度な処理タスクと通信を行い、モジュールは定義されたインターフェイスを介してコアに接続できます。

モジュールは、フロントエンド Web サイト、電子メール ボックス、管理コンソールなどのようなものであり、PHP、Java、Ruby on Rails などの任意のテクノロジで構築できます。

モジュールとコア間の通信に使用する通信プロトコルを教えてください。プロトコルは、ほとんどの言語が理解し、双方向通信で簡単に処理できるものでなければなりません。

そして、誰かがそのようなアーキテクチャに欠陥を見つけた場合は、優れた拡張性と柔軟性を提供するより良いものを親切に提案してください。

4

2 に答える 2

3

つまり、基本的にこれは SOA のようなアーキテクチャーです。JavaEE および EJB (3+) または Spring フレームワークがすぐに思い浮かびます。

コンポーネント (「モジュール」) は通常、SOAP サービスを介して、フロントエンド、バックエンド、複合サービスの間のオプションのエンタープライズ サービス バス (ESB) と結合されます。

これがあなたのケースにぴったりなのか、それとも単にオーバーサイズなのか...誰にも言えません...

于 2012-07-15T09:46:54.433 に答える
3

Thilo が提案したように、HTTP を使用して Core で REST API を公開します。

複雑さは、従来の Web サービスの RPC (手続き型モデル) と、http 要求 (URI の動詞 GET、POST、PUT、および DELETE をいくつかのヘッダーと本文で補完) を使用する場合により適したリソース モデルとの間のトレードオフにあります。 .

それでも、これにより、柔らかく、保守が容易で、移植可能なディストリビューションが作成されます。すべてのクライアント モジュールは、まったく異なるテクノロジに基づいて構築されている可能性があるため、「その仕事に最適なツール」を使用できます。

キャッシュ、書き換え、負荷分散、ssl などの HTTP の利点は言うまでもありません。

于 2012-07-15T13:08:32.290 に答える