.NET の相互運用のためにプロキシを作成するか COBOL を編集するか

COBOL 型が、相互運用する マネージ 非 COBOL と互換性がない場合、既存の COBOL を再設計するか、既存の COBOL と非 COBOL 間のインターフェイスとして機能するプロキシ COBOL クラスを作成できます。

この 2 つのオプションには次の事項が関連します。

• 既存の COBOL コードの編集

  型を操作して、連絡節で互換性のある型を使用するようにします。EXIT または GOBACK のポイントが複数ある場合は、新しい連絡節にデータを戻すように COBOL の再設計が必要となる場合があります。あるいは、1 つ以上のメソッドを含むオブジェクト指向 COBOL クラスとして COBOL を再設計することもできます。ただし、使用するメソッドが増えるほど、再設計の手間が増えます。

  COBOL モジュールを IL にコンパイルします。これにより、モジュールおよびそのエントリ ポイントがインスタンス メソッドとして公開されます。これにより、.NET COBOL コードで、MicroFocus.COBOL.RuntimeServices ネームスペース (Micro Focus Runtime (Interop RuntimeServices) アセンブリ内) の Interop クラスの CobLoad メソッドを使用してプログラムのインスタンスを取得し、他のメソッドと同様に COBOL メソッドを直接呼び出すことができます。

• プロキシ COBOL クラスの作成

  .NET COBOL でプロキシ クラスを作成すると、既存の COBOL と非 COBOL マネージ コード間に薄い層が追加されます。このクラスは、オブジェクトおよびプロパティを使用する マネージ アプリケーションと COBOL との間のインターフェイスとなります。これには、標準 COBOL の CALL "program" USING… 構文を使用します。

  既存の COBOL を IL に再コンパイルすると、多くの場合 (特に非 UI COBOL サブルーチンの場合)、変更はごくわずかで済みます。

  .NET COBOL コードで、プロキシ クラスを呼び出して、そこから元の COBOL を呼び出すことができます。

COBOL を直接呼び出す利点は次のとおりです。

• プロキシ層がないため、パフォーマンスが若干改善される可能性があります。
• 管理するモジュールが少なくて済みます。
• プロキシ クラスを作成する必要がありません。

プロキシ クラスを使用する利点は次のとおりです。

• 同じ COBOL ソースを マネージ アプリケーションと従来のアプリケーションの両方で使用できるため、その他のプラットフォームで使用可能になります。
• 管理するアーキテクチャが明瞭かつ簡単になります。
• 元の COBOL コードの連絡節を変更したり、オブジェクトのプロパティとして渡されるデータを抽出するコードを追加したりする必要がありません。
• プロキシ クラスでインターフェイスを実装する場合、標準のコーディング パターンを適用できます。つまり、実装と定義は別になります。