Spring Framework 도 해보자 1

주말에 Struts 1도 아니구 2를 공부 했다가.. 근데.. 이걸 요즘 실무에서 많이 사용하나 싶어서 여기저기 검색을 해봤는데.. Spring 쪽으로 많이들 사용하는 것 같다.
에궁.. 그리하여.. 내일부터는 Spring에 대한 강좌부터 공부를 해야 겠다..
과연 무엇이 도움이 될지,… 지속적인 삽질의 연속이지만..  좋다! 해보자..

http://blog.daum.net/openeidos/8879784

Spring Framework의 기본 개념
[출처] Spring Framework의 기본 개념 (돌 프로그래밍 카페) |작성자 골목대장

 

1.    왜? 프레임 워크 인가?

엔터프라이즈 환경의 프로젝트에서 각 프레임워크가 도입되는 이유는 무엇인가?
 가장 큰 이유는 개발 현장의 개발생산성의 향상과 고품질이 보장된 어플리케이션의 개발을 위해서다.
 다양한 요구 사항을 만족할 수 있는 유연하고 풍부한 기능을 제공하는 프레임워크 구축, 개발 생산성 향상과 고품질의 시스템 개발을 위한 프레임워크의 필요성이 대두되면서, Struts, Spring, WebWork 와 같은 프레임워크 가 등장하기 시작하였다.

2.    왜 Spring 인가?.

J2EE 기반에서 가장 두각을 나타내는 프레임워크는 Spring 인데, 이는 각 레이어를 느슨한 Interface의 결합과 설정의 외부화를 통해 개발이 보다 유연하고 견고해지는 부분도 있지만, 일관된 방법으로 기존 기술들을 편하게 사용할 수 있도록 해주고, 비즈니스 객체들을 효과적으로 구성하고 관리하는데 가장 큰 장점이 있기 때문이다.
더불어 막강한 JDBC 자원 관리가 개발자들에게 혁신적인 소스 코딩량의 절약을 가능케 해준다는 것이 장점 중하나로 보고 있다.

왜 LightWeight 라고 하는가?
Spring 은 하나의 프레임워크 이다. 그런데 왜 Spring 컨테이너, IoC 컨테이너 라는 말을 사용할까?
그렇다면 컨테이너란 무엇인가? Servlet 컨테이너, EJB 컨테이너 라는 말을 종종 들어봤다면, 정확한 사전적인 정의도 찾아봤겠지만, “인스턴스의 생명주기를 관리하며, 생성된 인스턴스들에게 추가적인 기능들을 제공” 하는 역할을 하는 것이 바로 컨테이너 라고 보면 된다.

Servlet 컨테이너는 Servlet의 생성, 생성 후 초기화, 서비스의 실행, 소멸에 관한 모든 권한을 가지고 있다.
개발자들이 직접 Servlet을 생성하고 서비스 하지 않는다.
이처럼 컨테이너는 Servlet 인스턴스에 대한 생명 주기를 관리하는 기능을 가진다.
또한 Servlet 컨테이너의 web.xml 을 보면 JSP/Servelt 접근 권한에 대한 추가적인 서비스도 지원하고 있다.
이는 Servlet 의 구현과는 별도로 각 JSP/Servlet 에 대한 Security 를 관리 해주는 기능을 한다.

3.    Spring Architechture

기본적으로 스프링 아키텍쳐는 모듈단위의 계층구조로 되어 있고 각 모듈들은 독립적으로 분리, 사용이 가능하다.
뿐만 아니라 각각의 모듈은 일관된 방법으로 사용할 수 있기 때문에 한번 익숙해 지고 나면 사용이 무척 쉽다.
더불어 각 레이어의 다양한 프레임워크와 조합이 가능하고 , 다양한 개발 환경에 최적의 조합을 유도할 수 있다.

