웹 서비스라는 기술이 국내에 소개되고 많은 개발자들이 관심을 갖게 된지도 벌써 1년반 정도 지난 것 같다. 그동안 필자는 XML을 기반으로 SOAP, WSDL, UDDI를 이용하는 웹 서비스 기술을 어느 정도 사용할 수 있는지, 또 앞으로 어떻게 발전할 것인지에 대한 질문을 많이 받아왔다. XML에 관한 기본 지식이 있는 독자라면 아마도 SOAP 라우터를 통해 간단한 메쏘드를 호출하는 부분에서 출발해 WSDL4J, UDDI4J API를 이해하는 과정으로 진행하는 것이 웹 서비스의 기본이라고 알고 있을 것이다. 하지만 이러한 것 이외에 실제 기업 환경에 웹 서비스를 적용하면서 생길 문제 대해서 아직 소홀한 것 같다.
현존하는 웹 서비스의 문제
웹 서비스는 기술적으로 어느 정도 완성단계에 들어섰다고 하지만 현재 기업들이 도입하기에는 아직 여러 문제점을 안고 있다. 첫째, 웹 서비스에 대한 개념 자체에 대한 이해 부족이다. 웹 서비스가 과연 현재 인터넷 비즈니스 환경에서 어떤 의미를 지니고 있는지를 이해하고 자신들이 제공하고 있는 서비스에 어떻게 적용해야 할지 알지 못하는 경우다. 물론 인터넷 서비스를 제공하는 있는 모든 기업이 웹 서비스를 도입해야 할 필요는 없다. 웹 서비스는 단지 인터넷상의 서비스 유통과정의 발전을 의미하는 것이지 서비스 그 자체에 대한 기술적인 방법을 제시하는 것은 아니기 때문이다.
두 번째로 비즈니스 모델의 부재를 꼽을 수 있다. 웹 서비스로 수익을 낼 수 있는 모델을 찾고 있지 못하다는 점이다. 초기 인터넷 비즈니스가 수익모델을 창출하기까지 많은 시간이 걸렸듯이 웹 서비스를 어떻게 도입해야 수익을 낼 수 있는지 많은 사람들이 고민 중이다. 그 해답을 정확히 집고 있는 사람이 앞으로 인터넷 비즈니스를 주도하게 될지도 모르는 일이다.
세 번째는 기술의 성숙도 부족이다. 아직도 웹 서비스를 도입하기에는 부족한 점이 많다는 의견이다. 보안, 트랜잭션처리, 성능 그리고 웹 서비스의 프로세스 관리의 기술에 대한 구현이 아직 초기 단계이기 때문에 지금 당장 적용하기에는 부적합하다는 의견이다.
마지막으로 인터넷 서비스 시장의 미성숙이다. 개인적으로 이 점이 앞으로 웹 서비스의 대중화에 가장 큰 걸림돌이 될 것이라 보고 있다. 전 세계적인 IT 경기의 침체에 따른 인터넷 비즈니스의 성장이 느려짐에 따라 전문가들이 예측한 인터넷의 비즈니스의 더딘 발전은 웹 서비스 도입을 늦추게 할 큰 요소가 될 수 있다. 아무리 훌륭한 개념도 비즈니스 모델도 시장이 따라주지 않으면 아무 소용없다는 것은 누구나 아는 사실이다.
그렇다면 이러한 문제를 해결할 방법은 없을까? 웹 서비스의 대중화는 인터넷 비즈니스의 성숙을 그만큼 앞당기는 것이다. 자본주의의 발전 단계처럼 물물교환이나 작은 시장에서 시작해 월마트와 같은 대형 유통업체가 등장하고, 전 세계가 단일 시장이 되어 가는 것처럼 웹 서비스가 인터넷 비즈니스의 진화를 앞당기려면 웹 서비스의 기술적 성숙이 무엇보다도 시급하다. 특히 웹 서비스의 보안이나 서비스의 품질과 비즈니스 프로세스 관리에 대한 검증이 필요하다. 물론 이에 대한 기술적 스펙은 이미 나와 있지만 아직 완전히 검증된 것은 아니기 때문이다.
전체적인 구조와 개발 과정
우선 앞으로 만들어 볼 애플리케이션의 전체적인 구조를 살펴보자. 웹 서비스를 실행하기 위해서는 두 사람이 필요하다. 한 사람은 서비스를 제공하는 사람이며(프로바이더라고 한다), 또 한 사람은 프로바이더가 제공하는 서비스를 이용하는 사람이다(리퀘스터라고 한다). 웹 서비스가 진행되는 일반적인 과정은 프로바이더가 먼저 자신의 서비스를 웹 서비스화(SOAP을 통해 요청받을 수 있는 상황으로 만드는 과정)하는 과정이며, 해당 웹 서비스를 UDDI에 등록하는 과정으로 마무리된다. 이후, 리퀘스터는 UDDI를 검색하여 원하는 서비스를 자신의 워크스페이스(workspace)로 반입하는 과정을 거친 후, 프록시 코드와 필요하다면 클라이언트 코드를 생성함으로써 프로바이더를 호출할 수 있게 된다. 프로바이더와 리퀘스터가 웹 서비스를 개발하는 과정을 간략히 요약하면 <그림 1>과 같으며, 프로바이더와 리퀘스터가 서비스를 바인딩하고 호출하는 과정은 <그림 2>와 같다.
프로바이더가 개발하는 과정을 좀더 자세히 살펴보면 다음과 같다.
① 웹 서비스로 제공할 자바빈을 선택한다.
② WSAD를 이용해 이 자바빈을 웹 서비스화 한다.
③ 해당 웹 서비스가 SOAP 라우터를 통해 서비스되는지를 테스트한다.
④ 모든 과정이 정상적이라면 해당 서비스를 UDDI에 등록한다.
리퀘스터가 웹 서비스를 개발하는 과정은 다음과 같다.
① UDDI를 검색해 원하는 서비스를 선택한다.
② 해당 서비스의 WSDL을 워크스페이스로 반입한다.
③ WSAD를 이용해 프록시와 클라이언트 코드를 생성한다.
④ 프로바이더를 호출해 서비스를 제공받는다.
WSAD를 이용한다면 이 모든 과정을 WSAD 워크스페이스 내에서 진행할 수 있다. 실제 웹 서비스를 개발하고 실행하기 위해 필요한 모든 컴포넌트는 XML 기반에서 작성되기 때문에 개발자가 이 모든 과정을 수작업으로 진행한다면 오류가 발생할 소지도 크다. 또한 SOAP, WSDL, UDDI에 관한 모든 스펙을 이해하고 있는 개발자는 매우 드물기 때문에 수작업 개발은 거의 불가능하다고 해도 과언이 아니다.
이런 이유로 웹 서비스를 지원하는 각 업체는 개발자들이 웹 서비스의 각 세부사항을 잘 알지 못하더라도 웹 서비스를 개발하는데 있어 쉽고 빠르게 개발할 수 있는 툴을 제공하고 있다. 자바 웹 서비스를 개발하려는 개발자라면 WSAD를 사용하는 것이 좋은 선택이 될 수도 있을 것이다. WSAD에는 웹 서비스를 개발하기 위한 모든 기능이 위저드 형식으로 제공되고 있기 때문에 개발자는 자신이 개발하려는 자바빈만 존재한다면 자신이 원하는 형식으로 모든 기능을 자동 생성할 수 있다. 그럼 지금부터 WSAD를 사용해 자바 웹 서비스를 실제로 개발하는 과정을 소개하기로 한다.
프로바이더용 웹 프로젝트 작성
우리가 진행할 프로바이더용 애플리케이션은 EJB를 사용하는 J2EE 애플리케이션이 아니다. JDBC를 이용해 데이터베이스로부터 데이터를 얻어오는 단순한 애플리케이션이기 때문에 애플리케이션 작성은 웹 Perspective를 사용하면 가장 쉽게 작성할 수 있다. 웹 Perspective를 작성하는 방법은 우선 WSAD의 Perspective에서 여러 가지 Perspective 중에서 하나를 선택할 수 있는데 일단 ‘웹’을 선택하기로 한다. 선택 즉시 웹 Perspective가 열리는데, 현재 독자들이 어느 perspective에서 작업하고 있는지 궁금할 것이다. WSAD의 타이틀이 ‘J2EE-Application Developer’이면 J2EE Perspective에서 작업 중이라는 것이며, ‘웹 - Application Developer’라는 타이틀이 보이면 현재 웹 perspective에서 작업 중이라고 생각하면 된다.
좌측 상단의 네비게이터 창에서 팝업 메뉴를 클릭하면 「신규
창 하단의 ‘완료(F)’ 버튼을 클릭하면 네비게이터 창에 두 개의 프로젝트가 생성되어 있음을 알 수 있다. 하나는 MortgageRateWebService라는 웹 프로젝트이며, 다른 하나는 MortgageRateWebServiceEAR이라는 J2EE 프로젝트가 생성된다. 이렇게 두 개가 생성되는 이유는 J2EE 스펙에 의한 것으로 J2EE 스펙에 의하면 웹 프로젝트는 하나의 J2EE 프로젝트에 속해 있어야 하기 때문이다. 네비게이터 창의 두 프로젝트를 모두 펼쳐보면 J2EE 애플리케이션을 작성하기 위해 필요한 파일 템플릿들이 작성되어 있음을 알 수 있다.
프로바이더용 서버 프로젝트 작성
프로바이더가 작성하는 웹 서비스 애플리케이션은 SOAP 라우터를 내장하고 있는 WAS에서 실행된다. 우리가 앞에서 작성한 MortgageRateWebService 애플리케이션을 수행하려면 이 애플리케이션을 호스팅할 서버 프로젝트와 이 서버 프로젝트 내의 서버 인스턴스를 생성하고 구성해야 한다. 이런 목적으로 우선 서버 프로젝트를 하나 작성하려면, 서버 Perspective에서 작업하는 것이 가장 효율적이므로 서버 Perspective를 생성하기로 하자.
WSAD의 Perspective 메뉴에서 「열기(O)
해당 Servers라는 프로젝트를 마우스로 선택한 후, 팝업 메뉴에서 「신규
이미 우리는 UDDI를 호스팅하기 위해 WAS를 하나 실행 중이며, 이 WAS는 8080 포트를 사용하고 있기 때문에 현재 작성하고 있는 서버 인스턴스는 8080이 아닌 다른 포트를 사용해야만 한다. ‘HTTP 포트 번호(H)’ 란에 8083을 입력해 충돌이 발생하지 않도록 반드시 조정해야만 한다. 화면을 닫으면 네비게이터 창과 서버 구성창이 조금 변했음을 알 수 있다.
HTTP 포트의 충돌은 조정했으나 UDDI 서버는 bootstrap 포트로 900번을 사용하고 있으며, trace 포트로 7000번을 사용하고 있다. 조금 전에 작성한 서버 인스턴스도 여전히 900, 7000번을 사용하고 있기 때문에 역시 이들 포트도 수정이 필요하다. WSAD 좌측 하단의 서버 구성창에서 서버 구성을 확장하면 MortgageRateWebServiceServer가 보이는데 이 MortgageRateWebServiceServer를 더블 클릭하면 WSAD 화면 우측 상단에 ‘MortgageRateWebServiceServer 구성 편집기’가 나타나며, 이 창의 하단에 있는 ‘포트’ 탭을 클릭하면 서버 인스턴스의 포트를 수정할 수 있다.
<화면 3과 같이 포트를 조정한 다음 변경사항을 저장한 후 종료한다(이 구성 편집기가 열려 있는 상황에서는 서버 실행이 불가능하기 때문에 반드시 종료한다. WSAD 전체를 종료한다는 의미는 아니므로 실수로 WSAD 전체 창을 종료하는 오류를 범하지 않길 바란다).
이 서버 인스턴스에 앞에서 작성한 웹 프로젝트를 등록해 보자. 서버 구성창에서 MortgageRateWebServiceServer를 선택한 후, 팝업메뉴에서 「프로젝트 추가
프로바이더용 자바빈 반입
웹 서비스를 개발하기 위해서는 자바빈 하나가 필요하다. 물론 이 자바빈을 본 연재에서 제작하는 것도 하나의 방법이지만 지면을 낭비할 우려가 있으므로 이미 작성되어 있는 빈을 하나 반입하기로 한다. WSAD에서 기본적으로 제공하는 파일을 반입해 보자. 우선 현재 perspective가 서버 perspective이긴 하지만 우리가 자바빈을 수정할 필요는 없으므로 계속되는 작업도 서버 perspective에서 진행하기로 한다. 네비게이터 창에서 MortgageRateWebService 프로젝트를 확장하면 source 폴더가 있음을 확인할 수 있다. 이 폴더를 클릭한 후 ‘파일(F)’ 메뉴에서 ‘가져오기(I)’ 메뉴를 선택한다.
<화면 4>에서 압축할 파일 우측의 ‘찾아보기’를 눌러 MortgageRateWebService.zip 파일을 선택하고, webservice 패키지내의 모든 파일을 선택한 후, 폴더 위치가 MortgageRateWebService/source인지를 확인한다.
자바빈과 메쏘드 설명
네비게이터 창에서 source 폴더의 webservice라는 패키지 밑에 있는 LowestMortgageRateWebService.java 파일을 더블 클릭해보자. 화면 우측 상단에 자바 소스 파일이 열린다. 이 자바빈에는 submitRateInquiry라는 메쏘드가 하나 존재하는데 여기서는 이 메쏘드를 웹 서비스로 호출하려 하는 것이다.
우선 이 메쏘드를 한번 살펴보면 입력 파라미터로 두 개의 스트링 파라미터를 받는다는 사실을 알 수 있다. String CustomerNumber(고객 번호), String Term(기간)을 입력받아 이 고객에게 적용할 수 있는 가장 낮은 대출 이율을 DB를 검색해 결과 값을 WebServiceResult라는 객체에 담아 리턴하는 메쏘드다. 결과 값을 저장하고 있는 WebServiceResult.java 파일을 더블 클릭해보면 내부에 세 개의 속성을 갖고 있음을 알 수 있다.
◆ boolean b_RC(대출이 가능한지 불가능한지 여부)
◆ String s_Rate(대출이 가능하다면, 적용 가능한 이율)
◆ String s_Comment(해당 이율이 산정된 근거)
이렇게 결과 값을 자바 객체로 선언한 이유는 실제 환경에서 primitive형의 결과를 돌려주는 경우도 물론 있지만, 이런 식으로 자바 객체를 사용하는 경우 이 객체의 스키마가 어떤 형식으로 선언되며, 어떤 형식으로 SOAP을 통해 리퀘스터에게 전달되는지를 좀더 자세히 설명하기 위해서다.
위저드를 이용해 웹 서비스화 하기
WSAD가 제공하는 웹 서비스 위저드를 사용하면 한 줄의 코딩도 없이 자바빈을 웹 서비스화 할 수 있다. 우선 네비게이터 창에서 LowestMortgageRateWebService.java 파일을 클릭한 후, 팝업 메뉴에서 「신규
WSAD는 웹 서비스 개발에 필요한 모든 기능을 하나의 화면으로 처리할 수 있도록 작성됐기에 웹 서비스에 대해 자세한 내용을 잘 모르는 사용자라면 이 화면에서 그냥 ‘완료’ 버튼을 눌러도 무방하다. WSAD는 LowestMortgageRateWebService.java 파일을 웹 서비스화 하는데 필요한 모든 파일을 생성하며, 생성된 파일들을 MortgageRateWebServiceServer 실행환경에서 실행한다. 하지만 개발자라면 누구나 웹 서비스를 개발하기 위해 필요한 세부적인 내용에 관심이 있을 것으로 생각한다. 보다 자세한 진행 과정은 ‘이달의 디스켓(wsad_add.hwp)’에 첨부했으니 이를 참고하기 바란다.
샘플 프로그램 테스트
모든 과정이 완료된 다음 약간의 시간이 지나면 화면 우측 상단에 브라우저가 나타난다. 이 브라우저를 통해 웹 서비스가 올바르게 작동하는 지를 테스트할 수 있다. 이 화면은 물론 샘플 프로그램으로 작성된 JSP 파일이 실행된 결과이다(생성된 파일들을 살펴보는 과정은 ‘이달의 디스켓’의 wsad_file.hwp 파일을 참조하기 바란다). 우선 브라우저 좌측 화면에 submitRateInquiry라는 메쏘드가 있음을 알 수 있다.
이 메쏘드는 우리가 웹 서비스로 작성한 메쏘드 이름과 동일하며, 이 메쏘드를 마우스로 클릭하면 <화면 7>과 같이 submitRateInquiry 메쏘드에서 필요한 입력 파라미터를 입력할 수 있는 화면이 나타난다.
CustomerNumber에 1을 입력하고 Term에 10을 입력하고 ‘Invoke’ 버튼을 눌러 보자. 이것은 CustomerNumber 1인 고객이 10년 동안 대출받을 수 있는 가장 낮은 이율이 얼마인지를 알고자 하는 것이다. WSAD 화면 우측 하단의 콘솔 창으로 DB를 액세스하는 과정이 진행되며, 브라우저에는 <화면 8>과 같이 웹 서비스가 실행된 결과가 나타날 것이다. 이 화면이 나타났다면, 프로바이더는 웹 서비스를 위한 모든 비즈니스 로직 개발이 완료됐음을 알 수 있다.
남은 부분은 독자의 몫으로
지금까지 웹 서비스로 제공하려는 서비스가 프로바이더의 SOAP 라우터에서 정상적으로 실행되는 과정을 살펴보았다. WSAD를 이용해 웹 서비스를 개발하는 과정은 그리 어렵지 않다. 무엇보다도 웹 서비스에 대한 지식이 전혀 없는 독자라 할지라도 웹 서비스를 쉽고 빠르게 개발할 수 있다는 점이 가장 큰 장점이다(지금까지 살펴본 것과 같이 코딩을 전혀 하지 않고서도 자바빈을 웹 서비스화 할 수 있음을 알 수 있다).
웹 서비스는 프로바이더만으로 구성되는 것이 아니며, 아직까지 프로바이더가 해야할 일이 한 가지 더 남아 있다. 바로 UDDI에 지금까지 개발한 웹 서비스를 등록하는 과정이다. 이렇게 등록된 서비스는 리퀘스터가 UDDI를 조회함으로써 사용 가능하다. 하지만 지면 관계상 조회한 서비스를 리퀘스터 진영에서 클라이언트 형식으로 작성하는 과정은 독자 몫으로 남기고 이번 호를 마치고자 한다. 다음 호에는 실제로 EJB로 구축된 일부 서비스의 예를 들어 그것을 여러 가지 방식으로 웹 서비스화 하면서 생기는 문제점과 해결책에 대해 생각해 보자. @
