JEUS 웹 서비스

본 장에서는 JEUS 웹 서비스와 지원되는 스펙의 개념을 기술한다. 또한 JEUS 웹 서비스를 위한 설정 파일들과 툴들 그리고 시스템 변수에 대해서 살펴본다.

1. 기본 구조

Jakarta EE 8 호환 WAS(Web Application Server)인 JEUS는 Jakarta EE 8에서 요구하는 JAX-WS 웹 서비스를 지원한다. JAX-WS 웹 서비스의 가장 중요한 특징은 설정 파일들 없이 자유롭게 구현할 수 있는 POJO(Plain Old Java Object) 방식의 웹 서비스 구현이다. JEUS 웹 서비스는 Jakarta EE 8 스펙을 준수하는 벤더들과의 웹 서비스 상호 호환성이 보장된다.

JEUS 웹 서비스의 구조는 다음과 같다.

JEUS 웹 서비스의 구조

Annotation 및 XML 설정 파일

JEUS 웹 서비스는 비즈니스 로직으로 EJB와 Java 클래스를 사용한다. EJB는 EJB 컨테이너 내부에서 실행되고 Java 클래스는 웹 컨테이너의 내부에서 실행된다.

JEUS 웹 서비스는 Java SE 5에서 지원하는 Annotation을 이용하여 웹 서비스와 관련된 정보들을 설정하는 JAX-WS 웹 서비스의 구현을 기본적으로 지원한다. 또한 하위 호환성을 위해 이러한 정보들을 webservices.xml과 같은 웹 서비스 Deployment Descriptor(이하 DD)에 설정하는 JAX-RPC 웹 서비스 또한 지원한다.
툴과 유틸리티

JEUS 웹 서비스에서는 WSDL 파일 및 Java 클래스의 생성 및 관리를 위해서 Command Line 툴과 Apache Ant 툴을 사용한다. 툴의 사용법은 다음 여러 장에 걸쳐서 설명한다.

Ant 툴 기능을 사용하기 위해서는 Apache Ant 1.6.1 이상을 인스톨해야 한다. http://ant.apache.org에서 Apache Ant를 다운로드할 수 있다.
시스템 환경변수

JEUS 웹 서비스를 위한 특별한 시스템 환경변수는 없고, JEUS Web Engine 안내서와 JEUS EJB 안내서에서 기술된 시스템 환경변수만으로 충분하다.

2. 웹 서비스 설계

본 절에서는 웹 서비스를 설계하는 과정에서 고려해야 할 사항에 대해서 설명한다.

2.1. 웹 서비스 Back-end 선택

웹 서비스 컴포넌트는 웹 컨테이너나 EJB 컨테이너에서 실행되는 Jakarta EE 컴포넌트이다.

웹 서비스의 Back-end는 다음의 개체들을 공개할 수 있다.

Java 클래스 파일

Java 클래스 파일은 웹 컨테이너에서 실행된다. Java 클래스는 EJB를 생성하는 것보다 보통 작업이 더 빠르고 간단하게 끝난다.

영속성(Persistence), 보안, 트랜잭션 등과 같은 EJB 컨테이너에서 제공하는 기능들이 크게 중요하지 않을 때 Java 클래스 웹 서비스 Back-end가 좋은 선택이다.
Stateless Session EJB

EJB는 트랜잭션이 중요한 시스템에서 선택될 수 있는 프로그래밍 모델로 Stateless Session EJB은 EJB 컨테이너에서 실행된다.

DB에 업데이트나 삭제와 같은 작업들을 많이 하는 시스템에서는 비즈니스 로직을 EJB로 구현한다면 트랜잭션 관리에 효율적이므로 좋은 선택이라고 볼 수 있다.

위와 같이 트랜잭션이 중요한 경우가 아닐 때에도 EJB Back-end는 웹 서비스 Back-end로서 좋은 선택이 될 수 있는데 바로 CMP(Container Managed Persistence)가 그 예이다. CMP에 대해 더 세부적인 사항을 알아보려면 Enterprise Java Beans 매뉴얼을 참고한다.

