내용 목차
본 장에서는 JEUS 웹 서비스와 지원되는 스펙의 개념을 기술한다. 또한 JEUS 웹 서비스를 위한 설정 파일들과 툴들 그리고 시스템 변수에 대해서 살펴본다.
Java EE 7 호환 WAS(Web Application Server)인 JEUS는 Java EE 7에서 요구하는 JAX-WS 웹 서비스를 지원한다. JAX-WS 웹 서비스의 가장 중요한 특징은 설정 파일들 없이 자유롭게 구현할 수 있는 POJO(Plain Old Java Object) 방식의 웹 서비스 구현이다. JEUS 웹 서비스는 Java EE 7 스펙을 준수하는 벤더들과의 웹 서비스 상호 호환성이 보장된다.
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 안내서"에서 기술된 시스템 환경변수만으로 충분하다.
본 절에서는 웹 서비스를 설계하는 과정에서 고려해야 할 사항에 대해서 설명한다.
웹 서비스 컴포넌트는 웹 컨테이너나 EJB 컨테이너에서 실행되는 Java EE 컴포넌트이다.
웹 서비스의 Back-end는 다음의 개체들을 공개할 수 있다.
-
Java 클래스 파일은 웹 컨테이너에서 실행된다. Java 클래스는 EJB를 생성하는 것보다 보통 작업이 더 빠르고 간단하게 끝난다.
영속성(Persistence), 보안, 트랜잭션 등과 같은 EJB 컨테이너에서 제공하는 기능들이 크게 중요하지 않을 때 Java 클래스 웹 서비스 Back-end가 좋은 선택이다.
-
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는 좋은 선택이라 볼 수 있다.
JEUS 웹 서비스는 RPC 방식과 문서(Document) 방식을 지원한다.
일반적으로 웹 서비스 구현은 서비스 Endpoint로부터 시작하거나 WSDL로부터 시작할 수 있다. 이것은 개발자의 취향과 개발 환경에 따라서 선택되며 각각 장점을 가지고 있으며, JEUS 웹 서비스에서 JAX-WS 방식과 JAX-RPC 방식으로 구현될 수 있다.
-
서비스 구현이 단순하고 쉬우며 직관적으로 구현 가능하다.
-
구현 언어에 중립적으로 상호 운영성이 가능한 서비스를 구현하기에 적합하다.
서비스 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 방식의 웹 서비스 구현에 대한 자세한 내용은 “제3장 JEUS 웹 서비스 구현”을 참고한다.
-
JAX-RPC 방식
JAX-RPC 방식에서 유의할 사항은 서비스 설정에 관한 정보를 기술(description)해야 한다는 것이다. JAX-RPC 스펙은 Java로부터 WSDL로의 매핑에 대해 자세히 정의하고 있다. 그러나 서비스 Endpoint 인터페이스만으로는 완전한 WSDL을 생성할 수 없다. 서비스 Endpoint 인터페이스는 WSDL의 서비스와 바인딩에 대한 정보를 제공하지 못한다. JAX-RPC 스펙을 위해 JEUS 웹 서비스 구현에서는 별도의 서비스 설정 파일을 작성하여 이러한 정보를 Java-to-WSDL 툴킷에 제공해야 한다.
JAX-RPC 방식의 웹 서비스 구현에 대한 자세한 내용은 “제21장 JAX-RPC 웹 서비스 구현”을 참고한다.
WSDL로부터 시작
WSDL을 먼저 작성하고 이것으로부터 웹 서비스 구현을 생성하는 방법이다.
웹 서비스의 중심 목표 중 하나는 플랫폼 사이의 상호 운영성이다. 이러한 방법은 개발 언어에 중립적으로 상호 운영성 중심적인 서비스를 생성하기 좋은 방법이다. 웹 서비스 구현으로부터 생성된 WSDL은 플랫폼 특성이 반영된다. 즉, Java 편향된다. 그러나 WSDL로부터 시작된 웹 서비스의 기술(description)은 웹 서비스 기술에 사용된 XML 타입과 용어에서 보다 중립적이다. 즉, Java 환경에 익숙하지 않은 개발자에게도 친근할 수 있는 일반적 명명법으로 WSDL을 작성할 수 있게 한다.
그러나 이 방식은 개발자로 하여금 WSDL에 대한 보다 깊은 이해를 요구한다. JAX-WS 웹 서비스 구현은 “제3장 JEUS 웹 서비스 구현”에서 설명하고 있다. 또한, JAX-RPC 웹 서비스 구현은 “제21장 JAX-RPC 웹 서비스 구현”에 설명하고 있다.
SOAP 메시지의 헤더나 바디 또는 Attachment를 직접 다루려고 할 때 메시지 핸들러의 생성이 필요하다.
-
JAX-WS 핸들러 프레임워크를 이용할 수 있다. 자세한 설명은 “제7장 핸들러 프레임워크”를 참고한다.
-
웹 서비스의 경우 SOAP 메시지의 JAX-RPC 표준 핸들러를 생성하고, SAAJ(SOAP with Attachments API for Java)를 이용하여 직접 메시지를 다룰 수 있다. 보다 자세한 설명은 “제24장 JAX-RPC 웹 서비스 SOAP 메시지 핸들러 생성”을 참고한다.