본문 바로가기
정보과학/웹서비스특론

웹 서비스 시스템 개발

by J1소프트 2023. 9. 9.
728x90

1. JAX-RPC

 

1.1 웹 서비스 시스템

웹 서비스 시스템이란 인터넷에 연결되어 있는 원격 클라이언트에 의해 호출될 수 있는 원격 프로시저의 집합으로서 서버 측 응용 프로그램을 의미한다.

 

► JAX-RPC를 이용해서 작성된 웹 서비스 시스템은 서블릿으로 작성된 한 개의 웹 응용 프로그램이며, 개발 완료된 웹 서비스 시스템은 WAR 파일 형태로 패키징되어 웹 컨테이너에 배치되고 실행된다.

 

► 웹 서비스 시스템은 요청과 응답형 모델을 지원한다.

웹 서비스 클라이언트가 원격 프로시저를 호출하는 요청 SOAP 메시지를 전송하면, 웹 서비스 시스템은 원격 프로시저를 실행하고 그 결과를 응답 메시지로 구성해서 클라이언트에게 되돌려준다.

 

► 웹 서비스 시스템은 HTTP 전송 프로토콜을 사용한다.

인터넷에 연결된 어떤 클라이언트도 HTTP를 통해 웹 서비스 시스템의 원격프로시저를 호출하여 사용할 수 있다.

 

웹 서비스 시스템과 웹 서비스 클라이언트 간의 관계는 다음과 같이 표현될 수 있다.

1.2 JAX-RPC

Java API for XML-based RPC(JAX-RPC)는 XML 기반 RPC를 위한 표준 자바 API이다. 다시 말하면 RPC와 XML을 이용한 웹 서비스와 클라이언트를 작성하는 API라고 할 수 있다. JAX-RPC API를 JAX-RPC 런타임이라고 부르기도 한다.

 

JAX-RPC의 RI(Reference Implementation)는 다음과 같은 표준에 기반을 두고 있다.

▸ HTTP 1.1

▸ SOAP 1.1

▸ WSDL 1.1

 

웹 서비스는 사용자가 서비스를 호출하는 방식을 크게 두 가지로 구분하고 있는데 JAX-RPC는 그 중 RPC 방식의 SOAP 호출방식에 따른 API이다. JAX-RPC는 RPC의 프로토콜로서 SOAP을 사용하며 실제 JAX-RPC 클라이언트와 웹 서비스 간의 모든 통신 내용을 SOAP 방식으로 인코딩하여 HTTP를 통해 전달한다.

참고: SOAP RPC와 SOAP 도큐먼트

RPC 방식의 SOAP 호출은 전통적인 RPC의 방식을 그대로 계승한다. 즉 사용자는 원격 웹 서비스의 서비스 중 하나를 선택하여 요청한 후 결과를 얻는 방식이다. 따라서 서비스를 호출하는 사용자는 형성된 XML의 형태보다 전달할 인자와 돌려받을 결과 값이 중요하다. 따라서 RPC 방식의 SOAP API는 사용자가 쉽게 서비스를 호출하도록 가능한 SOAP 메시지 구성 부분을 자동화하게 된다. 그리고 RPC 방식과 마찬가지로 대부분의 경우 호출한 후 서비스의 결과가 전달될 때까지 기다려야 하는 동기식 형태이다. 즉 SOAP 메시지가 RPC 형태로 전달되었다는 사실을 웹 서비스 시스템에서 이를 해석하여 올바른 결과를 돌려줄 수 있도록 일련의 과정을 거쳐야 한다는 것을 의미한다.

반면에 도큐먼트 형식의 SOAP 호출 방식은 XML 메시지에 가깝다. 즉 사용자는 서비스에 전달할 내용이 특정 수신자로 전달되기를 원하거나 단지 메시지를 서비스로 전달하는 데 의미를 둔다. 따라서 사용자가 SOAP 메시지를 의미 있게 구성할 수 있도록 도큐먼트 방식의 SOAP API는 SOAP 메시지를 쉽게 작성할 수 있는 API를 제공한다. 이러한 API의 제공으로 사용자는 SOAP 메시지의 부분을 원하는 형태로 설정할 수 있다. 이를 받아들이는 웹 서비스는 굳이 메시지의 내용을 해석하지 않고 첨부 파일 다루듯이 메시지 전체 내용을 3자에게 전달하거나 그 자체로 처리한다.

