[토비의 스프링 3.1] Vol.1 스프링의 이해와 원리 - 스프링 프로젝트 시작하기 (1)

9.1) 자바 엔터프라이즈 플랫폼과 스프링 애플리케이션

스프링 애플리케이션의 종류

• 스프링으로 만들 수 있는 애플리케이션의 종류에는 제한이 없다.
  
  1. 자바 언어를 사용하는 모든 종류의 프로젝트라면 어디든 사용할 수 있다.
  2. 웹을 이용하는 자바 엔터프라이즈 시스템, 스윙이나 이클립스 RCP로 만드는 독립형 프로그램에도 적용 가능하다.
     
  3. 또한 애플릿이나 모바일 애플리케이션 개발,
     스프링을 핵심 엔진으로 사용하는 엔터프라이즈 미들웨어 제품에도 이용할 수 있다.
• 그러나 스프링의 탄생 배경이나 스프링이 주로 제공하는 기능의 목록을 볼 때
  스프링은 주로 자바 엔터프라이즈 환경에서 동작하는 애플리케이션을 개발하는 목적으로 사용된다.
• 자바 엔터프라이즈 애플리케이션은 서버에서 동작하며 클라이언트를 상대로 서비스를 제공하도록 되어 있다.
  즉 클라이언트의 요청을 받아서 그에 대한 작업을 수행하고 그 결과를 돌려주는 것이 기본적인 동작 방식이다.
  하지만 클라이언트의 요청 없이도 정해진 시간이나 특정 이벤트 발생에 따라 독자적으로 작업을 수행하기도 한다.

클라이언트와 백엔드 시스템

• 엔터프라이즈 애플리케이션은 클라이언트가 될 수 있고 백엔드 시스템도 될 수 있다.
  1. 엔터프라이즈 애플리케이션은 자신이 클라이언트가 돼서 또 다른 엔터프라이즈 시스템에 서비스를 요청할 수도 있다.
  2. 또는 데이터베이스나 레거시 시스템 같은 엔터프라이즈 정보 시스템이라고
     불리는 백엔드 시스템의 기능을 이용해 동작하기도 한다.
  3. 가장 많이 사용되는 구조는 클라이언트가 웹 브라우저이고 백엔드 시스템이 DB인 구성이다.
     간단히 DB를 사용하는 웹 애플리케이션이라고 하며 스프링이 사용하는 애플리케이션의 기본 구조라고 생각할 수도 있다.
  4. 그렇다고 해서 꼭 클라이언트는 웹 브라우저여야 하며 백엔드 시스템은 DB를 이용해야 하는 것은 아니다.
     자바 서버가 받아들일 수 있는 방식으로 요청을 보내기만 한다면 어떤 종류의 클라이언트이든 상관없다.
  5. 백엔드 시스템 또한 DB는 물론이고 메시징 서버, 메일 서버, 메인프레임도 가능하다.
     자바가 제공하는 접속 방식을 지원하는 시스템이면 된다.
  6. 하나의 스프링 애플리케이션이 동시에 여러 종류의 클라이언트를 상대로 서비스를 제공할 수도 있으며
     당연히 한 번에 여러 종류의 백엔드 시스템을 이용할 수 있다. 여러 개의 DB를 동시에 이용하는 것도 가능하다.

애플리케이션 서버

• 스프링으로 만든 애플리케이션을 자바 서버환경에서 배포하려면 JavaEE 서버가 필요하다.
  1. JavaEE 표준을 따르는 애플리케이션 서버는 크게 두 가지로 구분할 수 있다.
  2. 하나는 JavaEE의 대부분의 표준 기술을 지원하고
     다양한 형태의 모듈로 배포가 가능한 완전한 웹 애플리케이션 서버 WAS이다.
  3. 다른 하나는 웹 모듈의 배포만 가능한 경량급 WAS 또는 서블릿 JSP 컨테이너다. 
• 웹 모듈의 배포만 가능한 경량급 WAS 또는 서블릿 JSP 컨테이너
  1. 스프링은 기본적으로 Tomcat이나 Jetty 같은 가벼운 서블릿 컨테이너만 있어도 충분하다.
  2. EJB나 리소스 커넥터, WAS가 제공하는 분산 서비스 등이 굳이 필요하지 않다면
     서블릿 컨테이너로도 엔터프라이즈 애플리케이션에 필요한 핵심기능을 모두 이용할 수 있다.
• JavaEE의 대부분의 표준 기술을 지원하고 다양한 형태의 모듈로 배포가 가능한 완전한 웹 애플리케이션 서버 WAS
  1. 고가의 WAS를 사용하면 성능 면에서 미션 크리티컬한 시스템에서 요구하는
     고도의 안정성이나 고성능 시스템에서 필수적인 안정적인 리소스 관리, 레거시 시스템의 연동이나
     기존 EJB로 개발된 모듈을 함께 사용하는 등의 필요가 있다면 상용 또는 오픈소스 WAS를 이용할 수 있다.
  2. 또 WAS는 상대적으로 관리 기능이나 모니터링 기능이 뛰어나서 여러 대의 서버를 동시에 운영할 때 유리한 점이 많다.
  3. 무엇보다도 자바 엔터프라이즈 버전 표준을 최대한 활용할 수 있다.
