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 サービスは Web サービスではなく、別の言語で作成されたコードからはアクセスできません。
EGL REST-RPC サービス・アクセスでは常に POST メソッドが使用されますが、リクエスターに対してはその詳細が隠蔽されます。他の言語で作成されたロジックから EGL REST-RPC サービスにアクセスするときに役立つその他の詳細については、『EGL REST-RPC メッセージ構造』を参照してください。
Rich UI アプリケーションでは、サービスによって返された有効数字が 15 桁を超えるすべての数値データが、EGL ランタイム・コードによって丸められます。JSON が EGL 生成 Java™ コードに返されるときには、丸めは行われません。
EGL 生成のサービスへのアクセスは常に、RESTful スタイルではなく RPC スタイルに準拠しています。パラメーターと戻り値により、交換されるデータが識別されます。サービスへのアクセスには、パス変数や照会パラメーターは使用されません。
EGL で作成されたサービスにアクセスするときには、インターフェース・パーツを作成する必要はありません。ただし、サービス・パーツをインターフェース・パーツのように使用できます。
myService IMyService{};
サービスに送信されるデータまたはサービスから返されるデータのタイプについて詳しくは、『サービス・アクセスのプロトタイプ』を参照してください。
EGL サービス・パーツをインターフェース・パーツとして使用できますが、ほとんどの場合は個別のインターフェース・パーツを使用してください。例えば、サービスがよく変更されるかまたは機密の場合、サービス実装を他の開発者に配布しないようにすることがあります。ただし、Rich UI アプリケーションから専用サービスにアクセスするときにはサービス・パーツをインターフェース・パーツとして使用する必要があります。これについては、『Rich UI でのサービス・アクセス』を参照してください。
すべての EGL Web サービスのデプロイのためのランタイム・アーキテクチャーには、同じパターン (生成されたコードまたはランタイム・コードが、リクエスターとサービスの間の中間コードとして機能する) があります。この中間コードによって、サービス・メッセージのテキスト・ベースのフォーマットと、サービスに必要なバイナリー・フォーマットの間でデータが変換されます。
ランタイム・プラットフォームは、Java EE に準拠するアプリケーション・サーバーです。EGL ランタイム・コードは XML ファイルを読み取り、サービスを呼び出し、リクエスターとサービスの間の中間コードとして機能します。
サービス・ラッパーは Java400 または Java400J2C プロトコルを使用してリモート・キャッチャー・プログラムと通信します。キャッチャー・プログラムはサービスを呼び出し、サービス・ラッパーとサービスの間を中継します。
サービス・ラッパーとサービスは、相互にローカルです。
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 プログラムの場合、詳細情報はプログラム自体に生成されます。
プロキシーの初回呼び出しには時間がかかります。これは、クラスパスのすべての JAR ファイルを含む EGL Java ランタイム・コードがロードされるためです。このロードは、初回呼び出し時および IBM i によりメモリーから JVM がアンロードされた後でのみ実行されます。
Java ランタイム・プロパティーは、EGL REST-RPC サービスによって返される例外に、提供可能な最大レベルの詳細情報を含めるかどうかを指定します。『Java ランタイム・プロパティーの説明』を参照してください。特に、egl.service.rest.exception.debug の項目は、EGL ランタイム・コードのバージョン 8.5 以上に影響していました。
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 サービスへのアクセスやその他のケースでは他のプロトコルが使用されます。詳細については、『共用可能プロトコル』を参照してください。