SOA : 자바 웹 서비스로 통하는 서비스 지향 아키텍처

SOA자바 웹 서비스로 통하는서비스 지향 아키텍처

SOA자바 웹 서비스로 통하는서비스 지향 아키텍처

지은이 _마크 D. 한센 옮긴이 _SOA-JWS 팀

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 �SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 i� SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 �SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 i�

목 차

01장 자바웹서비스와함께하는서비스-지향아키텍처 2

1.1 내가 멍청한 걸까? 아니면 자바 웹 서비스가 진짜 어려운 걸까? .............. 2

1.1.1 기술에 쉽게 현혹되지 말라 ............................................. 4

1.1.2 JWS는 도구 모음이지 애플리케이션이 아니다 .............................. 6

1.1.3 깨달음 .............................................................. 7

1.2 웹 서비스 플랫폼 아키텍처 ............................................. 8

1.2.1 호출 ................................................................ 8

1.2.2 직렬화 .............................................................. 11

1.2.3 배포 ................................................................ 16

1.3 자바 웹 서비스 : 2장 ~ 8장 ........................................... 18

1.4 SOAShopper 사례 연구 : 9장 , 10장 .................................... 21

1.5 SOA-J와 WSDL 중심 개발 : 11장 ........................................ 22

02장 자바웹서비스개관 25

2.1 SOA 애플리케이션 개발에서의 JWS의 역할 ................................ 26

2.1.1 가상의 SOA 애플리케이션 .............................................. 26

2.1.2 SOA 개발을 가능하게 하는 JWS ......................................... 29

2.2 사용 편의 특성에 대한 개관 ............................................ 36

추천자 서문 .......................................................... xvii

저자 서문 ........................................................... xxi

이 책에 대해 ......................................................... xxiii

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 �SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 i� SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 �SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 i�

2.2.1 소스 코드 어노테이션 .................................................. 37

2.2.2 표준 WSDL/자바 매핑 ................................................. 38

2.2.3 표준 직렬화 컨텍스트 .................................................. 39

2.2.4 개발 모델 ........................................................... 40

2.2.5 JWS 타협점Trade-Off .................................................. 42

2.3 JAX-WS 2.0 .......................................................... 43

2.3.1 자바/WSDL 매핑 ...................................................... 44

2.3.2 정적 WSDL .......................................................... 45

2.3.3 동적 클라이언트와 정적 클라이언트 ...................................... 45

2.3.4 자바 인터페이스 프록시를 통한 호출 ..................................... 46

2.3.5 XML로 호출 ......................................................... 46

2.3.6 XML 서비스 프로바이더 ............................................... 46

2.3.7 핸들러 프레임워크 .................................................... 47

2.3.8 메시지 컨텍스트 ...................................................... 48

2.3.9 SOAP 바인딩 ......................................................... 48

2.3.10 HTTP 바인딩 ......................................................... 49

2.3.11 예외 상황의 SOAP 결함으로의 변환 ...................................... 49

2.3.12 비동기 호출 .......................................................... 50

2.3.13 단방향 오퍼레이션 .................................................... 50

2.3.14 클라이언트 측의 스레드 관리 ........................................... 50

2.3.15 WSDL 스타일 - RPC/Literal과 Document/Literal Wrapped 스타일의 지원 ....... 50

2.3.16 XML 카탈로그 ....................................................... 51

2.3.17 가참조Pseudoreference의 전달(출력과 입/출력 파라미터 Holder<T>) ........... 52

2.3.18 런타임 엔드포인트의 공개(Java SE 한정) ................................ 52

2.4 JAXB 2.0 ........................................................... 54

2.4.1 XML 스키마의 자바 표현으로의 연동 ..................................... 57

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 �iiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 �i SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 �iiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 �i

2.4.2 자바 타입의 XML 스키마로의 매핑 ....................................... 59

2.4.3 매핑 어노테이션 ...................................................... 59

2.4.4 바인딩 언어 .......................................................... 62

2.4.5 바인딩 런타임 프레임워크(마셜링/언마셜링) ............................... 65

2.4.6 유효성 검증validation .................................................. 69

2.4.7 이식성portability....................................................... 70

2.4.8 마셜 이벤트 콜백Marshal Event Callback.................................... 71

2.4.9 부분 바인딩 .......................................................... 71

2.4.10 이진 데이터 인코딩(MTOM 혹은 WS-I) ................................. 72

2.5 WS-Metadata 2.0 ..................................................... 73

2.5.1 WSDL 매핑 어노테이션 ................................................ 78

2.5.2 SOAP 바인딩 어노테이션 ............................................... 78

2.5.3 핸들러 어노테이션 .................................................... 79

2.5.4 서비스 구현 빈 ....................................................... 79

2.5.5 WSDL과 자바로부터 시작하기 ........................................... 79

2.5.6 자동 배포 ........................................................... 80

2.6 엔터프라이즈 웹 서비스: WSEE 1.2 ..................................... 80

2.6.1 포트 컴포넌트 ........................................................ 81

2.6.2 서블릿 엔드포인트 .................................................... 81

2.6.3 EJB 엔드포인트 ....................................................... 82

2.6.4 단순화된 패키징 ...................................................... 82

2.6.5 핸들러 프로그래밍 모델 ................................................ 82

2.7 그 밖의 Ja�a EE 5 어노테이션의 영향력 ................................... 82

2.7.1 의존성 주입 .......................................................... 82

2.7.2 인터셉터 ............................................................ 83

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 �iiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 �i SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 �iiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 �i

2.7.3 EJB 3.0에서의 POJO 지원 .............................................. 83

2.8 결론 ................................................................ 84

2.8.1 예제 구축과 실행을 위한 환경 설정 ...................................... 84

03장 REST를이용한기본SOA 85

3.1 왜 REST인가? ........................................................ 85

3.1.1 REST란 무엇인가? .................................................... 86

3.1.2 이 장에서 다루는 주제 ................................................. 87

3.2 EIS 레코드를 위한 XML 문서와 스키마 .................................... 88

3.2.1 반드시 WSDL이 아니라고 인터페이스가 아니라는 의미는 아니다 .............. 96

3.3 JWS를 사용하는 REST 클라이언트와 JWS를 사용하지 않는 REST 클라이언트 ...........97

3.3.1 JWS를 사용하지 않고 REST 서비스로부터 EIS 레코드 가져오기 ................ 98

3.3.2 JWS를 사용하는 REST 서비스로부터 EIS 레코드 가져오기 .................... 101

3.3.3 JWS 사용 없이 EIS 레코드를 REST 서비스에 보내기 ......................... 105

3.3.4 JWS를 사용하여 RESTful 서비스에 EIS 레코드를 보내기 ...................... 110

3.4 데이터 변환을 위한 XSLT와 JAXP를 사용한 SOA－스타일 통합 ................ 114

3.4.1 데이터 변환을 위한 XSLT 사용 방법과 이유 ................................ 115

3.4.2 JAXP를 사용한 XSLT 처리 .............................................. 121

3.5 JWS를 사용하는 경우와 사용하지 않는 경우의 RESTful 서비스 ............. 126

3.5.1 JWS를 사용하지 않고 REST 서비스 배포 .................................. 126

3.5.2 JWS를 사용하여 RESTful 서비스 배포 ..................................... 132

3.6 결론 ................................................................ 136

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 ixSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 �iii SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 ixSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 �iii

04장 SOA에서의WSDL,SOAP그리고자바/XML매핑의역할 137

4.1 SOA에서의 WSDL의 역할 ............................................... 138

4.1.1 WSDL 예제 .......................................................... 141

4.2 SOA에서의 SOAP의 역할 ............................................... 145

4.3 디스패치: 어떻게 JAX-WS 2.0이 WSDL/SOAP을 자바 호출에 대응시키는가 ....... 151

4.3.1 WSDL 포트 결정 ...................................................... 151

4.3.2 WS-I Basic Profile의 역할 ............................................... 153

4.3.3 RPC/Literal .......................................................... 154

4.3.4 Document/Literal ..................................................... 156

4.3.5 Document/Literal Wrapped ............................................. 159

4.3.6 디스패치 처리 요약 ................................................... 162

4.3.7 SOA 통합을 위한 JAX-WS 2.0 디스패치의 단점 ............................. 165

4.4 JAX-WS 2.0 디스패치 제약의 극복 ...................................... 166

4.5 SOA는 종종 ‘WSDL과 자바로부터’를 원한다. .............................. 175

4.5.1 SOA에서의 자바/XML 매핑의 역할 ....................................... 178

4.5.2 SOA에 있어 자바/XML매핑를 위한 JAXB 2.0의 한계 ........................ 180

4.6 JAXB 2.0의 자바/XML 매핑 제한의 극복 .................................. 182

4.6.1 스키마 컴파일러와 자바의 사용 ......................................... 182

4.6.2 스키마 생성기와 XSTL의 사용 ........................................... 189

4.7 결론 ................................................................ 194

05장 JAXB2.0데이터바인딩 195

5.1 바인딩 대 매핑 ....................................................... 195

5.2 표준 JAXB 2.0 자바/XML 바인딩의 개요 ................................. 199

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 ixSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 �iii SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 ixSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 �iii

5.3 JAXB 2.0으로 타입 매핑 구현하기 ........................................ 209

5.4 타입 매핑을 위한 재귀적 프레임워크 ..................................... 217

5.5 JAXB 2.0 어노테이션으로 타입 매핑 구현하기 .............................. 224

5.6 JAXB 2.0 바인딩 언어로 타입 매핑 구현하기 ............................... 235

5.7 JAXB 2.0 XmlAdapter 클래스로 타입 매핑 구현하기 ........................ 245

5.8 XSLT를 대신해 데이터 변환을 처리하는 JAXB 2.0 ........................... 256

5.9 결론 ................................................................ 262

06장 JAX-WS클라이언트측개발 265

6.1 JAX-WS 프록시 ....................................................... 265

6.1.1 JAX-WS의 WSDL에서 자바로의WSDL to Java 매핑 ....................... 267

6.1.2 서비스 엔드포인트 인터페이스 어노테이션 ................................ 273

6.1.3 프록시로 웹 서비스 호출하기 ........................................... 279

6.1.4 프록시로 오류 처리하기 ................................................ 282

6.2 XML 메시징 .......................................................... 285

6.2.1 정제하지 않은Raw XML로 XML 메시징하기 ................................. 286

6.2.2 커스텀 어노테이션 JAXB 클래스들로 XML 메시징하기 ....................... 289

6.3 커스텀 자바/XML 매핑으로 호출하기 : JAXB 대신에 Castor를 사용하는 예제 ..........292

6.4 비동기 호출 .......................................................... 297

6.4.1 폴링 ................................................................ 297

6.4.2 프록시와 비동기 메소드 ................................................ 299

6.4.3 콜백 ................................................................ 301

6.5 SOAP 메시지 핸들러 .................................................. 304

6.6 결론 ................................................................ 310

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 x SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 x

07장 JAX-WS2.0-서버측개발 311

7.1 JAX-WS 서버 측 구조 .................................................. 311

7.2 서비스 엔드포인트 인터페이스SEI를 사용하는 WSDL로부터 시작하기 ........... 316

7.3 JAXB를 사용하지 않는 프로바이더와 XML 처리 ............................. 320

7.4 커스텀 자바/XML 매핑을 사용하는 웹 서비스 배포하기 ...................... 325

7.5 유효성 검사와 폴트 처리 ............................................... 329

7.5.1 유효성 검사Validataion ................................................. 329

7.5.2 폴트 처리 ........................................................... 332

7.6 서버 측 핸들러 ....................................................... 343

7.7 ja�ax.xml.ws.Endpoint를 사용해 Java SE에서의 배포 ....................... 347

7.8 결론 ................................................................ 355

08장 SOA컴포넌트의패키징과배포[JSR-181과JSR-109] 357

8.1 웹 서비스 패키징과 배포 개요 ........................................... 359

8.1.1 WAR를 사용한 서블릿 엔드포인트 패키징 ................................. 360

8.1.2 EJB-JAR를 사용한 EJB 엔드포인트 패키징 ................................. 363

8.1.3 자동배포 ............................................................ 365

8.1.4 컨테이너의 배포 과정에 대한 개요 ....................................... 365

8.1.5 EJB 엔드포인트 배포와 실행 ............................................ 371

8.2 배포 기술자 없는 배포 ................................................. 376

8.2.1 서비스 구현 빈 만을 사용하기 ........................................... 376

8.2.2 서비스 엔드포인트 인터페이스 사용하기 .................................. 378

8.2.3 WSDL 아티팩트를 포함하기 ............................................. 381

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 x SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 x

8.3 배포 기술자 사용하기 .................................................. 384

8.3.1 서블릿 엔드포인트를 위한 web.xml ...................................... 384

8.3.2 무상태 세션 빈 엔드포인트를 위한 ejb-jar.xml.............................. 390

8.3.3 webser�ices.xml을 사용할 때 ........................................... 395

8.3.4 플랫폼에 한정된 배포 기술자 ........................................... 397

8.4 글래스피시의 자동배포 ................................................ 402

8.5 웹 서비스 보안 ....................................................... 405

8.6 OASIS XML 카탈로그 1.1 ............................................... 407

8.7 요약 ................................................................ 409

09장 SOAShopper:이베이,아마존,야후쇼핑통합하기 411

9.1 SOAShopper 개요 .................................................... 411

9.2 SOAShopper SOAP 서비스들 ........................................... 417

9.3 SOAShopper의 RESTful 서비스와 표준 XML 스키마 ......................... 423

9.4 서비스 구현체 ....................................................... 431

9.5 이베이와 아마존 서비스 (SOAP) ......................................... 434

9.6 야후 서비스(REST) .................................................... 444

9.7 SOAShopper API와 통합 계층 ....................................... 450

9.8 Ja�a EE상의 실세계 SOA애플리케이션 구현에 대한 결론 .................... 460

10장 Ajax와자바웹서비스 463

10.1 Ajax 개괄 ............................................................ 464

10.2 Ja�a EE 웹 서비스와 Ajax의 연동 ........................................ 468

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xiiiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xii SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xiiiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xii

10.3 예제 코드 : SOAShopper Ajax 프론트엔드 ................................ 470

10.4 Ajax와 Ja�a EE에 대한 결론 ............................................. 479

11장 SOA-J를이용한WSDL중심자바웹서비스 481

11.1 SOA-J 아키텍처 ....................................................... 483

11.2 SOA-J를 이용한 WSDL 중심 개발 ........................................ 486

11.3 호출Invocation 하부시스템 .............................................. 493

11.4 직렬화Serialization 하부시스템 ........................................... 503

11.5 배포 하부시스템 ...................................................... 514

11.6 결론 ................................................................ 519

부록A 이책에서사용되는자바,XML그리고웹서비스표준들 523

부록B 소프트웨어구성안내 525

B.1 Ja�a EE 5 SDK 설치 ................................................... 526

B.2 아파치 Ant 1.7.x 설치 ................................................. 527

B.3 아파치 Ma�en 2.0.x 설치 ............................................... 527

B.4 책 예제코드 설치 ..................................................... 528

B.5 Ma�en 설정.......................................................... 528

B.6 Ant 설정 ............................................................ 530

B.7 글래스피시 서버의 시작과 정지 ......................................... 532

B.8 예제를 실행하여 설치 테스트하기 ........................................ 532

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xiiiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xii SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xiiiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xii

B.9 SOAShopper Case Study 빌드와 배포(9, 10장) ............................. 534

B.10 SOA-J 애플리케이션 프레임워크 빌드하고 배포하기(11장) ................... 535

B.11 Ja�a SE 6 설치 (선택적) ............................................... 535

부록C 네임스페이스접두어(Prefix) 537

부록X JEUS6에서예제실행하기 539

X.1 Ma�en 설정.......................................................... 539

X.2 Ant 설정 ............................................................ 541

X.3 예제를 실행하여 설치 테스트하기 ........................................ 543

용어정리 545

참고자료 561

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 x�SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xi� SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 x�SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xi�

옮 긴 이 글

장동준“처음이란 말은 나를 참 설레게 하는 말이다. 그렇지만, 시작이란 말은 나를 참 긴장하게 만든다. 성

공이나 실패에 대한 두려움보다 끝을 예측할 수 없기에, 나는 처음 해보는 시작을 좋아한다. 그래서,

흔쾌히 번역에 참여를 하게 됐다. 어느덧 시작에 대한 책임을 질 때가 왔다. 졸역에 대한 독자들의 따

끔한 질책과 혹평을 겸허히 받을 준비를 해야겠다. 스터디를 통해 도움을 많이 주신 창신님을 비롯한

모든 공역자 분들께 진심어린 감사를 드리며, 번역을 위해 주말을 흔쾌히 허락해 준 아내 종숙과 아영,

신희에게 심심한 고마움을 전한다.”

오픈마루에서 자아의 발현을 위해 노력하는 범인이고, 속내를 볼 수 있는 자바를 좋아한다. XML 문

서 관리, 이메일 응대, 검색, 지능형 에이전트, 플랫폼 프로바이더 관련 일들을 하였다.

조지훈“그리 길지 않은 시간이었는데, 시작할 때와는 많은 것들이 달라졌다. 번역은 영어가 아니라 국어

실력에 좌우된다는 점을 새삼 깨닫게 해준 첫 번역 작업, 존경하는 선배님들과 함께 할 수 있었기에

더욱 의미 있는 추억으로 남는다. 언제나 믿음과 기대로 살펴주시는 선배님들께 부끄럽지만 또한 설레

는 마음으로 이 책을 전해드리고 싶다. 그리고 아직은 좋은 아빠, 능력 있는 아빠에도 부족하기만 한

내게 ‘세상을 사는 이유, 그 자체’가 되어 준 첫 딸 ‘은’이와 가족들에게 감사의 마음을 전한다.”

NHN 웹플랫폼개발팀에서 전사 플랫폼 개발과 자바 관련 기술지원 및 교육을 담당하고 있다.

