'2007/11'에 해당되는 글 7건

2007/11/30 꿈......... 이였을까........ (20)
2007/11/26 2007.11.26.일... 나... 그리고.... (17)
2007/11/21 SW 개발자의 길, 아니다 싶으면 포기하라! (29)
2007/11/20 스프링(spring) 소개 (29)
2007/11/19 무공 극 체라 소서 육성법 (28)

꿈......... 이였을까........

every day/diary 2007/11/30 11:06

꿈... 이였겠지???

그렇지??

나 아직... 잠에서 안 깬거지??

.

.

.

.

사랑하지 않으니까..... 잡지 않는다고....

.

.

.

다.. 핑계 같다.... ... 그래.. 핑계......

.

.

마지막 까지.. 아프게 해서.. 미안해.... 미안해..... 미안하다....

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Writer profile

Posted by Mr.용

받은 트랙백이 없고, 댓글 20개가 달렸습니다.

2007.11.26.일... 나... 그리고....

every day/diary 2007/11/26 13:05

처음 시작했던 일과는 달리...(처음에는 웹프로그래머였죠..)

지금은 BPM 을 하고 있습니다.... 참.. 답답하네요...

뭐랄까... 현제 내가 원하지 않는 일을 하는 부분에 대한 내 기분과...

지금의 만족할 수 없는 연봉....

거기에.... 회사에 있는 개발자라고는 딸랑 저 한 명...

그리니.. 회사에서 그 동안 해온 온갖 잡다한 프로젝트(물론 잡다하지는 않겠지만..)

모두 유지보수를 하고... (실제 참여했던 프로젝트라면.. 알기라도 하죠;; ㅜㅜ )

프로그램을 하니까.. 어느정도 상식적으로 가진 지식으로..

고객 서버나 메일 서버,DNS에 문제가 생기면.. 해결해주어야하고.. (물론 저희 회사 서버도 관리합니다. ㅡㅡ )

매일 새벽 2시~3시 퇴근.. 아침 8시 출근;;

ㅎㅎ 삶이 삶 같지도 않고...

벌써 만 5년차가 다 되어가는데... 정말... 뭘 배운건지.. 뭘 하는건지.. 회의가 많이 드네요..

여자 친구는 제가 과중한 업무에 시달림에도.. 이해해주지 못하고..

후... 너무 힘드네요..

ㅎㅎ 웃음 뿐이 안나오네요.....

집 안에서도.. 어머니와 아버지가 주시는 스트레스.. 에휴.....

사면초과라는게 이럴때 딱 맞는 말인거 같습니다.....

이러지도 못하고.. 저러지도 못하고.. 스트레스에 눌려 죽겠네요...

몇 일전.. 너무 몸이 안좋아서 병원에 갔습니다.... 물론 회사는 제껴버렸죠 ㅡ_ ㅡ;;

병원에서 과중한 업무와 스트레스로 인해 면역력 저하 ㅡ_ ㅡ;;;

오호 통제라.. 건장한 28살 청년이 면역력 저하라니;;

결국에 입병에... 몸살에... 그냥 쓰러져서 전화기도 꺼놓고.. 병원에서 링겔 맞았습니다..

원래.. 29살에는 고민이 많다고 하더군요...

저보다 더 힘들게 일하시는 분들도 계시겠지만.....

정말.. 쉬고 싶네요... 요즘엔....

그냥 지나가는 넋두리였습니다.... 너무 답답해서... ^^

조금만.. 제 자신을 돌아볼 틈이 있었습니다. 좋겠습니다.......

(점심시간인데.. 소주가 땡기네요 ㅎㅎㅎㅎ)

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Writer profile

Posted by Mr.용

받은 트랙백이 없고, 댓글 17개가 달렸습니다.

SW 개발자의 길, 아니다 싶으면 포기하라!

training 2007/11/21 13:00

발췌 : http://www.zdnet.co.kr/news/enterprise/ ··· 2C00.htm

SW 개발자의 길, 아니다 싶으면 포기하라!

