EGL での SOA サポート

EGL でのサービス指向アーキテクチャー (SOA) に対する 2 種類のサポートは、サービス開発とサービス・アクセスです。

サービス開発

EGL では、サービス開発時に次のようなサービス・パーツを最初にコーディングします。
Service MyServicePart
   value STRING = "Hello ";
   
   function myEcho(myString STRING IN) returns (STRING)
      return (value = myString);
   end
end

サービス・パーツの内容はサービス実装です。 この場合、実装は「world」などの入力文字列を受け入れ、「Hello」とこの入力文字列を連結したものをリクエスターに返します。サービス・リクエスターがさまざまな関数 (サービス・オペレーション) にアクセスできるように設定できます。

サービス・パーツを作成するときに、サービス・パーツのデプロイ方法を指定します。サービス・パーツを次のいずれかのサービスとしてデプロイできます。
EGL サービス
EGL サービスは、EGL 固有のバイナリー・フォーマットでデータを交換します。

さまざまな種類の EGL コードから EGL サービスに比較的高速にアクセスできます。ただし EGL サービスは Web サービスではなく、別の言語で作成されたコードからはアクセスできません。

EGL REST-RPC サービス
EGL REST-RPC サービスは、EGL 生成の Web ベースのリクエスターからアクセスできます。データは常に JSON フォーマットであり、HEX、BLOB、および CLOB データを含めることはできません。

EGL REST-RPC サービス・アクセスでは常に POST メソッドが使用されますが、リクエスターに対してはその詳細が隠蔽されます。他の言語で作成されたロジックから EGL REST-RPC サービスにアクセスするときに役立つその他の詳細については、『EGL REST-RPC メッセージ構造』を参照してください。

Rich UI アプリケーションでは、サービスによって返された有効数字が 15 桁を超えるすべての数値データが、EGL ランタイム・コードによって丸められます。JSON が EGL 生成 Java™ コードに返されるときには、丸めは行われません。

SOAP サービス
SOAP サービスは従来型 Web サービスであり、あらゆる言語で作成されたコードからアクセスできます。

EGL 生成のサービスへのアクセスは常に、RESTful スタイルではなく RPC スタイルに準拠しています。パラメーターと戻り値により、交換されるデータが識別されます。サービスへのアクセスには、パス変数や照会パラメーターは使用されません。

サービス・アクセスのコード開発

サービス・パーツを含むあらゆる EGL 論理パーツは、サービス・リクエスターとして動作することができます。 以下の種類のサービスにアクセスできます。
  • EGL サービス
  • EGL REST-RPC サービス
  • SOAP サービス (EGL 生成であるかどうかは関係ありません)
  • IBM® i サービス・プログラム
  • ほとんどの場合 REST スタイルに準拠するサード・パーティー REST サービス 以下のバリエーションがサポートされます。
    • 一部の REST サービスは、リソースの作成以外のタスクに POST 要求を使用します。POST 要求を使用してサード・パーティー REST サービスにアクセスすると、ビジネス・データが送信されないことがあります。
    • 一部の REST サービスでは、削除するリソースを識別するために、URI に依存することなく、DELETE 要求に表現 (ビジネス・データ) を組み込む必要があります。 EGL では、DELETE 要求の表現が必要な REST サービスのアクセスをサポートしますが、この必要のない REST サービスのアクセスもサポートします。
サービス・アクセスには、通常、次のステップが含まれます。
  1. サービス・バインディング (サービスへのアクセスに必要な詳細) を指定します。サービス・バインディングは、リクエスターまたは EGL デプロイメント記述子に指定できます。可能な場合はデプロイメント記述子を使用してください。これは、構成担当者がリクエスターを更新および再生成せずに、サービス・バインディングを更新できるためです。
  2. このサービスを基に、インターフェース・パーツを作成します。インターフェース・パーツには、関数プロトタイプ が含まれています。これは、アクセス可能な各関数のパラメーターと戻り値の型を指定する定義です。インターフェース・パーツを作成するか、またはワークベンチを使用して EGL サービス・パーツまたは WSDL ファイルからインターフェース・パーツを自動的に作成することができます。

    EGL で作成されたサービスにアクセスするときには、インターフェース・パーツを作成する必要はありません。ただし、サービス・パーツをインターフェース・パーツのように使用できます。

  3. インターフェース・パーツが型定義である変数を宣言します。 例えばインターフェース・パーツが IMyService、変数が myService、デプロイメント記述子項目も IMyService の場合、変数宣言は次のようになります。
    myService IMyService{};

