1

私はこれらのバンドルを持っています：

  • 通信サービスは通信サービスを提供します。
  • 通信Comm Serviceは、を使用してメッセージを送受信する通信バンドルです。
  • ポーリングは、マルチキャストモードでポーリングメッセージを送信します。

Communicationバンドルは飽和状態であり、私のアプローチは特定のアクションのために他のバンドルを実装することです-ポーリングバンドルはポーリングの送信を担当し、ポストカードバンドルはポストカードの送信などを担当します（ほんの一部の例）。

バンドルがポーリング/ポストカード/メッセージの送信作業を委任する必要がある場合に、サービスをバンドルComm Serviceの入力パラメーターとして渡すアプローチはありますか？PollCommunication

以下のスニペットは正しいですか？

通信バンドルコード：

PollBundle p = new PollBundleImpl();
p.sendPoll(String pollQuestion, CommService cs);

Pollまたは、 /PostcardバンドルComm Serviceが独自にサービスを取得できるようにするためのより良いアプローチですか？

4

3 に答える 3

8

バンドル間でサービス オブジェクトを渡してはなりません。これを行うと、OSGi フレームワークは、どのバンドルがサービスを認識できるかを制御できなくなります。そのため、そのサービスを廃止する必要があるときに、バンドルの完全なセットに通知できません。

したがって、Poll バンドルは自身の CommService を見つける必要があります。これにはいくつかの方法があります。OSGi 仕様のDeclarative Servicesを使用することを強くお勧めします。bnd アノテーションと組み合わせて使用​​すると、Poll バンドルのコードを次のように記述できます。

@Component
public class Polling {

    private CommService commService;

    @Reference
    public void setCommService(CommService cs) {
        this.commService = cs;
    }

    public void someMethodThatUsesCommService() {
         sendPoll(cs);
         // ...
    }
}

Jacek Laskowski の回答で説明されている Blueprint ソリューションよりもこのアプローチをお勧めします。これは、冗長でタイプセーフでない XML ファイルを記述する必要がなく、OSGi サービスのライフサイクルに一致するより優れたライフサイクル特性を備えているためです。ただし、Declarative Services と Blueprint の両方のアプローチは、低レベルの OSGi API (例: ) をいじるよりも確実に安全ServiceTrackerですServiceListener。

于 2013-03-08T20:04:25.793 に答える
2

依存性注入を利用してバンドルを分離することを強くお勧めします（ OSGi Service Platform Enterprise仕様のブループリントコンテナー仕様をOSGi Blueprint参照してください。ただし、V5リリース用であることに注意してください）。

この仕様では、個別のxmlファイルを使用してバンドルの依存関係を宣言します- （デフォルトですが、ヘッダーOSGI-INF/blueprint/*.xmlで変更できます）。Bundle-Blueprint

したがって、あなたの場合Comm Service、サービスがバンドルの依存関係であるバンドルを開発しますCommunication。また、サービスを登録してバンドルの依存関係になることができるように、同じサービスインターフェイスPollのバンドルも存在する可能性があります。PostcardCommunication

このような構成では、バンドル/サービスCommunicationを渡すのはバンドルではありませんが、初期化中にとバンドルはサービスの依存関係を取得します。Comm ServicePollPostcardComm Service

Pollバンドルの架空のブループリント構成は次のとおりです。

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
  <bean id="PollSenderBean" class="pl.japila.osgi.poll.PollSender">
    <argument ref="commService" />
  </bean>
  <service id="PollSenderBeanService" ref="PollSenderBean" 
           interface="pl.japila.osgi.Sender">
    <service-properties>
      <entry key="type" value="poll" />
    </service-properties>
  </service>
  <reference id="commService" interface="pl.japila.osgi.comm.CommService" />
</blueprint>

Postcardバンドルも同様です。このようなクエリが必要な場合に特定のサービスを利用できるようにentry、の値に注意してください。poll

バンドルのブループリント構成はCommunication次のようになります。

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
  <reference-list activation="lazy" member-type="service-object"
                  id="Sender" interface="pl.japila.osgi.Sender" />
</blueprint>

ソリューションを研究および学習するには、仕様およびおそらくApacheAriesブループリントモジュールを参照してください。

于 2013-03-08T17:54:33.960 に答える
1

私が言うようにCommService、異なる呼び出しで異なるものを使用する必要がない限り、それ自体を見つけましょう。 p.sendPoll(String pollQuestion..)PollBundleCommService

基本的にこれは結合を減らします。PollBundleあなたは投票を送ることについて知る必要があるだけです。これは実際にはアーキテクチャによって異なりますが、一般に、移動する必要のあるオブジェクトが少なく、インターフェイスが単純であるほど優れています。

于 2013-03-08T16:56:15.557 に答える