얼마전에 지인분들과 같이 3D를 스터디하면서 병행했던 번역이 완결되는 이 시점에 블로깅을 하지 않으면 타이밍을 놓칠까하여 블로그 admin 화면을 띄워본다.
원서의 제목은  ”3D for iPhone Apps with Blender and SIO2: Your Guide to Creating 3D Games and More with Open-Source Software“이다. 번역본의 제목은 “블렌더와 SIO2를 이용한 아이폰 3D 프로그래밍 : 오픈소스로 3D 앱/게임 개발하기“이다.

책 작업을 하는 것이 처음은 아니다. SOA를 검색하면 제일 상위에 랭크되는 “SOA : 자바 웹 서비스로 통하는 서비스 지향 아키텍처”의 glossary 번역하면서 번역에 살짝 발을 담구기도 하였고(역자로는 본인이 사양하여 이름을 넣지는 않았다:), 현재 나름 아이폰개발서적으로 1위를 달리고 있는(yes24 기준) “시작하세요! 아이폰 3 프로그래밍 : iPhone SDK를 이용한 아이폰 개발“의 아이폰 SDK 3.0에 대한 부록을 공저했었고, 대중에게 빛을 보지 못한 책이지만 이 외에도 번역을 하기도 했었다.
번역을 많이 해본 것은 아니지만, 할때마다 많은 어려움을 느낀다. 원서의 영문을 국문으로 옮기기까지 실은 몇단계가 지나야 한다.
(1)영문을 읽고 그것을 머릿속으로 직역한다. 직역은 단어와 문법 그대로를 가지고 뜻을 국문으로 옮기는 작업이다. (2)다음으로 앞선 문장이나 챕터 전반에 걸친 내용과 전체적은 문맥에 근거하여 최대한 국문에 맞도록 수정한다. (3) 그리고 나서는 그 글을 쓰는 입장이 아닌 읽는 사람의 입장으로 문장을 보고 다시 다듬는다. (4) 3단계를 거쳤음에도 매끄럽지 않고 부자연스럽다면 소위 의역이라고 말하는 단계를 거친다.
이게 지금 당장 생각나는 단계들이다. 물론 그 사이사이에 단계들이 껴들어가긴 한다. 책 전체의 단어를 통일하기 위해 glossary 테이블을 공유하여 채워가는 것이 예이다. 많이 부족한 실력에도 나름대로의 체계를 실어 점진적인 발전을 꾀하고자 하지만, 항상 쉽지 않음을 느낀다.
이렇게 쉽지 않게 번역한 이 책이, 독자분들의 냉철한 심판을 받으면서 어떤 책으로 기억될런지 두렵기도 하다.
적어도 SIO2와 블렌더를 다루기 위해 가볍게 읽으며 따라해볼만한 가벼운 느낌의 책이 되었으면 하는 것이 내 바람이다.

많이 부족하지만 앱 개발자들의 필연적인 다음 레벨이 될 3D영역으로의 항해에 작은 바람이라도 되었으면 한다.
아울러 썼던 역자 서문도 첨부해본다.

최근에 가장 나한테 있었던 큰 이슈라면, 얼마 전에 있었던 크라우드 컴퓨팅 컨퍼런스에서의 발표였던 것 같다.
ACC(Advanced Computing Conference) 2010의 국내 최초 크라우드 컴퓨팅 서비스 업체인 NexR의 “NexR 아이큐브 클라우드적용사례:프라이빗 &모바일 클라우드”에서 실제 적용 사례를 발표 했었고,  IBM dw Live에서 “스타트업에서의 모바일 서비스와 클라우드 컴퓨팅 적용”이란 세션으로 발표를 했다.

cloud mobile

매번 발표 기회는 갑자기 오는 듯 하다. 작년 회사 서비스 시작부터 GAE(Google App Engine)과 Amazon EC2를 전전긍긍하면서 각각 크라우드 서비스에 대한 장단점이나 현실적인 한계나 대처 방법등을 학습하게 되었고, 현재는 국내 최초 크라우드 컴퓨팅 업체인 NexR의 iCube Cloud를 잘 쓰고 있다.
발표는 대략, 크라우드 컴퓨팅과 모바일 클라우드 컴퓨팅에 대한 정의 정립, 클라우드 컴퓨팅 도입 팁, 각 벤더들의 장단점, 한계 등을 실제 경험과 구체적인 측정 자료를 근거로 진행했다.

