톰캣에 대해 공부하다 보니 계속 나오는 단어가 있었습니다. 바로 JAVA EE. 대체 JAVA EE가 뭘까요? 톰캣은 뭐고 스프링과는 어떤 관계일까요? 단순히 톰캣만 알아볼 게 아니라 이 세 친구들 간의 관계를 명확히 이해해야 각각의 역할도 확실히 알 수 있겠다는 생각이 들어 찾아보기 시작했습니다. 먼저 JAVA EE가 무엇인지 알아봅시다.
Java EE (Java Platform, Enterprise Edition)
Java EE는 기업용 애플리케이션에 필요한 기능들의 사양을 정의해둔 명세서라고 할 수 있습니다.
구체적으로는 JSP, Servlet, EJB, JDBC 등 기업용 애플리케이션을 개발하고 실행하는 데 필요한 사양들을 명시하고 있습니다. 이 사양을 각 vendor 사들이 구현하여 판매하면 개발자들은 어느 제품을 사용하더라도 새로 API를 공부하거나 OS에 따라 변경할 필요가 없는 것입니다. 이렇게 Java EE의 사양에 따라 만들어진 제품이 바로 우리가 흔히 말하는 WAS(Web Application Server)입니다. 대표적으로는 GlassFish, JBoss EAP 등의 제품이 있습니다.
Java EE 프로젝트가 오라클에서 이클립스 재단으로 이관되며 공식 명칭이 Jakarta EE로 변경되었습니다만 자세한 내용은 다루지 않겠습니다. 궁금하시면 Java EE에서 Jakarta EE로의 전환을 읽어보시길 바랍니다.
Java EE Container
위 그림을 보면 Java EE 서버가 클라이언트와 통신하는 구조를 알 수 있습니다. 그중에서도 Jave EE 서버에 있는 Web Container와 EBJ Container를 자세히 보겠습니다.
Web Container는 웹 클라이언트의 HTTP 요청을 받을 수 있고 servlet의 생명 주기를 관리하며 jsp, filter 등을 지원합니다. Java에서는 HTTP 요청을 servlet을 통해 처리하기 때문에 Servlet Container라고도 부릅니다. EJB Container가 웹 브라우저 클라이언트가 요청한 비즈니스 로직을 수행하려면 Web Container를 거쳐야 합니다.
EJB(Enterprise Java Beans) Container는 Java EE 응용 프로그램의 Enterprise Bean 실행을 관리하며 요청에 대한 비즈니스 로직을 수행합니다. 구체적으로는 bean의 생명주기를 관리하며 보안과 transaction 관리, 리소스 풀링 등의 기능을 제공합니다.
각각의 Container들이 가진 컴포넌트가 궁금하시다면 위의 Jakarta EE 의 아키텍처 다이어그램을 참고하시면 됩니다.
여기까지 이해했다면 이제 Jave EE와 톰캣, 스프링의 관계를 알아볼 차례입니다.
톰캣과 Java EE의 Web Container
⚠️ 복습
Web Container는 웹 클라이언트의 HTTP 요청을 받을 수 있고 servlet의 생명 주기를 관리하며 jsp, filter 등을 지원합니다. Java에서는 HTTP 요청을 servlet을 통해 처리하기 때문에 Servlet Container라고도 부릅니다.
보통 WAS가 무엇이냐 물으면 동적 컨텐츠를 제공하는 서버이며 그 예로는 톰캣이 있다고 대답합니다. 하지만 톰캣은 온전한 WAS라고 할 수 없습니다. Java EE를 완전히 구현한 것이 WAS인데, 톰캣은 Java EE 중에서도 Web Container만 구현하고 있기 때문입니다.
Java EE에서 Web Container를 구현한 것이 톰켓입니다. 따라서 톰캣은 온전한 WAS가 아니며 HTTP 요청을 Servlet을 통해 관리합니다.
스프링과 Java EE의 EJB Container
⚠️ 복습
EJB(Enterprise Java Beans) Container는 Java EE 응용 프로그램의 Enterprise Bean 실행을 관리하며 요청에 대한 비즈니스 로직을 수행합니다. 즉 비즈니스 객체들을 Bean으로 관리할 수 있는 기능에 대한 스펙을 지정한 것입니다.
스프링과 EJB Container의 관계를 설명하려면, 먼저 EJB의 과거에 대해 알아보아야 합니다.
처음엔 EJB가 제공하는 다양한 기능들 덕에 EJB가 많이 사용되었습니다. 하지만 EJB는 실제 사용할 때 불편한 점들이 너무 많았습니다. EJB를 사용하려면 제공하는 API를 상속 받아야만 했고, 그에 따른 부가적인 코드를 작성해야 하는 등의 불편함이 있었습니다. 뿐만 아니라 vendor 사마다 EJB를 구현한 내용이 달라 다른 vendor 사의 제품으로의 변경도 어려웠습니다. 미들웨어 제품에 대한 종속성을 벗어나기 위해 Java EE가 만들어졌는데, 이제는 특정 Jave EE 제품에 종속되어버리게 된 것입니다.
이러한 단점때문에 개발자들은 Java EE와 같은 환경과 기술의 종속에서 벗어나 POJO(Plain Old Java Object) 방식 즉, 특정 클래스를 상속하거나 인터페이스를 구현하지 않는 가벼운 객체를 원하게 되었습니다. 이런 수요로 인해 Java EE를 개선하여 탄생한 것이 스프링입니다.
스프링은 더이상 비싸고 무거운 Java EE 서버를 사용하지 않아도 주요 기능들을 사용할 수 있게 만들었습니다. 이제 Java EE가 아닌 톰캣과 같은 가벼운 일반 Servlet Container와 함께 사용할 수 있게 되었죠. 스프링이라는 이름도 이전의 EJB 시절을 겨울에 비유하여 새로운 봄이 온다는 의미에서 지어진 것입니다.
이렇듯 스프링은 POJO 방식의 프로그래밍을 지향하면서 적용한 기술이나 메서드가 구현하는 코드에 직접 반영되지 않는 비침투적인(non-invasive) 기술을 사용합니다. 이 비침투적인 기술을 위한 스프링의 핵심 기능이 바로 IoC/DI(Inversion of Control/Dependency Injection), AOP(Aspect Oriented Programimg), PSA(Portable Service Abstraction)인 것입니다.
결론
- Java EE는 기업용 어플리케이션에 필요한 기능들의 사양을 정의해둔 명세서이다.
- Java EE에서 Web Container를 구현한 것이 톰캣입니다. 따라서 톰캣은 온전한 WAS가 아니며 HTTP 요청을 Servlet을 통해 관리합니다.
- Java EE의 단점을 개선하여 탄생한 것이 스프링입니다. 스프링은 POJO 방식의 프로그래밍을 지향하며 비침투적인 기술을 지향합니다.
References
Apache HTTP Server? Apache Tomcat? 서버 바로 알기