익스트림 프로그래밍 제2판을 사기위해 강컴에 들렸다가 배송비 내는 것이 아까워
뭐하나 더 살까(항상 이런식이다.) 둘러보다 반가운 이름을 보게 되었다.
SWT/JFace 인 액션 : 이클립스 스타일로 만드는 자바 GUI 애플리케이션
이라는 책을 보다보니..
==================================
양석호 javanese@naver.com
KAIST 전산과를 졸업하고, 웹, 모바일, 임베디드, 자바 GUI애플리케이션 등 다양한 프로젝트를 수행했다. 모바일 애플리케이션 개발 도구를 이클립스 기반으로 만들다가 이클립스에 완전히매료되었으며 현재 네이버 이클립스 플러그인 까페(http://cafe.naver.com/eclipseplugin)를 운영하고있다.
==================================
라는 것이 있지 않은가. 오랜 잊혀진 친구를 만난듯 너무 반가웠다.
더욱이 틈틈히 지식을 담아주기 위해 북마크의 '하루에한번' 메뉴에도 들어있는 사이트
'네이버 이클립스 플러그인 까페'의 주인장 javanese가 석호였다니.. ^^

하이텔에서 만나 자바랜드를 오픈하기전인 초기시절부터 실력으로도 두각을 내고, 어린 나이에도
어른스럽게 행동하였기에 모두의 이쁨을 받았던 석호였는데..
어느덧 기간이 흘러, 사회의 한 구성원으로 그리고 한 분야의 전문가로 성장해가는 모습을 보니
감회가 새롭고 가슴이 따듯해 진다.

관심은 항상 가지고 있고, 여유가 되면 해야지 미루어왔던 분야였지만,
이를 계기로 열심히 공부할 계기가 되지 않을까 싶다 ...
그렇기에... 주저하지 않고 이책도 주문해 버렸다. ^^

석호야 기다려라!~ 열심히 공부해서 카페에 글 남이 남겨주꾸마. ^^

Posted by 아름프로
한때 XP와 Agile쪽을 공부하며,
켄트백 가라사데 ... 에 신도마냥 정신없이 몰입했던 기억이 지금은 추억처럼 남아 있다.
당시 공부하던 때만해도 너무나도 이에 대한 인식과 지식이 부족하던 시대였기에..
이를 도입하기 위해 회사와 팀사람들과 옥신각신하며, 새로운 것 만을 너무 좋아하는 놈(^^;)
소리 들으며 결국엔 제대로 실천해 보지 못했던 아픈 기억이지만 ...
뭔가에 미쳐서 사람들과 미친듯이 주장하고 더 공부하던 것이 돌이켜보며.. 가장
즐거웠던 기억중에 하나가 아니였나 생각도 든다.

그런 것 있어 김창준씨처럼 한길로 오래기간 꾸준히 할 수 있는 모습에 ...
XP와 Agile란 것을 떠나 한 사람을 존중하며 존경안할 수 없는거 같다.

원본인 Extreme Programming Explained 를 봤음에도 기억조차 흐릿한 기억과 추억을
새롭게 변역되어 나온
' 익스트림 프로그래밍 제2판 : 변화를 포용하라'
를 통해서 찾아볼까 한다.

더불어 한때 나의 우상이였던, 켄트백의 동영상 'Ease At Work' 도 틈틈히 봐야겠다. ^^
구글 Ease At Work 
Posted by 아름프로
새롭게 마음도 다잡고, 정리도 할겸해서 개발환경을 새롭게 구성하기로 마음먹고 진행 중이다.
여기서 말하는 통합 개발환경이라는 것은 프레임워크, 개발툴, 관련서버, DB, 개발언어, 형상관리,
리팩토링, 테스트, 문서화, 레포팅, 모니터링 등등.. 모든 것을 다 포함한 개념이다.

개발이 단순 노다성을 벗어나며 프레임워크나 패턴의 사용에 따른 설계 및 코딩능력을 중요시 되던
시기가 있었지만, 이는 개발자의 능력과 사상에 따라 팀을 이루어 개발시에 오히려 문제를 일으키는
요소로까지 작용하였고, 그러한 부분은 여러 툴들이 기능을 향상함에 따라 어느정도 보안해기 시작했지만,
적지 않은 가격과 시간이 흐르며 툴에 종속적으로 그 모양새가 변모 되어갔다.
(그래서 한때는 특정 툴에서 개발 잘하던 개발자가 다른 툴에서는 어찌할 바를 모르는 웃지 못할 상황까지
생기기도 했었다.)

이러한 변화의 흐름속에 묻혀 생활하면서 얻은 결론은
시대에서 최고라 칭하는 프레임워크만을 잘한다고, 최고의 기능을 제공한다는 툴을 잘 다루는 것으로,
궁극적으로 원하는 단기간에 최고의 결과물을 내놓기가 어렵다는 것이였다.
결국, 이 모든 것과 그 이외에도 개발에서 사용되어야하는 모든 것들이 함께 잘 어울려져야만 해야만 했고,
또한 이것은 대중적(또는 범용적)인 환경을 제공해야 된다는 것이다.
(아무리 좋은 것도 프로젝트 시마다 새롭게 가르쳐야하고 배워야하는 것이라면, 이는 장점보다
단점이 더 많은 것이다.)

여러 과정과 시행착오, 경험들은 뒤로하고, 그래서 구성할 수 있는 최고의 조합이 현재로써는
eclipse과 springframework을 기반으로 한 통합 개발환경이다. (그 외 다양한 오픈소스들과...)
이 새부적인 내용에 대해서는 생각하는 환경이 구축되어감에 이곳을 통해 조금씩 정리해볼까 한다.

통합환경은 크게 이렇다고 하더라도, 새부적인 부분에 있어서도 이슈들이 상당히 많다.
우선 가장 핵심이되는 프레임워크 차원에서의 spring 의 쓰임새는 이를 사용해본 사람이라면
공감하겠지만, 사용하는 사람의 사상과 설계 방식에 따라서 완전히 달리할 수 있다는 것이다.

이전의 수많은 프레임워크라는 것을 접하고 하면서 지금의 struts나 spring을 바라보는 관점은
일반일들에 비해 나는 좀 달리하고 있고, 사용방식은 조금은 특이하다. (최소한 이러한 방식 또는
관점을 이야기하는 것을 듣고 보지 못했기에.. )

특히나, 웹기반에 있어서의 도메인 객체를  모델링하는 것은, 객체지향이라는 자바의 태생(!)에도
불구하고 이러한 설계를 상당히 싫어함을 넘어 Anti- 로까지 생각을 한다.
core J2EE Pattens에서 이야기하는 VO(Value Object), 최근에는 DTO(Data Transfer Object),
hibernat에서는 domain model 등.. 으로 이야기하는 그 모든 것들이 이 대상이 될 수 있다.

EJB가 툴에서 자동생성해 주는 것이 나오기전의 노가다로 일일이 작성하며, 초기 EJB 기반으로의
프로젝트를 진행해 본 사람이라면, 지금에 이야기하는 DTO나 DAO가 왜 필요한지, 그리고
자신도 모르는 사이 그러한 것을 구현한 것을 알 것이다.
하지만, 그렇게 구현한 DTO(VO)는 결국엔 고객의 무수한 요구사항 수정덕에 이렇게 설계 스스로에
대해, "왜 이렇게 설계한 것일까? 아니야 고객의 잘못이야? 아니지 이러한 수정요구까지 반영 못한
것이 잘못이지"라 떠들며 자학 또한 해보았을 것이다.
그러면서 편법으로 구현빈 내에 쿼리를 집어 넣지 않고 할 수 있는 방법과 파라메터들을 좀 더 유연하고
정형화해서 쓸 수 있는 방법들을 찾으며, 나름대로의 패턴과 프레임워크들을 만들어 보았으리라
생각한다.

이러한 것이 struts의 등장으로 사람들이 다시 우르르 이동과 함께 박수를 보내기 시작했다.
(struts가 EJB 대안이나 그렇다는 이야기는 분명아니다, 많은 이들에게 고민이 많던 시기에
등장했다는 것을 말하려는 것이다.)
나 또한 struts를 여러 프로젝트에서 감사의 마음(!)과 찹찹한 마음(그간만들었던 여러
MVC기반의 나만의 프레임워크가 날아간 순간)으로 잘(!) 사용하였다.
하지만, 개인적으로 사용을 좀 달리해서 사용하였다.
내가 사용하는 Action Mapping 은 프로젝트 많아야 3~5개 정도로 국한 시키는 방식이였고,
ActionForm 또한 사용하지 않는 방식이였다.
(프레임워크는 그대로 적용해야지, 프레임워크의 프레임워크를 만들면 안되다는 이야기 또한
있지만, 난 후자의 방식을 좋아하고 그것이 옳다고 믿는 사람이다.)
대규모 프로젝트의 Action Mapping을 모든 화면의 Action마다 만들어서는 오히려 감당히
어려웠기에 공통의 호출과 그에 따른 리턴 방식을 공통화 시키고, 웹기반에서 주로 사용하는
다운로드, 엑셀변환, pdf 추출, 프린터등등을 별도의 모듈로 만들어 이를 Rule 기반으로 호출시에
이렇나 기능들이 동시에 처리되어 결과로 뿌려줄 수 있게 설계하였기에 이런 것이 가능하였다.

ActionForm을 사용하지 않았던 것은 앞선 EJB를 사용하면서 느꼈던 VO(DTO, DAO)를 별도로 생성해서
개발을 하는 것에 대한 불신(!) 때문이다. 이는 EJB의 비즈니스 로직의 변경보다 화면의 변경이슈가
더 많은 상황에서 화면상의 파라메터와 DTO 간의 종속성(나는 이렇게 표현한다)은 웹개발에 있어서
생산성을 현격히 저하 시킨다고 믿기 때문이다.
(여러 툴에서 이를 해소해 준다고는 하지만, 툴에 지나치게 종속적을 되는 것 또한 옳지 않다고 생각
하기도 하기에... )
이는 최근에 이슈가 되고 있는 DTO와 도메인 모델의 사용에 어느 것이 좋니, 나쁘니 하는 것에 있어
개인적으로는 둘 다 웹개발 생산성에 도움이 되지 않는다는 것으로도 이야기하는 것이다.
(이렇기에 사상적으로 많이 틀리다고 스스로 인정하는 부분이다.)
이러한 논리는 View단과 Controller단의 Layer을 어떻게 잘 구분하고 비즈니스 로직을 어디에 어떻게
줄까라는 것을 해결하기 위해, 많은 고민과 방식을 취하는 이들과는 상반 될 수도 있다고 본다.
이에 대해서는 논란의 소지가 다분히 있지만, 나만의 생각을 정리하는 것이기에..
그리고 누구에게도 강요하고픈 생각 또한 없는 것이기에 편안히 적고 있다.

어쨌든, 내가 얻은 경험에서의 핵심은.

1. DB로부터의 데이터를 가져오고 하는 기본은 변형된 쿼리 방식보다는 각 DB마다의 특성을
그대로 사용할 수 있는 쿼리를 사용할 수 있어야 한다. 즉, 표준 SQL이든 각 벤더에 종속된
쿼리든 그 쿼리 그대로를 사용할 수 있어야 하고, 이럴 시에만 대용량 데이터 처리든 대규모
프로젝트에 유리하다.

2. form 파라메터를 form data든 DTO나 도메인 객체든, 이를 다시 퍼시턴트 객체로 사용하든
하는 방식보다는 파라메터 자체를 쿼리와 직접적으로 처리하는 것이 개발 공수를 상당히
줄 일 수 있다.

3. 이를 위한 컨트롤러는 화면이나 액션마다의 맵핑에 따른 결과보다는 정형화된 패턴으로 호출과
결과값을 가져올 수 있도록 하는 것이 좋다.

는 것이다.

이를 위해서 지난 날에는 모든 부분을 실제 모두 개발을 했었지만,
지금에 있어서는 다음의 조합으로 가능하다.

1. 쿼리를 비즈니스 객체에서 분리하여, DAO는 정형화 할 수 있으며 이에 따른 개발은 spring기반으로
가능하며, 쿼리의 분리는 iBatis를 활용하면 된다. (예전엔 쿼리를 관리하는 XML을 별로도 두어
id를 주고 context상에 쿼리를 넣고 해석하는 등의 엔진을 만들어서 사용도 해봤다.)

2. form의 파라메터들은 Map 타입으로 받을 수 있기에 이는 iBatis에서의 Map을 파라메터들의 맵으로
받아 #파라메터명 으로 처리하는 것이 가능한 부분에서 효과적으로 사용이 가능하다.
(다시 말해, 굳이 form data를 사용하지 않고도 웹의 파라메터를 iBatis에서의 쿼리 파라메터로 바로
처리할 수 있게 있기에 일괄 된 결과 값을 가져올 수 있다.)
이러한 것을 통해 비즈니스 로직은 viewer단에서 자연스레 처리가 가능하다.
(비즈니스 로직이 DTO나 도메인 모델등에 어디에 포함되니 안되니하는 논란에서 벗어날 수 있다.)

3. 이 부분을 위해 예전에 Rule기반의 엔진을 별도로 만들어 XML기반에서 룰(element 또는 Attribute)을
임의대로 바꿔가며 호출해서 사용하였었다. 그런데 이 부분을 요즘에 쓰기 좋게 나온 오픈 Rule 엔진들
또는 Groovy 또는 JRuby를 활용, 이도 아니면 Sping의 WebFlow에서도 어느정도
가능하리라 보인다. (실제 1,2 부분은 얼마전의 프로젝트에서 사용해보며 가능성을 확인한바 있고,
3을 새롭게 설계함에 있어 1,2를 처리 방식이 단순 DB에서의 데이터만을 가져오는 것 이외에 여러
기능들이 추가 될 것으로 생각된다.)

다시 제목의 통합개발 환경으로 돌아가 이러한 기반위에 좀 더 효율적인 개발툴과 기능들의 연계를
새롭게 구성할까 한다.
초기에는 메시징 기반으로 웹서비스의 연동, ESB를 활용한 SOA기반과 BPEL을 포함 시킨 BPM기반으로의 연계 및 확장까지 구상해 보았지만, 일차적으로는 자바의 이러한 개발 환경을 '일반화'와 '대중화' 쪽에
목표를 두기로 했다.
그러기 위한 기준으로는 자바기반(JSP 호스팅)의 호스팅이 되는 곳에서 쉽게 사용이 가능하여야 되는
것을 전제로 하기로 했다.

이는 지금까지 기업솔루션 중심으로 개발을 해온 나였기에... 정작,
내 사이트를 PHP기반의 제로보드나 터터툴로..., 또 지인들의 부탁으로 PHP기반의 쇼핑몰을
만들어줘야했던 현실을 바꿔보고 싶은 마음도 있기 때문이다. (이젠 JSP 호스팅도 많아졌고 저렴도 해졌기에.. )
최근 zb5의 발표로 호스팅업체들의 MySQL4.1 지원, PHP5 등 지원으로 서버증설 및 난리를 치는 것을보며,
자바의 대중적 쓰임은 아직 미비할 따름이듯 싶다. 이에 기업 솔루션 개발 및 생각으로만 굳어버린
머리와 마음을 좀 더 많은 이들이 사용할 수 있는 것들을 만들고 나 또한 사용하고 싶은 요즘이고,

이러한 생각과 정리들을...
틈틈히 실천으로 만들어 볼까 한다.

ps : 위에 쓴 내용만으로는 이해하기 어려운 부분이 많으리란 것은 충분히 동감한다.
많은 분들이 공감할 수 있는 결과물이 빨리 나올 수 있는 날을 기대해 볼 따름이다.
Posted by 아름프로

Spring이 어느덧 2.0 RC2를 7월6일에 발표하였다.
개인적으로는 dev 메일링을 받아 개발진척이나 관련 프로젝트들의 진행을
꾸준히 모니터링하고 있는데, 분위기상  정식 릴리즈가 임박했음이 느껴진다.

이에 곧 나올 2.0 정식버젼에 앞서 어떤 것들이 새롭게 변모되었는지 이제는
한번쯤 봐둘 필요가 있을 듯 싶어 간단히 정리해 볼까한다.

1. IoC 컨테이너의 향상

  2.0으로 올라오며, 내부적으로 가장 많은 변화가 있었던 부분이 IoC 컨테이너
  부분이다. (단, 사용자 관점에서는 큰 변화를 느끼지 못하겠지만)
  간단히 간추려 보면,

  1.1. XML 설정파일이 쉬워지다.  

  내용인 즉, 새로운 스키마의 지원에 따른 내용을 쉽게 처리할 수 있다는 것이다.
  <util:XXX> , <jee:XXX> 와 lang, tx, aop 스키마가 추가 지원되고 이에 대한 것이
   IDE 에서의 제공되는 spring 플러그인에서 제공된다는 것이다.
   결과적으로 새로운 것 더 열심히 공부하면 더 쉽게 쓸 수 있다는 것이다. ^^
   참조 : http://static.springframework.org/spring/docs/2.0.x/reference/new-in-2.html

  1.2. XML 작성의 확장

  2.0에서는 단지 쉬어지기만 한 것이 아니라, 좀 더 확장성을 띄고 있다.
    이는 XML 스키마를 직접 작성가능하게 함으로 이를 가능케 한다.
    위에서 언급한 새롭게 등장한 스키마와 같이, 나 또는 팀에서 자주 사용하는 스키마에
    대해서 이미 스키마로 구현이 가능하다는 것이다. (말그대로 확장성을 대폭 강화하여
    spirng을 사용하는 개개인이 스키마 확장까지 가능하게 되었다.)
    참조 : http://static.springframework.org/spring/docs/2.0.x/reference/extensible-xml.html

  1.3. 새로운 bean 범위
    
  기존의 Spring은 IoC 컨네이터 레벨에서 두가지(singleton과 prototype)만 지원했었지만,
    2.0에서는 위의 두가지 이외에 request, session, global session 가 추가되었다.
    앞선 두가지는 local(!) 개발에 후자 3개는 웹기반에 적용된다.
    크게 변화가 없는 듯 하면서도 변화가 생긴 부분이라 하겠다. (기존 사용방식에는 차이가 없다.)
   참조 : http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-scopes
 
2. AOP
 
  2.0에서는 AOP 제공이 매우 향상되었다.
   XML 설정이 쉬워졌으며, AspectJ pointcut 언어와 @AspectJ와 통합되었다.
   (이것은 AspectJ의 리더인 Adrian Colyer가 지난해 9월 IBM에서 Interface21(스프링을 만드는 회사)로
   옮기면서 이미 예견된 부분이다.)

  2.1. 쉬워진 AOP XML 설정

  2.0은 aspects 를 위한 새로운 스키마를 지원한다. AspectJ pointcut 언어와 전체적인 타입에 대한 안내
  (캐스팅이나 Object[]아규먼트와 같은 더이상의 조작은 필요없다.)의 이점을 제공한다.
  <aop:config> 엘리먼트 내에 <aop:aspect> <aop:pointcut> 등과 같은 방법으로 사용 가능하다.
  참조 : http://static.springframework.org/spring/docs/2.0.x/reference/aop.html#aop-schema

  2.2.  @AspectJ aspects의 제공

  2.0 은 @AspectJ annotations의 사용을 제공하고 이는 AspectJ와 Spring AOP간에 공유가 가능하다.

3. Middle Tier (Data Access)

  3.1. XML 내에 선언된 트랜젝션의 설정이 쉬어졌다.

  기존의 1.2.X 스타일이 계속 지원은 되지만, 2.0 스타일을 추천되며, 이 방식은 작성을 쉽게 소스량(!)을
  현저히 줄인다. 주목해야 할 부분은 AspectJ aspects library와 사용이 가능한데 이때 다양한 오브젝트와
  사용이 가능한데 하물며, Sping container에서 생성되지 않은 객체까지 사용이 가능하다는 점이다.
  (의미적으로는 이런데 자세히 봐야되겠다. 기존의 트랜젝션 관리에 있어서 많은 솔루션들이 가지고 있던
  문제가 여러 객체를 거치는 (프로세스를 가지는) 트랜젝션의 처리가 쉽지 않다는 것이였는데, 이 의미로는
  이것 또한 해결이 가능하다는 이야기이므로 정확한 확인이 필요할 듯 싶다.
  이가 가능하다면 엔터프라이즈 솔루션에 있어 상당한 기여가 있을 것 같다.)

  3.2. JPA

  Spring의 JDBC 추상 레이어 목적으로 Hibernate, JDO와 같은 것을 동일한 방법 내에서 포괄적으로
  Java Persistence API를 위해 제공한다.
  + JPA 관련 참조 : http://static.springframework.org/spring/docs/2.0.x/reference/orm.html#orm-jpa
  + Java Persistence API 참고 : http://java.sun.com/developer/technicalArticles/J2EE/jpa/index.html

  3.3. Asynchronous JMS

  개인적으로 오래 기다려온 내용이다.  
    이전의 1.2 버젼까지의 Spring은 JMS를 제공함에 있어 JmsTemplate 클래스가 기능적으로 훌륭히
  추상화하여 사용의 간편함을 제공하였다. 그러나 이것은 메시지의 비동기적인 production 와
  consumption은 지원하는 것이 아니였다.
    이번 2.0 에서는 이러한 부족한 부분을 완성하여 비동기적인 부분까지 지원이 되었다.
    참고 : http://static.springframework.org/spring/docs/2.0.x/reference/jms.html#jms-asynchronousMessageReception

  3.4. JDBC

  Spring의 JDBC 추상 프레임워크 내에 새롭게 주목해야할 크랠스가 있는데,
  첫째가 NamedParameterJdbcTemplate 로 named parameters 의 사용을 지원한다.
  둘째가 SimpleJdbcTemplate 로 기존의 core 기능에서 더욱 사용을 간편하게 만들어졌다. 단, 이는 Java 5(Tiger에서만 사용가능)

  자세한 것은 참조 사이트의 예제를 보면 바로 이해가 될 듯하다.
  참조 : http://static.springframework.org/spring/docs/2.0.x/reference/jdbc.html#jdbc-NamedParameterJdbcTemplate
  참조 : http://static.springframework.org/spring/docs/2.0.x/reference/jdbc.html#jdbc-SimpleJdbcTemplate

4. Web

  4.1. Spring MVC를 위한 form fag 라이브러리

  2.0 에서는 많은 개발자들의 요구에 의해 대부분의 JSP tag 라이브러리와 사용이 가능하게 하여,
  개발자의 만족도를 높였다고 확신하고 있다. struts에 있어서도 form tag의 사용에 따른 추가적인 개발
  요소가 만만치 않았던 것을 고려할때
  이에 대한 추가에 따른 개발에 도움이 될지 어떨지는 좀 더 확인 필요할 듯 싶다.
  참조 : http://static.springframework.org/spring/docs/2.0.x/reference/mvc.html
  참조 : http://static.springframework.org/spring/docs/2.0.x/reference/spring-form.tld.html

  4.2. Sping MVC 내에 분별력 있는 표준설정

  convention-over-configuration 를 통해 models, views, 와 controllers 의 기본 영역에서 주소를
  제공하여, naming convention의 표준화를 통해 XML 설정에 따른 소스 량을 줄이고, 내용을 명확하고
  쉽게 처리할 수 있도록 한다.
  기존의 무분별한 프로젝트마다의 naming conventions 을 설정한다거나 개개인마다의 방식을 만들어
  가는 것에서 큰 도움이 될 듯하다.
  참조 : http://static.springframework.org/spring/docs/2.0.x/reference/mvc.html#mvc-coc

  4.3. Portlet framework  

  웹기반에 있어서의 Portlet (JSR-168 Portlet)을 지원한다.
  이는 특별한 설명이 필요 없을 듯 싶다.
  참조 : http://static.springframework.org/spring/docs/2.0.x/reference/portlet.html

5. 그밖에

  5.1. Dynamic language 지원

  자바 이외에도 현재 JRuby, Groovy 와 BeanShell 가 포함되어 지원된다.
  참조 : http://static.springframework.org/spring/docs/2.0.x/reference/dynamic-language.html

  5.2. JMX

  Spring에서 지원하던 JMS의 변경은 발전적이상의 획기적인 것으로 ...
  + Controlling the registration behavior : MBean 등록에 있어서 3가지을 제공한다.
      - REGISTRATION_FAIL_ON_EXISTING : MBean 인스턴스가 등록되어 있으면 InstanceAlreadyExistsException 을 통한 등록거부(디폴트),
      - REGISTRATION_IGNORE_EXISTING : MBean 인스턴스가 등록되어 있으면 아무런 에러없이 등록거부(멀티 어플리케이션 환경에 유용)
      - REGISTRATION_REPLACE_EXISTING : MBean 인스턴스가 등록되어 있으면, 이를 등록해지하고 새롭운 MBean으로 등록처리(기존MBean 대처시 유용)
  + Notifications : NotificationListeners을 통한 MBeans의 변경을 모니터링 가능하다.

참조 : http://static.springframework.org/spring/docs/2.0.x/reference/jmx.html#jmx-exporting-registration-behavior
참조 : http://static.springframework.org/spring/docs/2.0.x/reference/jmx.html#jmx-notifications

  5.3. Task scheduling (작업 스케쥴링)

  드럭 리가 심여를 기울여 Tiger에 포함시킨 java.util.concurrent.* 패치지에는 기존의 thread 의
  기능을 강화하고 확장시킨 Executors 라는 인터페이스가 있다. 이는 위의 내용에서 이야기 하다시피
    Java5 에서부터 구현이되어 사용이 가능하다.
  이에 2.0 에서는 Java 1.3, 1.4 에서도 Executors와 같은 기능(thread pools)을 가능케 하고자 이와
  동일한 기능의 (하지만 세부적인 구현을 더 추상화 시킨) TaskExecutor 를 제공한다.
  이에 대한 것은 아래를 참조하면 된다.
  (얼마전 리스너를 여러개 띄운 상태에서의 스케쥴링을 해야하는 프로그램을 작성한 적이 있었다.
     Spring에서 Quartz Scheduler를 사용하여, 처리하려 하였지만 데드락의 징후(!)가 보여 충분한 테스트
     도 채하기도 전에(기간이  촉박했던 것이였기에) thread 로 대처하여 어찌어찌 작성을 했었다.
     돌이켜 기억해보면 이때 이 기능을 사용했으면  여러가지 도움이 되었을텐데라는 생각이 든다.)  
  그 이외에도 scheduling 관련해서 문서상으로도 많은 보강이 있어 보인다. (특히 Pooling 관련)

  참조 : http://static.springframework.org/spring/docs/2.0.x/reference/scheduling.html#taskexecutor  

  5.4. Java 5 (Tiger) 지원
  제목과 같이 Java 5 (Tiger)을 지원하는 기능들이 추가 되었다.

  - Using AspectJ to dependency inject domain objects with Spring :
     http://static.springframework.org/spring/docs/2.0.x/reference/aop.html#aop-atconfigurable
    - @AspectJ support :
     http://static.springframework.org/spring/docs/2.0.x/reference/aop.html#aop-ataspectj
    - Using @Transactional with AspectJ :
     http://static.springframework.org/spring/docs/2.0.x/reference/transaction.html#transaction-declarative-aspectj
  - @Required :
     http://static.springframework.org/spring/docs/2.0.x/reference/metadata.html#metadata-annotations-required
  - SimpleJdbcTemplate :
     http://static.springframework.org/spring/docs/2.0.x/reference/jdbc.html#jdbc-SimpleJdbcTemplate

6. 샘플 업데이트
  전반적인 소스의 업데이트와 showcases 라는 폴더가 새롭게 생겼다.

7. 문서의 향상
  2.0 에 맞춰 새롭게 레퍼런스 문서가 작성되었다.  

Posted by 아름프로
OSGi가 나오고 알려진지도 5년여가 되어간다.
하지만, R1 ~ R4가 나오기까지... 시대의 흐름속에 스펙자체의 큰 변경으로 많은 혼선과
어려움이 있었던 시기가 아니였나 싶다. 특히나, 이러한 빠른 변화에도 불구하고 현 실세계는
아직 OSGi를 실용화 되기엔 다소 이른감과 준비가 덜 된것도 큰 요인이 되었던 것으로 보인다.

하지만, R4가 지난해 10월경에 발표되고 이에 대한 것들이 다시 정리되어가는 현 시점에서는
그 쓰임새와 내용에 대해 다시 관심을 가지고 지켜보야할 것으로 보인다.
(기술적으로나 시대적인 흐름이 어느정도 물이 오른(!) 상태이기에.. )

개인적으로는 OSGi가 eclipse의 핵심엔진으로 플러그인 기능을 담당하는 모습에서 단순히
가전기기나 홈네트워킹을 위한 개발표준의 이상의 현 모습에 주목을 하지 않을 수 없다.
(궁금하신 분은 eclipse의 equinox 프로젝트를 들여다 보라.. )
번들을 구성하는 방식은 spring에서의 DI와 비슷하게 보여지면서도 인터페이스를 강조하는
형태에서는 만족스러움과 아쉬움이 동시에 느껴지기도 하지만,
springframework 내에 올 여름이면 OSGi가 포함되리라 로드존슨이 이야기한 상태이므로
현재로써는 모든 것이 긍정적으로 받아들여질 뿐이다. ^^
(확인을 위해 cvs에서 sandbox를 확인해 보니, 이미 어느정도 구현이 되어져 있는 상태를 확인할
수 있었다. 스프링 팀이 기특한 따름이다. ^^)
그런데 두 단체간의 약간의 힘싸움은 있는듯 하기에 조심스러운 마음도 없잖아 있다.
서로 손내밀어 주기를 원하는 모습에서.. ㅡㅡ;;

일예로 R3에서 포함되었던 JINI가 작동상의 일부 문제가 발견되점도 있지만,
이를 해결하는 과정에서 JINI팀의 무관심과 SUN의 전략적인 것이 맞물려 R4에서 제외되었다는
것이.. 최종적으로 적용되기까지 마음이 찜찜할 것 같다.

어쨌든,
OSGi를 통해 우리 정부에서도 밀고 있는 u-IT839 정책을 실현하기 위한 소프트웨어적인
접근과 홈네트워크 시대의 장을 여는 중요 포인트로써 관심 있게 다루어야 할 것이고,
이에 대한 관심과 스터디가 많이 이루어졌으면 하는 바램을 가져본다.

OSGi가 무엇인지 여기에 설명을 하지 않는 것은...
좀 더 흥미꺼리를 던져주기 위함과 관심을 보이는 사람의 연락도 기다려보기 위함이다. ^^

J2 EE, SE, ME가 다시 하나의 이슈로 접목되어 실용화 될 날도 머지 않아보인다.
Posted by 아름프로

BLOG main image

카테고리

분류 전체보기 (539)
이야기방 (19)
토론/정보/사설 (16)
IBM Rational (9)
U-IT (0)
SOA/WS/ebXML (110)
개발방법론/모델링 (122)
J2SE (34)
J2EE (60)
DataBase (39)
Open Projects (30)
BP/표준화 (50)
Apache Projects (15)
Web/보안/OS (22)
Tools (7)
AJAX/WEB2.0 (1)
Linux/Unix (1)
영어 (0)
비공개방 (0)

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

달력

«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

글 보관함

Total :
Today : Yesterday :