바라기의 이야기

[펌-출처] : http://www.imaso.co.kr/?doc=bbs/gnuboard_pdf.php&bo_table=article&page=3&wr_id=1641&publishdate=20031001

웹 서비스의 진정한 의의는 플랫폼에 상관없이 시스템을 통합할 수 있는 기능을 제공한다는 것이다. 하지만 지금까지 소개된 대부분의 자료는 MS 기반이나 자바 기반에서 각각의 시스템에 따른 웹 서비스 구현에 중점이 맞춰져 있었다. 이 연재를 통해 웹 서비스를 이용한 MS 플랫폼과 자바 플랫폼의 연동 가능성을 살펴보고 연동시 발생하는 문제점을 해결하여 플랫폼 통합의 진정한 웹 서비스 시스템을 구현해 보자.

실전!강의실 >> 웹 서비스

연+재+순+서
1회 2003.10｜현실로 다가온 웹 서비스, MS와 자바 플랫폼의 연동
2회｜웹 서비스를 이용한 이기종간 오브젝트 전달
3회｜SOAP의 Attachment 기능을 이용한 이기종간 파일 전송


연+재+가+이+드
운영체제 | 윈도우
웹 서버 | IIS, 아파치 톰캣 4. 1. 24
개발도구 | 아파치 AXIS 1.1 , MS SOAP 툴킷 3.0, JDK, 비주얼 베이직
기초지식 | XML, 자바, 비주얼 베이직, 웹 서비스에 대한 기본 개념
응용분야 | 웹 서비스를 이용한 시스템 통합

이기종 플랫폼에서 웹 서비스 연동 1
현실로 다가온 웹 서비스,
MS와 자바 플랫폼의 연동


이영석 |lzerosuk@chollian.net

필자는 XML 엔지니어로 활동하며 XML 파서를 이용한 XML 에디터 개발, XSLT 기반의 CMS 시스템을 개발했다. 현재 웹 서비스 기반의 BPMS 시스템을 개발하고 있다.

웹 서비스를 아는가? 아직도 웹 서비스를 웹 기반의 HTML 컨텐츠로 알고 있는 IT 개발자가 있을까? SOAP을 비누로 오인하는 개발자가 있을까? 이제 많은 개발자들이 SOAP, WSDL, UDDI 등의 세부적인 웹 서비스 구성요소까지는 아니더라도 SOAP이 XML 기반의 프로토콜이라는 것 정도는 알고 있을 것이다. 또 일부 개발자들은 이미 웹 서비스를 적용한 프로젝트를 진행중이거나, 새로운 프로젝트에 웹 서비스 적용을 고려하고 있을 것이다.
한국전산원의 자료(2002년 12월)에 따르면 국내 매출규모기준 상위 1000개의 기업중 100개 기업을 대상으로 웹 서비스에 대한 인지도와 관심도를 조사한 결과 98%의 기업이 “알고 있거나 준비중”이라고 대답했다. 또한 가트너의 연구 보고서는 2004년까지 글로벌 2000 기업들 중 70%가 웹 서비스 실험을 완료할 것이라고 말한 바 있다. 이처럼 웹 서비스 기술은 현실로 다가오고 있다.
이 연재에서는 현실로 다가오는 웹 서비스에 대응하기 위해 웹 서비스 기본 개념의 이해를 뛰어넘어 실제 프로젝트 수행을 준비할 때 발생하는 현실적인 문제를 중심으로 웹 서비스 구현 방안을 살펴보고자 한다. 웹 서비스의 목적이 이기종 플랫폼의 연동인 것처럼 이 연재의 중심을 이기종 플랫폼의 연동 가능성과 방안, 그리고 발생할 수 있는 문제에 대한 해결책의 모색에 두도록 하겠다. 웹 서비스의 기본적인 개념에 대한 논의는 가급적 생략하고 현실적인 구현 이슈에 대해 집중하도록 하겠다. 기초적인 웹 서비스의 개념과 웹 서비스를 구성하는 각 컴포넌트의 세부 사항에 대해서는 이전에 소개된 다른 자료를 참고하기 바란다.