언제나 느끼는 것이지만, 적어도 개발자분들은 ‘현실’적인 측면을 원한다.
윗선에서는 기획이나 전략에 대한 트렌드 뿐만 아니라 기술적인 측면에서도 최신 트렌드를 따라가거나 또는 앞서 가기를 원한다. 기업의 경쟁력이 될 수 있다는 생각이 어느정도는 들어있을 것이다.  하지만 실제 그것을 사용하는 개발 직군에서는 다양한 한계에 부딪히게 되고, 그것을 해결, 보완 혹은 우회하기 위해서 인적, 물적 리소스를 소비한다. 그 리소스는 바로 개발자들의 시간과 에너지인 만큼, 그것을 줄여주길 바란다. 거기에 집중해서 자료를 만들고 발표를 했다.

그래서인지 Q&A타임뿐만 아니라 발표 후에도 많은 분들이 도움이 됬다는 격려성 메시지를 날려주셨고 많은 질문을 주시기도 하였다.
굉장히 큰 보람을 느꼈고 나 자신한테도 많은 도움이 되었다.
물론 프레젠테이션 스킬에 있어서는 TED의 연사들처럼 몰입도 200%의 스킬을 구사하지는 못했지만, 도움이 된 것 자체로 큰 만족을 한다.
아래는 발표자료이다.

다른 사람들이 쉽게 도입하지 않는 기술들을 쓰는 것은 언제나 가려운 나의 호기심을 긁어주고 많은 배움을 얻게 해주지만, 그만큼 외롭고 힘든 여정인 것은 사실이다.
하지만 누군가 그러지 않았던가, 새로운 기술에 대한 습득은 “두려움”이 가장 큰 벽이라고. 그 두려움이 없는 편이라 다행이다.

P.S> 아쉽게도 기술과 서비스는 ‘=’관계가 아닌지라 모든 기술이 대중에게 빛을 보이는 것은 쉽지가 않다. 기획/전략/운영 등등이 시기 적절하게 맞아 떨어져 market pull이 있고 tech push가 일어나게 될때 비로소 큰 성공을 이룬다. 서비스를 기술적인 측면보다는 ‘서비스’측면에서 바라보는 것이 좋다고 굳게 믿던 내 신념이 좀 흔들리긴 한다. 개발자라는 직군으로써 그런 자세가 집중력을 흐트릴 수도 있기때문이다. 그래서, 이제는 구현을 하면서도, “이 기획은 이거보다 이게 좋겠어.”, “이 버튼은 여기보다 저기에 놓는게 좋겠어”라는 내가 만드는 서비스에 대한 무한애정행각은 좀 자제하고, 철저히 기술적인 측면에서만 바라보고 일하며, 또 그런 환경으로 몸을 옮기려 준비하고 있다. 이제 날을 세워야 할때가 아니던가.

지금은 작은 벤처 회사의 개발 디렉터로서 일을 하고 있고 어쩌면 내 개발 연차에 비해서는 가볍지 않은 일을 하고 있음에 분명하고 또, 그에 대한 많은 긴장감,부담감,자신감. 자부심 등등으로 채찍질을 하며 나날을 보낸다.

현재는 서버개발과 아이폰개발을 동시에 진행하고 있다.
서버는 크라우드 컴퓨팅 업체의 테스터로 좋은 조건(?)으로 사용하고 있지만, 안정성은 보장이 되는지, 프로덕션을 여기서 낼 수 있는지, 서버호스팅이 좋은지, 장비 구입이 좋은지.
WAS는 glassfish를 쓰기로 했는데 여기서는 클러스터링과 static resource에 대한 관리를 위해 어떤 설정들이 들어가야 하는지, 보통 하는 gate server로 apache를 두어서 해야하는지
DB서버는 분리해야하는데, 성능을 위한 리플리케이션을 mysql에서 어떻게 적용을 해야할지, 디비는 수평분리가 좋을지 수직분리가 좋을지, 백업 정책을 어떻게 잡아나갈 것인지,
서버사이드로직 개발 위한 프레임워크로 요즘 대세인 spring을 쓸 것인지, ORM으로 hibernate, iBatis, 아니면 가볍게 JPA를 쓸 것인지, RESTful API구현을 위해 JAX-RS는 뭐로 할지(jersey), API인증은 OAuth를 적용해야하는지 아니면 service specific auth protocol을 만들어버릴지, 내가 설계하고 있는 API가 진짜 RESTful한지에서부터 클라이언트 입맛대로 많은 일을 할 수 있을지,
클라이언트 사이드(웹)을 할때는, 브라우저 지원은 어디까지 해야하는지, webkit기반은 모두, IE7이상에 모바일 브라우저는 optional, 자바스크립트 프레임웍은 jQuery를 쓰기로 했는데 그안에서 어떤어떤 플러그인을 쓸지,
아이폰 개발을 하는데 DB handler로 CoreData를 쓸지 와일드하게 sqlite를 쓸지, IB(Interface Builder)를 쓸지 날코딩을 해서 fully 내손안의 있소이다를 외칠지. 로컬 캐싱은 몇row까지 지원할지, 로깅 포맷은 어떻게 정할지, 추후 버전에서 모델이 바뀔 경우를 대비해야할지, 뷰단을 담당하고 있는 주니어개발자에게 어느 범위까지 개발을 위임할지, 서버및 로컬디비 모듈과 연계를 위해서 내가 직접 하는것이 낫은지 주니어에게 내가 만든 모듈 API를 학습시킬지, 메모리릭 체킹은 어느 시점에 해야할지,
개발자 수는 나까지 3명뿐이지만 TRAC을 쓰고 있는데, 어떻게 하면 지금 self motivation용도뿐인 이 이슈트래커를 사내개발프로세스에 잘 흡수시킬지, 개발 하면서 보는 기획문서에 적잖이 보이는 수많은 워크플로우나 UX상의 오류나 더 좋은 대안을 찍고 넘어가야하는지 아니면 일단 무아지경으로 개발에만 집중을 해 나갈 것인지. priority에 대한 감이라고는 냉장고에 있는 홍시를 백개정도는 먹어야 찾을 거 같은 기획상의 작업 순서에 대해서 어떻게 설득을 해야할지.
등. 등. 등. 등. 등.

