자바EE, Spring

자바SE - 자바 플랫폼 스탠더드 에디션(Java Platform, Standard Edition, 약자 Java SE)는 데스크톱 및 서버, 최근의 고사양 임베디드 시스템을 위한 표준 자바 플랫폼으로 표준적인 컴퓨팅 환경을 지원하기 위한 자바 가상 머신 규격 및 API 집합을 포함한다. 따라서 자바 EE, 자바 ME 등 다른 플랫폼은 구체적인 목적에 따라 자바 SE를 기반으로 API를 추가하거나 자바 가상 머신 규격 및 API의 일부를 택해서 정의된다.

자바EE[1][2] - 자바 플랫폼, 엔터프라이즈 에디션(Java Platform, Enterprise Edition; Java EE)은 자바를 이용한 서버측 개발을 위한 플랫폼이다. Java EE 플랫폼은 PC에서 동작하는 표준 플랫폼인 Java SE에 부가하여, 웹 애플리케이션 서버에서 동작하는 장애복구 및 분산 멀티티어를 제공하는 자바 소프트웨어의 기능을 추가한 서버를 위한 플랫폼이다. 이전에는 J2EE라 불리었으나 버전 5.0 이후로 Java EE로 개칭되었다.
이러한 Java EE 스펙에 따라 제품으로 구현한 것을 웹 애플리케이션 서버 또는 WAS라 불린다. (웹 애플리케이션 서버는 대부분이 자바 기반으로 주로 자바 EE 표준을 수용하고 있으나, 자바 기반이지만 자바 EE 표준을 따르지 않는 제품과 .NET이나 Citrix 기반인 비 자바 계열도 존재한다.)

Java EE 표준기반 웹 애플리케이션에서 동작하는 프로그램 언어는 자바이다. 일반적으로 웹 모듈은 자바 서블릿 또는 JSP(Java Server Page)로 구성하고, 비즈니스 모듈은 EJB(Enterprise Java Beans)로 구성한다.

Sevlet과 JSP - 서블릿이나 JSP나 만드는 방법에 차이가 있을 뿐 동일한 역할을 한다.
Servlet - Java코드 안에 HTML 코드 (하나의 클래스)
JSP - HTML 코드 안에 Java코드

EJB(Enterprise Java Beans) - 엔터프라이즈 자바빈즈(Enterprise JavaBeans; EJB)는 기업환경의 시스템을 구현하기 위한 서버측 컴포넌트 모델이다. 즉, EJB는 애플리케이션의 업무 로직을 가지고 있는 서버 애플리케이션이다. EJB 사양은 Java EE의 자바 API 중 하나로, 주로 웹 시스템에서 JSP는 화면 로직을 처리하고, EJB는 업무 로직을 처리하는 역할을 한다.

EJB에는 다음 3가지 종류가 있다.

• 세션 빈 (Session Bean) : DB 연동이 필요 없음
• 엔티티 빈 (Entity Bean)
  • 데이터베이스의 데이터를 관리하는 객체
  • Insert(삽입), Update(수정), Delete(삭제), Select(조회)
  • DB 관련 쿼리는 자동으로 만들어지고 개발자는 고급 업무 처리에 집중할 수 있음
  • DB가 수정되면 코드 수정 없이 다시 배포(설정 문서 만들어서 복사)
• 메시지 구동 빈 (Message-driven Bean) : JMS로 빈을 날려줌

JSF(Java Server Faces)[1][2] - 자바서버 페이스(JavaServer Faces, JSF)는 자바 EE기반 애플리케이션을 개발하는 데 있어, UI를 개발하기 쉽게 하는 자바 기반의 웹 애플리케이션 프레임워크이다. 기존의 MVC 기반 프레임워크와는 달리 컴포넌트 기반이다. JSF는 기존의 HTML을 컴포넌트화하고, 클라이언트의 상태를 서버에서 관리하며, 브라우저에서 발생한 이벤트를 서버가 제어할 수 있도록 하여 스윙 스타일의 객체지향 웹 애플리케이션 개발이 가능하게 한다. JSF는 잘 정의된 MVC 구조를 갖고 있고 그 중에서 뷰의 기능이 탁월한 프레임워크이다. JSF를 사용함으로써 다음과 같은 EoD(Easy of Development)를 얻을 수 있다. 

• 재사용성 가능한 UI 컴포넌트로 UI 작성의 편리성
• UI와 애플리케이션 데이터간의 데이터 변환이 용이함
• 서버 리퀘스트를 통해 UI 상태를 서버에서 관리
• 클라이언트가 발생시킨 이벤트를 서버 애플리케이션 코드가 관리하는 모델 제공
• Custom UI 컴포넌트 개발의 용이성