웹 서비스 플랫폼을 위한 툴킷
SOAP, WSDL, UDDI로 구성된 웹 서비스 플랫폼 구성 컴포넌트 중 가장 핵심은 SOAP이다. 이기종 플랫폼 간 상호연동 여부는 각 제품이 제공하는 SOAP 메시지가 호환되는가 여부에 달려있다고 하겠다. SOAP의 구현을 가능하게 하는 툴킷은 상당히 많다. 그러나 아직도 각 벤더의 툴킷이 세부적으로 지원하는 SOAP, WSDL 등의 스펙이 다르기 때문에 환경을 구축할 제품의 선택에 앞서 툴킷간에 상호운용성이 보장되는가를 가장 먼저 살펴야 한다. 자바 환경을 구현하기 위해 아파치 프로젝트의 AXIS 1.1(Final Release)을 선택했으며, MS 기반의 환경을 구현하기 위해서 MS SOAP 툴킷 3.0을 선택했다. 많은 SOAP 툴킷 중에 각 플랫폼을 대표한다고 생각하는 최신 버전의 제품을 선정했다.
이 연재는 다음의 환경에서 상호운용성에 포인트를 맞추고 있으며, 동일 제품이라도 선택된 버전과 다른 버전에서의 결과는 본문 내용과 조금 차이가 있을 수 있다.

웹 서비스를 이용한 기본형 데이터 교환
서 두에 언급한 것처럼 이번 연재의 핵심 키워드는 이기종 플랫폼의 연동이다. 시스템간에 주고 받는 데이터는 다양하다. Int, char, short, double, float 등의 기본형(primitive) 데이터가 있으며, array, structure, type, class, javaBean 등의 복합형(complex) 데이터가 있다. 또한 파일을 전송하기 위한 바이너리 데이터 등이 있을 수 있다. 이번 호에는 기본형 데이터 전달을 살펴보고 2회, 3회에 걸쳐 복합형 데이터 전달, 바이너리 데이터 전달 등을 살펴보겠다.

자바의 AXIS 환경 구성
먼저 AXIS를 위한 환경을 구성하자. AXIS는 HTTP로 들어오는 SOAP 메시지를 처리하기 위한 방법으로 서블릿이 제공되고 있기 때문에 JSP/Servlet 컨테이너가 필요하다. AXIS 서버를 위한 JSP/Servlet 컨테이너는 톰캣을 사용했다. 물론 SOAP 메시지가 반드시 HTTP를 이용해 전달될 필요는 없다. SOAP 메시지는 HTTP는 물론 SMTP, TCP/IP 등의 다양한 프로토콜을 통해 전달될 수 있다. 하지만 웹 서비스라는 이름처럼 웹 환경에서 HTTP를 이용해 SOAP 메시지를 전달하는 것이 가장 일반적인 구현 접근 방법이며, 이러한 HTTP 기반의 구현 환경에서 분산환경에서 시스템 통합시 문제가 되는 방화벽을 통한 접근 문제를 해결할 수 있는 등 웹 서비스의 장점을 십분 살릴 수 있다.
xml.apache.org에서 AXIS 1.1을 다운받고 압축을 풀면 <화면 1>과 같은 폴더를 볼 수 있다. 간단히 폴더의 구성을 살펴보겠다. Docs 폴더에는 관련 문서와 API가 있다. lib 폴더에는 AXIS 환경을 구성하기 위한 라이브러리가 담겨 있다. Webapps 폴더에는 JSP/ Servlet 컨테이너에 등록하기 위한 웹 애플리케이션이 담겨 있다. 톰캣의 Webapps에 AXIS의 Webapps 안에 있는 AXIS 폴더를 복사해 넣고 톰캣의 Server.xml을 고쳐서 AXIS를 등록하는 것으로 서버쪽 환경 준비를 마친다. AXIS의 Webapps/axis/WEB-INF/lib에는 앞서의 상위의 lib 폴더와 동일한 라이브러리가 담겨 있기 때문에 별도의 서버를 위한 환경 설정은 필요없다. 클라이언트의 환경을 위해서는 lib 폴더의 jar를 CLASSPATH에 담아주면 된다.
SOAP 은 XML 메시지이기 때문에 XML 파서를 기본으로 사용하는데 Xerces를 권장하고 있다. 톰캣에는 Xerces 파서가 라이브러리에 포함되어 있기 때문에 톰캣 4.1.x 이상의 버전 환경이라면 다른 준비가 필요없으며, 클라이언트쪽에는 역시 CLASSPATH에 Xerces의 jar을 등록하는 것으로 환경 준비를 마친다(톰캣 4.1.12와 AXIS와는 궁합(?)이 잘 맞지 않으므로 다른 버전의 톰캣을 사용하는게 좋다). 좀더 자세한 환경설정은 AXIS의 Docs폴더 아래 install.html을 참조한다.
준비된 서버 환경을 테스트하기 위해 브라우저를 이용해 AXIS의 메인 페이지를 열어본다. 메인 페이지에 있는 ‘Validate the local installation’s configuration’을 통해서 환경이 제대로 설정되었는지 확인한다. <화면 2>를 통해서 정상적으로 설정되었는지를 확인할 수 있다.

