스프링은 다양한 기술들이 복합적으로 짜여있으며, 이것들이 함께 어떻게 상호작용하는지 알아야 스프링을 잘 사용할 수 있습니다.

스프링의 구조

1. Core Container
2. Web Layer
3. Data Access Layer
4. Infrastructure
5. Test Layer

1. Core Container (DI, IoC)

[전편에서 설명]https://velog.io/@yunhee-son/Spring-01-Core-Container-Ioc-DI

• 스프링의 메인 아이템
• 내가 만든 클래스를 스프링이 직접 관리하여 어플리케이션을 동작하게 한다.

SpEL - 짧은 표현식을 통해 필요한 데이터나 설정 값을 얻어올 수 있게 하는 특별한 형태의 표현식에 가까운 간편한 언어

2. Web Layer

• 웹과 관련된 모든 클래스들

• 스프링 MVC 프레임워크의 중심

  3. Data Access Layer

  

• ORM (Object to Relational Mapping) 관계형 맵핑 객체

• Transactions AOP에서 주로 사용된다.

• JMS (Java Message Service) 메시지 브로커에 비동기식 패션 메시지를 보내기 위한 경우 스프링은 JMS에 대한 도우미 클래스를 제공

  4. Infrastructure

  [전편에서 설명]https://velog.io/@yunhee-son/Spring01-Overview

  5. Test Layer

  

• TDD (Test-Driven-Development) 지원

1. POJOs를 기반으로 한 경량개발
2. 객체 간 느슨한 결합을 위한 의존성 주입
3. AOP(관점지향프로그래밍)을 기반으로 한 선언적 프로그래밍
4. 표준 자바코드 최소화

=> "Java Enterprise 개발 단순화"

1. POJOs(Plain-Old-Java-Objects)

• 포조는 Java EE 등으로 인해서 점점 무거워지는 객체에 대해서 반발하며 나타난 개념이다. 즉, 다른 클래스나 인터페이스를 상속/implements 받아 메서드가 추가된 클래스가 아닌 일반적으로 우리가 알고 있는 getter, setter 같이 기본적인 기능에 충실한 자바 객체를 말한다.

참고 https://needjarvis.tistory.com/585 https://velog.io/@galaxy/Spring의-기본-특징-POJO

2. 의존성 주입(DI) - Dependency Injection

의존성 주입은 객체간의 결합을 느슨하게 해준다. 느슨한 결합은 다음과 같은 장점이 있는데,

1. 두 객체 간의 관계라는 관심사의 분리
2. 두 객체 간의 결합도를 낮춤
3. 객체의 유연성을 높임
4. 테스트 작성을 용이하게 함

출처: https://mangkyu.tistory.com/150 [MangKyu's Diary]

3. 관점지향 프로그래밍

(Aspect Oriented Programming, 관점지향 프로그래밍)

• OOP(객체지향 프로그래밍)를 발전시키기 위한 개념이다.
• OOP로 처리하기에는 다소 까다로운 부분을 AOP라는 처리 방식을 도입하여 손쉽게 공통 기능을 추가/수정/삭제 할 수 있도록 해준다.

기존의 단순 OOP에서는 계좌이체, 입출금, 이자계산의 서비스가 각각의 OOP로 프로그래밍 되었고, 각각의 OOP 모두 기능 작동을 위해 로깅, 보안, 트랜잭션을 하는 코드가 구현되어있었다.

그런데 계좌이체, 입출금, 이자계산 비즈니스 모두가 공통적으로 갖는 로직이 있는 것을 알 수 있다. 그렇다면 이것을 각각의 OOP 소스코드에서 제거하고 외부로 빼내 하나의 공통 모듈로 만들 수 있다. 이것이 바로 기존의 OOP에 AOP 관점을 더해 발전시킨 기법이다.

Core Concern(핵심 관심) : 각 서비스의 핵심 비즈니스 로직. i.e. 계좌이체, 입출금, 이자계산 Crosscut Concern(횡단 관심) : 공통 모듈. i.e. 로깅, 보안, 트랜잭션

AOP의 핵심은 공통 모듈을 분리시켜 해당 소스코드가 외부의 다른 클래스에서 존재하는 것이다.

AOP개념을 도입함으로써 얻는 장점

• 각 비즈니스 로직마다 복붙을 통해 생겨난 중복 코드가 사라진다.
• 각 비즈니스 로직을 구현하는 개발자는 자기 자신의 비즈니스 코드에만 집중할 수 있어 코드가 간결해지고, 유지보수가 쉬워진다.
• 재활용성이 더욱 높아진다.

AOP의 기본 개념들

AOP의 구성 요소