이미 언급한 대로 기존의 비즈니스 로직은 필요에 의해 EJB(Stateless Session Bean 또는 CMP)로 구성되어 있을 수 있다. 이미 Stateless Session Bean으로 비즈니스 로직이 구현되어 있고, 이러한 상황에서 기존의 EJB 로직을 웹 서비스로 공개하고 싶다면 Stateless Session Bean 웹 서비스 Back-end를 선택하는 것이 좋다.

일반적으로 EJB 웹 서비스는 Stateless Session Bean만을 Back-end로 허용하므로 CMP는 웹 서비스와 연관이 없어 보일 수도 있다. 하지만 Stateless Session Bean이 CMP로 구현되어 있는 비즈니스 로직으로의 인터페이스 역할을 하도록 하고, Stateless Session Bean이 웹 서비스로 공개된다면 CMP 비즈니스 로직을 웹 서비스로 공개하게 된다. 기존의 CMP 비즈니스 로직의 장점을 그대로 이용하면서 웹 서비스 기능을 추가할 때 Stateless Session Bean 웹 서비스 Back-end는 좋은 선택이라 볼 수 있다.

2.2. RPC 방식과 문서 방식의 선택

JEUS 웹 서비스는 RPC 방식과 문서(Document) 방식을 지원한다.

RPC 방식

WSDL 1.1 스펙에 의하면 RPC 방식은 SOAP 메시지가 웹 서비스 오퍼레이션의 인자와 리턴값을 포함하고, 문서 방식은 XML 문서를 SOAP 메시지가 포함한다. 또한 RPC 방식은 원격 프로시저 호출(RPC) 방식의 메시지 교환 방식을 가리키며, 클라이언트와 서버가 잘 정의된 프로그래밍 모델로 만들어져야 한다. 클라이언트는 인자를 가지는 메소드를 호출하고 서버는 응답으로 하나의 값을 반환한다.

RPC 방식에서는 인자들의 개수에 제한이 없다.

문서(Document) 방식

XML 문서가 교환되고 각각의 element의 의미는 서버와 클라이언트가 해석의 몫으로 남겨둔다. 즉, SOAP 메시지의 바디의 구조에 대한 제약 사항은 SOAP에서 규정하고 있지 않으며, 응용 프로그램이나 혹은 별도로 정해진 XML 스키마에 의해 SOAP 바디에 위치한 XML 문서의 구조가 결정된다.

JEUS 웹 서비스에서 제공하는 문서 방식에는 표준 문서 방식과 WRAPPED 방식이 있다.

구분	설명
표준 문서 방식	각각의 웹 서비스 오퍼레이션은 1개의 인자(XML 문서)만 가질 수 있다.
WRAPPED 방식	여러 인자들을 하나의 복합 데이터 타입(complex data type)으로 포장하여 하나의 인자로 만들어 SOAP 메시지에 포함라게 되므로 웹 서비스 오퍼레이션들은 여러 개의 인자들을 가질 수 있다.

구분

설명

표준 문서 방식

각각의 웹 서비스 오퍼레이션은 1개의 인자(XML 문서)만 가질 수 있다.

WRAPPED 방식

여러 인자들을 하나의 복합 데이터 타입(complex data type)으로 포장하여 하나의 인자로 만들어 SOAP 메시지에 포함라게 되므로 웹 서비스 오퍼레이션들은 여러 개의 인자들을 가질 수 있다.

2.3. 웹 서비스 구현 방식 선택

일반적으로 웹 서비스 구현은 서비스 Endpoint로부터 시작하거나 WSDL로부터 시작할 수 있다. 이것은 개발자의 취향과 개발 환경에 따라서 선택되며 각각 장점을 가지고 있으며, JEUS 웹 서비스에서 JAX-WS 방식과 JAX-RPC 방식으로 구현될 수 있다.

서비스 Endpoint로부터 시작

서비스 구현이 단순하고 쉬우며 직관적으로 구현 가능하다.
WSDL로부터 시작

구현 언어에 중립적으로 상호 운영성이 가능한 서비스를 구현하기에 적합하다.

서비스 Endpoint로부터 시작