J2eeSTUDY(http://www.j2eestudy.co.kr)를 통해 ‘사람 냄새나는 따뜻한 개발자 커뮤니티’를 이루려

는 꿈많은 개발자이다.

정지웅“좋은 책, 무엇보다 평소에 존경해오던 분들과 함께 작업하며 많은 것을 배웠던 소중한 경험이었던

것 같습니다. Saas와 같은 낯선 단어들이 새로이 떠오르는 요즘, SOA가 말하는 비전은 이제부터가

본격적인 시작이 아닌가 하는 생각을 해봅니다. 물론 그 중심에는 더욱 성숙해진 자바 웹 서비스가 자

리잡고 있을 것이고, 이 책이 가지는 의미도 그런 시작을 알린다는 의미에서 더 각별한 것이 아닐지요.

창신님을 비롯해 가르침 주신 많은 공역자 분들께 감사드리며, 아무쪼록 이 책이 더 즐거운 웹 세상을

만드는데 작은 보탬이 되었으면 하는 바람입니다.”

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 x�SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xi� SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 x�SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xi�

오픈마루 스튜디오에서 즐거운 웹을 만들기 위해 노력하고 있는 개발자다. 주된 관심사는 데이터

중심의 웹 , 정보조직화 등이며, 블로그(http://humbleprogrammer.net/blog)에 관련된 이야기를 풀

어놓고 있다. 역서로 '자바 개발자를 위한 레일스'가 있다.

성명식“읽어보려 마음먹었던 책이었기에 겁 없이 달려들었습니다. 늘 하던 분야이기에 쉽게 생각했었습니

다. 고된 작업이었습니다. 하지만, 많은 것을 얻었습니다. 명세가 알려주지 못하는 많은 것들을 이 책

에서 볼 수 있어서 제 일에도 많은 도움이 되었습니다. 시간을 내서 다시 한 번 읽어볼 생각입니다. 이

책을 추천해 주시고 이 작업에 동참하도록 이끌어 주신 호경님과 창신님께 감사를 전합니다.”

티맥스소프트에서 JEUS 웹 서비스 모듈을 담당하고 있는 개발자이다. Java EE 웹 서비스를 비롯하

여 SOA, ESB 등 서비스 아키텍쳐에 관심을 두고 있다.

박호경“2007년 샌프란시스코에서 열렸던 자바원 컨퍼런스의 한켠에 자리잡은 북쉐프에서 처음 이 책을 발

견했었을 때, 최근 웹 서비스 분야에서 많은 개발자들의 관심사와 중요한 변화가 잘 반영되어 있는 아

주 알차게 정리된 책이라는 인상을 받았습니다. 이 책은 SOA 시대의 한 축을 담당하고 있는 웹 서비

스의 주요 기반 기술들에 대해서 보다 쉽게 설명하고 있으며, 최근 발전되어 온 여러 명세들에 대한

개념, 필요성과 그 적용에 대해 잘 설명하고 있습니다. 이 책을 독자들에게 전달할 수 있게 되어서 아

주 기쁘게 생각합니다. 번역에 있어서는, 그간의 현장에서의 개발 경험을 살려 본 책의 내용을 가능한

알기 쉽게, 그리고 내용이 변질되지 않게 전달하려고 노력하였습니다. 앞으로 웹 서비스 기술을 적용

혹은 개발하려는 사람들이 보다 본질적인 내용을 이해하는데 도움이 되었으면 합니다. 오랜 시간 함

께 웹 서비스를 연구해 오며, 책의 내용에 대해서 많은 가르침과 의견을 제시해 준 명식님과 창신님께

감사를 전합니다.”

티맥스소프트에서 JEUS 웹 서비스 모듈 개발을 담당하였다. Java EE 웹 서비스, 웹 서비스 보안과

웹 서비스 트랜잭션 모듈 개발에 주로 관여하였다.

강규영“보다 충실한 번역을 위해 원서를 가지고 역자들끼리 사전 스터디를 하였는데, 덕분에 훌륭한 분들

과 함께 공부할 기회를 얻게 되었습니다. 개인적으로는 이것만으로도 충분히 보람 있는 일이었습니다.

이 책이 독자 여러분의 공부에 조금이나마 도움을 드릴 수 있다면 더욱 기쁘고 보람찬 일이 되겠지요.”

오픈마루 스튜디오에서 스프링노트 개발에 참여하고 있다. 자바스크립트용 행동 주도 개발 프레임워

크인 JSSpec, 웹 기반 WYSIWYG 편집기인 Xquared 등의 오픈소스 프로젝트를 리드하고 있으며 현

재 개인 위키 http://jania.pe.kr 과 블로그 http://alankang.tistory.com 을 운영하고 있다.

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 x�iiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 x�i SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 x�iiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 x�i

이창신“수년간 티맥스에서 미쳐(?) 살았던 분야라는 원서의 치명적인 매력 덕분에 근 1년간 이 책의 번역

에매달리고 말았습니다. 「퍼펙트 JSP」 개정판 이래 두 번째로 코디네이터 역할까지 감행할 정도로,

제 개발자 인생의 중간평가 같은 심정이라면 너무 솔직한 거 아닌지 모르겠네요. SOA도 자바 웹 서비

스도 이 책을 통해 어렵고 복잡하다는 오명을 씻을 수 있으면 좋겠습니다. 전 동료(박호경, 성명식, 조

지훈)와 현 동료(장동준, 정지웅, 강규영)가 함께했다는 것도 특별하기 그지없습니다. 자바, XML, 웹

서비스를 마음껏 토론하고 소통할 수 있었다는 사실만으로, 저는 늘 그렇듯이 팀 모두에게 고마울 뿐

입니다. 이렇게 제 10번째 책이 나왔다는 것이 믿기지 않네요. 작년에 참 많이도 다른 분들의 책에 추

천사를 썼는데, 제 책이다 보니 참 쑥스럽습니다. 끝으로, 이 책을 내주신 위키북스와 베타리더 이동

국님께 충심으로 감사드립니다.”

엔씨소프트 오픈마루 스튜디오에서 OTO(Open Technology Officer)로 일하고 있다. OpenID,

OAuth, OpenSocial 등 공개 표준 기술에 대한 연구, 구현, 보급에 힘쓰고 있다. http://www.

iasandcb.pe.kr

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 x�iiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 x�i SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 x�iiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 x�i

과거마이크로소프트소속이었던PatHelland는상호운영성interoperability을논할때단어의

앞글자만따서즐겨쓰는약어가있다.HST,즉“싹엮기HookingStuffTogether”(실은,그는중간

에완전히다른단어(Shit이다－옮긴이주)를쓰지만,이책은온가족이함께볼수있는등급

이므로완곡하게표현했다)이다.아무리현란한용어와복잡한도표로포장해도,상호운영성

은그냥“싹엮기”이고,웹서비스WebServices도바로그런것이다.

세상에두번째컴퓨터가온라인에등장한이래,진정한상호운영성은여전히우리에게미

완의과제를남기고있다.IT환경은서로다른기술의광대한배열의중심에서서각자유용

한기능을제공하고있다(거나적어도나는그렇게들었다).비록다양한업체가애플리케이

션을구축하는(그리고이식하는)용도로자신들의도구를유일한/지배적인선택의자리에오

르게하려고애썼지만,IT세계의기술들이통합되기는커녕더욱다양해지고있다.수많은솔

루션들이기반언어,플랫폼,운영체계,하드웨어에무관하게‘A’프로그램이‘B’프로그램에말

을걸수있게하는까칠한문제의‘정답’임을자처해왔다.하지만‘모아니면도’식의사고방

식을요구하거나가장간단한상황만대처할수있을뿐,그이상은안되는솔루션을제공하

는등어떤것도완전히성공적임을입증하지는못했다.

1998년,돈박스DonBox와데이브위너DaveWiner그리고마이크로소프트,IBM,Lotus의몇

몇사람들이모여앉아원격프로시저호출remoteprocedurecall,RPC층을XML메시지로옮기

는아이디어를기술하는짧은문서를썼다.착상은간단했다.당시나왔던모든분산오브젝

트툴킷distributedobjecttoolkit－DCOM,자바RMI,CORBA가주된관심사였던－이하나의공

통된네트워크전송형식을공유한다면,엔터프라이즈IT프로그래밍의성배HolyGrail인진정

한상호운영성을이룩하는것은간단한일이될거란것이었다.

처음에는,SOAP이더간단하고나은HST의길을열것을약속했다.HTTP위에서전달되며,

데이터표현의만국공통어인XML기반으로,기존의분산오브젝트프로그래밍모델의모든

시멘틱semantic으로무장된오브젝트전쟁의다크호스였다.쉽게성공할것처럼보였다.분산

추 천 자 서 문

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xixSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 x�iii SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xixSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 x�iii

오브젝트의생성된코드깊숙이,아무도뒤져보지않을곳에XML을슬쩍흘려놓으면그만

이었다.당시우리가깨닫지못했던것은,안타깝게도이전망이너무도얄팍했고무서우리만

치순진했다는것이다.확실히비슷한(Java와.NET같은)환경에서는얼추맞아들어갈지도

모른다.하지만,그런경우에서조차XML이간단히해결해주지못하는차이로인해문제가생

기기쉽다.소위표준이라는것도사실어떤법적표준단체의소산이아니었다는사실과더

불어,업체들은‘WS-어쩌고저쩌고’명세를자고일어나면찍어내기바빴고,SOAP이추구했던

간단명료함은한마디로실종되었다.솔직히,좀험하게말하면,오랜동안전체웹서비스스

토리는‘메시지’라기보다는‘메스꺼움’(원어는mess엉망진창이었지만운율을맞추기위해메

스꺼움으로옮겼다－옮긴이주)이더했다.

이책의1장에서저자마크헨센MarkHensen은“웹서비스는쉽지않다”고썼다.대체‘SOAP’

의‘Simple’은어떻게된걸까?

얄궂게도,웹서비스가‘저속어dirtyword’상태를떠안고출발했지만,EJB와COBOL과마찬

가지로그메시지는점차분명해지고있으며‘바른말고운말’의기회도이토록고조된적이

없다.(SOAP1.2명세와REST논문을제대로읽어본사람이라면누구라도지적할수있는,

진정논쟁이라고할수없는)SOAP대REST논쟁과같은물타기는차치하더라도,마침내여

러업체와업계단체가단지“나는너한테문자열을넘길테니너는파싱parsing하고...”라는

것보다더욱의미있는방식으로실질적인HST를할수있는지점에이르고있다.

나는자바,.NET,XML을가르쳤던DeveloperMentor에서지도자로서,돈박스나마틴가

진MartinGudgin과같이W3C대표로SOAP과스키마명세를쓰던사람들과SOAP,WSDL,웹

서비스를배울기회를가졌다.자바,.NET,그리고다른플랫폼간의상호운영성에초점을맞

춘업계컨설턴트로서,나는실세계의상호운영성문제를보는독특한1인칭시점을지니고

있다.그리고또한독립강연자겸멘토로서,여러상호운영성도구를공부하고얼마나잘돌

아가는지파악하게된다.

모두그런기회를가지는것은아니지만,나같이저수준의‘삽질’오타쿠여서밤하늘의별

만큼이나많은WS-*관련명세를읽으며자학적인쾌락을추구하지않는이상,SOAP이나

WSDL은불가사의로남을것이고,척보기에누구도마음속에배울엄두가안나는지고한주

제로서,자바코드를다른플랫폼과통할수있게하는거구나하고감을잡는정도가될것이

다.괜찮다.아주솔직히,파고들필요는없다.주어진프로그래밍환경을쓰기위해밑바닥

부터죄다꿰고있어야만한다면,글쎄,뭔가잘못된것이다.

JAX-WS와JAXB표준은웹서비스삽질의그런모든저수준의난맥상을원하지않는한알

필요없도록고안되었다.마크의책은JAX-WS와JAXB의얽혀있는실타래를푸는것을그가

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xixSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 x�iii SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xixSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 x�iii

풀어본경험을바탕으로도와줄것이다.그는메시지에이르기위해메스꺼움을이겨내야만

했고,이제그는뒤돌아서험난한여정을거칠독자를안내하려한다.

종국에는이모든것이‘싹엮기’이야기가되기때문이리라.

-테트 뉴워드Ted Neward, 자바, .NET, XML 서비스 컨설팅, 교육, 강연, 저술 www.tedneward.com

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xx SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xx

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xx SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xx

2006년,자바는서비스지향아키텍처ServiceOrientedArchitecture,SOA를위한강력한플랫폼

으로탈바꿈했다.2006년5월발표된JavaEEEnterpriseEdition5는애플리케이션서버상의웹

서비스역량을심대하게향상했다.그리고JavaSEStandardEdition6이2006년12월에공개되

어자바프로그래밍언어의표준판에그러한기능의대부분을포용했다.

강건한웹서비스기술은SOA구현의근간이기때문에,이제이시대의엔터프라이즈시스

템이자바애플리케이션을SOA하부구조infrastructure로통합하는데필요한도구를자바가제

공하게된셈이다.

물론,자바에는한동안기초적인웹서비스기능이있었다.JAX-RPC1.0은2002년6월에

나왔다.2003년11월최종규격이나온J2EE1.4에는JAX-RPC1.1이있었다.그렇다면최신

버전의자바웹서비스JavaWebServices,JWSAPI는뭐가그토록달라진걸까?

답은강력함과편의성이다.프로그래머는J2EE1.4때보다JavaEE5에서엔터프라이즈

급애플리케이션개발이훨씬쉬워졌음을발견할것이다.그증거가9장과10장에있는데,

거기서내가개발한이베이,야후쇼핑,아마존을아우르는온라인쇼핑통합애플리케이션

을선보인다.SOAShopper라고불리는이애플리케이션은순수JavaEE5애플리케이션으

로,여러쇼핑사이트의REST와SOAP서비스를호출한다.SOAShopper는또한자체적으로

도SOAP과REST엔드포인트를제공하여크로스플랫폼검색과Ajax프론트엔드를제공한다.

SOAShopper는J2EE1.4와JAX-RPC로개발할때에는장난이아니었다.새로운자바웹서비

스표준으로는,짜는것이즐거움그자체였다.

이책은새로운자바웹서비스를구성하는다음과같은표준들에초점을맞춘다.

JAX-WS2.0[JSR224]-JavaAPIforXML-BasedWebServices.JAX-RPC의후

계자로서,자바로웹서비스를만들고쓸수있게해준다.

▒

저 자 서 문

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxiiiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxii SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxiiiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxii

JAXB2.0[JSR222]-JavaArchitectureforXMLBinding.JAX-WS와긴밀히연

계되어,자바오브젝트가XML로어떻게표현되는가를제어한다.

WS-Metadata[JSR181]-WebServicesMetadatafortheJavaPlatform.WS-

Metadata는자바웹서비스의유연한정의와배포를돕는어노테이션annotation

을제공한다.

WSEE1.2[JSR109]-WebServicesforJavaEE.WSEE는JavaEE컨테이너에

서의웹서비스의프로그래밍모델과런타임동작을정의한다.

이러한표준은몇가지큼직한발전과더불어많은자잘한향상을통해확실히더욱강력한

웹서비스프로그래밍플랫폼으로올라섰다.예를들어새로운어노테이션은웹서비스애플

리케이션작성을더쉽게해준다.그리고JAX-WS2.0[JSR244]에서자바/XML바인딩을JAXB

2.0[JSR222]로위임한것은JAX-RPC에비해크게JAX-WS의사용성을증대했다.배포모델

또한WS-Metadata[JSR181]로매우간단해지고나아진WSEE1.2[JSR109]버전이다.

1장과2장은이런JWS표준을자세히살펴보고어떻게이전의JWS표준을향상시켰는지

설명한다.3장부터10장까지는코드작성에주력한다.새자바웹서비스의강력함과편리함

을진정이해하기위해서는,코드를짜볼필요가있다.그리고그것이이책의주안점이다.3

장부터10장까지는강력한기능을최대한이용하며함정에빠지지않고일부한계를극복하

는방법을보여주는예제코드로꽉차있다.

11장은향후전망을바라보며웹서비스개발에있어WSDL중심적인접근법에대한몇가

지아이디어를프로토타입과함께선사하여SOA플랫폼으로서JWS가향후발전할가능성을

모색해본다.

나는이책을JAX-RPC가처음업계에등장한2002년에쓰기시작했다.프로그래머를위한

책을쓰려했고,좋은예제코드를JAX-RPC로짜는데애를많이먹으면서곧난관에봉착했다.

4년이지난후,글래스피시JavaEE5애플리케이션서버의시험판을만지작거리기시작하면

서,세상이많이변했음을직감했다.자바로웹서비스프로그램을짜는것이즐거워졌고다

시이책의마무리에파고들수있었다.

그결과로자바프로그래밍언어안으로부터SOAP,WSDL,그리고REST를다루는방법을

보여주는많은코드로채워진책이나왔다.이코드와부속설명은자바웹서비스를완전히

익히고SOA를위한강력한플랫폼으로자바를쓰는데도움을주기를바라마지않는다.

▒

▒

▒

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxiiiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxii SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxiiiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxii

SOA를위한자바웹서비스로의편견없는안내

이책의주된목적은SOA를위해자바웹서비스JWS를쓰는데에있어균형잡힌안내를제

공하는것이다.물론,어떤저자도편견을가지고있으며,나또한JWS표준이상당히훌륭하

다는믿음을실토하지않을수없다.그렇지않다면,이런책을썼을리없지않은가.

편견을실토하고나니,JWS는특히‘WSDL과자바로부터시작’으로알려진개발방식의취약

함도솔직히인정하려한다.이책에서다른많은방식으로설명되겠지만,JWS표준은웹서비

스를위한자바중심적인방식을제안한다.이미구축된SOA표준과협업하고기존의XML스키

마문서와WSDL에자바애플리케이션을맞춰야할때그방식이발목을잡을수도있다.

그런상황에서,웹서비스개발을위한WSDL중심적인방식을취할수있는것이해법이

될수있다.WSDL중심적인영역에서는JWS가덜강력하다.이책을통해,그단점을지적하

고극복할전략을소개하려한다.심지어11장에서는SOA-J라는이름의프로토타입프레임워

크를통해자바웹서비스에WSDL중심적인방식의대안을제시한다.

자바개발자와설계자architect를위한저작

이책은코드에관심이있는사람을위한것이고,따라서주로시스템을작성하는개발자와

시스템을설계하는설계자를대상으로한다.내려받아설치하고실행할수있는다량의코드

예제가있다.

웹서비스를다루는자바프로그래머를위한책이되기위해,이책에담긴설명과예제는

독자가자바에대한실제적인지식과더불어XML및XML스키마에대한기본적인이해를갖

고있음을가정하고있다.이책을시작하기위해SOAP과WSDL을많이알고있을필요는없

다.하지만책을읽어감에따라,웹서비스기초에대해탄탄한개념을잡고싶을때WSDL과

XML스키마에대한입문서를훑어볼필요가있을수있다.이책을통해,복습을할수있는

참고자료를제공할것이다.

이 책 에 대 해

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xx�SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxi� SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xx�SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxi�

J2SE5.0의숙지가바탕

이책은독자가J2SE5.0,특히제네릭스generics와어노테이션과같은자바언어확장을기

본적으로이해하고있음을가정하고있다.만약그렇지않다면,http://java.sun.com에있는

무료문서와입문서를통해필요한것을다배울수있다.

이런주제에대해겁먹을필요는없다.제네릭스와어노테이션은숙달하기어렵지않으며,

JavaEE5와SE6로웹서비스를할때알아야만한다.이책의일부지면을할애하여제네릭

스와어노테이션에대한안내를쓰지않은이유는웹에이미좋은무료정보가널렸기때문이

다.내가이책에서목표로삼은것은온라인입문서나문서로무료제공되는것이상을제공

하는것이다.

어째서글래스피시인가?

이책의모든예제코드는글래스피시 [GLASSFISH]오픈소스 Java EE 5참조구현체

referenceimplementation를써서개발과테스트를했다.집필할당시,글래스피시는사용가능한

구현체로유일했다.인쇄가들어갈무렵에는구현체가더많아졌고,예제는수정없이모든플

랫폼에서동작해야한다.바꿀곳이있다면글래스피시에특화된도구(예를들어WSDL에서

자바로컴파일하는wsimport나asadmin배포도구)가쓰이는빌드과정정도이다.

JBoss,BEA,IBM등의벤더가JWS표준을지원함에따라예제코드를실행할수있는안

내를제공할예정이다.이책의공식사이트http://soabook.com에서최신소식을확인하기

바란다.

글래스피시를써본적이없다면,https://glassfish.dev.java.net을통해한번써보기를권

한다.글래스피시는JavaEE의첨단을걷고있으며커뮤니티도대단하다.특히,메일링리스

트를통해받은기술지원이좋았다.질문을올렸더니JSR명세리더가몇분내에답해주는

것은흔한일이아니다!

이책에서다루지않는주제들

SOA와웹서비스둘다광범위한주제이다.논의를자바기술로한정해도,한책에전부다

루는것은불가능하다.이런현실에직면하다보니,자바개발자와설계자에게중요한핵심

사안이라고여겨지는것에집중하기로했다.느슨하게결합되는SOA애플리케이션으로분해

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xx�SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxi� SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xx�SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxi�

할수있는식으로웹서비스를만들고,배포하고,호출하는일이핵심사안과관련되어있다.

책의초점을맞추기위해,일부독자를실망시키게되는것을피할수없는데몇몇흥미로

울수있는주제를다루지않았기때문이다.이책의검토자들이지적해준그런주제들을내

가왜다루지않았는지그이유와함께여기나열해보았다.

SOA설계방침

SOA의이면에있는개념과설계철학을이책은다루지않는다.이책은자바웹서비스로

SOA컴포넌트를짜는법을자바개발자에게가르쳐주는방법서이다.SOA개념과설계에대

한완전한입문서로,토마스얼ThomasErl의Service-OrientedArchitecture[Erl]을추천한다.

UDDI

UDDI는매우중요하다.그리고JavaEE5는UDDI저장소에대해JAXR표준인터페이스

를제공한다.그러나JAXR은J2EE1.4이래로바뀌지않았다.게다가다른많은책과온라인

입문서에서잘다루어져있다.그래서,이책을감당할수있는크기로유지하게위해,과감히

생략했다.

엔터프라이즈메시징EnterpriseMessaging

엔터프라이즈메시징에대한장을넣었으면하는마음은있었다.어찌되었건SOA의기본

토대이기때문이다.하지만,이책의범위를JWS가제공하는기능으로한정했다.JWS는WS-

ReliableMessaging[WS-RM]이나어떤다른SOAP/WSDL지향적인신뢰적메시징방법을지

원하지않는다.물론,JavaEE5에는JavaMessageServiceAPIJMS가들어있다.그리고JMS

는SOA애플리케이션을구현하는데에유용한도구이다.그러니그자체로서JMS는웹서비

스도구가아니다.그래서초점을흐리지않기위해역시뺐다.

WS-Addressing, WS-Security,그리고다른많은WS-*표준들

웹서비스기반을위해고안된수많은표준을설명하려면수천페이지가들것이다.WS-*

표준은JWS에속하지않기때문에,따라서다루지않았다.거기에,내생각에는대부분의자

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xx�iiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xx�i SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xx�iiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xx�i

바개발자는여전히HTTP상의SOAP을떼고있는중이다.프로그래머를위한WS-*안내서

의시장은아마수년뒤의일일것이다.

글꼴과특수문자

Courier글꼴은자바타입,XML스키마컴포넌트,그리고본문중의모든예제코드를표시

하는데쓰인다.예를들어

java.lang.String-자바클래스(완전수식)

MyPurchaseOrder-자바클래스

xs:string-XML스키마타입

po:billTo-XML스키마전역요소

Courier글꼴은또한소프트웨어환경에특화된항목(즉경로,디렉토리,환경변수등)과컴

퓨터와의문자입출력을강조하는데에쓰인다.예를들어

JAVA_HOME-환경변수

$JAVA_HOME/bin-디렉토리

mvn install-콘솔에입력할명령

<>은환경에특화된디렉토리위치를가리킨다.예를들어

<AppServer>-JavaEE5애플리케이션서버가설치된곳의위치

<book-code>-책의예제가설치된곳의위치

본문중의부분코드

본문에는논의를전개하기위해많은부분코드가있다.각부분코드의밑에는그코드

가어디에있는지를나타내는파일경로가있다.그래서예를들어아래부분코드는<book-

code>/chap03/eisrecords/src/xml/order.xml에서왔다는식이다.더욱이,왼쪽의줄

번호는그코드가파일의어느부분인지를보여준다.

4 <Order xmlns="http://www.example.com/oms"

5 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

6 xsi:schemaLocation="http://www.example.com/oms

7 http://soabook.com/example/oms/orders.xsd">

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xx�iiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xx�i SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xx�iiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xx�i

8 <OrderKey>ENT1234567</OrderKey>

9 <OrderHeader>

10 <SALES_ORG>NE</SALES_ORG>

11 <PURCH_DATE>2005-12-09</PURCH_DATE>

12 <CUST_NO>ENT0072123</CUST_NO>

13 <PYMT_METH>PO</PYMT_METH>

14 <PURCH_ORD_NO>PO-72123-0007</PURCH_ORD_NO>

15 <WAR_DEL_DATE>2005-12-16</WAR_DEL_DATE>

16 </OrderHeader>

17 <OrderItems>

18 <item>

19 <ITM_NUMBER>012345</ITM_NUMBER>

20 <STORAGE_LOC>NE02</STORAGE_LOC>

21 <TARGET_QTY>50</TARGET_QTY>

22 <TARGET_UOM>CNT</TARGET_UOM>

23 <PRICE_PER_UOM>7.95</PRICE_PER_UOM>

24 <SHORT_TEXT>7 mm Teflon Gasket</SHORT_TEXT>

25 </item>

26 <item>

27 <ITM_NUMBER>543210</ITM_NUMBER>

28 <TARGET_QTY>5</TARGET_QTY>

29 <TARGET_UOM>KG</TARGET_UOM>

30 <PRICE_PER_UOM>12.58</PRICE_PER_UOM>

31 <SHORT_TEXT>Lithium grease with PTFE/Teflon</SHORT_TEXT>

32 </item>

33 </OrderItems>

34 <OrderText>This order is a rush.</OrderText>

35 </Order>

book-code/chap03/eisrecords/src/xml/order.xml

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxixSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xx�iii SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxixSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xx�iii

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxixSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xx�iii SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxixSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xx�iii

많은유능한분들의도움과지원이아니었다면이책의저술을마칠수없었을것이다.특

히,글래스피시프로젝트커뮤니티의모든분께이책을통해드러나는값진통찰력을제

공해준데에감사드리며,StephenDiMilla, JeromeDochez, JosephFialli,MikeGrogan,

DougKohlert,KohsukeKawaguchi,JitendraKotamraju,BhaktiMehta,CarlaMott,Dhiru

Pandey,VivekPandey,DineshPatil,EduardoPelegri-Llopart,VijayRamachandran,그리고

KathyWalsh에각별한정을표하고싶다.그중썬마이크로시스템스의VijayRamachandran

과DougKohlert에는WS-Metadata,WSEE,그리고JAX-WS관련부분을검토해준데에더욱

감사드린다.

웹서비스를이용한프로세스와데이터통합에대한연구를수행했던MIT에서교환교수로

StuartMadnick교수로부터초청을받았던시절이프로젝트(이책의집필)을처음구상했다.

그를비롯한그의연구팀과의협업은자바웹서비스에대한내관심에불을당겼고,마침이

이책으로결실을본셈이다.

BruceScharlau,ArtSedighi,그리고MattAnderson은초고를검토해주며많은유익한조

언을해주어이책으로승화했다.

11장에설명된SOA-J프로젝트에값진기여를해주었던인도뱅갈로에있는내친구

들인KishoreGopalakrishna와그의팀원인RohitAgarwal,Vinit Sharma,그리고Rohit

Choudhary에게도감사를표하고싶다.

TedNeward는통찰력넘치는비평을해주었으며고맙게도추천문을써주었다.이책을통

해그와함께한것은대단한영광이다.

이책은PrenticeHall출판사의편집자GregDoench로부터인고의지도가없었다면결코

나올수없었다.그의지혜와경험은값으로따질수없다.또한이책을출판의길로인도해

준MichelleHousley,JulieNahil,DmitriKorzh,그밖의모든모든출판사스태프들에게감

사드리고싶다.

감 사 의 글

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxxiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxx SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxxiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxx

집으로돌아와,내아이들,Elizabeth,Eric,그리고Emily는책을쓰는동안잦은포옹과장

난기어린방해로나에게힘을주었다.마지막으로가장중요한,나의아내Lorraine의사랑과

격려가이책을가능하게했다.아내의인내와이해가없었더라면,이작업은결코마칠수없

었다.

SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxxiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxx SOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxxiSOA: 자바 웹 서비스로 통하는 서비스 지향 아키텍처 xxx

마크D.한센MarkD.Hansen박사는소프트웨어개발자이자컨설턴트이며기업가이다.그의

회사인JavectorSoftware는웹서비스에특화된컨설팅과소프트웨어애플리케이션개발을

제공한다.마크는또한글래스피시프로젝트의컨텐츠개발자이며WSDL중심적인웹서비스

개발을위한SOA-J오픈소스애플리케이션프레임워크를개발해오고있다.

이전에,마크는웹서비스기술을통한프로세스와데이터통합을위한MIT연구애플리케

이션팀의방문교수였다.그전에는eBusiness컨설팅서비스의손꼽히는제공사중하나인

Xpedir,Inc.의책임부사장을역임했다.

마크는포츈 500대기업을대상으로맞춤인터넷솔루션을개발을위해 1993년

Kinderhook을창립했다.KinderhookSystems의설립전에는,기업형데이터웨어하우스에

서의데이터정합성관리용도구를제공하는매사추세츠주캠브리지에근거한소프트웨어회

사인QDBSolutions,Inc.의창업자이자부사장으로일했다.QDBSolutions는1997년Prizm

Technologies에합병되었다.

마크의저술은Wall Street Journal, InformationWeek,ComputerWorld,Database

Management,DatabaseProgrammingandDesign,BusinessCommunicationsReview,EAI

Journal,그리고IntelligenceEnterprise와같은간행물에실렸다.

마크는코넬대학에서수학학사학위를,시카고대학에서수학석사학위를,MIT경영대학

원에서석사학위를,MIT컴퓨터과학연구소에서박사학위를취득했다.

마크와그의아내로렌은뉴욕근거에3명의자녀엘리자베스,에릭그리고에밀리와함께

거주하고있다

저 자 에 대 해

1

01장.자바웹서비스와함께하는서비스-지향아키텍처

요즈음의엔터프라이즈자바애플리케이션들은너나할것없이모두서비스-지향아키텍처

Service-OrientedArchitecture,SOA를지원해야하는요구에맞닥뜨리게된다.대부분의SOA애

플리케이션의근본은웹서비스다.그렇기때문에,엔터프라이즈자바개발자라면JavaEE5

와JavaSE6에포함된웹서비스표준들에능숙해지고싶은욕구를가지고있으리라생각

된다.이표준에는JAX-WS(이전에는JAX-RPC였던)[JSR224], JAXB[JSR222],WebServices

MetatdataWS-Metadata [JSR181],SOAPwithAttachmentAPI for Java(SAAJ) [JSR67],그리고

WebServicesforJavaEEWSEE 1)[JSR109]등이포함된다.이제부터이표준들을한데묶어

자바웹서비스JavaWebService,JWS라부르도록하겠다.

SOA애플리케이션은느슨하게결합된looselycoupled웹서비스들로구성된다.우리가엔터

프라이즈자바개발자이니만큼SOA애플리케이션을개발하는데JWS도구들을사용하고자

한다.더구나,주요엔터프라이즈자바벤더들이SOA애플리케이션을위한개발플랫폼으로

써JWS기술들을지지하고있는상황이기도하다.

그래서JWS표준이매우중요한것이다.이표준들은엔터프라이즈자바환경에서SOA개

발을하는데기초가된다.느슨하게결합된SOA애플리케이션을통해비즈니스프로세스는

보다유연하게만들어진다.이결과로,기업은급속히변화하는세계시장에보다잘적응할

수있게되므로,결국이모든것은기업차원의경쟁력제고에있어서도매우중요한역할을

차지하게된다.

하지만불행히도,내경우와비슷한전철을밟게된다면자바웹서비스의학습곡선이다소

가파르다는사실을금새알게될것이다.단순히,자바클래스를웹서비스로배포하거나그

러한서비스들을소비할수있는간단한클라이언트를생성하는데에도많은종류의강력하

고복잡한기술들이요구된다.물론,JavaEE튜토리얼에간단한“HelloWorld”애플리케이션

이나와있긴하다.

�) EE컨테이너에대한배포표준인WSEE는JavaSE가아닌,JavaEE에서만지원된다.

자바 웹 서비스와 함께하는 서비스-지향 아키텍처2

그러나구매주문시스템같은것을배포해야할필요가있다면일은좀더복잡해진다.

WSDL에서부터시작하는경우라면,실제구매시스템에수동으로패키징되고매핑되어야하

는온갖종류의기괴한클래스들이컴파일될것이며,자바클래스들에서부터시작하는경우

에도WSDL은여러분이원하는방식대로생성되지않을것이다.만약여러분이이런종류의

문제들로당황해본적이있다면,나는그심정을충분히이해한다말할수있다.나또한그래

왔고,그것이내가이책을쓰게된직접적인동기가되었기때문이다.

1.1 내가 멍청한 걸까? 아니면 자바 웹 서비스가 진짜 어려운 걸까?

처음엔,그저내가멍청하다고생각했다.자바웹서비스에관계된일을하기전까지나는컨

설팅업체를경영하고있었다.지난수년동안관리자로서일해왔기때문에,기술자로서의두

뇌는좀굳어져있는상태였다.‘계속그일을해!’나는거듭해서내자신에게말했다.‘그러면

결국이기술에통달할수있을거야.’그게대략3년전쯤의일이었고,나는JWS어노테이션과,

배포기술자deploymentdescriptors,WSDL프록시proxy,스키마컴파일러schemacompiler같은것

들과씨름해왔으며,그러는가운데배운경험들을바탕으로이책을펴내기에이르렀다.

지난3년간,나는자바제네릭스Generics,리플렉션Reflection,영속성persistence,병행성

concurrency과같은주제들을습득했다.아파치Axis소스코드를공부했으며,몇개의패치를

제출하기도했다.그리고선이내,내자신이그리멍청하지는않다는사실을깨달을수있었다.

여태껏JWS표준들에대한직관적인이해를향상시키려했던노력들은,내게는긴투쟁의연

속이나마찬가지였다.그리고이런경험을한사람이비단나하나만이아니었다.

저명한학자인리처드몬슨-헤펠RichardMonson-Haefel은2003년말에자바웹서비스표준의

J2EE1.4버전에기초한,960쪽짜리책을출간했다.무려960쪽!이사실하나만으로도,우리는

JWS와관계된학습곡선에대한의미심장한결과를파악할수있다.어떤특정주제가매우어

려운것이아니고,JAX-WSAPI자체가무엇을하는지파악하는것도그다지어렵지않다.그러

나진정어려운부분은이모든API들이기반웹서비스표준(예를들어XML,WSDL,SOAP같

은),HTTP프로토콜그리고다른JavaEE컨테이너서비스(예를들면,의존성주입Dependency

Injection)와어떻게연관되는지를이해하는일일것이다.기반이되는WSDL,SOAP,XML그리

고HTTP등이자바표준가운데서어떻게녹아들었는지연결지어보려하면할수록JWS표준

을사용해서작업한다는사실자체가어색하고부자연스럽게느껴지기마련이다.

지난2년동안,학자들은－몬슨헤펠도그들중하나였다－자바웹서비스표준을맹렬히

비난했다.그들의관점은,구버전의JWS인J2EE1.4버전상에서작업했던그들의경험들에서

비롯된것이다.나또한그런예전버전의API로는유용한SOA-스타일의개발이힘들다는데

3자바 웹 서비스와 함께하는 서비스-지향 아키텍처

동의한다.하지만,특별히JavaEE5와JavaSE6에내장된최신버전을놓고볼때,나는표준

자체가문제라는사실에대해서는동의하기어렵다.대신에자바웹서비스개발을위한범용

적인프레임워크를생성하는문제자체가원래복잡한것이원인이아닌가의심해보고싶다.

리처드몬슨-헤펠은2006년4월22일에아래와같은이메일내용을그의블로그에포스팅

한바있다.이글은우리가운데얼마나많은사람들이자바웹서비스에많은시간을소모하

고있는지를단적으로잘나타내는비유라할수있다.

이책의명제중하나는,간단히말해웹서비스가근본적으로어렵다는것이다.우리는이

사실을인정하고넘어가야한다.웹서비스는분산컴퓨팅에기반하기때문에어려운것이고,

분산컴퓨팅은컴퓨터과학에있어서도가장어려운문제이기때문이다.

그래서이책은JWS표준을사용하면SOA스타일의애플리케이션을쉽게만들수있다는

따위의과장광고는하지않는다.대신에,이책은JWS를살펴보고이컴포넌트기술들의장점

과단점들을이해할수있도록도와준다.그과정에서어떻게JWS가웹서비스를효율적으로

배포deploy하고소비consume할수있는강력한SOA-스타일의애플리케이션을만드는데사용

될수있는지에대해,내가여태껏배워온것들을여러분과공유할것이다.이여행의대미는

9장과10장에서다루게되는이베이,아마존,그리고야후!쇼핑과통합된쇼핑엔진을구현한

SOAShoper예제애플리케이션을구축하는대목에있다.SOAShopper는REST와SOAP엔드

포인트둘모두를발행publish하고,REST와SOAP엔드포인트를소비하며,Ajax프론트엔드

를제공한다.

데이브 포드너의 웹 서비스를 대하는 다섯 가지 단계

부정－단순한객체접근프로토콜SimpleObjectAccessProtocol,SOAP이군.그렇지?

난처함－좋아,SOAP,WSDL,WS-IBP,JAX-RPC,SAAJ, JAX-P등의표준에

대해읽어봐야겠어.그다음에위키를확인하고,마지막으로서비스와클라

이언트측을다룬예제들을따라해봐야지.

분노－이것들이왜그리어렵게만들어졌는지도무지알수가없어!

죄책감－모두들웹서비스를잘사용하고있는데,분명내탓일거야.내가뭔

가실수하고있는게틀림없어

납득－웹서비스는단순하지도,쉽지도않은것이군.

1.

2.

3.

4.

5.


1.1.1 기술에 쉽게 현혹되지 말라

2001년초반Ariba, IBM그리고마이크로소프트가W3C노트W3CNote로서WSDL1.1을발

표했을때만해도,웹서비스는분산컴퓨팅을보다쉽게만들어줄수있는방법으로써계획

되었다.개발자들은더이상크로스플랫폼CrossPlatform분산애플리케이션을생성하기위해

CORBA표준같은것을이해할필요가없을것으로보였다.더나아가,웹서비스는분산컴

퓨팅을인터넷상에존재하는모든대상에적용할수있는기술로써기대를받았다.

나처럼대부분의자바개발자들은,이러한초기의웹서비스비전들을신봉했다.1990년대

에우리가인터넷을통해경험한것에따르면그비전들은충분히납득이가는것이었기때문

이다.일찍이HTTP상에서동작하는HTML이대중을위한분산컴퓨팅플랫폼인월드와이드

웹의놀라운성장에원동력이되었던바있다.HTTP상의XML을위한표준들도이와마찬가

지로웹서비스－비즈니스애플리케이션을위한분산컴퓨팅플랫폼－성장의원동력이되어

줄것으로믿었다.

결국,우리는모두그환상에매혹되고말았다.웹서비스가분산컴퓨팅을보다쉽게만들

어줄것이라믿었던것이다.

엔터프라이즈자바업계의리더들은웹서비스의비전을구현하는일에착수했다.이비전

을실현하는과정에서,자바업계는그들이끔찍한표준들을몇개만들어냈다는사실을발견

했다.초기의JAX-RPC,JAXB나다른표준들을읽어본사람들은－나를포함해서－점차불안

해졌다.무언가가잘못돌아가고있다는걸느낄수있었다.이표준을주도하고있는전문가

그룹이뭔가궤도를이탈했다고추측했다.웹서비스가약속했던것들이사라지는것에대해

점차씁쓸함과환멸마저느끼게되었다.우리들사이에서도SOAP과REST에대한논쟁이시

작되었고,이런자바웹서비스표준의복잡성이누구의탓인지를두고설왕설래가계속되었다.

하지만,비단복잡성때문에SOAP대신REST를선택하는결과가벌어지는것은아니다.그

렇다고,전문가그룹이기술을과용overengineering한탓도아니다.전문가그룹은정석을따

랐을뿐이고,웹서비스의비전을실현하려고노력했을뿐이다.결국그들은분산컴퓨팅이

진정어려운문제라는사실을재발견해낸셈이되었다.SOAP,WSDL,XML,그리고심지어

REST조차도결코분산컴퓨팅을쉽게만들어주진못했다.

물론,JWS표준에는결함이있었다.하지만그건이미예견된결과였을뿐이다－새로운기

술은종종,다루기힘든(EJB를보라)급격한변화와특이점을동반하기마련이다.이문제들

은다음버전의 2)개선점을통해수정되기마련이다.

2) EJB3.0은비난세력들이요구해왔던진보된기능들,가령관점지향프로그래밍(AspectOrientedProgramming)과제어역전

(InversionOfControl)과같은것들을구현하면서계속해서발전을거듭하고있다.


JWS명세Specification가얼마나개선되었는지를보여주는일례로JAX-WS2.0을들수있다.

6장과7장에서이명세를자세히다루고있기때문에,지금은이것이JAX-RPC1.1에비해어

떻게큰개선을가져왔는지에대해맛보기정도로만살펴보기로하자.첫번째,JAX-RPC데

이터바인딩DataBinding은삭제되었고,명세는REST엔드포인트를지원하는것과동시에,

WSDL과자바간의매핑에초점을맞추는방향으로좀더단순화되었다.자바데이터바인딩

은JAX-RPC에있던XML스키마로부터더개선되고널리쓰일수있는JAXB2.0으로대체되

었다.두번째,JAX-WS는어노테이션을통해자바인터페이스로부터생성되는WSDL의형태

를제어할수있게해준다.이런어노테이션의사용을통해JAX-RPC서비스를배포할때필

요하던배포기술자를좀더적게사용할수있다.세번째로,JAX-WS는프로그래머가XML

에직접작업할수있는인터페이스(클라이언트측은Dispatch,서버측은Provider)를제

공한다－사용하고싶지않을때는효율적으로JAXB데이터바인딩자체를생략할수도있다.

확실히,JAX-WS2.0에는아직더개선의여지가남아있다.내가생각할수있는가장큰

개선점은개발자가WSDL과관련된스키마에명시된,네이티브XML타입을직접다룰수있

도록하는다른바인딩방법(JAXB외에추가적으로)을제공하는것이다.XJ[XJ]같은자바의

XML확장들이그런역할을할수있다.개발자들이JAX-WS로작업하면서경험하는복잡성

과혼란의대부분은,JAX-WSWSDL컴파일러가만드는클래스들,즉JAX-WS/JAXB에의해

생성되는클래스들을WSDL에명시된XML메시지에매핑하는방법을결정하는어려움에기

인한다.그러나이주제는앞으로도많은난관을헤쳐나가길기다려야하는별도의연구영역

(네이티브XML타입으로직접프로그래밍하는일을단순화시켜줄수있는언어를만드는것)

이다.즉,내가여기서말하고자하는바는JAX-WS가이상적이라는얘기가아니라,EJB3.0

