Spring Framework 개념

프레임워크 (Framework)란 일하기 위한 틀

 

웹 프레임워크를 예로 들어 설명하자면, 웹에서 어떤 일을 하기 위해 정해놓은 틀이라는 겁니다.

웹에서 MVC 패턴에 따라 프로젝트를 진행하고자 할 때, 뷰 페이지를 생성하거나 요청을 컨트롤 하거나 비즈니스 로직을 수행하는데 도움이 되는 클래스들을 만들어 하나의 라이브러리로 제공하는 것이 바로 웹 프레임워크이지요.

사용자는 프레임워크가 제공하는 라이브러리를 이용해서 도움을 받으며 가이드라인에 따라 프로젝트를 진행하면 되기 때문에 쉽고 빠르게 작업이 가능합니다.

웹 프레임워크의 대표적인 예 : 오픈 프로젝트인 Struts1 & 2, Spring framework

 

1. Spring Framework 개요

  엔터프라이즈 급의 웹 어플리케이션 개발에서 필요로 하는 라이브러리를 제공하는 프레임워크로 현재 가장 많이 사용되고 있습니다. J2EE가 제공하는 다수의 기능을 지원하면서 그 사용이 용이하다는 장점이 있죠.

  가장 강력한 기능은 IoC(DI(Dependency Injection)), AOP(Aspect Oriented Programming)입니다.

  전통적인 어플리케이션 제작에 있어서 클래스는 홀로 사용되어 지지 않습니다. 보편적으로 다른 클래스를 가지고 있거나 부모 클래스를 상속받아 사용하는 등, 거의 모든 클래스가 has-a나 is-a 관계를 가지고 있으며 이러한 부분을 의존성(Dependency)이라고 부르며 한 객체가 다른 객체에 의존하고 있다 말할 수 있죠.

  의존성을 가진 클래스의 인스턴스를 생성하기 위해 개발자들이 직접 new 연산자를 사용하거나 Factory 패턴을 통해 인스턴스를 생성하여 사용합니다.

주요 기능과 특징

  ■ Lightweight Container

      - 자바 객체를 담고 있는 컨테이너.

      - 자바 객체의 생성, 소멸과 같은 라이프 사이클을 관리.

      - 스프링으로부터 필요한 객체를 가져와 사용할 수 있음.

  ■ DI(Dependency Injection) 패턴을 지원

      - 설정 파일을 통해서 객체간의 의존 관계를 설정.

      - 객체는 직접 의존하고 있는 객체를 생성하거나 검색할 필요가 없음.

  ■ AOP(Aspect Oriented Programming)를 지원

      - 자체적으로 AOP를 지원.

      - 트랜잭션이나 로깅, 보안과 같이 여러 모듈에서 공통으로 필요로 하지만 실제 모듈의 핵심은 아닌 기능을 분리해서 각 모듈에 적용.

  ■ POJO(Plain Old Java Object)를 지원

      - 스프링 컨테이너에 저장되는 자바 객체는 특정한 인터페이스를 구현하거나 클래스를 상속받지 않아도 됨.

      - 기존에 작성한 코드를 수정할 필요 없이 스프링에서 사용 가능.

  ■ 트랜잭션 처리를 위한 일관된 방법을 제공

      - 설정 파일을 통해 트랜잭션 관련 정보를 입력하기 때문에, 트랜잭션 구현에 상관없이 동일한 코드를 여러 환경에서 사용 가능.

  ■ 영속성과 관련된 다양한 API를 지원

      - JDBC를 비롯하여 iBATIS, 하이버네이트, JPA, JDO 등 데이터베이스 처리와 관련하여 널리 사용되는 라이브러리와의 연동을 지원.

  ■ 다양한 API에 대한 연동을 지원

      - JMS, 메일, 스케줄링 등 엔터프라이즈 어플리케이션을 개발하는데 필요한 다양한 API를 설정 파일을 통해서 손쉽게 사용 가능.

 

Lightweight Container

  해당 코드 안에 container 의존적인 부분이 없다는 말입니다. container가 J2EE 의존적이지 않아 standalone Java 환경에서도 구동이 가능하다는 거죠.

 

자바 기반의 어플리케이션

  객체 생성, 서로간의 의존관계(소유)를 연결시키는 작업에 대한 제어권이 개발자에게 존재

  서블릿, EJB 기반의 개발은 객체 생성의 제어권이 컨테이너로 넘어감 그로 인해 객체의 Life Cycle을 관리하는 권한은 컨테이너들이 전담

 

  IoC가 말하는 제어권 역전

  객체의 생성과 소멸까지의 Life Cycle 관리를 컨테이너가 관리함을 의미. 즉 스프링 컨테이너는 객체에 대한 생성 및 생명주기를 관리하는 기능을 제공.

  이와 같은 이유로 Spring Framework를 Spring Container, IoC 컨테이너와 같은 용어로 부르는 경우도 종종 볼 수 있음

 

