EJB 3 가 나오면서 Java Persistence API (JPA)가 등장하게 되었다. Persistent 는 Cobuild 사전에 다음과 같이 정의되어 있다.
첫번째는 별로 안좋은 의미로 '완고한', '고집이 센' 정도로 받아들일 수 있을 것 같다. 두번째는 어려움이나 저항이 심해도 무엇인가를 계속해서 시도하려는 상태를 의미하는 것 같다. 보통은 '영속성', '지속성' 이라는 것으로 표현한다.
그럼 Java Persistence 를 '자바 지속성', '자바 영속성' 이라고 표현하는게 올바른 것인가? 또한, Hibernate나 JDO와 같은 Persistence Framework를 '지속성/영속성' 프레임워크라고 표현해야 하는가? 한글로 어떻게 표현할지에 대한 것은 조금은 미루어두고 우선 Persistence라는 것이 소프트웨어에서 무엇을 의미하는지 살펴보자.
최근 들어, 3 amigo들(Ivar Jacobson, James Rumbaugh, Grady Booch)의 개정판들이 나오기 시작했다.
Booch 책의 3판이 2007년도에 개정되어서 출판되었으며, Jacobson의 UseCase 책도 2008년도에 개정판이 나올 예정인 것 같다.
Booch 의 책 69쪽을 보면 Persistence에 대한 의미를 설명하고 있다.
Persistence의 의미
소프트웨어에서 객체는 어느 정도의 공간을 점유하고 특정 시간 동안 존재하게 된다. Atkinson 등 여러 사람들은 수식의 평가 내에서 발생되는 임시적인(transitory) 객체에서 부터 단일 프로그램의 실행보다 오래 유지되는 데이터베이스에 있는 객체까지 객체 존재에 대한 지속성(continuum)이 있다고 주장한다. 이러한 객체 persistence에 대한 의견은 다음과 같은 사항들을 포함하고 있다.
전형적인 프로그래밍 언어는 통상 처음 세가지 정도의 객체 persistence 만을 강조하는 반면에, 나머지 세가지 종류의 persistence는 일반적으로 데이터베이스 기술의 영역이다. 이로 인해서 매우 엉뚱한 아키텍처 결과를 초래하기도 하는 문화적인 충돌이 발생된다. 즉, 프로그래머들은 프로그램 실행 간에 상태가 보존되어야만 하는 객체를 저장하기 위한 특별한 목적의 스키마를 잘 만들고자 하고, 데이터베이스 설계자들은 자신들의 기술을 임시적인(transient) 객체에도 처리하게끔 잘못 적용한다는 것이다.
Atkinson 등이 말한 "프로그램 보다 오래 남는 데이터"에 대한 재미있는 확대 해석은 어플리케이션이 전체 트랜잭션 실행 동안 사용중인 데이터와 연결이 끊어질 수 있는 웹 어플리케이션의 경우이다. 데이터 소스와 연결이 끊어진 동안에 클라이언트 어플리케이션이나 웹 서비스에 제공된 데이터에게 어떤 변화가 발생될 것이며, 둘 간의 정확성은 어떻게 처리되어야 하는가? MS의 ADO.NET과 같은 프레임워크는 그러한 분산되고 연결이 끊어지는 시나리오를 해결하는데 도움을 주고 있다.
동시성(concurrency)과 객체에 대한 개념의 연결됨으로 인해 동시성 객체지향 프로그래밍 언어(concurrent object-oriented programming language)를 발생하게 했다. 비슷한 경향으로 객체에 대한 persistence 개념의 대두는 객체지향 데이터베이스를 발생하게 했다. 실제적으로 이러한 데이터베이스는 sequential, indexed, hierarchial, network, 관계형 DB 모델과 같은 검증된 기술을 토대로 만들어졌으나, 개별 프로그램의 생명기간(lifetime)을 넘어서는 객체의 생명시간이라는 관점에서 DB 쿼리와 다른 오퍼레이션들이 완성되는 것을 통해 객체지향 인터페이스의 추상화를 프로그래머에게 제공한다. 이러한 통합(unification)은 전반적으로 특정 종류의 어플리케이션에 대한 개발을 단순화시킨다. 특히, 어플리케이션의 DB적인 측면과 DB가 아닌 측면에 동일한 설계 방법을 적용을 가능하게 한다.
어떤 객체지향 프로그래밍 언어는 persistence에 대한 직접적인 지원을 제공한다. Java는 EJB와 JDO(Java Data Object)를 제공한다. Smalltalk는 저장소로 혹은 저장소로부터 객체를 스트리밍하는 프로토콜을 가진다. (하위 클래스에 의해서 재정의가 되어야 함) 하지만, 객체를 2차원적인 평평한 파일로 스트리밍하는 것은 제대로 맞지않는 persistence에 대한 원초적인 해결책이다. Persistence는 몇몇 상업적으로 유용한 객체지향 DB를 통해서 달성될 수 있다. persistence에 대한 좀 더 전형적인 방법은 관계형 DB에 객체지향 껍질(skin)을 입히는 것이다. 수정된 객체-관계형 매핑이 개별 개발자들에 의해서 만들어질 수 있다. 하지만, 이것은 잘 하기에는 매우 도전적인(문제가 많은) 작업이다. 오픈소스 프레임워크인 Hibernate와 같은 프레임워크가 이러한 작업을 수월하게 해준다. 이러한 방법은 대체하기에는 위험하거나 너무 비용이 많이 발생될 수 있는 관계형 DB 기술에 대규모 투자가 이루어졌을 때 가장 매혹적이다.
persistence는 데이터에 대한 생명기간 이외에 더 많은 것을 다룬다. 객체지향 DB에서 객체의 상태를 영구 보존할 뿐만 아니라 객체의 클래스도 개별 프로그램보다 더 오래 유지시킴으로써 모든 프로그램이 동일한 방식으로 저장된 상태를 해석한다. 이는 특히 객체의 클래스를 변경해야하는 경우 DB의 무결성(integrity)을 유지하는데에 노력을 하게끔 한다.
대부분의 시스템에서 일단 생성된 객체는 존재가 소멸되기 까지 동일한 물리적인 메모리를 소비한다. 하지만, 분산된 여러 프로세서에서 실행되는 시스템에서 공간을 건너띄는 persistence에 관심을 쏟아야만 하는 경우도 있다. 그러한 시스템에서 기계(machine)에서 기계로 이동하고 서로 다른 기계에서 서로 다른 표현을 가질 수 있는 객체를 생각하는 것이 필요하다.
요약하면 persistence는 다음과 같이 정의된다.
이상과 같이 Booch 책에서 persistence라는 의미를 설명한 내용이다. 마지막에 요약되어서 나와있지만, 객체가 시간과 공간을 초월하여 여러 프로그램간을 옮겨다닐 수 있는 성질로 표현할 수 있는데, 딱히 우리말로 한단어로 표현하기가 쉽지 않다. 프로그래머가 가장 이해하기 쉬운 단어는 '객체의 저장' 정도가 되겠지만, 이렇게 번역하기는 또한 persistence가 갖게 되는 다른 의미가 많이 상쇄되는 느낌이다. 왜냐하면 '저장' 이라는 의미가 주로 DB 저장을 뜻하는 경우가 대부분이기 때문일 것이다. 아무튼 'DB 저장' 과는 별도의 개념인 '객체 저장(persistence)' 이라는 개념이 필요할 것 같다.
1. Something that is persistent continues to exist or happen for a long time; used especially about bad or undesirable states or situations.
2. Someone who is persistent continues trying to do something, even though it is difficult or other people are against it.
2. Someone who is persistent continues trying to do something, even though it is difficult or other people are against it.
첫번째는 별로 안좋은 의미로 '완고한', '고집이 센' 정도로 받아들일 수 있을 것 같다. 두번째는 어려움이나 저항이 심해도 무엇인가를 계속해서 시도하려는 상태를 의미하는 것 같다. 보통은 '영속성', '지속성' 이라는 것으로 표현한다.
그럼 Java Persistence 를 '자바 지속성', '자바 영속성' 이라고 표현하는게 올바른 것인가? 또한, Hibernate나 JDO와 같은 Persistence Framework를 '지속성/영속성' 프레임워크라고 표현해야 하는가? 한글로 어떻게 표현할지에 대한 것은 조금은 미루어두고 우선 Persistence라는 것이 소프트웨어에서 무엇을 의미하는지 살펴보자.
최근 들어, 3 amigo들(Ivar Jacobson, James Rumbaugh, Grady Booch)의 개정판들이 나오기 시작했다.
Booch 책의 3판이 2007년도에 개정되어서 출판되었으며, Jacobson의 UseCase 책도 2008년도에 개정판이 나올 예정인 것 같다.
Booch 의 책 69쪽을 보면 Persistence에 대한 의미를 설명하고 있다.
Persistence의 의미
소프트웨어에서 객체는 어느 정도의 공간을 점유하고 특정 시간 동안 존재하게 된다. Atkinson 등 여러 사람들은 수식의 평가 내에서 발생되는 임시적인(transitory) 객체에서 부터 단일 프로그램의 실행보다 오래 유지되는 데이터베이스에 있는 객체까지 객체 존재에 대한 지속성(continuum)이 있다고 주장한다. 이러한 객체 persistence에 대한 의견은 다음과 같은 사항들을 포함하고 있다.
■ 수식 평가의 임시적인(transient) 결과
■ 절차적인 프로그램의 지역 변수
■ (ALGOL 60과 같은) 프로그램 언어 자체적인 변수, 전역 변수, 범위마다 정도의 차이가 있는 heap 항목
■ 프로그램 실행 간 존재하는 데이터
■ 프로그램의 다양한 버전 간 존재하는 데이터
■ 프로그램 보다 오래 남는 데이터
■ 절차적인 프로그램의 지역 변수
■ (ALGOL 60과 같은) 프로그램 언어 자체적인 변수, 전역 변수, 범위마다 정도의 차이가 있는 heap 항목
■ 프로그램 실행 간 존재하는 데이터
■ 프로그램의 다양한 버전 간 존재하는 데이터
■ 프로그램 보다 오래 남는 데이터
전형적인 프로그래밍 언어는 통상 처음 세가지 정도의 객체 persistence 만을 강조하는 반면에, 나머지 세가지 종류의 persistence는 일반적으로 데이터베이스 기술의 영역이다. 이로 인해서 매우 엉뚱한 아키텍처 결과를 초래하기도 하는 문화적인 충돌이 발생된다. 즉, 프로그래머들은 프로그램 실행 간에 상태가 보존되어야만 하는 객체를 저장하기 위한 특별한 목적의 스키마를 잘 만들고자 하고, 데이터베이스 설계자들은 자신들의 기술을 임시적인(transient) 객체에도 처리하게끔 잘못 적용한다는 것이다.
Atkinson 등이 말한 "프로그램 보다 오래 남는 데이터"에 대한 재미있는 확대 해석은 어플리케이션이 전체 트랜잭션 실행 동안 사용중인 데이터와 연결이 끊어질 수 있는 웹 어플리케이션의 경우이다. 데이터 소스와 연결이 끊어진 동안에 클라이언트 어플리케이션이나 웹 서비스에 제공된 데이터에게 어떤 변화가 발생될 것이며, 둘 간의 정확성은 어떻게 처리되어야 하는가? MS의 ADO.NET과 같은 프레임워크는 그러한 분산되고 연결이 끊어지는 시나리오를 해결하는데 도움을 주고 있다.
동시성(concurrency)과 객체에 대한 개념의 연결됨으로 인해 동시성 객체지향 프로그래밍 언어(concurrent object-oriented programming language)를 발생하게 했다. 비슷한 경향으로 객체에 대한 persistence 개념의 대두는 객체지향 데이터베이스를 발생하게 했다. 실제적으로 이러한 데이터베이스는 sequential, indexed, hierarchial, network, 관계형 DB 모델과 같은 검증된 기술을 토대로 만들어졌으나, 개별 프로그램의 생명기간(lifetime)을 넘어서는 객체의 생명시간이라는 관점에서 DB 쿼리와 다른 오퍼레이션들이 완성되는 것을 통해 객체지향 인터페이스의 추상화를 프로그래머에게 제공한다. 이러한 통합(unification)은 전반적으로 특정 종류의 어플리케이션에 대한 개발을 단순화시킨다. 특히, 어플리케이션의 DB적인 측면과 DB가 아닌 측면에 동일한 설계 방법을 적용을 가능하게 한다.
어떤 객체지향 프로그래밍 언어는 persistence에 대한 직접적인 지원을 제공한다. Java는 EJB와 JDO(Java Data Object)를 제공한다. Smalltalk는 저장소로 혹은 저장소로부터 객체를 스트리밍하는 프로토콜을 가진다. (하위 클래스에 의해서 재정의가 되어야 함) 하지만, 객체를 2차원적인 평평한 파일로 스트리밍하는 것은 제대로 맞지않는 persistence에 대한 원초적인 해결책이다. Persistence는 몇몇 상업적으로 유용한 객체지향 DB를 통해서 달성될 수 있다. persistence에 대한 좀 더 전형적인 방법은 관계형 DB에 객체지향 껍질(skin)을 입히는 것이다. 수정된 객체-관계형 매핑이 개별 개발자들에 의해서 만들어질 수 있다. 하지만, 이것은 잘 하기에는 매우 도전적인(문제가 많은) 작업이다. 오픈소스 프레임워크인 Hibernate와 같은 프레임워크가 이러한 작업을 수월하게 해준다. 이러한 방법은 대체하기에는 위험하거나 너무 비용이 많이 발생될 수 있는 관계형 DB 기술에 대규모 투자가 이루어졌을 때 가장 매혹적이다.
persistence는 데이터에 대한 생명기간 이외에 더 많은 것을 다룬다. 객체지향 DB에서 객체의 상태를 영구 보존할 뿐만 아니라 객체의 클래스도 개별 프로그램보다 더 오래 유지시킴으로써 모든 프로그램이 동일한 방식으로 저장된 상태를 해석한다. 이는 특히 객체의 클래스를 변경해야하는 경우 DB의 무결성(integrity)을 유지하는데에 노력을 하게끔 한다.
대부분의 시스템에서 일단 생성된 객체는 존재가 소멸되기 까지 동일한 물리적인 메모리를 소비한다. 하지만, 분산된 여러 프로세서에서 실행되는 시스템에서 공간을 건너띄는 persistence에 관심을 쏟아야만 하는 경우도 있다. 그러한 시스템에서 기계(machine)에서 기계로 이동하고 서로 다른 기계에서 서로 다른 표현을 가질 수 있는 객체를 생각하는 것이 필요하다.
요약하면 persistence는 다음과 같이 정의된다.
Persistence는 객체의 존재가 시간(즉, 객체는 객체를 생성한 무엇인가가 존재를 끝마치게 한 후에 계속해서 존재함)이나 공간(즉, 객체의 위치는 객체가 생성되었던 주소 공간에서 부터 이동됨)을 초월해서 여기저기 옮겨다니는(through) 객체의 성질(property)이다.
이상과 같이 Booch 책에서 persistence라는 의미를 설명한 내용이다. 마지막에 요약되어서 나와있지만, 객체가 시간과 공간을 초월하여 여러 프로그램간을 옮겨다닐 수 있는 성질로 표현할 수 있는데, 딱히 우리말로 한단어로 표현하기가 쉽지 않다. 프로그래머가 가장 이해하기 쉬운 단어는 '객체의 저장' 정도가 되겠지만, 이렇게 번역하기는 또한 persistence가 갖게 되는 다른 의미가 많이 상쇄되는 느낌이다. 왜냐하면 '저장' 이라는 의미가 주로 DB 저장을 뜻하는 경우가 대부분이기 때문일 것이다. 아무튼 'DB 저장' 과는 별도의 개념인 '객체 저장(persistence)' 이라는 개념이 필요할 것 같다.
반응형
'Homo Faber > Concepts' 카테고리의 다른 글
| Domain Driven 과 Model Driven (1) | 2008.02.28 |
|---|---|
| Domain Driven Design(2) - Entity [Reference Object] (0) | 2008.02.26 |
| Domain Driven Design(1) - Association (0) | 2008.02.25 |
| Hibernate에서 Equals 와 HashCode (0) | 2008.02.21 |
| 객체지향 어플리케이션에서의 Persistence (0) | 2008.02.15 |