자바 AXIS를 이용한 예제
환경준비를 마쳤으면 등록할 서비스를 만들어 보자. 기본형 데이터를 매개변수와 리턴 값으로 갖는 메쏘드 2개를 담은 클래스를 만들어 보자.
작 성한 자바 파일을 컴파일한 후 ‘PrimitiveDataTest.class’를 톰캣에 등록한 AXIS 폴더의 ‘tomcatwebappsaxisWEB-INF classes’ 다음 위치에 복사한다. 작성한 클래스를 AXIS를 통해 웹 서비스로 등록하기 위해선 WSDD를 통해 AXIS에 등록해야 한다. 등록된 웹 서비스 리스트에서 ‘WSDL’을 선택하면 등록된 서비스의 WSDL을 얻을 수 있다.
다음의 내용을 담은 deploy.wsdd 파일을 생성한 후에 AXIS의 라이브러리를 CLASSPATH에 설정하고 AXIS의 AdminClient를 이용해서 wsdd를 등록한다.

> java org.apache.axis.client.AdminClient deploy.wsdd

등록이 성공적으로 되었는지를 확인하기 위해서는 AXIS의 메인 페이지에서 ‘View the list of deployed Web services’를 선택하여 등록된 웹 서비스 목록을 확인한다(<화면 3>).

WSDL의 역할
웹 서비스에서 WSDL의 역할은 중요하다. WSDL은 등록된 서비스의 명세서와 같은 역할을 한다. 즉 등록된 서비스에는 어떤 메쏘드가 있는지, 이 메쏘드를 사용하기 위해서는 어떤 타입의 매개변수가 몇 개 필요한지, 메쏘드가 실행된 후 결과 값은 어떤 타입인지 등 서비스를 받기 위해 필요한 모든 명세가 담겨 있다. 마치 CORBA의 IDL과 같은 역할을 한다고 하겠다. 웹 서비스를 제공하는 서버의 입장에서는 반드시 이 명세서를 작성해 서비스를 받을 클라이언트에게 서비스 명세를 알려줘야 한다. 이 WSDL은 사람이 직접 손으로 작성할 수도 있지만 대부분의 웹 서비스 툴킷을 통해 자동으로 코드 → WSDL, WSDL → 코드의 변환 작업이 가능하다. 개발자가 관여할 필요없이 서버 시스템은 등록된 클래스를 분석해 WSDL을 생성하고 그렇게 생성된 WSDL은 클라이언트 시스템에서 자동으로 서비스를 받을 수 있는 프록시 코드로 변환된다.
결국 WSDL은 개발자가 보는 문서의 의미보다는 서버와 클라이언트 시스템 간에 주고 받는 시스템이 보는 문서로서의 의미가 더욱 커졌다. 즉 개발자는 WSDL에 대해서 잘 몰라도 웹 서비스 시스템을 구현할 수 있다는 말이다(다음 호 연재에서 WSDL을 자세히 분석하는 시간을 가질 것이다).

