스프링의 3대 핵심 요소

 

스프링에서 가장 대표적인 핵심 요소가 3가지 정도에 대해서 알아보겠습니다.

 

1. PSA, Portable Service Abstraction

PSA는 서비스의 추상화를 의미하며 Spring이 다른 기술을 추상화하여 개발자가 각 기술의 구현 세부 정보에 대해 

걱정하지 않아도 일관된 방식으로 사용할 수 있게 해주도록 합니다.

 

기본적으로 스프링은 Servlet을 기반으로 운영되게 됩니다. 

스프링 이전에는 우리가 아는 것처럼 단순히 @RequestMapping 어노테이션을 붙인다고 해서 

API가 만들어 지지는 않았습니다. 

이전에는 webapp의 web.xml(DD, 배포 서술자로도 불립니다.)에 이러한 url 정보들을 적어 놓고 이를 받는 java 클래스에서

doGet, doPost를 overide하여 실질적인 서비스 로직을 구현하였습니다.

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5">
<servlet>
<description>Hello World Sevlet</description>
<display-name>HelloWorld</display-name>
<servlet-name>HelloWorld</servlet-name>
<servlet-class>HelloWorldServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>HelloWorld</servlet-name>
<url-pattern>/helloworld.do</url-pattern>
</servlet-mapping>
</web-app>

web.xml의 예시

 

하지만 이러한 방식은 너무나도 불편할 뿐만 아니라. 유연한 구조를 가지지 못하고

유지보수를 더욱 힘들게 하였으며 확장성 또한 떨어지게 하는 방식이었습니다.

 

스프링은 이러한 부분을 개발자가 신경쓰지 않을 수 있도록 하여 지금의 어노테이션 방식으로 API 생성 방식을 단순화 하였습니다.

이러한 것이 바로 PSA라고도 할 수 있습니다.

스프링에서는 이 뿐만 아니라 Spring의 JDBC에서 DataSource의 연결, 커밋, 롤백, 해제 등 여러 부분을 추상화하여 

공통되는 코드를 최소화 하고 개발자들은 비지니스 로직에 집중할 수 있는 환경을 제공하였습니다.

 

스프링은 PSA를 사용하여 JDBC, 트랜잭션, 메시징, 캐싱, 보안 등  다양한 영역에서 서로 다른 기술을 추상화하고 있습니다.

이러한 PSA는 Spring이 다양한 기술을 지원하면서도 개발자가 일관된 방식을 코드를 작성할 수 있도록 도와줍니다.

 

2. AOP

AOP는 이전 글에도 말했다 싶이 스프링에서 매우 중요하게 동작하는 요소이며

@Transactional, @ControllerAdvice등 여러 기능에 활용되고 있는

관점지향 프로그래밍 입니다.

 

핵심 비지니스 로직과 별개로 다른 공통 기능을 분리하여 관리하는 특징이 있습니다.

스프링 프레임 워크에서 활용되는 예시는 해당 글을 확인해 주시길 바랍니다. 

https://hoonco.tistory.com/36

Spring 그 시작과 핵심

 

이번엔 실제로 저희가 프로그래밍을 하기 위해 AOP에 간단한 용어 및 사용법을 정리하려 합니다.

 

1) Aspect (관점)

여러 모듈에서 공통으로 사용되는 기능들을 모듈화한 것으로, 로깅, 보안, 트랜잭션 등이 있습니다.

포인트 컷과 어디바이스의 결합으로 포인트컷에 대해 어떤 어드바이스 메소드를 실행할지 결정하게 됩니다.

 

2) Join Point (조인 포인트)

프로그램 실행 시점에서 Aspect가 적용될 수 있는 위치로, 메소드 호출, 필드 접근 등이 있습니다.

 

3) Advice (어드바이스)

Join Point에 삽입되어 동작하는 코드로 Aspect가 구현되는 코드입니다.

관심사에 해당하는 공통 기능의 코드 입니다.

Advice의 동작 시점에 대한 부분은 아래와 같습니다.

동작 시점	설명
Before	타겟 메소드 실행 전에 실행되는 Advice입니다.
After	타겟 메소드가 실행된 후에 실행되는 Advice입니다.
After Returning	타겟 매소드가 정상적으로 실행 된 후에 실행되는 Advice입니다.
After Throwing	타겟 메소드에서 예외가 발생한 후에 실행되는 Advice입니다.
Around	타겟 메소드의 실행 전, 실행 후에 실행되는 Advice입니다.

 

