2

次の例を考えてみましょう

@Remote
public interface RegistrationService {
    public String register();
    public void unregister(String id);
    public void heartbeat(String id);
}

@Stateless
@Remote(RegistrationService.class)
public class RegistrationServiceBean implements RegistrationService {
    /* ... */
}

私はインターフェースを持っています、としましょうRegistrationService。これにより、リモート クライアントは自分自身をアプリケーションに登録できます。定期的にheartbeat()を呼び出すことで、まだ生きていることを知らせます。

EJB とそのインターフェースを文書化する正しい方法はどれですか?

例えば：

インターフェース

  1. このインターフェイスのユーザーは、自分自身をアプリケーションに登録できます。その後、アプリケーションは何かを再計算して、登録されているすべてのクライアントに均等に分配します。（これには、他のクラス、たとえば再計算クラスに関する知識が含まれます）
  2. インターフェイスのユーザーは、自分自身を登録し、サーバーがまだ接続されている場合にサーバーに通知できます。実装では、この情報を使用して、登録されたクライアントの量に基づいて下層のシステムにタスクを発行します(これには他のクラスに関する知識は含まれませんが、アプリケーションの観点からはそれほど正確ではありません)。

クラス

  1. この RegistrationService の実装は、クライアントが登録、登録解除、またはハートビートの期限が切れたときに、RecalculationClass で再計算を発行します。これは、クライアント間でデータを均等に分散する必要があるため必要です。

どんな考えでも大歓迎です。ありがとう。

スヴェン

4

2 に答える 2

2

インターフェース javadoc には、実装に関する情報が含まれていてはなりません。インターフェイスは、どのようにではなく、何についてのものです。

たとえば、実装がインターフェースのメソッドへの呼び出しを完全に無視することは有効です。つまり、空のメソッドがあります。

javadoc は次のように表示されますNotifies that the specified application is still alive。実装がその情報をどうするかは実装次第です。

于 2012-10-23T06:34:54.967 に答える
0

クライアントにとってどの情報が重要かによると思います。再計算がユーザーに完全に見えない場合は、インターフェースで文書化する必要はないかもしれません。クライアントが再計算の詳細を別の方法で確認できる場合は、それをここで示す必要があります。これにより、ユーザーはどのようなやり取りが発生するかを知ることができます。再計算が完全に内部的なものであり、クライアントが気付かないうちに変更できる場合は、インターフェイスの説明に含める必要はなく、含めるべきではありません。

于 2012-10-23T06:38:00.787 に答える