 | |
|
난이도 : 중급 Brett D. McLaughlin, Sr., Author and Editor, O'Reilly Media, Inc.
2007 년 8 월 07 일 얼마 전까지만 해도, XML 작동 옵션은 SAX, DOM, 또는 자작(home-brewed) API로 제한되었습니다. 수 백 개의 개발자 친화적인 API들이 존재하는 요즘도, 개발자들은 XML에 대한 완벽한 제어권을 갖고 있다고는 볼 수 없습니다.
XML은 유연성에 관한 것이다.
XML의 기원부터 거슬러 올라가 장황한 역사를 짚어가지는 않겠지만, 필자가 강조하고 싶은 것은 XML이 원래는 유연성에 관한 것이라는 점이다. XML은 벤더 중립적인 포맷을 통해서 데이터를 표현한다. 이 포맷은 XML 스팩에 대한 이해를 기반으로, 애플리케이션에 의해서 쉽게 만들어지고, (다른) 애플리케이션들에 의해 소비된다.
좀더 구체적으로 말해서, 여러분이 XML을 사용하고 있고, 어떤 엘리먼트와 애트리뷰트를 사용하고 있는지를 말해주면, 필자는 그러한 XML을 읽고 실행하는 코드를 매우 빠르게 만들 수 있다. 그 반대의 경우도 마찬가지다. 필자가 제약 조건 모델(constraint model)을 제공한다면(일반적으로, DTD 또는 XML Schema의 형태로), 여러분도 빠르게 필자의 데이터로 작업할 수 있다.
원래의 API들도 이러한 유연성으로 관리된다.
최초의 XML API가 등장했을 때에는, 뼈대밖에 없었다. Simple API for XML (SAX)의 초기 버전과 Document Object Model (DOM)(참고자료)는 작동의 측면에서 매우 기본적이었다. 하나의 엘리먼트에서 데이터를 가져다가, 이것의 자식들로 작업을 하고, 애트리뷰트의 값을 알아내고…이것이 전부였다. XML의 어휘 구조를 다루는 것 외에는, API들은 많은 기능들을 제공하지 않았다.
XML 초기에는 이것으로도 충분했다. 프로그래머들이 C와 어셈블러를 사용하여 저급의 비트와 바이트를 관리하던 것과 마찬가지로, SAX는 XML API 없이도, XML 문서에 잘 맞고—매우 기본적인 포맷으로 된 데이터—프로그램들은 원하는 모든 것을 수행할 수 있었다.
|
JAXP: 그릇된 해결책?
여러분이 프로그래밍에 신중을 기한다면, SAX와 DOM은 벤더 중립성을 유지할 수 있다. 프로퍼티 파일들과 약간의 런타임 검사를 통해, 벤더 클래스와 파일 이름으로부터 SAX와 DOM 코드를 깨끗하게 유지할 수 있다.
|
|
래퍼 API의 등장
저급의 컨트롤에서 탈피하여—더욱 개발자 친화적인 API를 향한 첫 번째 움직임은 —JAXP(Sun의 Java™ API for XML Processing)였다. JAXP는 XML 파서가 사용되었던 것과 관련이 있는, 벤더 스팩의 상세를 SAX와 DOM 코드에서 제거하는 것이 목표였다.
하지만, JAXP는 편의상, SAX와 DOM에 이미 존재하는 기능을 포함하고 있는 여러 헬퍼 메소드를 제공했다. Sun은 자바 시장을 주름잡고 있기 때문에, 개발자들은 이러한 헬퍼 메소드를 서둘러 사용하기 시작했고, SAX와 DOM에는 비교적 덜 의존하게 되었다.
프로그래머는 여전히 SAX의 근본 원리를 알아야 하지만(ContentHandler가 무엇인지, 콜백 메소드를 구현하는 방법 등), JAXP는 이러한 상세들을 많이 추상화 했다. 사실, SAX의 어휘 핸들러를 설정하는 것 같은 특정 액션을 수행하려면, JAXP를 우회하고 SAX로 직접 작업해야 했다.
그리고 지금의 데이터 바인딩, JDOM, 그리고 많은 API들
거의 10년이 지난 지금, 많은 API들을 사용할 수 있게 되었다. SAX와 DOM 그리고 JAXP 외에도, JDOM, XOM, dom4j, StAX 등을 사용하여 XML과 (아주) 직접적으로 작업할 수 있게 되었다. Zeus, Castor, JAXB 같은 데이터 바인딩 API들을 사용하여 XML에 대해 많은 것을 알지 못해도 XML을 다룰 수 있게 되었다. 스트링 보다는 XML 문서가 논리적 데이터로서 나타내는 데이터로 작업할 수 있게 되었다. Eclipse 같은 프레임웍은 이 모든 일들을 수행하고, 여러분은 그저, XML을 포인팅, 클릭, 수정하면 된다. 말 그대로 수백 가지의 선택권이 있다. (XSLT를 이용한 XML 변형 조차 다루지 못했다.)
여전히 유연한가?
XML에 사용할 수 있는 많은 API들을 생각한다면, 자바와 XML 프로그래머들은 전보다 더 많은 유연성을 보장받고 있는 것 같다. 결국, 이 많은 선택권이 유연성을 드러내는 것 아닌가? 그렇다면 이제부터 구체적으로 유연성 부분에 대해 살펴보도록 하자.
파서의 유연성
여러분이 클래스 파일을 갖고 있고, 그것이 여러분이 선택했던 API와 함께 제공된다면 원하는 어떤 XML 파서라도 사용할 수 있다. 따라서, XML4J에서 Sun의 오래된 Crimson 파서에서 Apache Xerces (version 1 또는 2)로 쉽게 변환한다는 관점에서, 이는 단순하다. JAXP 같은 API들이 이를 쉽게 만들었고(이 모든 새로운 API들이 나타나기 전에 SAX나 DOM에서 사용할 수 있는 것에 대해 사이드바를 통해 설명했다.), 많은 데이터 바인딩 API에서, 여러분은 파싱이 진행 중이라는 것 조차 모른다. 이 모든 것이 뒤에서 발생한다. 따라서, 여러분은 여러분이 원하는 어떤 파서라도 사용할 수 있다. 이 정도면 파서의 유연성은 검증된 것이다.
사용상의 유연성
수 많은 XML API들은 데이터를 다룰 수 있는 여러 가지 방법을 제공한다. SAX와 DOM을 사용하면, 문서에서 미가공 데이터에 쉽게 접근할 수 있다. 조금 덜 하지만 JAXP도 마찬가지다. (XML 주석이나 DTD의 문법 같은 것을 다루기 위해서는 약간의 훈련이 필요하다고 언급한 바 있다.) 여러분이 데이터 바인딩 API를 사용한다면, XML의 트래핑 없이 XML 문서에서 데이터 작업을 할 수 있다. person 엘리먼트는 Person 객체가 되고, getAge()를 사용하여 age 애트리뷰트의 값을 얻을 수 있다. 많은 경우, XML 문서에서 데이터를 사용하는 방식에 따라, XML을 어느 정도 알고 있느냐에 따라서 API를 선택할 수 있다. 이로써 사용상의 유연성도 검증되었다.
에러 핸들링 차원의 유연성
이제는, 고급 API의 유연성이 문제를 일으키는 부분에 대해 살펴보자. Sun의 JAXB 같은 API의 데이터 바인딩 오퍼링에서, XML 문서의 미가공 스트링, 엘리먼트, 애트리뷰트 등 여러 레이어에서 작업한다. 결국, 문서에 있는 것들이 정확하지 않게 포맷팅 되면, 문제 해결에 유연성을 발휘할 수 없다. 일반적으로, 마샬링과 언마샬링 에러가 생기고, XML을 픽스해야 하고 프로세스를 재실행 해야 한다. (또는 호출 프로그램에 예외를 던져야 하는데, 이것 또한 마찬가지다.) 실제로 에러를 픽스하고 파서에서 상세 정보를 얻는 것은 어떤가? 이는 고급 API의 범위가 아니다. 따라서 이 부분은 불완전하다.
XML 문서로 작업할 때의 유연성
앞서 언급했던 사용상의 유연성은 XML 문서로 작업할 때의 유연성과 같다. 비록 똑 같은 경우는 아니지만 말이다. 많은 새로운 (사용하기 쉬운) API에서, XML 문서의 데이터로 작업한다.—가끔은 XML로서가 아닌, 객체나 애트리뷰트로서 말이다. XML 문서에서의 작업이 의미하는 것은 문서의 조각들을 직접 변경, 수정 또는 제거할 수 있고, 엘리먼트 이름, 애트리뷰트, 심지어 주석과 프로세싱 명령어를 직접 다룰 수 있다는 의미이다.
이러한 수준의 조작과 유연성이 필요 없는 것처럼 보이겠지만, 프로그래밍과의 유사점이 다시 떠오른다. C와 어셈블리 언어를 통해 "하드코어" 코더들은 가장 낮은 수준의 컴퓨터 프로그래밍 작업을 수행한다. SAX와 DOM 같은 API들을 통해, 하드코어 자바와 XML 프로그래머는 XML 문서에서 자신들이 원하는 무엇이든 다 수행할 수 있다. 또한, 대부분의 게임들이 C나 어셈블리 언어로 구현되는 것처럼, 추가 파워가 미가공의 속도, 성능, 해킹으로 변하기 때문에 SAX와 DOM은 프로그래머에게 JAXB나 JDOM 같은 고급 레벨 API 보다 훨씬 더 많은 힘을 준다. 이러한 고급 API들은 많은 장점들을 제공하지만, 실제 XML 문서에서 직접 작업할 수 있는 많은 유연성은 제공하지 못한다.
맺음말
지금까지는 표면적인 부분만을 다루었다. 요즘 XML 코드를 누가 사용하는지, 어떤 API를 사용하는지 모르기 때문에 실행 코드에 대해서는 다루지 않았다. 수백, 수천, 수만 명의 사람들이 여전히 SAX와 DOM을 사용하여 startProcessingInstruction() 메소드를 작성하거나 또는 데이터 바인딩과 헬퍼 API를 완전히 손안에 넣었는가? developerWorks 편집 스태프들도 마찬가지인지 궁금하다.
여러분이 아직도 XML에 대해서 완벽한 제어권을 갖고 있다고 믿고 있는가? 필자는 이 질문을 SAX가 신속한 XML 읽기에 대한 유일한 옵션이었고, DOM이 XML 문서를 객체 폼으로 다룰 수 있는 선택이었던 초기 시절부터 XML을 다루었던 프로그래머들에게 묻고 싶다. 여러분이 고급 레벨에서 작업하고 있으며, 그것에 아무런 문제가 없다고 생각하는가? 아니면, 우리 모두 Turbo Pascal 프로그래머가 되어서, 선택된 일부 사람들만 ASM 터미널의 스택에 개입하는가?—이 문제를 포럼(영문 페이지)에서 논의해 주기 바란다.
참고자료 교육
제품 및 기술 얻기
토론
필자소개 | 
| | Brett McLaughlin은 Logo 시절부터 컴퓨터를 다루었다. 현재는 자바와 XML 커뮤니티에서 가장 유명한 작가 이자 프로그래머가 되었다. Nextel Communications와 Allegiance Telecom, Inc.에서 인프라스트럭처를 구현한 바 있다. Lutris Technologies에서는 애플리케이션 서버를 작성했고, 최근에는 O'Reilly Media, Inc.에서 이와 관련한 책을 집필 및 편집하고 있다. 그의 신작 Java
Java 5.0 Tiger: A Developer's Notebook
은 자바 기술에 대한 최신 버전이고, 거의 고전이라고 할 수 있는
Java and XML
은 자바 언어에서 XML 기술을 사용하는 방법을 다룬 탁월한 저서로 인정받고 있다. |
기사에 대한 평가
| |