4) Point Cut(포인트 컷)

Join Point의 부분 집합으로, 어떤 Join Point에 Advice를 적용할지 결정하는 역할을 합니다.

표현식으론 리턴타입, 패키지 경로, 클래스명, 메소드명 등이 있습니다.

 

5) Weaving (위빙)

Aspect를 적용하는 과정으로 Complie-time, Load-time, Runtime 위빙 등이 있습니다.

즉, 포인트 멋으로 지정한 관심 메소드가 호출될 때, Advice에 해당하는 관심사 메소드가 삽입 되는 과정을 의미합니다.

 

 

포인트컷 표현식

포인트 컷은 어떤 메서드나 클래스의 어느 지점에서 Advice를 적용할지를 적용하는 표현식이기 때문에

AOP의 기본이 되는 부분입니다.

 

표현식에 대한 요소는 아래와 같습니다.

표현식	설명
execution	메소드 실행 시점에 Advice를 적용하는 표현식 입니다.
bean	특정 빈에 대해 Advice를 적용하는 표현식입니다.
within	특정 패키지나 클래스 내부에서 Advice를 적용하는 표현식입니다.
args	메소드 파라미터에 따라 Advice를 적용하는 표현식입니다.
this	빈의 프록시 객체에 대한 참조를 이용하여 Advice를 적용하는 표현식입니다.
target	타겟 객체에 대한 참조를 이용하여 Advice를 적용하는 표현식입니다.
@annotation	어노테이션에 대한 정보를 활용하여 Advice를 적용하는 표현식입니다.

 

아래는 AOP를 활용한 간단한 예시 입니다.

@Slf4j
@Aspect
@Component
public class AOP {

    @Around("execution(* pple.link.ppleprod.domain.*.controller.*.*(..))")
    public Object performence(ProceedingJoinPoint pjp) throws Throwable {
        long begin = System.currentTimeMillis();
        Object retVal = pjp.proceed();
        log.info("response time: {}",(System.currentTimeMillis() - begin));
        return retVal;
    }
}

해당 AOP는

pple.link.ppleprod.domain 아래에 있는 package 중 controller package안에 있는 모든 클래스, 모든 메소드들에 대한

Advice를 지정하여 응답시간이 얼마나 걸리는지에 대한 코드 입니다.

이처럼 간단한 코드만으로 모든 API의 응답 시간을 구할 수 있으며

이를 통하여 평균 응답시간, 이상 증세 체크 등 여러 기능을 구현할 수  있게 됩니다.

 

3. IoC/DI ( Inversion of Control / Dependency Injection )

이전 글에서 설명했다 싶이 IoC는 객체의 생성, 관리, 소멸 등을 관리를 개발자가 아닌 프레임워크에서 관리하는 방식이며

이 구역을 IoC 컨테이너라 하고 해당 객체를 주입해주는 기능이 DI입니다.

 

이전 글에서 스프링에서의 사용 예시가 적혀있으니 아래 링크에서 확인해 주세요! 

https://hoonco.tistory.com/36

Spring 그 시작과 핵심

 

이번엔 IoC/DI가 없었다면 우리는 어떻게 했었을까요

옛날 서블릿 프로그래밍 시절로 돌아가봅시다.

 

옛날엔 스프링이 아닌 Java단의 스펙인 Sevlet을 활용하여 웹 개발을 했었습니다.

물론 WAS인 톰캣의 도움을 받아 관리의 도움을 받기는 합니다 ex) 서블릿 컨테이너

 

서블릿 프로그래밍은 개발 방식도 불편하지만

그 뿐만 문제가 아니라 서블릿과 다른 객체들의 생명주기가 가장 큰 문제였습니다.

 

서블릿을 extends하면 init, service, doGet,doPost, destory라는 메소를 overide할 수 있는데

서블릿의 생명주기를 여기서 모두 지정해주어야 합니다.

 

이처럼 단순히 API를 하나 만드는데 여러 작업이 필요하고 이 뿐만 아니라

해당 서블릿 객체에 대한 라이프 사이클을 관리해주어야 하고 

사용자 정의 클래스, JDBC 클래스 등 많은 객체들의 생명 주기를 관리해주어야 했습니다.