[Web Application Server] Webservice 정의

본 포스팅에서는 JEUS Webservice에 대해 알아보는 시간을 갖도록 하겠습니다

---

Webservice는 사라져가는 EJB의 대안으로 떠오르고 있는 J2EE Spec 중 하나입니다. Webservice는 SOAP Protocol을 사용하여 XML 형식으로 손쉽게 Remote 환경에 전달이 가능한 J2EE 기능 중 하나입니다.

먼저 웹 서비스의 개요에 대해 알아보겠습니다.

웹 서비스란 무엇인가에 대해 먼저 알아 보겠습니다.

- 웹 서비스는 애플리케이션 플랫폼과 프로그래밍 언어와는 독립된 방식으로 통신할 수 있도록 하는 표준화된 기술이다.

- 웹 서비스는 표준 XML 메시징 통해 네트워크로 접근될 수 있는 오퍼레이션들을 기술하는 소프트웨어 인터페이스이다.

- 웹 서비스는 인터넷에만 연결되어 있다면 서비스에 대한 권한을 가진다.

- 웹 서비스는 사용자 누구에게라도 비즈니스를 공개하고 사용될 수 있도록 메시징 프로토콜, 프로그래밍 표준, 서비스 발견을 위한 편의 환경 등을 정의한다.

- 웹 서비스는 인터넷의 URI로 접근 가능한 응용 프로그램이다.

- 웹 서비스는 인터페이스와 바인딩은 XML 문서로 정의되고, 기술되며, 발견한다.

- 웹 서비스는 인터넷에 공개되어진 또 다른 웹 서비스와 상호 연동이 가능할 뿐 아니라 기존의 백엔드(back-end) 응용 프로그램들과도 연동이 가능하다.

SOAP Message 인코딩 방법에 대해 알아보겠습니다.

정보 교환 방식은 다음과 같습니다.

- RPC 방식입니다.

RPC 방식은 원격 프러시저 호출(RPC) 방식의 메시지 교환 방식을 가리키며, 클라이언트와 서버가 잘 정의된 프로그래밍 모델로 생성되어야 한다.

클라이언트는 인자를 가지는 메소드를 호출하고 서버는 응답으로 하나의 값을 반환한다.

RPC 방식의 메시지 교환 방식에서는 SOAP은 메시지 Body의 형태를 따로 정의한다.

- 문서(Document) 방식입니다.

문서 방식에서는 XML문서가 교환되고, 각각의 엘리먼트의 의미는 서버와 클라이언트의 해석의 몫이다.

즉 SOAP 메시지의 Body의 구조에 대한 제약 사항은 SOAP에서 규정하고 있지 않으며, 응용 프로그램이나 혹은 별도로 정해진 XML 스키마에 의해 SOAP Body속에 있는 XML 문서의 구조가 결정한다. 

SOAP 메시지의 구성 요소는 다음과 같습니다.

- SOAP 메시지는 SOAP Envelope를 가지며 Envelope는 Header와 Body라는 2개의 하위 요소들을 갖는다.

- Header는 필수 요소는 아니다.

- Header의 하위 요소들은 Header 블록이며 각각의 Header 블록은 데이터의 논리적인 묶음이다.

- SOAP Body는 SOAP 메시지의 필수 요소이며 SOAP 메시지의 궁극적으로 전달하고자 하는 내용들을 포함한다.

두번째로 웹 서비스 설계 방법에 대해 알아보겠습니다.

Java 클래스 웹 서비스 Back-end 개발 방식입니다.

- Java 클래스는 EJB를 생성하는 것보다 보통 작업이 더 빠르고 간단하다.

- 영속성(Persistence), 보안, 트랜잭션 등과 같은 EJB 컨테이너에서 제공하는 기능들이 크게 중요하지 않을 때 사용한다.

Stateless Session Bean 웹 서비스 Back-end 개발 방식입니다.

- EJB는 트랜잭션이 중요한 시스템에서 선택될 수 있는 프로그래밍 모델링이다.

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

- Stateless Session Bean으로 비즈니스 로직이 구현되어 있을 경우 효율적이다.

세번째로 웹 서비스 구현 방식에 대해 알아보겠습니다.

웹 서비스를 구현 하는 절차는 다음과 같습니다.

- Back-end 자바코드를 작성한다.

- 웹-서비스를 설계한다.

- SOAP 메시지 핸들러, 핸들러 체인을 생성한다.

- 자바 코드를 컴파일 한다.

먼저 JAX-WS 방식입니다.

JAX-WS 방식은 다음과 같은 특징을 가지고 있습니다.

- 유의할 사항은 서비스 설정에 관한 정보를 기술(description)하지 않아도 된다는 장점이 있다.

- JAX-WS 스펙을 위해 JEUS 웹 서비스 구현에서는 별도의 설정 파일을 작성하지 않고도 구현이 가능하다.

다음으로 JAX-RPC 방식입니다.

JAX-RPC 방식은 다음과 같은 특징을 가지고 있습니다.

- 유의할 사항은 서비스 설정에 관한 정보를 기술(description)해야 한다는 것이다.

- JAX- RPC 스펙은 Java로부터 WSDL로의 매핑에 대한 세세한 정의를 필요로 한다.

- 서비스 Endpoint 인터페이스 만으로는 완전한 WSDL을 생성할 수 없다.

- 서비스 Endpoint 인터페이스는 WSDL의 serivce와 binding에 대한 정보를 제공하지 못한다.