이EJB2.1에비해개선된것처럼단순히JAX-RPC에비해서개선된기술이라는것이다.

요약해보자면,WSDL명세가나온이후엔터프라이즈자바커뮤니티는웹서비스기술에

기반한분산컴퓨팅을위한자바중심의플랫폼을처음부터만들기시작했다.이는분명방대

한작업이었고동시에명세가이해하기어렵다는사람들의동요또한잠재워야하는작업이

었다.이런관점에서보면JWS표준들은그리엉망은아닌셈이다.사실,자바가SOA개발플

랫폼이되려면아직많은일들이남아있다.이표준들은그과정에서우리가웹서비스개발

의복잡성과씨름하는데필요한API들을제공한다

그러면왜우리가이런환멸을느끼는걸까?환멸에빠진만큼,거기서우리가배워야만하

는교훈은무엇일까?나는그것이이업계에서우리가몇번이고반복해서배우게되는것－‘결

코기술에쉽게매혹되지말라!’는교훈의일종이라고생각한다.만약웹서비스가분산컴퓨

팅의만병통치약이될것이라고가정하지않았다면,우리는이런혼란에빠지지않았을것이

다.대신에,우리는좀더낙관적인입장을취할수있었을것이다.


1.1.2 JWS는 도구 모음이지 애플리케이션이 아니다

웹서비스가본질적으로어렵다는것을깨달은뒤로,나는JWS명세들에대해가지고있던전

제들을하나둘씩다시검토해보기로했다.나는더이상이명세들이대폭단순화되리라고

는믿지않았다.그런복잡성이,그기반에있는분산컴퓨팅이란문제에서비롯된본질적인

것이라고받아들이게된것이다.

JWS를SOA스타일개발의애플리케이션프레임워크로서바라보는대신,웹서비스－SOA

기반의분산컴퓨팅환경의컴포넌트들－를소비하고배포하는하나의도구모음ToolSet으로

인식하기로했다.문제는내가멍청해서가아니라도구에게너무많은것을기대했기때문이

다.JWS기술로SOA애플리케이션을생성하는데는몇가지규칙과설계에대한이해가필요

하다.이책의전반에걸쳐JWS애플리케이션개발을좀더쉽게만들수있는좋은설계들에

대한예제가여럿제시될것이다.

예를들어,4장에서는‘관심사의분리separationofconcerns’를촉진하는매개로써중앙집중

식의스키마라이브러리의사용에대해설명하고있다.그런라이브러리는타입정의과정

(웹서비스로SOA애플리케이션을생성하는데꼭필요한부분)을인터페이스정의과정(예:

개별SOA컴포넌트들의WSDL표현생성)으로부터분리하게된다.다른예로,5장에서는

SOA시스템에타입매핑시스템을도입해서,JWS가생성한클래스들을애플리케이션의다

른부분들로부터분리시키는방법을보여주고있다.이러한기법은이후에소개되는9장의

SOAShopper구현에서도사용된다.

좋은설계와함께,보다쉬운프로그래밍을이끌어낼수있는방법중의하나는애플리케

이션프레임워크를사용하는것이다.이를테면,아파치스트럿츠프레임워크는모델2또는

모델뷰컨트롤러MVC프레임워크에기반한웹애플리케이션개발을도와준다.프레임워크는

복잡한도구모음들의상위에서추상화계층을제공한다.추상화계층은특정한방식으로프

로그래밍할수있도록도와주는역할을한다.프레임워크는프로그래밍시에취하는선택의

폭을검증된패턴들의부분집합으로제한함으로써작업을보다쉽고,보다덜혼란스럽게해

준다.

애플리케이션프레임워크는좋은설계를도와주는역할도하게된다.그결과로써,좋은

SOA프레임워크는XML스키마라이브러리의사용을장려하고,WSDL문서들간의스키마

재사용을촉진하도록해야만한다.좋은SOA프레임워크는반드시컴파일된스키마와WSDL

을다른애플리케이션클래스들로부터분리시켜야만한다.

애플리케이션프레임워크는도구모음을이용하지만사실,도구모음이상의것을지향한다.

프레임워크는도구모음을사용하는데있어서특정한방법을권장한다.예를들어스트럿츠


는여러다른도구모음중에서서블릿Servlet과자바서버페이지JavaServerPages,JSP를사용한다.

이러한도구모음위에서,스트럿츠는MVC프레임워크에따라애플리케이션을만들기위한

클래스들의프레임워크(예:Action, ActionMapping)를제공한다.

스트럿츠와웹서비스간의공통점을생각해보면서,나는JWS가애플리케이션프레임워크

가아닌도구모음을제공하는것이라는사실을깨달았다.우리는SOA비즈니스애플리케이

션을개발하기위해서단순히기반이되는도구모음이아닌스트럿츠같은애플리케이션프

레임워크를간절히원했던것이다.SOA는특히WSDL중심적이기때문에,이상적으로WSDL

중심개발을할수있게해주는프레임워크를원하고있었다.

불행히도,이책을쓰기전까진자바웹서비스에서스트럿츠에비견될만한인기있는프레

임워크가나타나지않았다.나는그시발점으로WSDL중심개발을위한프레임워크인SOA-J

라는것을직접만들었다.특별히호기심많은독자들을위해귀띔해주자면SOA-J에대한소

개내용은11장에있다.

1.1.3 깨달음

JWS가애플리케이션이아니라도구모음이라는것을이해한것이야말로나의진정한깨달음

이라고할수있다.이런사실을모르고JWS로성공적인개발을하려했다면도구모음들이

어떻게동작하는지알기위해그리고친숙해지기위해수많은시간을소모했을것이라는사

실을그제서야깨달을수있었다.이책은내가얻은그런경험들을여러분에게전수하는책

이다.이책은다양한작업들을수행하는방법에대한수많은예제로가득차있다(예:REST

엔드포인트를발행하고,JAXB바인딩을Castor와같은다른것들로대체하거나,WSDL없이

웹서비스를소비하는등의).여러분이많은코드예제가있는쪽을좋아한다면결코실망하지

않을것이다.

코드를본격적으로파고들기전에,웹서비스의개발과배포를위해 3)모든플랫폼에일

반적으로들어가는여러가지컴포넌트들을살펴보고자한다.이를위해서몇가지공통적인

용어들을소개할필요가있다.우선그런플랫폼들을웹서비스플랫폼이라칭하기로하자.

다음절에서는웹서비스플랫폼들에대해알아보기위해내가웹서비스플랫폼아키텍처

WebServicesPlatformArchitecture,WSPA라고부르는,이책전반에걸쳐언급되는플랫폼이등장

한다.WSPA를우리가사용할레퍼런스아키텍처로간주해도좋다.자바웹서비스를다루는

과정에서WSPA를참조해가며그장점과단점을논할것이다.

3) 웹서비스배포를위한JavaEE5외의다른플랫폼으로Axis,SystinetServer그리고XFire를들수있다


1.2 웹 서비스 플랫폼 아키텍처

웹서비스플랫폼은특정프로그래밍언어를사용해서웹서비스를호출하고배포하는데쓰

이는도구들의집합이다.나는초점을자바에맞추고있긴하지만,이절에서다루는개념들

은여러언어에적용될수있다.

플랫폼은서버측컴포넌트와클라이언트측컴포넌트들을가지고있다.서버측컴포넌트

들은보통특정한컨테이너와함께패키징된다(예:JavaEE애플리케이션서버또는서블릿

엔진).클라이언트측컴포넌트들은보통웹서비스에바인딩되는자바인터페이스의인스턴

스에접근하는도구로써패키징된다.아파치Axis,XFire,SystinetServer,JWS또는그어떠

한플랫폼이든간에,다음의세가지핵심적인하부시스템을제공해야만한다:호출Invocation,

직렬화 4)그리고배포Deployment.이해를돕기위해이하부시스템들에대한기본적인사안

들을간추려살펴보면JWS가무엇을하도록설계되었는지이해하고,그동작을논하기위한

용어들을파악하는데분명도움이될것이다.

1.2.1 호출

서버와클라이언트측모두각각다른호출방식을가진다.서버측호출방식은다음과같은

것들을책임진다.

서버 측 호출

전송계층을통해SOAP메시지를수신한다(예:HTTP나JMS엔드포인트로부터).

메시지의전처리preprocess프로세스를담당할핸들러를호출한다(예:신뢰성을

위한메시지의저장이나,SOAP헤더header의처리같은).

타겟서비스의메시지를결정한다－달리말해,메시지가호출하고자하는

WSDL오퍼레이션operation이어떤것인지를결정한다.

타겟WSDL오퍼레이션을통해어떤자바클래스/메소드가호출될지를결정한

다.이것을자바타겟JavaTarget이라부르겠다.자바타겟을결정하는일을디스

패칭dispatching이라고부른다.

SOAP메시지를직렬화하부시스템Serializationsubsystem이처리하게하고자바

타겟에파라미터로전달할수있도록자바객체로역직렬화deserialize한다.

직렬화하부시스템에의해생성된파라미터를사용해자바타켓을호출하고,타

겟메소드에의해반환되는자바객체를획득한다.

4) 여기서는‘직렬화(Serialization)와역직렬화(Deserialization)’를통칭해서부르는줄임말로써‘직렬화’라는용어를사용했다.

1.

2.

3.

4.

5.

6.


반환된객체를직렬화하부시스템이처리하게하고,그로인해타겟WSDL오

퍼레이션에명시된반환메시지를따르는XML요소로직렬화하게한다.

반환된XML요소를타겟WSDL오퍼레이션을다루는SOAP메시지응답SOAP

MessageResponse으로포장한다.

메시지전달을위해SOAP응답을전송계층으로보낸다.

이프로세스의각단계에서,호출하부시스템은예외를반드시처리해야한다.예외가발생할때,

호출하부시스템은종종예외를SOAP오류메시지SOAPfaultMessage로패키징해서클라이언트에게

반환한다.실제호출프로세스는여기서설명한것보다좀더미묘하고복잡한것이사실이다.하

지만,여기에개괄적으로다룬단계들은,우리가자바웹서비스아키텍처를논하는데있어서좋

은출발점이되어줄것이다.이후장－특별히JAX-WS를연구해보는6장과7장,그리고SOA-J 5)

호출방식을설명하는11장등에서－에서이내용을좀더자세하게다룰것이다.

여기서본것처럼,호출프로세스invocationprocess는,결코단순하지않다.이복잡성의일

부는SOAP을지원하는데서비롯된것이다.대신3장에서는REST라고불리는좀더간단한

대안을살펴볼것이다.그러나REST를적용하더라도호출은여전히복잡하다.웹서비스의

XML기술description을자바타겟에매핑시키고,XML메시지로타겟을호출하는등의일반적

인문제와는달리,호출은결코풀기쉬운문제가아니다.

자바인터페이스를사용해서,웹서비스를호출하고싶다면,클라이언트측의호출프로세

스도서버측프로세스와유사하다.사실이방식이웹서비스－이방식은여러분이해결하고

자하는문제자체에많이의존하게된다－호출에항상가장적합한방식은아니다.여러분의

클라이언트가XML로작업을한다면,그냥XML로부터SOAP메시지를구성하고웹서비스에

전달하는편이더쉬울것이다.다른한편에서는,클라이언트가자바객체로작업한다면JWS

의방식처럼클라이언트측호출하부시스템이그역할을수행하게된다.

클라이언트 측 호출

서비스엔드포인트인터페이스serviceendpointinterfaceSEI라불리는자바인터페

이스를구현해서웹서비스엔드포인트의인스턴스를생성한다.호출하부시스

템은SEI인터페이스들을생성하기위한하나이상의팩토리를가지고있다.이

팩토리인스턴스들은직접생성할수도있고JNDI를사용해서접근할수도있다.

일반적으로SEI인터페이스는자바프록시와호출핸들러InvocationHandler를사

용해서구현된다.6장에서이매력적인주제를다뤄볼것이다.

SEI인터페이스의호출을처리한다.

5) 1.5절에서,SOA-J가JWS기반의애플리케이션프레임워크라고소개한바있다.

7.

8.

9.

1.

2.


SEI로전달되는파라미터들을받아서,직렬화하부시스템에전달하게된다.직

렬화하부시스템은파라미터로전달받은내용들을,타겟서비스의WSDL에명

시된XML스키마를따르는XML요소로직렬화한다

타겟서비스의WSDL에기반해서파라미터요소들을SOAP메시지로포장한다.

메시지를서비스의품질또는다른요구사항에기반해후-처리post-process(예:

신뢰성을위해,메시지를별도로저장하거나,SOAP헤더에설정한경우)하는

핸들러를호출한다.

타겟웹서비스로의전달을위해메시지를전송계층으로보낸다.

전송계층으로부터SOAP메시지응답을수신한다.

SOAP메시지를직렬화하부시스템으로보내SEI의반환타입에명시된클래스

의인스턴스인자바객체로역직렬화한다.

역직렬화된SOAP응답을반환해서,SEI호출을완료한다.

보다간단한설명을위해,여기서도예외처리프로세스에대한설명은생략하겠다.일반적

으로클라이언트측호출은서버측호출의역순으로이루어진다.서버측호출서비스시스

템의최전선에는WSDL에서정의된프록시SOAP오퍼레이션이담긴자바메소드가위치하

게된다.이시스템은자바메소드를호출해서WSDL오퍼레이션을실행한다.클라이언트측

의호출하부시스템의최전선에는WSDL에서정의한SOAP오퍼레이션이프록시자바인터

페이스와함께위치하게된다.이시스템은WSDL오퍼레이션을실행해서자바메소드호출

을처리한다.그림1.1에거울에비친듯이대칭적인이두동작이묘사되어있다.

여기서한가지흥미로운점은,그림1.1의중간부분에위치하는WSDL에의해명시된

SOAP요청,응답부분이다.양끝단의자바메소드호출은웹서비스의관점에서는임의적인

것이나다름없기때문이다.사실,서버측에서는클라이언트측과는완전히다른메소드시그

니처를가지게된다.대부분의경우에클라이언트와서버간의메소드시그니처는서로다른

편이고,사용되는프로그래밍언어도다를수있다.하지만만약양측이동일한자바클래스

라이브러리로작업하게된다면자바RMI를통한호출을수행할수도있다.

그림의1-1은클라이언트와서버측의호출이마치거울에비친것처럼유사하다는사실을묘사

한것뿐이라는점을명심해두어야한다.실제로는,이그림의어느한쪽은자바메소드호출을수

행하지않을수도있다.예를들어,웹서비스이기때문에SOAP/HTTP상에서CICS트랜잭션(주로

IBM메인프레임시스템등에서동작하는트랜잭션서버－옮긴이주)을호출하는자바클라이언트

를사용할수도있다.이런시나리오라면,클라이언트측에서만자바로된호출하부시스템을가

지게되고다른쪽에는SOAP을서버측의CICS로변환하게되는무엇인가를사용할수도있다.

3.

4.

5.

6.

7.

8.

9.


1.2.2 직렬화

직렬화Serialization는자바클래스의인스턴스를XML요소Element로변환하는과정을말한다.역

으로,XML요소를자바클래스의인스턴스로변환하는프로세스는역직렬화Deserialization라고

부른다.이책에서는직렬화와역직렬화모두를일컬어간단히‘직렬화’라고부르도록하겠다.

이론의여지는있지만,직렬화는모든자바웹서비스플랫폼에서가장중요한역할을수행

하는컴포넌트이다.그림1.2는직렬화가해결해주는문제들을보여주고있다.이그림을설

명하기위해서직렬화가WSDL,SOAP과어떤연관이있는지이시점에서좀더자세히다루

어보도록하겠다. 6)이런세부적인사항(아직1장이긴하지만!)을소개하는과정은WSPA의

직렬화하부시스템이정확히어떤일을하는지이해하기위해서도반드시필요하다.

웹서비스컨테이너안에는많은SOAP엔드포인트－각각은웹서비스들의그룹에대응하

게된다－들이상주해있다.엔드포인트는수행할수있는오퍼레이션들을정의하는역할을

하는,WSDL을하나씩가지고있다.

6) 이설명을이해하기위해,WSDL과SOAP을좀더들여다볼필요가있지않느냐는의문이든다면,그런걱정은일찌감치붙들

어매두어도좋다.4장에서좀더자세히다룰예정이니까.지금은단순히일반적인개념들을이해하는데만초점을맞추면된다.

그림 1.1 클라이언트 측 호출 하부시스템은 SEI 프록시상의 메소드 호출을 SOAP 요청/응답으로 변

환한다. 서버 측 호출 하부시스템은 SOAP 요청/응답을 자바 타겟의 메소드 호출로 변환한다.


그림1.2에서우측하단의설명선으로된상자는,그러한WSDL인터페이스의부분코드

를보여주고있다.이부분코드들을살펴보면서<types>요소에주목해보자.이요소는

WSDL문서의나머지부분에서정의되는웹서비스에의해사용되는XML스키마타입정의

를포함하고있다.이부분코드는customerPurchase라는이름의요소에대한정의를보

여주고있다.이요소의완전한qualifiedname이름은wrapper:customerPurchase다.요

소는onCustomerPurchase의메시지정의의한부분으로써사용된다.좀더살펴보면,

CustomerPurchase라는portType은입력으로사용되고있다.그리고이portType은입력

으로OnCustomerPurchase메시지를사용하는processCustomerPurchase란오퍼레이션

에의해정의되고있다.

그래서이부분코드는wrapper:customerPurchase요소의한인스턴스를포함하는입

력메시지가필요한processCustomerService라는웹서비스를정의한다.웹서비스를호

출하면그결과로wrapper:customerPurchase의인스턴스를포함하고있는SOAP메시지

의생성을요구한다.WSDL부분코드에있는wrapper:customerPurchase에대한정의가

imported:customer와imported:po의두요소를참조하고있는것에주목하자.이두요소

에대한스키마는보이지않지만,접두어prefix의이름(imported)으로부터충분히WSDL의

어느부분쯤에서불려와졌으리라는사실을추측할수있다.그래서SOAP메시지의생성에

는imported:customer와imported:po의인스턴스생성이필요하다.

자,이제그림1.2의좌측하단에위치한,설명선으로된상자에있는자바부분코드를살펴

보고,여기에서불려진com.soabook.sales.Customer와com.soabook.purchasing.

PurchaseOrder 클래스에주목하자.이클래스들은newPurchase 메소드의파라미

터클래스들로써사용되었다.그림1.2에보여진웹서비스프록시는WSDL의오퍼레이션인

processCustomerPurchase와자바인터페이스메소드인newPurchase를바인딩한다.이프

록시는호출하부시스템에의해생성된다.프록시는SOAP메시지송신을통해SOAP엔드포인트

에서배포되는WSDL오퍼레이션을호출하게된다.그래서웹서비스프록시의newPurchase

메소드구현은반드시com.soabook.sales.Customer와com.soabook.purchasing.

PurchaseOrder의인스턴스를취하는어떤장치를호출해야만하고,SOAP메시지의바디body

안에삽입될수있는wrapper:customerPurchase의인스턴스를생성해야만한다.

이러한장치가바로,웹서비스플랫폼아키텍처WSPA의직렬화하부시스템이다.직렬화하

부시스템은호출과정에서다음단계들에대한책임을진다:

호출 과정에서 직렬화 시스템의 책임

웹서비스프록시로부터파라미터를전달받는다.1.


그림 1.2 직렬화는 SOAP을 통해 웹 서비스에 전달하도록 자바 인스턴스를 XML 문서로 변환한다.


cust (com.soabook.sales.Customer의인스턴스)파라미터를imported:

customer의인스턴스로직렬화한다.

파라미터po(com.soabook.purchasing.PurchaseOrder의인스턴스)를

imported:po의인스턴스로직렬화한다.

이두요소를wrapper:customerPurchase의인스턴스로합친다.

wrapper:customerPurchase의인스턴스가SOAP메시지에포함되도록웹서

비스프록시에게전달하고,SOAP엔드포인트로보낸다.

이간단한예제가보여주듯이,직렬화하부시스템은자바인터페이스를통한웹서비스호

출과정에있어서중심역할을한다.직렬화하부시스템은각각의자바클래스들의인스턴스

에서추출한파라미터들을타겟XML스키마의인스턴스로변환(인터페이스프록시에전달)

하게된다－이런경우에는wrapper:customerPurchase가타겟이된다.이러한자바클래

스에서타겟스키마컴포넌트로의매핑을가리켜타입매핑TypeMapping이라고부른다.이러

한변환을위해서직렬화엔진은어떻게타입매핑을구현할것인지를알려주는,일련의매핑

전략(그림1.3에서묘사한바있는)－달리말해,어떻게자바클래스의인스턴스를XML스키

마컴포넌트들의인스턴스로직렬화할것인지－을필요로한다

매핑전략은자바클래스,클래스의타겟XML스키마타입,그리고클래스의인스턴스들을

스키마타입(또는기타등등의)인스턴스로변환해줄수있는직렬변환기(또는역직렬변환

기)와연관되어있다.직렬화컨텍스트serializationcontext는,특정한웹서비스를배포할때사

용되는타입매핑을구현하기위해직렬화하부시스템이사용할수있는일련의매핑전략을

말한다.

여러다른웹서비스플랫폼들이직렬화컨텍스트를만드는매핑전략을제각기다른방식

으로제공한다.대부분그과정에는하나가아닌복수의메소드가사용되는편이다.다음은

그방법들중일부를나열해본것이다.

타입 매핑을 구현하는 방법

표준바인딩StandardBinding.매핑은자바클래스들을XML스키마로변환하는

표준바인딩에의해미리정의된다.각자바클래스는XML스키마로서,고유

의표현을가지게된다.JWS는기본적으로이방식을사용하며,다른커스터마

이징도지원한다.표준바인딩은JAXB와JAX-WS명세에기술되어있다.

소스코드어노테이션SourceCodeAnnotation.JWS는표준바인딩에기반한커스터

마이징을지원하는데이방식을사용한다.타겟자바클래스의소스에있는어노

2.

3.

4.

5.

▒

▒


테이션들은어떻게클래스가XML스키마컴포넌트에매핑될지,그리고웹서비

스의WSDL이어떤형태를갖게될지를명시하기위해표준바인딩을수정하게

된다.

알고리즘을사용하는방법Algorithmic.직렬화하부시스템이실행하는알고리즘

에매핑방법이내장된다.JAX-RPC1.1과Axis1.x가이방법을사용한다.

규칙기반RuleBased.매핑은직렬화하부시스템과독립적으로생성,편집될수있

는별개의규칙으로써명시된다.이규칙들은직렬화하부시스템에의해해석된다.

SOA-J(1.5절에서소개한)는매핑에규칙기반의방식을사용한다.Castor[CASTOR]

직렬화프레임워크도매핑파일을사용해서이런접근법을지원한다.

그림 1.3 직렬화 컨텍스트는 직렬화를 수행할 직렬화 하부시스템이 사용할 매핑 전략을 포함하게 된다.

각각의방식들은제각기장단점을지닌다.JWS는자바프로그래머들이자바타겟이어떻

게WSDL오퍼레이션으로표현되어야하는지를쉽게명시하기위해소스코드어노테이션을

도입했다.나는규칙기반방식을선호하는데,최종사용자가이미존재하는자바클래스를

기존의스키마타입으로매핑할수있어야하기때문이다－여러분이많은레거시클래스들과

스키마들을다루어야하는엔터프라이즈애플리케이션들을SOA스타일로느슨하게결합시

▒

▒


키기위해웹서비스를사용하는경우라면스키마타입은매우유용한방법이될것이다.

직렬화는매력적이고자세히살펴볼만한가치가충분한주제다.여러가지다양한종류의

작업에대해제각기적합한방식들이존재한다(예를들어레거시시스템과의통합과신규시

스템개발의경우를생각해보자).바로이것이야말로항상시장에서수없이다양한직렬화방

식간에경쟁이계속되고있는이유라고할수있을것이다.5장에서는JAXB2.0의직렬화를

좀더깊숙이다뤄보겠다.

1.2.3 배포

배포하부시스템은자바타겟을설정하는데필요한도구를제공하여,SOAP기반의웹서비

스를실행한다.좀더상위관점에서바라보면,배포하부시스템은다음과같은것들을처리

할필요가있다.

배포 하부시스템의 책임

자바타겟을배포하기.이작업은호출이이루어지는자바컨테이너에크게의

존하게된다.EJB컨테이너에서는무상태세션빈StatelessSessionBean을배포하

는것을의미할수있다.하지만다른환경에서는단순히각각의자바타겟들

의클래스정의를호출하부시스템이사용하는클래스로더에서사용할수있

게하는것을의미하기도한다.

WSDL오퍼레이션을자바타겟에매핑하기.이작업은웹서비스플랫폼을설정

하는작업을포함하는데,이를통해호출하부시스템이수신하는SOAP메시지를

자바타겟에정확히연관시킬수있게된다.이연관관계(또는바인딩)는호출하

부시스템이배포하부시스템으로부터얻어올수있도록메타데이터로저장되며,

반드시호출되어야하는자바타겟을결정하는데사용된다.WSDL오퍼레이션

을자바메소드에연결시키는일외에도,배포하부시스템은호출시스템이수신

되는메시지에대해SOAP바인딩을정확히해석하도록도와야한다(예:RPC와

포장된wrapped상태의documentstyle또는포장되지않은documentstyle).

직렬화컨텍스트를정의하기.배포시스템은직렬화컨텍스트(그림1.3참조)를

사용해직렬화하부시스템을설정하게된다.이때시스템은WSDL과파라미터에

서얻어진XML스키마타입과자바타겟으로부터얻은반환클래스를바인딩하게

된다.

WSDL을발행하기PublishingWSDL.배포하부시스템은자바타겟을바인딩될

WSDL오퍼레이션을담고있는WSDL문서와연관시킨다.이WSDL문서는

▒

▒

▒

▒


URL또는다른형식(예:UDDI레지스트리내부에서)으로웹서비스클라이언

트에게제공된다.

SOAP핸들러SOAPHandler설정하기.배포하부시스템은자바타겟의호출이

전또는이후시점에QoSQualityofService를제공하기위해,필요한SOAP핸들

러를설정한다.이핸들러들은인증authentication,신뢰성reliability그리고암호화

encryption같은서비스들을제공하게된다.호출하부시스템이핸들러를호출하

긴하지만실제로는배포하부시스템이핸들러들을웹서비스에설정하고연계

시킨다.

엔드포인트리스너EndpointListener를설정하기.WSDL포트에의해명시되는

URI에SOAP메시지전송리스너가위치하기때문에배포하부시스템은컨테

이너에별도의설정을하게된다.몇몇웹서비스플랫폼에서는WSDL이엔드

포인트가정의되지않은채제공되고,이경우에엔드포인트는배포기술자에

있는배포하부시스템에의해‘채워지게’된다.

이설명에서볼수있듯이배포하부시스템은온갖종류의매력없는작업들을잔뜩수행해

야만한다.다양한종류의상황들을처리하기위해(예:QoS요구사항,커스텀자바/XML바

인딩,설정가능한엔드포인트URL등)배포기술자(배포하부시스템에의해사용되는XML

파일들)는GUI도구없이는관리하기어렵고복잡할정도로빠른속도로덩치가커진다. 7)

그림1.4는웹서비스플랫폼에서사용될수있는배포기술자들의종류와,그기반의컨테이

너와기술자간의관계를보여주고있다.

그림1.4에서볼수있듯이,웹서비스플랫폼은복수의컨테이너에걸쳐존재할수있다.

여기서는,애플리케이션서버컨테이너(예: JavaEE)와웹서비스디렉토리컨테이너(예:

UDDI)를보여주고있다.

애플리케이션서버컨테이너는디렉토리를포함하고있을수도있다.화살표는의존관계를

보여준다.그림에서볼수있는것처럼각각의객체들은각특정컨테이너의배포기술자에

따라컨테이너에배포된다.엔드포인트리스너,SOAP핸들러,자바타겟은WSDL/자바매핑

기술자에서도사용될수있다.참조reference가여러개있다는것은객체도다수의역할을가

진다는것을의미한다.예를들어,자바타겟은컨테이너의객체와웹서비스플랫폼의객체

둘모두로써배포될수있다.

7) 돌이켜보면,EJB2.1에서작업하는이들에겐,기하급수적으로늘어나는배포기술자야말로,공통적인불만사항이었던것같다.

J2SE의웹서비스를통해,배포기술자는더더욱복잡해져만갔다.다행히도JavaEE5에서,배포기술자의필요성은급격히감

소했다.

▒

▒


요약하자면,웹서비스플랫폼아키텍처WSPA는세가지하부시스템을정의한다:호출,직렬

화그리고배포.책의나머지부분을통해아직다루지않은자바웹서비스의내용들을알아

볼것이다.그과정에서JavaEE와JavaSE에정의된JWS의다양한컴포넌트들이WSPA전반

에서수행하는역할에대해논하게될텐데,그때하부시스템들과그세부적인사항들을다시

살펴보게될것이다.

1.3 자바 웹 서비스 : 2장 ~ 8장

앞에서언급한대로,이책의주된목적은,SOA애플리케이션개발에자바웹서비스를사용

하는데있어서자세한기술적이해를제공하는데있다.직접코딩을해봐야지만기술적인

실제의이해를얻을수있기때문에,이책은그런기술들을사용하는많은소프트웨어예제

들을제공한다.자세한기술적이해를깊게하기위한그첫단계는JWSAPI의깊숙한곳을

탐험해가면서그장점과한계를살펴보는것이다.2장은JWSAPI에대한고수준의개요를제

그림 1.4 배포 하부시스템은 매우 많은 배포 기술자를 사용할 수도 있다.


공한다.3~8장은이API들로어떻게웹서비스를작성하고배포할지에대한자세한예제들을

제공한다.이예제들은소프트웨어벤더들이제공하는전형적인“HelloWorld”정도의튜토

리얼의수준을넘어선다.대신에,보다자세하고실세계에서사용할수있는구현들을제공한

다.게다가어떻게하면이API들로프로그래밍할수있는지만을간단히보여주는데그치지

않고1.2절에서다룬웹서비스플랫폼아키텍처와그API들을연관시킨예제들을사용한다.

다음은각장의내용에대한간단한요약설명이다.

2장 : 자바 웹 서비스 개요

주요자바웹서비스API들의기능과강점그리고약점에대해전반적인개요들을다루고있

으며,JAX-WS2.0 [JSR224], JAXB2.0 [JSR222],WS-Metadata2.0 [JSR181],그리고Web

ServicesforJavaEE1.2[JSR109]등을다루고있다.그리고특별히이API들이실제웹서

비스애플리케이션프레임워크에서어떻게적용되는지를살펴본다.여기서다루진않았지

만SOAPwithAttachmentsAPIforJava(SAAJ)[JSR67]가6장과7장에서SOAP처리에대해

JAX-WS를논하는과정중에언급된다.

3장 : REST를 사용한 기본적인 SOA