이런 전체적인 뒷고민들이야 어찌됬든 번듯한 애프리케이션과 웹서비스 하나면 만족할 비개발자들에게 이런 고민과 결정에 따른 필요한 인적, 물적 리소스 산정에 대한 당위성은 어떻게 설득을 시켜야 할지.

오늘 전 회사에서 같이 일하던 개발자분의 말로 “날이 선 개발자”(한기술에 정통한)가 되기 위해서는 내가 가는 이 길이 아닐지도 모르겠단 생각을 하지만
generalist->speciallist로의 결정을 하기엔 아직은 때가 아니라는, 그리고 정말 날을 세우기 위해 필요한 힘이 아직 부족하다는 확고한 믿음 때문에

힘들지만 달린다.

self motivation, 내가 하는 개발일에 대한 동기부여가 많이 떨어져 있는 매우 위험한 상태. 환경과 컨디션에 의존성이 걸려 있다면 그건 이미 아마추어란 소리. 밀림에서든 동물원 철장 안에서든 사자는 사자여야 하는 법. 추스리고, 안되면 허황된 당위성에 대한 자기 최면이라도.

개발방법론, blah blah~ driven 같은 정립된 방법론 말고, 현재 내가 처한 프로젝트를 좀 더 주도적으로 체계적으로 갈등 없이 진행하는 방법. 큰 고민거리임. “프로젝트가 서쪽으로 간 까닭은(톰 드마르코, 팀 리스터외 지음, 박재호,이해영 옮김)”을 다 읽어가고 있으며 챕터 하나하나 뼛속 깊이 되새기고 다시는 저런 우에 휘말리지 말자고, 휘말리더라도 무슨 문제가 있는지는 “알고” 당하자는(다시 그런 우에 진입도 하기 전에 알아차릴 수 있도록)

이렇게 세개인듯.

누군가 그랬다, 서쪽으로 가고 있는지 아는게 어디냐.

그래, 난 나침반은 있으니까, 움직이면 된다.

오늘 하루 나이를 더 먹은 나에게
어떤 변화가 있었고 얼마만큼 진한 하루였던가, 그런 아쉬움으로
2시를 맞으면 아차싶어 또 다시 내일을 위해 잠을 청한다.
그리고 다시 부비적 거리며 일어날테지.

나쁘지도 좋지도 않은 생활, 그저 생활이지만
나에겐 이게 악순환처럼 느껴진다.

이젠 그 고리를 잘라야 할 때.

애플리케이션에서 SessionFactory 인스턴스가 생성될 때 Hibernate는 설정 파일을 읽고 각각의 매핑 파일을 식별한다. SessionFactory에서 생성된 세션 객체는 데이터베이스로의 연결을 하며, 이는 퍼시스턴스 클래스의 인스턴스에 대한 퍼시스턴스 컨텍스트이다. 인스턴스는 transient, persistent, detached 중 한가지의 상태에 놓이게 된다. transient 상태에서 객체는 아직 테이블과 연관이 없으며 persistence 상태에서 객체는 테이블과 연결이 되어 있고, detached  상태에서는 테이블과의 싱크를 보장하지 않는다. Employee 객체를 저장하는 Hibernate코드는 Listing7과 같다.

