👉스프링은

• 자바 어플리케이션 빌드를 위한 유명한 프레임워크
• 처음 목적은 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일차]