SOA에 대한 EGL 지원

EGL은 SOA(Service Oriented Architecture)에 대해 서비스 개발 및 서비스 액세스의 두 가지 지원을 제공합니다.

서비스 개발

EGL을 사용하는 경우에는 다음과 같은 서비스 파트를 코드하여 서비스 개발을 시작합니다.
Service MyServicePart
   value STRING = "Hello ";
   
   function myEcho(myString STRING IN) returns (STRING)
      return (value = myString);
   endend

서비스 파트의 컨텐츠는 서비스 구현입니다. 위 코드의 경우 구현은 "world"와 같은 입력을 수락하고 요청자에게 "Hello"와 입력 문자열의 연결을 리턴합니다. 서비스 요청자가 몇 가지 함수 또는 서비스 조작에 액세스할 수 있도록 할 수 있습니다.

서비스 파트를 작성할 때는 이를 배치하는 방법을 지정합니다. 서비스 파트는 다음 유형의 서비스 중 하나로 배치할 수 있습니다.
EGL 서비스
EGL 서비스는 데이터를 EGL에 고유한 2진 형식으로 교환합니다.

EGL 서비스는 다양한 유형의 EGL 코드가 액세스할 수 있으며 액세스 속도가 비교적 빠릅니다. 그러나 EGL 서비스는 웹 서비스가 아니며 다른 언어로 작성된 코드는 이 서비스에 액세스할 수 없습니다.

EGL REST-RPC 서비스
EGL REST-RPC 서비스는 EGL로 생성된 웹 기반 요청자가 액세스할 수 있습니다. 데이터는 항상 JSON 형식이며 이는 HEX, BLOB 또는 CLOB 데이터를 포함할 수 없습니다.

EGL REST-RPC 서비스는 항상 POST 메소드를 사용하지만 해당 세부사항은 요청자에 대해 숨겨져 있습니다. 다른 언어로 작성된 로직에서 EGL REST-RPC 서비스에 액세스하는 경우에 의미가 있는 다른 세부사항은 "EGL REST-RPC 메시지 구조"를 참조하십시오.

Rich UI 애플리케이션에서, EGL 런타임 코드는 서비스가 리턴했으며 유효숫자가 16개 이상인 모든 숫자 데이터를 반올림합니다. EGL로 생성된 Java™ 코드에 JSON이 리턴되는 경우에는 반올림이 수행되지 않습니다.

SOAP 서비스
SOAP 서비스는 기존 웹 서비스이며 모든 언어로 작성된 코드에서 액세스할 수 있습니다.

EGL로 생성된 서비스에 대한 액세스는 항상 RESTful 스타일이 아니라 RPC 스타일을 따릅니다. 매개변수 및 리턴값은 교환할 데이터를 식별합니다. 서비스에 대한 액세스는 경로 변수 또는 조회 매개변수를 포함하지 않습니다.

서비스 액세스를 위한 코드 개발

서비스 파트를 포함한 모든 EGL 파트는 서비스 요청자 역할을 수행할 수 있습니다. 다음 유형의 서비스에 액세스할 수 있습니다.
  • EGL 서비스
  • EGL REST-RPC 서비스
  • SOAP 서비스(EGL로 생성되거나 그렇지 않은 것 모두)
  • IBM® i 서비스 프로그램
  • REST 스타일을 대부분 만족시키는 써드파티 REST 서비스. 다음과 같은 변형 형태가 지원됩니다.
    • 일부 REST 서비스는 자원 작성 태스크 외에도 POST 요청을 사용합니다. POST 요청을 사용하여 써드파티 REST 서비스에 액세스하면 비즈니스 데이터를 전송하지 않을 수 있습니다.
    • 일부 REST 서비스에서는 DELETE 요청에서 삭제할 자원을 식별하는 데 URI에 의존하지 않고 표현(비즈니스 데이터)을 포함시킬 것을 요구합니다. EGL은 DELETE 요청에 대해 표현을 필요로 하는 REST 서비스의 액세스를 지원하지만, 이러한 요구사항이 없는 REST 서비스의 액세스 또한 지원합니다.