Spring Container는 POJO를 관리하기 위한 Container.

  POJO란 특정 인터페이스에 종속되지 않은 Java Beans와 같은 클래스를 말합니다. 즉, 서블릿 클래스 안에서 사용되어지는 비즈니스 로직을 담당하는 DAO, DT, VO와 같은 객체를 뜻하죠.

  특정 인터페이스에 종속된 클래스는 클래스를 작성해야 할 때 작성할 규칙을 가지고 있는 클래스를 말하며 대표적인 것이 서블릿 클래스입니다.

 

Spring, EJB, 그리고 Non EJB

  스프링은 서블릿 안에 사용되고 있던 POJO 클래스의 객체 생성과 소멸과 의존성을 개발자가 아닌 Spring Framework가 맡습니다.

  왜 이와 같은 클래스 생성과 소멸을 Spring이 맡는가 하면 EJB 아키텍쳐 기반으로 어플리케이션을 개발할 경우 개발 과정이 복잡하고 테스트하기 어려운 단점이 있지만 EJB 컨테이너가 제공하고 있는 기능들은 꽤 매력적이기 때문입니다.

  Non EJB 아키텍쳐의 경우 개발 속도가 빠르고 테스트의 용이성이 뛰어나지만 컨테이너 기능으 지원하지 않으므로써 EJB 컨테이너가 지원했던 기능들을 개발자들이 직접 구현하는 불편함을 감수할 수 밖에 없었습니다.

  이와 같은 각각의 장단점을 보완하는 방법으로 POJO 객체는 개발자들이 직접 개발을 하지만 사용에는 POJO를 관리할 수 있는 컨테이너를 만들어서 EJB 컨테이너가 지원하는 기능을 지원하는 것입니다. 이 때문에 마지막까지 개발자들에게 남아 있던 POJO에 대한 제어권을 컨테이너에게 넘긴 것이죠.

 

*위의 말을 한번에 이해할 수 있다면 그 사람은 서블릿 기반의 Non EJB 개발을 해 본 사람이라죠?

 

Non EJB 개발에 가장 큰 걸림돌은 계층간 역할의 분담

  복잡함을 줄이기 위해 계층간 역할 분담을 했지만 실제적으로 계층을 정확히 구분하기가 매우 어려우며 나중에 개발단위가 커지면 계층한 역할이 모호해지는 경우도 대부분입니다.

 

  이는 명확하게 계층간의 구분이 이루어지고 잘 설계된 아키텍쳐를 가지지 않는 Non EJB 아키텍쳐의 한계죠.

IoC(Inverse of Control)

  제어의 역전. 객체 생성과 의존성을 개발자가 아닌 컨테이너가 맡는다는 개념입니다. 인스턴스의 생성과 관리의 주체가 개발자에서 컨테이너에게 넘어갑니다. 개발자는 더이상 객체 생성에 신경 쓸 필요 없이 마치 객체가 생성되어 있는 것처럼 프로그램 코드를 작성하고 설정 데이터에 객체간의 의존성을 정의하면 컨테이너가 알아서 객체를 생성해 프로그램을 수행합니다. 이것으로 객체의 관계를 느슨하게 연결할 수 있으며 Spring Framework를 경량 프레임워크라고 부르는 이유죠.

IoC의 핵심

  개발자가 직접 작성해 사용해오던 자바빈을 이제는 컨테이너가 관리하겠다는 것으로 개발자는 Java Bean 객체를 Spring Container에 등록해 놓기만 하면 객체 생성과 소멸 등의 부수적인 작업은 컨테이너가 알아서 해줍니다. 이렇게 객체와 객체간의 의존성을 개발자에게서 Container로 가져가는 것이 IoC의 핵심이죠.

 

IoC의 구성

  설정 파일을 통해 관리되고 Container가 설정 파일을 해석하는 과정을 거치기 때문에 어떤 객체가 생성되고 어떤 객체가 어떤 객체를 소유하고 있는지 알 수 있습니다.

  모든 IoC Container는 각 Container에서 관리해야 하는 객체들을 별도의 저장소(Repository)에서 관리합니다.

 

  서블릿 클래스를 등록하는 web.xml 설정파일처럼 각각의 객체를 지정하는 설정파일을 IoC 컨테이너가 가지고 있습니다.

EJB Container

  - ejb-jar.xml에 객체의 정보를 저장

Servlet

  - web.xml에 객체의 정보를 저장

Spring framework

  - POJO들을 관리하기 위한 별도의 저장소로 xml 파일 형태와 JAVA Properties 파일 형태를 이용