도큐먼트 형식을 자세하게 보면 RPC 방식의 SOAP 호출과 마찬가지로 클라이언트는 하나의 SOAP 요청을 등록하고 SOAP 응답을 받게 된다. 하지만 내부적인 관점에서 보면 둘은 다르다.

이것들의 주요한 차이점은 다음과 같다.
1. 도큐먼트 형식의 SOAP 호출에서 클라이언트는 자바 호출을 직렬화할 필요가 없고, 인자로 XML문서를 주면된다. 거꾸로 서버는 XML 문서를 자바 호출이나 데이터 타입으로 역직렬화할 필요가 없다.

2. RPC 방식의 SOAP 호출에서는 클라이언트와 서버는 잘 정의된 프로그래밍 모델로 만들어져야 한다. 클라이언트는 인자를 가지는 메소드를 호출하고 서버는 응답으로 하나의 값을 반환하는 형식이다. 도큐먼트 방식에서는 XML 문서가 교환되고 각각의 엘리먼트의 의미는 서버와 클라이언트가 해석의 몫으로 남겨두다. 그리고 클라이언트와 웹 서비스는 요청과 응답을 위한 복합적인 문서들을 꾸러미로 묶을 수 있다.

실제로 WSDL의 서비스 바인딩은 SOAP RPC 또는 도큐먼트 방식에 따라 다른 바인딩을 기술하도록 한다.

실제로 SOAP 호출은 XML로 구성한 SOAP 메시지를 HTTP로 전달한 후 서비스가 보낸 SOAP 메시지 중 원하는 내용을 추출하는 복잡한 단계를 거치게 된다. 하지만 이처럼 SOAP 호출을 위해 매번 XML을 SOAP 메시지 형식으로 바꾸는 것이 개발자들에게는 매우 번거로운 작업일 수밖에 없다.

JAX-RPC는 이러한 복잡한 작업을 개발자 대신 해주고 간단한 서비스 호출 관련 API만 사용자에게 제공하여 SOAP 호출과 관련된 개발자 작업을 상당히 단순화시킨다. 또한 서비스 제공자에게는 기존의 자바 컴포넌트를 쉽게 웹 서비스로 전환할 수 있도록 하며 새로 서비스를 작업할 때도 손쉽게 웹 서비스를 개발할 수 있도록 자바 API를 제공한다.

 

무엇보다 웹 서비스 개발에 있어서 JAX-RPC를 사용하는 가장 큰 의의는 서비스 제공자는 자바 플랫폼에서 개발된 서비스를 모든 플랫폼의 사용자에게 제공할 수 있으며, 서비스 사용자는 어떠한 플랫폼에 있는 웹 서비스라도 쉽게 사용할 수 있다는 것이다. 이것은 JAX-RPC가 제공하는 xrpcc라는 툴을 이용해서 자바 서비스 구현 내용에 해당하는 WSDL을 생성하고, xrpcc가 임포트된 WSDL을 사용하여 자바스텁을 생성하기 때문이다.

 

이러한 JAX-RPC는 요청과 응답 SOAP 메시징을 채택하고 있기 때문에 비동기적인 SOAP 메시징을 할 수 없다.

따라서 요청과 응답 모델을 이용하려는 응용 프로그램 개발에 적합하다.

참고 사이트 : JAX-RPC
- http://java.sun.com/xml/jaxrpc/
- JWSDP 설치 디렉토리/jaxrpc/docs/ReleaseNotes.html

1.3 스텁과 타이 클래스

