연재 가이드운영체제 : 윈도우 2000/XP, 유닉스 계열, 리눅스나 Mac OS X도 가능
개발도구 : 이클립스 3.1
기초지식 : 자바, 웹서비스, XML
응용분야 : 자바 플랫폼을 이용한 웹서비스 제공

지난 한달 사이에 많은 일이 있었다. EJB 3.0 새 스펙(2번째 조기 초안)과 JBoss의 뒤이은 새 구현체가 나왔고 JAX-RPC 2.0과 JAXB 2.0의 조기 구현체가 WS-I 샘플 애플리케이션 패키지에 포함되어 출시되었다. 이로 인해 우리의 계획에도 중대한 변경이 생겼다.

작전 변경 - JAXB 2.0 + JAX-RPC 2.0
정말 세상의 변화는 놀랍다. 스펙이 나오고도 구현체가 나오기까지 한참 걸렸던 것이 엊그제 같은데 이제는 스펙이 진행 중에 구현체도 나온다. 특히 J2EE 5.0의 핵심 컴포넌트인 EJB 3.0, JAXB 2.0, JAX-RPC 2.0, 이 세 가지 기술의 진행 과정을 보면 그러한 경탄이 나올 만하다.

WS-I SA(Sample Application) 1.1

WS-I(Web Services Interoperability)는 웹 서비스의 상호운용성을 확보하기 위한 관련 업계의 공동체이다. 웹 서비스가 서로 다른 컴퓨터 환경간의 통신을 XML로 아우르려 해왔지만, 그렇다고 그 (XML을 기반한다는) 선택 자체가 모든 문제를 해결하는 것은 아니다. 오히려 갖가지 충돌이 빚어져서, SOAPBuilders의 몇 차례 라운드(Round)를 통해 SOAP 메시지를 통한 웹서비스 플랫폼 제공 업체, 웹 서비스 제작 업체 간의 상호운용성을 면밀히 검증해온 바, 이것은 웹 서비스 관련 스펙의 기술적 문제라기보다는 다양한 웹 서비스 실시 방식에 대한 합의가 필요함을 깨닫기에 이르러 WS-I와 같은 대동단결이 이루어졌다. WS-I는 프로파일(Profile)로 먼저 상호운용성 보장을 위한 요구 사항을 정리하고, 그것을 테스트하는 도구를 제공하며, 실제로 이러한 상호운용의 가능성을 보여주는 예제 애플리케이션(Sample Application, 이하 SA)도 제시한다. 현재 기본 프로파일(Basic Profile)의 최신 버전인 1.1에 부합하는 SA가 나와 있는데, 썬에서 지난 1월말에 JAX-RPC 2.0과 JAXB 2.0으로 완전히 새로 짠 WS-I SA 1.1(참고 자료 1)을 발표하였다. 잠시 뒤에 설명하겠지만 WS-I SA는 먼저 WSDL을 설계한 후 각 프로그래밍 언어(현재는 자바와 C#이 대표적)로 대응하는 개발 방식을 취하고 있다. 프로그래밍 언어 독립적인 웹 서비스의 본질에 맞기는 하지만, 웹 서비스, 특히 WSDL에 익숙하지 않은 개발자에게는 웹 서비스 설계와 제작을 어렵게 느끼게 할 수 있다. SA 1.0에서는 공급망관리(Supply Chain Management)를 소매, 도매, 제조사 형식으로 꾸몄는데, 1.1에서는 카탈로그를 붙여 그림 파일이나 PDF 설명서와 같은 첨부 파일에 대한 사용이 두드러진 특징이다. 웹 서비스의 설계와 개발, 더욱이 상호운용성을 고려하는 이에게는 무척 좋은 예제일 것이다.

EJB 3.0의 경우 JBoss의 구현체가 있어 이번 연재에 시도해 볼 수 있었지만, JAX-RPC 2.0과 JAXB 2.0의 경우 스펙만 나온 상태였는데, 마침 썬의 Arun Gupta(그는 썬을 대표해 WS-I에 참여하고 있고, 필자와는 JAX-WSA 1.0이라는 WS-Addressing용 자바 API 제정을 함께 하고 있다)로부터 조기 구현체가 WS-I SA 1.1 팩의 일부로 나왔다는 소식을 받고는 중대 결심을 했다. JAX-RPC 2.0은 WSM을 포함하고 있고 JAXB 2.0을 통해 XML을 처리하므로 차세대 자바 웹 서비스의 전모를 독자에게 전달할 수 있는 기회라고 판단, 과감히 채택했다. 따라서 택시 예약 서비스의 전체적인 구조도 달라졌으며 아직 소개하지는 않았지만 개발 방법도 바뀌게 되었다.

잠시 복습 - 구조 확인
그러면 먼저 지난 달의 복습 삼아 전체 조망을 보도록 하자. <그림 1>이 JAX-RPC 2.0과 JAXB 2.0의 채택으로 <그림 2>와 같이 달라진다.

<그림 1> J2EE 5.0 관점의 택시 예약 서비스 구조(갱신 전)

<그림 2> J2EE 5.0 기반의 택시 예약 서비스의 새로운 구조

EJB 3.0 ED2와 JBoss EJB 3.0 PR 3

공부할 거리가 하나 더 늘었다. 지난달 지령에 발맞춰 EJB 3.0의 ED를 바탕으로 공부한 독자라면 2개로 나누어진 ED2의 스펙에 놀랄 것이다. 이번 2차 조기 스펙은 아예 퍼시스턴스(Persistence) 쪽을 전체 스펙에서 뽑아내 더욱 강화했다. 이는 하이버닛(Hibernate)으로 엔티티 빈의 개혁에 박차를 가하고 있음을 가리키는데, EJB QL이 하이버닛의 QL을 토대로 대폭 진화하여 상당한 수준의 오브젝트 기반 쿼리 언어를 제공하고 있다. JBoss EJB 3.0(참고 자료 2)의 프리뷰도 3번째 버전이 나왔다. 이전 버전이 JBoss 4.0.1 RC1만을 지원하는 문제를 해결한 것을 위시로, ED2에 맞게 향상되었다. 하이버닛을 직접 쓰지 않고도 하이버닛을 EJB 3.0의 표준 퍼시스턴스 API로 사용할 수 있다는 점이 흥미롭다는 생각이 든다.

이로서 이 연재는 J2EE 5.0 기반 SOA를 사실상 완전히 논할 수 있게 되었다. 달리 말하면 조기 스펙과 조기 구현체에 어울리는 조기 학습이 가능해진 셈이다.

스타일이 살아 있다 - 자바에서 WSDL로? WSDL에서 자바로?
지난 달에 우리는 서비스의 인터페이스를 정했었다. 다시 떠올려보면,

이 표현은 자바 프로그래밍 언어로 된 것이다. 하지만 앞서도 말했듯이 (상당히 반복되어 왔고, 앞으로도 그럴 것 같다), 웹 서비스는 어떠한 플랫폼에서 어떠한 프로그래밍 언어로도 접근하고 활용할 수 있도록 하는 데에 의의가 있다.

<그림 3> WSDL 중심 개발

<그림 3>은 그러한 웹 서비스의 본령에 충실한, 즉 원리주의적 개발 방침이다. WSDL에 정통한 누군가가 프로그래밍 언어 중립적인 WSDL을 작성하여 각 언어 개발자에게 전달하면 주어진 WSDL을 가지고 웹 서비스 프로그램을 짜게 된다.

이때 필요한 것이 WSDL에서 해당 프로그래밍 언어로의 대응이다. 자바에서는 JAX-RPC 스펙이 이 주제에 대한 표준을 정하고 있어서, JAX-RPC 구현체에는 WSDL을 주면 자바 아티팩트(WSDL에 대응하는 각종 자바 클래스들)을 생성하는 툴이 들어 있다. 하지만 문제는 현실에 있다. CORBA의 IDL도 그렇고 웹 서비스의 WSDL도 그렇고, 추상이 지나치다 보니 되래 감이 안 온다. 즉 어떻게 짜야할지, 특히 그러한 추상적 인터페이스 선언에 익숙하지 않은 개발자들에게는 시간도 쫓기는데 난감할 따름이다.

JAX-RPC 2.0 ED2

JAX-RPC 1.1까지 자바 웹 서비스의 사실상 모든 것을 담당해왔던 JAX-RPC는 2.0으로 오면서 XML과 자바 사이의 대응을 JAXB 2.0에게 넘기도 무척 가벼워졌다. 이제 JAX-RPC가 할 일은 WSDL과 자바 간의 대응이고, WSDL 안의 타입에 대한 대응은 JAXB 쪽으로 위임하도록 되어 있다. JAX-RPC 2.0과 JAXB 2.0은 J2SE 6.0 머스탱에 포함될 예정이므로, 앞으로 웹 서비스 클라이언트를 실행하기 위해 별도의 런타임 라이브러리를 추가할 필요가 없어지게 된다. 만약 택시 예약 서비스의 J2SE 리치 클라이언트에서 RCP를 쓰지 않는다면, 머스탱에서는 애플리케이션 코드만으로 클라이언트를 돌릴 수 있다. JAX-RPC 2.0은 JAXB 2.0뿐만 아니라 WSM도 포함하고 있어서, 자바와 XML 스키마-WSDL간의 대응을 완벽히 조절할 수 있는 강력함이 기대되는 기술이기도 하다.

어차피 프로그램은 프로그래밍 언어로 짜는 것, 그래서 바로 특정 프로그래밍 언어로부터 WSDL를 생성하는 방식이 있는 셈이다.

<그림 4> 프로그래밍 언어 중심 개발

<그림 4>는 자바 개발자가 웹 서비스 제공자를 제작하고 .NET 개발자가 웹 서비스 소비자를 제작하는 경우의 예이다. 누군가가 중간의 위치에서 WSDL을 설계하는 것이 아니라, 서비스 공급 측의 프로그래밍 언어로부터 WSDL이 유도되고 바로 그 WSDL을 서비스 수요측이 끌어오는 꼴이다.

이때에는 역으로 자바에서 WSDL로 대응하는 규칙과 툴이 필요한데, 역시 JAX-RPC에서 그 일을 맡는다. 그런데 가만 생각해보면, 태생부터가 다른 자바와 WSDL(그리고 XML 스키마까지)을 딱딱 들어맞게 대응시킨다는 것은 근본적으로 어려움이 있을 수밖에 없다. 이 문제 있어 자바는 .NET에 비해 꽤나 뒤져 있는데다가(필자의 팀장님마저 늘 감탄해마지 않는다. 그리고도 C#은 나올 때부터 메타데이터를 지원해왔다), 툴도 플랫폼(액시스, 썬 RI, BEA 등) 별로 가지각색이어서 플랫폼간의 이동이 불편하기까지 하다.

자바 웹 서비스의 현실은 사실 이 업계에 종사하고 있는 필자도 암담하게 느껴질 때가 종종 있다. 부족한 점이 여기저기 눈에 띄며, .NET을 위시한 경쟁자들의 움직임도 만만치 않다. 그러나 분명한 것은 역설적으로 그만큼 기회가 많기도 하다는 인식이다. 불편한 것도 많고 안되는 것도 많다. 그러니까 발전할 여지가 무궁무진하다면 너무 긍정적인 시각일까?

숨 고르기
지난 달 독자의 몫은 어떻게 준비되고 있는지 필자로서 몹시 궁금하다. 매우 몰아치기는 했지만, 사실 한달 만에 모든 것을 준비하기란(거기에 주업까지 겸하고 있다면) 너무 빡빡했을지도 모른다는 생각이 이제야 들어 미안함과 동시에, 약간의 시간 여유를 줄 수 있게 되어 다행스럽기도 하다.

JSR 223 "Scripting for Java Platform"

필자의 이번 학기 수강 과목 중에 ‘인터넷 프로그래밍’이라는 과목은 PHP를 가르친다. 내내 서블릿과 JSP만 해왔던 필자에게는 새로운 경험이라 좋았지만, 막상 과제를 하려니 ‘JSP였으면···’하는 생각이 들지 않을 수 없다. 그런데 공교롭게도 이 과목의 선생님은 자바를 무척 싫어하는 분이다. 기본적으로 강한 타입의 언어를 좋아하지 않고(몹시 연로하신 박사님이다), 스크립트 언어의 가볍고도 간결한 표현력에 무게를 더 두는 그런 분이다. 필자도 물론 자바가 전부라고 생각하지는 않지만, 웬만하면 자바로 하고 싶은 개인적인 편애가 있다고 생각해보니 선생님의 마음도 이해는 갔다. PHP는 확실히 웹 사이트 개발에 있어 강력한 점이 많다. JSP 2.0이고 JSF고 하지만 프레임웍이 없기 전에는 정말이지 끔찍했었고, 프레임웍이 나오고 나니 이제는 복잡하기 그지없다. 하지만 비즈니스 컴포넌트의 구성에 있어 자바는 그 위치가 높아지고 있어 웹 시스템 개발자에 있어 자바 친화적인 사이트의 개발은 전부 자바로 하는 것 이상의 현실적인 방안이 없었던 셈이다. 톰켓의 아버지이자 이제는 스트럿츠의 아버지로 유명한 크랙 맥클래너헌의 아들이야기가 스트럿츠 배포판의 한 텍스트 파일에 들어 있는데, 자신은 자바로 먹고 살고 있지만 아들은 PHP 프로그래머라고 한다(우리 나라에는 아직 이런 부자 관계가 없을 것이다. 이 정도 되려면 아버지가 적어도 50대까지 현역 프로그래머여야 한다. 물론 일반적으로 그렇다는 거고, 아주 일찍 장가가고 아들이 병역 면제라면 40대-20대 부자 프로그래머가 탄생 가능하다. 하지만 한국의 프로그래머 아버지가 아들이 프로그래머 되는 걸 좋아할까?) 자신은 아들에게 자바를 강요까지는 아니지만 강조해도 아들은 PHP가 좋다고 한다니, 솔직히 필자가 그런 아들을 두었다 해도 잘 이해는 안갈 것 같다(결코 세대차가 아니다). 이런 세상이다. 공존이 필요하다. PHP에서 자바를 불러 쓸 수 있고 자바에서도 PHP를 불러 쓸 수 있는 세상. 그것이 바로 JSR 223, 자바 플랫폼 스크립트 기술이다. PHP뿐만 아니라 자바스크립트에 최근 관심을 불러 모으고 있는 그루비(Groovy)까지 실제 지원되고 있다. 현재 스펙 공개안까지 나온 상태(참고 자료 3)고, JWSDP 1.5와 잘 붙는 구현체도 있다(참고 자료 4). 마침 JSR 223의 스펙 리드인 Michael Grogan이 JAX-WSA도 함께 하고 있어 얘기를 나눠보니 PHP의 발전 속도가 (JSR 223 구현체에 비해) 너무 빨라 JSR 223의 구현 프로젝트도 PHP 오픈소스 프로젝트 안에서 하면 좋겠다고 한다. 새 버전의 PHP가 나올 때마다 따라서 업데이트된 JSR 223 구현체가 함께 나온터라, 마치 MySQL과 MySQL Connector/J(JDBC 드라이버) 같은 느낌이 든다. 앞으로도 더 많은 스크립트 언어가 JSR 223을 지원하여 서로 보완하는 프로그래밍 환경으로 나아가리라 믿는다.

그리고 안타깝게도, 썬의 WS-I SA 1.1에 들어 있는 JAX-RPC 2.0과 JAXB 2.0 RI는 매우 급조한 형태라서 자바->WSDL 형식의 개발을 JAXB 2.0과 WSM의 어노테이션으로 커스터마이즈하는 방법이 아직 분명하지가 않다. 그리고 이클립스의 RCP도 다음 달에 API가 확정되므로 그에 맞춰 나아가는 것이 좋으리라 여겨진다. 이렇게 기반 기술들이 마련되어 가는 동안 독자가 할 일을 다시 한번 정리해보면,

◆ 학습 분야
- 코디네이터 : end-to-end 설계 전반, SOA 방침, WSDL, XML 스키마, SVN, CruiseControl, Wiki
- EJB 담당 : EJB 3.0 기술, JBoss EJB 3.0 조기 구현체, JBoss 4.0
- JWS 담당 : JAX-RPC 2.0+JAXB 2.0, WSM 기술, WS-I SA 1.1, Tomcat 5.5
- RCP 담당 : SWT, JFace, 이클립스 RCP, JAX-RPC 2.0+JAXB 2.0
- MIDlet 담당 : MIDP 2.0, JSR 172 J2ME Web Services, WTK WSDL 툴
- JSF 담당 : JSF 기술, MyFaces(HTML 렌더링 킷, WML 렌더링 킷), Jetty 5.0, JAX-RPC 2.0+JAXB 2.0

◆ 준비 분야
- 코디네이터 : SVN, CruiseControl, Wiki 환경 구축 및 사용 방법 전파
- EJB 담당 : JBoss 4.0 + EJB 3.0 서버 준비 및 세션 빈, 엔티티 빈 테스트
- JWS 담당 : WS-I SA 1.1 테스트
- RCP 담당 : 이클립스 RCP 실행 환경 테스트
- MIDlet 담당 : WTK 2.2 실행 환경 및 웹 서비스 테스트
- JSF 담당 : Jetty 5.0 + MyFaces 서버 준비 및 HTML·WML 렌더링 테스트

◆ 토의 분야
- 이상적인 프로젝트 디렉토리 구조(소스, 테스트, 바이너리 위치등) 합의
- 테스트 작성 방식(각 모듈 담당은 독립적으로 테스트 작성. 코디네이터는 통합 테스트 작성 및 각 모듈 당당이 독립적인 테스트 작성을 할 수 있도록 더미 데이터 제공)
- Wiki를 통한 실시간 문서 작성 규칙(문서 양식과 대상 항목 등)

학습 분야와 준비 분야가 WSM(액시스, 비하이브 WSM)에서 JWS(JAX-RPC 2.0과 JAXB 2.0)으로 바뀌었으므로 이 점 주의하길 바란다.

어떻게 생각해? - SOA 개발
2월은 짧고도 각종 프로젝트의 출범으로 숨가쁜 달이었다. 남들 2년 하는 석사를 1년에 하려다 보니(영국의 특이한 제도라 시간 절약 차원에서 고맙기는 하지만), 방학이 아닌 2월은 참으로 적응이 안 되는 시간의 연속이었다. 혹시나 이미 지난 달의 임무를 완벽히 마친 독자 팀이 있다면, 지체 없이 구현으로 들어가 보기를 강력히 권한다. 다음 달에는 서비스 측을 위한 UML과 클라이언트 측 공통 UI 설계도를 바탕으로 택시 예약 서비스의 구현에 다가가 보도록 하겠다.@

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.