웹서비스를가장단순한방식으로바라보는방식에대해다루고,본격적인기술적예제

가나오기시작한다:RepresentationalStateTransferREST가기존의HTTP와JWS를사용해

RESTful서비스를어떻게구현하는지를보여준다.또한,SOA통합을위한방법으로REST가

가진한계들에대해서도논의할것이다.이러한한계들을이해함으로써다음장에서소개하

는SOAP과WSDL이왜필요한지를알수있게될것이다.

4장 : SOA에서 WSDL , SOAP의 역할 그리고 자바/XML 매핑

이장은SOA에서왜WSDL과SOAP가필요한지에대한논의로시작된다.그러고나서,실세

계의SOA통합시나리오에서,SOAP과WSDL이어떻게사용되는지에대해자세히설명하는

부분으로넘어간다.어떻게WSDL의구조에기반해서SOAP요청이디스패치되는지를보여

주기위해,SOAP과WSDL을1.2절에서소개한웹서비스플랫폼아키텍처를바탕으로설명

한다.마지막으로,이장은SOAP요청에의해운반된XML을웹서비스를구현하는자바클

래스들로매핑하는방법에대해논한다.그러한매핑을구현하는도구로써JAXB2.0을소개

하고,그제약과해결방법에대해서도다룬다.

5장 : JAXB 2.0 데이터 바인딩

JAXB2.0을자세히다루면서,XML을자바로매핑하는다른방법들과비교하게된다.JAXB2.0

의표준자바/XML바인딩,스키마컴파일러,그리고스키마컴파일러에의해생성되는어노테

이션등의많은기술적인예제들을자세히다룬다.어떻게JAXB런타임이어노테이션에기반


해직렬화와역직렬화를수행하는지에대해서도,또한JAXB직렬화/역직렬화과정의동작을

어떻게여러분고유의어노테이션을통해서커스터마이징할수있는지도소개할것이다.여기

서JAXB2.0을웹서비스플랫폼아키텍처－이책에서사용되는레퍼런스아키텍처인－의직

렬화하부시스템으로써적용하고있다.그다음으로JAXB의한계에대해자세히다루는데,특

별히JAXB2.0기반의직렬화하부시스템에서타입매핑의추상화가가진어려움들을살펴보

고,이런어려움들이어떻게관심사의분리를어렵게하고변화관리에부정적인영향을미치

게되는지에대해논한다.이장에서는XmlAdapter클래스와같은좀더진보적인JAXB2.0

의특징들을어떻게사용할지,그리고어떻게여러분고유의JAXB2.0기반의재귀적인직렬화

하부시스템을여러분고유의방식으로구축할지에대한자세한예제를포함한다.앞서논한제

약들에대한해결책들도제시된다.여기소개되는커스텀직렬화계획은SOA-J직렬화하부시

스템의프로토타입을소개하면서좀더상세히설명할것이다.

6장 : JAX-WS 2.0 클라이언트 측 개발

이장에서는,JAX-WS2.0의클라이언트측API가자세히다룬다.즉,타겟서비스의자바인터

페이스를제공하는JAX-WS2.0프록시클래스를사용해서,웹서비스를호출하는방법에대

해설명한다.JAX-WSWSDL컴파일러(예:글래스피시의wsimport명령 8))를사용해서컴파

일타임에WSDL로부터자바인터페이스를생성하는방법을다루고나서,이인터페이스를사

용해런타임에웹서비스를호출할수있는JAX-WS프록시클래스인터페이스를생성하는법

을알아볼것이다.이런기초적인예제들외에도,6장에서는JAX-WS2.0의WSDL에서자바로

의WSDLtoJava매핑에대해깊이있게다룬다.이매핑을이해하는것은,JAX-WSWSDL컴파일

러에의해생성된클래스들을사용하는방법을이해하는데있어서매우중요한대목이다.생

성된인터페이스클래스에서JAX-WS가사용하게되는어노테이션들을살펴보고나서,이어

노테이션들이어떻게JAX-WS2.0프록시에의해서,송수신메시지를구성하게되는지를보여

줄것이다.또한이장에서는,JAX-WS에서예외처리와,자바Exception클래스인스턴스,그

리고SOAP오류메시지SOAPFaultMessage간의매핑방법에대해서도살펴본다.기본적인것을

모두다룬후엔3장에서소개한REST모델로돌아가,JAX-WS를사용한XML메시징(SOAP을

사용하지않는)에대한좀더상세한주제들을살펴본다.디폴트바인딩을다른것으로교체하

는방법과JAXB클래스와Castor를포함한다양한바인딩을사용하고,웹서비스호출방법으

로JAX-WS의사용(DispathcAPI를통해)에대한논의가이어진다.JAX-WS의비동기호출과

SOAP메시지핸들러를설명하는데있어서입문자도쉽게이해할수있을정도의상세하고기

술적인예제들이제공된다.

8) 이책의서문에서밝힌대로,모든예제는글래스피시를사용해서개발하고테스트했다.하지만,기반이되는모든코드들은

어떤JAX-WS구현체에서든지동작할수있다.IBM,JBoss,BEA,오라클등의모든JAX-WS도구들이동일한WSDL자바간매

핑을구현하고있고,동일한클래스들을생성해낸다.


7장 : JAX-WS 2.0 서버 측 개발

이장은JAX-WS2.0에대한논의의후반부로써,서버측API에초점을맞추고있다.논의는

JAX-WS의서버측아키텍처에대한설명과이아키텍처가1.2절에서소개한웹서비스플랫

폼아키텍처WSPA의참조설계에어떻게대응되는지에대한내용으로시작한다.SOAP프로토

콜바인딩,오류처리,메시지핸들러를포함해서JAX-WS의다양한부분들이어떻게조화를

이루는지에대해자세한이해를돕기위한내용들을다룬다.JAXB바인딩인터페이스,WSDL

생성그리고디스패치서비스를설명하고난다음,@WebService와@WebServiceProvider

어노테이션두가지모두를사용해서,웹서비스배포방법에대한일련의예제들을소개

한다. SOAP요청과함께전달되는HTTP요청헤더로접근할수있게하는방법으로써

WebServiceContext의리소스주입ResourceInjection을다룬다.JAXB2.0의또다른바인딩방

식으로써,Castor를사용해서웹서비스를배포하는방법에대한상세한예제도다룬다.그리

고마지막으로유효성검증과오류처리에대한논의와서버측핸들러를구현하는방법,Java

SE의웹서비스배포도구인javax.xml.ws.Endpoint클래스를사용해서컨테이너없이배

포하는방법등에대한내용들을다룬다.

8장 : SOA 컴포넌트 패키징하고 배포하기

웹서비스를패키징하고배포하는방법에초점을맞추면서,이장을끝으로JWS표준에대한

상세한논의를마감하게된다.WS-Metadata[JSR181]어노테이션과,이를사용해EJB와서블

릿엔드포인트을배포하는방법에대한예제를다룬다.배포기술자를전혀사용하지않고서

도웹서비스를배포할수있는방법(그렇다,JavaEE5에서는가능하다!)과디폴트배포방식

과어노테이션기반의배포방식을재정의하는방법을소개하고,언제어느부분에서배포기

술자를사용하는것이적합한지를배울것이다.

이장은서블릿엔드포인트의배포에필요한WAR구조에대한설명과,EJB엔드포인트에

사용되는EJBJAR/EAR구조에대한설명도포함하고있다.또그밖에도,JavaEE5컨테이너

구현체가배포처리를어떻게수행하는지에대한상세한개요도다룬다(예:컨테이너가어노

테이션이달린패키지컴포넌트에서배포된웹서비스로이동하는방법).

다른JWSAPI에대한설명처럼,이논의도JavaEE5의웹서비스배포하부시스템에대한

장/단점을비평하기위해,1.2절의웹서비스플랫폼아키텍처의레퍼런스설계를적용하고

있다.패키징과배포에는수많은방법이존재하기때문에,이장은이런방법들을적용한각각

의다양한형태들에대한10종류의패키징예제를포함하고있다.마지막으로,심화주제로써

JavaEE5에서제공되는OASISXMLCatalog[XMLCatalog1.1]지원에대해다루게된다.


1.4 SOAShopper 사례 연구 : 9장 , 10장

9장과10장은2장부터8장까지다뤘던기술과기법들을통합해서살펴보고,JWS를사용해서

SOA통합애플리케이션을만드는방법을보여주고있다.SOAShopper애플리케이션은이베

이,아마존,그리고야후!쇼핑을통합하는온라인쇼핑시스템이다.이시스템은각쇼핑사

이트들의클라이언트로써,웹서비스소비자consumer역할을하게된다또한,SOAShopper는

웹서비스공급자provider이기도한데,이는이세쇼핑사이트들을아우르는검색서비스를제

공하는REST와SOAP엔드포인트를배포하기때문이다.

9장 : SOAShopper ,이베이, 아마존, 야후 쇼핑 통합하기

SOAShopper는데모애플리케이션이긴하지만여기서보여주는기법들은무척강력한것들

이다.이장에서는실제SOA통합시스템을생성하기위해이전장에서다룬모든도구들을

사용하게될것이다.이장은RESTful서비스들을배포하고소비하는코드,WSDL/SOAP서

비스의배포와개발,JAXB로타입매핑구현하기,WSDL중심적인서비스통합,그리고Ajax

클라이언트에대한지원등에대한논의와예제들을포함하고있다.

10장 : Ajax와 자바 웹 서비스

10장은9장에서개발했던SOAShopper애플리케이션을사용해서RESTful서비스들을소비

하는Ajax프론트엔드를만들어본다.이장에서는JWS가Ajax클라이언트들을지원하는데

있어실제로어떻게사용되는지에대해초점을맞추게된다.

1.5 SOA-J와 WSDL 중심 개발 : 11장

자바웹서비스JWS만을배우고싶은독자라면11장을건너뛰어도좋다.대신,웹서비스플랫

폼아키텍처WSPA가어떻게WSDL중심적인방식으로구현되었는지,JWS에의해제공되는

도구들을어떻게사용했는지가궁금하다면,11장을반드시읽어야한다.이최종장에서는,

SOA-J의세세한부분들을짚어가며설명하고있다.

WSDL중심적이라는용어는WSDL을통해웹서비스를생성하고,그WSDL문서에구현하

는자바요소에대한참조를어노테이션으로다는방식을말한다.이러한WSDL중심적인접

근방식은,기업의표준또는e-비즈니스프레임워크(예:표준스키마와메시지기술이존재하

는경우)에통합된웹서비스를생성하는경우에적합하다고볼수있다. 9)

9) 4장에서그런상황들에대해설명하고있다.


SOA-J는프로토타입애플리케이션프레임워크다.나는JWS로WSDL중심적인SOA개발

을할수있다는가능성을살펴보고자,개념을증명하기위한목적으로이프레임워크를개발

했다.SOA-J의소스코드(오픈소스)는이책과함께제공되는코드예제로제공된다. 10)최신

버전의SOA-J또한http://soa-j.org에서찾아볼수있다.

11장 : SOA-J와 함께하는 WSDL중심 자바 웹 서비스

이장에서는JWS기반의애플리케이션프레임워크인SOA-J가어떻게설계되었는지를살펴

보게된다.SOA-J가WSDL로부터SOA컴포넌트를조합하는단순한방식을어떻게제공하는

지를설명할것이다.이장에는제법많은UML다이어그램이나온다.SOA아키텍처를좀더

자세히다루고싶었기때문이다.이논의는웹서비스엔진(SOAP서버라고부르기도하는)이

어떻게동작하는지를궁금해왔던모든사람들에게유용할것이다.여기에서사용된원칙들

은WSPA 11)에요약되어있으며,Axis와XFire와같은제품들에도녹아들어있다.

이장에세부구현을포함한이유는,예전에내가아파치Axis를접했을때의경험에서비롯

된것이다.처음Axis소스코드를접했을때,나는완전히길을잃어버린기분이었다.다행스

럽게도,SOA-J에대한설명을읽고나면,여러분이다른웹서비스엔진의소스코드를보게

되더라도,길을완전히헤매진않을수있을것이다.

10) 책의예제들을다운로드하고설치하는방법에대해서는부록B를참조하라.

11) 1.2절을참조하라

25

02장.자바웹서비스개관

이번장에서는JavaEE5와JavaSE6가지원하는자바웹서비스JWS표준이제공해주는능

력들에대한개요를설명한다.SOA애플리케이션개발에서의JWS의역할을살펴봄으로써논

의를시작한다(2.1절).그러고나서사용편의성중심의JavaEE5기능들을다룬다(2.2절).프

로그래밍프로세스를쉽게하는것이JavaEE5웹서비스출시의최우선과제이므로먼저이

러한사용편의성을위한설계결정과그것이개발에미치는효과에대해간략하게살펴본다.

이번장(2.3－2.5절)에서는JWS를정의한JSRJavaSpecificationRequest 1)에따라JWS가가지

고있는능력을분류하여논의한다.각각의JSR들을리뷰할때,그기능들은이미앞서언급

된1.2절의‘웹서비스플랫폼아키텍처’와연관된다.여기서언급되는,책을통틀어가장중

요한JSR들은JAX-WS2.0 [JSR224], JAXB2.0 [JSR222],WS-Metadata2.0 [JSR181]과Web

ServicesforJ2EE1.2[JSR109](흔히줄여서WSEE)이다.

이번장은JavaEE5기술혁신중에서웹서비스JSR에는명시적으로포함되진않았지만

웹서비스개발에큰영향을미치는것에대해살펴보면서마무리한다(2.7절).여기에서는의

존성주입dependencyinjection과EJB3.0과같은능력들에대해다룬다.

이번장에서는큰그림에대한올바른이해를제공하고,3장에서11장으로이어지는설계와

프로그래밍에본격적으로뛰어들기위한준비과정의역할을한다.

1) 자바커뮤니티(Javacommunity)는JSR을이용하여언어에대한새로운기능을정의한다.JSR은www.jcp.org에기술된

JCP(JavaCommunityProcess)의한부분으로서정의되고승인된다.

자바 웹 서비스 개관26

2.1 SOA 애플리케이션 개발에서의 JWS의 역할

기본적으로JWS는자바를이용하여웹서비스를이용하고생성하는것을가능하게해주는기

술들의집합체로구성된다.JWS라는기술이SOA개발에서어떤위치에적용되는지논의를

시작하기위해가상적인SOA애플리케이션을검토한다.

2.1.1 가상의 SOA 애플리케이션

그림2.1은이번논의에사용될가상의SOA애플리케이션을보여준다.고객의주문을처리

하는주문관리애플리케이션이다.이애플리케이션은고객의주문을SOAP요청으로받아서

SOAP응답으로주문확인을고객에게되돌려준다.

그림2.1의가운데에있는주문관리애플리케이션은기존서비스들을모아놓은형태로구

성되어있음을강조하기위해서‘SOA복합애플리케이션CompositeApp’으로명명되었다.토마

스얼ThomasErl은[Erl]의46페이지에서“서비스는로직이라는독립적인단위로존재한다.그

러므로비즈니스프로세스는프로세스의부분을실행하는데있어서각각책임을질수있는

일련의서비스로나뉠수있다”라고쓰고있다.얼의말대로이예제를기술하면SOA복합애

플리케이션은주문관리비즈니스프로세스를자동화하고있다고할수있다.그러한비즈니

스프로세스는그림2.1에서표기된바와같이다음단계로나눌수있다.

주문 관리 비즈니스 프로세스

고객이PO번호와주문항목리스트를포함한다른정보들을함께담아서고

객주문을보낸다－물건과수량이주문된다.

PO번호와주문항목은구매주문시스템으로넘겨진다.구매주문시스템은

PO가주문항목을가지고있는지와어떤지불조건이요구되는지결정하기위

해구매주문을검사한다.

PO가주문항목을가지고있다면권한부여와요구되는지불조건에대한설명

이반환된다.

다음은주문항목이재고에있는지,배송일은언제가될지를결정하기위해재

고관리시스템으로주문항목을넘긴다.

항목가용성ItemAvailability이반환된다.

마지막으로항목에대한지불조건과예상배송일에대한내용을담고있는응

답메시지가고객에게전달된다－주문확정.

1.

2.

3.

4.

5.

6.

27자바 웹 서비스 개관

얼의용어를써서표현하자면,이비즈니스프로세스는구매주문서비스와재고관리서비

스와같은두개의‘독립적인로직단위’로나눌수있다.SOA복합애플리케이션안의서비스

가그러하듯이이들‘로직단위’는입력과출력메시지로설명될수있다.구매주문서비스(그

림2.1의오른편상단)는다음서비스를제공할책임이있다.

구매 주문 서비스

입력메시지:PO번호와주문되는항목리스트.

처리:구매주문이주문항목을가지고있는지와어떤지불조건이요구되

는지결정한다.

그림 2.1 주문 관리를 위한 SOA 복합 애플리케이션


출력메시지:주문항목에대한권한부여와그항목들에요구되는지불조건에

대한기술.

그림2.1에표기된것처럼구매주문서비스는JavaEE5를이용하여구현되었다.구매관

리시스템에포함된또다른서비스는재고관리시스템이다.이시스템은다음서비스를제

공할책임이있다.

재고 관리 서비스

입력메시지:주문항목리스트

처리:항목들이재고에있는지와언제배송을시작할지결정한다.

출력메시지:항목리스트와예상배송시작일－항목가용성이라고한다.

그림2.1에서표기된것처럼재고관리서비스는.NET을이용하여구현되었다.

그림2.1의가운데위치한주문관리시스템은구매주문서비스와재고관리서비스에의

해제공되는근간서비스들의복합체이기때문에SOA복합애플리케이션이라고한다.이시

스템은고객주문이들어오면구매주문서비스와재고관리서비스를순차적으로호출하고

주문확정을위해그서비스들로부터받은정보들을묶어서처리한다.이주문관리시스템은

그자체로하나의서비스로간주할수있음에주목하자.사실고객주문의발송자에게는정확

히다른하나의서비스로취급된다.그러므로SOA를사용하면근간서비스들을조합하여서

비스를구성할수있다.따라서구축된주문관리서비스는다음과같이기술할수있다.

주문 관리 서비스

입력메시지:PO번호및주문항목들외에주문제품과수량과같은다른정보들을

포함하는고객주문

처리:고객이특정한PO를통해서요청한항목을살수있는권한이부여되

는지와권한이부여된다면지불조건이무엇인지,언제물품이배송

가능한지를결정한다.

출력메시지:주문확정－항목의지불조건과예상배송날짜를담고있다.


그림2.1에표기된대로주문관리서비스는JavaEE5를사용하여구현되었다.

2.1.2 SOA 개발을 가능하게 하는 JWS

이러한주문관리설계에대해서생각해보면,복합SOA애플리케이션이호출하는내재된서

비스들은잘정의된인터페이스를가져야한다는것은분명하다.예를들면,구매주문시스

템으로부터권한부여및지불조건을요청하는주문관리시스템에서는요청이어떤형식을

가져야하는지정확히알아야한다.또한그요청을구매주문서비스가받고이해할수있는

형태를한메시지로포장할수있는방법을알아야한다.이예에서웹서비스표준은요구되

는인터페이스를정의하는데필요한구조를제공한다.SOA에서꼭요구되는사항은아니지

만,웹서비스는플랫폼에중립적인방식으로SOA애플리케이션을작성하는것을쉽게해주

는인터페이스와메시지에관한표준을제공한다.앞서살펴본예제에서구매주문서비스는

JavaEE5환경에서구현되어있고,재고관리서비스는.NET환경에서구현되어있다.그러

나JavaEE5와.NET모두웹서비스를지원하므로그들이각각가지고있는웹서비스인터

페이스를이용하여그기존애플리케이션들을호출하는주문관리시스템을구축하는것이

가능하다.

웹서비스를사용할때인터페이스는WSDL [WSDL1.1,WSDL2.0]을이용하여정의한

다.그러므로그림2.1각각의서비스는WSDL문서와함께연계되는모습으로그려져있다.

WSDL은XML을이용하여표현된다.WSDL은웹서비스의입출력파라미터들을XML스키

마 2)[XSDPart0]에의해나타낸다.입력파라미터들은메시지구조를사용하여웹서비스로

전달된다.마찬가지로출력파라미터들은메시지로받게된다.다시얘기하면SOA는어떤특

수한메시지구조를강제하는것은아니지만,SOAP[SOAP1.1,SOAP1.2]은누구에게나보

증할수있는선택인것이다.SOAP메시지는WSDL인터페이스정의에의해기술된입출력

파라미터들을전달하는데사용할수있다.그래서웹서비스는SOA개발에필요한두가지

핵심요소들을제공한다.인터페이스정의언어WSDL와메시지표준SOAP이다.

SOAP메시지는다양한전송방식(예를들면,HTTP,SMTP와JMS)을통해교환할수있다.

이전에언급된주문관리예제에서는HTTP가사용되었다.HTTPGET요청은WSDL인터페

이스정의를서비스로부터가져오기위해서발부되고,HTTPPOST는SOAP요청/응답교환

을다루기위해서사용된다.그것이기본적인웹서비스프레임워크(즉,SOAP/HTTP를가지

고있는WSDL)가SOA애플리케이션개발에사용되는방식이다.

2) 이는간단한개요이고,웹서비스에서의WSDL과SOAP의사용은4장에서자세히다룬다.


JWS표준은자바로WSDL과SOAP/HTTP에관한작업을할수있도록도구를제공한다.자

바메소드를SOAP메시지로호출하는것을가능하게하고,연관된WSDL인터페이스정의를

발행할수있게해주는서버측도구가있다.마찬가지로WSDL문서를읽고SOAP메시지

를보내고받기위한클라이언트측도구가있다.그림2.2는다양한자바웹서비스표준JSR

들이어떻게서버측을지원하는지를보여준다.서버측에서의다양한JSR들의역할을설명

하기위해그림2.2에서는서비스의배포와호출과정을번호를매겨가며추적하였다.지금

까지살펴본SOA의수준이10000피트상공이었다면이제부터는100피트정도의높이에

서JWS표준들을심도있게다루며,보다상세하게설명한다. 3)

그림2.2가묘사하는바를이해하기위해‘포트컴포넌트’라고이름붙여진폴더가있는아

래부분부터시작한다.이것은JavaEE5컨테이너에배포되는패키지된웹서비스를나타낸

다.가운데‘웹서비스애플리케이션’이라고된상자는웹서비스를구현한(배포작업이끝난)

런타임클래스들이다.그위에는‘자바파라미터들’이라고이름붙여진몇개의상자와‘자바

응답’이라고이름붙여진상자하나가있다.파라미터상자들은‘웹서비스애플리케이션’안

의클래스들중한클래스의메소드에전달되는자바객체의런타임인스턴스를나타낸다.구

매주문서비스예제(그림2.1)를다시생각해보면,이파라미터들은PO숫자와주문항목들

이될수있다.마찬가지로이파라미터들위의‘XML파라미터들’과‘XML응답’으로이름붙

여진상자들은이러한파라미터들과응답값의XML형태를나타낸다.그림을계속보면제일

위쪽부근에‘엔드포인트’라고이름붙여진원이있다.이것은WSDL인터페이스정의문서를

위한HTTPGET요청과,SOAP입출력메시지를교환하기위한HTTPPOST요청을웹서비

스애플리케이션이받아들이게되는URL을나타낸다.

그림2.2에서의어두운색막대들은어떤JSR이웹서비스배포와호출의여러단계에상

응하는지나타낸다.그림2.2의라벨1-10을추적하면이JSR들의각단계에서의역할이설

명된다.

서버 측 웹 서비스의 배포와 호출

JWS는포트컴포넌트(포트라고도한다)를웹서비스의서버시점view이라고정

의한다.포트컴포넌트는(서블릿엔드포인트타입으로의배포를위한)WAR

형태나(EJB엔드포인트타입으로의배포를위한)EJBJAR형태의패키지로묶

을수있다.WSEE [JSR109]는배포과정과(배포기술자를포함하는)패키지

구조를정의하는주요한표준이다.WS-Metadata[JSR181]는어떻게패키지안

의클래스에들어있는어노테이션이배포를구체화하는지기술한다(즉,포트

3) 다음장들에서이주제를아주자세히파혜치며예제코드들을살펴본다.

1.


컴포넌트를나타내는WSDL인터페이스는WS-Metadata어노테이션을사용하

여사용자의목적에맞추어설정하는것이customizing가능하다).JavaEE5포트

컴포넌트의배포는1장에소개된WSPA참조시스템에서의배포하부시스템의

기능에상응한다.8장에서는배포에대해서깊게논의한다.

그림 2.2 서버 측－Java EE 5 웹 서비스 JSR들의 역할


그림2.2의가장윗부분으로이동하여,1단계에서설명된포트컴포넌트단위

로배포된웹서비스의호출을추적해본다.엔드포인트는웹서비스를기술

하는WSDL에대한HTTPGET요청을지원한다.WSDL의구조는JAX-WS의

WSDL/자바매핑에의해결정된다.이매핑은6장에서상세히다룬다.이매핑

은JAX-WS, JAXB와WS-Metadata에의해서정의되는어노테이션을사용하여

커스터마이징할수있다.일반적으로JAX-WS어노테이션은사용하는WSDL

의스타일(WSDL스타일에대해서는4장을참조한다)값을조종한다.반면에

JAXB어노테이션은자바파라미터와반환타입의XML스키마의요소들로의

변환을조종한다.WS-Metadata어노테이션은WSDL인터페이스의특이사항들

(즉,WSDL문서에포함된다수의XML요소들의타겟네임스페이스와로컬네

임들)을조종한다.WSDL요청을처리하는것은공식적으로는WSPA에서관장

하는부분이아니지만 4)웹서비스플랫폼의호출처리를담당하는하부시스

템의기능에보통포함된다.

배포된웹서비스의호출은HTTPPOST를통해서엔드포인트가SOAP요청을

받게되면시작된다.

웹서비스엔드포인트는보통서블릿클래스로구현하며이것은배포단계(1단

계참조)중에지정된엔드포인트URL에서요청을기다린다.이서블릿은포트

컴포넌트의개발자가설정하는부분이아니다.그보다는JWS의JavaEE5구현

의일부이다.배포중에어노테이션혹은배포기술자들은WSEE런타임에의

해읽혀지고,엔드포인트URL은결정되고,컨테이너의내부요소들은엔드포인

트의리스너를그엔드포인트에배포하기위해설정된다.이과정은8장에서상

세히기술하고있다.엔드포인트를세팅하는것은WSPA에있어서는배포하부

시스템의기능이다.

5단계는SOAP요청이XML파라미터－WSDL에서파라미터의형태로기술된

XML스키마요소들의객체－의집합이된것을보여준다.JAX-WS런타임은

SOAP메시지로부터파라미터들을추출하는책임이있다.이것은4장에서다룰

꽤나중대한변환작업이라할수있다.XML파라미터를추출하는것은WSPA

내부의호출하부시스템에의해다루어지는디스패치과정의한부분으로정의

할수있다.

4) 그이유는실제로클라이언트가WSDL을얻을수있는방법은여러가지가있기때문이다.많은경우WSDL문서는UDDI디렉

토리를통해접근이가능하다.그러한경우에WSDL에대한요청은그디렉토리로단순히전달되어지기만할뿐웹서비스플

랫폼에서실제로처리를해주지는않는다.UDDI는이책에서다루지않는다.그이유는서론에서언급하였다.

2.

3.

4.

5.


XML파라미터들이자바파라미터들로역직렬화된다.역직렬화는JAXB런타임

에의해서처리된다.역직렬화는타겟자바클래스의어노테이션에의해서제어

된다(즉,타입매팅이정의된다).JAXB런타임은타겟클래스의어노테이션을

검사하기위해‘인트로스펙션introspection’을사용하며그정보는(JAXB에의해

정의된자바/XML표준매핑과더불어)타겟파라미터들의객체를생성하는데

사용된다.JAXB직렬화와어노테이션은5장에서설명한다.이단계는WSPA에

서의직렬화하부시스템에대응된다.

파라미터가생성되면타겟자바클래스의메소드가호출된다.WSPA에서이것은

호출하부시스템의역할이다.JavaEE5에서는JAX-WS런타임에의해처리된다.

호출을위한메소드를제공하는클래스는EJB나POJO가될수있다.그림2.2는

JAX-WS,JAXB와WS-Metadata모두가웹서비스애플리케이션을구성하기위해,

어노테이션이달린자바클래스를정의하는데있어서각자역할을수행하는것

을보여준다.그것은바로각각의JSR들에정의된어노테이션이이클래스에사용

되었기때문이다.호출되는클래스는(서비스구현빈이라고한다)웹서비스를구

현하고있음을나타내는WS-Metadata어노테이션(예:@WebService)으로표기

해야한다.파라미터와반환타입을나타내는클래스들은대개많은JAXB어노테

이션들을가지게된다.그에덧붙여몇개의JAX-WS어노테이션들이WSDL의스

타일을제어하기위해서비스구현빈에사용된다.

호출후에는이프로세스의단계들이역으로동작한다.자바반환타입클래스

는XML반환타입객체가되기위해JAXB직렬화과정으로넘겨진다.(6장의

역직렬화과정과같은)이직렬화과정은자바반환클래스의어노테이션에의

해제어된다.

다음으로,JAX-WS런타임은XML반환타입객체를가져다가SOAP응답으로

포장한다.

마지막으로SOAP응답은HTTP응답에실려서요청자에게로다시보내진다.

일부단계(예를들면서버측의핸들러호출)는여기서기술하지않았다.그러나JavaEE5

컨테이너안에서웹서비스가배포되고호출되었을때,어떤일들이벌어지는지정도는설명

을할수있을만큼상세하게다루었다.이단계들중에열거한정보들은이제부터살펴볼여

러장들에훨씬자세하게설명되어있으니이시점에서너무장황하다고느껴서의기소침할

필요는없다.데이브포드너DavePodnar의웹서비스를다루는다섯번째단계 5)“수용－원래

5) 윗주5.1장1.1절을참조한다

6.

7.

8.

9.

10.


그렇다웹서비스는단순하거나쉽지가않다.”를기억하라.

그림2.3은여러JWS표준JSR들이어떻게웹서비스에있어서클라이언트측을지원하는지

를보여준다.이논의는JavaSE6혹은JavaEE5를사용하는클라이언트측의구현체에적용

된다.서버측의설명과마찬가지로여기다양한JSR들의역할은그림2.3에나타난숫자라

벨들에따라WSDL을읽고서비스를호출하는과정을추적하면서설명한다.

그림2.3에겹쳐서그늘진부분들은클라이언트측에서다양한JSR들이어디에적용되는지

를보여준다.

웹 서비스의 클라이언트 측 호출

웹서비스의클라이언트측호출에있어첫번째단계는WSDL로부터자바를

생성하는매핑툴을사용하여서비스엔드포인트인터페이스SEI를생성하는것

