EGL での SOA サポート
EGL でのサービス指向アーキテクチャー (SOA) に対する 2 種類のサポートは、サービス開発とサービス・アクセスです。
サービス開発
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 REST-RPC サービス
- SOAP サービス (EGL 生成であるかどうかは関係ありません)
- IBM® i サービス・プログラム
- ほとんどの場合 REST スタイルに準拠するサード・パーティー REST サービス
以下のバリエーションがサポートされます。
- 一部の REST サービスは、リソースの作成以外のタスクに POST 要求を使用します。POST 要求を使用してサード・パーティー REST サービスにアクセスすると、ビジネス・データが送信されないことがあります。
- 一部の REST サービスでは、削除するリソースを識別するために、URI に依存することなく、DELETE 要求に表現 (ビジネス・データ) を組み込む必要があります。 EGL では、DELETE 要求の表現が必要な REST サービスのアクセスをサポートしますが、この必要のない REST サービスのアクセスもサポートします。
- サービス・バインディング (サービスへのアクセスに必要な詳細) を指定します。サービス・バインディングは、リクエスターまたは EGL デプロイメント記述子に指定できます。可能な場合はデプロイメント記述子を使用してください。これは、構成担当者がリクエスターを更新および再生成せずに、サービス・バインディングを更新できるためです。
- このサービスを基に、インターフェース・パーツを作成します。インターフェース・パーツには、関数プロトタイプ が含まれています。これは、アクセス可能な各関数のパラメーターと戻り値の型を指定する定義です。インターフェース・パーツを作成するか、またはワークベンチを使用して EGL サービス・パーツまたは WSDL ファイルからインターフェース・パーツを自動的に作成することができます。
EGL で作成されたサービスにアクセスするときには、インターフェース・パーツを作成する必要はありません。ただし、サービス・パーツをインターフェース・パーツのように使用できます。
- インターフェース・パーツが型定義である変数を宣言します。
例えばインターフェース・パーツが 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 生成のコードが EGL 生成のローカル・プロキシーを呼び出します。
- プロキシーが EGL COBOL ランタイム・コード、つまり COBOL と Java の間のデータ変換を処理するキャッチャー・プログラムを呼び出します。
- キャッチャー・プログラムが Java Native Interface (JNI) を使用して EGL Java ランタイム・コードを呼び出します。このランタイム・コードは、IBM i 上の Java 仮想マシン (JVM) で実行されます。
- 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 サポート』を参照してください)。
プロトコル
Web サービスへのアクセスでは常に HTTP プロトコルが使用されますが、 COBOL Web サービスへのアクセスやその他のケースでは他のプロトコルが使用されます。詳細については、『共用可能プロトコル』を参照してください。
