스프링 2.5 환경에서 하이버네이트 사용하기

참조 요약: Spring One 2008 Wokring With Hibernate in a Spring 2.5 Environment

스프링의 HibernateTemplate
(Hibernate 3.1 이전)

– 스프링이 관리하는 트랜잭션을 사용한다.
– 예외 번역 제공

public class HibernateClinic extends HibernateDaoSupport {

}

Native Hibernate DAO
(Hibernate 3.1+_

– 트랜잭션 훅(hook)을 제공한다.
– transactional session을 찾는 로직을 제공할 수 있게 한다. sessionFactory.getCurrentSession()
– 예외 번역 제공 @Repository PersistenceExceptionTranslation post processor
– 순수 하이버네이트 API만 사용할 수 있다.

단위 테스트 종류
– “Logical” 단위 테스트
– 통합 테스트

스프링으로 통합 테스트하기
– DI
– 애플리케이션 컨텍스트 로딩 줄이기
– 자동 롤백
– 하이버네이트 + JDBC 조합

AbstractTransactionalDataSourceSpringContextTests
– Ctrl + Shift + T ATDSSCT
– 애플리케이션 컨텍스트 로딩, 캐슁
– DI
– JdbcTemplate 제공

WAR에서 하이버네이트 VS OSGi 개발
– 일반 WAR 배포
  – SessionFactory가 클래스패스에 도메인 타입들을 찾는다.
  – 저장소(DAO, repositoru)들이 SessionFactory를 사용한다.
– OSGi 개발
  – 여러 도메인 번들로 쪼갠다.
  – SessionFactory는 도메인 타입에 접근해야 한다.
  – 저장소는 SessionFactory에 접근해야 한다.

OSGi 환경에서 하이버네이트
– “infrastructure” 번들
  – SessionFactory 서비스를 제공하고
  – 모든 도메인 타입을 가져온다.
– 여러 도메인 모델
  – 도메인 타입을 공개한다.
  – SessionFactory 서비스를 사용한다.
– Petclinic 예제를 제공한다.

=====

발표에서 다루는 내용이 너무 많아서 다소 산만했습니다. 하이버네이트만 집중적으로 다뤘으면 어땠을까 싶더군요. @Repository 얘기가 나오니까 컴포넌트 스캔 얘기로 새고.. 도메인 객체에 repository 객체 주입하는 얘기가 나오니까 @Configurable이랑 aspectj 얘기로 새고.. 테스트 얘기 나오니까 Test Context 쪽으로 또 얘기가 새버렸다가 나중엔 다시 하이버네이트랑 OSGi 얘기 조금 꺼내고 끝~~

멋진건 54분이라는 짧은 발표 시간 중에도 저렇게 많은 내용과 중간 중간 전부 데모까지 보여줬다는 겁니다.

Spring Architecture – Eberhard Wolff

참조: http://www.parleys.com/display/PARLEYS/Home#slide=1;title=Spring%20Architectures;talk=20676612

아키텍처

The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them.

Wikipedia

객체: Information hiding

클래스: 객체의 타입을 정의. White box 재사용.

재사용:

A Software Component is a unit of composition with contractually-specified interfaces and explicit  context dependencies only. A software component can be deployed independently and is subject to composition by third parties.

C. Szyperski: Component Software – Beyond Object-
Oriented Programming, Addison-Wesley, 1999

컴포넌트: note the plugability.
– 계약 같은 인터페이스
– Only 명시적인 의존성
– 독립적인 배포
– 컴포지션
– 결과: 간편한 재사용(black box)
– 결과: 간편한 수정(인터페이스는 놔두고 내부만 바꿀 수 있으니.)

객체는 컴포넌트인가?
– 계약 같은 인터페이스? 있네, public 메소드
– 명시적인 의존성? 없네. 코드 내부에서 암거나 만들 수 있으니까.
– 독립적인 배포? 대부분은 안 돼지.
– 컴포지션? No.

DI를 사용하는 객체는 컴포넌트?
– 계약 기반인가? 응
– 명시적인 의존성? 응 설정하자나. setter/constuctor injection,
– 독립적인 배포? Yes. Everything else is injected
– 컴포지션? Yes. DI 컨테이너를 사용해서 조합하니까.

계층
– 각각의 계층은 하위 계층에만 의존해. -> 더 나은 의존성 관리(계층을 쉽게 바꿀 수 있으니까..)
– Typical technical
– 퍼사드를 사용할 수 있음.

스프링을 사용하는 컴포넌트
– 스프링 설정 파일을 각각의 컴포넌트 별로 만든다.
– 추가적인 기반 설정 파일은 javase.xml로..
– Facade를 인터페이스로 추가하고, bean 설정 파일에서 의존성을 정의한다.
– 각각의 컴포넌트는 JAR 파일로.
– 자신만의 빌드 스크립트를 가지고 있고
– 그들 컴포넌트를 묶을 때는 classpath*을 사용한다.

ApplicationContext applicationContext =
 new ClassPathXmlApplicationContext(
  “classpath*:/config/applicationContext.xml”);

스프링 설정 파일 + Facade 사용했을 때 컴포넌트 체크 리스트
– Contractually-specific 인터페이스? Yes. Facade 사용했으니까.
– Only explicit context depedencies? No. 스프링 빈 의존성이 명시적이지 않을 수도 있다.
– 독립적인 배포 가능? Yes. 설정 파일 + 참조하는 클래스
– A way of composition? Yes. 스프링 DI.

계층은 어떤가?
– ApplicationContext 계층 구조를 사용해서 구현했다.
– DispatcherServlet과 ApplicationContext 같은 예.
– 예제 코드

ApplicationContext environmentApplicationContext =
 new ClassPathXmlApplicationContext(
  “javase.xml”);

ApplicationContext persistenceApplicationContext =
 new ClassPathXmlApplicationContext(
  new String[] { “classpath*:*-persistence.xml” },
 environmentApplicationContext);

ApplicationContext logicApplicationContext =
 new ClassPathXmlApplicationContext(
  new String[] { “classpath*:*-logic.xml” },
  persistenceApplicationContext);

ApplicationContext guiApplicationContext =
 new ClassPathXmlApplicationContext(
  new String[] { “classpath*:*-gui.xml” },
  logicApplicationContext);

Vertical Slices.
– 예제 코드

ApplicationContext environmentApplicationContext =
 new ClassPathXmlApplicationContext(“javase.xml”);

ApplicationContext catalogApplicationContext =
 new ClassPathXmlApplicationContext(
  new String[] { “classpath*:/catalog-*.xml”},
 environmentApplicationContext);

ApplicationContext configuratorApplicationContext =
 new ClassPathXmlApplicationContext(
  new String[] { “classpath*:/configurator-*.xml” },
 catalogApplicationContext);

ApplicationContext trackingApplicationContext =
 new ClassPathXmlApplicationContext(
  new String[] { “classpath*:/tracking-*.xml”},
configuratorApplicationContext);

이후 발표는…
– 스프링 JavaConfig를 사용해서 스프링을 사용해서 컴포넌트 설정 예제
– 스프링 DM을 사용하여 컴포넌트 개발 예제
가 이어집니다.

Using Spring Security 2

참조: http://www.parleys.com/display/PARLEYS/Home#slide=1;title=Using%20Spring%20Security%202;talk=19267601

귿. 발표자 말투도 느린편이고, 억양도 알아들을만 합니다. 어제 들은 아리드안 코일러의 AOP 발표에 비하면 훨씬 알아 듣기 쉬운것 같네요.

데모 코드는 스크린캐스팅에 잡히지 않아서 참조할 수 없었지만, 대충 말해주면서 코딩하기 때문에 어떻게 코딩하는지 눈치챌 수 있습니다. 물론 Spring Security 2에 새로 도입한 스키마들을 알고 계셔야게죠.

몇 가지 정리해둡니다.

1. URL 권한 확인으로는 충분하지 않다.
– 리소스랑 URL이랑 1:1로 맵핑되는게 아닌 경우.
/listCustomers.html 과 /print.view?page=listCustomers 이 두 개의 URL이 같은 리소스를 나타낼 경우 권한처리를 어떻게 할 것인가
– URL이 없을 수도 있다.
Web Application이 아닌 경우 권한 처리는?
– 여러 Ajax 요청을 처리하는 하나의 URL
헤더 정보만 조금씩 다른데, 그 정보에 따라 권한 처리해야 할테네 어떻게 할텐가?

=> Method Authonrization!!

2. 메소드 권한처리
– AspectJ 포인트컷 표현식 사용 가능
– @Secured 애노테이션 사용 가능
– JSR 250의 @RoleAllowed 사용 가능

3. 베스트 프랙티스
– URL 체크로 개괄적인(corse grained) 권한 처리를 한다.
– 메소드 체크로 세밀한(fine grained) 권한 처리를 한다.
– Role 사용하지 말고, Right를 사용하라. User <–> Role <–> Riht
@Secured(“PERM_DELETE_USER)
public oid deleteUser(User user)

마지막 문구

Spring Security is more powerful than Acegi was
… and now it is also easy 😉

http://www.parleys.com 멋진 싸이트

사용자 삽입 이미지
Adobe Air로 만들어서, 그걸 설치해줘야 하는데 간단하네요. 설치한 뒤에 발표를 볼 수 있습니다. Spring One 2008 발표자료 중 하나가 떴네요. 캬오~ 멋져부러.

– Using Spring Security 2
http://www.parleys.com/display/PARLEYS/Home#slide=14;title=Using%20Spring%20Security%202;talk=19267601

Spring One 2008 세션 주제 살펴보기

로드존슨의 키노트로 Spring One 2008이 시작.

Spring Core
Spring 2.5 on the Way to 3.0
OSGi Programming Mode
Using Spring Security 2
Spring Transaction Choices for Performance
Five Aspects You Don’t Know About
Working with Hibernate with Spring 2.5
Open Forum with Rod Johnson
Applying the Spring Frameworks for Model-Driven Architecture
Making Sense of AOP Choices
– Spring Architecture and Best Practices

Spring Enterprise
Enterprise Application Management
Enterprise Development Tools for Spring
Spring Dynamic Modules for OSGi
Enterprise Integration with Spring Batch
Enterprise Integration Patterns with Spring

Spring Web
Decorating Web Pages with AJAX using Spring JavaScript
Using Spring Web Services
What’s new in Spring MVC 2.5 and beyond
JavaServerFaces – The Biggest Loser of Java Web Frameworks?
RESTful Web Services in Spring
Spring Web Flow 2.0 Deep Dive

Spring In Production
Spring – Case Study
Persistence Tuning for the Spring Environments
Introduction to the Springsource Application Platform
Building Web Applications with the Springsource Application Platform
Inside SpringSource Application Platform
Classloading in OSGi

Partner Talk
EclipseLink–High Performance Persistence for Spring
– Case study – Spring and Spring MVC in Production
Model Centric Design and Development of RIAs for Spring

하나같이 주제들도 좋고 무언가 기대하게 만드는 군요. 위 세션들 중에 일부는 어떤 블로그에 요약본을 올려주고 있습니다. 저같이 갈증나시는 분들은 그걸로라도…