DL(Dependency Lookup)

  저장소에 저장되어 있는 Bean에 접근하기 위해 개발자들이 Container에서 제공하는 API를 이용해 사용하고자 하는 Bean을 Lookup하는 것을 말합니다. 저장소에 의해 관리되고 있는 빈을 개발자들이 직접 Lookup하여 사용하는 것으로, DL을 사용할 경우 저장소에 있는 Bean은 Lookup하기 위해 컨테이너에서 제공하는 API와의 의존 관계가 발생합니다.

  컨테이너 API와 의존관계를 많이 가지면 가질수록 애플리케이션이 컨테이너에 대해서 가지는 종속성은 증가할 수 밖에 없습니다. 따라서 가능한 DL을 사용하지 않는 것이 컨테이너와의 종속성을 감소시킬 수 있는 방법입니다. 그리고 컨테이너와의 종속성을 줄이기 위한 방법은 DI를 통해 가능하죠.

 

DI(Denpendency Injection) – Spring

  DI는 Spring Framework에서 사용하는 방식으로 각 클래스 사이의 의존관계를 Bean definition 정보를 바탕으로 컨테이너가 자동적으로 연결해 주는 것입니다. 컨테이너가 의존관계를 자동적으로 연결시켜 주기 때문에 개발자들이 컨테이너 API를 이용하여 의존관계를 관여할 필요가 없게 되므로 컨테이너 API에 종속되는 것을 줄일 수 있습니다.

  개발자들은 단지 Bean Definition에 의존관계가 필요하는 정보를 추가하기만 하면 됩니다. 

  Spring Framework는 각 클래스 사이의 의존관계를 관리하기 위한 방법으로 Setter Injection, Constructor Injection, Method Injection의 세가지 유형을 제공합니다.

AOP(Aspect Oriented Programming)

  그동안의 전통적인 프로그래밍에서 개발자들이 느끼고 있던 불편함을 개선한 새로운 프로그래밍 패러다임으로 AOP에서 비즈니스 로직을 구현한 기능들을 Primary(Core) Concern이라고 부르고 보안, 인증, 로그들과 같은 부가적인 기능들을 Cross-Cutting Concern이라고 부르는데 이중 개발자를 피곤하게 하는 Cross-cutting concern을 어떻게 다룰 것인가에 대한 새로운 패러다임을 재고하고 있습니다. AOP 이전에는 Primary concern과 Cross-cutting concern이 하나의 프로그램에 구현되어 왔죠.

AOP는 Primary concern과 Cross-cutting concern을 별도의 코드로 구현하고 최종적인 프로그램은 이 둘을 조합하여 완성하게 됩니다.

Advice, Code, Point-Cut, Weaving

Code : Primary(Core) concern을 구현해 놓은 코드

Advice : Cross-cutting concern을 구현한 코드

JoinPoint : Advice와 Code를 연결해주는 설정 정보(Code의 어느 위치에 Advice를 위치할 것인가에 대한 것) – Method 호출, 필드값 변경

Point-cut : 실제 Advice가 정용되는 Jointpoint

Weaving : Code와 Advice를 조합하여 완성된 어플리케이션을 만드는 과정

*이해되시면 AOP 절반은 이해하신 겁니다.

 

왜 AOP(Aspect Oriented Programming)라고 지칭하는가 하면, AOP의 Aspect는 Advice와 Point-cut을 함께 지칭하는 단어랍니다.

 

  Spring의 AOP 패키지는 이러한 AOP 개념을 멋지게 구현한 것으로서 그 배경에는 IoC 혹은 DI가 자리잡고 있습니다. Spring AOP도 여러 AOP 프레임워크 중의 하나로 나름의 특징이 있죠.

  1. 자체적인 프록시 기반의 AOP 지원

  2. 필드값 변경과 같은 Joinpoint는 사용할 수 없고 메소드 호출 Joinpoint만 지원

  3. Spring AOP는 완전한 AOP를 지원하는 것이 목적이 아닌 엔터프라이즈 어플리케이션을 구현하는데 필요한 정도의 기능 제공을 목적

  4. Aspect는 별도의 문법을 알아야 하지만 Spring AOP는 자바를 기반으로 하고 있기 때문에 다른 언어 불필요

  5. Spring AOP는 내부적으로 프록시를 이용하여 AOP가 구현되기 때문에 메소드 호출에 대해서만  AOP를 적용할 수 있다는 점이 아쉬운 점

 

  최근 주목받고 있는 REST 아키텍쳐의 자바 구현체인 Restlet과 같이 사용 가능

  Restlet만으로는 모든 웹서비스를 구현하기에 불편하나 Spring과 결합 모델로 구현이 가능

-----------------

여러 사이트(블로그)에 있는 내용들을 모아 정리한 것입니다.