- JAX-RPC 스펙을 위해 JEUS 웹 서비스 구현에서는 별도의 서비스 설정 파일을 작성하며 이러한 정보를 Java-to-WSDL 툴킷에서 제공한다.

실제 구현과정에 대해 알아보겠습니다.

앞서 이야기 했던 WSDL을 기준으로 Webservice를 개발하는 방식입니다.

WSDL로부터 시작한 Webservice 개발 방식입니다.

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

- 웹 서비스의 중심 목표 중 하나는 플랫폼 사이의 상호 운영성이며 이러한 방법은 개발 언어에 중립적으로 상호 운영성 중심적인 서비스를 생성하기 좋은 방법이다.

- 웹 서비스 구현으로부터 생성된 WSDL은 플랫폼 특성이 반영되어 있다. 즉 Java 편향적인 방식이다.

- WSDL로부터 시작된 웹 서비스의 기술(description)은 웹 서비스 기술에 사용된 XML 타입과 용어에서 보다 중립적이다.

- 즉, Java 환경에 익숙하지 않은 개발자에게도 친근할 수 있는 일반적 명명법으로 WSDL을 작성 가능하다.

- 그러나 이 방식은 개발자로 하여금 WSDL에 대한 보다 깊은 이해를 요구한다.

다음으로 서비스 Endpoint로부터 개발을 시작하는 방식입니다.

서비스 Endpoint로부터 시작한 Webservice 개발 방식입니다.

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

- 이러한 방법은 서비스 구현을 쉽고 직관적으로 진행할 수 있는 장점이 있다.

- 이것은 개발자가 자신에게 익숙한 개발 환경, 즉 Java 환경에서 다른 플랫폼과의 상호 운영성에 대한 걱정 없이 서비스 Endpoint와 서비스 구현체를 개발할 수 있다.

- 그 다음에 작성된 Java 코드로 부터 플랫폼 독립적인 WSDL을 도출한다.

- 이렇게 생성된 WSDL이 플랫폼에 독립적으로 정의되기 위하여 JAX-WS와 JAX-RPC는 어떻게 서비스 Endpoint로부터 WSDL을 도출하여야 하는지에 대한 지침을 제공한다.

- 이 방식은 특히, Java 개발자에게는 웹 서비스 개발을 시작하는 가장 쉬운 방법이다.

웹 서비스 soap message handler를 생성하고 이를 구현하는 방법입니다.

Handler의 역할 client side은 다음과 같다.

- Client Side에서는 Stub을 통해 handlerRequest, handlerReponse 메소드를 호출하여 결과을 수신한다.

Handler의 역할 server side은 다음과 같다.

- Server Side는 handlerChain의 handlerRequest()를 등록한 순서대로 모두 처리한 이후 endpoint 또는 EJB로 넘겨지며, 업무처리가 완료 된 이후 handlerResponse()를 역순으로 처리한 이후 client에 전송 된다.

그럼 먼저 자바 클래스 웹 서비스의 구현과정을 설명합니다.

서비스 엔드포인트 인터페이스 정의는 다음과 같습니다.

- 서비스 엔드포인트 인터페이스 (SEI)를 정의한다.

- 서비스 엔드포인트 인터페이스는 echoString 과 echoString_double이라는 웹 서비스 오퍼레이션 정의한다.

- 서비스 엔드포인트 인터페이스는 외부에 공개되어 접근 가능한 웹서비스 오퍼레이션들을 정의한다.

(SOAP이라는 프로토콜을 사용하여 접근할 수 있는 오퍼레이션들을 정의한다)

- 서비스 엔드포인트 인터페이스는 java.rmi.Remote 인터페이스를 직접적으로나 간접적으로 확장한다.

(정의된 Method들은 java.rmi.RemoteException타입을 익셉션으로 처리한다)

구현 클래스 정의는 다음과 같습니다.

- 구현 클래스는 J2EE 서버내에서 인스턴스화 되어 실행된다.

- 구현 클래스는 런타임시에는 웹 서비스로 동작한다.

자바 클래스 작성 원칙은 다음과 같습니다.

Java 클래스 backend로서 웹서비스를 구현할 때 아래의 규칙들을 준수합니다.

1. Service Endpoint Interface(SEI) 를 정의한다.

2. public 클래스를 정의한다.

3. 파라미터 없는 디폴트 생성자를 정의한다.

4. 웹서비스에서 public, non-static으로 노출되는 Java 클래스의 Method 들을 정의한다.

5. 쓰레드에 안전한(Thread-safety) Java 코드를 작성한다.

6. 상호 운용성을 위해서 오버로딩 된 method들을 사용하지 말아야 한다.

다음으로 WSDL로 부터 웹 서비스의 구현방식에 대해 알아보겠습니다.

- 사용자는 wsdl2java Ant 태스크를 수행하여 서비스 인터페이스를 얻을 수 있다.

- wsdl2java Ant 태스크는 사용자가 작성했거나 가지고 있는 WSDL 파일을 입력으로 한다.

- 대부분의 웹-서비스를 구성하는 백앤드(back-end) 구성 요소인 자바 코드를 작성하는 것으로부터 시작하지만 개발 환경에 따라서 WSDL로부터 서비스 인터페이스를 생성가능하다.

지금까지 Webservice의 기본 개요 및 설계 방식 그리고 구현 방식에 대해 살펴 보았습니다. 다음 시간에는 실제 Webservice 생성 및 배치 그리고 실제 비즈니스 로직을 구현하는 방법에 대해 살펴보도록 하겠습니다.

고맙습니다.