서비스 Endpoint를 먼저 구현하고 이것으로부터 WSDL을 생성하는 방법이다. 이 방법은 서비스 구현을 쉽고 직관적으로 진행할 수 있는 장점이 있다. 이것은 개발자가 자신에게 익숙한 개발 환경, 즉 Java 환경에서 다른 플랫폼과의 상호 운영성에 대한 걱정 없이 서비스 Endpoint와 서비스 구현체를 개발할 수 있게 한다. 그 다음에 작성된 Java 코드로부터 플랫폼 독립적인 WSDL을 도출하게 된다.

이렇게 생성된 WSDL이 플랫폼에 독립적으로 정의되기 위해서 JAX-WS와 JAX-RPC는 어떻게 서비스 Endpoint로부터 WSDL을 도출해야 하는지에 대한 지침을 제공한다. 이 방식은 Java 개발자에게는 웹 서비스 개발을 시작하는 가장 쉬운 방법이다.

JAX-WS 방식

JAX-WS 방식에서 유의할 사항은 서비스 설정에 관한 정보를 기술(description)하지 않아도 된다는 것이다. JAX-WS 스펙을 위해 JEUS 웹 서비스 구현에서는 별도의 서비스 설정 파일을 작성하지 않고도 wsgen 툴킷에 의해 웹 서비스를 구현할 수 있다.

JAX-WS 방식의 웹 서비스 구현에 대한 자세한 내용은 JEUS 웹 서비스 구현을 참고한다.
JAX-RPC 방식

JAX-RPC 방식에서 유의할 사항은 서비스 설정에 관한 정보를 기술(description)해야 한다는 것이다. JAX-RPC 스펙은 Java로부터 WSDL로의 매핑에 대해 자세히 정의하고 있다. 그러나 서비스 Endpoint 인터페이스만으로는 완전한 WSDL을 생성할 수 없다. 서비스 Endpoint 인터페이스는 WSDL의 서비스와 바인딩에 대한 정보를 제공하지 못한다. JAX-RPC 스펙을 위해 JEUS 웹 서비스 구현에서는 별도의 서비스 설정 파일을 작성하여 이러한 정보를 Java-to-WSDL 툴킷에 제공해야 한다.

JAX-RPC 방식의 웹 서비스 구현에 대한 자세한 내용은 JAX-RPC 웹 서비스 구현을 참고한다.

WSDL로부터 시작

WSDL을 먼저 작성하고 이것으로부터 웹 서비스 구현을 생성하는 방법이다.

웹 서비스의 중심 목표 중 하나는 플랫폼 사이의 상호 운영성이다. 이러한 방법은 개발 언어에 중립적으로 상호 운영성 중심적인 서비스를 생성하기 좋은 방법이다. 웹 서비스 구현으로부터 생성된 WSDL은 플랫폼 특성이 반영된다. 즉, Java 편향된다. 그러나 WSDL로부터 시작된 웹 서비스의 기술(description)은 웹 서비스 기술에 사용된 XML 타입과 용어에서 보다 중립적이다. 즉, Java 환경에 익숙하지 않은 개발자에게도 친근할 수 있는 일반적 명명법으로 WSDL을 작성할 수 있게 한다.

그러나 이 방식은 개발자로 하여금 WSDL에 대한 보다 깊은 이해를 요구한다. JAX-WS 웹 서비스 구현은 JEUS 웹 서비스 구현에서 설명하고 있다. 또한, JAX-RPC 웹 서비스 구현은 JAX-RPC 웹 서비스 구현에 설명하고 있다.

2.4. SOAP 메시지 핸들러 생성

SOAP 메시지의 헤더나 바디 또는 Attachment를 직접 다루려고 할 때 메시지 핸들러의 생성이 필요하다.

JAX-WS 방식

JAX-WS 핸들러 프레임워크를 이용할 수 있다. 자세한 설명은 핸들러 프레임워크를 참고한다.
JAX-RPC 방식

웹 서비스의 경우 SOAP 메시지의 JAX-RPC 표준 핸들러를 생성하고, SAAJ(SOAP with Attachments API for Java)를 이용하여 직접 메시지를 다룰 수 있다. 보다 자세한 설명은 JAX-RPC 웹 서비스 SOAP 메시지 핸들러 생성을 참고한다.