IoC 라는 스프링의 특징 때문에 스프링은 전체 프로젝트의 설정을 관리할 수 있는 일관된 방법을 제공함으로써, 개발자들이 각종 프로퍼티 파일을 작성하지 않도록 유도한다. 객체들간의 의존성이 따로 관리됨으로써 비즈니스 로직이 EJB로 개발되었건 일반 자바 객체로 개발되었건 동일한 방법으로 해당 로직을 이용할 수 있는 이점이 추가된다.

* IoC(Inversion of Control : 제어의 역행)
* DI(Dependency Injection : 의존성 주입)
* AOP (Aspect-oriented Programming : 관점 지향 프로그래밍)

Spring을 하기 앞서 위 3가지의 개념을 집중적으로 이해할 필요가 있다.



http://himanshugpt.wordpress.com/2010/07/05/262/ 

 - Core : 스프링의 핵심으로 기능과 그 설정을 분리하기 위한 IoC 기능이 구현된 BeanFactory를 제공한다.
  // Supporting utilities Bean container
 - Context : Core 패키지와 마찬가지로 스프링의 기본 기능이다. 이것은 JNDI 가 EJB를 비롯한 리소스에 접근 경로를 제공하는 것처럼 스프링 기반에서 구현된 기능 객체(Bean)들에 대한 접근 방법을 제공한다.
 //Application context, UI support, Validation , JNDL EJB support and remodeling, Mail
 - DAO : DAO 패키지는 JDBC 에 대한 추상화 계층으로 지루한 JDBC 코딩이나 예외처리를 없애준다. 또한 트랜잭션 관리 기능도 제공된다.
   // Source-level metadata AOP infrastructure.
 - ORM : 객체/관계 매핑을 위한 JDO , Hibernate , iBatis 등과의 통합을 위한 패키지이다.ORM 제품들을 스프링의 기능과 조합해서 사용할 수 있게 한다.
   // Hibernate ,iBatis, JDO support
 - AOP  : AOP 얼라이언스 와 호환되는 AOP 구현 패키지 이다.
  // Transaction infrastructure , JOBC,DAO support
 - WEB : 일반적인 웹 어플리케이션 개발에 필요한 기본 기능을 제공하고 , WebWork 나 Struts 와의 통합을 위해 사용되는 패키지 이다.
  // WebApplicatonContext, Mutipart resolver, Web utilities
 - WebMVC : Struts와 같은 일반적인 WAF 의 기능을 스프링 버전으로 구현하고 있는 패키지 이다. 기존에 사용하고 있던 WAF 가 없다면 사용을 고려해 볼 만 하다.
  //Web MVC, Framework, Web Views, JSP/Velocity / PDF/Export

 * JNDI (Java Naming and Directory Interface)
  - 서비스가 다른 서비스를 탐색할 때 유용하게 사용.
  - 분산된 자원 끼리의 탐색을 원활하게 하기 위한 type casting 임(DNS 도 이에 속함)
  - J2EE 환경에서 사용되는 핵심 기술로, 필요한 자원을 key/value의 쌍으로 저장 후 나중에 key를 이용하여 value를 얻는 명세이다. 대표적인 구현 물로는 DNS 서버 이다.
  - 이것 저것 정보를 찾아봤는데, Spring를 기준으로 하자면, Naming 서비스를 사용하는 방식은
   (1) Spring XML Configuration 파일에 설정하는 방식
      JNDI 객체를 bean으로 등록하는 방식으로, JNDI 객체를 Lookup 만 할 수 있고 , 일반적으로 많이사용
   (2) JNDI API를 wrapping 한 jndiTemplate class를 사용하는 방식
      JNDI API를 쉽게 사용할수 있는 JndiTemplate class를 직접 사용, JNDI API를 모두 사용하고 싶을떄..
보다 자세한 설명 : http://www.egovframe.org/wiki/doku.php?id=egovframework:rte2:itl:naming_service