Listing 7. Persisting an object with Hibernate

Session session = null;
Transaction tx = null;

// At this point the Configuration file is read
SessionFactory sessionFactory = new Configuration().configure().buildSessionFactory();

// A specific session object is obtained
session = sessionFactory.openSession();

// A new database transaction is started
tx = session.beginTransaction();

// Employee Object is created & populated
Employee emp = new Employee();
emp.setId(1);
emp.setEmpFirstname("K L");
emp.setEmpLastname("Nitin");

// Using the session, emp object is persisted in the database
session.save(emp);

매핑정보가 있는 설정 파일은 특정 퍼시스턴스 클래스에서 데이터베이스 테이블로의 매핑을 식별한다. 이는 특정 column들을 특정 field들로 매핑시키고 관계, 집합, 주키(primary key)매핑, ID 값 생성 메커니즘을 가진다. 매핑파일은 기본적으로 매핑되고자 하는 테이블에 기반한 이름으로 지어진다. 예제 애플리케이션에서는 EMPLOYEE테이블에 대응하는 Employee.hbm.xml 를 설정파일로 사용하였다. Listing 8에서 볼 수 있듯이 매핑파일은 데이터베이스에 있는 id, emp_firstname, emp_lastname 칼럼을 가지고 있는 EMPLOYEE 테이블에 매핑되는 Employee클래스에 대한 설정 정보를 가진다. id는 주키(primary key)이며 반드시 값이 할당 되어 있어야 한다.

Listing 8. Employee.hbm.xml

<hibernate-mapping package="demo">
  <class name="Employee" table="employee" >
    <meta attribute="sync-DAO">false</meta>
      <id name="Id" type="integer" column="emp_id">
        <generator/>
      </id>
       <property name="EmpFirstname" column="emp_firstname"
              type="string" not-null="true" length="30" />
      <property name="EmpLastname" column="emp_lastname"                      type="string" not-null="true" length="30" />
    </class>
</hibernate-mapping>

언제 Hibernate를 사용하는 것이 좋을까

Hibernate는 하나부터 열까지 OR매핑을 하고자 할때 가장 좋다. 이는 완벽한 ORM솔루션을 제공하지만 쿼리에 대한 제어를 어렵게 한다. Hibernate는 애플리케이션과 데이터베이스 각각에 대한 설계에 대한 완벽한 통제가 가능한 상황에서 이상적인 솔루션이다. 이런 경우 애플리케이션을 데이터베이스에 맞도록 수정하거나 데이터베이스를 애플리케이션에 맞도록 수정할 것이다. 이런 경우에 완전한 object-relational 애플리케이션을 구축하기 위하여 Hibernate를 사용할 수 있을 것이다. Hibernate는 SQL에 익숙하지 않은 객체지향 프로그래머에게 최고의 옵션이다.

The Java Persistence API

Java Persistence API는 표준 object-relational 매핑이며 JavaEE 5플랫폼에 대한 퍼시스턴스 관리 인터페이스이다. EJB3  스팩 활동의 노력으로 모든 주요 Java 벤더들이 제공한다. Java Persistence API는 Hibernate, Oracle TopLink, Java Data Objects(JDO), EJB container-managed persistence와 같은 주요 퍼시스턴트 프레임워크와 API들의 아이디어에 기반하여 구현되었다. JPA는 특정 퍼시스턴스 프로바이더의 구현체가 사용될 수 있는 플랫폼을 제공한다. Java Persistence API의 주요 특징은 어떤 persistence provider든 그것에 끼워 맞춰질 수 있다는 것이다.

JPA는 ORM을 위한  POJO기반의 표준 퍼시스턴스 모델이다. 이는 EJB3스팩의 한 부분이며 entity benas를 대체한다. entity beans는 실제 개발 현장에서 여러 이유에서 완전한 퍼시스턴스 솔루션으로서 인정받는데 실패한 EJB2.1의 한 부분이었다:

• Entity beans는 무거운 컴퍼넌트이며 Java EE서버와 강하게 결합되어 있었다. 이떄문에 재사용에 적합한 가벼운 POJO에 비해 적합치 않게 받아들여 졌다.
• Entity beans는 개발과 배포하기 어렵다.
• CMP entity beans가 자체의 설정과 ORM 선언이  Java EE 서버에 많이 의존하는데 반하여, BMP entity beans은 JDBC를 사용하도록 강제한다.

