* Annotation
코드에 관한 데이터를 제공하며, 효용성으로는 문서화, 컴파일러 체크, 코드분석에서 사용한다.

annotation은 데코레이션, 클래스, 인터페이스, 필드에 적용되어 툴과 라이브러리를 활용할 수 있게 함으로써, 코드에 명시적 프로그래밍을 줄이고 좀 더 많은 선언문을 제공한다.   annotation은 프로그램의 의미적인 부분에 직접 영향을 주지 않고, 툴이 프로그램을 어떻게 다루어야 하는지에 알려준다. 툴이 실행 중인 프로그램의 의미적인 부분에 영향을 줄 수 있다.
annotation은 런타임에 소스 파일 또는 클래스 파일 등에서 읽을 수 있다. annotation은 javadoc 태그의 기능을 보안하고 있다. 마크업을 문서 생성시 필요한 정보를 제공하기 위해 사용하고자 할 경우, javadoc 태크 또는 annotation을 사용해야 한다. 일반적으로 어플리케이션 프로그래머는 annotation 타입을 정의하는 경우가 거의 없지만, annotation 타입을 정의하는작업은 어렵지 않다.

  1. 컴파일러가 에러를 탐지하거나 경고등을 무시하는 등등의 용도
  2. 컴파일 또는 설치시에 소프트웨어 도구가 코드, XML 파일 등을 처리하기 위한 용도
  3. 실행시 별도의 처리 루틴이 필요한 경우(실행 루틴 점검 등과 같은)


* Annotation의 종류
  Marker Annotation : 이름으로 구분하기 위하여 사용하며 추가적인 데이터를 필요하지 않음
  Single-Value Annotation : 간단한 신텍스를 사용하며 단일 데이터를 필요로 함
  Full Annotation : 복잡한 신텍스이며, 다중 데이터를 사용하며 name=value 형태를 취함
   --> 데이터가 Array 인 경우 "{ }"를 이용


* Annotation Type의 정의
  1. Annotation 타입 선언은 인터페이스를 선언하는 방법과 유사하다.
  2. Annotation 타입 선언 시에는 interface 키워드 앞에 @ 기호를 붙인다.
  3. 메소드는 파라메터를 가질 수 없다.
  4. 메소드는 throws 절을 가질 수 없다.
  5. 메소드의 리턴 타입 : 프리미티브(Primitive), String, Class, 열거형(Enum), annotation, 앞에서 열거한 타입들의 배열
  6. 메소드는 기본값(Default Value)를 가질 수 있다.


* 기본 Annotation
  @Deprecated : 더 이상 사용하지 말아야할 메소드를 알림 (비추천 메소드)
  @Documented
  @Retention(RetentionPolicy.RUNTIME)
  public @interface Deprecated {

   }

  @Override : 상위 요소를 오버라이드 할 것임을 알림
  @Target(ElementType.METHOD)
  @Retention(RetentionPolicy.SOURCE)
   public @interface Override {

   }


  @SuppressWarnings : 경고를 하지 않도록 억제 시킴
     - unchecked : 비확인
     - deprecate : 비사용


   @Target({TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE})
   @Retention(RetentionPolicy.SOURCE)
   public @interface SuppressWarnings {
       String[] value();
   }



* Built-in Annotation
  Target : Annotation의 대상을 무엇으로 할 것인지를 기록 (CONSTRUCTOR, FIELD, METHOD, PACKAGE, ...)
   - ANNOTATION_TYPE : annotation 타입(Annotation Type)선언
    - CONSTRUCTOR : 생성자 함수 선언
    - FIELD : 필드 선언(enum 상수 포함)
   - LOCAL_VARIABLE : 로컬 변수 선언
    - METHOD : 메소드 선언
    - PACKAGE : package 선언
    - PARAMETER : parameter 선언
    - TYPE : 클래스, 인터페이스 (annotation타입(AnnotationType)포함), enum선언


   @Documented
   @Retention(RetentionPolicy.RUNTIME)
   @Target(ElementType.ANNOTATION_TYPE)
   public @interface Target {
       ElementType[] value();
   }


  Retention : 어느 과정에서 Annotation을 사용할 것인지를 기록 (여러개의 값 중 선택 가능) (SOURCE, CLASS, RUNTIME)
   - SOURCE : 소스파일에서만 사용하며 컴파일 이후는 사용하지 않음
    - CLASS : 컴파일 과정까지 사용하며 Runtime에서는 사용하지 않음
    - RUNTIME : Runtime에서까지 사용함


   @Documented
   @Retention(RetentionPolicy.RUNTIME)
   @Target(ElementType.ANNOTATION_TYPE)
   public @interface Retention {
      RetentionPolicy value();
   }

  Documented : Javadoc에 포함(문서화)되어야 함을 알리는 Marker Annotation

   @Documented
   @Retention(RetentionPolicy.RUNTIME)
   @Target(ElementType.ANNOTATION_TYPE)
   public @interface Documented {
   }


  Inherited : 하위 클래스에 상속되어야 함을 알리는 Marker Annotation

   @Documented
   @Retention(RetentionPolicy.RUNTIME)
   @Target(ElementType.ANNOTATION_TYPE)
   public @interface Inherited {

   }



