대강 살펴보는 자바부터 스프링부트까지의 역사
세미나로 진행한 내용을 발표 스크립트와 함께 작성한 내용 입니다.
많은 내용들을 축약하다보니 다소 정확하지 않은 내용이 포함되어 있을 수 있습니다.
설명의 흐름을 위해 연도 상관 없이 넣은 설명들이 있습니다. 보통 이런 애들은 연도를 따로 쓰지 않았습니다.
1991년 제임스 고슬링이 만들었습니다. 당시 썬 마이크로시스템즈 다녔고, 2010년에 오라클에 썬마이크로시스템즈가 인수 합병되었습니다. 그래서 요즘 오라클 사이트 들어가서 jdk 받거나 하게 된 겁니다.
PHP, ASP, 펄 스크립트, C, 파이썬 등으로 CGI를 구현할 수 있습니다. 자바로도 구현 가능합니다. 일종의 스펙이므로 언어 무관하게 구현 가능합니다. 다만 단점은 요청 마다 새로운 프로세스를 생성하고, DB connection을 새로 여는 방식 입니다.
HttpServlet을 상속받아 구현해두고, web.xml에 등록해두면 요청이 들어올 시 doPost()나 doGet()에 구현된 내용을 실행해 그 결과를 리턴해주는 방식으로 동적으로 작동하는 웹 컴포넌트를 만든 것 입니다. CGI와 달리 요청 시 스레드를 생성합니다. 그리고 JVM위에서 동작 합니다.
서블릿으로 웹 서비스 구현 시 톰캣처럼 서블릿을 지원하는 서블릿 컨테이너를 사용합니다. 서블릿 컨테이너는 서블릿 생명주기를 관리해주고, 통신이나 보안, 멀티스레드 관리 등을 해주는 녀석입니다. front controlle를 둠으로써 HttpServlet에 대한 의존성을 없앨 수 있고, 저게 생김으로 인해 이제 매번 등록하는 과정 없이 그냥 @Controller 같은걸로 개발이 가능해진 것입니다.
기존엔 모든 로직이 HttpServlet을 상속받아 구현 후 하나씩 등록해야 했다면, 프론트 컨트롤러 방식을 사용하면 프론트 컨트롤러만 HttpServlet을 상속받으면 됩니다. 내부 로직은 if로 분기치는 식으로 정의하면 됩니다.
디스패쳐 서블릿이 web.xml에 매번 등록하는 과정을 개선하기 위한 것이라면, 이번엔 코드 개발 시의 문제점을 해결하기 위한 개선점 입니다. JSP는 결국 Servlet으로 변환되므로 하는 일 자체는 Servlet과 동일합니다. 하지만 java에 html을 넣냐, html에 java를 넣냐 그 차이입니다.
그래서 비즈니스 로직이 세는걸 막기 위해 JSP를 쓰더라도, JSP에 자바코드를 넣는건 지양해야 합니다. 그리고 JSP는 war로 빌드해야 하지만, 타임리프는 jar로 컴파일해도 됩니다.
CGI는 매번 새로운 DB connectio을 맺어야 한다고 했습니다. 근데 DB 연결은 비용이 큰 연산입니다. 그러니 미리 어느정도 DB connectio을 맺어놓고 그걸 돌려쓰자는게 Connection Pool 입니다. 이걸로 거의 PHP랑 비슷한 성능까지 쫒아갑니다. 예~~전에 혹시 이클립스를 써봤다면 스프링 배울 때 이클립스 EE 버전도 저 Java EE를 지원하는 것 입니다. Java SE가 기본적인 자바 언어의 대부분이 포함된 에디션이라면, EE는 그 위에 당시 웹 프로그래밍에 필요한 기능을 다수 포함한 에디션 입니다.
요즘 스프링부트를 표준처럼 쓰는 것 처럼, 당시엔 EJB를 표준처럼 써야 했다고 합니다.
POJO는 좋은 거긴한데, 어쨌든 J2EE같은 프레임워크가 필요하긴 했습니다. 그러다보니 POJO 기반의 프레임워크들이 나오기 시작합니다.
우선 DB 쪽을 살펴보면 하이버네이트가 있었습니다.
JPA랑 Spring Data JPA랑 다른거긴 합니다. 그러니 그냥 둘 다 JPA라고 할 때도 머리속으론 알고 있어야 구분이 됩니다. Hibernate 부분엔 JPA 구현체 어떤걸 넣어도 됩니다. EclipseLink, OpenJPA 등이 있습니다.
그러니 스프링부트로 프로젝트를 진행하면서 외부 톰캣에 올리는건 스프링부트의 시작에 반하는 행동이긴 합니다.