サービスに送信されるデータまたはサービスから返されるデータのタイプについて詳しくは、『サービス・アクセスのプロトタイプ』を参照してください。

EGL サービス・パーツをインターフェース・パーツとして使用できますが、ほとんどの場合は個別のインターフェース・パーツを使用してください。例えば、サービスがよく変更されるかまたは機密の場合、サービス実装を他の開発者に配布しないようにすることがあります。ただし、Rich UI アプリケーションから専用サービスにアクセスするときにはサービス・パーツをインターフェース・パーツとして使用する必要があります。これについては、『Rich UI でのサービス・アクセス』を参照してください。

Web サービスのデプロイメント

すべての EGL Web サービスのデプロイのためのランタイム・アーキテクチャーには、同じパターン (生成されたコードまたはランタイム・コードが、リクエスターとサービスの間の中間コードとして機能する) があります。この中間コードによって、サービス・メッセージのテキスト・ベースのフォーマットと、サービスに必要なバイナリー・フォーマットの間でデータが変換されます。

以下に、各デプロイメントの概要を示します。
  • EGL REST-RPC サービスを生成すると、一連の Java クラスが出力されます。デプロイメント記述子を生成またはデプロイすると、サービス・ロケーションを指定する XML ファイルが出力に組み込まれます。

    ランタイム・プラットフォームは、Java EE に準拠するアプリケーション・サーバーです。EGL ランタイム・コードは XML ファイルを読み取り、サービスを呼び出し、リクエスターとサービスの間の中間コードとして機能します。

  • Java に基づく SOAP サービスを生成すると、一連の Java クラスが出力されます。デプロイメント記述子を生成またはデプロイメントすると、サービス・ラッパー と呼ばれる Java クラスが出力に組み込まれます。このサービス・ラッパーは、EGL 生成の出力とは異なります。これについては『Java ラッパーの生成』で説明します。 ランタイム・プラットフォームは、Java EE に準拠するアプリケーション・サーバーです。アプリケーション・サーバーがサービス・ラッパーを呼び出し、次にサービス・ラッパーがサービスを呼び出し、サービス・ラッパーがリクエスターとサービスの間を中継します。サービス・ラッパーとサービスは、相互にローカルです。
  • IBM i 向けの COBOL ベースの SOAP サービスを生成すると、出力は COBOL プログラムになります。デプロイメント記述子を生成またはデプロイすると、EGL 生成のサービス・ラッパー (Java クラス) が出力に組み込まれます。
    この状況は Java ベースの SOAP サービスに似ていますが、サービス・ラッパーはサービスに対してリモートです。次の 2 つのランタイム・プラットフォームがあります。
    • Java EE に準拠したアプリケーション・サーバーがローカル・サービス・ラッパーを呼び出すと、このサービス・ラッパーはリクエスターと IBM i の EGL COBOL ランタイム・コードの間を中継します。
    • インストールされている IBM i によって EGL COBOL ランタイム・コードが実行されます。ランタイム・コードにはキャッチャー・プログラム が含まれています。これは、Java と COBOL の間のデータ変換を処理するロジックです。

    サービス・ラッパーは Java400 または Java400J2C プロトコルを使用してリモート・キャッチャー・プログラムと通信します。キャッチャー・プログラムはサービスを呼び出し、サービス・ラッパーとサービスの間を中継します。

  • COBOL for CICS® に基づく SOAP サービスを生成すると、出力は COBOL プログラムになります。 デプロイメント記述子を生成またはデプロイすると、CICS で使用するための 2 つ目の EGL 生成 COBOL プログラム (サービス・ラッパー) が出力されます。デプロイメント記述子からのもう 1 つの出力は、WSBIND ファイルです。
    ランタイム・プラットフォームは CICS で、以下のアクションを実行します。
    • WSBIND ファイルを使用して SOAP エンベロープ・コンテンツをバイナリー・フォーマットに変換します。
    • サービス・ラッパーを呼び出します。サービス・ラッパーは、リクエスターとサービスの間の中間コードとして機能します。

    サービス・ラッパーとサービスは、相互にローカルです。

サービス・アクセス

EGL 生成のリクエスターからのサービス・アクセスには、一貫性のあるパターンがあります。これは、プロキシーが EGL 生成のリクエスターとサービスの間を中継するというパターンです。プロキシーにより、リクエスターで使用されるフォーマットとサービスに必要なフォーマットの間でデータが変換されます。ただし、EGL サービスがリクエスターに対してローカルの場合はプロキシーは使用されません。