이 이슈들을 해결하기 위하여  EJB3 소프트웨어 전문 그룹은 JSR220의 일부로 JPA을 개발중이다. JPA는 다른 퍼시스턴스 기술들로부터 제일 좋은 아이디어들을 빌려왔다. JPA는 모든 자바 애플리케이션에 대하여 표준 퍼시스턴스 모델을 정의한다. JPA는 Java SE와 Java EE 애플리케이션 둘 모두에서 퍼시스턴스 솔루션으로 사용될 수 있다.

JPA는 애플리케이션 도메인에 있는 자바 객체와 관계 데이터베이스에 있는 테이블간의 매핑설정을 하기 위하여 메타데이터 어노테이션 그리고(혹은) XML 디스크립터 파일을 사용한다. JPA는 완전한 ORM 솔루션이며 상속과 다형성을 지원한다. 또한 entity beans에서 사용하던 EJB-QL JPQL(Java Persistence Query Language) 과는 다른 JPQL(Java Persistence Query Language)라는 SQL과 비슷한 쿼리 언어를 정의한다.

JPA를 사용하면 현재 사용하고 있는 Java  EE container에서 제공하는 기본 퍼시스턴스 프로바이더를 사용하는 대신에 JPA 스팩을 구현한 어떤 퍼시스턴스 프로바이더든 간에 연결시킬 수 있다. 예를들어 GlassFish서버는 기본 퍼시스턴스 프로바이더로 Oracle에서 제공하는 TopLink Essentials를 사용한다. 하지만 당신은 애플리케이션에 필요한 모든 JAR파일들을 포함시키는 대신에  퍼시스턴스 프로바이더로  Hibernate를 선택할 수 있다.

to be continue…

p.s> 금새 끝날거 같았는데 속도가 많이 줄었다. 페이퍼를 요즘 안 읽어서 그런가보다. ^^; 어쨌든 수고. ㅋ

2009년 한 가운데에 있었던 도전이 2010에도 거침없이 나아가기를 바라는 마음에 첫 QuickPress를 2010 첫 월요일을 준비하는 일요일 오후에 적어본다.

내 일에 있어서는 시작의 설레임으로 힘차게 내딛던 2008년 그때 처럼,
내 인생에 있어서는 인생의 큰 방점이자 큰 선물이었던 군대 전역의 해 2005년 그때의 벅참으로 살아가기를.

좀더 긍정적이고 좀더 진취적이고 좀더 열정적으로

2010 화이팅!!!!!!!!!!!!!!!!!!!!

Hibernate는 오픈소스로 경량의 객체관계 매핑 솔루션이다. Hibernate의 주요 특징은 객체 기반의 모델링을 지원함으로서 퍼시스턴스에 대하여 투명한 체계를 제공한다는 점이다. 데이터페이스와 애플리케이션간의 매핑을 위해 XML을 이용하고 매우 정제되어 이는 객체를 지원한다. 현재 Hibernate 버전은 3.x이며 향후 Java annotation의 지원하고 EJB스팩을 모두 지원해나갈 예정이다.

Hibernate는 Hibernate Query Language 혹은 HQL이라 불리는 매우 강력한 쿼리 언어를 포함하고 있다. HQL은 SQL과 매우 비슷하며 추가적인 컨벤션을 정의할 수도 있다. HQL은 완전히 객체 지향적이며 이로써 상속, 다형성, 관계등의 객체지향의 강점을 누릴수 있다. HQL쿼리는 자바 클래스와 프로퍼티의 이름을 제외하고는 대소문자를 가린다. HQL은 쿼리 결과로 객체를 반환하며 프로그래머의에 생성되고 직접적으로 접근되어질 수 있다. HQL은 페이지네이션이나 동적 프로파일링같은 SQL은 지원하지 않는 향상된 기능을 제공한다. HQL은 여러 테이블을 작업할때에 명시적인 join을 요구하지 않는다.

왜 Hibernate를 필요로 하는가?

객체 관계 매핑을 위해 전통적으로 사용되어 오던 Entity beans는 이해하기 어려우며 유지관리가 어렵다. Hibernate는 특정 클래스에 매핑되어야 하는 데이터베이스의 테이블에 대한 관계 정의가 되어 있는 XML 파일의 메타데이터로 객체관계 매핑을 간단하게 수행시키신다. 다른 persistence 프레임워크는 객체관계의 매핑을 위해 애플리케이션 클래스를 수정해야할지 미로즤만 Hibernate에서는 그렇게 할 필요가 없다.