* Custom Annotation
  개발자가 정의하는 어노테이션으로 class 형태로 만들어진다. 어노테이션의 선언은 @interface 로 한다.
  이름 앞에 '@'문자가 오는 것 외에는 기본적으로 인터페이스를 선언하는 것과 동일(메소드들의 내용은 없고 형태만 선언)하다.
  default 가 찍히지 않은 메소드는 필수로 입력해야 한다

   @Retention(RetentionPolicy.RUNTIME)
   public @interface Maker {
       int num();
       String id();
       String name();
       String date() default "unsigned";
   }


   @Maker(num=1, id="dryang", name="junsun.yang")
   public class UseMaker {
        ...
   }

'Program > Java' 카테고리의 다른 글

Spring MVC - Annotation Base HandlerInterceptor  (0) 2009.12.27
Spring MVC Annotation 기초  (2) 2009.12.27
About JAXB  (0) 2009.12.27
StringUtils  (0) 2009.12.22
Annotation (since tiger / 1.5)  (0) 2009.12.15

 - Terms

원래, 마샬이란 말을 지키거나, 축제 준비를 위하여 물건들을 가지런히 하는 것을 가리킨다.

의식에서, 마샬링이란 여러 벌의 코트 팔들이 하나의 구도를 이루도록 배열하는 것이다. 군에서의, 마샬링은 전투준비를 위해 군대를 모으고 정렬시키는 것을 의미한다.

컴퓨터 프로그래밍에서, 마샬링은 하나 이상의 프로그램 또는 연속되어 있지 않은 저장 공간으로부터 데이터를 모은 다음, 데이터들을 메시지 버퍼에 집어넣고, 특정 수신기나 프로그래밍 인터페이스에 맞도록 그 데이터를 조직화하거나, 미리 정해진 다른 형식으로 변환하는 과정을 말한다.

마샬링은 대체로, 어떤 한 언어로 작성된 프로그램의 출력 매개변수들을, 다른 언어로 작성된 프로그램의 입력으로 전달해야 하는 경우에 필요하다.

 - HelloPC

 

마샬링(marshalling)은 클라이언트가 사용하고자 하는 객체의 형태에 관계없이 같은 방식으로 인터페이스 함수를 사용할 수 있게 하는 메카니즘이다.

마샬링은 두 가지의 단계를 포함한다.

서버의 인터페이스 포인터를 다른 프로세스의 클라이언트에서 사용할 수 있게 한다.
클라이언트가 인터페이스의 함수에 실은 함수 인자들을 정확하게 서버로 전달해야 한다.
원칙적으로 클라이언트는 in-proc서버만을 사용할 수 있다. 원격에 있는 서버를 사용하기 위해서는 그 서버를 대행하면서, 클라이언트와 같은 프로세스에서 실행될 수 있는 프록시나 핸들러가 필요하다.

프록시는 원격의 서버를 순수하게 대행한다는 의미이지만, 핸들러는 대행을 할 수도 있고, 자신이 구현할 수도 있는 혼합형태이다. 어쨌든 둘 다 원격의 객체와 클라이언트의 연결을 위한 대행의 역할을 한다.

클라이언트가 서버의 함수를 호출할 때 넘겨지는 인자, 그리고 서버 함수의 리턴값은 프로세스의 경계를 넘어서 유효해야 한다. 이 측면 또한 마샬링이 개입되는 곳이다.

인자의 형태에 따라 다른 형태의 마샬링이 일어난다. DWORD같이 간단한 타입은 직접 복사가 된다. 그러나 어떤 영역을 가리키는 포인터가 넘어갈 때는 그 영역 전체가 프로세스 경계를 넘어 복사되어야 한다.

 커스텀 마샬링과 표준 마샬링

커스텀 마샬링의 경우 객체는 프록시/스텁에 자신의 인터페이스(인자)에 대한 마샬링 정책을 명확하게 정의해야 한다. 커스텀 마샬링은 주로 효율을 높이기 위한 목적으로 사용된다.

OLE는 또한 표준 마샬링을 지원한다. 즉 표준 프록시와 표준 스텁을 제공하는데, 이 둘간에는 표준 RPC를 통해 통신한다.