스텁(Stub)과 타이(Tie) 개념은 JAX-RPC에만 있는 것이 아니다. 이 단어는 RMI, CORBA, DCE RPC와 같은 그 외 많은 분산 컴퓨팅 기술에도 사용되었다. 어떤 사람들은 ‘스텁과 스켈레톤(skeleton)’ 같은 용어가 익숙할 수도 있다. 스텁과 타이를 이해하기 위해서는 우선, 원격 프로시저 호출에서 무엇이 그렇게 흥미진진한 것인지를 이해하는 것이 중요하다. 원격 프로시저 호출의 내면 개념은 응용 프로그램이 객체 상의 메소드에 대해 호출하고, 그 객체의 실제 구현이 다른 프로세스 공간에 존재한다는 것이다.

 

이 프로세스들은 보통 네트워크 접속에 의해 분리된 각각의 머신에 위치하고 있다. 응용 프로그램은 메소드를 호출(클라이언트)할 때 그것이 실제로 원격 객체(서비스)에 대해 호출하는지를 알 필요가 없으며, 그 결과에 대해 걱정할 필요도 없다.

웹 서비스 클라이언트 응용 프로그램은 원격 객체에 대한 프록시처럼 동작하는 로컬 객체인 스텁을 갖고 있다 스텁 객체는 원격 객체와 동일한 메소드를 가지고 있지만 비즈니스 로직은 구현하지 않는다.

 

이러한 스텁은 합의 하에 메소드명과 그 매개변수를 정해진 포맷으로 패키징하며, 기반구조에 대한 인터페이스를 나타낸다. 이것을 마샬링(marshalling) 또는 인코딩이라고 부른다.

 

요청 SOAP 메시지는 HTTP에 의해 웹 서비스 시스템으로 전달되고, 웹 서비스 시스템에서는 이런 SOAP 메시지를 타이 클래스를 이용해서 원래의 원격 프로시저명과 인자를 얻어내어 서버 응용 프로그램에서 승인한 형태로 데이터를 복원해야 한다. 이 과정을 언마샬링(unmarshalling) 혹은 디코딩이라고 부른다.

 

수신자는 객체의 메소드를 호출하여 결과를 얻은 후 타이 클래스를 이용해서 응답 SOAP 메시지로 인코딩하여 발신자에게 보낸다. 발신자를 도착한 응답 메시지를 스텁 클래스를 이용해서 원래의 값을 얻어낸다.

 

다음은 웹 서비스가 배포된 이후의 스텁과 타이 클래스의 웹 서비스 구조이다.

런타임에서 이러한 서비스는 다음과 같이 동작한다.

1. 원격 프로시저를 호출하려면 클라이언트 응용 프로그램이 스텁의 메소드를 호출한다.

2. 스텁은 JAX-RPC 참조 구현 런타임에 있는 루틴을 실행한다.

3. 런타임은 원격 메소드 호출을 SOAP 메시지로 변환하고, 이 메시지를 HTTP 요청 형태로 서버에 전송한다.

4. 서버가 HTTP 요청을 수신하면 JAX-RPC 런타임이 SOAP 메시지를 추출하고 이를 다시 메소드 호출의 형태로 변환한다.

5. JAX-RPC 런타임 시스템은 타이 객체의 메소드를 호출한다.

6. 타이 객체가 서비스의 구현 메소드를 호출한다.

2. 웹 서비스 시스템 개발

 

2.1 시스템 개발 순서

JAX-RPC는 웹 서비스의 가장 전형적인 모습을 가진 자바 API이다. 전형적이라고 함은 웹 서비스의 가장 본질적인 요구 사항을 수렴하고 있다는 말인데 이는 바로 RPC이다. JAX-RPC는 웹 서비스를 그것도 RPC 방식으로 호출하고 결과를 얻기 위한 것으로 개발자들이 가장 많이 사용하는 API일 것이다. 웹 서비스 개발은 서비스를 제공하는 서버 부분과 서비스를 이용하는 클라이언트 부분으로 나눈다.

 

JAX-RPC API를 사용한 웹 서비스 서버 부분 개발은 다음과 같은 순서로 작성한다.

1. 원격 프로시저를 정의하는 서비스 인터페이스를 작성한다.