サービス・タイプ別の詳細情報を次の表に示します。

要求されるサービスの特性 デプロイされるリクエスターの特性 プロキシーの特性
専用 EGL JavaScript が組み込まれた HTML ファイル プロキシーは EGL ランタイム・コードに入っており、HTTP 要求を使用せずにローカル環境でサービスを呼び出します。
ローカル EGL EGL 生成の Java コード プロキシーが使用されていません。
EGL 生成の COBOL プログラム
リモート EGL EGL 生成の Java コード プロキシーは EGL ランタイム・コードにあります。
EGL 生成の COBOL プログラム アクセスはサポートされていません。
REST または EGL REST-RPC EGL 生成の Java コード、または JavaScript が組み込まれた HTML ファイル プロキシーは EGL ランタイム・コードにあります。
EGL 生成の COBOL プログラム アクセスはサポートされていません。
SOAP EGL 生成の Java コード、または JavaScript が組み込まれており、Java EE に完全に準拠しているアプリケーション・サーバー (IBM WebSphere® Application Server など) にデプロイされている HTML ファイル。 プロキシーは、リクエスター固有のデプロイメント記述子から生成された Java クラスです。
EGL 生成の Java コード、または JavaScript が組み込まれており、その他のプラットフォームにデプロイされている HTML ファイル プロキシーは EGL ランタイム・コードにあります。
EGL 生成の COBOL プログラム プロキシーは、リクエスター固有のデプロイメント記述子から生成された COBOL プログラムです。

サービス・アクセスのもう 1 つの側面として、サービス・バインディングの詳細情報が格納されている場所があります。 CICS プログラム以外の EGL 生成のすべてのリクエスターの場合、リクエスター固有のデプロイメント記述子から生成され、リクエスターにデプロイされる XML ファイルにその詳細情報が記述されます。CICS プログラムの場合、詳細情報はプログラム自体に生成されます。

EGL 生成の COBOL プログラムが IBM i にデプロイされ、SOAP サービスにアクセスするときには、EGL 生成の Java と COBOL コードの両方が使用されます。この影響を理解するため、以下のランタイム・イベントに注意してください。
  1. EGL 生成のコードが EGL 生成のローカル・プロキシーを呼び出します。
  2. プロキシーが EGL COBOL ランタイム・コード、つまり COBOL と Java の間のデータ変換を処理するキャッチャー・プログラムを呼び出します。
  3. キャッチャー・プログラムが Java Native Interface (JNI) を使用して EGL Java ランタイム・コードを呼び出します。このランタイム・コードは、IBM i 上の Java 仮想マシン (JVM) で実行されます。
  4. EGL Java ランタイム・コードは、SOAP サービスにローカルまたはリモートでアクセスします。

プロキシーの初回呼び出しには時間がかかります。これは、クラスパスのすべての JAR ファイルを含む EGL Java ランタイム・コードがロードされるためです。このロードは、初回呼び出し時および IBM i によりメモリーから JVM がアンロードされた後でのみ実行されます。

Web 上でのセキュリティー

Java ランタイム・プロパティーは、EGL REST-RPC サービスによって返される例外に、提供可能な最大レベルの詳細情報を含めるかどうかを指定します。『Java ランタイム・プロパティーの説明』を参照してください。特に、egl.service.rest.exception.debug の項目は、EGL ランタイム・コードのバージョン 8.5 以上に影響していました。

WS-Addressing と WS-Security のサポート

EGL 生成の SOAP サービスまたは EGL 生成の SOAP サービス・リクエスターを IBM WebSphere Application Server にデプロイする場合は、そのアプリケーション・サーバーの WS-Addressing 機能と WS-Security 機能を使用できます。そのサービスまたはサービス・リクエスターは、JAX-RPC ではなく JAX-WS に依拠している必要があります (『JAX-WS と JAX-RPC のための EGL サポート』を参照してください)。

追加情報については、以下のいずれかのサイトにアクセスして、「WS-Addressing」または「WS-Security」を検索してください。

プロトコル

Web サービスへのアクセスでは常に HTTP プロトコルが使用されますが、 COBOL Web サービスへのアクセスやその他のケースでは他のプロトコルが使用されます。詳細については、『共用可能プロトコル』を参照してください。


フィードバック