클라이언트 생성
이제 서버에 등록된 서비스를 이용하는 클라이언트 코드를 만들어 보자. 일반적으로 자바 환경에서 클라이언트를 작성하는 방법은 크게 두 가지로 나눌 수 있다. AXIS의 call 객체를 직접 생성해 호출할 메쏘드 이름과 매개변수를 call 객체에 설정하여 작성하는 방법과 ‘WSDL To Java’ 툴을 이용해 WSDL을 클라이언트 프록시 코드(Stub class)로 변환하여 이 프록시 코드의 메쏘드를 호출하는 형태로 작성하는 방법이다.
다음은 AXIS의 call 객체를 이용해 서비스를 호출하는 클라이언트 코드이다. 다음의 코드를 ‘SampleClient01.java로 저장하고 컴파일한 후 실행한다. 결과는 <화면 4>와 같다.
자바 환경에서 클라이언트를 작성하는 다른 방법은 WSDL을 기반으로 하여 자동으로 클라이언트 프록시 코드를 생성해 이것을 이용하는 것이다.
< 그림 1>처럼 ‘WSDL To java’ 툴을 이용해 생성된 프록시는 클라이언트가 서버에 등록된 서비스를 호출하는 것을 대행한다. 클라이언트 코드에서는 프록시의 메쏘드를 호출하는 것만으로 서버의 서비스를 호출할 수 있다. 가장 먼저 해야 할 일은 AXIS에서 제공하는 WSDL2Java.class를 이용해서 Stub 클래스를 생성하는 것이다. WSDL2Java 실행시 매개변수로 WSDL 파일이나 WSDL이 있는 곳의 URL을 준다. 앞서 AXIS에 등록된 서비스의 WSDL을 생성해 보여주었던 URL을 매개변수로 넣어 Stub을 생성한다(<화면 5>).

>java org.apache.axis.ws이.WSDL2Java http://[ServerIP]/axis/services/PrimitiveData
Test?wsdl

자바의 패키지 네이밍 룰에 따라서 IP의 역순으로 패키지를 구성한 후 Stub이 생성된 것을 볼 수 있다. 생성된 자바 클래스는 다음과 같다.

◆ 포트 이름.java : 서버가 제공하는 서비스를 메쏘드로 제공하는 인터페이스. 포트 객체이다.

◆ 서비스 이름.java : 포트 객체를 할당 받을 수 있는 메쏘드를 제공하는 인터페이스
◆ 서비스 이름 + Locator.java : 서버의 서비스 로케이션(EndPointURL)에 서비스를 요청하는 클래스
◆ 바인딩 이름 + Stub.java : 실제 호출을 대행하는 클래스

이 중 포트 역할을 하는 PrimitiveDataTest.java를 살펴보자. 이 클래스는 자바의 인터페이스 형태로 서버에서 제공하는 서비스를 메쏘드 형태로 담고 있다. 프로그래머는 이 인터페이스가 제공하는 메쏘드를 호출하는 형태로 클라이언트를 작성할 수 있다. 다음은 이 Stub 파일들을 이용한 클라이언트 코드이다.
Stub을 이용한 클라이언트 코드는 직관적이며 쉽게 코드를 작성할 수 있다. 실행한 결과는 <화면 6>과 같이 앞서의 예제와 동일하다.

MS SOAP 툴킷 환경 구성
이 제는 MS 기반의 웹 서비스 환경을 살펴보자. 서버 환경은 MS의 IIS(Internet Information Server)를 이용해 구성하겠고 클라이언트 코드는 비주얼 베이직을 이용해 작성하겠다. IIS와 비주얼 베이직이 준비되었으면 MS SOAP 툴킷 3.0을 설치하자. MS SOAP 툴킷을 이용한 클라이언트 코드는 윈도우 98 이상에서 잘 동작하지만 서버 환경을 위해서 2000 이상에서 작업할 것을 권한다. 기본적인 요구 환경은 다음과 같다.

◆ 비주얼 스튜디오 인스톨러 1.1 이상 설치 환경에서 SOAP 툴킷의 설치가 가능
◆ 인터넷 익스플로러 5.01 이상
◆ MSXML 4.0 이상

MS SOAP 툴킷 3.0을 설치하면 <화면 7>과 같은 구성 요소들이 설치된다. WSDL을 자동으로 생성하는 WSDL 제너레이터, ISAPI (Internet Server API), 디버깅을 위한 Trace 도구, 그리고 MS XML 4.0 파서가 설치된다.
서비스를 제공하기 위해 서버쪽에 먼저 IIS에 가상 디렉토리를 정해야 한다. 편의상 C:MSSOAPServer 폴더를 MSSOAPServer라는 가상 디렉토리로 잡는다고 가정한다. 가상 디렉토리를 설정한 후 마지막으로 가상 디렉토리에 ISAPI 핸들러를 등록한다. 이것은 가상 디렉토리로 들어오는 SOAP 메시지를 처리하는 역할을 한다. MS SOAP 툴킷이 설치된 C:Program FilesMSSOAPBinaries 폴더로 이동한다. 그리고 다음과 같은 명령으로 등록한다.