Hibernate를 사용하면 데이터베이스가 변경되더라도 SQL스크립트를 변경하는등의 작업을 피할 수 있다. 애플리케이션에서 사용되는 데이터베이스를 변경시키고자 한다면 설정파일의 dialect 프로퍼티를 수정함으로서 쉽게 처리할 수 있다. Hibernate는  기존의 상업용 ORM 프레임워크로부터는 제공되지 못했던 SQL 모든 기능을 완벽하게 지원한다. Hibernate는 MySQL, Oracle, Sybase, Derby, PostgreSQL를 포함한 많은 데이터베이스를 지원하며 POJO기반의 모델과도 원활하게 동작한다.

Hibernate는 선택된 데이터베이스에 기반하여 JDBC코드를 생성하므로써 JDBC코드를 쓰면서 사용하는 문제로부터 해방시켜준다. 또한 커넥션 풀도 지원해준다. Hibernate에서 사용되는  API은 매우 간단하고 배우기 쉽다. 개발자는 SQL에 대한 기초 지식만 있떠라도 Hibernate를 사용할 수 있으며 SQL쿼리를 집합을 쉽게 사용할 수 있게 해준다.

Hibernate 아키텍쳐

내부적으로 Hibernate는 다른 애플리케이션과의 통함을 위한 JTA(Java Transaction API)와 JNDI를 적용하기 위한 데이터베이스의 추상화 계정을 제공하는 JDBC를 사용한다. 데이터베이스와의 상호작용에 필요한 Hibernate의 연결 정보는 JDBC의 connection pool에 의해 제공된다.

Hibernate의 아키텍쳐는 두개의 주요 인터페이스로 구성되는데 Session과 Transaction이 그것이다. 이는 애플리케이션의 퍼시스턴스 계층에 있는  Query 인터페이스와 함께 사용된다. 애플리케이션의 비즈니스 계층에 정의된 클래스들은 특정 JDBC API들을 사용하는 데이터베이스 계층과의 상호작용을 하기 위한 Hibernate 퍼스스턴스 계층과의 독립적인 메타데이터를 통하여 상호작용한다. 더하여 Hibernate는 Configureation클래스라는 설정을 위한 인터페이스를 사용한다. Hibernate는 callback 인터페이스를 사용하게끔 하며 몇몇 추가적인 인터페이스는 기능적인 매핑의 확장을 위해 사용된다. Hibernate의 전체적인 아키텍쳐는 Figure3에서 볼 수 있다.

Figure 3. Hibernate architecture: The big picture

Hibernate의 일부인 주요 프로그래밍 인터페이스는 다음과 같다

• org.hibernate.SessionFactory 는 session 인터페이스를 얻는데 사용되며 connection pool 메커니즘과 유사하게 보여질 수 있다. 모든 애플리케이션 내의 쓰레드가 하나의 SessionFactory를 사용하기 때문에 thread safe하다(Hibernate가 하나의 데이터베이스를 사용하는 한은.). 이 인터페이스는 설정 파일을 통해서 어떤 파일들이 로딩될지 결정된다.
• org.hibernate.Session는 애플리케이션과 데이터베이스간의 상호작용을 결정하기 위한 하나의 쓰레드를 제공한다. 이는 single connection과 유사하며 매우 경량이긴 하나 thread safe하지 않다.

• org.hibernate.Transaction는 애플리케이션에서의 원자적인 하나의 작업단위를 결정하는 하나의 쓰레드 객체를 제공한다. 이는 기본적으로 JDBC, JTA, CORBA 트랜잭션에 기초한다.

• org.hibernate.Query는 HQL이나 데이터베이스에 있는  SQL과 같은 쿼리를 수행하는데 쓰인다. Query인스턴스는 가벼우며, 그 쿼리가 생성된 세션 밖에서는 사용할 수 없다는 것에 주의해야 한다.


Hibernate 설정

Hibernate의 설정은 hibernate.cfg.xml이라는 XML파일을 통해 할 수 있다. 이 설정 파일은 특정 관계 데이터베이스로의 연결을 하기 위한 정보가 들어 있다. 설정 파일은 참조해야할 매핑파일을 알고 있어야 한다. 런타임에서 Hibernate는 매핑파일을 읽고 데이터베이스의 테이블에 대응하는 동적 자바 클래스를 빌드하는데 그 매핑 파일을 사용한다. 예제 설정 파일은 Listing 6에서 볼 수 있다.

Listing 6. hibernate.cfg.xml

<hibernate-configuration>
   <session-factory>
    <!-- local connection properties -->
     <property name="hibernate.connection.url">
        jdbc:mysql://localhost/hibernateDemo
     </property>
     <property name="hibernate.connection.driver_class">
        com.mysql.jdbc.Driver
     </property>
     <property  name="hibernate.connection.username">
root
 </property>
     <property name="hibernate.connection.password">