김효정 기자 ( ZDNet Korea ) 2007/11/20

Microsoft

20일 오전에 MS가 주관하는 ‘2007 데브데이’ 행사에 참석했다. IT업계에 종사하는 사람이라면, 아마도 한번쯤은 MS의 독점성과 라이선스 정책 등에 대해 불만을 품어봤을 만하다. 그럼에도 불구하고 SW 개발자들의, MS에 대한, 관심은 어느 행사보다 뜨거움을 느낄 수 있었다.

기자는 오전 행사 중 한국MS의 최고기술임원인 김명호 박사(혹은 이사, 왠지 모르지만 박사라는 호칭이 더 어울린다)의 기조연설만 듣고 나서 김박사와의 짧은 인터뷰를 진행할 수 있었다. 그는 기조연설과 인터뷰를 통해 ‘한국에서 SW 개발자가 가야 할 길’에 대해 <희망차고도 암울한> 사회적 딜레마를 이야기해 주었다.

아래의 글은 김명호 박사를 통해 들을 이야기를 바탕으로 작성해 보았다.

[明, SW 개발자여 전문인으로 거듭나자!]
ZDNet Korea의 컬럼니스트 중 한명인 류한석 소장은 얼마 전 자신의 컬럼에 ‘한국에서 SW 개발자가 성공하지 못하는 세가지 이유’를 통해 어려운 사회적 현실을 이야기 했다. 그러한 이유가 아니더라도, SW 개발자로 성공한다는 것 자체는 다른 어떠한 직업과 견주어도 결코 쉬운 것만은 아닐 것이다.

한국 자바 개발자의 1세대라 할 수 있는 김명호 박사 역시 개발자 출신으로 성공의 길을 걷고 있다고 할 수 있지만 “이 길이 아니다 싶으면 차라리 다른 일을 하라”는 말을 서슴지 않고 내던지고 있다. 요즘 시대에 개발자는 한국이라는 좁은 시장에서가 아니라 전세계적으로 통할 수 있는 전문성을 가져야 하는데, 이를 달성하는 것은 결코 쉬운 일이 아니기 때문이다.

SW 개발자로 성공하려면, 단기간 학원 교육을 통해, 누구나 습득할 수 있는 주류 기술 몇 가지만 배워서는 안 된다. 코딩, 테스트, 디버깅, 이식, 성능, 설계, 스타일 등 다양한 소양을 갖춘 전문인이 진정한 개발자라고 할 수 있다. 단순히 코딩만을 할 줄 안다고 해서 전문인으로써의 ‘정신과 혼’을 담지 않고 있다면 ‘하급 노동자’에 지나지 않는다는 것이다.

개발자와 아키텍트는 다르다
한국의 개발자들은 마치 개발자가 아키텍트로 가는 중간 단계로, 한번쯤 거쳐야 할 과정쯤으로 여기는 경향이 있다. 그러나 아키텍트와 개발자는 엄연히 다른 직업이다. 아키텍트가 되기 위해 개발자 경험이 있는 것은 좋지만, 막연하게 개발자를 거쳐 아키텍트가 된다고 생각하는 것은 옳지 않다는 것이 김박사의 설명이다.

그는 “아키텍트가 될 자질을 갖추는 것은 개인의 소양에 따라 다르다. 이를 건설에 비유하자면, 개발자는 건설현장에서 일하는 인부고 아키텍트는 건축설계사라고 볼 수 있다. 미적, 공학적인 요소를 갖추었을 때 건축설계사가 되는 것처럼, 현장 인부가 자신의 경력을 통해서만 될 수는 없는 것이다”라며 “대신 그들은 미장이나 도색 전문가 혹은 작업반장이 될 수 있다. 즉, 해달 분야의 전문가로 훌륭히 성공할 수 있는 것이다”라고 말했다.