Soapvdir.cmd UPDATE MSSOAPServer

성공적으로 등록되었다면 <화면 8>과 같은 정보를 볼 수 있다.

MS SOAP 툴킷을 이용한 예제 - 서버에 서비스 등록하기
앞 서 AXIS에 등록한 서비스와 동일한 역할을 하는 서비스를 만들어 보자. 비주얼 베이직을 열어서 액티브X DLL 프로젝트를 선택한다. 프로젝트 이름을 ‘PrimitiveDataTest’라고 하고 클래스 이름은 ‘vbSample01’로 한다. 물론 여러분이 원하는 이름을 사용해도 상관없다. 프로젝트 속성 메뉴를 열어서 ‘무인실행’과 ‘메모리에 보유’를 선택한다. c:MSSOAPServer 위치에 다음의 코드를 가진 클래스와 프로젝트를 저장한다.
‘DLL 만들기’를 이용해서 PrimitiveDataTest.dll을 만들면 서버에 등록되어 서비스될 클래스 준비는 끝난다.

WSDL 생성하기
다 음으로 할 작업은 WSDL을 만드는 것이다. 앞서 AXIS의 경우에는 클래스를 AXIS에 등록하는 작업만으로 WSDL이 생성되었지만 MS SOAP 툴킷을 이용하는 경우에는 WSDL 제너레이터를 이용해 WSDL을 만들어야 한다. WSDL 제너레이터를 실행시키고 ‘Select the COM .dll file to analyze’까지 next 버튼을 눌러 이동한다. 서비스 이름을 입력하라는 곳에 앞서의 예제와 동일하게 ‘Primitive DataTest’를 입력하고 Local path에 생성한 dll을 선택하고 next 버튼을 누른다. 서비스를 선택하는 곳에서 hello와 sum 메쏘드를 선택하고 next를 누른다. SOAP listener information에서 Listener URI에 http://serverIP/MSSOAPServer를 입력하고 type에는 ISAPI를 선택하고 next 버튼을 누른다. Specify URIs는 기본 값을 특별히 변경할 필요가 없다. 다음 호에서는 이 값들을 변경하는 일이 있을 것이다. 일단은 next 버튼을 눌러 다음 메뉴로 이동한 후 저장할 위치를 선택하고 finish 버튼을 눌러 완료한다.
다음의 4개의 파일이 생성된 것을 볼 수 있다.

◆ PrimitiveDataTest.WGen
◆ PrimitiveDataTest.WSDL
◆ PrimitiveDataTest.wsml
◆ PrimitiveDataTestClient.wsml

wsml 이라는 확장자를 가진 두개의 파일이 있다. wsml은 Web Service Meta Language의 약자로 서비스를 위한 메타 데이터를 담고 있는 MS 기반의 웹 서비스를 위한 특별한 파일이다. ‘서비스명.wsml’을 열어 보면 서비스되는 메쏘드(operation)에 대한 정보가 담겨 있다. 일반적으로 ‘XXXClient.wsml’은 실행될 클라이언트 쪽에 위치되어야 하지만 기본형 데이터의 전달시에는 특별한 의미는 없다.
생성된 WSDL의 경우 앞서 AXIS가 생성한 WSDL과 크게 다르지 않은 것을 알 수 있다. WSDL에 대한 구체적인 내용에 대해서는 AXIS와 MS SOAP 툴킷을 연동하는 예제에서 살펴보자.

클라이언트 생성
클 라이언트 코드의 작성에 앞서서 클라이언트의 실행환경을 설정하자. 클라이언트의 실행에 있어서 필요한 파일은 wsdl과 wsml이다. 두 개의 파일은 앞서 WSDL 제너레이터에 의해 생성되었다. 이 두 파일을 클라이언트가 실행될 곳에 복사해 넣는다.
MS SOAP 툴킷을 이용해 클라이언트를 작성하는 방법에도 크게 두 가지가 있다. 하나는 High-Level API를 이용하는 것이고, 다른 하나는 Low-Level API를 이용하는 것이다. 먼저 High-Level API를 이용한 코드를 살펴보자. 다음의 코드는 비주얼 베이직 스크립트를 이용하였다.
MSSOAP.SoapClient30이라는 객체를 생성하고 초기화한 후 원하는 서비스를 호출하는 간단한 코드이다. 이때 주의깊게 볼 코드는 다음의 부분이다.