infosys
 </property>
     <!-- dialect for MySQL -->
     <property name="dialect">
        org.hibernate.dialect.MySQLDialect
     </property>
     <property name="hibernate.show_sql">false</property>
     <property name="hibernate.transaction.factory_class">
        org.hibernate.transaction.JDBCTransactionFactory
     </property>
     <mapping resource="Employee.hbm.xml" />
  </session-factory>
</hibernate-configuration>

JQuery를 쓰게 되면 브라우저 분기를 하기 쉽지만 IE의 버전을 분기해주는 것은 빌트인되지 않은 기능이다. 특히 요즘 거의 “무시”의 대상이 되고 있고, 또 그래야만 하는(?) IE6에 대한 분기를 위해 보통 다음과 같은 코드를 사용하게 되는데

jQuery.browser.msie6 = $.browser.msie && /MSIE 6.0/i.test(window.navigator.userAgent);

여기에 헛점이 있다. 바로 IE6의 윗 버전 브라우저들에서 하위 버전의 Compatible모드를 지원하기 때문에 UserAgenet에 6.0텍스트가 포함되어 있을 수 있기 때문이다.(정확히 어떤 경우에 아래와 같은 UserAgent설정이 되는지는 확인해보지 않았으나, 본 버전의 바로 하위 버전에 대해 Compatible모드를 지원해주는 듯 하다)

고로, 정확하게는 아래와 같이 사용해야 할 것이다.

jQuery.browser.msie6 = $.browser.msie && /MSIE 6.0/i.test(window.navigator.userAgent) && !/MSIE 7.0/i.test(window.navigator.userAgent);

다른 XML파일은 SQLMap.xml로 , 그 이름처럼 테이블간에 관계에 대한 정보를 가진다. 이 파일은 하나의 애플리케이션에서 여러개를 가질 수 있다. 이 파일은 SQL 문장들과 매핑되는 도메인 객체가 있는 것이 위치한다. 이 디스크립터는 입력으로 쓰일 문장과 SQL ResultSets로 매핑되는 결과에 대한 내용을 표기한다. 이 파일은 쿼리를 포함하기도 한다. 따라서 쿼리를 바꾸려면 애플리케이션의 자바 코드를 바꾸는 것이 아니라 XML을 바꾸어야 한다. 매핑은 데이터베이스와 상호작용할 실제 SQL문장을 사용하여 이루어진다. 이렇게 SQL을 사용하는 것은 개발자에게 매우 큰 융통성을 부여하며  SQL프로그래밍 경험을 가진 누구에게나 iBATIS를 쉽게 이해할 수 있게 해준다.

EMPLOYEE테이블에 대한 CRUD연산을 수행하는 SQL문을 정의한 SQLMap.xml파일이 아래 Listing 2에 있다.

Listing 2. SQLMap.xml for operations on EMPLOYEE

<sqlMap namespace="Employee">
  <typeAlias alias="Employee" type="com.sample.Employee"/>
  <resultMap id="EmpResult">
    <result property="id" column="emp_id"/>
    <result property="firstName" column="emp_firstname"/>
    <result property="lastName" column="emp_lastname"/>
   </resultMap>
  <!-- Select all data from the table using the result map for Employee class.-->
  <select id="selectAllEmps" resultMap="EmpResult">
    select * from EMPLOYEE
  </select>
<!-- Select the data from the table based on the id. -->
<select id="selectEmpById" parameterClass="int" resultClass="Employee">
 <select emp_id as id,emp_firstname as firstName,     emp_lastname as lastName from EMPLOYEE where emp_id= #id#