4.    Advantage of Spring Framework

 - 다양한 형태의 Transaction 을 선언적으로 사용
 - 개발자는 필요한 Transaction에 대한 메소드명만으로 Transaction 구현에서 해방 Remote EJB 사용의 간편성
 - 설정 파일에서 Remote EJB가 필요한 객체에 매핑하는 것으로 Local Object 사용하듯이 사용 다양한 Framework과의 통합.
 - 많이 사용되고 있는 웹 프레임워크와 ORM 프레임워크에 대한 탁월한 지원.
 - AOP를 보다 쉽게 적용.
 - Business Logic 외에 logging, exception 처리등을 선언적으로 사용 할 수 있는 기반 제공
 - Transaction을 선언적으로 사용하는 이유도 AOP의 강력한 지원으로 가능.
 - Convention over configuration 의 결합으로 설정의 최소화
 - Spring Framework 의 불편함으로 지적되던 XML 설정을 Convention over Configuration 도입으로 최소화.
 - Unit Test 지원 – 견고한 코드 관리를 위한 Unit Test Case 의 작성 지원.
 - 설정 관리의 단일화 – Application 설정 관련 부분을 Spring Framework 으로 단일화 해서 관리.
 - Object Pool을 기본적으로 가지고 있어서 Object 생성 제거의 Overhead 최소화
   à 기본적으로 Singleton 형태로 Object가 사용됨.
   à 호출시 매번 생성되는 형태도 가능.
 - 분산 시스템 구성시 비용 최소화
   à RMI 지원, Caucho’s Hessian and Burlap 지원, Spring’s HttpInvoker 지원, Web Service 지원, JMS 지원, Enterprise Application 개발을 위한 Full Stack 지원.

5.    Disadvantage of Spring Framework

- Spring Framework에 대한 막연한 거리감.
- IOC, AOP 등 새로운 개념에 대해 모두 잘 알아야 할거라는 부담감.
- 설정 파일 다루기와 Object 재사용에 대한 이해 부족
- Spring Framework 의 장점을 살릴수 있는 도구 제공이 미흡.
- Spring Framework 도입으로 인한 추가 작업
- 설정 파일 관리
  à 서비스간의 연결을 담당하는 XML관리가 필요, 다만 Convention over Configuration 의 활용과 generator 등을 통해 작업 최소화 가능.
- Interface 생성
  à 각 Layer간 연결이 Interface를 통해 이뤄지기 때문에 Interface 생성이 필요.
  à Overhead 작업으로 볼 수도 있지만, Layer 간 loosed coupling 을 위해서 Spring Framework를 사용하지 않을 경우에도 필요.

6.    Spring Framework의 각 Jar 파일의 구성
Spring Framework 배포본을 다운로드하여 압축을 풀면 dist 폴더가 존재, 여기에는 spring framework 의 라이브러리가 jar 파일 형태로 제공되는데, 필요에 따라 이들 파일들을 선택적으로 가져다가 사용.

A.     Full Jar (/dist)
spring.jar : 모든 표준 모듈들을 결합한 파일, modules 폴더의 모든 jar 파일들을 합친것.
(extension 폴더의 jar 파일들은 미포함)

