5

着手する必要がある特定のプロジェクトがあり、最初の一歩を踏み出す前にマスターからのガイダンスが必要です.

いくつかの外部ソース (つまり、ファイル、XML-RPC、Web サービスなど) から入力を受け取り、それを何らかの方法で処理し、ルールを適用し、他の外部システムと通信し (おそらく)、アクセスするアプリケーションがいくつかあります。データベース（おそらく）にアクセスしてから、応答を返します。クライアント間のすべての小さな違いに対応するために、同じアプリケーションのさまざまなバージョンを維持しています。（はい、はい、知っています。それはひどいです、それが私がそれを修正したい理由です...）

私が考えているのは、構成を通じてさまざまなコンポーネントを接続し、ビジネス ルールによって情報の流れを管理する、コンポーネント ベースのアーキテクチャを構築することです。本質的に、各クライアントに異なる構成セットを持つプログラムのコピーを提供できる必要があります。私は、VB スタイルのドラッグ アンド ドロップ方式でシステムを接続できる GUI ベースのアプリケーションを夢見ています。

さて、上記は確かに以前に行われたことのように聞こえます...そして私は車輪を再発明したくありません. 問題は、上記が大量のリアルタイム トランザクションを処理できる必要があることです。そのため、BPEL のようなものが正しい選択になるかどうかはわかりません。

ホイールを丸くする前に、何か推奨事項はありますか?

4

1 に答える 1

1

私はあなたのアプリケーションのために非常に単純なXML方言を書きます。要素タイプを最小限に抑え、class="my.class.name'属性を使用して実行時に正しいクラスインスタンスを構築します。これにより、たとえば、3つの実装（たとえば、、）を持つ要素を簡単に作成 <source class="my.package.XmlRpc">でき<source class="my.package.LocalFile">ます<source class="my.package.WebService">。各要素タイプは、インスタンス化されると、XMLコンテンツを読み取って、正しく構成するために必要な追加データを見つける必要があります。

使いやすいXML解析ライブラリ（私はJDomをお勧めします）がたくさんあり、XMLの表示と編集のためのツールサポートがたくさんあります。XMLは、文書化、操作、およびGUIへのラップが簡単です。

つまり、各コンポーネントは要素タイプを取得し、それらの特定の実装に依存する構成は要素内に埋め込まれます。単純な配線がある場合（特定のコンポーネントインスタンスは1つの場所でのみ使用されます）、包含を回避できます。複雑な配線がある場合（たとえば、複数の場所でコンポーネントインスタンスを再利用する必要がある場合、たとえば、フィルターを再利用したり、中間結果を計算したりする場合）、最初にコンポーネントインスタンスを定義し、次にこれらへの参照から配線を構築します。インスタンス。

私は基本的に、Antビルドファイルのようなものを提唱しており、物事を可能な限りシンプルに保つために取り組んでいます。

于 2012-09-12T08:56:12.923 に答える