이다.SEI는호출할웹서비스의자바방식의표현을제공한다.SEI는클라이

언트애플리케이션에서인터페이스정의가사용되기때문에클라이언트애플

리케이션컴파일이되기전에생성된다. 6)그림2.3은SEI생성과정이JAXB,

JAX-WS와WS-Metadata를포함하는것을보여준다.JAXB는XML파라미터들

과반환타입들을WSDL에표기된대로SEI에서사용될자바파라미터와반환

타입으로매핑하여준다.WS-Metadata어노테이션은wsdl:operation으로

부터자바메소드로의매핑을기술하기위해SEI에표기된다.한편JAX-WS는

SEI의구조에포함되어WS-Metadata어노테이션과함께기술되는WSDL에서

자바로의표준매핑을제공한다.

런타임에는 JAX-WS의javax.xml.ws.Service라는클래스의인스턴스

가호출할웹서비스의클라이언트뷰client view를제공하기위해사용된다.

Service.getPort메소드중하나가이전단계에생성된SEI의런타임인스턴

스를얻기위해서사용된다.런타임인스턴스는자바프록시기술을사용하여

구현하고있고,그림2.3에서프록시객체로나타내어지고있다.그림에서보듯

이프록시객체는서비스엔드포인트인터페이스SEI를구현한다.

웹서비스호출은프록시객체의SEI메소드중의하나를호출하면서시작된다.

SEI메소드로넘겨진파라미터들은SEI를생성할때만들어진클래스들의인스

턴스이다.이클래스들은WSDL에포함된스키마로부터JAXB매핑에의해정

의된다.그림2.3은프록시인스턴스가구현한SEI가WS-Metadata와JAX-WS

6) SEI생성없이XML을웹서비스로단순히전송하는것만으로도웹서비스호출이가능하다.이러한접근방법은JAX-WS의6장

에언급된Dispatch인터페이스를사용한다.

1.

2.

3.


를사용하고있음을보여준다.SEI에는그두JSR로정의한어노테이션들이있

다.그러나이어노테이션들은사용자의SEI메소드호출에는영향을미치지않

는다.이어노테이션들은JAX-WS런타임이JAXB파라미터들과메소드호출을

웹서비스로전송되는SOAP요청으로변환하는과정에사용된다.SOAP요청

이JAX-WS런타임에의해생성되면,웹서비스엔드포인트로전송되어지기전

에핸들러들이(존재한다면)불려진다.핸들러들은사용자에의해서정의되며

SOAP요청/응답메시지들을조작할수있다.클라이언트핸들러의패키징과

정은WSEE명세 7)에정의되어있고,핸들러의호출은JAX-WS런타임에의해

7) JavaEE5나JavaSE6클라이언트로만지원된다.

그림 2.3 클라이언트 측－자바 웹 서비스 JSR들의 역할


서행해진다.핸들러들을엔드포인트구현에붙이기위해사용되는어노테이션

들은WS-Metadata명세에정의되어있다.

핸들러에서의작업이끝나면SOAP요청메시지는웹서비스로전송되고,

SOAP응답이돌아온다.SOAP응답은역순으로처리된다.먼저핸들러들이적

용된다.그리고SOAP응답파라미터들은(JAXB런타임을통해)역직렬화된다.

마지막으로프록시객체는응답값으로JAXB객체를반환한다.

여기서볼수있듯이클라이언트측의처리과정은서버측의배포와호출보다조금더간

단하다.6장은클라이언트측의보다자세한내용에대해초점을맞추고웹서비스를어떻게

호출하는지보여주는예제들을자세히다룬다.

2.2 사용 편의 특성에 대한 개관

JWS의주요목적은자바개발자들로하여금웹서비스를보다편하게개발하고배포하게하

기위함이다.JavaEE5[JSR244]에언급된대로,“JavaEE다음버전이갖는주요목표는개

발편의성이다.”

프로그래밍프레임워크를사용하기쉽게하기위하여설계자는타협점을가진설계결정을

내려야한다.예를들면JSTLJavaServerPagesStandardTagLibrary[JSR52]은JSPJavaServerPages[JSR

152]를생성하고유지함에있어URL기반의리소스접근과XML처리와같은통상적인기능

들을표준화함으로써쉽게해준다.그러나이러한사용편이성은기능에대한타협의대가다.

예를들면JSTL에서의XML처리는SAXSimpleAPIforXML방식을지원하지않는다.

좋은타협은제약을적게하면서도좀더사용하기편하게만드는것이다.대부분의JSP작

성자들은SAX처리능력을필요로하지않으므로이예에서의타협은좋은것이라하겠다.

더욱이좋은타협은필요할경우‘선택적배제’를가능하게해준다.예를들면,JSP2.0은JSTL

프레임워크에서는다루기적합하지않은상황들을처리할필요가있을때JSTL을배제하고

스크립릿scriptlets이나커스텀태그들을사용할수있게해준다.그리하여만약SAX를사용해

야할필요가생기면사용할수가있다.

이절에서는JWS에내재되어있는사용편의를위한설계결정들에대해서간단히살펴보고,

플랫폼의유용성에미치는영향을살펴본다.이러한설계결정들이‘좋은타협’인지간단히논

의해본다.하지만대부분의논의들은3~8장에걸쳐산재하여있다.

1장1.2절의웹서비스플랫폼아키텍처의개관부분에서기술하고있듯이자바로웹서비

스를배포하는것은본질적으로조금복잡하다.웹서비스플랫폼의주요설계목표는이러한

4.

5.


복잡성－특히배포복잡성－을개발자로부터보이지않게하는것이어야한다.웹서비스를

바탕으로하는간단하거나혹은조금은복잡한SOA방식의애플리케이션을설치하기위해

여러개의배포기술자들에대해고민할필요가없어야한다.

경험을통해알게된사실은그러한복잡성을줄이기위한접근법은일반화에제약을거는

것으로그문제를단순화하는것이다.JWS는웹서비스를어떻게생성하고배포하는가에대

해제약조건을부여함으로써복잡성을줄이려는몇가지메커니즘이있다.그중꼽을수있

는것은소스코드어노테이션,표준WSDL/자바매핑,표준직렬화컨텍스트(즉,JAXB)와‘자

바로부터시작’하는개발방식이다.

2.2.1 소스 코드 어노테이션

JWS설계자들은배포복잡성을줄이기위해웹서비스용의소스코드어노테이션을도입하

였다.어노테이션은JAX-WS[JSR224],WS-Metadata[JSR181]와JAXB[JSR222]에서정의

한다.이어노테이션들은WSPA에서정의하는세가지하부시스템－호출,직렬화,배포－

에서사용한다.

예를들어보통WS-Metadata어노테이션을사용하면JAX-RPC서비스를배포하는데필요

했던복잡한배포기술자들을작성하지않아도되고,대신에배포할클래스가어떻게웹서비

스로매핑되는지기술하기위한어노테이션만추가하면된다.이러한방식에서는JWS배포

하부시스템이컨테이너와웹서비스플랫폼을위한기술자descriptor들을생성하게된다.개발

자들은기술자에대해신경쓸필요없이어노테이션에만집중하면된다.

물론이렇게되면소스코드가더복잡해지고읽기힘들어진다.이런방식으로이미존재하

는자바클래스를SOA방식의웹서비스인터페이스로공개하고싶다면이미존재하는클래

스에어노테이션을추가하거나필요한어노테이션을가진래퍼클래스들을만들어야한다.

시간이경과되고실제로적용되는프로그래밍경험이쌓여야어노테이션을사용하는것이

배포기술자를직접다루는것보다더쉬운것임을알게될것이다.


2.2.2 표준 WSDL/자바 매핑

JAX-WS는WSDL과자바간의표준매핑을정의한다.최소한의소스코드어노테이션을가진

서비스구현빈 8)SIB이배포되면그결과로생성되는WSDL은기본매핑방식을따르게된다.

기본매핑을가지게되면웹서비스를배포할때WSDL혹은XML에대한이해가없는자바

프로그래머들은아주편해진다.이는자바프로그래밍언어에직접적으로웹서비스지원기

능을집어넣게된큰목적에있어서한부분을차지한다.

그러나표준매핑을이용하게되면웹서비스를배포하는것은한결쉬워지는반면에,그

아티팩트가유용한웹서비스라는보장은없게된다.기존의WSDL약정에웹서비스가부

합되어야한다면표준매핑은도움이되지않는다는것이문제이다.생성될WSDL을어노

테이션을통해변형하면서만든다하더라도그러한커스터마이징작업에는한계가있다.예

를들면WSDL의동일한포트내의두개의오퍼레이션들을두개의다른SIB의메소드로매

핑할수없다.그래서wsdl:port에foo와bar오퍼레이션이존재하면이들은모두같은클

래스혹은인터페이스의메소드로매핑되어야한다.foo를MyClass.doFoo()로,bar를

AnotherClass.doBar()로매핑하는것은불가능하다. 9)

더간단한예를들자면,WSDL포트는SIB로만매핑할수있다－어노테이션이없는클래스

를웹서비스로배포할수가없다. 10)

다시말하면,시간이지나봐야표준WSDL/자바매핑이얼마나유용한지를알게될것이다.

지금은찬사를보내거나비난하기에는너무섣부르다.현재로선가장최선의선택은우리의

선택에잘부합하는지판단하기위해충분히이해하는것이다.

WSDL/자바매핑에대한판단은아직유보되었지만자바가WSDL에대한표준매핑을가

지는것이아주중요하다는것은확실히말할수있다.표준매핑은그것이가지고있는한계

점에도불구하고자바클래스를웹서비스로쉽게배포하는것을가능하게해준다.그림2.3

에서설명하였듯이이미존재하는WSDL로부터서비스엔드포인트인터페이스SEI를자동으

로생성하는것을가능하게해준다.

8) 서비스구현빈은웹서비스엔드포인트로배포될수있는클래스형태이다.POJO혹은무상태세션빈이될수있으며8장의8.1

절에논의된일정한요건을만족하여야한다.

9) 한계점에대해서는4장,4.3.6절에서더자세히논의한다.

10) [JSR181]의3.1절에따르자면SIB의구현체는@WebService어노테이션을가져야한다.


2.2.3 표준 직렬화 컨텍스트

표준직렬화컨텍스트는웹서비스를배포할때타입매핑과직렬화를담당하는클래스를설

정할필요가없게해줌으로써개발을간소화한다.다시말하면,표준직렬화컨텍스트를사용

할때는XML을어떤자바클래스로매핑해야하는지를정의하지않아도된다.기본매핑은

표준직렬화컨텍스트가제공한다.JWS는직렬화과정을JAXB로이관시킴으로써이것을가

능하게하였다.JAXB는XML스키마요소들을자바로역직렬화하거나혹은자바에서시작하

여XML스키마요소들로직렬화하기위한표준규칙이있다.JAXB를사용하면지원되는타

입매핑은제한되지만웹서비스의설정작업은아주간단해진다.

이분야는간소화작업이아주환영받는곳이며,JAXB는자바/XML바인딩을위한든든한

프레임워크를제공한다.그러한표준직렬화프레임워크가실제로얼마나유용한지살펴보려

할때에도어려운점은발생한다.구체적으로,XML스키마를JAXB를사용하여컴파일하게

되면생성된자바클래스는기존의클래스들과는판이하게다르다.그래서예를들어구매주

문(예:imported:po)에대한XML스키마타입을사용하는웹서비스를JAXB프레임워크를

사용하여배포하고싶다면이미존재하는PurchaseOrder 클래스를사용할수없을것이다.

JAXB가imported:po로생성한Po클래스를사용하여야할것이다.

아무것도없이처음부터애플리케이션을개발하는것이라면생성된JAXB클래스들을사

용하는것이좋다.그것은예를들어서아무것도없이처음부터개발을시작하는경우에는

JAXB가imported:po로매핑하여생성한Po클래스를사용하는것은아무문제가없다.그

러나이미존재하는클래스들(예:PurchaseOrder클래스)에기반하여웹서비스를배포하

려고하면JAXB는유용성이떨어진다.이문제를해결하기위해서는두가지방법을5장에서

다룬다.첫번째방법은생성될클래스들을의도적으로변경하기위해서표준JAXB매핑을

커스터마이징하는것이다.이러한방법을통하여기존의PurchaseOrder클래스에어노테

이션을추가하여JAXB가그것을imported:po로매핑하게한다.4장에서보게되겠지만이

런방식의어노테이션사용은여러난관이많고원하는매핑을생성하는것이불가능하다.두

번째방법은가지고있는클래스들을JAXB로생성된코드들에매핑하기위해래퍼를사용하

는것이다.래퍼를사용하는방식은생성된Po클래스와기존의PurchaseOrder클래스간

의번역을위한자바코드를작성한다.래퍼작업은한번작성하면그코드에대한유지보수

를해야한다.래퍼방식의접근법은본질적으로자바/XML매핑을자바코드로저장하는것

에다름아니며,이는디버깅이어렵고변경에대한관리가복잡해지기때문에일반적으로추

천할만한방법이아니다.예를들어imported:po스키마가변경하면생성된Po클래스가

변경되고작성한래퍼코드또한업데이트해야한다.


이전JAX-RPC1.1에서의경험은우리에게교훈을남긴다.JAX-RPC1.1은지원되는타입

매핑에제한을둠으로써얻어진간소성은플랫폼을비실용적으로만든다는것을가르쳐주었

다.(JSR-109버전1.1－J2EE웹서비스의초기배포규약－과함께)JAX-RPC1.1에서는직렬

화컨텍스트가JAX-RPC매핑파일에정의되었다.매핑파일은배포도구로생성할수도있고

타입매핑을조정하기위해손으로직접작성할수도있다.이프레임워크에서는매핑규칙은

정의될수있으나java.lang.String과같은단순한자바타입과단순한타입의배열혹은

‘JAX-RPC밸류타입’이라고부르는JAX-RPC1.1명세5.4절에정의되어있는자바빈의특정

한타입에대해서만정의가가능하다.이러한제약조건은JAX-RPC1.1구현에있어서직렬

화과정을단순화하기위해서부여한것이다.불행히도많은실제시나리오에서는웹서비스

는‘JAX-RPC밸류타입’이아닌클래스에대한타입매핑을가지고배포되어야할경우가있다.

이러한한계는JAX-RPC1.1을웹서비스플랫폼으로서의유용성을제한해왔다.유사하게어

노테이션에기반한표준JAXB타입매핑메커니즘은JAX-RPC1.1에서의접근방식보다훨씬

간단하긴하지만여전히웹서비스로배포되는XML의구조를제한하고있고따라서JAXB의

웹서비스배포에적용할표준직렬화프레임워크로서의유용성을제한하고있다.

그러나대체로JAXB2.0은과도하게제한적이지않으며단순성과기능성사이의균형을잘

맞추고있다는느낌이다.JAXB2.0은자바/XML바인딩도구로써아주많은개발자들에의해

선택받고있다.

2.2.4 개발 모델

JWS는자바개발자들로하여금웹서비스개발을쉽게하게위해서설계되었다.그결과‘자

바로부터개발’방식으로편향되게되었다.‘자바로부터의개발’은자바클래스의개발을시작

함으로써웹서비스를생성한다는것을가정한다.사실그클래스를웹서비스로배포하기위

해해야하는작업은대부분@WebService어노테이션을그클래스에추가하는것이다.JAX-

WS와JAXB런타임엔진은표준WSDL/자바매핑과XML/자바매핑을통하여그클래스를

WSDL문서로매핑한다.‘자바로부터개발’방식에서는WSDL이나XML타입을손보고싶으

면클래스에어노테이션을추가하면된다.‘자바로부터개발’은WS-Metadata구현이요구하

는유일한개발방식이다.

다른방식으로는JWS가정의하는‘WSDL로부터개발’이있다.이방식을택하면이미존재

하는WSDL을가지고(JAX-WS구현의일부의형태로제공되는)WSDL컴파일러를통하여

WSDL을구현하는자바프로그램요소들을생성할수있다.이방식은WSDL에매핑되는SEI

의집합을얻게된다.해야할일은WSDL에정의된웹서비스를구현하기위하여적절한비

즈니스로직을가지고SEI들을구현하는것이다.


마지막으로JWS명세 11)는 ‘WSDL과자바로부터의개발’방식을언급하고있다.이방

식은이미존재하는WSDL을구현하려는자바클래스의@WebService어노테이션으로이

WSDL을참조하게한다.이클래스의어노테이션은클래스를참조하는WSDL로매핑하여야

한다.만약일치하지않는것이존재하게되면개발과정이나배포과정중에실패할것이다.

실제로이러한방식은대부분의프로그래머들에게까다롭게느껴질수있는데그이유는이

러한작업은어노테이션이WSDL을어떻게변형시키는지에대해서아주익숙해야만가능하

기때문이다.또한어노테이션을이용하여참조할WSDL에쉽게매핑하기힘든자바클래스

를가지고무의식적으로작업을시작할수도있다.이런방식으로하려면각벤더들이참조할

WSDL에대해자바클래스을매핑할수있도록어노테이션을어떻게활용해야하는지에대한

최선의방법을프로그래머들에게똑똑하게가이드해줄좋은도구를제공해야한다.

보다시피‘WSDL과자바로부터의개발’을할경우에는WSDL의구조를이미존재하는클

래스의자바메소드나파라미터로매핑하는것이배포작업할때문제가된다.경험상이것

은내부적이든비즈니스파트너와의것이든시스템통합을위해웹서비스를사용하려고하

는개발자들이가장흔히직면하는문제이다.통합을하는개발자들은흔히구현해야하는

WSDL로부터개발을시작한다(예:비즈니스파트너의e-비즈니스인터페이스를위한명세나

내부EAI프로젝트를위해필요한SOA서비스).또통합을하는개발자들은통상적으로이미

존재하는클래스에서개발을시작하기도한다(예:구매시스템).기존의시스템을WSDL에

부합하는웹서비스를통해앞단으로내세우는것은프로그래밍에있어서의난제이다.

‘WSDL과자바로부터의개발’문제는아주커스터마이징이잘되는직렬화하부시스템없이

는우아하게풀수있는문제가아니라는것을알아야한다.‘WSDL과자바로부터의개발’방

식에서는이미존재하는자바객체(파라미터와반환타입)에매핑되어야하는XML스키마타

입을가지고있다.그래서직렬화문제를단순화시키려하는(예를들자면JAX-RPC1.1에서와

같이표준직렬화컨텍스트를정의하는방법을통해서)대부분의웹서비스플랫폼은‘WSDL

과자바로부터의개발’문제를풀기위한래퍼코드에대한필요성을소개하는것으로마친다.

래퍼코드는이미존재하는WSDL과XML스키마문서의표준자바표현을이미존재하는클

래스로옮기기위해필요하다.실제로는이방식이‘WSDL과자바로부터의개발’문제를풀기

위해가장널리쓰이는방식이다.개발자들은‘WSDL로부터의개발’방식에따라서이미존재

하는WSDL로부터SEI를생성하기위해서JAX-WSWSDL컴파일러를사용한다.그러고나서

이SEI는래퍼를통해서이미존재하는클래스에매핑이된다.

11) [JSR181]2.0절을참조.


한편으로는‘WSDL과자바로부터의개발’방식이실제로는가장처리하기쉬운방식인경우

가존재하는데,이것은WSDL과자바가모두정의되어있는경우개발자들은설계작업에신

경쓸필요가없기때문이다.즉개발자들은유연하면서유용한WSDL과좋은자바API를설

계할필요가없는것이다.이것은설계자관점에서는그렇긴하지만개발자관점에서는‘WSDL

과자바로부터의개발’방식은JWS도구를사용하는가장풀기어려운문제이다.JWS는자바

로부터유효한WSDL을생성할수있으며XML스키마로부터자바클래스를컴파일할수있

지만이미존재하는자바를기존의XML스키마와WSDL로매핑해야하는작업에는그다지

도움이되지못한다.

JWS도구의이런어려움들때문에웹서비스를개발하고배포하는데있어서가장좋은방

법은이미작업할WSDL과자바클래스들을가지고시작한다고가정을하는것이라고생각한

다.개발자로서‘WSDL과자바로부터개발’문제를푸는법을익힌다면나머지두가지개발

방식은훨씬쉽다.그것은바로‘WSDL과자바로부터개발’을하는것은JWS의자바/XML바

인딩(JAXB)과자바/WSDL매핑(JAX-WS)의상세부분을배우게하는것이기때문이다.부가

적으로‘자바로부터의개발’과‘WSDL로부터의개발’방식의한계점을인식하는것을배우게

될것이고,미래의문제들을야기할수있는웹서비스구조를만드는것을피할수있다.

2.2.5 JWS 타협점Trade-Off

이전에논의한대로각각의JWS의단순화는유용한웹서비스를생성하고배포하는웹서비스

플랫폼의능력과의타협을통해얻어진다.예를들면JWS의‘자바로부터의개발’방식은웹서비

스를배포하는것을쉽게만들어주지만그웹서비스의유용성은어떨까?여러분의회사나산업

XML스키마의표준타입과호환이될까?이러한(JAX-WS,JAXB,WS-Metadata와WSEE에대한)

타협점들에대해서3~10장에서논의한다.11장에서는이러한타협점에관한문제들을풀기위

해‘WSDL과자바로부터의개발’방식에초점을둔다른설계방식에대해살펴보고,관리에관

한문제들을소위‘WSDL-중심’개발방식을채용함으로써훨씬풀기쉽게만들것이다.

3~10장에들어가기전,그리고JWS상세에대해서좀더설명하고분석하기전에이장의

나머지부분에서는JWS프로그래밍모델의개관에대해서알아볼것인데,이것은JWS프로

그래밍모델이1장1.2절에서설명하는일반적인웹서비스플랫폼구조와연관되기때문이다.

JWS안에는강력한기관들이많이있으므로더잘이해하면할수록웹서비스를개발할때의

난제들을해결하는데유용한더많은도구들을가지게될것이다.


2.3 JAX-WS 2.0

JAX-WS2.0은JWS의호출하부시스템과배포하부시스템의일부,그리고약간의직렬화하

부시스템을규정한다.또JAX-RPC1.1에대한후속명세로서많은개선점을제공하고있다.

JAX-WS는많은기능들을제공하는데표2.1은1장1.2절에서설명한웹서비스플랫폼구

조의어떤부분에그러한기능들이적용되는지보여준다.이절에서는표2.1에수록된각각

의기능들에대해설명한다.

표 2.1 JAX-WS 기능 표

호출 직렬화 배포

동적/정적클라이언트

자바인터페이스프록시를이용한호출

XML을가지고호출

메시지컨텍스트

핸들러프레임워크

SOAP바인딩

HTTP바인딩

예외Exception를SOAP결함Fault로의변환

비동기호출

단방향One-way호출

클라이언트측의스레드관리

유사 참조 전달Pseudo

ReferencePassing

WSDL스타일－RPC/Literal과Document/LiteralWrapped방식의지원

자바/WSDL매핑

정적인WSDL

XML서비스제공자

XML카탈로그

런타임 엔드포인트 공개(JavaSE에서만)


2.3.1 자바/WSDL 매핑

JAX-WS2.0명세[JSR224]는표준자바/WSDL매핑을정의한다.이표준자바/WSDL매핑은

JWS배포하부시스템의일부분이며,WSDL의오퍼레이션들이어떻게자바메소드로연결되

는지를결정한다.즉,SOAP메시지가WSDL의오퍼레이션을호출하면자바/WSDL매핑은

어떤자바메소드가호출이되는지와SOAP메시지가어떻게메소드의파라미터로매핑이되

는지를결정한다.역으로,매핑은또어떻게메소드의반환값이SOAP응답으로매핑되는지

결정한다.

이표준매핑은자바클래스로부터시작하여이를JAX-WS프로세서(보통java2wsdl이

나wsgen과같은이름을가진도구)를통과시켜웹서비스엔드포인트에대한WSDL설명

을생성하게해준다.개발자는2.5절의WS-Metadata논의에서설명된대로자바코드에어

노테이션을추가하여생성될WSDL의형태에영향력을행사할수있다.생성된WSDL은항

상WS-IBasicProfile1.1 [WS-IBP1.1]을만족하여야한다.이것이 ‘자바로부터의개발’

방식이다.

역으로WSDL문서로부터시작하여자바클래스와인터페이스를생성할수있다.표준매

핑은내장된바인딩선언(jaxws:bindings확장요소를사용하여WSDL원본에작성된어

노테이션)이나선언을포함하는외부바인딩파일을제공함으로써표준매핑을커스터마이

징할수있다.이런방식으로얻게되는자바클래스들은래퍼클래스들이며,개발자들은웹

서비스를구현하기위해요구되는비즈니스로직을채워야한다.이런방식으로생성되는자

바클래스들은WSDL/자바매핑을설명하는소스코드어노테이션을가지고있다.생성된어

노테이션을가진클래스들을배포하여그결과로나타나는웹서비스는,“매핑프로세스중에

WSDL문서안에입력으로준정보들을신뢰할수있게반영하게된다” 12)그래서개발자가

그렇게생성된클래스들을배포하게되면처음작업을시작했던것과완전히동일한WSDL을

얻지못할수도있으나기능적으로는동일하게된다.이것이‘WSDL로부터의개발’방식이다.

일단배포작업에이르게되면‘WSDL로부터의개발’방식과‘자바로부터의개발’방식은완

전히동일하다고보아도된다.JWS는웹서비스에대한자바중심의접근방식이다.WSDL로

부터시작할경우에도,JAX-WS를사용하여이WSDL을어노테이션이달린자바소스로변환

하며,이변환된소스는배포하려는웹서비스의JWS구현체내부정의가된다.JAX-WS에서

는WSDL로부터자바클래스가생성되므로,WSDL을인터페이스정의언어InterfaceDefinition

Language;IDL로간주한다.런타임에전시되는실제WSDL은어노테이션으로부터얻어진다.

12)　JAX-WS2.0명세,2장[JSR224]


어노테이션은WSDL의형태를결정하는데있어서아주큰유연성을제공하지만(예를들면

자바메소드의파라미터를SOAP헤더의요소로매핑하게할수도있다),WSDL/자바매핑의

몇가지기본원칙에있어서는유연하지못하다.

WSDL 포트 타입은 자바 인터페이스로 매핑된다:wsdl:portType요소는서

비스엔드포인트인터페이스SEI라고하는자바인터페이스로매핑하여야한다.

이것은매핑단위의제약이다.하나의포트타입에존재하는개개의오퍼레이

션들을다른자바인터페이스로매핑할수는없다.JWS모델은SEI와포트타

입간에1-1매핑을강제한다.포트타입을구현하기위해서는SEI를배포해야

한다.

파라미터와 반환 타입의 매핑은 JAXB와 호환돼야 한다 :어노테이션은SEI

파라미터와반환타입간에특정타입매핑을규정할수있게한다.그러나타

입매핑들은JAXB2.0에호환돼야한다.즉,SEI파라미터와반환타입에사용

된클래스들은자기들이매핑될XML스키마컴포넌트들을규정하기위해서

JAXB어노테이션을사용하여야한다.

2.3.2 정적 WSDL

JAX-WS에서는개발자들은정적인WSDL문서를규정할수있는데,이를통해서표준WSDL/

자바매핑혹은XML/자바(JAXB)매핑에근거하여자동으로WSDL을생성하는작업을건너

뛸수있다.이특성은특정한WSDL에부합해야하는웹서비스를공개할필요가있을때－

SOA방식의시스템봉합을진행하는데있어서흔히만날수있는경우이다－아주중요하다.

이특성은또한WSDL을JAXB로생성한타입이아니라특정스키마(예를들면기존의po:

purchaseOrder요소정의)에근거해서공개하는것을가능하게한다.이정적WSDL접근

방식은‘WSDL과자바로부터의개발’에사용된다(2.2.4절참조).

2.3.3 동적 클라이언트와 정적 클라이언트

JAX-WS웹서비스클라이언트는javax.xml.ws.Service객체이다.Service객체는목표

로하는웹서비스WSDL문서의wsdl:service요소에매핑된다.Service객체는동적으

로혹은정적으로생성이가능하다.동적으로생성할경우에는Service는Service.create

팩토리메소드들중하나에의해런타임에생성된다.다르게는개발시점에JAX-WS벤더에

의해서제공되는JAX-WS처리도구(예를들면글래스피시의wsimport)를이용하여WSDL

문서로부터Service클래스의서브클래스를생성할수도있다.

▒

▒


2.3.4 자바 인터페이스 프록시를 통한 호출

동적으로혹은정적으로생성된Service객체는서비스엔드포인트인터페이스SEI를사용

하여웹서비스를호출하는프록시를생성할수있다.Service.getPort메소드들중하

나를가지고,목표로하는wsdl:port로연결되는SEI의객체를만든다.물론사용되는SEI

는JAX-WS의자바/WSDL매핑과JAXB의XML/자바매핑에부합되어야한다.이러한이유

로SEI프록시를사용할경우에는런타임이전에JAX-WS처리도구(예를들면글래스피시

의wsimport)를가지고목표WSDL을컴파일할때SEI와함께만들어지는정적으로생성된

Service객체를통상적으로함께사용한다.

2.3.5 XML로 호출

자바프록시를통한호출에대한대안으로,Service객체를사용하여XML메시지를보내고

받는형태로웹서비스를호출할수있다.이경우Service는createDispatch메소드들중

하나를사용하여javax.xml.ws.Dispatch의객체를제공한다.이방식은JAXB직렬화과

정을건너뛰게되므로유용할수있다. 13)이렇게SOAP메시지를임의로구성해서웹서비

스로바로전송할수있게해준다.또한자바부터의혹은자바로의변환과정없이XML을통

하여직접적으로웹서비스와상호통신하는것을가능하게해준다.웹서비스프로그래밍작

업을하다보면종종문제해결에있어XML을직접다루는것이가장자연스런방법이라는

것을알게될것이다.이방식을지원하게해준JAX-WS설계자에게영광을!(JAX-RPC에서는

지원되지않았다)

2.3.6 XML 서비스 프로바이더

XML메시지를가지고웹서비스를호출하는것이이제가능하므로(2.3.5절참조)JAXB어노

테이션이달린클래스들로의자동화된바인딩을제공하지않고단순하게XML메시지를보

내고받는서비스를배포하는것이가능하다.JAX-WS는javax.xml.ws.Provider인터페

이스를통해서이기능을제공한다.서비스가Provider인터페이스를통해서생성되면SEI

를사용하지않으며,JAX-WS의자바/WSDL매핑과JAXB의자바/XML매핑작업을건너뛰

게된다.Provider인터페이스는직접적으로XML요청및응답메시지를가지고동작하는

서비스를작성하는것을가능하게해준다.JAXB형태가아닌타입매핑을사용하는서비스를

배포하는데있어서이접근법을어떻게활용할수있는지에대해서는7장에서설명한다.

