0

私が取り組んでいる分散プラットフォームの正規データ モデルを定義しようとしています。これは、次のアーキテクチャに基づいています。

  • クライアントに機能を公開する RESTful API ファサード
  • Apache Camel に基づいており、クライアント要求のルーティングと変換に使用される基本的なミドルウェア
  • ミドルウェアによって呼び出される RESTful ビジネス サービス

アイデアは、ファサード層が着信要求を共通の情報モデルに変換できるようにすることです。これは、ヘッダーとペイロードを持つカスタム メッセージの形式を持っています。

  • ヘッダーには、要求されたワークフローにメッセージをルーティングするために、ミドルウェア (Apache Camel) が必要とする情報が含まれている必要があります (基本的に、ファサードは、クライアントからの各着信要求を処理するためにどのビジネス プロセスを呼び出す必要があるかを認識します)。これは、列挙型マップとして、またはカスタム メッセージを表すクラスの一連の属性としてモデル化できます。
  • ペイロードには、着信要求の「ビジネス モデル」を表す適切な Java Bean が含まれている必要があります (TicketOrder または Customer オブジェクトなど)。カスタム メッセージを表すクラスのオブジェクト属性としてモデル化でき、そのメッセージを管理するワークフローに関与する Camel のすべてのプロセッサ/コンバーターは、そのペイロード タイプ (選択された Java Bean) を予期する必要があります。

簡単に言うと、受信リクエストを処理してビジネス サービスにルーティングするために Camel が必要とする関連情報のみを含むミドルウェアのビジネス データ モデルを定義しようとしています。このデータは Java Bean としてモデル化され、ペイロードとしてメッセージに添付されます。メッセージのヘッダーには、Camel にとって意味のあるルーティングの詳細が含まれています。

上記のソリューションをどのように改善しますか？それは良いアプローチであり、十分に柔軟だと思いますか? どうもありがとうございました。

4

1 に答える 1

0

Camel を (軽量) ESB として使用している場合は、それほど心配する必要はないと思います。camel ルート内では、ケースに最も適した形式を維持することができます。いくつかのソリューションでは、複数の形式を並行して実行することもできます (たとえば、Java Bean を使用してビジネス ロジックを実行できますが、XSTL を使用して実行することもできます)。メッセージを XML と XPath に変換して分離を改善し、CBR の処理を​​行います)。

Java Bean モデルを頻繁に使用する必要がある場合は、JSON からモデルを抽出できるプロジェクトを作成することをお勧めします。これにより、このアーティファクトのバージョンを (たとえば Maven を使用して) 制御できるようになります。 Java アプリケーションの正規モデルになります (JSON 要求が大幅に変更される場合は、このプロジェクトを更新する必要があります)。Java データ モデル プロジェクトを作成し、OSGi コンテナーを操作すると、OSGi がさまざまなアプリケーションに対してさまざまなバージョンのモデルを使用できるため、分離のメリットがさらに大きくなります。

よろしく、ルアン

于 2013-08-06T11:40:49.783 に答える