2008년 3월 5일 수요일

JAX-RPC Vs JAX-WS

JAX-WS 2.0은 JAX-RPC 1.1의 후속 제품입니다. 이 두 가지 웹 서비스 프로그래밍 모델을 비교합니다.


머리말
웹 서비스는 긴 역사를 갖고 있다. 처음에는 SOAP 이 있었다. 하지만 SOAP 은 메시지가 어떻게 보이는지를 기술만 할 뿐이었다. 그 다음에는 WSDL이 등장했다. 하지만 WSDL은 자바™로 웹 서비스를 작성하는 방법을 알려주지 않았다. 그 뒤를 JAX-RPC 1.0이 이었다. 몇 달 사용하고 난 후에, 그 스팩을 작성했던 Java Community Process (JCP) 멤버들은 약간의 조정이 필요하다는 것을 깨달았고, 그 결과로 JAX-RPC 1.1이 탄생했다. 이 스팩을 사용하고 1년 정도가 지난 후에, JCP 멤버들은 더 나은 버전을 구현하고 싶었다. 바로 JAX-RPC 2.0이다. 주요 목표는 산업 방향에 맞추어 조합하는 것이었지만, 업계는 RPC 웹 서비스를 좀처럼 수행하지 않았고, 여전히 메시지 지향 웹 서비스를 사용하고 있었다. 따라서 “RPC”가 명칭에서 빠지고, "WS"(물론, Web Services를 의미한다.)로 대체되었다. 따라서 JAX-RPC 1.1의 후계자는 JAX-WS 2.0(Java API for XML-based Web services)인 것이다.
JAX-RPC 1.1과 JAX-WS 2.0간 차이점을 조목조목 따지기 전에, 변하지 않은 것은 무엇인지부터 짚고 넘어가자.
  • JAX-WS는 여전히 SOAP 1.1 over HTTP 1.1을 지원하기 때문에 상호 운용 성은 문제 없다. 같은 메시지가 여전히 와이어를 타고 흐른다.
  • JAX-WS는 여전히 WSDL 1.1을 지원하기 때문에, 여러분이 알고 있는 스팩이 여전히 유효하다. WSDL 2.0 스팩은 거의 완성 단계에 다다랐지만, JAX-WS 2.0 이 완성되었을 당시에는 여전히 작업 중이었다.
  • SOAP 1.2
    JAX-RPC와 JAX-WS는 SOAP 1.1을 지원한다. JAX-WS 역시 SOAP 1.2를 지원한다.
  • XML/HTTP
    WSDL 1.1 스팩은 HTTP 바인딩을 정의했는데, 이는 SOAP 없이 HTTP를 통해 XML 메시지를 전송할 수 있는 수단이 된다. JAX-RPC는 HTTP 바인딩을 무시했다. JAX-WS는 여기에 대한 지원을 추가했다.
  • WS-I's Basic Profiles
    JAX-RPC는 WS-I의 Basic Profile (BP) version 1.0을 지원한다. JAX-WS는 BP 1.1을 지원한다. (WS-I는 웹 서비스 상호 운용성 기구이다.)
  • 새로운 자바 기능
    • JAX-RPC는 자바 1.4로 매핑된다. JAX-WS는 Java 5.0과 매핑된다. JAX-WS는 Java 5.0의 새로운 많은 기능들에 의존한다.
    • J2EE 1.4의 후속인 Java EE 5는 JAX-WS에 대한 지원을 추가했지만, JAX-RPC도 여전히 지원한다. 이것 때문에, 웹 서비스 풋내기들이 혼란을 겪는다.
  • 데이터 매핑 모델
    • JAX-RPC는 고유의 데이터 매핑 모델이 있는데, 모든 스키마 유형의 90 퍼센트를 커버한다. 커버되지 않는 것들은 javax.xml.soap.SOAPElement로 매핑된다.
    • JAX-WS의 데이터 매핑 모델은 JAXB이다. JAXB는 모든 XML 스키마에 대한 매핑을 약속한다.
  • 인터페이스 매핑 모델
    JAX-WS의 기본 인터페이스 매핑 모델은 JAX-RPC 모델과는 크게 다르지 않다. 하지만:
    • JAX-WS의 모델은 새로운 Java 5.0 기능을 사용한다.
    • JAX-WS의 모델은 비동기식 기능을 도입했다.
  • 동적 프로그래밍 모델
    • JAX-WS의 동적 클라이언트 모델은 JAX-RPC의 그것과는 매우 다르다. 업계의 필요에 맞춰 많은 변화가 생겼다.
      • 메시지 지향 기능을 도입한다.
      • 동적 비동기식 기능을 도입한다.
    • JAX-WS는 동적 서버 모델도 추가한다. 이것은 JAX-RPC에는 없다.
  • MTOM (Message Transmission Optimization Mechanism)
    JAXB를 통한, JAX-WS는 새로운 어태치먼트 스팩인 MTOM에 대한 지원을 추가한다. Microsoft는 SOAP with Attachments 스팩을 전혀 채택하지 않았다. 하지만 누구나 MTOM을 지원하기 때문에, 어태치먼트 상호 운용성은 현실이 되었다.
  • 핸들러 모델
    • 핸들러 모델은 JAX-RPC와 JAX-WS가 매우 다르다.
    • JAX-RPC 핸들러는 SAAJ 1.2에 기반하고 있다. JAX-WS 핸들러는 새로운 SAAJ 1.3 스팩에 기반하고 있다.