2. 원격 인터페이스를 구현한 클래스를 작성하고, 원격 프로시저의 실제 내용을 작성한다.

3. 웹 응용 프로그램 배치 기술자(Deployment Descriptors)를 작성한다.

4. 타이 클래스를 생성하기 위한 RMI interface 배치 기술자를 작성한다.

5. 타이 클래스 및 WSDL 문서를 생성한다.

6. 웹 서비스 정의를 패키징하고, 웹 컨테이너에 배치한다.

 

2.2 시스템 개발 방법

⑴ 서비스 정의 인터페이스 작성

서비스 정의 인터페이스는 서비스에서 원격 클라이언트가 호출하는 메소드를 정의한다. 이 인터페이스를 작성할 때는 다음과 같은 몇 가지 규칙을 지켜야한다.

 

► 반드시 패키지를 적용해서 작성한다.

► 서비스 정의 인터페이스는 java.rmi.Remote 인터페이스를 상속한다.

► 서비스 정의 인터페이스의 접근 제어자는 반드시 public이어야하고, 인터페이스 내부에 'public final static'과 같은 상수 constant 선언이 있으면 안 된다.

► 원격 호출 시 문제가 생길 경우에는 java.rmi.RemoteException이나 그 서브 클래스에 해당하는 예외를 발생시킨다.

► 메소드 매개변수나 결과 데이터 타입은 반드시 JAX-RPC 타입을 지원해야 한다.