그렇다고 벽돌을 나르는 수준의 초급 개발자가 10년 후 작업반장 수준의 상급 개발자가 되는 것은 아니다. 먹고 살기 위해서 개발을 한다면 행복해 질 수 없을 테고, 당연히 훌륭한 개발자가 될 수도 없다. 때문에 개발자들이 당면한 과제는 어떻게 하면 훌륭한 개발자가 될 수 있냐는 올바른 방법론이 필요하다.

이에 대해 김명호 박사는 몇 가지 지침을 가르쳐 준다.

훌륭한 개발자가 되려면?
1) 기본에 충실해야 한다.
여기서 말하는 기본과 초급은 분명 다르다. 개발자라면 알고 있어야 할 프로그래밍의 기본 구조나 알고리즘 등의 기본에 충실하지 못하다면, 10년이 지나도 불행하기는 마찬가지일 것이다. 만약 개발자인 당신이 먹고 살기에 급급해서 수박 겉핥기로 몇몇 기술만 습득했다면 지금이라도 당장 시작하는 것이 중요하다. ‘언젠가는 적용해야 할 핵심기술’을 습득하는 것이 중요하다.

2) 지식의 포트폴리오를 유지하라.
재테크에서의 교훈에 따라 ‘달걀을 한 바구니에 담지 마라’는 것을 생각하자. 즉, 개발자는 어느 한 분야에 올인하지 말고 ‘남들도 다 아는’ 주류 기술과 ‘남들은 모르는’ 전문 기술로 분산 투자해야 한다는 것이다.

3) 분야 전문가나 해박한 지식을 갖춰라.
앞서 언급한 대로 건설현장에서 미장이나 도색 전문가, 작업반장이 될 수 있는 분야별 전문가가 된다면 어디서든 존중 받을 수 있다. 그러나 여기서 중요한 것은 과도한 욕심을 부려서는 안 된다는 것이다. 분야의 전문가인 동시에 해박한 지식을 갖추고 있다면 그야말로 ‘천재’라고 할 수 있지만, 이 둘 중 한가지만 갖춰도 충분하다는 것이다. 모든 분야에 대해 피상적인 지식만을 갖추고 있다거나, 사장된 기술에 매달린다거나, 자아도취에 빠져 자신만의 방법이 옳다고 여기는 오류를 범할 수 있기 때문이다.

4) 학습을 두려워 마라.
이것이 김박사가 가장 강조하는 부분으로, 충분한 기본지식을 갖추고 있다면 새로운 지식을 습득하는 것에 두려움이 없으며 새로운 기술을 습득하고 끊임없이 발전해 나가는 것이야 말로 행복한 개발자가 되는 최우선 요소다. 만약 새로운 기술을 습득하는데 더디다고 느낀다면 그것은 기본이 부족하기 때문이며, 지금이라도 기본을 습득해 나간다면 신기술 습득에 대한 두려움은 사라진다.

이러한 개발자를 위한 성공 방법론이 제시됐음에도 불구하고, 개발자가 선택할 수 있는 최악의 길은 ‘다른 길을 찾아가는 것’이다. 개발자가 뭐 그리 대단한 것인가? SW 개발자가 아니더라도 얼마든지 다른 분야에서 전문인이 될 수는 있는 것이다. 자신이 택했지만 SW 개발자로의 미래가 안 보인다고 생각된다면, 과감히 다른 길을 선택하라.

개발자야 말로 ‘파레토의 80대 20의 법칙’이 가장 확실하게 적용되는 분야다. 20%의 능력 있는 개발자만이 훌륭하게 80%의 개발을 수행할 수 있다.