13) 6장에서는JAXB직렬화과정을건너뛰기위해Dispatch를어떻게사용하는지에대한예제를제공한다.


2.3.7 핸들러 프레임워크

JAX-WS는클라이언트측과서버측양쪽모두에서사용될수있는요청및응답핸들러를정

의한다.핸들러는메시지의전처리와후처리를담당한다.예를들면클라이언트메시지를호

출하고자하는웹서비스로보내기전에인증에관련된헤더를달거나하는메시지후처리작

업을하는곳에핸들러를사용할수있다.서버측에서는메시지가호출하고자하는서비스로

보내지기전에인증헤더를검사하는전처리작업을위하여핸들러를사용할수있다.

JAX-WS핸들러는핸들러체인이라고하는순서가있는리스트의형태로구성되어순서대

로호출된다.핸들러는클라이언트측과서버측모두에서XML메시지와메시지의컨텍스트

(2.3.8절참조)에대해읽기/쓰기접근을가지고있다.핸들러체인은배포에관련된메타데

이터(즉,@javax.jws.HandlerChain)를사용하여설정한다.클라이언트측에서는핸들러

체인을HandlerResolver인터페이스를사용하여런타임에설정할수있다.

핸들러는모두포트레벨에서정의되므로SEI에서정의된메소드들은모두같은핸들러체

인을사용하여야한다.이는클라이언트와서버측의호출모두에적용된다.

JAX-WS는로지컬핸들러와프로토콜핸들러라는두가지타입의핸들러를정의한다.로

지컬핸들러는XML메시지처리에관계하며프로토콜바인딩과는독립적이다.프로토콜핸

들러는반대로연관된프로토콜바인딩(예를들면SOAP)을처리하도록설계되었다.예를들

면SOAP프로토콜핸들러 14)는SAAJAPI [JSR67]를통해서메시지의SOAP구조체에접근

할수있다.동일한핸들러체인에서로지컬핸들러 15)는메시지페이로드가javax.xml.

transform.Source나JAXB어노테이션이달린클래스객체이어야접근할수있으며SAAJ

API를통해서는불가능하다.

@HandlerChain어노테이션을사용하여핸들러를배포할경우에는‘핸들러체인파일’이라

고부르는설정파일들을필요로한다.WSEE[JSR-109]는핸들러체인파일사용에관한내용

을포함하면서핸들러의배포모델에대해규정한다.

14) javax.xml.ws.handler.soap.SOAPHandler<T extends SOAPMessageContext>

15) javax.xml.ws.handler.LogicalHandler<C extends LogicalMessageContext>


2.3.8 메시지 컨텍스트

JAX-WS에서는핸들러와엔드포인트,그리고클라이언트에서XML요청/응답메시지와함께

옮겨다니는메시지컨텍스트(javax.xml.ws.handler.MessageContext)를조작하는것

이가능하다.이것은유용한도구인데,그예로요청핸들러와엔드포인트구현,그리고응답

핸들러간의통신과같은것을가능하게해준다.메시지컨텍스트의사용법을이해하려면메

시지의일렬화(예:웹서비스신뢰성메시지[WS-RM]와같은경우)같은작업형태를구현하

려할때,SOAP헤더요소에서부터특정한순서로메시지의배열을꺼내는요청핸들러를가

지고있다고가정해보자.이런경우메시지를동시다발적으로처리하는엔드포인트에서는

일렬화된메시지가모두처리되기전까지는응답은내보내고싶지않을것이다.이경우엔드

포인트에서의처리이긴하지만,응답메시지의순서를매기는것은요청핸들러가메시지컨

텍스트에넣어둔일련의순서정보에근거하여결정될수있다.

엔드포인트구현은의존성주입(2.7.1절참조)을통해메시지컨텍스트에접근이가능하다.

클라이언트에서는 BindingProvider 인터페이스의 getRequestContext,

getResponseContext메소드를사용하여메시지컨텍스트에접근할수있다.이러한기능은

특정프로토콜기반기능의초기화작업에유용하게사용될수있다.엄격히말하면이것은웹서

비스에서다루는영역이아니지만매우유용하다.예를들어클라이언트메시지컨텍스트에서사

용자이름과암호를설정함으로써HTTP인증작업을할수있게해준다.

2.3.9 SOAP 바인딩

JAX-WS2.0은SOAP메시지처리를위한SOAP바인딩을정의한다.mustUnderstand처

리와SOAP1.2의next 16)와ultimateReceiver 17)에대한지원이여기에포함된다.

SOAP바인딩은SOAP핸들러(프로토콜핸들러의확장－2.3.3절참조)도지원한다.SOAP

바인딩은핸들러예외상황과서비스예외상황을SOAP결함메시지(2.3.11항참조)로매

핑한다.WS-Metadata의어노테이션들(2.5.2절참조)은이SOAP바인딩을임의대로조정

할수있게해준다.

JAX-WS구현은SOAPHTTP바인딩,첨부가붙은SOAP과SOAPMTOM을지원해야한다.

16) SOAP1.1에서는nextactor가같은의미이다.

17) SOAP1.1에서는actor속성을생략함으로써같은의미가된다.


2.3.10 HTTP 바인딩

기존의SOAP바인딩에추가적으로,JAX-WS에서는REST프레임워크[Fielding]를사용하여

정의된웹서비스의배포와사용을가능하게하기위해XML/HTTP바인딩을제공한다.그런

서비스를흔히RESTful이라고하며,SOAP을사용하지않고XML을HTTP상으로송수신한다.

HTTP바인딩은JAX-WS로하여금RESTful웹서비스를배포하고사용할수있게해준다.3

장에서는RESTful서비스를JAX-WS와HTTP바인딩을사용하여구현하는방법을설명한다.

2.3.11 예외 상황의 SOAP 결함으로의 변환

JAX-WS가자바인java.lang.Exception을SOAP결함메시지로매핑하는것은매우유용

하다.Provider인터페이스(2.3.6절참조)를사용하여RESTful서비스를배포하는경우라

할지라도JAX-WS런타임은Exception객체를클라이언트에반환되는SOAP결함메시지로

매핑할수있다.자바예외상황의WSDL의결함으로의매핑은WebFault어노테이션을통해

서제어가가능하다.이기능은서비스의예외상황을SOAP결함으로매핑시키는코드를작

성해야하는필요성을없애줌으로써많은시간과노력을절약해준다.물론결함처리과정을

커스터마이징하려고한다면JAX-WS핸들러를통해서가능하다. 18)나는SOA-J에서,전체적

으로자바/WSDL매핑과JAXB직렬화메커니즘을사용하지않는경우에도JAX-WS결함처

리를활용한다.

자바예외상황을SOAP결함으로변환하는JAX-WS방식에는비평이있어왔다.주요비

평내용은,자바로구현하지않아자바와는상관이없는웹서비스소비자에게는잠재적인혼

란을야기하면서,자바와관련이있는상세한구현내역을웹서비스의영역에포함시킨다

는것이다.이것은엉뚱하다고여겨진다.SOAP메시지구조나혹은내용에문제가있어서웹

서비스에서던진자바예외상황은자바에특정된예외상황이아니다.이런예외상황들을

WSDL의결함메시지로번역하는것은큰의미가있다.반대로어떤자바런타임의문제(예:

ClassCastException을던지는상황)때문에예외상황을던지는경우라면WSDL상의결함

메시지로변환해서는안된다.

즉,좋은코드작성을통해자바에특정되지않은SOAP결함메시지로재해석하면서자바

내부문제인예외상황을잡게할필요도존재한다.다른한편으로는애플리케이션에특정한

예외상황을JAX-WS의SOAP결함처리메커니즘으로전달하는것이안전하다.

18) 7장7.5절에서는,핸들러를통해SOAP결함처리를구현하는방법을보여주는프로그래밍예제를제공한다.


2.3.12 비동기 호출

JAX-WS는JAX-RPC1.1에정의된호출모델에비동기지원을추가하였다.이는기업용자바

에있어서아주큰진보인데,그것은비동기성이SOAP에있어서아주근본적인요구사항이

기때문이다.

그러나더좋은사실은JAX-WS가폴링Polling과콜백Callback방식의두가지의비동기요청

-응답메시징방식을지원한다는것이다.폴링방식은클라이언트코드가응답이도착했는지

응답객체를주기적으로검사하는것이가능하다.대신에콜백방식에서는응답이가용한상

황일때응답을비동기적으로처리할수있는핸들러를정의한다.비동기콜백방식은자바

메시지서비스JMS[JSR914]의임시메시지큐에서비동기적으로돌아오는응답을처리하기

위해리스너를정의하는것과아주유사하다.리스너는응답하는서비스가응답을가지고다

시부를때호출된다.폴링방식은응답이도착하길기다리면서임시큐를주기적으로검사하

는것과유사하다.

2.3.13 단방향 오퍼레이션

JAX-WS2.0은자바메소드를WSDL의단방향오퍼레이션으로매핑하는것을지원한다.이것이

중요한기능인이유는JMS와유사한메시지를전송하고잊어버리는방식이면서HTTP상의SOAP

에기반한방식이기때문이다.단방향오퍼레이션은개발자로하여금신뢰성메시지프로토콜(예

를들면,웹서비스신뢰성메시지전송[WS-RM])을지원하는것을용이하게해준다.신뢰성메시

지전송은,메시지방식의웹서비스에기반하여느슨하게결합하는응용프로그램을만드는것－

이는SOA설계의주요목표이다－을가능하게하는플랫폼으로JWS를사용가능하게해준다.

2.3.14 클라이언트 측의 스레드 관리

java.util.concurrent.Executor의객체를JAX-WS클라이언트(즉,javax.xml.ws.Service

객체)에서설정하여사용자의스레드제어가가능하게할수있다.이기능은비동기웹서비

스호출을할때,개발자가스레드의생성과사용에대해제어할수있게해준다.사용예로는

성능향상을위해서사용자스레드풀링을구현하는것을들수있다.비동기호출에대해서

더알고싶으면2.3.12항을참고한다.

2.3.15 WSDL 스타일 - RPC/Literal과 Document/Literal Wrapped 스타일의 지원

JAX-WS는JAXB로직렬화작업을위임한다.그러나직렬화된파라미터들을SOAP메시지로

담기위해서는JAXB는JAX-WS로부터어떤가이드가필요하다.그가이드는배포된웹서비


스가채용한WSDL의스타일에따라다르며,그스타일은웹서비스가배포될때결정된다.

예를들면,파라미터들은SOAP바디요소의각각의자식요소로따로포장되거나(Unwrapped

방식)바디의하나의자식요소로묶어감쌀(Wrapped방식)수있다.

JAX-WS는WS-I에호환하는두가지의가장인기있는WSDL스타일－RPC/Literal과

Document/LiteralWrapped방식－을지원한다 19).RPC/Literal방식은JAX-WS에서는‘RPC’

방식이라고한다 20).이방식은javax.jws.SOAPBinding어노테이션을사용하여몇가지

속성과함께설정하며,그속성들은style은RPC,use는LITERAL,그리고parameterStyle

은WRAPPED가된다.Document/LiteralWrapped방식은 JAX-WS에서는 ‘Document

Wrapped’라고한다 21).이방식은javax.jws.SOAPBinding어노테이션을사용하여다

음속성들과함께설정하는데,그속성들은style은DOCUMENT,use는LITERAL,그리고

parameterStyle은WRAPPED가된다.

WSDL의스타일은다양한멀티플랫폼환경(예를들면자바와.NET환경)에걸쳐있는웹

서비스상호운영성에있어서중대하면서도혼란스러운주제이다.이주제는4장,4.3절에서

깊이다룬다.

채용된WSDL의스타일을근거로하여,JAX-WS는각각의메소드에대해서요청빈Bean과

응답빈이라는두개의빈을정의한다.이빈들은본질적으로는요청파라미터와응답값들의

래퍼이다.JAXB에의해서직렬화되면,요청빈과응답빈은각각올바른SOAP요청메시지

몸체와SOAP응답메시지몸체를생성한다.

2.3.16 XML 카탈로그

JAX-WS는XML카탈로그－OASISXMLCatalogs1.1명세를포함한다－를지원한다.이는

4장에서논의한대로WSDL문서가외부스키마를가져오게쉽게하여,표준타입을사용

할때마다각각의WSDL문서가같은스키마정보를중복하여보관하지않아도되게도와주

는훌륭한기능이다.스키마를가져올때의어려운점은런타임에발견할수있을까하는것

이다.스키마를로컬에있는HTTP서버에올려야할까?물론그럴순있지만URL이http://

localhost/myschema.xsd와같이된다면다른기계상에서는제대로동작하지않을것이다.

XML카탈로그를통해서들여오는스키마의외부참조를같은스키마의로컬객체로매핑

할수있다.패키징을제대로한다면(예를들면응용프로그램jar파일에스키마를더하는것),

19) Document/Literal/Bare타입도지원하지만,WS-I호환방식은아니다.

20) [JSR224]의3.6.2.3절을참조하라

21) [JSR224]의3.6.2.1절을참조하라.


로컬의객체는런타임의컨텍스트클래스로더에의해서접근가능해야한다.8장의8.7절에

서는XML카탈로그사용법을설명하는예제를제공한다.

2.3.17 가참조Pseudoreference의 전달(출력과 입/출력 파라미터 Holder<T>)

자바메소드의호출에서는객체에대한참조가값으로전달된다.자바메소드호출에서

Purchase의객체를넘길때,받아들이는객체가얻는값은PurchaseOrder에대한참조이

지,PurchaseOrder에대한복사본이아니다.웹서비스는이런방식으로동작하지않는다.

PurchaseOrder가웹서비스로넘겨지면,객체의직렬화된복사본이SOAP메시지로포장되

어전송망으로보내진다.

참조를전달하는것은(청구지주소를정규화하는것과같이)PurchaseOrder객체의

상태를변경하는메소드를호출하려고하는경우에유용하다. JAX-WS2.0은Holder클

래스를이용하는가참조전달메커니즘을제공한다.물론SOAP을가지고로컬주소공간

에존재하는PurchaseOrder에대한참조를실제로전달할수는없지만, JAX-WS는마

치그런것들을하고있는것처럼보이게해준다.이것은Holder<PurchaseOrder>클래

스를PurchaseOrder에대한참조로사용함으로써가능하다.웹서비스를호출하는동

안에 JAX-WS는PurchaseOrder에대한복사본을목표서비스로보내고,그것의변경

된버전(예를들면정규화된청구지주소)을돌려받게된다.그내막을살펴보면 JAX-

WS는 Holder<PurchaseOrder>객체를업데이트하여웹서비스로부터돌려받은

PurchaseOrder 객체를참조하게한다.

이메커니즘은문제없이동작하지만그값에대해서는정확성이의심되며,위험할수도있

다고보여진다.PurchaseOrder객체를참조하는또다른객체들을가지고있다고가정해보

면,이객체참조들은웹서비스호출의결과로는업데이트되지않으며,Holder클래스의객

체만이업데이트된다.그러므로이참조들은이제는유효하지않으며수동적으로업데이트

해주어야한다.내견해로는Holder개념은(입력/출력파라미터,응답값과는다른출력파

라미터와더불어)잘못안내되고있다.웹서비스로객체의참조를전달할수는없으며,마치

할수있는것처럼보이게노력하는것은혼란을가중시키는,에러가상존할수있는코드를

만들어내게된다.

2.3.18 런타임 엔드포인트의 공개(Java SE 한정)

JAX-WS는런타임에웹서비스엔드포인트를공개하는것을가능하게하는기능을제공한

다 22).간단한API(javax.xml.ws.Endpoint)를통해서웹서비스를구현한객체를특정

22) 보통,호출가능한엔드포인트를생성하는것은배포단계에서이루어진다.


URL에배정할수있다.

런타임의엔드포인트공개는아주인상적이다－개인적인견해로는JAX-WS의가장멋진기

능중에하나다.불행히도JavaEE5에서는WSEE[JSR109]에의해서허용이안되게되었다.

WSEE의5.3.3절에보면“이기능을사용하는것은,관리환경에서이식성이없는것으로non-

portable간주된다.서블릿과EJB컨테이너모두엔드포인트를동적으로공개하는것을허용하

지않아야…”라고되어있다.

이런뛰어난기능을JavaEE5컨테이너에서지원할수있는해결책을찾기위해전문가단

체ExpertGroup의모임이소집되었더라면하는생각이있는데,그이유는특히이러한기능이

‘사용자편의성’이라는JavaEE5에서설정된목표와일맥상통하기때문이다.잘되면Java

EE의추후버전에서볼수있을것이다.

아무튼좋은소식은JAX-WS가규정한동적엔드포인트공개메커니즘이JavaSE6 23)에

서부터지원된다는것이다.JavaSE6의이러한기능들을어떻게사용하는지에대한자세한

프로그래밍예제를7장,7.7절에서제공한다.

다음일부분의코드에서엔드포인트API의힘과단순함을알수있다:

MyServiceImpl myWebService = ... // 웹 서비스 생성

Endpoint myEndpoint = Endpoint.publish("http://javector.com/myService",

myWebService);

JAX-WS런타임은필요한서버인프라를생성하는것을책임진다.이것에는HTTP컨텍

스트를생성하는것과특정URL에대한SOAP요청을듣는것이포함된다.이러한단순한

접근법을사용할때는,MyServiceImpl에포함된소스코드어노테이션이나Endpoint.

setMetadata 메소드를이용하여배포된메타데이터문서를기반으로엔드포인트

에대한WSDL약정이생성된다.WSDL에대한기본위치는http://javector.com/

myService?wsdl이다.

추가적인엔드포인트메소드는(SOAP1.1/HTTP와다른바인딩을사용하고싶다면)바인

딩과서버컨텍스트에대한임의조정을가능하게해준다.JAX-WS는또한동시다발적인요

청에대해서어떻게서비스할것인지를제어하기위해엔드포인트마다맞춤Customjava.

util.concurrent.Executor객체를설정하게한다.이것은병행성concurrency이나성능에

대한목적으로스레드관리를최적화할필요가있을경우에훌륭한기능이다.

23) JavaSE6는http://java.sun.com/javase/6에서다운로드가가능하다.


2.4 JAXB 2.0

2.3절에서는JAX-WS명세에서가장흥미있고중요한기능이라고생각되는것들을집중적으

로다루었다.이기능들에대해서는앞으로여러장들에걸쳐서더깊게다루며,특히6장과7

장은각각JAX-WS의클라이언트와서버측에대해초점을맞추고있다.

이절에서는,JAXB2.0의중요하면서도흥미있는기능들에초점을맞춘다.JAXB2.0은자

바표현으로부터XML스키마컴포넌트로의,혹은그역으로의변환을위한표준자바/XML

바인딩을정의한다.여기에는쉽지않은문제가존재한다.XML스키마는복잡하면서도표현

적인언어이다.자바도마찬가지다.이런언어들사이에서의표준바인딩을구현하는것은크

고복잡한작업이다.이에대한명세가370쪽이넘어간다는것은놀랄일이아니다.

JAX-RPC는JAXB1.0과무관한본연의자바/XML바인딩을정의하였다.JAX-WS2.0(JAX-

RPC의계승자)는더이상자바/XML바인딩에대해정의하지않는다.그작업은JAXB2.0으

로이관되었다.

이책의목표는JAXB에대한포괄적인프로그래머가이드를제공하는것이아니다.그보다

는웹서비스로의적용－JAX-WS2.0에서자바/XML바인딩프레임워크로의역할－으로범

위를좁혀서초점을맞춘다.이번절에서는JAXB가어떤문제들을해결할수있고,1장1.2절

에서설명한웹서비스플랫폼구조에적용되는지알아본다.더블어JAXB의특성을정의하는

기능들－즉,어떤부분에는잘되지만,다른부분에서는잘안되는기능들－을주의깊게살

펴볼것이다.4,5장에서는JAXB2.0와연관하여더많은상세한내용들과프로그래밍예제

들을제공한다.

JAXB2.0에대한논의를시작하기위해자바/XML바인딩이라는용어와이와연관된자바

/XML매핑,그리고타입매핑 24)이라는용어를어떻게사용할것인지에대해명확하게정의

하는것이도움이된다.타입매핑은자바프로그래밍요소와XML스키마컴포넌트사이의

관계(예:corp:AddressType과samples.Address)를정의할때사용한다.타입매핑은

직렬변환기와역직렬변환기에의해구현된다.직렬변환기는자바클래스의객체를스키마에

부합하는XML객체로변환한다.역직렬변환기는그반대의상황을수행한다.타입매핑은쌍

<J,X>으로간단하게표현할수있다.여기에서J는자바프로그램요소이고,X는XML스키

마컴포넌트이다.그자체로는(즉,직렬변환기와역직렬변환기가없이는)타입매핑이어떻게

구현되는지에대해논할수없다.

24) 내가알기로는,일반문건에서는-심지어자바언어명세에서조차도-이런용어들의사용에일관성이없다.여기설명된용어정

의들은용어사용에있어혼선을빚지않기위해내가정한것이다.


여기서는자바/XML맵을타입매핑의집합이라고정의한다.이것은반드시함수일필요는

없는데,다른말로하자면,같은자바클래스라도두가지의다른XML스키마타입으로매핑

될수있다는것이다.자바/XML맵이각각의자바프로그래밍요소를유일한XML스키마컴

포넌트로보낸다면(즉,함수로정의된다면)자바/XML바인딩이라고부를것이다.

이렇듯바인딩을자바클래스가스키마컴포넌트를유일하게표현하는맵으로정의하는것

이상으로,타입매핑프레임워크가직렬화를바라보는관점을권장하는방식과,바인딩프레

임워크가직렬화를바라보는관점을권장하는방식에는차이가있다.바인딩을통해작업하

는프로그래머들은자바클래스를어떤스키마타입이나요소의표현방식이라고생각하는

경향이있다.즉,바인딩관점에서는자바클래스는자바클래스가연동된스키마를의미한다.

그리고그러한바인딩은스키마객체를다루는데있어서고수준의API(예:DOM보다고수준)

로간주된다.

반대로,타입매핑프레임워크로작업하는프로그래머들은자바클래스가특정스키마컴

포넌트를나타낸다고(혹은특정스키마요소에연동된다고)생각하는것은권장되지않는다.

그보다는,타입매핑은단순히자바라는세상에서XML이라는세상으로의가교역할을하는

것이다.이런관점에서는자바클래스는단순히상응하는XML요소를의미하기위해존재하

는것이아니다.그보다는,자바클래스는기존시스템(예:구매)안에서기능을수행하고,필

요한경우에다른시스템과데이터를교환하기위해적절한XML형태로(로부터)직렬화될

수있다.

이런용어정의를통해보면,JAXB2.0은자바/XML바인딩도구로생각하는것이최선이다.

그것은JAXB2.0이사용하는자바클래스에추가되어있는어노테이션이바인딩을정의하기

때문이다.각각의클래스는어노테이션을근거로하여유일한XML스키마컴포넌트로매핑

된다 25).5장5.1절에서는바인딩과매핑의차이에대해서더자세히논의한다.

이절을읽을때,JAXB2.0명세는자바개발자들이XML스키마의객체를가지고작업하는

것을쉽게하려고XML스키마의자바바인딩을제공하고있다는것을명심해야한다.JAXB

2.0의목적은SAX,DOM혹은XPath의자바구현보다더상위수준의추상화를제공하거나

XML을자바프로그래밍언어에서다루는다른접근방법을제공하는것이다.바인딩은,여러

자바클래스들을XML스키마와연관시켜XML스키마객체들을자바메소드를사용하여다

룰수있도록함으로써,이러한메커니즘을제공한다.

25) 이것은@XmlRootElement 어노테이션의경우에는약간사실과다르다.이렇게어노테이션이달린클래스는XML스키마

타입과,그타입의전역요소,두가지모두정의할수도있다.그러나기본적인개념은여전히유효하다.하나의자바클래스에

두가지의어노테이션을적용(하여두가지의타입매핑을정의)할수는없다.


JAXB2.0의저자는바인딩이일어나는두가지의시나리오를그린다.

자바로부터 시작:이시나리오에서는,자바클래스는이미존재하고있으며

JAXB2.0스키마생성기를통해서XML스키마를생성하는데사용된다.클래

스들에명시적으로어노테이션을추가할필요는없는데,그이유는JAXB2.0

은어디든필요한곳에암시적인어노테이션을제공하기위해디폴트값을정

의하기때문이다.

XML 스키마로부터 시작:이시나리오에서는스키마가먼저존재하고데이터

바인딩에쓰이는자바클래스들이JAXB2.0스키마컴파일러를통해서생성

된다.

두경우중어떤경우도SOA스타일의통합문제에접근할때주로맞닥뜨리게되는‘XML

과자바로부터시작’상황을처리할수있도록설계되지않았다는것에주목한다.그런시나

리오에서는통상적으로,사용하길원하는XML스키마또는최소한의어떤공통표준XML타

입을가지고있다.또한웹서비스인터페이스와함께전면에내세우려고하는기존의자바

클래스를가지고있다.따라서,여기서의난점은이미존재하는XML스키마를이미존재하고

있는자바클래스로매핑하는것이다 26)－‘XML과자바로부터시작’문제이다.JAXB2.0에서

정의된것과같은통합시나리오에서는기존의자바/XML바인딩을적용하는것보다는자바

/XML매핑을정의하는것(과그타입매핑을구현하는직렬변환기)에관심이있다.한가지

차이점은하나의XML스키마로매핑할필요가있는다수의자바클래스들이있을수있다는

것이다.또다른차이점은SOA스타일의통합에필요한매핑을자동으로생성하기위해서스

키마컴파일러나생성기에의존할수없다는것이다.매핑은개발자가결정하여야한다.어떤

경우에는JAXB2.0어노테이션을사용하여서매핑을구현하는것자체가불가능할수도있다.

JAXB2.0명세[JSR222]의1.3절에서는“JAXB어노테이션메커니즘은임의의클래스를모든

XML스키마의개념으로의매핑을가능하게할만큼정교하지않다”라고기술한다.

이러한‘스키마와자바로부터시작’문제는JAXB2.0으로직접풀수있는것은아니지만,

JAXB2.0을이문제를해결하기위한도구로사용할수는있다.‘스키마와자바로부터시작’

문제를풀기위해JAXB2.0을사용하는특수한접근법은5장에서설명하고있다.더일반적

이고정교한접근법은SOA-J직렬화하부시스템이분석되어있는11장에서설명한다.

JAX-WS와같이JAXB는많은기능들을제공하며,표2.2에서는가장중요하고흥미있다고

26) 이문제는2.2.4절에설명한‘WSDL과자바로부터의개발’방식에서의문제와유사하다.

▒

▒


생각하는그러한기능들이1장1.2절에서설명한웹서비스플랫폼구조의호출,직렬화,배

포하부시스템에어떻게연결되는지보여준다.

표 2.2 JAXB 기능 표


바인딩런타임프레임워크(마셜/언마셜)

매핑어노테이션

유효성검증

마셜이벤트콜백

부분바인딩

이진데이터인코딩(MTOM혹은WS-I)

XML스키마의자바표현으로의연동

자바타입을XML스키마로

매핑

매핑어노테이션

연동언어

이식

2.4.1 XML 스키마의 자바 표현으로의 연동

앞에서논의한대로,JAXB2.0명세는XML스키마컴포넌트(예:요소,타입,속성)들을자바

의컨텐츠(예:클래스,빈프로퍼티)로표현하는표준자바/XML바인딩을제공한다.이바인

딩은,WSDL의메시지부분을웹서비스호출중에사용되는자바메소드의파라미터와반환

타입으로매핑시키는JWS배포하부시스템의일부를구성한다.

JAXB2.0구현은XML스키마로부터JAXB의스키마유도schemadrived자바프로그램요소

들을생성하는스키마컴파일러를제공한다.일반적으로복합타입으로부터생성된스키마

유도프로그램요소들은자바밸류클래스라고한다.각각의밸류클래스는get/set속성을이

용하여부합하는스키마컴포넌트들의내용에대한접근을제공한다.그래서복합타입의요

소와속성들은자바밸류클래스의속성으로매핑된다.밸류클래스의표면적인특성들(예:

빈프로퍼티의이름)은JAXB의연동언어(BindingLanguage,2.4.4절참조)를사용하여커스

터마이징할수있다.그러나밸류클래스의기본구조는원본스키마컴포넌트에의해결정

된다.예를들면,다음과같이여러번등장하는요소들

<xs:element name="foo" type="Bar" maxOccurs="unbounded"/>

은List<Bar>나Bar[]로매핑할수있지만,어느방식이든구조는기본적으로동일하다.


이제area코드와local number의형태로전화번호를표현한XML스키마컴포넌트를단

일string형태의자바속성으로매핑하려고한다고하자(예제2.1참조).

예 제 2.1 | 두 개의 Attribute를 단일 빈(Bean) 속성으로의 매핑

<xs:element name="phone">

<xs:complexType>

<xs:attribute name="area" type="xs:string"/>

<xs:attribute name="localnum" type="xs:string"/>

</xs:complexType>

</xs:element>

String getPhone(); // s = area+"-"+localnum일 때

void setPhone(String s); // area+"-"+localnum을 반환

JAXB를통해서이작업을하려면,javax.xml.bind.annotation.adapters.XmlAdapter를

상속하는임의의매핑클래스를작성하여야한다(2.4.3절참조).

복합타입에반해,단순타입－특히xs:string과같이기본탑재된XML스키마타입－은

부합하는자바원시타입과홀더클래스(예:java.lang.String, java.lang.Integer,

int)로매핑된다.

JWS프레임워크에서의사용한계를넘어서,JAXB밸류클래스는고도로추상화하여XML

객체를다룰수있게해주는훌륭한도구가될수있다.이클래스들과더불어,스키마컴파일

러는요소들의객체를만들어주는팩토리를생성한다.팩토리와밸류클래스는스키마로부

터유효한XML객체를쉽게만들수있게해준다.DOM과같은저수준의API를가지고작업

하면스키마객체를생성하는프로그램작성은더힘이든다.예를들어DOM을사용하게되

면,인포셋을수집하여에러를잡아내기위해서JAXP의유효성검증기(validator)에넣어

돌린다.그대신에JAXB(혹은XmlBeans[XMLBeans]와같은유사한스키마컴파일러)를사

용하면유효한XML을생성하는코드작성이더쉬워진다.

XML스키마를JAXB자바로표현하는데있어주요한장애는,기존의자바객체를이미존

재하는스키마컴포넌트의유효한객체로직렬화할때는도움이안된다는것이다.2.2.4절

에논의한대로‘WSDL과자바로부터의개발’문제는SOA스타일의통합에서는중요하다.이

러한JAXB한계점의결과는기존의WSDL을사용하여웹서비스를배포할때(즉,기존의스

키마로부터WSDL을만들때),생성되는자바인터페이스(즉,SEI)들은JAXB밸류클래스형


