以下の実例は、EGL でのサービスおよび関連インターフェースの開発用として推奨されます。
- インターフェースを設計ツールとして使用する
- EGL サービスでコード化しておきたい機能を記述するインターフェースを 1 つ以上作成できます。
これらのインターフェースの完成後、ユーザーまたは他の人員がサービスをコーディングすることができます。
これをインターフェースの実装 と呼んでいます。
この第一義は、インターフェースで記述されるすべての関数がサービスに含まれることです。
これらのインターフェースにより、サービスが満たさなければならない規約の種類を提供します。
インターフェースをこのように使用すると、以下の利点が得られます。
- 組織の人員が、サービス開発の開始前に必要な操作について明確に認識するために役立ちます。
- サービス・コードの開発中に、開発者はクライアント・アプリケーションを終了することができます。
これは、クライアント・コードが、サービス・パーツではなく、インターフェース・パーツに基づく変数と相互作用できるためです。
- サービス・パーツまたはインターフェース・パーツを参照する不必要な宣言を回避する
- 特に別の方法を実行する理由がない限り、サービス・バインディング・ライブラリーを使用して、
サービス・パーツまたはインターフェース・パーツを参照する every 変数を定義します。
通常、これらの種類の変数を、他の場所で宣言する、関数に渡す、関数から戻す、
または特定のサービスを参照するために複数を宣言する必要はありません。
EGL ライブラリー内の各変数は、実行単位に対してグローバルです。
- サービス・パーツおよびインターフェース・パーツの異なる集合ごとに、
複数のサービス・バインディング・ライブラリーを作成する
- バインド済み変数を小さな論理集合に編成して、新規パーツが追加される際に、
ライブラリーの再生成の必要性を回避します。
- @EGLBinding および @WebBinding プロパティー内の debugImpl フィールドに値を割り当てる
(サービス・バインディング・ライブラリーで使用される)
- プロパティー・フィールド debugImpl は、サービスが開発時スタブにすぎなくても、
デバッグ時にアクセスされるサービス・パーツを識別します。
パーツが指定されない場合、デバッグ・セッションはそのサービスをステップスルーしないで、
デプロイ済みサービスを呼び出します。
ただし、この場合にランタイム・サービスが不在であると、
ServiceInvocationException 型の例外がスローされます。
- 指定された関数仮パラメーターの値を戻す必要がない場合、IN 修飾子を使用して時間および帯域幅を節約する
- IN 修飾子を使用すると、実行時処理に必要な時間が削減され、
サービスからクライアントへ返信しなければならないデータ量が削減されます。
- サービス・パーツにおけるグローバル変数の宣言を回避する
- サービス内のすべての変数を関数仮パラメーターまたは他のローカル変数として宣言する場合、
サービスをどこにデプロイしても、サービスの振る舞いには一貫性があります。