</select>
<!--  insert the data into the table -->
<insert id="insertEmp" parameterClass="Employee">
    insert into EMPLOYEE (
      emp_id,
       emp_firstname,
       emp_lastname)
    values (
      #id#, #firstName# , #lastName# )
  </insert>
<!-- update the Employee record based on the id -->
  <update id="updateEmp" parameterClass="Employee">
    update EMPLOYEE set
      emp_firstname = #firstName#,
      emp_lastname = #lastName#
    where
      emp_id = #id#
  </update>
<!-- delete the Employee record based on the given id -->
    <delete id="deleteEmp" parameterClass="int">
    delete from EMPLOYEE where emp_id = #id#
  </delete>
</sqlMap>

Listing 2에서 typeAlias 태그는 타입에 대한 별칭으로 사용되어서 매번 경로까지 포함한 전체 클래스명을 타이핑하지 않아도 되도록 해준다. 이 태그는 쿼리로부터 반환되는 컬럼과 Employee클래스로 표현되는 클래스의 프로퍼티에 대한 매핑 정보를 가지는 resultMap 태그를 포함한다. 이 resultMap태크에 이어 쿼리들이 정의된다. SQLMap.xml은 여러개의 쿼리들을 포함한다. select, insert, update, delete 문장들은 각각의 태그안에 쓰여진다. 모든 문장은 id 어트리뷰트를 사용하여 이름이 지어진다.

Loading the descriptor files to your Java application

XML파일들간에 매핑작업과 전체적인 설정이 완료되면 SQLMapConfig.xml을 자바 애플리케이션에서 가져와 사용해야 한다. 첫단계는 앞서 작성했던 SQLMap.xml 설정파일을 로딩하는 것이다. 이를 위해 Listing 3.에 있는 iBATIS 프레임워크에 포함되어 있는 com.ibatis.common.resources.Resources 클래스를 사용할 것이다.

Listing 3. Loading SQLMap.xml

private static SqlMapClient sqlMapper;
...
 try {
      Reader reader = Resources.getResourceAsReader("com/mydomain/data/SqlMapConfig.xml");
      sqlMapper = SqlMapClientBuilder.buildSqlMapClient(reader);
      reader.close();
    } catch (IOException e) {
      // Fail fast.
      throw new RuntimeException("Something bad happened while building the SqlMapClient instance." + e, e);
    }
  }

SqlMapClient클래스는 SQLMaps와 함께 사용된다. 이는 select, insert, update등과 같은 문장들에 해당하는 액션들을 수행한다. SqlMapClient객체는 Thread safe하기때문에 한개의 객체만 사용해도 충분하다. 따라서 static 멤버로 선언하는 것이 적절하겠다. 이 객체는 하나의 SQLMapConfig.xml파일로부터 설정 정보를 읽어와 생성된다. iBATIS프래임워크는 SQLMapConfig.xml파일을 읽기 위한 Resources.getResourceAsReader() 유틸리티를 제공한다. 따라서 SQLMap클래스의 인스턴스를 사용하여 데이터베이스로부터 객체에 접근할 수 있다.(이번 경우에는 Employee객체)

EMPLOYEE테이블에 있는 연산을 호출하기 위해서 여러종류의 메소드가 있지만 그중에서도 queryForList(), queryForObject(), insert(), update(), queryForMap()과 같은 SQLMap에서 제공하는 메소드들이 제공된다.  Listing4에 있는 queryForList()메소드는 Employee객체들의 리스트를 반환한다.

Listing 4. queryForList()

sqlMapper.queryForList("selectAllEmps");

쿼리의 결과로 한개의 로우를 가져오고자 할때는 queryForObject()를 사용하면 된다. 이 두가지 메소드 모두 파라미터로 쿼리문의 이름을 받는다.

이와 유사하게 Listing 5처럼  insert, update, delete연산을 수해할 수 있는 메소드들이 있다. 이 메소드들은 SQLMap.xml파일에 선언된 쿼리분의 이름과 파라미터로 Employee객체를 넘겨받는다.

Listing 5. Insert, update, and delete operations

sqlMapper.insert("insertEmp", emp);
sqlMapper.update("updateEmp", emp);
sqlMapper.delete("deleteEmp", id);

iBATIS에서는 이런 방식으로  SQL문장을 직접적으로 사용하여 자바객체를 저장하게 된다.

언제 iBATIS를 사용하는가

iBATIS는 SQL에 대한 모든 컨트롤을 하고자 할때 매우 적합하다. SQL쿼리들이 매우 잘 최적화되어있을때에도 유용하다. iBATIS는 애플리케이션과 데이터베이스간의 설계에 대한 모든 조작을 하고자 할때는 적합하지 않다. 그 이유는 애플리케이션과 데이터베이스간에 서로 잘 구조화되도록 설정이 바뀌어야하기 때문이다. 이러한 경우에 객체관계(object-relational)애플리케이션을 개발할 수 있으며 다른 ORM툴을 사용하는것이 더 올바른 선택일 것이다. iBATIS는 상대적으로 더 SQL중심적이기때문에, ORM툴들이 생성해내는 SQL에 반해 iBATIS는 SQL을 직접적으로 사용하게 된다. iBATIS는 관계 데이터베이스가 아닌 데이터베이스들을 사용할때에도 적절치 않다. 그러한 데이터베이스들은 트랜잭션이나 iBATIS가 사용하는 주요 기능들을 제공하지 않기 때문이다.

to be continue…

p.s>이제 좀 알고 싶은 내용이 나온다…-0-; 회사일이 바뻐서 진도를 못빼고 틈날때 바짝 하느라 번역질이 낮을거 같지만,,,
쿨하게 publish를 눌러본다.-_-;