• 스프링 개발팀은 필요할 때는 비용을 들이더라도 적합한 조건을 가진 WAS를 사용할 것을 권장한다.
  1. 물론 WAS를 사용할 때는 분명한 이유와 근거가 있는지 먼저 충분히 검토해야 한다.
  2. 훨씬 가볍고 빠르며 저렴한 비용으로 사용할 수 있는 서블릿 컨테이너로도 대개는 충분한데
     특별한 이유도 없이 무겁고 다루기 힘든데다 비싸기까지 한 WAS를 사용할 필요는 없다.
• 실제로 개발환경과 운영환경에서 가장 많이 사용되는 자바 서버는 웹 모듈만 지원하는 서블릿 컨테이너인 아파치 톰캣이다.
  1. 스프링 개발을 책임지고 있는 기업인 스프링소스는
     톰캣을 기반으로 엔터프라이즈 스프링 애플리케이션에 최적화된 경량급 애플리케이션 서버인 tcService를 개발했다.
  2. tcServer를 이용하면 기존 톰캣에서는 아쉬웠던 고급 서버 관리 기능, 배포 기능과 진단 기능을 포함해서
     톰캣 전문가에게 받는 기술지원도 함께 제공받을 수 있다.
  3. 대부분의 기능을 사용하지도 않을 고급 WAS를 구매하는데 비싼 비용을 들이기는 부담스럽고,
     그렇다고 운영하고 관리하기 불편한데다 필요할 때 기술지원도 받을 길이 없는
     오픈소스 제품인 톰캣을 그대로 사용하기는 불안하다면 tcServer가 좋은 대안이다.
  4. tcServer는 스프링의 개발회사가 개발하는 것인 만큼
     스프링 애플리케이션 개발과 운영에 꼭 필요한 중요한 기능이 많이 제공된다.

스프링 애플리케이션의 배포 단위

• 스프링으로 만든 애플리케이션은 세 가지 단위로 배포할 수 있다.
  1. 독립 웹 모듈
  2. 엔터프라이즈 애플리케이션
  3. 백그라운드 서비스 모듈
• 스프링은 보통 war로 패키징된 독립 웹 모듈로 배포된다.
  1. 톰캣 같은 서블릿 컨테이너를 쓴다면 독립 웹 모듈이 유일한 방법이다.
  2. WAS로 배포한다고 하더라도 독립 웹 모듈을 사용하는 경우가 대부분일 것이다.
  3. 여러 개의 웹 모듈을 묶어서 하나의 웹 애플리케이션 모듈로 만들지 않는 한
     독립 웹 모듈이 가장 단순하고 편리한 배포 단위다.
• 경우에 따라선 확장자가 ear인 엔터프라이즈 애플리케이션으로 패키징해서 배포할 수도 있다.
  1. 스프링 애플리케이션에서 EJB 모듈을 긴밀하게 사용하거나
     반대로 EJB 모듈에서 스프링으로 만든 애플리케이션을 이용해야 한다면
     EJB와 스프링 웹 모듈을 엔터프라이즈 애플리케이션으로 통합해야 한다.
  2. 때로는 EJB 모듈은 없지만 엔터프라이즈 애플리케이션 배포 방식을 선택하는 경우도 있다.
  3. 하나 이상의 웹 모듈과 별도로 분리된 공유 가능한 스프링 컨텍스트를 엔터프라이즈 애플리케이션으로 묶어주는 방법이다.
• 이 두 가지 방법 외에도 스프링으로 만든 애플리케이션이 UI를 가질 필요는 없고
  서버 내에서 백그라운드 서비스처럼 동작할 필요가 있을 때 사용하는 rar 패키징 방법도 있다. 
  1. rar는 리소스 커넥터를 만들어 배포할 때 사용하는 방식이다.
  2. 이때 J2EE 1.4나 그 이상의 표준을 따르는 WAS가 반드시 필요하다.
• 운영 플랫폼이나 서버의 종류는 개발 중에라도 언제든지 필요에 따라 변경이 가능하다.
  1. 어차피 서블릿 컨테이너나 웹 모듈 모두 JavaEE 표준의 일부일 뿐이기 때문에 설정만 바꾸면 이전이 가능하다.
  2. 다만 특정 서버환경에서만 제공하는 기능을 사용한다면 변경이 힘들 수 있다.
  3. 그러므로 장기적으로 서버를 변경하거나 서버의 종류를 바꿀 가능성이 있다면
     서버의 기능에 종속되지 않도록 주의하거나 손쉽게 다른 서버의 기능으로 변경 가능하도록 추상화해서 사용해야 한다.