이제는 SOAP 1.2, XML/HTTP, WS-I Basic Profiles, Java 5에 대해 설명하도록 하겠다.
SOAP 인코딩
SOAP 인코딩은 웹 서비스 커뮤니티의 관심사에서 멀어지고 있다. WS-I 기본 프로파일에서 지원되지 않는다. 따라서, 자바 웹 서비스의 최신판인 JAX-WS는 SOAP 인코딩을 허용하지 않는다. JAX-RPC는 SOAP 인코딩을 지원하므로, SOAP 인코딩 메시지를 사용해야 한다면, JAX-RPC를 고수하라.
프로그래밍 모델 관점에서 볼 때, SOAP 1.1과 SOAP 1.2 사이에는 큰 차이는 없다. 자바 프로그래머로서 느끼게 되는 유일한 차이라면, 핸들러를 사용할 때이다. SAAJ 1.3이 업데이트 되어 SOAP 1.2를 지원한다.
SOAP 1.2의 변화와 마찬가지로, SOAP/HTTP와 XML/HTTP 메시지들 간에는 프로그래밍 모델 관점에서 볼 때 큰 차이가 없다. 유일한 차이는 핸들러를 사용할 때이다. 앞으로의 글에서 설명하겠다. HTTP 바인딩은 고유의 핸들러 체인과 메시지 콘텍스트 속성들을 갖고 있다.
JAX-RPC 1.1은 WS-I Basic Profile (BP) 1.0을 지원한다. 이후에, WS-I 멤버들은 BP 1.1을 개발했다. (관련 AP 1.0과 SSBP 1.0도 개발했다.) 이 새로운 프로파일은 소소한 문제들을 명확히 했고, 어태치먼트에 대해서 보다 명확히 정의를 내렸다. JAX-WS 2.0은 이 새로운 프로파일을 지원한다. 대부분의 경우, 이들의 차이점은 자바 프로그래밍 모델에는 영향을 미치지 않는다. 예외는 어태치먼트이다. WS-I는 어태치먼트에 대한 몇 가지 의문점을 해결하지 않은 채, 고유의 XML 어태치먼트 유형인 wsi:swaRef를 정의했다.
많은 사람들은 이 모든 프로파일들에 혼란을 겪는다. 혼란을 막으려면 히스토리가 필요하다.
WS-I의 첫 번째 기본 프로파일(BP 1.0)은 다양한 스팩들을 명확히 했다. 하지만, 완벽하지는 못했다. 특히 SOAP with Attachments (Sw/A)에 대한 지원은 여전히 혼란스럽다. WS-I 멤버들은 기본 프로파일을 기반으로 어태치먼트를 만들었고(BP 1.1), 그들이 놓쳤던 부분들을 픽스했다. 또한 기본 프로파일에 독자적인 보충을 직접 추가했다. AP 1.0 과 SSBP 1.0이다. AP 1.0은 Attachment Profile로서 Sw/A의 사용법을 기술하고 있다. SSBP 1.0 은 Simple SOAP Binding Profile이고, (Microsoft의 .NET 처럼) Sw/A를 지원하지 않는 웹 서비스 엔진을 기술하고 있다. WS-I가 보유하고, 작업 중인 나머지 프로파일들은 기본 프로파일들을 바탕으로 만들어지고 있다.
자바 언어에도 많은 변화가 있었다. JAX-WS는 다음에 의존한다. 주석, 제너릭, executor. JAX-WS가 이 새로운 기능에 어떻게 의존하는지를 다음 글에서 설명하겠다. 자바의 새로운 특징은 참고자료섹션에서 Java 5 링크를 참조하기 바란다.
JAX-WS 2.0은 JAX-RPC 1.1의 후속이다. 변하지 않은 부분들도 있지만, 프로그래밍 모델 대부분은 어느 정도는 변했다. 이 글에서 다룬 주제들은 후속 시리즈에서 계속 설명해 나갈 것이다. 다음 글에서는 JAX-RPC에서 JAX-WS로 옮겨야 하는 이유 또는 옮기지 말아야 하는 이유를 상세하게 비교 분석하겠다.
JAX-RPC 1.1을 고수해야 하는 이유:
  • 당분간 계속 유지하고 싶다면, 당분간은 JAX-RPC도 지원된다.
  • Java 5로 전향하기 싫을 경우
  • SOAP 인코딩 메시지를 보내거나 RPC/encoded 스타일의 WSDL을 보내야 하는 경우
JAX-WS 2.0으로 전향해야 하는 이유:
  • 새로운 메시지 지향 API를 사용해야 할 경우
  • MTOM을 사용하여 어태치먼트 데이터를 보내야 하는 경우
  • JAXB를 통해 XML 스키마를 더욱 잘 지원하기 위해
  • 웹 서비스 클라이언트에 비동기식 프로그래밍 모델을 사용하고 싶을 경우
  • SOAP 1.2 메시지를 핸들 할 수 있는 클라이언트나 서비스가 있어야 하는 경우
  • 웹 서비스에서 SOAP을 배제하고 XML/HTTP 바인딩만 사용하고 싶을 경우
  • 최신 기술을 사용하고 싶을 때


교육

제품 및 기술 얻기


Russell Butek은 IBM의 SOA 및 웹 서비스 컨설턴트이다. 한때는 IBM WebSphere 웹 서비스 엔진 개발자로서, 또한 JAX-RPC Java Specification Request (JSR) 전문가 그룹의 멤버로 활동했었다. Apache의 AXIS SOAP 엔진 구현에도 참여했다.

Nick Gallardo는 IBM 소프트웨어 엔지니어이다. 웹 서비스의 다양한 측면들을 연구하고 있다. 최근에는 JAX-WS 지원도 하고 있다. 이전에는, WebSphere와 Tivoli 플랫폼에서 작업했다.
작성자: 시간:
라벨: ,

댓글 없음:

댓글 쓰기

피드 구독하기: 댓글 (Atom)