태의파라미터타입과반환타입을가진다.기존의자바응용프로그램에이클래스들을사용

하려면기존의자바클래스에서부터JAXB밸류클래스들로의매핑을처리해주는코드를작

성할필요가있다.그작업은나름의직렬변환기를직접작성하는정도의작업이다.

2.4.2 자바 타입의 XML 스키마로의 매핑

JAXB2.0자바/XML바인딩은자바클래스에서XML스키마로의표준매핑을제공한다.JAX-

WS2.0은웹서비스로배포된자바클래스로부터WSDL을생성하기위해이매핑을사용한다.

이‘자바로부터개발’이라는웹서비스로의접근방식(2.2.4절참조)은자바를XML스키마로

변형하는데JAXB표준매핑을적용하는주요사용예이다.

‘자바로부터개발’방식에서는,wsdl:operation의형태로배포되는자바메소드의파

라미터와반환타입은wsdl:types부분의스키마컴포넌트를결정한다.WSDL구조는4

장에서더상세하게설명하며,당분간은wsdl:types부분이웹서비스를설명하는WSDL

인터페이스에서사용되는XML스키마요소와타입정의를포함한다는것을이해하는정도

로충분하다.

JAXB구현은표준매핑을이용하여현존하는클래스로부터스키마를생성하는스키마생

성기를제공한다.스키마생성기는자바빈스타일의프로퍼티를찾아서속성과요소로매핑

한다.작업하는클래스가자바빈과같지않다면XML스키마는제대로생성되지않을것이

다.그러나클래스가많은프로퍼티를가지고있다면JAXB스키마생성기는클래스로부터유

용한스키마를생성할것이다.그러나자동생성되는이름들은원하는값들이아닐수있으며,

의도했던방식으로프로퍼티가요소와속성으로매핑되지않을수도있다.이런문제점들을

뛰어넘기위해매핑어노테이션이제공되며(2.4.3절참조),이를통해스키마생성기로하여

금필드와클래스를XML스키마컴포넌트들로어떻게매핑해야하는지알려준다.이론적으

로이러한방식은현존하는자바인터페이스를현존하는포트타입에매핑할경우에사용할

수있다.하지만이는이미언급하였듯이사용자직렬변환기를작성하는것만큼의많은작업

을요구한다.또다른결점은하나이상의스키마컴포넌트로의바인딩을제공하기위해여러

개로구성된어노테이션의집합을제공할수없다는것이다.

2.4.3 매핑 어노테이션

매핑어노테이션은JAXB2.0이표준자바/XML바인딩을커스터마이징하려고사용하는메

커니즘이다.2.4.2절에논의한스키마생성기는두개의입력을요구하는데,하나는클래스

들의집합이고,하나는매핑어노테이션들의집합이다.그러나스키마생성기는모든것에있


어서기본값을가정하며,따라서어노테이션이없다면생성된스키마는전적으로기본자바

/XML바인딩에따른다.

예제2.2는get/setPurchaseOrderNumber로정의된자바빈프로퍼티를orderNum으

로이름붙여진스키마요소로매핑하는데매핑어노테이션이어떻게사용되는지보여준다.

예 제 2.2 | 프로퍼티 이름의 기본 매핑을 커스터마이징 하기

public class PurchaseOrder {

// ...

@XmlElement(name="orderNum")})

String getPurchaseOrderNumber();

void setPurchaseOrderNumber();

};

<xs:element name="orderNum" type="xs:string"/>

이어노테이션들은개발자로하여금자바/XML바인딩의커스터마이징을허용하면서,역방

향으로매핑할경우에는스키마컴파일러에의해생성된다.즉‘XML로부터개발’작업을진

행할경우스키마로부터JAXB가생성하는코드는,프로그램요소가매핑되는XML컴포넌트

들을기술하는어노테이션을포함한다.이생성된어노테이션들은JAXB클래스들을XML인

포셋표현방식으로직렬화할경우런타임에사용된다.JAXB구현은생성된클래스－다른

JAXB구현에의해생성되었더라도－들의객체를이어노테이션에근거하여어떻게직렬화

할지실제적으로알수있다.그것은2.4.7절에논의하는이식성에있어서핵심이다.

그러나매핑어노테이션의또다른사용처는이진데이터인코딩－즉,어떻게그림과같은

이진데이터가인코딩되는지－을제어하는것이다.이것은2.4.10항에서논의한다.

여기서볼수있듯이,매핑어노테이션은직렬화하부시스템부분과JWS구현을위한배

포하부시스템으로구성된다.이어노테이션은,호출전후로SOAP메시지로(부터)직렬화되

는XML인포셋의형태로자바클래스를마셜링하는것을가이드하기때문에직렬화작업에

서사용된다.또어노테이션은,배포된자바인터페이스의파라미터와반환타입에부합하는

WSDL메시지파트부분에대한XML스키마를정의하기위해서배포작업중에사용된다(‘자

바로부터개발’방식).이두가지사용은제휴관계에있다.어노테이션은일련의타입매핑

을정의하고(배포),그러한타입매핑을구현하기위한마셜링작업의지침으로사용한다(직

렬화).


타입매핑을규정하는언어와마셜링지침을하나의메커니즘－어노테이션－으로묶는것

은웹서비스개발자들에게는다음과같은의미가있다.

타입매핑을생성하는것은자바클래스생성에견줄만한프로그래밍작업이

다.구현작업과분리하여타입매핑을선언적으로규정하는것은불가능하다.

타입매핑은자바클래스에대해스키마생성기를실행시키지않고서는(혹은

어노테이션을검사하기위한리플렉션의어떤다른형태를사용하지않고서는)

결정될수없다.

JWS의목표중하나는자바클래스로부터웹서비스를생성하는것을쉽게하는것이다.어

노테이션은자바프로그래머들이타입매핑과직렬화메커니즘을하나의언어로,웹서비스

를구현한자바코드를가지고바로규정하는것을가능하게한다.따라서순수자바프로그

래머들에게는,어노테이션이웹서비스를쉽게만들어줄것이다

그러나다른영역에서는이러한어노테이션중심의설계에서오는이점이적을수있다.

‘WSDL과자바로부터개발’방식에서는훨씬복잡해진다.예를들면,어노테이션에있어서한

가지분명한한계점은스키마컴포넌트와자바클래스간에일대일대응을강요하는것이다.

PurchaseOrder클래스를,배포하려고하는다른웹서비스의다른XML스키마타입으로매

핑할필요가있을경우에는어떤일이발생할까?PurchaseOrder어노테이션에바인딩이기

술되어있다면,여러버전의PurchaseOrder를생성하지않고서는불가능할것이다.

‘WSDL과자바로부터개발’방식은또한JAXB2.0어노테이션이지원하지않는타입매핑

을요구한다.이런경우는예제2.1의간단한전화번호의경우에묘사된것과같이아주일반

적이다.불행히도JAXB가제공하는@XmlJavaTypeAdapter 메소드는그런경우를다루기

에는어색하다.@XmlJavaTypeAdapter를사용하는데에는다음사항이요구된다.

자바클래스에어노테이션을추가하고javax.xml.bind.annotation.

adapters.XmlAdapter를상속받는어댑터클래스를구현해야한다.

매핑되어야하는클래스(즉,바인딩된타입)를JAXB2.0어노테이션이목표

XML스키마컴포넌트로매핑할수있는밸류타입으로변환하여야하는어댑

터를만들어야한다.

@XmlJavaTypeAdapter접근방법은직렬화과정에있어제어할수있는큰힘을제공하지

만,해야할일이많다.

▒

▒

▒

▒


2.4.4 바인딩 언어

2.4.3절에서는JAXB자바/XML바인딩과정의커스터마이징을가능하게하는어노테이션기

능에대해설명하였다.JAXB2.0바인딩언어는XML에어노테이션을추가하는데있어서유

사한기능을제공하는데,이를통해2.4.1절에설명된XML스키마의자바방식표현을커스

터마이징할수있게해준다.

바인딩언어는JWS프레임워크내의배포하부시스템의한부분이며,SEI의파라미터와반

환타입이되는자바타입의형태를만들어내기위해서사용된다.매핑어노테이션과는달리

바인딩언어선언은마셜링을위해JAXB런타임에의해사용되지않는다.그래서바인딩언

어는순전히배포하부시스템의한부분이며직렬화시스템에서는사용되지않는다.그러나

스키마컴파일러에의해서생성되는어노테이션은바인딩선언과소스가되는스키마로부터

얻어진다.따라서바인딩선언은(표준XML/자바바인딩과더불어)직렬화하부시스템을궁

극적으로제어하는매핑어노테이션을설계하는데사용된다.

바인딩선언이라고부르는바인딩언어의커스터마이징은언제나자바코드에삽입이되

는어노테이션과는달리XML스키마에삽입이되거나별도의설정파일을통해서제공될

수있다.

바인딩선언은적용범위가있다.예를들면바인딩선언은예제2.3에서처럼,전역선언이

될수있다.

예 제 2.3 | 전역 바인딩 선언

<jaxb:globalBindings>

<jaxb:javaType name="long" xmlType="xs:date"

parseMethod="pkg.MyDatatypeConverter.myParseDate"

printMethod="pkg.MyDatatypeConverter.myPrintDate"/>

</jaxb:javaType>

</jaxb:globalBindings>

그러한선언은컴파일되는모든스키마들에적용된다.이런경우,xs:date타입의XML

객체는javax.xml.datatype.XMLGregorianCalendar으로의기본바인딩을따르기보다

자바의long타입으로매핑되어야한다.parseMethod와printMethod속성은JAXB에게

이타입매핑을마셜링할수있는메소드들을어디서찾을수있는지알려준다.여기에적힌


xmlType은제한적으로얻어지는XML원자데이터타입이어야한다는것에주목한다.그래

서이접근방법은일반적인비표준타입매핑을규정하는데사용할수없다.

대신에바인딩은컴포넌트의스키마정의안에서<xs:appinfo>안에나타날때요소적용

범위를가질수있다.예제2.4는요소선언안에서의바인딩선언을보여준다.

예 제 2.4 | 컴포넌트 범위의 바인딩 선언

<xs:complexType name="foo">

<xs:sequence>

<xs:element name="po" type="javector:PurchaseOrder"

maxOccurs="unbounded"/>

<xs:annotation><xs:appinfo> <jaxb:dom/> </xs:appinfo></xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

이스키마의바인딩정의부분은굵은글씨체로되어있다.그러한선언은지역컴포넌트에

만적용된다.이런경우,po라는이름을가진요소는DOM－특히org.w3c.dom.Element의

객체－으로매핑된다.JAXB2.0방식의바인딩을적용하는것을원하지않을경우,DOM으

로매핑하는것은유용할수있다.그것은다른직렬화메커니즘을JAXB와융합시키는임시

방편의방법을제공한다.예를들어javector:PurchaseOrder에대한사용자직렬변환기

를가지고있다면이런방법을통해JAXB로부터DOM을얻어내어그것을사용자직렬변환기

에넘겨줄수있다.

전역범위와컴포넌트범위사이에는정의범위와스키마범위라는다른두가지레벨이

있다.

바인딩선언은외부바인딩파일에서도제공될수있다.그러한외부바인딩은관련된스키

마로다시역참조할수있게하기위해XPath표현식을사용한다.예제2.5는예제2.4에서의

바인딩선언을외부바인딩파일의일부분으로보이게하는방법을보여준다.


예 제 2.5 | XPath 표현식을 사용하여 관련 스키마를 참조하는 외부 바인딩 파일

<jaxb:bindings xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"

xmlns:xs="http://www.w3.org/2001/XMLSchema" version="1.0">

<jaxb:bindings schemaLocation=".../mySchema.xsd">

<jaxb:bindings node="//xs:complexType[@name='foo']">

<jaxb:bindings node=".//xs:element[@name='po']">

<jaxb:dom/>

</jaxb:bindings>

</jaxb:bindings>

</jaxb:bindings>

</jaxb:bindings>

‘WSDL로부터개발’을선택한많은웹서비스개발자들은구현에특화된XML을가지고

WSDL을변형하고싶어하지않기때문에바인딩정의를외부파일에넣을수있다는것은

중요하다.결국,웹서비스에서의전반적인핵심은비즈니스프로세스로의기술및플랫폼

독립적인접근방법을제공하는것이다.그러한JAXB의구현에특화된XML을WSDL에끼

워넣는것은모양새가좋지않을뿐아니라사람들로하여금WSDL을이해하기더힘들게

만든다.부가적으로어떤개발자들과아키텍처설계자들은이부분에서발생할수있는보

안문제를염려한다.WSDL에자바구현에관한정보를집어넣는것은악의적인해커들이

보안허점을악용하는데도움이될수있는내부시스템에대한정보들을제공하는것이다.

그런보안에대한여러분의우려를굳이타인과공유하지않더라도,소속된조직의누군가

는우려할수있으며,결국에는여러분의웹서비스모듈이배포가되는것에장애가될소

지가있다.

불행히도외부바인딩파일을생성하기위한XPath기반의접근법은사용하기에어렵다.

우선,웹서비스개발자들이XPath에대해익숙해야한다.대부분의자바개발자들은그렇지

않다.두번째로,외부바인딩파일은디버깅이어렵다.바인딩선언을변경할때마다스키마

컴파일러를다시실행하여산출되는자바클래스들을점검하여야한다.이런방식이유용하

려면JAXB제공자는이러한바인딩을만들고,편집하고,테스트할수있는쓸만한시각적인

개발도구세트를제공하여야할것이다.

바인딩언어에대한이번논의를종합해보면,이런접근방식을통해서사용자타입매핑과

직렬화를규정하는것은가능하지않다는것을지적하고싶다.대조적으로2.4.3절에설명된

것처럼어노테이션이달린POJO로부터XML스키마를생성하기위해‘자바로부터개발’방식

을사용하려한다면,@XmlJavaTypeAdapter를사용하여사용자타입매핑을삽입할수있


다.다른방식,즉XML스키마와바인딩선언을가지고개발을시작할경우에는이와상응하

는동등한메커니즘이존재하지않는다.결과적으로‘WSDL로부터개발’방식을사용한다면,

사용자직렬화방식을채택하기위해서우회방안을적용할필요가있다.

그런우회방안중하나로예제2.4와예제2.5에서볼수있는<jaxb:dom>선언이있다.

이바인딩선언은XML스키마컴포넌트가표준방식으로매핑되는부담을효과적으로덜어

주면서DOM요소로바인딩시켜준다.생성된프로그램요소들중에서,스키마컴포넌트는

org.w3c.dom.Element의객체로표시된다.응용프로그램코드는이Element객체를사용

자역직렬변환기에넘겨준다.그러나XML로다시마셜링하기전에DOM을얻어내기위하여

사용자직렬변환기를호출하고,생성된프로그램요소들을사용하는이DOM을넘겨주어야

한다.이것이수행되면,JAXB의마셜링오퍼레이션을호출한다.

바인딩언어에대한이짧은분석을결론짓자면,스키마컴파일러에의해생성되는자바

프로그램요소들의구조를조작하는데있어서는가장유용하다고하겠다.사용자직렬화에

대한지원은그다지없는편이다.외부바인딩파일에서사용하는것이매우어렵다는사실

은바인딩언어의유용성을더깎아내린다.이런난점들을피하기위해서WSDL안에바인

딩선언을삽입하게된다.따라서,구현에특화된XML로WSDL을훼손하고싶지않다면두

개의WSDL사본을가지고있어야한다.그중하나는JAXB에서내부적으로사용하기위함

이고,하나는외부공개용이다.이두가지선택사항들중어떤것도그다지좋아보이진않

는다.

2.4.5 바인딩 런타임 프레임워크(마셜링/언마셜링)

JAXB2.0바인딩런타임프레임워크는JWS구현에있어서직렬화하부시스템의핵심이다.

바인딩런타임프레임워크는마셜링과언마셜링오퍼레이션을구현한다.

JAXB는 ‘직렬화/역직렬화’라는용어대신에‘마셜링/언마셜링’을사용한다. ‘마셜링’은더

기술적인말이라고할수있는데,자바프로그램요소에대해마셜링을수행한결과는－예

를들면아직직렬화되지않은－DOM이될수있기때문이다.따라서마셜링은어노테이션

이달린JAXB클래스를어노테이션에따라커스터마이징하여자바/XML표준바인딩에따

라XML인포셋표현(예:파일에저장된XML문서,DOM)으로변환하는공정이다.마찬가

지로언마셜링은XML인포셋표현(예:파일에저장된XML문서,DOM)을컨텐트객체의트

리형태로변환하는것이다.이변환은인포셋에연관된XML스키마와,목표컨텐트객체의

프로그램요소정의안에규정된매핑어노테이션에의해커스터마이징된JAXB2.0표준자

바/XML매핑에의해정의된다.컨텐트객체의자바프로그램요소는스키마로부터유도된


JAXB2.0스키마유도프로그램요소이거나스키마생성기에의해스키마로매핑되는기존

의프로그램요소이다.

다음단계들은JWS호환응용프로그램에배포되는웹서비스를호출하기위해바인딩런타

임프레임워크가어떻게JAX-WS2.0호출아키텍처와연동하는지를나타낸다.

JWS응용프로그램은배포된엔드포인트에서SOAP메시지를받는다.

SOAP바인딩(javax.xml.ws.soap.SOAPBinding)의설정에따라JAX-WS는

메시지컨텍스트(javax.xml.ws.handler.soap.SOAPMessageContext)의

객체를준비하며,이것은SAAJ방식으로표현한메시지를포함한다.

JAXB는메시지의SAAJ방식표현을만들어내기위해MTOM/XOP 27)의처

리를제공해야할수도있다.그러한처리는요구가있기전까지미루어진다.

즉,성능상의이유로SAAJ객체로구체화되기위해서MTOM처리가필요한

SOAP메시지의일부에실제로접근을요청하기전까지는MTOM처리가미

루어진다.

JAX-WS는핸들러를호출한다.핸들러처리가진행되는동안응용프로그램은

SOAP메시지의내용에대해SAAJ인터페이스를통한접근이가능하다.이전

단계에서논의된대로,SAAJ를통한접근은MTOM처리를유발할수있으며이

는JAXB런타임바인딩프레임워크에서처리된다.

요청핸들러에서의작업이끝나면JAXB런타임은SOAP메시지의내용을요청

빈(2.3.14항참조)으로언마셜링한다.요청빈은JAX-WS에의해정의되지만,

JAXB는배포패키지에포함된파라미터와반환타입을기초로하여요청빈과

SOAP메시지간의바인딩을수행한다.

요청빈은JAXB런타임에의해서생성되며,웹서비스를구현하는자바메소드

에대해파라미터로넘겨지는자바객체를포함한다.JAX-WS는이파라미터들

을가지고메소드를호출한다.

JAX-WS는메소드호출로부터반환되는자바객체를넘겨받아서응답빈의객

체를생성하기위해서사용한다(2.3.14항참조)

JAXB는응답빈을마셜링한다.

27) MTOM/XOP관련설명은2.4.10절을참조하라.

1.

2.

3.

4.

5.

6.

7.

8.


2단계에서처럼,엔드포인트의SOAP바인딩을기초로하여,JAX-WS는응답의

SAAJ방식의표현을포함하기위해서메시지컨텍스트를업데이트한다.이것

은응답빈에대한SAAJ인터페이스이다.

JAX-WS는응답핸들러를호출한다.

응답메시지를전송하기이전에,JAX-WS는메시지에대한MTOM처리를제공

하기위해필요한대로JAXB런타임을호출한다.

JAX-WS는프로토콜전송단으로응답메시지를넘긴다.

여기서JWS명세에대한이해를도와줄만한몇가지이슈가있다.첫째,호출중에는두가

지의역직렬화작업이일어난다.처음에JAX-WS구현은전송된요청메시지의직렬화된형

태로부터SAAJ인터페이스를가지는인포셋방식의표현으로역직렬화한다.SAAJ는DOM기

반이므로,근본적인인포셋표현은DOM구현일수있으며,인포셋에접근이필요할때항상

가능하게해주는STaX나어떤다른종류의풀파서pullparser가될수도있다 28).이어지는직

렬화작업은JAXB런타임이인포셋방식의표현을JAXB어노테이션이달린프로그램요소로

언마셜링할때발생한다.

둘째,MTOM처리는실제로첫번째직렬화(직렬화되어있는전송단에서의형태로부터

인포셋방식의표현을생성하는것)의부분이지만JAX-WS를대신하여JAXB런타임이처리

한다.

셋째,모든핸들러의처리는SOAP메시지의인포셋표현에서부터JAXB언마셜링이일어

나기전과,SOAP메시지의인포셋표현으로의JAXB마셜링이일어난후에발생한다.결과적

으로프로그래머들은디폴트로는핸들러를통하여JAXB어노테이션이달린프로그램요소에

대한접근을할수없다.물론핸들러안에서JAXB마셜링을수행하기원한다면,JAXB바인

딩을통한인포셋으로의접근을얻기위해그접근법을사용할수있다.그러나그접근법은

처리과정중에또다른마셜링단계를요구하며,그에따라성능이떨어질수도있다.

그림2.4는두단계의역직렬화처리과정을나타낸다.SOAP요청은‘전송단’형식－여기

에서는MIME패키지－에서부터시작한다.첫단계는전송단형식에서XML인포셋으로변

환하고,SAAJ를통한접근을제공한다.이런형태의요청메시지는핸들러프레임워크에서사

용된다.두번째단계에서인포셋을자바프로그램요소로언마셜링을한다.이요소들은웹

서비스에서메소드호출을위한파라미터로사용된다.

28) JWS구현은아니지만,Axis2(http://ws.apache.org/axis2/)는이런접근법에대한예를제공한다.Axis의AXIOM객체모델은

SOAP메시지에대한성능중심의인터페이스를제공한다.AXIOM에서는,응용프로그램(예:핸들러)이SOAP메시지의일부에

접근을요구하기전까지는메시지는직렬화된형태를유지한다.접근이요청되면,메시지에서필요한만큼만역직렬화된다.

9.

10.

11.

12.


자바웹서비스의호출을위한이런두단계의(역)직렬화프레임워크를지원하기위해서

JAXB런타임은다음과같은기능에대한접근을프로그래머에게제공해주는javax.xml.

bind.*API를제공한다.

마셜링 :응용프로그램레벨의프로그램은JAXB어노테이션이달린클래스

객체와다양한XML인포셋형태간마셜링을할수있다.

객체 팩토리와 생성자 :팩토리와생성자는JAXB어노테이션이달린클래스의

객체를생성하기위해서제공된다.이는프로그래머들에게XML스키마컴포

넌트들의객체를생성하기위한편리한방법을제공한다:객체팩토리와생성

자를사용하여JAXB어노테이션이달린클래스에대응하는객체를생성하고

필요한만큼자바프로퍼티를설정한다.그리고XML을얻기위해객체를마셜

링한다.

JAXB2.0은 JAXB1.0과자바/XML바인딩을위한다른스키마컴파일프레임워크(예:

XmlBeans [XMLBEANS])를능가하는데,그것은스키마로부터생성된프로그램요소들뿐만

아니라POJO로(부터)의마셜링을지원하기때문이다.이기능은웹서비스를생성하고배포

하기위한‘자바로부터개발’방식에있어서중추적역할을한다.

▒

▒

그림 2.4 JWS 직렬화 - 전송 와이어에서부터 웹 서비스까지


내가가장크게비판하고싶은것은JAXB런타임자체가아니라,JAXB런타임이JWS에서

지원하는유일한자바/XML바인딩프레임워크가라는사실이다.그림2.4에서볼수있듯이

직렬화처리과정에는(1)XML인포셋의생성과(2)인포셋과웹서비스를구현하는자바객체

들사이의마셜링,이두개의별도컴포넌트가있다.

JWS명세가JAXB2.0런타임바인딩프레임워크에탈착이가능한대안을수용하는것은

어렵지않을것이다.현재,XML인포셋관점에서JAXB프로그램요소로의변환작업은눈에

보이지않고내부에서일어난다.이런언마셜링은요청핸들러가끝나고난다음에,그리고

배포된자바객체를호출하기전에일어난다.그것은JAX-WS2.0구현에의해서수행되며(적

어도현재의2.0릴리스시점에서는)표준API의부분이아니다.웹서비스배포시스템이런

타임바인딩프레임워크를규정하는것을허용하기위해서얼마만큼의적은수의API를노출

하면될것인가는쉽게상상할수있다.

2.4.6 유효성 검증validation

유효성검증은직렬화하부시스템에서의핵심컴포넌트이다.웹서비스를구현하기위해서

유효하지않은XML을어떻게처리할지를제어할수있어야한다.유효하지않다는의미는,

웹서비스를정의하는WSDL/XML스키마에대해서XML이유효하지않은것을의미한다.흔

히유효하지않은XML이문제없이통과하는것이바람직할경우가있다.예를들어특정한

속성이설정되었는지아닌지는특정한SOAP메시지의목표가되는웹서비스의호출에있어

서아무의미가없을수있다.

JAXB1.0과는다르게, JAXB2.0에서는유효하지않은XML의언마셜링이허용된다－사

실,이는디폴트동작이다.JAXB어노테이션이달린밸류클래스는,언마셜링에서의유효성

검증처리를건너뛰기위해어떤유효하지않은조건(예:out-of-orderelements,missingor

unexpectedelements) 29)을허용하는JAXB2.0의유연한언마셜링모드flexibleunmarshalling

mode를사용할것을요구한다.

이것은유효하지않은데이터의처리에있어서유연성을허용하기때문에큰진보라할수

있다.또유효성검증이요구되면,그기능을사용할수도있다.언마셜링중의JAXB2.0유

효성검증작업은JAXP1.3의javax.xml.validation.Schema의객체를Unmarshaller.

setSchema()메소드로넘겨줌으로써활성화된다.

유효성검증기능이활성화되면,디폴트동작은첫번째에러가발생할때unchecked

exception을던지는것이다.그러나Unmarshaller.setEventHandler()메소드를사용

29) out-of-orderelements는 XML인스턴스의요소의순서가스키마에서정의한순서와다른경우를말하고missingor

unexpectedelements는XML인스턴스의요소가스키마에서정의한요소가아니라다른요소인경우를말한다


하여javax.xml.bind.ValidationEventHandler을정의하고세팅함으로써이동작을변

경할수도있다.이러한접근법을사용하면,유효성검증에러가발생할경우,이벤트핸들러

가호출된다.이벤트핸들러는언마셜링작업중에보고된모든에러를수집하여한번에보

고할수있도록작성할수있다.사실이러한형태의유효성검증의디폴트구현은javax.

xml.bind.util.ValidationEventCollector에의해제공된다.이는디버깅작업에매우

유용하다.또unchecked exception으로던지고싶지않은어떤타입의에러가있을경우

에도유용하다.

JAXB2.0은선택사항이기는하나fail-fast유효성검증을지원한다.아마도추후릴리스에

서는필수사항이될것이다.지원이되면,fail-fast유효성검증은자바컨텐트트리에대한

모든변경사항을런타임에체크할수있게한다.내포된XML인포셋이연관된스키마에대해

유효하지않게되어버리는어떤변경사항이라도예외를던지게된다.fail-fast유효성검증은

속성predicate을사용하여구현한다.속성은스키마유효성검증법칙을프로그램요소프로퍼

티에적용하는부분코드이다.fail-fast유효성검증이지원되면,JAXB밸류타입의프로퍼티

의세터는소스스키마에명시된유효성검증법칙을적용시키는속성을가지고생성된다.

이에더해,JAXB1.0에서가용한유일한접근법이었던좀더견고하고구조적인언마셜링

모드를사용할수도있다.그러나이방식을취하게되면,밸류클래스보다는JAXB자바컨텐

트인터페이스를가지고작업하여야한다.그것은일단생성자가아닌객체팩토리를가지고

작업하여야한다는것을의미한다.내가보기에더오래된JAXB1.0방식을사용하고자하는

유일한경우는하나의요소이름이중복적으로나타날때,상이한JAXB프로퍼티로매핑하고

싶을때이다.예를들어,여러줄에걸쳐서주소를나타내고있는여러개의street요소를

가지고있고,이들을street1,street2 등과같은자바프로퍼티로매핑하고싶을경우유

용하다.그러나이러한종류의기능이정말로요구되는경우는본적이없다.

2.4.7 이식성portability

JAXB2.0의이식성은2.4.3절에있는매핑어노테이션을사용하여가능하다.어떠한JAXB구

현에서의런타임마셜링시스템이라도JAXB어노테이션이달린클래스를목표스키마의객

체로직렬화할수있어야한다.마찬가지로런타임의언마셜시스템은스키마객체를JAXB

어노테이션이달린클래스의객체로역직렬화할수있어야한다.

이것은중요한데,그이유는JAXB어노테이션이달린클래스로부터만들어진웹서비스를,

스키마를다시컴파일한다거나혹은벤더에종속적인구현클래스를사용하기위한웹서비

스의리팩토링작업없이,어떠한JAXB2.0플랫폼(예:SAP,Netweaver,JBoss,글래스피시)

으로도배포할수있다는것을의미하기때문이다.


2.4.8 마셜 이벤트 콜백Marshal Event Callback

콜백은직렬화 30)과정중에응용프로그램의고유한처리를가능하게한다.처리가직렬화

작업이전(타겟생성직후)혹은직렬화작업직후에발생하도록정의할수있다.이는직렬화

과정의외부에서프로퍼티를설정하는데있어서유용한특징이다.

내가마주쳤던한가지경우는,여러개의소스로부터데이터를한데묶는POJO로XML을

언마셜링하는것이었다.예를들어,어노테이션을추가한사용자객체가있다고하면그것

은사용자정보를포함하고있는SOAP메시지로부터언마셜링될수있다.하지만모든사용

자의데이터(예:트랜잭션내역)가SOAP메시지에포함되어있지않다면,또다른소스(예:

SAP)로부터객체데이터의나머지를싣고싶을수있다.그런경우언마셜링이끝나고난뒤,

이벤트콜백을사용하여SAP데이터를실을수있다.

2.4.9 부분 바인딩

javax.xml.bind.Binder클래스는XML문서의부분바인딩을지원한다.이기능은,예

를들어SOAP메시지의바디부분을처리하지않고헤더부분의JAXB바인딩을생성할수

있게해준다.어쩌면,핸들러처리를수행하면서특정SOAP헤더요소에대한업데이트만을

할수있다면성능적인측면에서이기능은매우유용할것이다.

예를들어myapp:persisted라는이름을가진SOAP헤더요소를true로명기하여전체

SOAP메시지를영속적인저장소에보존하였음을명시하기위한핸들러를생성하고싶다고

가정해보자.다음은부분바인딩메커니즘을가지고어떻게그작업이수행될수있는지보여

준다.

org.w3c.dom.Element persistedElt = ... // SOAP 헤더로부터 얻어온다