B.     Module Jar(/dist/modules)  이하 (Contents / Dependencies 의 형태로 기재)
- spring-core.jar : core utilites / Commons Logging(Log4J)
- spring-beans.jar : JavaBeans support, bean container / spring-core(CGLIB)
- spring-aop.jar : AOP framework, source-level metadata support, AOP alliance interface / spring-core( spring-beans, CGLIB , Commons Attributes)
- spring-context.jar : application context, validation, JNDI, UI context support, scripting / spring-beans(Velocity, FreeMarker, JasperReports)
- spring-dao.jar : DAO support, transaction infrastructure / spring-core(spring-beans, spring-aop, spring-context, JTA)
- spring-jdbc.jar : JDBC support , iBatis SQL Maps support / spring-dao, spring-beans(iBatis SQL Maps)
- spring-support.jar : JMX support, JCA support, scheduling support, mail support, caching support / spring-beans(spring-context, spring-dao, spring-jdbc, JMX, Quarts, JavaMail, EHCache)
- spring-web.jar : web application context, mulitpart resolver, Struts support, JSF support, web utilities / spring-context, Servlet,(JSP,JSTL ,Commons FileUpload, COS, Struts, JSF)
- spring –webmvc.jar : framework servlets, web MVC framework, web controller, web views / spring-web(Tiles, iText, POI , Velocity, FreeMarker, JasperReports)
- spring-remoting.jar : remoting support , EJB support, JMS support / spring-beans, spring-aop(spring-context,spring-web,Hessian,Burlap, JAX-RPC, EJB, JMS) , Extension Module Jar(/dis/exmodules)
- spring-portlet.jar : framework portlets, portlet MVC / spring-web,spring-webmvc(Portlet)
- spring-jdo.jar : JDO 1.0/2.0 support / spring-dao, spring-jdbc , JDO(spring-web,spring-portlet)
- spring-jpa.jar : JPA 1.0 support / spring-dao, spring-jdbc,JPA(spring-web, spring-portlet)
- spring-hibernate2.jar : Hibernate 2.1 support / spring-dao, spring-jdbc, Hibernate2(spring-web,spring-portlet)
- spring-hibernate3.jar : Hibernate 3.0/3.1 support / spring-dao, spring-jdbc, Hibernate3(spring-web,spring-portlet)
- spring-toplink.jar : TopLink support / spring-dao, spring-jdbc, TopLink
- spring-ojb.jar : OJB 1.0 support / spring-dao,spring-jdbc , OJB
- spring-mock.jar : JNDI mocks, Servlet API mocks, Portlet API mocks, JUnit support / spring-core

C.     Aspects Jar(/dist/aspects)
- spring-aspects.jar : AspectJ aspects, for explicitly linking aspects into an IDE (Eclipse AJDT)
- Not needed for deployment, since its classes are also in “spring” and “spring-aop”

D.     Summary
- 편하기 사용하기 위해서는 /dist/spring.jar 만 사용한다.
- 꼼꼼하게 필요한것만 사용하려면 /dist/spring.jar 를 사용하지 말고, /dist/modules 폴더의 필요한 jar 파일들만 선택하여 사용한다.
- /dist/extmodules 파일들은 필요한 것만 골라서 사용한다.
- /dist/aspects 의 jar 파일은 eclipse 로 AspectJ를 사용하려고 할 때만 필요하다. 실제 배포시 필요 없음.

7.    DI 의 개념

일반적으로 어플리케이션은 컴포넌트들을 조합하여 이루어진다고 가정하자. 컴포넌트란 소프트웨어 모듈로서 더 이상의 수정이 없이도 사용할 수 있는 라이브러리를 뜻한다.
이때 어플리케이션을 구성하는 과정에서 각 컴포넌트들 사이의 결합은 서로가 서로를 호출하는 형태로 이뤄진다.
이러한 컴포넌트들간의 연관관계(혹은 Dependency)는 여러가지 문제점을 가진다.
이러한 문제점은 시스템의 구동과정에서의 문제를 의미하는 것이 아니라, 개발과정에서 여러가지 형태의 변경과정, 유지, 보수, 업그레이드 과정에서 발행하는 문제를 의미한다.
여러 컴포넌트들 가운데 특정 컴포넌트를 변경하려고 하면, 혹은 교체하려고 하면, 이 컴포넌트와 연관된 컴포넌트들에게도 변경이 불가피 하게 된다.

<그림 1>


발생의 전환점은 바로 여기 있는데, 그렇다면 컴포넌트들 간의 연관관계를 더 느슨하게 혹은 외부에서 할수 없을까?
그렇다!!! 연관관계를 컴포넌트들간에 이뤄지도록 하지 말고, 컴포넌트들을 가지는 컨테이너가 연관관계를 규정하도록 하자. 그렇게 하면 컴포넌트들 사이에는 연관관계가 발생하지 않으므로 위에 언급되었던 문제들은 해결될것이다.
이것이 바로 Inversion of Control / Dependency Injection 의 핵심 개념이다.

<그림 2>


