[Spring] Spring Framework의 기본 개념

왜 프레임워크인가?

엔터프라이즈 환경의 프로젝트에서 각 프레임워크가 도입되는 이유는 무엇인가?
가장 큰 이유는 개발 현장의 개발생산성의 향상과 고품질이 보장된 어플리케이션의 개발을 위해서이다.

다양한 요구사항을 만족할 수 있는 유연하고 풍부한 기능을 제공하는 프레임워크구축, 개발 생산성 향상과 고품질의 시스템 개발을 위한 프레임워크의 필요성이 대두되면서, Struts, Spring, WebWork와 같은 프레임웍이 등장하기 시작했다.

왜 스프링인가?

다양한 프레임워크가 나와있고, 그 중에 J2EE기반에서 가장 두각을 나타내는 프레임웍이 Spring이 아닌가 싶다.
이는, 각 레이어를 느슨한 Interface의 결합과 설정의 외부화를 통해 개발이 보다 더 유연하고 견고해지기도 이기도 하지만, 일관된 방법으로 기존 기술들을 편하게 사용할 수 있도록 도와주고, 비즈니스 객체들을 효과적으로 구성하고 관리하는데에 가장 큰 장점이 있기

때문이다. 더불어 막강한 JDBC 자원 관리가 개발자들에게 혁신적인 소스 코딩량의 절약을 가능케 해준다는게 강점 중 하나라고 본다.

 

왜 LightWeight 라고 하는가?

Spring은 하나의 프레임워크이다. 그런데 왜 Spring 컨테이너, IoC 컨테이너라는 말을 사용할까? 그렇다면 컨테이너의 정의는 무엇을까?

Servlet 컨테이너, EJB 컨테이너라는 말하는 것을 종종 들어봤을 것이다. 컨테이너. 우리들이 흔하게 사용하고 있지만 도대체 컨테이너가 뭐란 말인가?
정확한 사전적인 정의는 아니지만  "인스턴스의 생명주기를 관리하며, 생성된 인스턴스들에게 추가적인 기능들을 제공"하는 역할을 하는 녀석이라고 보면 될거같다.

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

스프링 아키텍쳐

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

스프링은 전체 프로젝트의 설정을 관리할 수 있는 일관된 방법을 제공함으로써, 개발자들이 각종 프로퍼티 파일을 작성하지

않도록 유도한다.
이것은 IoC라는 스프링의 특징 때문인데, 객체들간의 의존성이 따로 관리됨으로써 비즈니스 로직이 EJB로 개발되었건 일반 자바 객체로 개발되었건 동일한 방법으로 해당 로직을 이용할 수 있는 이점도 추가된다.

IoC(Inversion of Control : 제어의 역행) 혹은 DI(Dependency Injection : 의존성주입)이라고 불리우는 이 개념과, AOP (Aspect-oriented programming : 관점지향프로그래밍) 개념을 이해한다면, Spring Framework의 전반적인 내용을 이해하고 개발할 수 있다고 생각한다.

개념설명에 앞서, 스프링이 갖는 장점에 대해서 알아본다.

Spring Framework 장점

• 다양한 형태의 Transaction을 선언적으로 사용

• 개발자는 필요한 Transaction에 대한 메소드명만으로 Transaction 구현에서 해방 Remote EJB 사용의 간편성

• 설정 파일에서 Remote EJB가 필요한 객체에 매핑하는 것으로 Local Object 사용하듯이 사용 다양한 Framework과의 통합

• 많이 사용되고 있는 웹 프레임워크와 ORM 프레임워크에 대한 탁월한 지원

• AOP를 보다 쉽게 적용

• Business Logic외에 logging, exception 처리등을 선언적으로 사용할 수 있는 기반 제공

• Transaction을 선언적으로 사용하는 이유도 AOP의 강력한 지원으로 가능

• Covention 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 지원

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을 사용하지 않을 경우에도 필요

Spring Framework을 사용하기 앞서, 각 Jar파일들이 어떻게 구성되어 있는지 살펴본다.

Spring Framework 배포본을 다운로드하여 압축을 풀면 dist 폴더가 존재한다.
여기에는 spring framework의 라이브러리가 jar파일 형태로 제공되는데 필요에 따라서 이들 파일들을 선택적으로 가져다가 이용하게 된다. 이 jar 파일들의 정보를 요약하면 다음과 같다 :

Full Jar (/dist)

• "spring.jar" (~1915 KB)

  • 모든 표준 모듈들을 결합한 파일 (modules 폴더의 모든 jar 파일들을 합한 것이다.)

  • Note: extension 폴더의 jar 파일들은 포함하지 않았다.

Module Jar (/dist/modules)

• "spring-core.jar" (~145 KB)

  • Contents: core utilities

  • Dependencies: Commons Logging, (Log4J)

• "spring-beans.jar" (~295 KB)

  • Contents: JavaBeans support, bean container

  • Dependencies: spring-core, (CGLIB)

• "spring-aop.jar" (~270 KB)

  • Contents: AOP framework, source-level metadata support, AOP Alliance interfaces

  • Dependencies: spring-core, (spring-beans, CGLIB, Commons Attributes)

