0

OSGi によって促進される高度なモジュール性は、私が取り組んでいる一連の SOA サービスにとって望ましいものです。

各サービスは、バックエンド サービス (ある程度の永続性を含む)、サービス インターフェイス (SOAP/REST など)、およびフロントエンド UI で構成されます。

ネイティブ カーボン製品は、私のサービスがカスタム OSGi カーボン コンポーネントとして作成されるので、うまく適合しているようです。

SOA サービスの実装に WSO2 スタック (DSS、ESB、AS など) を使用する場合と比較して、カスタム OSGi Carbon コンポーネントの長所と短所は何ですか?

回答の要約

この質問は締め切られましたので、これは受け取った回答の要約です。

WSO2 カスタム カーボン コンポーネント (OSGi)ベースの SOA サービスを作成する理由:

  • あなたはWSO2を拡張しています
  • 再利用したいOSGiコンポーネントがすでにある
  • Carbon UI フレームワークを再利用したい

WSO2 製品ベースのSOA サービスを使用する理由

  • Carbon 管理 UI を使用したサービス ライフサイクルの監視と管理の容易さ
  • SOA 機能の開発が容易 (ESB および DS 機能に Java コードは不要)

たとえば、WSO2 製品ベースのサービスとして作成されたバックエンド サービスと、WSO2 カスタム カーボン コンポーネントとして作成されたフロント エンドなど、アプローチの組み合わせを使用できると思いますか?

4

2 に答える 2

1

カスタム OSGi Carbon コンポーネント

あなたのサービスは OSGi バンドルとして実装されていると思います。したがって、サービス制御は OSGI レベルで行うことができます。炭素管理サービスを見ると、これらは OSgi サービスであり、OSgi レベルで制御できます。

SOA サービスを実装するための WSO2 スタック (DSS、ESB、AS など) の使用

ここで、wso2 スタックは、既存のサービス (例: esb プロキシ) のインターフェイスを実装するか、既存のデータ層を外部に公開します (例: DS) または、Spring などの一般的なパターンである独自のサービスを実装できます。 /*.aar に展開して (例: AS)

私の理解では、OSGI サービスと wso2 stack を使用して作成しようとするサービスは、どちらも大きな問題なく動作するはずです。

しかし、監視に関しては、OSGiコマンドを使用する必要があるため、OSGiサービスはそれほど簡単ではないと思います..

于 2013-06-10T14:12:43.253 に答える
1

Carbon 管理コンソール自体でサービスの UI を提供している場合、つまり製品の機能を拡張/強化している場合は、OSGi バンドルを作成する道をたどる必要があります。例: ユーザーが多くの異なるパラメーターを受け入れる管理コンソールを介して新しいスロットリング ポリシーを構成できるようにする新しいスロットリング アルゴリズムを追加します。

ユーザーレベルのアプリケーションで使用される機能を開発している場合は、OSGi パスを使用する必要はありません。プラットフォームを拡張/変更しない限り、OSGi について何も知る必要はありません。エンド ユーザーの場合、ESB を構成するときに、シナリオを既存のメディエーターで構成できない場合を除き、カスタム コードを記述する必要はありません。したがって、ESB と DSS は、新しいサービスを開発する必要がある場合、(エンド ユーザー向けの) 構成駆動型のアプローチに従います。

于 2013-06-10T14:13:41.700 に答える