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

JEUS 웹 서비스는 JavaSE 5에서 지원하는 Annotation을 이용하여 웹 서비스와 관련된 정보들을 설정하는 JAX-WS 웹 서비스의 구현을 기본적으로 지원한다. 또한, 하위 호환성을 위해 이러한 정보들을 webservices.xml과 같은 웹 서비스 Deployment Descriptor에 설정하는 JAX-RPC 웹 서비스 또한 지원한다. 파일 작성법은 본 안내서에서 설명한다.

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

Ant 툴 기능을 사용하기 위해서는 Apache Ant 1.6.1 이상을 설치해야 한다.

JEUS 웹 서비스를 위한 특별한 시스템 환경변수는 없다.

JEUS 웹 서비스의 작동을 위해서는 "JEUS Web Container 안내서"와 "JEUS EJB 안내서"에서 기술된 시스템 환경변수만으로 충분하다.

웹 서비스 컴포넌트는 웹 컨테이너나 EJB 컨테이너에서 실행되는 JavaEE 컴포넌트이다. 웹 서비스의 Back-end는 다음의 개체들을 공개할 수 있다.

Java 클래스 파일은 웹 컨테이너에서 실행되고 무상태 Session Bean은 EJB 컨테이너에서 실행된다.

Java 클래스 웹 서비스 Back-end

Java 클래스는 EJB를 생성하는 것보다 보통 작업이 더 빠르고 간단하게 끝난다. 영속성(Persistence), 보안, 트랜잭션 등과 같은 EJB 컨테이너에서 제공하는 기능들이 크게 중요하지 않을 때, Java 클래스 웹 서비스 Back-end가 좋은 선택이다.

Stateless Session Bean 웹 서비스 Back-end

EJB 웹 서비스를 언급하기에 앞서, EJB는 트랜잭션이 중요한 시스템에서 선택될 수 있는 프로그래밍 모델이다. 데이터 베이스에 업데이트나 삭제 같은 작업들을 많이 하는 시스템에서는, 비즈니스 로직을 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 방식에서 유의할 사항은 서비스 설정에 관한 정보를 기술(description)하지 않아도 된다는 것이다. JAX-WS 스펙을 위해 JEUS 웹 서비스 구현에서는 별도의 서비스 설정 파일을 작성하지 않고도 wsgen 툴킷에 의해 웹 서비스를 구현할 수 있다. JAX-WS 방식의 웹 서비스 구현은 “제3장 JEUS 웹 서비스 구현”에 설명하고 있다.

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

WSDL로부터 시작

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

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

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

SOAP 메시지의 Header나 Body, 혹은 Attachment를 직접 다루고자 할 때 메시지 핸들러의 생성이 필요하다.