부트01 개발 환경의 변화와 자바
개발환경의 변화와 자바
알림 - 이 문서는 제이펍 출판사가 출판하고 윤석진 작가가 지은 “스프링 부트로 배우는 자바 웹 개발” 이라는 책의 내용을 학습하고 기록을 남기는 문서임을 알립니다.
1. 인프라와 스프링 프레임워크의 변화
인프라 아키텍처의 변화
- 메인프레임
- 최초의 서버/클라이언트 구조는 메인프레임 컴퓨터에 특정 인원만 접속할 수 있는 구조로 주로 사내에서 인트라넷으로 사용하였다.
- 서버/클라이언트
- 웹이 활성화 되고 닷컴 열풍이 불자 서버/클라이언트 구조는 B2C(Business-to-Customer)로 트렌드가 변화되었다.
- 이 시기에는 서버에서 파일로 데이터를 저장하거나 자체 개발을 통해 데이터를 저장하고 소켓 통신을 통해 클라이언트와 통신하였다.
- 데이터베이스와 웹 서버
- 전자 상거래가 활성화 되고, 웹의 흥행하면서 데이터베이스와 웹서버를 사용한 아키텍처가 주류를 이루게 되었다.
- 이 시기에는 데이터베이스에 저장되어 있는 데이터를 JSP, PHP, ASP와 같은 서버 언어로 데이터를 전달하고 클라이언트에서 전달받은 데이터를 처리하는 방식이 자리를 잡았다.
- 클라우드
- 사용자 이용폭이 큰 서비스를 제공하고자 하면 물리장비를 사용하기 부담스러울 때가 있다. 이럴때 클라우드 서비스를 활용하기도 한다.
- 하지만 클라우드는 클라우드 업체에 기술이 종속되고 임의로 증설하거나 변경하는 것이 어렵다는 단점이 있다.
스프링 프레임워크의 변화
- EJB(Enterprise JavaBean)
- 초기에는 오라클의 웹로직이나 IBM의 웹스피어와 같은 서버를 사용하고, 개발할 때는 EJB를 이용하여 개발을 진행하였다.
- Spring Framework
- EJB는 세션빈(SessionBean), 엔티티빈(EntityBean)과 같은 요소들을 설정해야했고, 스프링에 비해서 테스트하기 어렵고 무거웠다.
- 스프링프레임워크는 로드 존슨이 2002년에 출판한 저서인 (Expert One-on-One J2EE Design and Developement)에서 선보인 코드에서 부터 점점 발전하여 2.5버전 이후로 안정화 되면서 웹로직, 웹스피어 서버에 스프링 기반의 프로젝트가 증가하였다.
- 전자정부 프레임워크에서도 기반 기술로 스프링 프레임워크를 채택하면서 스프링 프레임워크와 톰캣 조합이 표준처럼 쓰이게 되었다.
- Spring Boot
- 최근 스타트업은 작은 규모로 빠르게 서비스를 런칭하기 위해 루비온레일즈(RubyOnRails)나 장고(Django)를 사용하는 것을 선호하다. 해당 기술은 톰캣과 같은 별도의 애플리케이션 서버 설치 없이 웹 서버만으로 클라우드 서비스를 이용해 쉽게 확장할 수 있으며 개발도 스켈레톤을 제공해주므로 빠르게 시작할 수 있다.
- 스프링도 EJB에 비해서는 가볍고 설정의 부담이 줄어들었지만 시간이 지나고 나니 다른 언어의 프레임워크에 비해 무겁고 설정할 것이 많은 프레임워크가 되었다.
- 스프링 부트는 설장 자동화를 이용해서 웹 개발을 하는데 필요한 인프라성 코드를 제공해주므로써 빠르게 개발을 시작할 수 있다. 또한 클라우드 환경에서도 별도의 작업 없이 스프링 부트를 이용하면 시간을 많이 단축할 수 있다.
2. 웹 애플리케이션 컨테이너
웹 서버 : HTML과 같은 정적 파일들을 전달해 주는 역할을 하는 서버
웹 애플리케이션 서버(WAS): PHP, JSP, ASP와 같은 언어들을 사용해서 동적인 페이지들을 가능한 서버, 자바진영에서는 웹 애플리케이션 컨테이너라고도 한다.
자바 개발을 위해 꼭 필요한 클래스 로더
- WAS가 어떻게 웹 애플리케이션을 인식하고 동작시키는지 알기 위해서는 클래스 로더를 알아야 한다.
- 자바 코드를 작성한 후 컴파일하면 해당 코드는 JVM(Java Virtual Machine)에서 실행 가능한 상태가 된다. 이때 JVM이 클래스를 실행하기 위해서는 클래스를 로딩하는 과정이 필요하다. 그 과정을 수행해 주는 역할을 하는 것이 클래스 로더다.
- 클래스 로더의 특징
- 구조가 계층적이다. 상위 클래스 로더에서 하위 클래스 로더를 갖는 방식이다. 최상위 클래스 로더는 부트스트랩 클래스 로더이다.
- 클래스 로딩을 위임할 수 있다.
- 자식 클래스 로더는 클래스 위임을 통해 부모 클래스 로더가 로딩한 클래스를 찾을 수 있지만, 부모 클래스 로더는 자식 클래스 로더가 로딩한 클래스를 알 수 없다.
- 클래스 로더로 로딩한 클래스들을 언로딩할 수 없다. 클래스 로더가 로딩한 클래스를 언로딩할 수 없으므로 가비지 컬렉터가 동작하거나 WAS가 재시작할 때 초기화 된다.
- 클래스 로더의 네가지 유형
- 부트스트랩 클래스 로더(bootstrap class loader)
- 확장 클래스 로더(extension class loader)
- 시스템 클래스 로더(system class loader)
- 사용자 정의 클래스 로더(user-defined class loader)
- 부트스트랩 클래스 로더는 JVM 런타임 실행을 위해 기반이 되는 파일들을 로드한다.
- 부트스트랩 클래스로더가 로딩이 끝나면 확장 클래스 로더가 자바의 최상위 객체인 Object를 포함한 자바 API를 로드한다.
- 확장 로더의 로드가 끝나면 시스템 클래스 로더가 클래스 패스에 포함된 클래스들을 로드한다.
- 사용자는 시스템 클래스 로더가 로드하는 클래스 패스 영역에만 접근할 수 있다. 보통 독립적인 영역이 필요한 WAS의 경우에는 시스템 클래스 로더 하위에 사용자 정의 로더를 만들어서 사용한다. 대부분의 문서에서 톰캣 설치 위치를 CATALINA_HOME으로 지정하는 것은 WAS에서 생성한 클래스 로더를 기준으로 동작하기 위함이다.
3. WAR 파일의 특성
WAR는 압축 파일에 자바 관련 규약이 포함된 것이다. 직관적으로 보면 WAR는 WEB-INF 디렉토리 구조를 말한다. 웹 애플리케이션 컨테이너는 WAR 파일의 WEB-INF 폴더를 기준으로 클래스 파일들을 로드한다.
- WAR 파일 디렉토리 구조 ```
- web Archive
- content directory : html js css
- WEB-INF : web.xml
- classes : java
- libs : jar ```
- WEB-INF : web.xml
- content direcotry
- content directory는 webapp 또는 web과 같은 이름으로 프로젝트 설정에 따라서 조금식 다르지만, HTML, 자바스크립트(javaScript), CSS 또는 HTML 태그를 포함하고 있는 JSP 파일처럼 브라우저에서 보여 줘야하는 정적 자원을 관리하기 위한 디렉토리이다.
- contents directory 디렉토리는 브라우저 상에서 직접 접근할 수 있기 때문에 최근에는 이 디렉토리를 WAR 파일의 상위에 두지 않고 WEB-INF 하위에 설정하고 있다.
- WEB-INF
- WAR로 패키징하면 클래스 파일들은 WEB-INF 하위 classes 디렉토리에 저장된다.
- libs 디렉토리에는 JAR 형식의 외부 라이브러리들이 있다. 이 JAR 파일들은 사용자 정의 클래스 로더, 웹 애플리케이션 컨테이너 로더를 통해 클래스 패스에 추가된다.
- 웹 어플리케이션 클래스 로더
- 웹 애플리케이션 클래스 로더는 클래스 로더의 유형 중에서 시스템 클래스 로더 하위에 사용자가 정의한 클래스 로더에 해당한다.
- 웹 애플리케이션 컨테이너는 웹 애플리케이션 자체 API를 제공하기 위해 컨테이너를 로드하는 클래스 로더와 사용자가 추가한 JSP나 WAR 파일들ㅇ르 다루기 위한 ServletContext Loader를 사용한다.
- 컨테이너가 시작되고 콘텍스트가 초기화되면 서블릿 스펙의 권장 사항에 따라 WEB-INF/classes 파일을 먼저 검색해서 로딩하고, 그 후에 WEB-INF/libs에 있는 JAR 파일들을 로드한다.
- content directory : html js css