표준 프록시와 표준 스텁은 각각의 인터페이스를 처리하는 작은 코드인 인터페이스 마샬러의 집합이다. 그래서 프록시는 프록시 매니저로, 스텁은 스텁 매니저로 불린다. 또한 마샬러는 인터페이스 프록시, 인터페이스 스텁이라고 불린다. 용어의 혼동을 피하기 위해 인터페이스 프록시는 facelet으로, 인터페이스 스텁은 stublet으로 부른다.

 마샬링 기본 메카니즘
클라이언트는 CoGetClassObject를 실행하여 원격 서버를 실행하고, 원격 서버는 CoRegisterClassObject함수를 통해 마샬링을 시작하게 된다. 이 과정을 통해 일단 서버의 IClassFactory가 클라이언트에 넘겨진다.

이 과정을 자세히 살펴보면 다음과 같다.

CoRegisterClassObject안에서 COM은 객체에게 클라이언트 프로세스에 포함될 프록시의 CLSID를 요구한다. 만일 객체가 CLSID를 제공하지 않을 때는 COM은 표준 마샬링 프록시를 사용한다.
COM은 객체에게 마샬링 패킷을 요구한다. 마샬링 패킷은 프록시가 객체와 연결할 때 필요한 정보들을 담고 있다. 객체가 제공하지 않으면 역시 COM은 표준 패킷을 사용한다.

COM은 프록시 CLSID와 마샬링 패킷을 클라이언트에 넘긴다.

클라이언트의 프로세스에서 COM은 1에서 얻어진 CLSID로 프록시를 생성하고, 2에서 얻어진 마샬링 패킷을 가져온다.

이제 프록시는 클라이언트가 CoGetClassObject에서 요구한 인터페이스의 포인터를 넘긴다. 클라이언트는 이 포인터(보통 IClassFactory)로 실제 객체를 생성할 수 있다.
1,2과정은 CoMarshalInterface함수가 담당하고, 3과정은 Service Control Manager가 담당한다. 4,5과정은 CoUnmarshalInterface가 담당한다.
 

- Document

원래, 마샬이란 말을 지키거나, 축제 준비를 위하여 물건들을 가지런히 하는 것을 가리킨다. 의식에서, 마샬링이란 여러 벌의 코트 팔들이 하나의 구도를 이루도록 배열하는 것이다. 군에서의, 마샬링은 전투준비를 위해 군대를 모으고 정렬시키는 것을 의미한다.
컴퓨터 프로그래밍에서, 마샬링은 하나 이상의 프로그램 또는 연속되어 있지 않은 저장 공간으로부터 데이터를 모은 다음, 데이터들을 메시지 버퍼에 집어넣고, 특정 수신기나 프로그래밍 인터페이스에 맞도록 그 데이터를 조직화하거나, 미리 정해진 다른 형식으로 변환하는 과정을 말한다.
마샬링은 대체로, 어떤 한 언어로 작성된 프로그램의 출력 매개변수들을, 다른 언어로 작성된 프로그램의 입력으로 전달해야 하는 경우에 필요하다.
마샬링(marshalling)은 클라이언트가 사용하고자 하는 객체의 형태에 관계없이 같은 방식으로 인터페이스 함수를 사용할 수 있게 하는 메카니즘이다.
마샬링은 두 가지의 단계를 포함한다.

1) 서버의 인터페이스 포인터를 다른 프로세스의 클라이언트에서 사용할 수 있게 한다.
2) 클라이언트가 인터페이스의 함수에 실은 함수 인자들을 정확하게 서버로 전달해야 한다.
원칙적으로 클라이언트는 in-proc서버만을 사용할 수 있다. 원격에 있는 서버를 사용하기 위해서는 그 서버를 대행하면서, 클라이언트와 같은 프로세스에서 실행될 수 있는 프록시나 핸들러가 필요하다.
프록시는 원격의 서버를 순수하게 대행한다는 의미이지만, 핸들러는 대행을 할 수도 있고, 자신이 구현할 수도 있는 혼합형태이다. 어쨌든 둘 다 원격의 객체와 클라이언트의 연결을 위한 대행의 역할을 한다.
클라이언트가 서버의 함수를 호출할 때 넘겨지는 인자, 그리고 서버 함수의 리턴값은 프로세스의 경계를 넘어서 유효해야 한다. 이 측면 또한 마샬링이 개입되는 곳이다.
인자의 형태에 따라 다른 형태의 마샬링이 일어난다. DWORD같이 간단한 타입은 직접 복사가 된다. 그러나 어떤 영역을 가리키는 포인터가 넘어갈 때는 그 영역 전체가 프로세스 경계를 넘어 복사되어야 한다.