[暗, 과연 한국에서 SW 개발자가 성공할 수 있나?>
김명호 박사는 SW산업에서 이러한 파레토의 법칙이 중요하다고 말한다. 뛰어난 소수의 전문인력이 SW산업을 발전시킬 수 있고, 이러한 인재를 정책적인 지원 하에 키워내야 한다는 것이다.

그러나 현실은 그다지 밝지 않아 보인다. 정부의 정책이라는 것이 ‘노동정책’에 가깝기 때문이다. 즉, 대학과 같은 전문교육기관에 의한 전문가를 양성한다기 보다 실업자를 줄이기 위해 하급 개발자를 배출해 내는데 급급하고 있다는 지적이다.

막상 현재 대학의 교육 현실은 어떠한가? 학부제를 도입한 이후, 학생들은 어려운 과목은 제외하고 쉽거나 학점을 잘 받을 수 있는 과목을 수강할 수 있게 된 상태다. 숙명여대 전산관련 학과의 한 교수는 “요즘 학생들은 알고리즘과 같이 기본을 다질 수 있는 과목은 어렵다고 회피한다. 그저 취업을 위한 학점 챙기기나 가벼운 프로그래밍 기술에 몰린다”고 안타까워한다.

이럴 바에는, 오히려 비전공자가 낫다는 의견도 있다. 기본에 충실하지 않은 전공자들보다 학원에서 5~6개월 집중적으로 배우고, 취직해서 급여를 받는 이들이 더욱 충실도가 높고 급여도 적게 든다는 것에 SI업체들이 매력을 느낄 수도 있다는 것이다.

실패 거듭하는 ‘SW 정책’
실제 이렇게 부실한(기본에 충실하지 못하다는 의미로, 이들이 모두 부실하다는 것은 아니다) 개발자들을 고용한 SI업체를 통해 프로젝트가 실패한 경우, 그 책임소재의 표적은 SI가 아닌 HW로 돌리는 경향이 있기도 하다. 어떻게 보면 이것이 ‘SW 분리발주 정책’을 창출한 계기 중 하나이며, 개발자의 ‘표준공임단가’를 책정하게 된 이유가 될 것이다.

특히 개발자에 대해 표준공임단가를 두어 금전적 보상에 제한을 두어서는 안 된다. 이는 능력 있는 전문가가 되고자 하는 이들의 의지를 꺾을 수 있기 때문이다. 핀란드의 한 대학에서 내놓은 조사자료에 의하면 ‘SW 개발생산성에 있어 훌륭한 개발자 1명의 개발생산성이 하급 개발자에 비해 20배 가량 높다’는 결과가 있다. 이는 급여 측면에서 볼 때에도 그 이상의 가치가 있는 것이다.

현재 정부의 실업정책에 가까운 SW 정책은 이러한 측면에서 많이 부족하다는 지적이다. 즉, 표준공임단가에 묶여 있기 때문에 국내에서는 아무리 뛰어나다고 해도 인정받지 못하는 토양이 굳어져 가고 있으며, 이는 마찬가지로 기업 내부에서도 개발자에게 인색할 수 밖에 없다.

또한 전문인을 양성하기 위해 수년의 기간이 필요하지만, 단기간 성과를 내야만 하는 국내의 프로젝트 특성도 개발자를 힘들게 하는 악순환에 한 몫 거들고 있다.

소수의 전문인 중심 체계 필요
김명호 박사는 “정책적으로 획기적인 변화가 있어야 한다. 노동집약적 산업이 아닌 지식집약적 산업으로 바꾸기 위한 정책이 필요하다. 물론 교육도 마찬가지다. 전산 관련 대학 정원을 줄여서 의욕이 있는 전문가를 양성해 내고 이들을 대상으로 SW정책을 만들어 가야 할 것이다”라고 말했다.

그는 또 “16만 명에 달하는 국내 개발자들 모두에게는 미안한 말이지만, 누구나 다 성공할 수는 없다. 끊임없이 노력할 수 있고 자기를 발전시킬 수 있는 소수 개발자들만이 성공할 수 있으며, SW 정책도 이들에게 마음 놓고 일할 수 있는 환경을 만들어 주는 산업으로 만들어야 정부차원의 ‘미래의 먹거리’ 산업으로 성장할 수 있을 것이다”라고 주장했다. @

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Writer profile

Posted by Mr.용

받은 트랙백이 없고, 댓글 29개가 달렸습니다.

스프링(spring) 소개

training/study 2007/11/20 09:58

발췌 : http://www-128.ibm.com/developerworks/k ··· ring1%2F

The Spring series, Part 1: Spring 프레임웍 소개

Spring AOP와 IOC 컨테이너

문서 옵션

JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다.

		이 페이지를 이메일로 보내기
		샘플 코드

제안 및 의견

피드백

난이도 : 초급

Naveen Balani, Technical Architect, Webify Solutions

2005 년 6 월 21 일

Spring 기술을 사용하여 강력한 J2EE 애플리케이션을 구현한다. Naveen Balani가 Spring 시리즈를 통해서 Spring 프레임웍을 소개한다. 아울러 Spring의 aspect 지향 프로그래밍(AOP)과 Inversion of Control(IOC) 컨테이너도 소개한다.

Spring은 오픈 소스 프레임웍으로서 기업 애플리케이션 개발의 복잡성 문제를 다루기 위해 만들어졌다. Spring 프레임웍의 가장 큰 장점 중 하나는 레이어 아키텍쳐라는 점이다. J2EE 애플리케이션 개발에 일관된 프레임웍을 제공함과 동시에 원하는 컴포넌트만 선택적으로 사용할 수 있다는 이점이 있다.

이 글에서는 Spring 프레임웍을 소개하고자 한다. 먼저 기반 모듈의 관점에서 프레임웍의 기능을 설명하고, 가장 관심을 끄는 두 가지 모듈인 Spring aspect 지향 프로그래밍(AOP)과 Inversion of Control(IOC) 컨테이너를 설명하겠다. 전형적인 애플리케이션에서 IOC 컨테이너가 어떻게 작동하는지도 예제를 통해 설명한다.

예제 애플리케이션을 위해 다운로드 섹션에서 Spring 프레임웍과 Apache Ant를 다운로드 하라.

Spring 프레임웍

Spring 프레임웍은 일곱 개의 명확한 모듈로 구성된 레이어 아키텍쳐이다. Spring 모듈은 코어 컨테이너의 상단에 구현된다. 여기에서 빈(bean)의 구현, 설정, 관리 방법이 정의된다. (그림 1)

그림 1. Spring 프레임웍의 모듈
A diagram of the Spring framework

Spring 프레임웍을 구성하는 각 모듈(또는 컴포넌트)은 독립적이거나, 다른 모듈들과 함께 구현된다. 각 컴포넌트의 기능은 다음과 같다.

코어 컨테이너(core container): Spring 프레임웍의 핵심 기능을 제공한다. 코어 컨테이너의 주요 컴포넌트는 BeanFactory(Factory 패턴의 구현)이다. BeanFactory는 Inversion of Control (IOC) 패턴을 사용하여 애플리케이션의 설정 및 의존성 스팩을 실제 애플리케이션 코드에서 분리시킨다.
Spring 컨텍스트(Spring context): Spring 프레임웍에 컨텍스트 정보를 제공하는 설정 파일이다. Spring 컨텍스트에는 JNDI, EJB, 국제화, 밸리데이션, 스케줄링 같은 엔터프라이즈 서비스들이 포함된다.
Spring AOP 모듈(Spring AOP): 설정 관리 기능을 통해 aspect 지향 프로그래밍 기능을 Spring 프레임웍과 직접 통합시킨다. 따라서 Spring 프레임웍에서 관리되는 모든 객체에서 AOP가 가능하다. Spring AOP 모듈은 Spring 기반 애플리케이션에서 객체에 트랜잭션 관리 서비스를 제공한다. Spring AOP에서는 EJB 컴포넌트에 의존하지 않고도 선언적 트랜잭션 관리를 애플리케이션과 결합할 수 있다.
Spring DAO: Spring JDBC DAO 추상 레이어는 다른 데이터베이스 벤더들의 예외 핸들링과 오류 메시지를 관리하는 중요한 예외 계층을 제공한다. 이 예외 계층은 오류 핸들링을 간소화하고, 예외 코드의 양도 줄여준다. Spring DAO의 JDBC 예외는 일반 DAO 예외 계층에 순응한다.
Spring ORM: 프레임웍은 여러 ORM 프레임웍에 플러그인 되어, Object Relational 툴 (JDO, Hibernate, iBatis SQL Map)을 제공한다. 이 모든 것은 Spring의 일반 트랜잭션과 DAO 예외 계층에 순응한다.
Spring Web module: 웹 컨텍스트 모듈은 애플리케이션 컨텍스트 모듈의 상단에 구현되어, 웹 기반 애플리케이션에 컨텍스트를 제공한다. Spring 프레임웍은 Jakarta Struts와의 통합을 지원한다. 웹 모듈은 다중 요청을 핸들링하고, 요청 매개변수를 도메인 객체로 바인딩하는 작업을 수월하게 한다.
Spring MVC framework: MVC 프레임웍은 완전한 기능을 갖춘 MVC 구현이다. MVC 프레임웍은 전략 인터페이스를 통해 설정할 수 있으며, JSP, Velocity, Tiles, iText, POI 같은 다양한 뷰 기술을 허용한다.

Spring 프레임웍 기능은 J2EE 서버에 사용될 수 있으며, 대부분 다른 환경에서도 받아들여진다. Spring의 초점은 특정 J2EE 서비스로 묶이지 않은 재사용 가능한 비즈니스 및 데이터-액세스 객체들을 허용하는 것이다. 이 같은 객체들은 J2EE 환경(웹 또는 EJB), 스탠드얼론 애플리케이션, 테스트 환경을 통해 재사용 될 수 있다.

위로

IOC와 AOP

제어 역행(Inversion of Control) 패턴의 기본 개념은 객체를 구현하지 않고 구현되는 방법을 기술하는 것이다. 컴포넌트와 서비스들을 코드에 직접 연결하지는 않지만, 설정 파일에서 어떤 컴포넌트가 어떤 서비스를 요구하는지를 기술한다. 컨테이너(이 경우, Spring 프레임웍, IOC 컨테이너)는 이 모든 것을 연결한다.

전형적인 IOC 시나리오에서, 컨테이너는 모든 객체들을 만들고 필요한 속성들을 설정하여, 이들을 한데 연결하고 메소드가 언제 호출될 것인지를 결정한다. IOC의 이 세 가지 구현 패턴을 아래 테이블에 정리했다.

Type 1	서비스는 정용 인터페이스를 구현해야 한다. 이 인터페이스를 통해 종속관계에 있는 객체들이 제공된다.
Type 2	JavaBeans 속성(세터 메소드)를 통해 종속 관계가 할당된다.
Type 3	종속 관계가 생성자 매개변수로서 제공되고 JavaBeans 속성으로서는 노출되지 않는다.

Spring 프레임웍은 IOC 컨테이너 구현에 Type 2와 Type 3 구현을 사용한다.

Aspect-지향 프로그래밍

Aspect-oriented programming(AOP)은 프로그래머들이 크로스커팅 문제를 모듈화 할 때, 사용하는 프로그래밍 기술이거나 로깅과 트랜잭션 관리 같은 전형적인 책임들을 분할하는 작동이다. AOP의 핵심 생성자는 aspect이다. 이것은 다중 클래스에 영향을 미치는 작동들을 재사용 가능한 모듈로 캡슐화 한다.

AOP와 IOC는 기업 애플리케이션 환경의 복잡한 문제에 모듈식의 접근 방식을 취한다는 점에서 상호 보완적인 기술이라고 할 수 있다. 전형적인 객체 지향 개발 방식에서는 메소드와 자바 클래스에 로거(logger) 문장을 배치하여 로깅 기능을 구현한다. AOP 방식에서는 로깅 서비스를 모듈화 하고, 이를 로깅을 필요로 하는 컴포넌트에 적용한다. 장점은 자바 클래스가 로깅 서비스의 존재를 인식할 필요가 없고, 관련 코드에만 집중한다는 점이다. 결과적으로 Spring AOP를 사용하여 작성된 애플리케이션 코드는 약결합이다.

AOP 기능은 트랜잭션 관리, 로깅, 기타 다양한 기능들을 위해 Spring 컨텍스트로 통합된다.

위로

IOC 컨테이너

Spring 디자인의 핵심은 org.springframework.beans 패키지이다. JavaBean 컴포넌트와 함께 사용할 수 있도록 설계되었다. 이 패키지는 사용자가 직접 사용하지는 않는다. 다만 다른 기능에 대한 기반 미디어로 작동한다. 그 다음으로 중요한 추상화 레이어는 BeanFactory 인터페이스이다. 이것은 객체들이 이름별로 생성 및 검색되도록 Factory 디자인 패턴의 구현이다. BeanFactory는 객체들 간 관계도 관리한다.

BeanFactory는 다음 두 개의 객체 모드를 지원한다.

Singleton 모드는 객체의 공유 인스턴스에 특별한 이름을 부여한다. 이는 룩업(lookup) 시 검색된다. Singleton은 디폴트이고, 가장 빈번히 사용되는 객체 모드이다. 스테이트리스(stateless) 서비스 객체에 이상적이다.
Prototype 모드는 각각의 검색 결과가 독립적인 객체의 구현이 되도록 한다. Prototype 모드는 사용자가 자신의 객체를 가져야 하는 곳에 사용된다.

빈 팩토리 개념은 IOC 컨테이너로서의 Spring의 토대이다. IOC는 그 책임을 이 프레임웍으로 이동시키고, 애플리케이션 코드로부터 멀어진다. 다음 예제에서 보여주겠지만, Spring 프레임웍은 JavaBean 속성과 설정 데이터를 사용하여 어떤 종속 관계들이 설정되었는지를 분석한다.

BeanFactory 인터페이스

org.springframework.beans.factory.BeanFactory는 간단한 인터페이스이기 때문에 광범위한 기반 스토리지 메소드를 위해서도 구현될 수 있다. 가장 일반적으로 사용되는 BeanFactory 정의는 XmlBeanFactory이다. 이것은 XML 파일의 정의를 기반으로 빈을 로딩한다. (Listing 1)

Listing 1. XmlBeanFactory

BeanFactory factory = new XMLBeanFactory(new FileInputSteam("mybean.xml"));

XML 파일에서 정의된 빈들은 느리게 로딩된다. 다시 말해서, 빈이 요청되기 전 까지는 인스턴스화 되지 않는다. BeanFactory에서 빈을 검색하려면 getBean()메소드를 호출한다. (Listing 2)

Listing 2. getBean()

MyBean mybean = (MyBean) factory.getBean("mybean");

빈의 정의는 POJO(클래스 이름과 JavaBean 초기화 속성에 의해 정의된다.) 또는 FactoryBean이 될 수 있다. FactoryBean 인터페이스는 인다이렉션 레벨을 Spring 프레임웍을 사용하여 구현된 애플리케이션에 추가한다.

위로

IOC 예제

제어 역행(inversion of control)을 이해할 수 있는 가장 쉬운 방법은 작동법을 이해하는 것이다. Spring IOC 컨테이너를 통해 애플리케이션 종속 관계들을 투입하는 방법을 설명하면서 이 글을 마치도록 하겠다.

온라인 신용 카드 계정을 개설하는 사용 케이스 예제를 설명하겠다. 신용 카드 계정을 개설하기 위해 사용자는 다음 서비스들과 인터랙팅 해야 한다.

사용자 신용 내역 정보를 쿼리하는 신용 등급 서비스
신용 카드와 은행 정보를 통해 고객의 정보를 기입 및 연결하는 원격 신용 연결 서비스
신용 카드의 상태를 사용자에게 이메일로 전송하는 이메일 서비스

위로

세 가지 인터페이스

이 서비스는 이미 존재하고 이들을 약결합 방식으로 통합한다고 가정한다. 아래 리스팅은 이 세 가지 서비스에 대한 애플리케이션 인터페이스이다.

Listing 3. CreditRatingInterface

public interface CreditRatingInterface {

   public boolean getUserCreditHistoryInformation(ICustomer iCustomer);

}

Listing 3의 신용 등급 인터페이스는 신용 내역 정보를 제공한다. 사용자 정보를 포함하고 있는 Customer 객체가 필요하다. 구현은 CreditRating 클래스에서 제공한다.

Listing 4. CreditLinkingInterface

public interface CreditLinkingInterface {

public String getUrl();

		public void setUrl(String url);

		public void linkCreditBankAccount() throws Exception ;

}

신용 연결 인터페이스는 신용 내역 정보를 은행 정보와 연결하고 신용 카드 정보를 기입한다. 신용 연결 인터페이스는 getUrl() 메소드를 통해 검색되는 원격 서비스이다. URL은 Spring 프레임웍의 빈 설정 메커니즘을 통해 설정된다. 구현은 CreditLinking 클래스에서 제공한다.

Listing 5. EmailInterface

public interface EmailInterface {

      public void sendEmail(ICustomer iCustomer);

      public String getFromEmail();

      public void setFromEmail(String fromEmail) ;

      public String getPassword();

      public void setPassword(String password) ;

      public String getSmtpHost() ;

      public void setSmtpHost(String smtpHost);

      public String getUserId() ;

      public void setUserId(String userId);
   }

EmailInterface는 사용자에게 신용 카드의 상태를 이메일로 알려준다. SMPT 호스트, 사용자, 패스워드 같은 메일 설정 매개변수들은 앞서 언급한 빈 설정 메커니즘을 통해 설정된다. Email 클래스가 구현을 제공한다.

위로

Spring

이 모든 인터페이스를 갖춘 후에 할 일은 이들을 약결합 방식으로 통합하는 것이다. Listing 6에서 신용 카드 계정의 사용 케이스 구현을 볼 수 있다.

모든 세터 메소드들은 Spring 설정 빈들을 통해 구현된다. 모든 종속 관계들(세 가지 인터페이스)은 이러한 빈들을 사용하여 Spring 프레임웍에 의해 투입될 수 있다. createCreditCardAccount() 메소드는 이 서비스를 사용하여 구현의 나머지 부분을 수행한다. Listing 7은 Spring 설정 파일이다. 강조할 부분은 화살표를 사용했다.

위로

애플리케이션 실행

예제 애플리케이션을 실행하려면 Spring 프레임웍과 모든 종속 관계 파일들을 다운로드 해야 한다. 그런 다음, 이 프레임웍을 c:\에서 압축을 풀면 C:\spring-framework-1.2-rc2 폴더가 만들어진다. Apache Ant도 다운로드 해야 한다.

소스 코드를 c:\ 에 압축을 풀면 SpringProject 폴더가 만들어진다. 이 Spring 라이브러리를 복사한다. C:\spring-framework-1.2-rc2\dist에서 spring.jar와 C:\spring-framework-1.2-rc2\lib\jakarta-commons의 commons-logging.jar를 SpringProject\lib 폴더에 복사한다. 그 다음에는 필요한 구현 종속 관계를 설정한다.

명령어 프롬프트를 열고 디렉토리를 SpringProject로 변경하고, 다음 명령어(build)를 명령어 프롬프트에 입력한다.

이것은 CreateCreditAccountClient 클래스를 구현하여 실행한다. 이 클래스는 Customer 클래스 객체를 만들고 이를 파퓰레이트 하여 CreateCreditCardAccount 클래스를 호출하여 신용 카드 계정을 만들어서 연결한다. CreateCreditAccountClient는 ClassPathXmlApplicationContext를 통해 Spring 설정 파일도 로딩한다. 일단 빈이 로딩되면 getBean() 메소드를 통해 액세스 할 수 있다.

Listing 8. Spring 설정 파일 로딩

ClassPathXmlApplicationContext appContext = 
                    new ClassPathXmlApplicationContext(new String[] {
     "springexample-creditaccount.xml"
    });

CreateCreditCardAccountInterface creditCardAccount = 
                    (CreateCreditCardAccountInterface)
	appContext.getBean("createCreditCard");