[출처] [본문스크랩] 2.웹 서비스를 이용한 이기종간 오브젝트 전달|작성자 독수리
1278471470_soap_이달의_디스켓-freo39.zip
1278471470_soap_이달의_디스켓-freo39.zip지난 호에서는 웹 서비스에서 이기종간 플랫폼 연동의 중요성과 함께 기본형 데이터의 전달을 통한 연동을 소개했다. 이번 호에서는 복합형 데이터 전달에 중요한 역할을 하는 WSDL에 대해 자세히 살펴보겠다. 실례를 들어 기본형 전달과는 다른 자바에서의 복합형 연동을 설명한다. 그리고 실제 프로젝트에 유용하게 사용되는 모니터링 툴을 통해 복합형 데이터가 어떤 SOAP 메시지 형태로 전달되는지에 대해서도 살펴보겠다.
실전!강의실 >> 웹 서비스
연+재+순+서
1회 2003.10｜현실로 다가온 웹 서비스 : MS와 JAVA 플랫폼의 연동
2회 2003.11｜웹 서비스를 이용한 이기종간 오브젝트 전달
3회｜SOAP의 Attachment기능을 이용한 이기종간 파일 전송
연+재+가+이+드
운영체제 | 윈도우
웹 서버 | IIS, 아파치 톰캣 4. 1. 24
개발도구 | 아파치 AXIS 1.1 , MS SOAP 툴킷 3.0, JDK, 비주얼 베이직
기초지식 | XML, 자바, 비주얼 베이직, 웹 서비스에 대한 기본 개념
응용분야 | 웹 서비스를 이용한 시스템 통합
이기종 플랫폼에서 웹 서비스 연동 2
웹 서비스를 이용한
이기종간 오브젝트 전달
이영석 | lzerosuk@chollian.net
필자는 XML 엔지니어로 활동하며 XML 파서를 이용한 XML 에디터 개발, XSLT 기반의 CMS 시스템을 개발했다. 현재 웹 서비스 기반의 BPMS 시스템을 개발하고 있다.
웹서비스는 사용자가 원하는 특정한 서비스를 제공하는 패키지가 아니다. 그 위에 다양한 패키지를 올려놓을 수 있는 플랫폼이다. XML 역시 제품이 아니라 플랫폼이다. 필자가 XML을 연재하던 초기에 가장 많이 들은 질문이 “왜 XML을 써야 하는가”였다. XML이 없는 IT 기술로도 사용자가 원하는 시스템은 얼마든지 만들어 낼 수 있다. 그런데 비싼 교육 비용과 업그레이드 비용을 들여 눈에 보이는 효과가 적은 XML에 누가 투자를 하겠느냐는 이야기였다. 요즘 듣는 질문 중 하나가 “왜 웹 서비스가 필요한가”이다. 참 어려운 질문이다. XML과 똑같다. XML이 없이도 사용자가 원하는 시스템을 얼마든지 만들어 낼 수 있었던 것처럼 웹 서비스가 없이도 얼마든지 다양한 방법으로 시스템을 통합할 수 있으니 말이다.
웹 서비스와 너무나 닮은 XML에서 그 답을 찾아보자. 지금 우리는 왜 XML을 사용하고 있는가? XML이 적용된 솔루션과 XML이 적용되지 않은 솔루션의 차이를 사용자는 알 수 없다. 사용자는 기능만을 느끼기 때문이다. 시스템의 반응 속도만을 느끼기 때문이다. 하지만 현재 시스템 개발에 XML을 사용하는 이유는 비싼 초기 도입 비용을 상쇄할만큼, 시스템을 개발하는 데 드는 비용과 유지 보수에 드는 비용을 줄이고 있기 때문이다. 이러한 비용의 절감은 간접적으로 사용자에게 혜택이 돌아간다. 웹 서비스도 마찬가지이다. 웹 서비스를 이용한 시스템은 개발과 유지 보수의 비용 절감을 얻을 수 있을 것이다. XML이 기반 기술로 개발하는 곳곳에 스며들어 영향을 주었듯이 웹 서비스가 그러할 것이다.
웹 서비스를 구성하는 기술로 SOAP, WSDL, UDDI가 있다. 이 기술들은 각각 서로 다른 버전 넘버를 가지고 발전하고 있다. 묶여서 힘을 발휘하지만, 묶여있지 않더라도 이들은 웹 서비스의 중요한 기능들이다. 현재 일부 기술 선도 업체에서 웹 서비스를 시스템에 적용하고 있다는 기사가 심심치 않게 나오고 있다. 굳이 SOAP, WSDL, UDDI를 모두 적용하지 않더라도 웹 서비스 기반의 시스템이라고 생각한다. 단순히 SOAP만을 이용했다고 하더라도 웹 서비스 기반의 시스템이라고 생각한다. J2EE의 모든 스펙을 다 이용해야만 J2EE 기반의 시스템이 아니듯이 웹 서비스 역시 마찬가지이다.
웹 서비스는 기술이다. 기술은 사용된다는 것에 의미가 있는 것이지 그것이 모두 사용되었다, 일부 사용되었다 하는 것이 중요한 것은 아니다. OSI 7 레이어와 HTML의 경우처럼 말이다. 그리고 웹 서비스의 생명은 플랫폼의 호환이다. 그렇기 때문에 플랫폼의 호환성은 중요한 관심 사항으로 WS-I의 Basic Profile 등에 대해 관심을 가져야 한다(<화면 1>).
웹 서비스를 이용한 복합형 데이터 교환
지난 호에서 기본형 데이터의 전달에 대해 살펴보았다. 기본형 데이터란 int, char, short 등의 데이터를 말한다. 이번 회에는 복합형 데이터를 주고 받을 수 있는 시스템에 대해서 살펴보자. 복합형 데이터란 array, structure, type, class, bean 등을 말한다. 객체지향적인 시스템이 일반화된 현재에는 기본형 데이터의 전달보다는 객체(object) 단위의 데이터 전달이 일반적인 데이터 전달 형태라고 하겠다. 복합형 데이터 교환을 위해 <그림 1>과 같은 시나리오를 가정하고 프로그램을 작성해 보자.
클라이언트는 서버에게 사과(Apple)가 들어있는 사과박스(AppleBox)를 요구한다. ‘사과’는 색깔이라는 속성을 가진 객체이며, ‘사과박스’는 사과들의 배열을 담고 있는 객체이다. 이 시나리오를 통해 복합형 데이터인 배열과 객체의 전달을 테스트할 수 있다.
자바 AXIS를 이용한 서비스 작성
지난 호를 보지 못한 독자를 위해 간단하게 자바에서 웹 서비스를 구성한 환경을 설명하겠다. 웹 서비스 툴킷으로 아파치 AXIS 1.1을 사용하였으며, 이 툴킷은 서블릿으로 아파치 톰캣 4.1.24에서 운영한다. 운영에 관한 구체적인 설정 방법은 지난 기사를 참고하기 바란다.
먼저 객체단위의 정보를 클라이언트에게 전송하는 서비스를 준비하자. 자바가 SOAP을 통해 모든 클래스를 전달할 수는 없다. 플랫폼 독립적인 운영환경에서는 서버가 전달하는 클래스를 클라이언트가 받아서 그 클래스의 의미를 이해할 수 있다고 보장할 수 없기 때문이다. 자바가 SOAP을 통해 전달할 수 있는 클래스는 자바의 빈즈(Beans)에 한정되어 있다.
자바빈즈는 썬 마이크로시스템즈에서 나온 객체지향 프로그래밍 인터페이스로서, 이것은 주요 운영체계 플랫폼의 네트워크 내에 적용될 수 있는 재사용 가능 애플리케이션 또는 프로그램 빌딩 블럭, 즉 컴포넌트들을 구축할 수 있게 한다. 자바 애플릿처럼, 자바빈즈 컴포넌트들(일명 빈즈)도 이자율을 계산하거나 사용자 또는 브라우저 특성에 맞게 페이지 내용을 변경하는 등 웹 페이지에 인터랙티브한 기능을 부여하는데 사용될 수 있다(www.terms.co.kr 발췌).
일반적으로 클래스는 속성(멤버 변수)과 동작(메쏘드)으로 구성된다. 하지만 빈즈의 액션은 속성에 접근(access)하는 목적으로 제공되기 때문에 자바빈즈는 정보의 보관소의 의미가 강하다고 하겠다.
조금 뒷부분에 객체를 전송할 때 메시지가 SOAP으로 어떻게 직렬화(serialize)되는지 살펴보겠지만 SOAP으로 전송되는 객체란 속성의 값들이지 동작의 형태가 아니다. 이런 이유로 SOAP으로 객체를 전송하기 위해서는 그 전달되는 객체가 빈즈로 만들어져야 한다.
<리스트 1, 2, 3>은 서버가 클라이언트에게 전달할 사과(Apple) 객체와 그것을 사과박스에 담아 클라이언트에게 보내기 위한 서비스 클래스이다. 이 세 리스트의 세 자바 파일을 컴파일하여 생성된 클래스를 톰캣에 등록한 AXIS 폴더의 tomcatwebappsaxisWEB-INF classes 위치에 ‘appleTest’라는 폴더를 만들고 그 안에 위치시킨다. 특별한 설명이 없이도 알 수 있겠지만 Apple.java는 color라는 속성을 가진 자바빈즈이고, AppleBox.java는 Apple.java 빈즈를 담는 역할을 하는 빈즈이며, AppleServer.java는 AXIS에 등록되어 SOAP으로 서비스될 서비스 객체이다.
WSDD를 이용한 서비스 등록
서비스로 등록될 클래스가 준비되었으니 이제 그 클래스를 서비스로 등록해보자. 지난 호에서 서비스를 등록한 것처럼 AXIS의 AdminClient를 통해 AppleServerDeploy.wsdd를 이용해 클래스를 등록한다.
> java org.apache.axis.client.AdminClient AppleServerDeploy.wsdd
<리스트 4>의 AppleServerDeploy.wsdd를 살펴보자.
AppleServerDeploy.wsdd는 ‘AppleServerService’라는 서비스로 등록되는 서비스를 표현하고 있으며,
지난 호에 살펴본 기본형 데이터의 전송이나 지금 살펴보는 복합형 데이터의 전송이나 여기까지는 동일하게 WSDD로 설정한다. 주의깊게 봐야 할 부분은 다음이다.
이렇게 명시하지 않으면 AXIS는 클라이언트에게 넘겨줘야 할 객체를 자바빈즈로 인식하지 못해 객체 단위의 정보를 반환하지 못한다. 더 자세한 WSDD에 대한 내용은 설치된 axis의 docs eference.html을 참조하기 바란다. 등록이 성공했는지를 확인하기 위해 브라우저를 열어 톰캣에 등록된 AXIS의 메인 페이지에서 ‘View the list of deployed Web services’를 선택하여 서비스 목록을 확인한다(<화면 1>).
객체를 전달받는 클라이언트 작성
웹 서비스를 위한 자바의 클라이언트는 두가지 방법으로 작성할 수 있다. 첫번째로는 WSDL을 사용해 생성한 프록시 역할을 하는 스텁(Stub)을 이용하는 방법이다. 두번째는 WSDL을 사용하지 않고 AXIS의 Call 객체를 이용하거나 혹은 로우레벨 API를 사용하여 프로그래밍하는 방법이다. 객체를 전송받는 경우에도 두가지 방법 모두 가능하다. 여기서는 스텁을 생성해서 클라이언트 프로그램을 작성하겠다. 먼저 ‘WSDL To Java’ 툴을 이용해 스텁을 생성한다. <화면 3>과 같은 구조로 클래스가 생긴 것을 볼 수 있다.
> java org.apache.axis.wsdl.WSDL2Java http://[ServerIP]/axis/services/ AppleServerService?wsdl
<화면 2>의 beanService 폴더를 보자. WSDL을 이용해 생성된 ‘~AppleServerService’ 폴더 내에 스텁 클래스 이외에 서버가 서비스하는 자바빈즈 클래스가 자동으로 생성된 것을 볼 수 있다. 즉 서버가 서비스를 하기 위해 사용하는 자바빈즈가 WSDL에 기록되었으며 서버에게 서비스를 받고자하는 클라이언트 사이드에 ‘WSDL To Java’ 툴을 통해 자바빈즈가 자동으로 생성되었다는 것이다. 클라이언트 개발자는 서버에서 어떤 방법으로 메쏘드의 결과값을 넘겨주는가에 관심을 가질 필요없이 로컬에 있는 스텝의 메쏘드를 호출하고 자바빈즈를 이용해 일반적인 프로그램을 작성하듯이 쉽게 SOAP 통신을 하는 프로그램을 작성할 수 있다.
아무리 좋은 기술이라도 복잡하고 어렵다면 실제 프로젝트에 적용되기 어렵다. 적용하는데 들어가는 초기 교육 비용이나 유지보수 비용이 많이 들기 때문이다. 하지만 스텁을 이용한 웹 서비스 클라이언트 개발은 다르다. 이렇게 쉽고 편리한 개발 환경이야 말로 웹 서비스의 진정한 장점이라 하겠다.
이제 사과(Apple.java)를 담은 사과박스(AppleBox.java)를 반환받는 클라이언트를 작성하자. 코드는 <리스트 5>와 같다. AppleSer verClient를 컴파일 후 실행하면 다음과 같은 결과를 볼 수 있다(<화면 4>).
> javac AppleServerClient.java
> java AppleServerClient
모니터링 툴의 사용
지금까지 살펴본 과정만으로도 자바 환경에서 객체를 전달하는 서버와 클라이언트 프로그램 작성에는 어려움이 없다. 하지만 눈에 보이는 것이 전부는 아니다. 가령 서버와 클라이언트 간에 주고받는 SOAP의 메시지는 어떤 형태를 가지는가, 그리고 WSDL이 전달하려고 하는 정보는 무엇이고 어떻게 자바의 스텁과 빈즈로 변환되는가 등의 눈에 보이지 않는 웹 서비스 기술의 몇 가지 숨은 면을 살펴보자.
먼저 서버와 클라이언트가 주고 받는 데이터를 살펴보자. 스텁이나 Call 객체 등으로 랩핑(wrapping)된 API를 사용해서 프로그램을 작성하지만 실제 서버와 클라이언트는 SOAP 스펙에 따라 데이터를 인코딩해서 주고 받는다. 프로그램 개발의 유용성을 위해 랩핑된 API를 제공하는 개발 환경에서 굳이 인코딩된 데이터를 볼 필요가 있을까 라고 생각할 수도 있지만 실제 프로젝트 진행시 서버와 클라이언트가 주고 받는 메시지를 모니터링해서 직관적으로 데이터를 확인할 수 있다는 것은 디버깅시 엄청난 장점을 제공한다.
대부분의 웹 서비스 툴킷에는 이러한 모니터링(혹은 Trace) 툴이 제공되고 있다. AXIS 역시 예외는 아니다. 모니터링 툴을 실행하기 위해서는 다음과 같이 tcpmon.class를 실행한다.
> java org.apache.axis.utils.tcpmon
<화면 5>와 같이 프로그램의 실행을 볼 수 있다. 약간 간단한 메뉴에 약간 엉성한 화면을 가진 간단한 톨이지만 사용하다 보면 여러모로 유용한 툴이라는 생각이 든다.
리스너 포트(Listener Port)에는 서버를 대신해서 리퀘스트가 들어올 포트를 지정한다. Act as a listener Target Hostname과 타겟 포트(Target Port)에는 실제로 서버의 위치를 지정한다. 다시 말해서 이 툴은 서버와 클라이언트 중간에 위치하며 클라이언트에겐 서버처럼, 서버에겐 클라이언트처럼 동작하는 것이다.
앞서의 예제를 응용해 객체를 주고 받을 때의 SOAP 메시지의 형태를 살펴보자. 클라이언트, 서버, 모니터링 툴이 로컬에서 실행되기 때문에 각각의 위치는 포트를 통해서 분리하도록 하자. 클라이언트는 서버가 8000번에 있다고 생각하며 동작하도록 한다. 모니터링 툴은 8000 포트를 리스닝(Listener Port)하게 설정하고 서버 포트(Target Port)를 8080으로 설정하자. 8080에는 실제로 서버가 있다.
먼저 클라이언트 코드를 수정하여 서버의 위치를 변경해야 한다. 클라이언트는 자동으로 생성된 스텁에 서버의 위치가 담겨있다. 뒤에 살펴보겠지만 WSDL에는 클라이언트가 어디로 서비스를 요청해야 하는가 하는 ‘end point URL’이 명시되어 있으며, WSDL to Java 툴은 이 정보를 이용해 스텁을 생성할 때 클라이언트의 서비스 요구가 지정된 URL로 보내지도록 스텁을 생성하기 때문이다. 앞서 자동으로 생성된 스텁 파일중 AppleServerServiceLocator.java의 일부를 보자.
/**
* AppleServerServiceLocator.java
*
* This file was auto-generated from WSDL
* by the Apache Axis WSDL2Java emitter.
*/
package _211._197._238._203.axis.services.AppleServerService;
public class AppleServerServiceLocator
extends org.apache.axis.client.Service
implements _211._197._238._203.axis.services.
AppleServerService.AppleServerService {
// Use to get a proxy class for AppleServerService
private final java.lang.String AppleServerService_address
= “http://203.238.197.211:8080/axis/services/AppleServerService”;
public java.lang.String getAppleServerServiceAddress() {
return AppleServerService_address;
}
… 이하 생략…
이 파일의 코드중에 ‘http://203.238.197.211:8080/axis/ services/AppleServerService’는 서버의 위치를 가리키고 있다. 이 부분을 ‘http://203.238.197.211:8000/axis/services/AppleServer Service’로 고쳐서 컴파일 후 실행해도 되겠지만, 자동으로 생성된 스텁을 고친다는 것은 여간 불편한 일이 아니다.
클라이언트에서 서버의 위치를 지정하는 쉽고 간단한 방법이 있다. 앞서의 AppleServerClient의 코드중 다음 부분을 보자.
// to get a stub...
AppleServer port = service.getAppleServerService();
이를 다음과 같이 URL을 넣는 코드로 수정한다.
// to get a stub...
AppleServer port = service.getAppleServerService(
new java.net.URL(“http://203.238.197.211:8000/
axis/services/AppleServerService”));
컴파일하여 클래스를 만들었다면 클라이언트의 준비는 끝났다. 이제 모니터링 툴을 실행하자. 리스너 포트에는 8000을 설정하여 8000번 포트를 리스닝하게 한다. Act as a listener Target Hostname에는 127.0.0.1, 타겟 포트에는 실제로 서버의 포트인 8080을 설정한다. add 버튼을 누르면 리스닝을 시작한다. 이제 클라이언트를 실행하자.
> java AppleServerClient
<화면 6>과 같이 모니터링 툴을 통해 클라이언트와 서버가 주고 받는 SOAP 메시지를 볼 수 있다. 객체를 전달하는 SOAP의 메시지를 살펴보자.
SOAP 메시지의 시작은
soapenc:arrayType=”ns2:Apple[5]”>
~생략~
xsi:type=”ns3:Apple”을 통해 알 수 있듯이 실제 Apple 타입이며 사용자가 정의한 Apple 타입에는
WSDL의 구조
이전 강의에 언급했지만 웹 서비스에서 WSDL의 역할은 중요하다. WSDL은 등록된 서비스의 명세서와 같은 역할을 한다. 이러한 서비스의 명세서는 사람이 볼 수도 있지만, 시스템과 시스템 사이에 주고 받아지는 문서의 의미가 강하다. 즉 자동으로 전달되어 서비스를 받고자 하는 쪽에 프록시 역할을 한다는 것이다. 이러한 관점에서라면 굳이 개발자가 WSDL의 한줄 한줄 의미를 이해할 필요가 없을 수도 있다. 하지만 계속 반복해서 말하듯이 클라이언트의 개발자가 자동으로 생성된 스텁을 사용하지 않고 프로그래밍하기 위해서는 서버가 제공하는 서비스를 이해해야 하고, 이기종간 연동에 있어서 스텁을 사용하지 못하는 경우가 생기기 때문에 대략적인 WSDL의 의미는 알아야 한다고 생각한다.
함께 살펴볼 WSDL은 앞서 예제에서 AppleServerService를 제공하는 서버가 생성한 WSDL이다. 브라우저를 통해 ‘http://localhost: 8080/axis/services/AppleServerService?wsdl’에서 AppleServer Service의 WSDL을 볼 수 있다.