< 커스텀 마샬링과 표준 마샬링 >
커스텀 마샬링의 경우 객체는 프록시/스텁에 자신의 인터페이스(인자)에 대한 마샬링 정책을 명확하게 정의해야 한다. 커스텀 마샬링은 주로 효율을 높이기 위한 목적으로 사용된다.
OLE는 또한 표준 마샬링을 지원한다. 즉 표준 프록시와 표준 스텁을 제공하는데, 이 둘간에는 표준 RPC를 통해 통신한다.
표준 프록시와 표준 스텁은 각각의 인터페이스를 처리하는 작은 코드인 인터페이스 마샬러의 집합이다. 그래서 프록시는 프록시 매니저로, 스텁은 스텁 매니저로 불린다. 또한 마샬러는 인터페이스 프록시, 인터페이스 스텁이라고 불린다. 용어의 혼동을 피하기 위해 인터페이스 프록시는 facelet으로, 인터페이스 스텁은 stublet으로 부른다.

< 마샬링 기본 메카니즘 > 클라이언트는 CoGetClassObject를 실행하여 원격 서버를 실행하고, 원격 서버는 CoRegisterClassObject함수를 통해 마샬링을 시작하게 된다. 이 과정을 통해 일단 서버의 IClassFactory가 클라이언트에 넘겨진다.
이 과정을 자세히 살펴보면 다음과 같다.

1) CoRegisterClassObject안에서 COM은 객체에게 클라이언트 프로세스에 포함될 프록시의 CLSID를 요구한다. 만일 객체가 CLSID를 제공하지 않을 때는 COM은 표준 마샬링 프록시를 사용한다.
2) COM은 객체에게 마샬링 패킷을 요구한다. 마샬링 패킷은 프록시가 객체와 연결할 때 필요한 정보들을 담고 있다. 객체가 제공하지 않으면 역시 COM은 표준 패킷을 사용한다.
3) COM은 프록시 CLSID와 마샬링 패킷을 클라이언트에 넘긴다.
4) 클라이언트의 프로세스에서 COM은 1에서 얻어진 CLSID로 프록시를 생성하고, 2에서 얻어진 마샬링 패킷을 가져온다.
5) 이제 프록시는 클라이언트가 CoGetClassObject에서 요구한 인터페이스의 포인터를 넘긴다. 클라이언트는 이 포인터(보통 IClassFactory)로 실제 객체를 생성할 수 있다.

1,2과정은 CoMarshalInterface함수가 담당하고, 3과정은 Service Control Manager가 담당한다. 4,5과정은 CoUnmarshalInterface가 담당한다.

'Program' 카테고리의 다른 글

아스키(ASCII) 코드 표  (0) 2009.12.22
WML - 기본 Tag  (0) 2009.12.16
input tag  (0) 2009.12.16
[마틴파울러]Refactoring에서 나온 관련 좋은 문구  (0) 2009.12.15
Java Architecture for XML Binding (JAXB)
번역 : 이원찬

Ed Ort and Bhakti Mehta


이 기사는 다음의 주제들을 다룰것입니다.

- JAXB란 무엇인가?
- 예제1 : XML문서 접근
- 스키마 바인딩
- 다큐먼트 언마샬
- 예제2 : XML문서 생성
- 스키마 바인딩
- 내용트리 작성
- 내용트리 마샬
- 예제3 : XML문서 갱신
- 바인딩 커스터마이징
- 별도의 잇점
- 예제 실행

What's JAXB?

Extensable Markup Language(XML)과 자바기술은 개발자가 인터넷을 통해 데이터와 프로그램의 교환을 돕는 자연스러운 파트너이다. 이것은 XML이 이기종 시스템들과 데이터를 교환하기 위한 표준으로 부상했으며 자바기술은 포터블 어플리케이션 플랫폼을 제공하기 때문이다. 이러한 파트너쉽은 특히 웹서비스에 대해 매우 중요하다. 이것은 사용자와 어플리케이션 개발자의 요구에 따른 프로그램의 기능을 어디서, 어디로든지(from anywhere to anywhere) 웹상에서 제공할 수 있다. XML과 자바기술은 웹서비스와 어플리케이션을 구현하기 위한 이상적인 도구로 인정받고 있다.

그러나 실제 이 둘을 어떨게 조합할 것인가? 더 구체적으로 말하자면 어떻게 자바 프로그램으로 XML문서(이것은 XML태그 데이터를 포함한 파일을 말한다) 에 접근하고 이를 이용할 것인가 하는것이다. 이를 구현하기 위한 가장 보편화된 방법중의 하나는 Simple API for XML(SAX)나 Document Object Model(DOM)과 같은 파서의 도움을 받는것이다. 이 파서들은 Java API for XML Processing(JAXP)에 포함되어 제공된다. 자바 개발자는 어플리케이션에서 JAXP API를 통해 SAX나 DOM을 호출하여 파싱된 데이터(이것은 문서를 스캔하고 논리적으로 여러개의 조각으로 나누는것이다.) 를 얻을 수 있다. 파싱된 데이터는 어플리케이션 이용될 수 있다. SAX의 경우는 파서가 문서의 시작점에서 시작된다. 그리고 문서의 각 부분을 순차적으로 어플리케이션에 전달한다. 메모리에는 아무것도 남기지 않는다. 어플리케이션은 파서로부터 데이터를 받을때에는 어떤 액션을 취할 수 있지만 어떤 데이터도 메모리상에 두고 취급 할 수 없다. 예를들어 이것은 데이터를 메모리상에서 갱신하고 갱신된 데이터를 XML파일로 리턴할 수 없다.