그림 1과 그림 2를 비교해 보면, 그림 1에서는 클래스 CA 가 클래스 IBImpl을 생성한다.
IBImpl 클래스가 다른 클래스로 변경되면 CA에도 변경이 필요하게 된다.
반면, 그림2에서 클래스 CA는 클래스 IBmpl 과 연관관계가 없다. 단지 인터페이스 IB만을 호출한다.
그러므로 IBImpl 클래스가 다른 클래스로 변경되어도 CA 에 변경이 가해질 일이 없게 된다.

즉 DI가 갖게 되는 장점은 아래와 같다.
 - 코드의 단순화
 - 종속적인 코드의 최소와(인프라 코드와 비즈니스 코드 분리)
 - 어플리케이션을 더 쉽게 유지 관리

이렇게 컨테이너 에게 제어권이 넘어간 것을 IoC 라고 하고 ,용어 자체의 문제로 인해 보통은 DI라고 부르는게 추세다. 기존 코드가 코드안에 객체의 생성과 소멸을 했다고 한다면, DI 개념 안에서는 객체를 생성, 파괴 하고 객체간의 의존관계를 컨테이너에 의해서 제어함 한다는 것이 핵심인 것이다.
컨테이너가 객체를 제어하는 방식은 XML 이 될 수도 있고 Properties 로도 할수 있따.
스프링에서는 간단한 Convention 룰을 통해서 XML로 관리한다고 보면 될 것이다.

IoC 의 구현방법에는 두가지가 있다. 첫째는 Dependency Lookup 이다.
이 것은 컨테이너가 callback을 통해서 제공하는 lookup context를 이용해서 필요한 리소스나 오브젝트를 얻는 방식이다. EJB 와 Apache Avalon의 구현방법이다.
둘째는 Dependency Injection 이다.
우리가 해야하는 부분은 바로 이 DI 부분이다. 이것은 비즈니스 오브젝트에 look up 코드를 사용하지 않고, 컨테이너가 직접 의존구조를 오브젝트에 설정할 수 있도록 지정 해 주는 방법이다.
DI는 다시 Setter Injection 과 Constructor Injection으로 나뉜다.
Dependency Lookup은 JNDI 등을 이용하는데, 오브젝트간에 decoupling 을 해주는 면에서 장점이 있기는 하다.
하지만 이렇게 만들어진 오브젝트는 컨테이너 밖에서 실행 할 수 없고 JNDI외의 방법을 사용할 경우 JNDI 관련 코드를 오브젝트내에 일일히 변경해 줘야 하며 테스트하기 매우 어렵고 코드양이 매우 증가하고 Strong typed 가 아니므로 Object로 받아서 매번 Casting 해야 하고 (그래서 primitive type은 wrapper class를 써야 하고) NamingException 같은 Checked exception을 처리 하기 위해서 exception 처리구조가 매우 복잡해지는 단점이 있다.
Dependency Injection은 각 오브젝트가 자신이 의존적인 resource 와 collaborator에 대한 lookup의 책임을 가지지 않고 대신 컨테이너가 그 일을 담당하고 오브젝트 내에 주입해주는 방식이다.
따라서 lookup과 관련된 코드들이 오브젝트 내에서 완전히 사라지고 컨테이너에 의존적이지 않는 코드를 작성할 수 있다.
이는 오브젝트가 컨테이너의 존재여부를 알 필요조차도 없기 때문이다.
또 특별한 인터페이스 구현이나 클래스의 상속의 필요가 없다.

8.    설치 (Spring Framework + maven)

참으로 간단 해졌구려.. 우선 설치 된 Eclipse 상에서 Help > Eclipse Market place 상에서
해당 Eclipse 버전에 맞는 SpringSource Tool Suite 와 Maven 을 install 한다.
근데… 좀 이상하다.. 버전이 맞지 않는듯한 느낌이 있어서 www.springsource.org/downloads 로 이동해서 내컴퓨터 사양에 맞는 버전을 다시 다운 받아서 설치한다.