국내에선 자바EE의 인기가 떨어지면서 함께 외면 받았지만 해외에선 자바 웹 개발의 표준 기술로 쓰였다.

JSP 모델1과 모델2, 그리고 MVC 패턴

톰캣과 아파치

JAR, WAR, EAR -
The Java Archive (JAR) file format is based on the ZIP file format and enables you to bundle multiple Java EE components into a single file. A JAR file can contain Java class files, XML descriptor files, auxiliary resources, static HTML files, and other files associated with each Java EE component. A standard Java Web application is deployed in a Web Application Archive (WAR) file, which is a JAR file with the extension of .war. A standard Java EE application is deployed in an Enterprise Application Archive (EAR) file, which is a JAR file with an extension of .ear.

WAR file is a specialized JAR file containing Web application components such as servlets, JSP files, HTML files, deployment descriptors, utility JAR files, etc. A WAR file can be deployed to a Web server such as Tomcat.

An EAR file is a specialized JAR file containing Java EE application components such as Web applications (WAR files), EJBs, resource adapters, etc. An EAR file can be deployed to a Java EE application server such as JBoss, WebLogic, or WebSphere. Java EE application servers load EAR files at runtime and deploy the components found within each file as Web applications, resource adapters, EJBs, and so on, based on the instructions found in each component's deployment descriptor.

웹서버, 애플리케이션 서버, 웹(서블릿) 컨테이너[1][2] -
웹 서버는 정적인 페이지(HTML, CSS)를 제공하는 서버를 의미한다. 아파치와 IIS는 두 가지의 유명한 웹 서버이다.
애플리케이션 서버는 서버 사이드 코드를 이용하여 동적인 컨텐츠를 만드는 서버를 의미한다. 자바 EE 세상에서는 애플리케이션 서버로 유명한 것들은 IBM WebSphere, Oracle WebLogic, Glassfish, JBoss 이다.
서블릿 엔진 혹은 웹 컨테이너 (서블릿 컨테이너로 잘 알려진)는 서블릿과 JSP를 위한 런타임 환경을 제공하지만 애플리케이션 서버의 필수적이라고 할 수 있는 EJB 같은 기술이 적용되어 있지 않다. 웹 컨테이너와 서블릿 엔진으로는 아파치 톰캣과 제티가 유명하다. (톰캣을 WAS로 부르기도 한다.)

전자정부프레임워크 서버 환경 구성 - 윈도우, 유닉스 아파치 톰캣 설치

 

자바EE의 역사 및 스프링과의 관계 -

자바는 본래 자바 애플릿 등의 클라이언트 GUI 

-> 자바의 플랫폼 독립적 특성을 활용해서 미들웨어에 필요한 공통 API 제공 시도 

-> J2EE(J2EE 5.0 이후로 Java EE) 표준 탄생

-> 자바EE 어플리케이션 서버(WAS) 시작

-> [문제와 비판]

    -실무와 거리 있는 아키텍트들이 실용성보다 API의 모양새나 플랫폼 독립성이라는 자바의 특성만을 강조한 설계를 하다보니 실제 사용 불편 (예) ORM 기능 누락으로 벤더사마다 다른 구현)

    -산출물 배포를 위한 상단한 분량의 XML 설정 작성

 

-> 스프링 프레임워크는 이러한 문제점을 개선하기 위해 처음 개발되었고, 특히 고가의 풀스택(full stack) 자바EE 서버가 아닌 탐캣(Tomcat)과 같은 일반 서블릿 컨테이너에서도 구동 된다는 것이 큰 강점으로 작용했습니다.

 

원래 탐캣은 자바EE 표준의 일부인 서블릿 기술의 참조 구현(reference implementation)으로 출발했습니다. 즉, 원래의 용도는 실제 서비스에 사용하기 보다는 서블릿이나 JSP라는 기술이 이런 것이라는 것을 보여 주기 위한 용도로 쓰였는데, 점차 성능이나 안정성이 개선되면서 이 시점에는 이미 실무에서 사용해도 문제없는 수준으로 발전하게 된 것입니다.

 

다시 말하면, 이는 스프링을 통해 비싼 자바EE 서버를 구매하지 않아도 EJB보다 훨씬 간편한 방식으로 EJB가 제공하던 선언적 트랜잭션 및 보안 처리, 분산 환경 지원 등 주요 기능을 모두 사용할 수 있게 되었음을 뜻하며, 무엇보다 이제는 더 이상 각 자바EE 서버 제품에 특화된 설정을 따로 공부하거나 서버 제품을 바꿀 때마다 포팅 작업이 필요없이 스프링만 이용하면 탐캣이든 레진(Resin)이든 기존의 풀스택 자바EE 서버이든 관계없이 간단하게 배포가 가능하다는 뜻이었습니다.