DOM접근법으로, 파서는 객체의 트리를 생성한다. 이 트리는 문서상에 존재하는 컨텐츠와 데이터의 정렬을 그대로 표현한다. 이 경우 트리는 메모리상에 존재한다. 어플리케이션은 트리를 이용해 필요한 데이터에 접근하고 적절한 연산을 수행한다.

지금 개발자들은 XML문서를 더 쉽게 이용한 수 있는 또다른 자바API를 만났다.(Java Architecture for XML Binding(JAXB)). 이 API에 대한 구현은 지금 Java Web Services Developer Pack v.1.1(또는 그 이상 버젼)에서 구할 수 있다.

이제부터 실제 JAXB가 어떻게 행동하는지, SAX와 DBM기반 처리와 비교해 보겠다.

An Example : Accessing an XML Document

당신은 books.xml과 같은 XML문서를 접근하고 출력하는 자바 어플리케이션을 개발할 필요가 있다. 이 문서는 책이름, 저자, 요약설명, ISBN과 같은 책에 관한 데이터를 포함하고 있다. 당신은 SAX 또는 DOM으로 XML문서에 접근하여 데이터를 출력할 수 있다. 예를들어, SAX를 사용한다면 다음과 같은 절차를 따르게된다:

먼저 SAX파서를 생성하는 프로그램을 작성하고 그 파서로 XML문서를 파싱한다. SAX파서는 문서의 처음부터 시작한다. 파서가 XML문서의 시작을 알리는 태그와 같은 특정 신호를 받았을때(SAX용어로, 이벤트라 한다) 호출한 프로그램은 해당 데이터를 이용할 수 있다.

컨텐트 핸들러를 생성하라. 이 핸들러는 이벤트가 발생할때마다 파서에 의해 호출되는 메소드를 정의한다. 이러한 콜백 메소드들은 데이터를 받을때 주로 적절한 액션을 수행한다.

예를들어, 여기 JAXP를 이용하여 XML문서를 파싱하고 생성하는 프로그램이 있다. 프로그램은 MyContentHandler라는 컨텐트핸들러를 이용한다. 이 핸들러는 SAX파서를 이용해 전달받은 데이터를 출력한다.

이제 JAXB를 이용하여 어떻게 books.xml과 같은 XML문서를 처리하고 데이터를 출력하는지 살펴보자. JAXB를 이용하여 당신은 다음과 같은 일을 할 수 있다:

* XML문서를 위한 스키마를 바인딩한다.
* 문서를 언마샬하여 자바 객체로 컨텐츠를 생성한다. 자바객체는 컨텐츠를 표현하고 XML문서형태로 정리된다. 이것은 당신의 프로그램에서 직접 이용할 수 있다.

마샬링이 끝나고 프로그램은 XML문서상에 있는 데이터에 접근하고 출력할 수 있다. 이것은 자바 컨텐츠 객체에 접근하여 손쉽게 출력된다. 여기에는 파서를 생성하고나 이용하지 않는다. 그리고, 컨텐츠 핸들러나 콜백 메소드도 사용되지 않는다. 이것은 개발자가 XML또는 XML처리에 대해 알지 못하여도 XML데이터를 처리할 수 있다는 것을 의미한다.

Bind the Schema

JAXB는 XML문서를 자바형식의 프로그램으로 표현하여 자바 프로그램으로 부터 XML문서에 대한 접근을 손쉽게 한다. 이를 위한 첫번째 단계는 XML문서에 해당하는 스키마를 이와 상응하는 자바클래스들로 바인딩 하는것이다.

Schema: 스키마는 XML스펙이다. 이것은 XML문서에 허용가능한 컴퍼넌트화 컴퍼넌트간의 관계를 관리한다. 예를들어, 스키마는 각 요소(element)들을 구분한다. 그것은 XML문서에 표현된다. 이것이 반드시 어떤 순서로 보여져야 한다거나, 어떤 속성(attribute)을 가질 수 있는지, 어떤 요소가 다른 요소로 확장되는지 구분한다. XML문서는 반드시 XML스키마를 가질 필요는 없다. 스키마가 정확한 XML문서 형태를 갖추었는지 확인 하는 절차가 필요하다. JAXB는 당신이 접근하고자 하는 XML문서는 스키마를 가지고 있다. 이 스키마는 W3C XML Schema Language오 생성되었다.