JointPoint : Crosscut Concern(횡단 관심)을 삽입할 시점(when). i.e. 함수가 Before(실행 전), After(실행 후), AfterReturning(반환 후), AfterThrowing(예외 발생시), Around(실행 전과 후) PointCut : 어떤 클래스의 어떤 함수에 삽입할건지. 삽입할 위치(where). Aspect : JointPoint(when) + PointCut(where) Advice : 무엇(what)을 삽입할건지. Weaving : Aspect(when + where) + Advice(what). 위빙을 통해 지정된 객체를 새 Proxy 객체로 생성한다. Proxy : Crosscut Concern(횡단 관심)이 Core Concern(핵심 관심)에서 직접 실행되지 않고 Proxy(대리인)을 생성해 실행된다.

[출처] https://greendreamtrre.tistory.com/601

4. 표준자바코드 최소화

스프링 프레임워크는 POJO(Plain Old Java Object)를 지원합니다. 즉, 별도의 API를 사용하지 않고 일반 자바 코드만으로 구성 가능하기 때문에 기본적으로 매우 가볍습니다. (스프링 기본 프로젝트는 약 2MB에 불과)

출처: https://the-dev.tistory.com/15 [DevLogs]

[참고하면 좋은 글] 우리는 왜 스프링을 사용하는가? https://joychae.tistory.com/27

• 자바 어플리케이션 빌드를 위한 유명한 프레임워크

• 처음 목적은 J2EE에 대응하는 보다 간단하고 가벼운 프레임워크
• 굉장히 많은 보조 클래스로 쉬운 작업이 가능

그렇다면 J2EE란 무엇인가??

J2EE는 매우 방대한 범위를 다루는 스펙 집합 J2EE의 대표 구성 요소

1. Servlet : 클라이언트가 보내는 HTTP 요청을 처리하는 서버측 자바 프로그램이며, Servlet 엔진이 있어야 합니다.

2. JSP(Java Server Pages): HTML이나 Java 코드를 써서 사용자에게 정보를 보여 줍니다. JSP가 처음 실행될 때 Servlet 엔진이 이것을 Servlet으로 컴파일시켜서 내부적으로는 Servlet으로 동작합니다.

3. EJB(Enterprise Java Beans) : Java에서 제공하는 분산 컴포넌트 기술로 비즈니스 로직이나 데이터, 메시지를 처리할 수 있습니다.

4. Remote Method Invocation(RMI): 프록시를 써서 원격에 있는 Java 객체의 메소드를 실행시키기 위한기술입니다.

5. Java Naming DirectoryInterface (JNDI): 자바 기술로 만들어진 객체에 이름을 붙여 찾을 수 있도록 단일한인터페이스를 제공합니다.

6. Java Database Connector(JDBC): 여러 종류의 데이터베이스 시스템에 접근하는 단일한 인터페이스를 제공합니다. 각각의 데이터베이스에 맞는 JDBC 드라이버가 있어야 합니다.

7. Java Connector Architecture(JCA): 이기종 플랫폼을 통합할 수 있도록 플랫폼 독립적인 인터페이스를 제공합니다.

8. Java Message Service (JMS): 여러 가지 메시징 시스템에 대한 플랫폼 독립적인 인터페이스를 제공합니다.

🔰J2EE 에서 JAVA EE로

J2EE는 기업용 자바 플랫폼 이라는 목적을 집중으로 하여, 2006년 JavaEE로 명칭을 바꾸게 됩니다. 자바EE는 출시 초창기에 기업용 자바 플랫폼이라는 새로운 생태계를 열며 큰 성과를 이뤘지만, 현재는 상업용 플랫폼의 한계와 스프링 프레임워크(Spring Framework) 등 오픈소스 SW의 발전으로 빛을 잃어가고 있습니다.

🔰새로운 시작, Jakarta EE(Jakarta, Enterprise Edition)

1999년 썬 마이크로시스템즈의 발표로 시작된 J2EE의 역사는 오라클을 거쳐 현재는 이클립스 재단의 이관으로, 2019년 Jakarta EE로 명칭이 또 한번 변경되었습니다.

자카르타EE는 기존 JCP 정책이 아닌 오픈소스 기반의 자카르타EE 사양 프로세스(Jakarta EE Specification Process, JESP)라는 개방적이고 중립적인 정책을 따릅니다. 오라클이 자바EE 프로젝트는 이관했지만 자바 상표권은 여전히 보유하고 있기 때문에 자바 네임스페이스 사용에 제약이 있었습니다. 이러한 이유로 자카르타EE에서는 자바 네임스페이스가 Jakarta로, API 패키지명은 javax.* 에서 Jakarta.* 로 변경되었습니다. 2020년 12월 발표한 자카르타의 네임스페이스 변화는 기존 개발자들에게 다소 혼란을 줄 것으로 예상됩니다. 이와 별개로 기존 사양 중 XML Registries, XML RPC, Deployment 등 일부 관련 없는 기술들은 자카르타EE에서 사라졌습니다.