Binder<org.w3c.dom.Node> myBinder = jaxbContext.createBinder();

PersistedValueClass perVC = (PersistedValueClass)

myBinder.unmarshal(persistedElt);

perVC.setPersisted(true);

myBinder.updateXML(perVC); // XML infoset을 업데이트 한다

SOAP헤더인포셋을핸들러내부에서다루는것은이방법이더쉬운데,그이유는DOM

인터페이스를통하여탐색하거나업데이트를하지않아도되기때문이다.그리고에러가상

존할가능성도적다.XML인포셋에그릇된데이터를삽입하는DOM코드를디버깅하는작

30) 여기서의직렬화라는의미는직렬화와역직렬화중어느것일수도있다.이는이책전반에걸쳐동일하다.


업에여러시간을보낸적이있다면,이런형태의부분바인딩접근법을통해서부여된향상

된엄격함에대해고맙게생각할것이다.기반JAXB구현이fail-fast유효성검증(2.4.6절참조)

을지원하고그기능지원을사용한다면,핸들러처리이후의XML에대한유효성은보장된다.

2.4.10 이진 데이터 인코딩(MTOM 혹은 WS-I)

JWS프로그래밍모델은SOAP메시지를통한이진데이터전송에서의최적화를지원한다.이

진데이터(예:xsd:base64Binary와같은이미지파일)의인코딩,SOAP엔벨로프로부터의

이진데이터의추출,압축된형태를MIME패키지로부착하는작업,그리고SOAP엔벨로프

의안에서인코딩이된부분으로의참조를추가하는일들이그런최적화작업에포함된다.직

렬화하부시스템의일부분인이진최적화의지원은JAXB런타임구현에서제공한다.JAXB는

언마셜링(그림2.4참조)이전에이진데이터를푸는,그리고마셜링작업후에SOAP메시지

를전송단으로직렬화하는작업의일부로써패키지로묶는서비스를제공한다.JAXB2.0은

MTOM/XOP와WSIAP,두가지형태의이진데이터인코딩을지원한다.

MTOM은“SOAPMessageTransmissionOptimizationMechanism” (www.w3.org/TR/

soap12-mtom/참조)으로명명된W3C표준이다.이표준은XML인포셋으로부터내용을뽑

아내어압축하고,MIME첨부형태로묶고,인포셋안에서참조를통해서대체하는작업에

대한표준화된절차에대해설명한다.MTOM에서묶을때사용하는인코딩방식은,또하

나의W3C의추천표준이며“XML-binaryOptimizedPackaging”[XOP]라고명명된XOP이

다.XOP는base64로인코딩된내용을이진옥텟스트림octetstream형태로인코딩된각각의

MIME파트를참조하는xop:include요소로대체한다.데이터가이미이진옥텟스트림형

태로되어있다면,XOP패키지안에바로삽입될수있다.

WSIAP는WS-IAttachmentProfileVersion1.0 [WSIAP]을나타낸다.WSIAP는SOAP

MessageswithAttachmentsSwA를명확하게규정한다.SwA는이진데이터를SOAP첨부파

일형태로다루는접근법을표준화하고자하는산업계의첫번째시도였다.WSIAP은많은

제품에서지원하므로JWS도그것을지원한다는점은중요하다.그러나산업계에서는주요

표준으로MTOM/XOP로수렴하고있는듯하다.

JAXB는클래스내부의어떤자바프로퍼티를MTOM과WSIAP를사용하여직렬화할것인

지를규정하기위하여어노테이션을사용한다.MTOM에서@XmlMimeType어노테이션은

이진(예:java.awt.Image)자바프로퍼티를xmime:contentType속성으로묘사된스키

마요소로어떻게바인딩할것인지를규정하기위하여사용한다.xmime:contentType속

성[XMIME]은xs:base64Binary나xs:hexBinary타입을가진XML요소의컨텐츠타입


을표시하기위해서사용한다.WSIAP에서는@XmlAttachmentRef어노테이션이같은역할

을수행한다.

JAXB구현을가지고작업할경우,추상클래스인AttachmentMarshaller와

AttachmentUnmarshaller를상속함으로써MTOM과WSIAP의지원을제공받는다.예를

들면,JAX-WS구현은일반적인MIME처리를제공한다.그러나MTOM이나WSIAP방식의

패키징을처리하기위해서는JAXB구현으로런타임에연결된다.이는JAX-WS런타임으로

하여금Marshaller.setAttachmentMarshaller와Unmarshaller.setAttachmentUnm

arshaller 메소드를가지고AttachmentMarshaller와AttachmentUnmarshaller를등

록하게함으로써수행된다.

MTOM처리는웹서비스플랫폼에있어서중요한컴포넌트이다.MIME처리는JAX-WS에

서하고첨부의언마셜링은JAXB에서처리하는JWS의구조에서는,JAXB를사용하지않는

직렬화하부시스템으로대체하여MTOM기능을사용하려시도하려면어떤대안이필요할것

이라는것은분명하다.이문제를고민하는이유는이번에도JAXB가잘처리하기힘든‘WSDL

과자바로부터개발’방식의처리때문이다.MTOM에서의상황은SOAP결함처리에서의상

황과유사하다(2.3.11참조).나는JWS의SOAP결함메시지메커니즘은선호하지만,전체

JWS프로그래밍모델을필연적으로받아들이지않고사용할수있었으면한다.MTOM에서

도마찬가지다.전체JWS구조를사용하지않고MTOM처리서비스에접근할수있다면좋

을것이다.

2.5 WS-Metadata 2.0

2.4절에서는특히SOA개발과배포에관련된특징들에초점을맞추어JAXB2.0명세에대

한개괄적인여행을하였다.JAXB2.0명세는5장에서상세히다루는데,5장에는JAXB를사

용하여SOA관련문제를어떻게다루는지를예시한매우많은프로그래밍예제가준비되어

있다.전체적으로JAX-WS와JAXB는호출과직렬화를위한JWS프레임워크의대부분을제

공한다.

이절에서는웹서비스배포에집중하여특히웹서비스로서자바클래스배포를수월하게

하기위하여JWS가어떻게어노테이션을사용하는가에초점을맞춘다.WS-Metadata2.0은

JavaSE6와JavaEE5런타임컨테이너를사용하여웹서비스를개발하고배포하기위하여

사용하는표준어노테이션을정의한다.이명세의주요한목적은‘사용편의성’이다.즉,웹서

비스를작성하고배포하고사용하는것을보다쉽게하는것이다.이목적은JavaEE5의보


다큰‘사용편의성’목적의일부이다.어노테이션은JavaEE5에퍼져있는‘사용편의성’의중

심에있다.예를들어,어노테이션은,배포기술자에대한필요성을줄이거나없애고무상태

세션빈에의존성주입과(2.7.1절참조)같은기능을더하기위한구조로써EJB3.0에서많이

사용되고있다.

나는자바클래스로부터시작할때어노테이션이웹서비스를개발하고배포하는것을보

다쉽게한다는것에동감한다.WS-Metadata의성향은‘자바로부터시작’하는개발모델이다.

8장의코드예제에서보는것처럼웹서비스를배포하기위하여J2EE1.4를사용하는것보다

JavaEE5를사용하면보다적은작업을하게된다.

일반적으로나는WS-Metadata어노테이션이커다란진일보라고생각한다.그렇지만보다

적합할수있는한영역이있다.‘WSDL과자바로부터시작’하는개발모델이다.‘WSDL과자

바로부터시작’하는개발에서어노테이션의영향력은복합적이다.‘WSDL과자바로부터시작’

하는애플리케이션의전체라이프사이클에대한어노테이션의영향력에대하여생각해보기

위하여다음예제를고찰해보자.

PurchaseOrder클래스를가지고있고createPurchaseOrder()메소드를웹서비스오

퍼레이션으로배포하려한다고가정해보자.게다가조직은비즈니스파트너들의구매과정

접점에대하여비즈니스파트너들이사용하는표준WSDL인터페이스를사용하여웹서비

스를공개할것을요구한다고가정하자.이시나리오에서기존오퍼레이션ns:createPO를

가지고있고그오퍼레이션을사용해야한다.이오퍼레이션은비즈니스파트너들이동의한

XML스키마에의해정의된표준ns:PurchaseOrder요소를포함하고있다.

WS-Metadata를사용하려면필요한어노테이션을포함하는PurchaseOrder클래스를수

정해야할것이다.그것은소스코드에접근할수있는지아닌지에따라서가능할수도,그렇

지않을수도있다.소스코드를가지고있을지라도그것이대규모애플리케이션의일부일수

도있고이프로젝트에대하여여러분의어노테이션을가진애플리케이션을다시컴파일하고

다시배포할수있는조직내에서의권한을가지고있지않을수도있다.

그러나논의를위하여,필요한어노테이션을더할수있고애플리케이션을다시컴파일하

고다시배포할수있다고가정하자.그다음으로여전히PurchaseOrder프로그램요소를

JAXB어노테이션을(2.4.3절참조)사용하는ns:PurchaseOrder요소로매핑하는문제를

갖게된다.확장매핑의사용자설정을가지고도이매핑을충족하기위한JAXB를얻는것이

불가능할수도있다. 31)

31) 많은자바/XML매핑은JAXB어노테이션을사용하여구현하는것이불가능하다.자세한것은2.4절과5장을살펴보아라.


다시,논의를위하여어노테이션을사용하여표현할수있는매핑이있다고가정하자.어

떻게이매핑을찾을것인가?어노테이션을작성해서WSDL/스키마생성기를실행하고,비

즈니스파트너들이동의하는표준WSDL과결과의WSDL이일치하는지아닌지를살펴보아

야한다.그과정은C코드를작성해서어셈블리언어프로그래밍을하고그것을컴파일해

서원하는바이트들을생성했는지아닌지를살펴보려는것과같은것이다.매우능률적인

과정이아니다!

그러나다시,논의를위하여끈기있게노력하여필요한WSDL을생성하는어노테이션을

얻을수있었다고가정하자.이제,비즈니스파트너들이WSDL을변경한다면무슨일이일어

날까?이경우,출발점으로되돌아가서어노테이션을작성하고WSDL/스키마생성기를실행

해서다시결과물을얻기위한시도를해야한다.일단올바른어노테이션을알아냈다면(그

것이가능하다고가정하자),다시새로운어노테이션을가진코드를다시컴파일하고다시배

포해야한다.

바라는바는,이예제를통하여‘WSDL과자바로부터시작’하는개발모델측면에서어노테

이션은얼마간의제약을가질수있다는것을깨닫는것이다.이러한문제에직면한다면,대

부분의프로그래머들은PurchaseOrder클래스를위한래퍼을만드는것을선택할것이다.

이것은비즈니스파트너의표준WSDL에대하여WSDL/스키마컴파일러를실행하여가장적

절하게이루어질수있다.결과의자바클래스들을얻을수있고그것들을여러분의실제클

래스를호출하는래퍼로바꿀수있다.어노테이션은생성된클래스들에대한수정범위를

한정하여,WSDL이변경되면생성된클래스들을새롭게갱신하여기존의PurchaseOrder.

createPurchaseOrder()메소드를호출하기위하여집어넣은수정내용을유지하게한다.

WS-Metadata의개요에서는‘WSDL과자바로부터시작’하는개발모델에대한‘래퍼기반의

통합’접근법을사용하는프로그래머의관점을취할것이다.그것이내가‘래퍼기반의통합’

접근법이‘WSDL과자바로부터시작’하는개발모델에접근하기위한가장좋은방법이라고

믿는다고말하는것은아니다.다른가능성을검토하는것도가치가있을수있다.예를들어,

11장에서는‘WSDL과자바로부터시작’모델과SOA-형식시스템통합에대해다른접근법을

설명하기위하여SOA-J를사용한다.그러나이시점에서,나는JWS프로그래밍모델을검토

하고있고이모델에서는‘래퍼기반의통합’접근법이아마도‘WSDL과자바로부터시작’개

발에대한가장좋은접근법이다.

표2.3에서보는것처럼,여기서논의하는WS-Metadata의특징들은모두웹서비스배포와

관련된것이다.이절의나머지는이특징들의개요를설명한다.8장에서는WS-Metadata와

WSEE(JSR-109)를상세히살펴보고많은배포예제들을제공한다.


표 2.3 WS-Metadata 2.0 기능 표


WSDL매핑어노테이션

SOAP바인딩어노테이션

핸들러어노테이션

서비스구현빈

WSDL과Java로부터시작하기

자동배포

이특징들을각각하나씩살펴보기전에,그림2.5를살펴보자.그림은웹서비스배포를구

체화하기위하여WS-Metadata를어떻게사용하는지를보여주고있다.그림2.5의코드와

WSDL은함께작용하는다양한WS-Metadata어노테이션들을설명하고있다.이예제는WS-

Metadata2.0명세4.7.3절Example3-thedocument/literalwrappedexample에서인용하였다.

WS-Metadata어노테이션은1에서8까지열거되어있고점선은WSDL에서어노테이션이

영향을미치는곳을보여준다.다음항목들은이어노테이션들이무엇을하는것인지에대한

일반적인개념을상세한설명없이알려주기위한것이다.이어노테이션들은8장에서상세

하게논의된다.WSDL의다양한형태는4장에서기술한다.

@WebService는이자바클래스가웹서비스로배포된다는것을JWS구현체가

이해하도록하기위하여표시하는것이다.

@SOAPBinding은웹서비스가SOAP프로토콜을사용한다는것을나타낸다.

@SOAPBinding.style엘리멘트는이웹서비스가도큐먼트스타일을사용하

여배포되어야한다는것을나타낸다.이어노테이션은보이는것처럼soap:

binding요소의'style'속성으로설정된다.

@SOAPBinding.use요소는이웹서비스를위한메시지들이('encoded'와

대립하는)'literal'형태를사용하여전송된다것을나타낸다.이어노테이

션은보이는것처럼 soap:body요소의'use'속성에작용한다.

@SOAPBinding.parameterStyle요소는이웹서비스를위한메시지들이

'wrapped'파라미터를사용해야한다는것을나타낸다.결과로,파라미터wrapper

의요소이름은웹서비스의오퍼레이션이름과같은"SubmitPO"이된다.

1.

2.

3.

4.

5.


그림 2.5 WS-Metadata 어노테이션은 WSDL의 형태를 규정한다


@WebMethod.operationName요소는WSDL오퍼레이션이름이"SubmitPO"

이어야한다는것을명시한다.

@WebResult.name요소는응답메시지가 "PurchaseOrderAck"로명명

된요소이어야한다는것을명시한다.이요소는여기에보이지않지만,

"SubmitPOResponse"로명명된응답래퍼에넣어진다는것에주의해라.

@WebParam.name요소는자바파라미터purchaseOrder에매핑되는요청파

라미터의이름이"PurchaseOrder"로명명되어야한다는것을명시한다.응답

요소처럼이요소도래퍼에넣어진다.

그림2.5의예제에서JAX-WS기본WSDL/자바매핑의효과도살펴볼수있다.예를들어,

portType의이름인DocWrappedService은자바클래스이름과같다.

2.5.1 WSDL 매핑 어노테이션

javax.jws패키지에속한WS-Metadata2.0WSDL매핑어노테이션은개별자바메소드에

할당되는WSDL오퍼레이션이름과같은정보를명시하여WSDL/자바매핑을구체화할수

있게한다.이어노테이션들은2.3.1절에서설명된기본WSDL/자바매핑을사용자설정으

로바꿀수있게한다.그림2.5에서다음어노테이션들은WSDL매핑어노테이션으로분류

된다:@WebService, @WebMethod, @WebResult, @WebParam.

만약 ‘WSDL로부터시작’또는 ‘WSDL과자바로부터시작’하려한다면,WebService.

wsdlLocation요소는필수다.그것은미리정해진WSDL의위치를명시할수있게한다.

2.5.2 SOAP 바인딩 어노테이션

javax.jws.soap패키지에속한WS-Metadata2.0WSDL바인딩어노테이션은SOAP바인

딩형식,용법,파라미터형식을사용자설정으로바꿀수있는능력을준다.이어노테이션

들은2.3.9절에서기술한기본JAX-WSSOAP바인딩을사용자설정으로바꾸기위하여사용

된다.바인딩형식/용법/파라미터에대한JAX-WS기본값은‘document/literalwrapped’이

다.하지만,javax.jws.SOAPBinding어노테이션을사용한다면‘rpc/literal’과‘document/

literal원형’과같은다른가능성을지정할수있다.SOAP바인딩형식과파라미터래핑은많

은혼란과상호운영성문제의원인이되어왔다.WS-Metadata와JAX-WS는이영역에서돋

보인다.WS-Metadata와JAX-WS는자바개발자가쉽고직관적으로웹서비스의SOAP바인

딩을이해하고구체화하도록한다.SOAP바인딩형식과파라미터래핑은4장4.3절에서상

세히설명한다.

6.

7.

8.


2.5.3 핸들러 어노테이션

2.3.7절에서설명한것처럼핸들러의배포는WS-Metadata어노테이션을사용하여지정된다.

javax.jws.HandlerChain어노테이션은웹서비스와외부에정의된핸들러체인을연결한

다.이핸들러체인은@HandlerChain.file멤버값으로참조되는파일에정의된다.

javax.jws.soap.SOAPMessageHandlers어노테이션은WS-Metadata 2.0에서반대

deprecated되고있다. 32)JAX-WS를사용할때, JAX-WS엔드포인트는SOAP핸들러를배포하

기위한구조로사용될수없기때문이다.

2.5.4 서비스 구현 빈

(3.1절의)WS-Metadata는자바클래스를웹서비스로배포하기위한요구조건을정의한

다.이요구조건을만족하는클래스를서비스구현빈이라한다.JAX-RPC에서는서비스가

java.rmi.Remote를확장하는서비스엔드포인트인터페이스SEI를사용하여구현될것을

요구하지만,이요구조건은더이상JAX-WS와WS-Metadata에서는적용되지않는다.게다가,

서비스구현빈에관한요구조건을따르는POJO와EJB는둘다웹서비스로배포될수있다.

이것은두개의다른빈명세를가지고있는J2EE1.4에대한큰개선점이다.하나는(웹서비

스가무상태세션빈인터페이스를가지고구현될것을요구하는)EJB배포에대한것이고하

나는웹컨테이너(서블릿)배포에대한것이다.

JSR-181처리기는(2.5.5절참조)목표컨테이너에따라다른아티팩트를생성한다－목표

가J2EE1.4EJB컨테이너라면EJB2.1인터페이스를포함한다.그러나어노테이션은개발자

가추상화보다상위수준에서작업할수있게하여컨테이너에특화된배포에대하여시간소

비적이고장황한세부항목사용을피할수있게한다.JSR-181처리기에의해생성된아티팩

트는자바웹서비스를위한이식성요구조건을기술하고있는WSEE1.2에의해정의된다.

2.5.5 WSDL과 자바로부터 시작하기

‘WSDL과자바로부터시작’하는개발모델은기존의자바클래스또는인터페이스에대한

구조체를WSDL에대한구조체로매핑하는어노테이션을사용하여지원한다.예를들어,

@WebMethod.operationName어노테이션은메소드를미리정해진wsdl:operation

과연결하기위하여사용될수있다.이러한접근법의장단점은WS-Metadata논의에대한

개요에서설명되었다(2.5절참조).

32) 어노테이션이'반대'된다는것은현재버전(JSR-181(WS-Metadata)버전2.0)까지는사용할수있지만,미래버전에서는제거될

것이라는것을의미하기때문에이어노테이션을(가능한)사용하지말것을권고하는것을뜻함


그논의에서지적된문제들은,‘WSDL과자바를가지고시작’모델을지원하는JSR-181구

현체는웹서비스구현이WSDL계약으로부터벗어나는지를알려주는피드백을제공해야한

다는WS-Metadata명세의요구조건에의해처리된다.부적합한부분과제안된어노테이션을

강조해주는GUI를가지고,기존WSDL에따르도록기존자바소스파일에어노테이션을붙

여주는잘구현된도구를상상할수있다.또한JSR-181처리기를단지실행해서일련의부적

합오류들로구성된일괄처리결과를주는나쁜도구를상상할수도있다.

어쨌든,이런피드백구조의의도는개발자가자신의자바코드를WSDL에서일어나는변

화에즉시맞추도록도와주는것이다.이것은중요한특징이다.

2.5.6 자동 배포

자바서버페이지JSPs에서사용되는것과유사한‘드래그앤드롭’배포모델인자동배포는

WS-Metadata명세([JSR181]의2.4절참조)에의해기획되었지만,필수조건은아니다.이런

모델에서웹서비스의런타임배포는전적으로웹서비스어노테이션에달려있다.특정구현

체에한정된배포도구는요구되지않는다.

(이책에서예제수행을위해사용하는JavaEE5구현체인)글래스피시는이런‘드래그앤

드롭’배포기능 33)을제공한다.프로그래밍예제들은8장에준비되어있다.

2.6 엔터프라이즈 웹 서비스: WSEE 1.2

앞절에서논의된WS-Metadata2.0은자바웹서비스를만들기위하여어노테이션기반프로

그래밍모델을정의하지만,WSEE1.2명세는JavaEE애플리케이션서버구현체간의이식성

을보증하기위한서비스구조와패키징을정의하고있다.

J2EE1.4에서웹서비스에관련된많은불평들은WSEE1.0을사용하는배포복잡성에집

중되어있다.이배포복잡성은여기에기술된단순화된구조및패키징과함께,2.5절에서기

술된어노테이션사용으로대단히감소되었다.

표2.4에서보는것처럼,여기에논의되는WSEE1.2특징들은모두배포와관련된다.이절

의남은부분에서는이특징들에대하여간략히논의한다.8장에서WS-Metadata[JSR181]과

함께WSEE1.2[JSR109]을상세히설명하고많은배포예제도제공할것이다.

33) 글래스피시에대한보다자세한것은부록B를살펴보아라.


표 2.4 WSEE 기능 표


포트컴포넌트

서블릿엔드포인트

EJB엔드포인트

단순화된패키징

핸들러프로그래밍모델

2.6.1 포트 컴포넌트

포트컴포넌트는웹서비스를실행하는컨테이너에패키징되어배포되는것이다.WSEE에의

해정의되는포트컴포넌트는JavaEE플랫폼에추가되는것으로(웹컨테이너의)서블릿과

JSP또는(EJB컨테이너의)EJB와같은다른배포가능한컴포넌트에대한웹서비스대응물

counterpart이다.

포트컴포넌트는서비스구현빈SIB을포함하고있는이식가능한웹서비스애플리케이션

을구성하는프로그래밍모델아티팩트를정의한다.SIB는유일한필수아티팩트이다－J2EE

와는다르게,webservices.xml기술자를요구하지않는다.

WSEE1.2에서정의된포트컴포넌트는J2EE1.4모델을간소화한것이다.J2EE1.4에서배

포를위해요구되는다른아티팩트는서비스엔드포인트인터페이스SEI,웹서비스배포기술

자(webservices.xml), JAX-RPC매핑배포기술자를포함한다.WSEE1.2에서다음아티

팩트는포트컴포넌트에선택적으로포함될수있다:WSDL문서,SEI,webservices.xml.

webservices.xml배포기술자가주어졌을때,webservices.xml배포기술자는어노테이

션으로주어진어떤상충되는배포정보에우선한다.

2.6.2 서블릿 엔드포인트

WSEE1.2에서는,POJO가SIB를위한WS-Metadata에서설명된요구조건을충족한다면

POJO는웹컨테이너에배포되는웹서비스를구현하기위하여사용될수있다,라고명시하

고있다.이것을일반적으로서블릿엔드포인트라고한다.


2.6.3 EJB 엔드포인트

WSEE1.2에서는,EJB컨테이너에배포되는웹서비스를구현하기위하여무상태세션빈을

사용할수있다,라고명시하고있다.이것을일반적으로EJB엔드포인트라고한다.무상태

세션빈으로부터SIB를생성하기위한요구조건은WSEE의5절에서자세히설명하고있다.

2.6.4 단순화된 패키징

많은일반적인배포시나리오에서배포기술자를요구하지않는다.더구나,배포기술자가요

구될때도J2EE1.4의대응물보다훨씬간단하다.다양한패키징선택사항에대한상세한예

제들은8장에준비되어있다.

2.6.5 핸들러 프로그래밍 모델

핸들러어노테이션은WS-Metadata2.0(2.5.3절참조)에의해정의되어있다.JavaEE

5에서핸들러프로그래밍과런타임모델은WSEE1.2에기술되어있다.WS-Metadata

@HandlerChain어노테이션은핸들러체인을포트컴포넌트에연결시켜준다.WSEE는핸들

러체인배포기술자의구조를정의한다.또한WSEE는리소스주입을통해<env-entry>파

라미터를접근하기위하여핸들러특성과같은런타임특성을정의하고있다.

2.7 그 밖의 Ja�a EE 5 어노테이션의 영향력

개발과배포를간단하게하기위하여(2.5절에서기술한)WS-Metadata2.0어노테이션을사용

하는발상은JavaEE5명세구석구석에도입된어노테이션의폭넓은사용의한가지예다.이

절에서는JavaEE5플랫폼의일부로만들어진다른흥미로운어노테이션들을간단히언급한다.

개발자들은웹서비스애플리케이션을개발할때이어노테이션들을사용할수있다.

2.7.1 의존성 주입

JavaEE5는다양한컨테이너안에서컨텍스트를생성하는과정을단순화는의존성주입구

조를도입했다.의존성주입은어떤객체가컨테이너에의해생성될때,리소스(예를들면,데

이터베이스커넥션)또는다른객체에(예를들면,웹서비스클라이언트)대한참조값을얻기

위하여사용된다.다양한컨테이너들은다양한형태의의존성주입을지원한다.JavaEE5명

세에서는EJB,웹,애플리케이션클라이언트(즉,main클래스)컨테이너안에서의주입지원

을명시하고있다.


웹서비스를지원하기위한어느정도의의존성주입패턴은JAX-WS2.0명세의일부

로만들어져있다.예를들어,@WebServiceRef어노테이션은명시한웹서비스에대

한참조값의주입을명시하고있다.이렇게참조값이생성된후에,이참조값은참조된

웹서비스를호출하는클라이언트로사용된다.마찬가지로, JAX-WS2.0의javax.xml.

ws.WebServiceContext는의존성주입을위한@Resource를사용하여웹서비스구현

안에서얻을수있다.이러한방법으로사용되는의존성주입의예제들은JAX-WS가상세히

논의되는6장과7장에서설명한다.

2.7.2 인터셉터

인터셉터는또다른메소드호출을가로채는방법이다.이것은AOPAspectOrientedProgramming

인터셉터개념에대한 Java EE 5구현이다.예를들어,submitPurchaseOrder(Purc

haseOrder po)메소드를호출하기전에입력po에대한유효성검사를원할수있다.

이러한유효성검사는javax.interceptor.Interceptors어노테이션을사용하는

submitPurchaseOrder메소드와연결된인터셉터로구현될수있다.

인터셉터는메소드가웹서비스로배포될때부가적인서비스를더하기쉽게한다.이전에

기술된유효성검사는한가지예이다.또다른예는보안이다.사용자의증명서가SOAP헤

더에적용된장면을생각해보자.호출자의증명서를기반으로,wsdl:port에대한개별메소

드에대하여접근제한을하기원할수있다.요청핸들러안에서,어떤메소드가호출되고보

안제한을적용할지해석하려고하는대신에,증명서를메시지컨텍스트에저장하는것이훨

씬쉽다.그러고나서,메시지컨텍스트에저장된사용자증명서를기반으로한보안규칙을

각메소드를적용한인터셉터를정의하자.

2.7.3 EJB 3.0에서의 POJO 지원

EJB3.0명세는엔터프라이즈자바빈을생성하고배포와연결된많은복잡도를감소시키기

때문에흥미롭다.EJB3.0을상세히논의하는것은이책의범위를벗어난다.하지만,웹서비

스에대한POJO지원의영향력을지적하고싶다.

EJB3.0은무상태세션빈에단순히@Stateless어노테이션을더하는것으로개발자가

POJO를무상태세션빈으로배포할수있게한다.더이상EJBObject, EJBLocalObject,

또는java.rmi.Remote인터페이스를제공할필요가없다.또한홈인터페이스의제공도필

요로하지않는다.

이것은EJB컨테이너안에서웹서비스를구현하기위한기존의POJO를배포하기쉽게한


다.J2EE1.4모델을(EJB2.1과JAX-RPC1.1)사용할때,EJB컨테이너를통하여기존의

POJO를웹서비스로배포하려한다면,필수인터페이스를구현한무상태세션빈래퍼를생

성할필요가있다.이요구조건의해제가‘WSDL과자바로부터시작’하는개발방법에대한

한가지장애물을제거했다.

2.8 결론

이장에서는JWS가제공하는웹서비스의가능성에대하여개괄적으로설명하였다.이장에

서상위수준의관점으로출발하여일반적인SOA애플리케이션을살펴보고웹서비스가적

합한분야를기술하였다.그다음으로중위수준으로내려와서JavaEE5와JavaSE6범위내

에서웹서비스런타임구현의일부를상세히기술하였다.그리고2.3절부터2.7절에서중위

수준의관점으로JAX-WS2.0,JAXB2.0,WS-Metadata2.0,WSEE1.2및그밖의웹서비스

관련명세들에대한개발및배포특징을계속해서살펴보았다.이모든과정을잘통과해냈

다면,자바웹서비스에대한전반적인지식을갖게된것이다.또SOA개발을위한플랫폼으

로서의JWS의장단점에대한나의견해도들었다.이번장을대충읽었다면,그것도좋다.이

후의프로그래밍예제로부터잠시쉬면서‘나무가아닌숲’을보고싶을때면,언제든지이곳

으로돌아올수있다.

3~8장에서는하위수준으로내려와,상세한예를통해자바웹서비스를어떻게프로그램

을하는지는배우게된다.3장은웹서비스를위한REST모델로출발한다.그것은REST가다

루기쉬워서WSDL과SOAP에익숙하지않다면REST는웹서비스를경험하는것을도울수

있기때문으로나역시REST로출발한다.만약REST에흥미가없거나,WSDL과SOAP으로

바로도약하길원한다면,자유롭게4장으로건너뛰어라.

2.8.1 예제 구축과 실행을 위한 환경 설정

나머지장들에는많은프로그래밍예제들이포함되어있다.이책을통해서공부할때,예제

들을내려받아살펴보고실행할것을강력히권한다.단지본문을읽는것보다그러한실제

체험으로부터더많은것을배울것이다.예제코드를실행하기위하여실행환경을구축할

필요가있다.환경구축과예제소스코드를내려받는방법에대한설명은부록B를살펴보

아라.

SOA : 자바 웹 서비스로 통하는 서비스 지향 아키텍처

Documents

Transcript of SOA : 자바 웹 서비스로 통하는 서비스 지향 아키텍처