이 예를 가정해 보자. books.xml문서는 books.xsd라는 W3C XML Schema를 가지고 있다. 이 스키마는 이라는 이름의 컴플렉스타입의 요소를 정의한다. 이것은 이 요소가 자식요소를 가진다는 것을 의미한다. 이 경우 요소이다. 각 요소는 , , 등과 같은 자식요소를 가지고 있다.

바인딩: 스키마를 바인딩한다는 말은 스키마를 표현하는 자바 클래스의 집합을 생성한다는 의미이다. 모든 JAXB구현은 바인딩 컴파일러라 불리는 스키마를 바인딩하기 위한 도구를 제공한다. (바인딩 컴파일러의 사용법은 각기 구현에 따라 다르다) 예를들어, JAXB레퍼런스 구현은 스크립트롤 통해 호출되는 바인딩 컴파일러를 제공한다. 당신이 books.xsd 스키마를 JAXB레퍼런스 구현에서 제공하는 바인딩 컴파일러를 이용하여 바인딩 하기를 원한다고 가정하자. 당신이 솔라리스 운영체제 환경에 있다면 당신은 스키마를 바인딩하기 위해 다음과 같이 스크립트를 이용할 수 있다.

xjc.sh -p test.jaxb books.xsd -d work

-p 옵션은 생성된 클래스를 위한 패키지를 구분하고 -d 옵션은 클래스가 저장될 디렉토리를 구분한다. 이 명령으로 클래스들은 test.jaxb. 라고 work 디렉토리 아래에 패키지된다.

바인딩 컴파일러는 인터페이스 집합과 그 인터페이스를 구현하는 클래스들을 생성할 책임을 가지고 있다. 다음은 books.xsd 스키마를 위해 생성된 인터페이스들이다:

- CollectionType.java 요소의 (unnamed)Complex type을 나타낸다.
- Collection.java 요소를 나타낸다.
- BookType.java BookType Complex type을 나타낸다.
- ObjectFactory.java 인터페이스의 인스턴스를 생성하기위한 메소드들을 가지고있다.

다음의 클래스들은 인터페이스를 구현한다. (이 구현들은 impl서브디렉토리에 생성된다.) 이 클래스들은 구현중심이라는 것을 명심하라. 클래스들은 구현 중심이므로 하나의 JAXB구현에서 바인딩 컴파일러에 의해 생성된 클래스들은 또다른 JAXB구현에 대해서는 재대로 작동하지 않을 것이다. 그러므로, 다른 JAXB를 구현하기 위해서는 스키마를 바인딩 컴파일러와 함께 다시 재바인딩 해주어야 한다.

- impl/CollectionTypeImpl.java CollectionType.java에 기술된 CollectionType인터페이스를 구현한다.
- impl/CollectionImpl.java Collection.java에 기술된 Collection을 구현한다.
- impl/BookTypeImpl.java BookType.java에 기술된 BookType을 구현한다.

This compiles all of the interfaces and classes in the test.jaxb package generated by the binding compiler.

생성된 모든 클래스들은 book.xsd스키마 전체를 나타낸다. 클래스의 get과 set메소드는 스키마에 명시된 요소와 속성의 타입에 따라 데이터를 넣거나 가져오는데 사용된다.

이제 당신은 생성된 인터페이스와 클래스들을 컴파일 할 수 있다. 예를들어 :