(참고 http://java.sun.com/xml/jaxrpc/)

 

서비스 정의 인터페이스를 작성하는 문법은 다음과 같다.

서비스 정의 인터페이스 작성 문법

package 패키지명;

import java.rmi.Remote;
import java.rmi.RemoteException;

public interface 인터페이스명 extends Remote {
     /// Field
     /// Method
     public 반환형 메소드명 (인자형 인자명) throws RemoteException;
     ...
}

간단한 예제를 통해 JAX-RPC에 대해서 자세히 알아보기 위해 Hello 서비스를 간단히 구현해보자. 서비스의 원격 클라이언트는 sayHello 메소드를 호출하며, 이때 문자열 매개변수를 넘겨주고 다시 문자열을 반환 받는다.

Hello 서비스에서 sayHello를 정의한 서비스 정의 인터페이스인 HelloIF.java는 다음과 같이 작성한다.

HelloIF.java - 원격 프로시저 sayHello()를 정의한 인터페이스

package Hello;

import java.rmi.Remote;
import java.rmi.RemoteException;

public interface HelloIF extends Remote {
     /// Field
     /// Method
     public String sayHello (String s) throws RemoteException;
}

⑵ 서비스 구현 클래스 작성

서비스 정의 인터페이스를 구현하는 클래스는 다음과 같은 형식으로 작성한다.

서비스 구현 클래스 작성 문법

package 패키지명;

public class클래스명 implements 서비스_정의_인터페이스명 {
     /// Field
     /// Constructor
     public 클래스명() {
         내용;
     }
     /// Method
     /// 인터페이스에서 정의된 메소드 오버라이딩
     public 반환형메소드명 (인자형 인자명) throws RemoteException {
         내용;
     }
     ...
}

인터페이스를 구현하는 클래스를 작성할 때는 다음과 같은 사항들에 주의를 기울여야 한다.

► 서비스 정의 인터페이스를 구현하는 구현 클래스도 역시 패키지를 적용해야 한다.

► 구현 클래스의 접근 제어자는 반드시 public이어야한다.

► 생성자의 접근 제어자도 반드시 public이어야한다.

► 생성자는 인자가 없는 디폴트 생성자 형태로 작성되어야한다.

 

HelloIF.java를 구현하는 클래스를 HelloImpl.java라고 하고 다음과 같이 작성한다.

HelloImpl.java - 서비스 구현 클래스

package hello;

public class HelloImpl implements HelloIF {
     public String message = new String("Hello ");
     public String sayHello (String s) {
         return new String(message + s + "!");
     }
}

sayHello() 메소드는 매개변수를 받아서 “Hello”와 “!”를 처음과 마지막에 붙여 반환하도록 작성되었다.

 

서비스 정의 인터페이스와 구현 클래스가 모두 작성된 후에는 컴파일을 수행하여 바이트 코드를 생성한다.

 

⑶ 웹 응용 프로그램 배치 기술자 작성

배치 기술자는 웹 응용 프로그램 안에 있는(JSP 페이지나 서블릿과 같은) 웹 컴포넌트에 대한 웹 서버의 환경설정 정보를 제공한다. Hello 서비스의 경우 서블릿의 형태로 배치되므로, 배치 기술자에 이에 대한 정보를 기술해야 한다. 웹 응용 프로그램 배치 기술자는 항상 web.xml 파일이며, 비록 웹 서비스 시스템 실행 시 적용해야 할 내용이 없더라도 반드시 web.xml 문서는 존재해야 한다.

 

일반적으로 web.xml에 기술되는 대표적인 내용은 다음과 같다.

► 세션에 대한 정보

► URL 매핑에 대한 정보

► 초기화에 대한 정보

► Welcome File(디폴트 문서)에 대한 정보

 

web.xml 문서는 다음과 같은 형식으로 작성될 수 있다.

web.xml - 웹 응용 프로그램 배치 기술자

<?xml version="1.0" encoding="euc-kr"?>

<!DOCTYPE web-app
     PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
     "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>
     <display-name>HelloApplication</display-name>
     <description>Hello Application</description>
     <servlet>
         ...
     </servlet>
     <servlet-mapping>
         ...
     </servlet-mapping>
     <session-config>
         ...
     </session-config>
</web-app>

web.xml 문서의 루트 엘리먼트는 <web-app> 엘리먼트이며, 웹 서비스 시스템 배치 시 적용해야 할 내용들은 자식 엘리먼트 및 자손 엘리먼트로 작성한다. 자식 엘리먼트 및 자손 엘리먼트를 작성한 뒤 반드시 유효성 검사를 거쳐 올바른 문서인지를 확인해야 한다. 그렇지 않으면 웹 서비스 시스템이 동작하지 않는다.

참고: web.xml 문서의 구조와 작성 방법
http://java.sun.com/dtd/web-app_2_3.dtd

⑷ RMI 인터페이스 배치 기술자 작성

타이 클래스와 WSDL 문서를 자동으로 생성하기 위해서는 RMI interface 배치 기술자인 jaxrpc-ri.xml 문서를 작성해야 한다. 이 문서에는 서비스 정의 인터페이스와 구현 클래스의 정보 및 웹 서비스 시스템의 종점 URL에 대한 정보가 기술된다.

jaxrpc-ri.xml - RMI 인터페이스 배치 기술자

<?xml version="1.0" encoding="euc-kr"?>
<webServices
         version="1.0"
         xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/dd"
         targetNamespaceBase="원격프로시저의 네임스페이스명"
         typeNamespaceBase="구조체에 대한 네임스페이스명">

     <endpoint
         name="웹 서비스 시스템 이름"
         interface="서비스 정의 인터페이스명"
         implementation="구현 클래스명"/>

         <endpointMapping
            endpointName="웹 서비스 시스템 종점명"
             urlPattern="URL 경로"/>
</webServices>
targetNamespaceBase 속성에는 웹 서비스 클라이언트가 원격 프로시저를 호출할 때 사용해야 할 네임스페이스명을 기술한다.
typeNamespaceBase 속성에는 웹 서비스 클라이언트가 구조체를 사용해서 원격 프로시저를 호출할때 사용해야 할 네임스페이스명을 기술한다.
<endpoint> 엘리먼트에는 웹 서비스 시스템의 원격 인터페이스와 구현 클래스의 이름 및 웹 서비스 시스템의 이름을 기술해 준다.
<endpointMapping> 엘리먼트에는 웹 서비스 클라이언트가 바인딩할 웹 서비스 시스템의 종점 URL을 기술해 준다.

Hello 웹 서비스 시스템에 적용할 jaxrpc-ri.xml 문서는 다음과 같이 작성할 수 있다.

jaxrpc-ri.xml - Hello 웹 서비스 시스템을 위한 배치 기술자

<?xml version="1.0" encoding="euc-kr"?>
<webServices
         version="1.0"
         xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/dd"
         targetNamespaceBase="http://localhost:8080/hello/webservice/wsdl"
         typeNamespaceBase="http://localhost:8080/hello/webservice/type">

     <endpoint
         name="webservice"
         interface="hello.HelloIF"
         implementation="hello.HelloImpl"/>

     <endpointMapping
         endpointName="webservice"
         urlPattern="/webservice"/>
</webServices>

⑸ 서비스 정의 패키징

서비스 정의는 WAR 파일 형태로 패키징된다. WAR 파일은 쉽게 배포하고 설치될 수 있다는 특징이 있으며 JAX-RPC의 경우 WAR 파일은 다음과 같은 파일을 포함한다.

 

► 하나 이상의 서비스 정의 인터페이스

각각의 서비스 정의는 단일 인터페이스이다. 그렇지만 WAR 파일은 하나 이상의 서비스에 대한 파일을 포함한다. Hello 서비스의 경우 HelloIF.class 파일이 서비스 정의 인터페이스 부분이다.

► 인터페이스를 구현한 하나 이상의 서비스 정의 클래스

각각의 서비스 정의 인터페이스에 대해 서비스 구현 클래스를 제공해야 한다. Hello의 경우 HelloImpl.class 파일이 여기에 해당한다.

► 서비스 구현 클래스가 요구하는 파일

각종 헬퍼 클래스들이나 JPEG 이미지, XML 문서 등이 여기에 해당한다. HelloImpl 클래스에는 여기에 대한 파일이 없다.

► 웹 응용 프로그램 배치 기술자

모든 WAR 파일은 web.xml을 요구한다.

► 서비스를 기술하는 WSDL 파일(옵션)

xrpcc 툴을 실행하면 WSDL 파일을 얻을 수 있다.

 

⑹ 타이 클래스 및 WSDL 문서 추가

웹 서비스 시스템은 요청 SOAP 메시지를 디코딩하기 위해 타이 클래스를 이용한다. 그래서 타이 클래스를 생성하고, WAR 파일에 추가해야 한다.

기존의 WAR 파일 속에 타이 클래스를 자동으로 생성시키기 위해서는 wsdeply.bat를 이용할 수 있으며, 이 경우에 타이 클래스뿐만 아니라 WSDL 문서까지 자동으로 생성되어 WAR 파일에 추가된다.

 

⑺ 웹 컨테이너에 배치

웹 서비스 시스템의 최종 산물인 WAR를 생성한 후, 톰캣과 같은 서블릿 컨테이너 또는 J2EE 응용 프로그램 서버의 서블릿 컨테이너에 배치를 하면 클라이언트의 원격 프로시저 호출을 수행할 준비가 모두 끝나게 된다.

 

지금까지 살펴 본 Hello 웹 서비스를 위한 디렉토리 구조와 관련 파일들의 위치를 정리하면 다음과 같다.

3. JAX-RPC 데이터 타입

 

자바 언어에서 제공되는 모든 데이터 타입이 스텁과 타이 클래스에 의해 인코딩과 디코딩 되지 않는다.

즉 J2SE에 있는 모든 클래스 유형을 JAX-RPC는 지원하지 않는다는 것이다. 따라서 JAX-RPC를 사용하여 웹 서비스를 제공할 때에는 JAX-RPC에서 지원하는 자바 타입을 사용해야 하는데 JAX-RPC에서 지원하는 자바 타입은 다음과 같다.

 

⑴ 자바 기본 데이터 타입

► boolean, short, int, long, float, double

 

⑵ J2SE에서 자바 클래스 타입

► java.lang 패키지 - Boolean, Byte, Double, Float, Integer, Long, Short, String

► java.math 패키지 - BigDecimal, BigInteger

► java.util 패키지 - Calendar, Date

► javax.xml.namespace.Qname, java.net.URI

 

⑶ Collection 타입의 클래스

java.util.Collection 인터페이스는 객체를 저장하고, 저장된 객체를 얻어내는 메소드를 정의하고 있다.

Collection 인터페이스를 구현한 클래스 중에서 다음과 같은 클래스는 JAX-RPC에서 지원한다.

► java.util.List 인터페이스 - ArrayList, LinkedList, Stack, Vector

► java.util.Map 인터페이스 - HashMap, Hashtable, Properties, TreeMap

► java.util.Set 인터페이스 - HashSet, TreeSet

 

⑷ 배열

기본적인 JAX-RPC 지원 타입을 사용한 배열, 예를 들어 int[], String[], double[][]와 같은 배열은 JAX-RPC에서 지원한다.

 

⑸ 예외

► java.rmi.RemoteException

► java.lang.Exception

 

⑹ 사용자 정의 클래스

프로그래머가 직접 정의해서 사용하는 클래스들은 다음과 같은 조건을 만족하면 JAX-RPC의 반환형 또는 매개변수형으로 사용될 수 있다.

► 반드시 public 생성자를 가져야한다.

► Remote 인터페이스를 (직접적이건 간접적이건) 구현하지 않아야 한다.

► 모든 필드의 데이터 타입은 JAX-RPC가 지원하는 타입으로 구성되어야 한다.

► 필드는 final 또는 transient로 선언되지 않아야 한다.

► 필드는 private 또는 protected 접근 제어자를 가져야 한다.

► 필드 값을 설정하고 값을 얻기 위한 setter 메소드와 getter 메소드를 가져야 한다.

► setter/getter 메소드의 접근 제어자는 public이어야 한다.

 

다음은 원격 인터페이스의 매개변수 또는 반환값의 데이터 타입으로 사용될 수 있는 사용자 정의 클래스(“book.class”)의 예를 보여주고 있다. 즉 위에서 정의한 조건을 모두 만족하도록 클래스를 작성한 예제이다.

package book;

public class Book {
     /// Field
     private String title;
     private int price;
     /// Constructor
     /// Method
     public void setTitle(String title) { this.title = title; }
     public void setPrice(int price) { this.price = price; }

     public String getTitle() { return title; }
     public int getPrice() { return price; }
}

정리하기

① 웹 서비스 시스템이란 인터넷에 연결되어 있는 원격 클라이언트에 의해 호출될 수 있는 메소드들의 집합으로 서버측 응용 프로그램을 의미한다.

 

② JAX-RPC는 XML-based protocol인 SOAP을 사용하고 WSDL의 생성과 해석을 지원하기 때문에 상호 운용이 가능하며, 요청과 응답 모델에 적합하다.

 

③ JAX-RPC 웹 서비스 시스템은 서블릿으로 작성된 한 개의 웹 응용 프로그램으로서 웹 컨테이너에 배치되고 실행된다.

 

④ 스텁은 원격 객체와 동일한 메소드를 가지지만 비즈니스 로직을 보유하지 않고 있으며, 타이는 객체의 메소드를 호출하고 그 결과를 전달한다.

 

⑤ 웹 서비스는 원격 인터페이스 작성, 구현 클래스 작성, 배치 기술자 작성, 타이 클래스 및 WSDL 문서 생성, 패키징 및 배치의 과정을 거쳐서 개발된다.

 

⑥ 인터페이스에서 정의되는 원격 프로시저의 매개변수와 반환값의 데이터 타입은 JAX-RPC에서 지원되는 데이터 타입이어야 한다.

'정보과학 > 웹서비스특론' 카테고리의 다른 글

웹 서비스 명세화, WSDL  (0) 2023.09.12
웹 서비스 클라이언트 개발  (1) 2023.09.11
SOAP API  (0) 2023.09.08
SOAP  (0) 2023.09.07
XML 스키마 (2)  (0) 2023.09.06

관련글

티스토리툴바