• "spring-context.jar" (~140 KB)

  • Contents: application context, validation, JNDI, UI context support, scripting

  • Dependencies: spring-beans, (Velocity, FreeMarker, JasperReports)

• "spring-dao.jar" (~105 KB)

  • Contents: DAO support, transaction infrastructure

  • Dependencies: spring-core, (spring-beans, spring-aop, spring-context, JTA)

• "spring-jdbc.jar" (~215 KB)

  • Contents: JDBC support, iBATIS SQL Maps support

  • Dependencies: spring-dao, spring-beans, (iBATIS SQL Maps)

• "spring-support.jar" (~190 KB)

  • Contents: JMX support, JCA support, scheduling support, mail support, caching support

  • Dependencies: spring-beans, (spring-context, spring-dao, spring-jdbc, JMX, Quartz, JavaMail, EHCache)

• "spring-web.jar" (~155 KB)

  • Contents: web application context, multipart resolver, Struts support, JSF support, web utilities

  • Dependencies: spring-context, Servlet, (JSP, JSTL, Commons FileUpload, COS, Struts, JSF)

• "spring-webmvc.jar" (~250 KB)

  • Contents: framework servlets, web MVC framework, web controllers, web views

  • Dependencies: spring-web, (Tiles, iText, POI, Velocity, FreeMarker, JasperReports)

• "spring-remoting.jar" (~170 KB)

  • Contents: remoting support, EJB support, JMS support

  • Dependencies: spring-beans, spring-aop, (spring-context, spring-web, Hessian, Burlap, JAX-RPC, EJB, JMS)
    Extension Module Jar (/dist/extmodules)

• "spring-portlet.jar" (~110 KB)

  • Contents: framework portlets, portlet MVC

  • Dependencies: spring-web, spring-webmvc, (Portlet)

• "spring-jdo.jar" (~65 KB)

  • Contents: JDO 1.0/2.0 support

  • Dependencies: spring-dao, spring-jdbc, JDO, (spring-web, spring-portlet)

• "spring-jpa.jar" (~45 KB)

  • Contents: JPA 1.0 support

  • Dependencies: spring-dao, spring-jdbc, JPA, (spring-web, spring-portlet)

• "spring-hibernate2.jar" (~90 KB)

  • Contents: Hibernate 2.1 support

  • Dependencies: spring-dao, spring-jdbc, Hibernate2, (spring-web, spring-portlet)

• "spring-hibernate3.jar" (~110 KB)

  • Contents: Hibernate 3.0/3.1 support

  • Dependencies: spring-dao, spring-jdbc, Hibernate3, (spring-web, spring-portlet)

• "spring-toplink.jar" (~55 KB)

  • Contents: TopLink support

  • Dependencies: spring-dao, spring-jdbc, TopLink

• "spring-ojb.jar" (~30 KB)

  • Contents: OJB 1.0 support

  • Dependencies: spring-dao, spring-jdbc, OJB

• "spring-mock.jar" (~75 KB)

  • Contents: JNDI mocks, Servlet API mocks, Portlet API mocks, JUnit support

  • Dependencies: spring-core

Aspects Jar (/dist/aspects)

• "spring-aspects.jar" (~10 KB)

  • Contents: 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"

정리하면 다음과 같다 :

• • 그냥 편하게 사용하려면 /dist/spring.jar 만을 사용한다.
    좀 따져서 꼼꼼하게 필요한 것만 사용하려면 /dist/spring.jar를 사용하지 말고 /dist/modules 폴더의 필요한 jar 파일들만 선택하여 사용한다.

  • /dist/extmodules 파일들은 필요한 것만 골라서 사용한다.

  • /dist/aspects 의 jar 파일은 eclipse로 AspectJ를 사용하려고 할 때만 필요하다. 실제 배포시에는 필요없다.

DI의 개념

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

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 

 

 

 

 

 

 

 

 

 

 

 

 

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

즉, DI가 갖게 되는 장점은 아래와 같다.

• 코드의 단순화

• 종속적인 코드의 최소화 (인프라 코드와 비즈니스 코드 분리)

• 어플리케이션을 더 쉽게 유지관리

이렇게 컨테이너에게 제어권이 넘어간것을 IoC라고 하며, 용어자체의 문제로 인해 보통은 DI라고 부르는게 요즘의 추세라고 본다.
기존 코드가 코드안에서 객체의 생성과 소멸을 했다고 한다면, DI 개념 안에서는 객체를 생성, 파괴와 객체간의 의존관계를 컨테이너에 의해서 제어함한다는것이 핵심인것이다. 컨테이너가 객체를 제어하는 방식은 XML이 될 수도 있고 Properties로도 할 수도 있다. 스프링에서는 간단한 컨벤션 룰을 통해서 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과 관련된 코드들이 오브젝트 내에서 완전히 사라지고 컨테이너에 의존적이지 않은 코드를 작성할 수 있다.
이는 오브젝트가 컨테이너의 존재여부를 알 필요조차도 없기 때문이다. 또 특별한 인터페이스 구현나 클래스의 상속의 필요가 없다.

 

=========================================================================================================================

출처 : http://okjsp.pe.kr 의 Quick 님이 만드신 자료입니다.

=========================================================================================================================