javac test/jaxb/*.java test/jaxb/impl/*.java

이 컴파일은 test.jaxb 패키지에 포함된 모든 클래스들과 인터페이스를 컴파일 한다.

Unmarshal the Document

XML문서를 언마샬 하는것은 컨텐츠객체의 트리를 생성하는 것이다. 이것은 문서의 컨텐츠와 구성을 표현한다. 컨텐츠 트리는 DOM기반의 트리가 아니다. 사실, JAXB를 통해 생성된 컨텐츠 트리는 DOM기반 트리에 비해 더 효율적으로 메모리를 사용한다.

컨텐츠 객체는 바인딩 컴파일러에 의해 컴파일된 클래스들의 인스턴스들이다. 바인딩 컴파일러 외에 JAXB구현은 마샬링과 같은 JAXB와 관현된 구현 런타임API를 제공해야만 한다. API들은 바인딩 프레임웍의 부분으로 제공된다. 바인딩 프레임웍은 세개의 패키지로 구성된다. 기본패키지인 javax.xml.bind 는 마샬링, 언마샬링, 확인(validation)과 같은 기능을 수행한다. 두번째로 javax.xml.bind.util 패키지는 많은 유틸리티 클래스들을 포함한다. 세번째로 javax.xml.bind.helper 패키지는 JAXB구현 제공자(priovider)를 위해 설계되었다. (역자주: JAXB implementation provider는 바인딩 컴파일러로 생성된 JAXB implementation을 말한다)

XML문서를 언마샬하기 위해서는:

- JAXBContext 객체를 생성한다. 이 객체는 JAXB API의 엔트리포인트를 제공한다. 객체를 생성할때는 컨텍스트경로를 명시하여야 한다. 이것은 바인딩 컴파일러에 의해 생성된 인터페이스를 포함한 하나 또는 그 이상의 패키지명의 목록이다. 컨텍스트경로에 여러개의 패키지명을 허용함으로써 JAXB는 서로다른 스키마의 XML데이터요소 조합을 언마샬할 수 있도록 지원한다.

예를들어 다음의 코드는 컨텍스트경로가 test.jaxb인 JAXBContext객체를 생성한다. 이 패키지는 books.xsd스키마를 위한 인터페이스를 포함한다.

import javax.xml.bind.JAXBContext;

JAXBContext jc = JAXBContext.newInstance("test.jaxb");

- 언마샬객체는 언마샬링과정을 제어한다. 이것은 실질적인 언마샬명령을 수행사는 메소드를 포함한다. 예를들어, 다음의 코드는 Unmarshaller 객체를 생성한다.

Import javax.xml.bind.Unmarshaller;

Unmarshaller unmarshaller = jc.createUnmarshaller();

- unmarshal 메소드를 호출하면 실질적인 XML문서의 엄마샬링을 한다. 예를들어 다음의 문장은 books.xml파일의 XML데이터를 언마샬한다.

Collection collection = (Collection)unmarshaller.unmarshal(new File(“books.xml”));

(주의) 여기서 Collection은 java.util.Collection이 아니라 test.jaxb.Collection 이다.

- 스키마에서 파생된 클래스의 get메소드의 사용은 XML데이터에 접근할수있게 한다. JAXB컴파일러가 생성한 클래스는 해당 스키마의 각 속성타입 또는 요소의 데이터를 획득하거나 기술할 수 있는 get, set메소드를 포함하고 있다. 예를들어, 다음의 문장은 books와 book요소의 데이터를 가져온다.

CollectionType.BooksType booksType = collection.getBooks();
List bookList = booksType.getBook();

데이터를 획득한 다음에는 프로그램상에서 직접 이것을 출력할 수 있다. 여기 books.xml파일의 데이터를 언마샬 하고 화면에 출력하는 프로그램 예제가 있다. 이 프로그램을 실행하면 다음의 결과를 보게 될 것이다.

Book details
Item id: 999
Book Name: Learning JAXB
Book ISBN: 123445
Book Price: 34 $
Book category: other
Book promotion: 10% on this book if purchased by March 2003
No of Authors 1
Author Name Jane Doe

Book details
Item id: 129
Book Name: Java Webservices today and Beyond
Book ISBN: 522965
Book Price: 29 $
Book category: magazine
Book promotion: Buy one get Learning webservices Part 1 free
No of Authors 2
Author Name John Brown
Author Name Peter T.

원본데이터의 확인 : 프로그램이 다음의 문장을 포함하고 있는지 확인하라.

unmarshaller.setValidating(true);

이 문장은 JAXB의 중요한 기능을 보여준다: 원본데이터의 무결성 검사는 스키마를 이용해 언마샬과정의 일부로 확인될 수 있다. 이경우, JAXB에게 원본데이터의 무결성을 검사할것인지 묻게된다. 만약 데이터에 문제가 발견되면 JAXB구현은 이것을 기록하거나 다른 행동을 취할 수 있다. JAXB는 여기에 매우 많은 유연성을 제공한다. JAXB스펙은 에러가 발생하였을 시 모든 제공자(Provider)가 validation 에러를 남기도록 명시하고 있다. 그러나, 구현(implementation)은 데이터의 처리를 멈추지 않아도 된다. 어떤 제공자는 첫번째 오류가 발생시 실행을 멈출것이고, 어떤 제공자는 매우 많은 에러가 발견되어도 멈추지 않을 것이다. 다시말해, 이것은 JAXB구현이 올바르지않은 XML문서도 성공적으로 언마샬 하고 자바객체트리를 생성할 수 있음을 말한다. 그러나, 결과는 바뀌지 않을 것이다. 모든 JAXB구현에게 핵심적으로 요구되는 기능은 정상적인 문서를 언마샬 할 수 있는것이다.

당신이 이러한 validation작업을 과부하(Overhead)라고 생각한다면 이러한 validating작업을 언제든지 끌수도 있다.

다른 소스의 언마샬링: 앞서본 예제가 파일로 저장된 XML데이터를 어떻게 언마샬하는지 설명하였지만 이것은 파일 뿐만이 아니라 InputStream객체나 URL, DOM노드와 같은 다른 소스도 언마샬할 수 있다. 예를들어, javax.xml.transform.sax.SAXSource객체는 언마샬할 수 있다. SAX이벤트도 언마샬 할 수 있다. 다시말해, 당신은 다큐먼트의 SAX파싱을 하고 이벤트를 JAXB에 전달하여 언마샬을 할 수 있다.

언마샬링을 하지않고 데이터 다루기: JAXB는 언마샬을 하지 않고도 XML데이터를 다룰수 있도록 한다. 스키마로부터 생성된 클래스들중에 ObjectFactory라는 클래스가 있다. 이것은 각 스키마에서 파생된 인터페이스와 클래스의 객체를 생성하는 메소드를 가지고 있다. 예를들어, books.xsd를 위해 생성된 패키지에는 ObjectFactory클래스가 있고 이 클래스는 createCollection이라는 Collection객체를 생성하기 위한 메소드가 있고 createBookType은 BookType객체를 생성한다. 이 메소드들은 어떤 언마샬과정을 거치지 않고 컨텐츠객체의 트리를 생성할 수 있게 한다. 이런 객체를 생성한 뒤에 컨텐츠를 삽입하기 위해서는 각 객체의 set메소드를 이용하면 된다.

또 다른 예제: XML문서 구축

당신은 XML문서데이터를 직접 제어하는것 보다 자바 어플리케이션을 통해 제어하는것을 필요로 할것이다. 여기 JAXB를 이용한 쉬운예가 있다.

XML문서를 생성하기 위해 DOM식의 접근법을 사용하였을 것이다. 이것은 당신이 문서의 내용을 메모리상에서 생성할 필요가 있기 때문이다. 반면에 SAX는 메모리상에서 데이터를 생성하는 작업을 허용하지 않는다. DOM식의 접근법을 이용할때, 프로그램은 문서를 생성하기 위해 DOM객체와 메소드를 생성하고 사용하게 된다. DOM은 데이터를 정렬하여 트리객체처럼 보여주도록 설계되었다. 당신의 프로그램이 Document 객체의 메소드를 사용하면 트리의 노드와 같은 다른 객체를 생성해 낼 수 있다. 각 노드는 XML문서의 내용을 포함하고 있다. 당신은 트리의 정렬순서에 따라 노드를 추가할 수 있다. 다시말해, DOM객체의 메소드는 루트노드를 만들거나 그 루트노드를 Document객체에 추가한다.

'Program > Java' 카테고리의 다른 글

Spring MVC Annotation 기초  (2) 2009.12.27
Annotation (since tiger / 1.5)  (0) 2009.12.27
StringUtils  (0) 2009.12.22
Annotation (since tiger / 1.5)  (0) 2009.12.15
XML 파싱  (0) 2009.12.15
아바타
감독 제임스 카메론 (2009 / 미국)
출연 샘 워딩튼, 조이 살디나, 시고니 위버, 스티븐 랭
상세보기

회사 송년회로 본 아바타.. 파랭이 전사들 이야기..
사실 아바타는 그다지 땡기는 영화는 아니였다.
그래도 회사에서 가야하니깐.. 봐야하지 뭐..
영등포 타임스 스퀘어 CGV에서 보는데..
요즘 여기를 자주 가는군.. ㅡㅡ;

영화는 나쁘진 않았다.
그러나 너무 길다는 느낌.. 좀 전체적인... 감독이 보여주고 싶었던게 많았던 그런 영화였던거 같다.
전개상 필요치 않는 부분도 사실 좀 많았고 좀 줄여도 될 장면들도 많았는데.. 그래서 그런지 좀 지루한 감도 없지 않았다.
그래도 CG와 상상력은 대단했다고 생각한다.
날아다니는 동물들이며.. 식물들.. 환상적이긴 했다.
이건 3D 로 보면 정말 실감난다고 했는데.. 그냥 2D극장에서 본게 좀 아쉽다.

스토리는 뭐.. 지구인이 파랭이들이 사는 행성에 가서 자원을 도둑질 하려고 하는 내용? ㅋㅋ
결국은 해피 앤딩이다..
그래도 그냥 티비에서 보는거 보다는 이런 CG는 극장에서 봐줘야지~~
그래도 3D로 못본건 정말 아쉽다..
이왕 보여주실꺼.. 돈 투자 좀 더하셔서.. 3D 로 보여주면 안되나? 쩝.. 아쉽구나~~

'Story > Diary' 카테고리의 다른 글

눈 실컷 보는구나~  (0) 2009.12.27
[Movie]전우치  (0) 2009.12.27
[Movie] 전우치  (0) 2009.12.27
크리스마스 이브  (0) 2009.12.24
재영네 돌잔치  (0) 2009.12.19

+ Recent posts