Call SoapClient3.mssoapinit(“PrimitiveDataTest.wsdl”, “”, “”)

mssoapinit의 문법은 다음과 같다.

Sub mssoapinit(par_WSDLFile As String,_
[par_ServiceName As String],_
[par_Port As String],_
[par_WSMLFile As String])

첫 번째 매개변수는 WSDL 파일이며 두번째 매개변수는 WSDL 파일 내에 서비스받을 서비스 이름이고, 세번째는 port 이름이다. 일반적으로 WSDL 내에 하나의 서비스만이 기술되는 경우 생략될 수 있는데, 여러 개의 서비스가 기술되었을 경우에는 첫번째 서비스명과 포트명을 가리키게 된다. 마지막 매개변수는 앞서 설명한 클라이언트를 위한 WSML 파일이다. 복합형 데이터의 전송의 경우에는 중요하지만 기본형의 경우에는 생략되어도 상관없다.
다음의 코드를 가진 파일을 ‘MSSampleClient01.vbs’로 저장한다. 실행은 다음과 같은 명령어를 콘솔에 입력하여 실행한다. 다시 한번 말하지만 WSDL 파일은 실행되는 위치에 있어야 한다(만약 실행 폴더에 없는 경우에는 ‘윈도우시스템/system32’에서 찾으려 한다). <화면 9>은 예제를 실행한 결과이다.
> cscript MSSampleClient01.vbs

이제 Low-Level API를 살펴보자. 코드는 다음과 같으며 마찬가지로 비주얼 베이직 스크립트이다.
Low-Level API에서는 sum 서비스만을 호출하고 있다. Low-Level API를 사용한 클라이언트의 가장 큰 특징은 SOAP 메시지를 코드에서 생성한다는 것이다. 즉 High-Level API에서는 SoapClient30 객체가 WSDL을 참조하여 서비스받기 위해 서버에게 전달하는 메시지를 자동으로 생성한 반면에 Low-Level API에서는 프로그래머가 주고 받을 SOAP 메시지를 이해하고 코드에서 직접 SOAP 메시지를 생성해야 한다.
<그림 2>처럼 SoapClient30은 SoapSerializer30과 Soap Reader30, WSDLReader30을 이용해서 구현되어 있다. High-Level API인 SoapClient30을 사용하는 대신에 Low-Level API인 SoapSerializer30과 SoapReader30을 이용해서 클라이언트를 구현할 수 있다. MS SOAP 툴킷에 대한 자세한 내용은 ‘MS SOAP Toolkit User Guide’를 참조하길 바란다.

AXIS와 SOAP 툴킷의 연동
지금까지 자바와 MS 플랫폼에서 각각 실행되는 예제를 살펴보았다. 이제 클라이언트와 서버를 두 플랫폼에서 연동해 보자. 먼저 자바를 서버 플랫폼으로, MS를 클라이언트 플랫폼으로 하는 경우를 살펴보자.
앞 서 예제에서 AXIS에 등록한 PrimitiveDataTest를 서버의 서비스로 사용하고, 비주얼 베이직 스크립트로 작성한 코드를 클라이언트로 사용한다. 일반적으로 WSDL은 서비스를 제공하는 서버로부터 얻어야 한다. AXIS가 제공하는 WSDL을 이용해 클라이언트를 실행해 보자. 브라우저를 열어 AXIS가 등록된 서비스에 대해 생성한 WSDL이 있는 페이지로 이동한다. 그 페이지를 ‘다른 이름으로 저장’ 메뉴를 이용해 클라이언트가 참조하는 ‘PrimitiveDataTest.wsdl’로 저장한다. MSSampleClient01.vbs를 실행하면 정상적으로 연동되는 것을 확인할 수 있다. WSDL을 사용하지 않고 Low-Level API로 작성된 클라이언트의 경우, Connector.Property(“EndPointURL”)의 값을 AXIS의 서비스 로케이션인 ‘http://203.238.197.211:8080/axis/ services/PrimitiveDataTest’로 바꿔주는 것만으로 연동이 가능하다.
반대로 MS를 서버 플랫폼으로 운영하는 경우는 조금 복잡하다. MSSOAPToolkit은 클라이언트의 요청시 헤더에 포함된 ‘SoapAction’의 값을 중요한 요소로 생각하기 때문에 자바로 작성된 클라이언트에서 이 값을 정확히 맞춰주어야 한다. 다음의 코드는 MS의 서버 서비스를 호출하기 위해 SampleClient01.java를 수정한 것이다.
WSDL2Java 툴을 이용해서 Stub을 생성하여 클라이언트를 작성하는 경우에는 특별히 고려할 사항이 없다. AXIS의 WSDL을 이용해 작업했던 것과 동일하게 WSDL 제너레이터로 생성된 WSDL을 이용해 Stub을 생성하여 코드를 작성하면 MS SOAP 툴킷과 연동하는 클라이언트를 만들 수 있다. 이와 같은 방법으로 기본형 데이터 전달의 경우에는 쉽게 두 플랫폼의 애플리케이션을 연동할 수 있다.