서비스 액세스는 일반적으로 다음 단계를 포함합니다.
  1. 서비스에 액세스하는 데 필요한 세부사항인 서비스 바인딩을 지정합니다. 서비스 바인딩은 요청자 또는 EGL 배치 디스크립터에 있을 수 있습니다. 구성 담당자가 요청자를 업데이트하고 다시 생성하지 않고 서비스 바인딩을 업데이트할 수 있으므로 가능하면 배치 디스크립터를 사용하십시오.
  2. 서비스를 기반으로 하는 인터페이스 파트를 작성합니다. 인터페이스 파트는 각 액세스 가능한 함수의 매개변수 및 리턴값 유형을 식별하는 함수 프로토타입을 포함합니다. 인터페이스 파트는 직접 작성하거나, 워크벤치를 사용하여 EGL 서비스 파트 또는 WSDL 파일로부터 자동으로 작성되도록 할 수 있습니다.

    EGL로 작성된 서비스에 액세스하는 경우에는 인터페이스 파트를 작성할 필요가 없으며, 서비스 파트를 인터페이스 파트로 사용할 수 있습니다.

  3. 인터페이스 파트가 유형 정의인 변수를 선언합니다. 예를 들어, 인터페이스 파트의 이름이 IMyService, 변수의 이름이 myService로 지정되었으며 배치 디스크립터 항목 또한 IMyService로 이름 지정된 경우 변수 선언은 다음과 같습니다.
    myService IMyService{};

서비스에 전송되고 서비스로부터 리턴되는 데이터의 유형에 대한 세부사항은 "서비스 액세스에 사용되는 프로토타입의 제한사항"을 참조하십시오.

EGL 서비스 파트를 인터페이스 파트로 사용할 수 있으나, 대부분의 경우에는 별도의 인터페이스 파트를 사용하십시오. 예를 들면, 서비스가 변경될 수 있거나 기밀이어서 다른 개발자에게 서비스 구현을 분배하지 않으려 할 수 있습니다. 그러나 "Rich UI에서의 서비스 액세스"에 설명되어 있는 바와 같이, Rich UI 애플리케이션에서 전용 서비스에 액세스하는 경우에는 서비스 파트를 인터페이스 파트로 사용해야만 합니다.

웹 서비스 배치

모든 EGL 웹 서비스 배치에 대한 런타임 아키텍처에는 동일한 패턴(생성된 코드 또는 런타임 코드가 요청자와 서비스 간에 중개 역할을 함)이 있습니다. 중개 코드는 서비스 메시지의 텍스트 기반 형식과 서비스에서 필요로 하는 2진 형식을 중간에서 변환합니다.

각 배치 유형의 개요는 다음과 같습니다.
  • EGL REST-RPC 서비스를 생성하는 경우 출력은 Java 클래스의 세트입니다. 배치 디스크립터를 생성하거나 배치하면 출력은 서비스 위치를 식별하는 XML 파일을 포함합니다.

    런타임 플랫폼은 Java EE를 준수하는 애플리케이션 서버입니다. 여기서 EGL 런타임 코드는 XML 파일을 읽고, 서비스를 호출하고, 요청자와 서비스 간의 중개 역할을 수행합니다.

  • Java를 기반으로 하는 SOAP 서비스를 생성하는 경우 출력은 Java 클래스의 세트입니다. 배치 디스크립터를 생성하거나 배치하면 출력은 서비스 랩퍼라고 하는 Java 클래스를 포함합니다. 이 서비스 랩퍼는 "Java 랩퍼 생성"에 설명되어 있는, EGL로 생성된 출력과는 다른 것입니다. 런타임 플랫폼은 Java EE를 준수하는 애플리케이션 서버입니다. 이 애플리케이션 서버는 서비스 랩퍼를 호출하며, 이 서비스 랩퍼는 서비스를 호출하고 요청자와 서비스 간의 중개 역할을 수행합니다. 서비스 랩퍼 및 서비스는 서로에게 로컬입니다.
  • IBM i용 COBOL 기반 SOAP 서비스를 생성하는 경우 출력은 COBOL 프로그램입니다. 배치 디스크립터를 생성하거나 배치하면 출력은 Java 클래스인, EGL로 생성된 서비스 랩퍼를 포함합니다.
    이 상황은 Java 기반 SOAP 서비스의 경우와 같지만 서비스 랩퍼가 서비스로부터 원격입니다. 런타임 플랫폼은 다음 두 부분으로 구성되어 있습니다.
    • 요청자와 IBM i의 EGL COBOL 런타임 코드 간의 중개 역할을 수행하는 로컬 서비스 랩퍼를 호출하는, Java EE를 준수하는 애플리케이션 서버.
    • IBM i 설치는 EGL COBOL 런타임 코드를 실행합니다. 이 런타임 코드에는 Java와 COBOL 간의 데이터 변환을 처리하는 로직인 캐처 프로그램이 포함되어 있습니다.

    서비스 랩퍼는 Java400 또는 Java400J2C 프로토콜을 사용하여 원격 캐처 프로그램과 통신합니다. 캐처 프로그램은 서비스를 호출하고 서비스 랩퍼와 서비스 간의 중개 역할을 수행합니다.

  • COBOL for CICS®를 기반으로 하는 SOAP 서비스를 생성하는 경우 출력은 COBOL 프로그램입니다. 배치 디스크립터를 생성하거나 배치하면 CICS에서 사용할 수 있도록 서비스 랩퍼라는, EGL로 생성된 두 번째 COBOL 프로그램이 제공됩니다. 배치 디스크립터로부터 생성되는 또 다른 출력은 WSBIND 파일입니다.
    런타임 플랫폼은 CICS이며, 이는 다음과 같은 역할을 수행합니다.
    • WSBIND 파일을 사용하여 SOAP 엔벨로프 컨텐츠를 2진 형식으로 변환합니다.
    • 요청자와 서비스 간의 중개 역할을 수행하는 서비스 랩퍼를 호출합니다.

    서비스 랩퍼 및 서비스는 서로에게 로컬입니다.