자카르타EE는 자바EE를 대체하지 않았고 둘 다 공존하고 있습니다. 자카르타EE는 자바EE 8에서 하드포크된 새로운 플랫폼으로 기존 자바EE와 호환되지 않습니다. 자바EE는 계속 유지되지만 8 버전을 마지막으로 더 이상의 릴리즈와 추가 기능은 제공되지 않고 있습니다. 개발자는 자바EE를 계속 사용할 것인지 아니면 자카르타EE로 마이그레이션 할 것인지를 선택해야 합니다. 다행히도 자카르타EE로 마이그레이션을 지원하는 도구가 제공되고 자바EE에 대한 패치도 계속 나올 것이기 때문에 당장 큰 이슈는 없을 것으로 예상됩니다.

자카르타EE의 핵심 목표는 '클라우드 네이티브 환경을 위한 엔터프라이즈 자바 기술'로 마이크로서비스, 컨테이너 등의 최신 기술 트렌드를 반영하고자 합니다. 이클립스 재단은 이전부터 마이크로서비스를 위한 표준 플랫폼으로 마이크로프로파일(MicroProfile) 프로젝트를 진행하고 있었기에 동일 선상에서 EE4J 프로젝트와 협력하고 통합할 것으로 예상됩니다. 최신 버전인 자카르타EE 9 릴리즈에는 새로운 기술 사양을 포함하고 있지 않습니다. 자카르타 네임스페이스 변경을 완료하고 관련 없는 사양을 정리하는데 중점을 두며 향후 혁신을 위한 준비를 하는 것으로 보여집니다.

👉그렇다면 스프링은?

그 전에, 스프링은 어쩌다 탄생하게 되었나?

초기의 기업들은 자바의 표준 기술로 Enterprise Java Bean을 사용했다. EJB는 트랜잭션, 분산기술, Entity Bean (ORM)등 기술을 지원하여 많은 기업들이 사용하였다. 하지만 비싸고, 어렵고, 복잡하고, 느린 단점이 있었다. EJB의 단점이 너무 심한 나머지 초기의 순수자바(POJO)를 사용하자는 이야기 까지 나왔다.

실무 개발자들이 EJB를 대신 할 오픈소스를 만들다.(Rod Johnson, Gavin King) Rod Johnson은 당시의 EJB를 비판하며 나중에 스프링을 만들어 냈고 Gavin King는 EJB의 Entity Bean의 낮은 기술 수준을 대체할 Hibernate를 만들었다. ORM기술에서 EJB가 묻히고 Hibernate의 인기가 많아지자 Hibernate를 토대로 JPA라는 자바표준 기술을 만들었다.

🔰스프링 역사

2002년 로드 존슨은 EJB의 문제점을 지적한 책을 출간했다. 그 책에는 EJB없이도 고품질의 애플리케이션 개발할 수 있다는 내용과 예제 코드를 선보였고, 그 코드에 스프링의 핵심이 되는 개념이 들어있었다. (BeanFactory, ApplicationContext, POJO, DI, IoC) 이 책이 유명해지자 개발자들이 책의 예제코드를 프로젝트에 사용하기 시작했고, Juergen Hoeller(유겐 휠러)와 Yann Caroff(얀 카로프)가 로드 존슨에게 오픈 소스 프로젝트를 제안했다. 여기서 J2EE(EJB)를 겨울로 빗대어 Spring이란 이름의 프레임워크가 탄생했다. 릴리즈

스프링 보급 초기에는 Bean 정의 파일의 비대화와 관리의 어려움이 문제가 되어 진입장벽이 높았으나,
버전 2.5 계열부터는 어노테이션을 이용해 Bean 정의 파일을 더욱 간결하게 이용할 수 있게 되었다.
또한 Config클래스로 Bean 정의를 할 수도 있다.
현재는 JavaEE에서도 XML의 Bean 정의 파일이 줄어들고 있다. 
(예전에는 bean을 등록하려면 xml파일에 정의해야 했음)

[참고하면 좋은 글]

[자바EE의 역사 및 스프링과의 관계] [[번역] Spring (1) 역사, 핵심 요소] [[스크랩] Spring & EJB 비교 (POJO란?)] [스프링 핵심 원리 1일차]

👉Core Container

스프링의 메인 아이템, Bean(객체) 공장

• 기본적으로 빈이 생성되는 방법을 관리합니다. 이곳에는 빈을 만들기 위한 빈 공장이 있다.

기본적으로 재구성할 수 있습니다. 속성, 독립성 및 컨텍스트를 설정하기 위한 파일이 실제로 메모리에 빈을 보관하는 스프링 컨테이너입니다.

👉Inversion of Control, 제어의 역전

객체의 생성 및 관리를 아웃소싱하는 접근 방식

• 객체의 생성과 관리를 외부에서 위탁처리한다는 의미입니다.

간단히 말해, 객체를 생성하고 관리하는 객체공장을 만들어서, 이곳에서 객체들을 제어하는 것이죠!

👉Dependency Inversion, 종속성 반전

클라이언트는 종속성을 제공하는 책임을 다른 개체에 호출하도록 위임합니다.

선행사항