기본형 데이터 연동을 마치며
웹 서비스 툴킷을 제공하는 업체가 표준화된 SOAP 인코딩 규칙을 지킨다면 이와 같이 두 플랫폼이 SOAP을 통해 연동되는 것은 당연한 결과이다. WSDL의 목적은 서버가 제공하는 서비스 명세를 서비스받고자 하는 클라이언트에게 알려주는 데 있다. 클라이언트를 작성하는 방법은 크게 두 가지로 나눌 수가 있는데, WSDL을 이용하는 경우와 이용하지 않는 경우이다. 자바의 경우 WSDL을 이용할 때 Stub을 생성해 직관적인 프로그래밍을 할 수 있으며 MS SOAP 툴킷의 경우 High-Level API를 사용해 간단한 코드로 프로그래밍할 수 있다. WSDL을 사용하지 않아도 자바의 AXIS나 MS SOAP 툴킷 모두 프로그래밍이 가능하지만 서버가 제공하는 서비스에 대해 프로그래머가 정확하게 알아야 한다는 어려움이 있다.
이번 호에서는 기본형 데이터의 전달을 통한 연동이 플랫폼에 상관없이 쉽게 가능하다는 것을 테스트를 통해 살펴보았다. 다음 호에서는 배열, 사용자가 정의한 객체 등의 복합형 데이터를 자바의 AXIS와 MS SOAP 툴킷을 이용해 상호 전달하는 방안을 살펴보겠다. 그리고 복합형 데이터의 전달에 중요한 역할을 하는 WSDL에 대해서 자세히 살펴보겠다. 이번 호에서 다룬 소스 코드를 ‘이달의 디스켓’으로 제공하니 참조 바란다.

정리 | 이종림 | nowhere@korea.cnet.com


[ WSDD ]
AXIS에서 서버의 관리자가 서비스를 유연하게 등록할 수 있는 방법으로 WSDD(WebService Deployment Description)라는 등록 정의 언어를 제공한다. 엘리먼트 내에 등록될 서비스를 엘리먼트로 표현하며, 를 이용하여 등록될 서비스에 특성을 부여할 수 있다. 복합형 데이터의 경우 특정한 ‘serializer’을 등록할 수 있는 기능 등을 제공한다.

[ AXIS의 AdminClient ]
실제로 기술한 서비스를 시스템에 배정하기 위해서는 WSDD를 AXIS 서버에게 전달할 수 있는 방법이 필요하다. 이러한 작업을 수행하는 것이 AdminClient이다. 다음과 같이 WSDD를 등록한다.

> java org.apache.axis.client.AdminClient deploy.wsdd

등록된 서비스의 목록을 볼 수도 있다.

> java org.apache.axis.client.AdminClient list

자세한 문법은 다음과 같다.

AdminClient [Options] [list | ]

Options으로는 다음과 같은 값을 설정할 수 있다.

◆ -l : AxisServlet URL를 설정한다.
◆ -h
◆ -p : AxisServlet port를 설정한다.
◆ -s : AxisServlet의 패스를 설정한다.

Command는 다음과 같다.

◆ list : 현재 배치된 서비스 목록을 보여준다.
◆ quit : SimpleAxisServer를 종료하라는 메tl지를 보낸다.
◆ passwd : admin password를 변경하게 한다.

만약 -l -h -p -s가 설정되지 않을 경우 기본적으로 http://localhost:8080/ axis/servlet/AxisServlet에 AxisServlet이 위치한다고 가정하고 동작을 시도한다.