서비스 액세스

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를 임베드하며 IBM WebSphere® Application Server와 같이 Java EE를 완전히 준수하는 애플리케이션 서버에 배치된 HTML 파일 프록시는 요청자 고유 배치 디스크립터로부터 생성된 Java 클래스입니다.
EGL로된 생성된 Java 코드, 또는 JavaScript를 임베드하며 그 외의 플랫폼에 배치된 HTML 파일 프록시가 EGL 런타임 코드에 있습니다.
EGL로 생성된 COBOL 프로그램 프록시는 요청자 고유의 배치 디스크립터로부터 생성된 COBOL 프로그램입니다.

서비스 액세스의 또 다른 요소는 서비스 바인딩 세부사항의 위치입니다. CICS 프로그램을 제외한 모든 EGL로 생성된 요청자의 경우, 이 세부사항은 요청자 고유 배치 디스크립터로부터 생성되었으며 요청자와 함께 배치된 XML 파일에 있습니다. CICS 프로그램의 경우 이 세부사항은 해당 프로그램 자체의 내부에 생성됩니다.

EGL로 생성된 Java 및 COBOL 코드는 EGL로 생성된 COBOL 프로그램이 IBM i에 배치되어 SOAP 서비스에 액세스하는 경우 둘 다 사용됩니다. 이로 인한 영향을 이해하려면 다음 런타임 이벤트에 주의하십시오.
  1. EGL로 생성된 코드가 EGL로 생성된 로컬 프록시를 호출합니다.
  2. 프록시가 EGL COBOL 런타임 코드(구체적으로는 COBOL과 Java 간의 데이터 변환을 처리하는 캐처 프로그램)를 호출합니다.
  3. 캐처 프로그램이 JNI(Java Native Interface)를 사용하여, IBM i의 JVM(Java Virtual Machine)에서 실행되는 EGL Java 런타임 코드를 호출합니다.
  4. EGL Java 런타임 코드가 로컬 또는 원격으로 SOAP 서비스에 액세스합니다.

프록시에 대한 초기 호출은 클래스 경로에 있는 모든 JAR 파일을 포함, EGL Java 런타임 코드가 로드되므로 느립니다. 이 로드는 첫 번째 호출 또는 IBM i가 JVM을 메모리에서 로드 해제한 후에만 수행됩니다.

웹 상에서의 보안

Java 런타임 특성은 EGL REST-RPC 서비스에서 리턴되는 예외에 가능한 최대의 세부사항 레벨을 포함시킬 것인지 여부를 지정합니다. "Java 런타임 특성에 대한 설명"을 참조하십시오. 특히 EGL 런타임 코드의 버전 8.5 이상에 적용되는 egl.service.rest.exception.debug 항목을 참조하십시오.

WS-Addressing 및 WS-Security에 대한 지원

EGL로 생성된 SOAP 서비스 또는 EGL로 생성된 SOAP 서비스 요청자를 IBM WebSphere Application Server에 배치할 때는 이 애플리케이션 서버의 WS-Addressing 및 WS-Security 기능을 사용할 수 있습니다. 서비스 또는 서비스 요청자는 "JAX-WS 및 JAX-RPC에 대한 EGL 지원"에 설명되어 있는 바와 같이 JAX-RPC가 아니라 JAX-WS에 의존해야 합니다.

추가 정보를 얻으려면 다음 사이트 중 하나로 이동하여 "WS-Addressing" 또는 "WS-Security"를 검색하십시오.

프로토콜

웹 서비스에 대한 액세스는 항상 HTTP 프로토콜을 포함하지만, COBOL 웹 서비스에 대한 액세스 및 기타 경우에는 다른 프로토콜이 사용됩니다. 세부사항은 "공유 가능 프로토콜"을 참조하십시오.