맨위로가기

EAR (파일 포맷)

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

EAR 파일은 .ear 확장자를 사용하는 표준 JAR 파일 형식으로, 엔터프라이즈 애플리케이션을 배포하기 위한 파일 형식이다. EAR 파일은 하나 이상의 모듈과 `META-INF` 메타데이터 디렉토리를 포함하며, `application.xml`을 주요 배포 설명자로 사용한다. EAR 파일 내에는 JAR, WAR, RAR 파일 등 다양한 유형의 모듈이 포함될 수 있으며, 각 모듈은 자체적인 배포 설명자를 가질 수 있다. 대부분의 애플리케이션 서버는 EAR 파일 내의 클래스를 격리하여 애플리케이션 간의 충돌을 방지한다.

더 읽어볼만한 페이지

  • 아카이브 포맷 - ARJ
    ARJ는 다양한 소프트웨어 유틸리티에서 압축 해제가 가능한 파일 포맷으로, macOS에서는 독립 실행형 유틸리티를 통해 압축을 해제할 수 있다.
  • 아카이브 포맷 - JAR (파일 포맷)
    JAR (Java ARchive)는 자바 런타임 환경에서 애플리케이션 배포를 위해 사용되는 ZIP 기반의 파일 포맷으로, 자바 클래스 파일과 매니페스트 파일을 포함하여 메타데이터와 실행 정보를 관리하며, 압축 및 전자 서명을 지원하고 실행 가능한 JAR 파일을 통해 애플리케이션을 간편하게 실행할 수 있게 한다.
  • 자바 플랫폼, 엔터프라이즈 에디션 - IBM 웹스피어
    IBM 웹스피어는 IBM에서 출시한 기업용 소프트웨어 제품군 브랜드로, 다양한 애플리케이션 인프라, 비즈니스 프로세스 통합, 정보 통합 및 개발 도구를 포함한다.
  • 자바 플랫폼, 엔터프라이즈 에디션 - 자카르타 서버 페이지
    자카르타 서버 페이지(JSP)는 웹 애플리케이션 개발에 사용되는 서버 측 스크립팅 기술로, 서블릿으로 변환되어 실행되고 HTML 형태로 결과를 반환하며, 지시어, 스크립틀릿, 표현식, 액션 등의 문법 요소, 표현 언어(EL), JSTL을 통해 동적인 웹 페이지를 구현하고 개발 편의성을 높였다.
EAR (파일 포맷) - [IT 관련 정보]에 관한 문서
파일 포맷 정보
이름Enterprise Archive (엔터프라이즈 아카이브)
파일 확장자.ear
마임 유형해당 사항 없음
유형 코드해당 사항 없음
균일 유형 식별자해당 사항 없음
소유자썬 마이크로시스템즈
장르파일 아카이브, 데이터 압축
컨테이너 대상해당 사항 없음
포함 대상해당 사항 없음
확장 기반JAR
확장 대상해당 사항 없음
표준해당 사항 없음

2. 파일 구조

EAR 파일은 .ear 확장자를 가진 표준 JAR 파일(ZIP 파일)이며, 애플리케이션 모듈과 배치 기술자(Deployment Descriptor)를 포함하는 META-INF 디렉터리로 구성된다.

EAR 파일의 구조는 다음과 같다.

디렉터리/파일설명
META-INF/메타데이터 디렉터리. 애플리케이션 모듈 및 배치 기술자를 포함한다.
application.xmlEAR에 대한 주요 배치 기술자. EAR에 포함된 모든 모듈을 나열하고 구성 설정을 지정한다.
MANIFEST.MF아카이브에 대한 메타데이터를 제공하는 매니페스트 파일.
JAR 파일엔터프라이즈 자바빈즈(EJB) 모듈 또는 유틸리티 클래스를 포함. 각 JAR 파일은 자체 `META-INF` 디렉터리를 가질 수 있다.
WAR 파일서블릿, JSP 파일, HTML 파일 등 웹 리소스를 포함하는 웹 모듈. `WEB-INF/` 하위 디렉터리에 `web.xml` (웹 모듈 배치 기술자), `classes/` (컴파일된 Java 클래스), `lib/` (웹 모듈 사용 라이브러리 JAR 파일)을 포함한다.
RAR 파일엔터프라이즈 정보 시스템(EIS)에 연결하는 데 사용되는 리소스 어댑터를 포함.


2. 1. 모듈

EAR 파일에는 다음과 같은 유형의 모듈이 포함될 수 있다.

  • 웹 모듈은 .war 확장자를 지닌다. 하나 이상의 웹 구성 요소, 기타 리소스, 웹 애플리케이션 배치 서술자로 이루어진 배치 가능한 단위이다. 웹 모듈은 표준 웹 애플리케이션 포맷 내의 디렉터리, 파일 계층 안에 포함된다.
  • POJO 자바 클래스는 .jar 파일 안에 배치될 수 있다.
  • 엔터프라이즈 자바빈즈 모듈은 .jar 확장자를 지니며 영구적으로 배치된 클래스를 기술하는 자신만의 META-INF 디렉터리 서술자가 있다. 배치된 엔티티 빈은 다른 구성 요소에 표시되며 원격으로 내보내진 경우 원격 클라이언트에도 표시된다. 메시지 빈과 세션 빈은 원격 액세스에 사용할 수 있다.
  • 리소스 어댑터 모듈은 .rar 확장자를 지닌다.

2. 2. META-INF 디렉터리

EAR 파일은 애플리케이션 모듈을 나타내는 하나 이상의 엔트리와 하나 이상의 배치 기술자를 포함하는 `META-INF`라는 이름의 메타데이터 디렉터리를 갖는다.

`META-INF` 디렉터리는 EAR 파일에 대한 메타데이터를 포함하며, 다음과 같은 파일 및 디렉터리를 포함한다.

  • '''`MANIFEST.MF`''': 아카이브에 대한 메타데이터를 제공하는 매니페스트 파일이다.
  • '''JAR 파일''' : 엔터프라이즈 자바 빈즈 (EJB) 모듈 또는 유틸리티 클래스를 포함한다. 각 JAR 파일은 일반적으로 JAR 모듈에 특정된 배포 설명자가 있는 자체 `META-INF` 디렉터리를 가진다.
  • '''WAR 파일''' : 서블릿, JSP 파일, HTML 파일 및 기타 웹 리소스를 포함한 웹 모듈을 포함한다. 각 WAR 파일은 일반적으로 다음과 같은 구조를 가진다.
  • `WEB-INF/`
  • `web.xml`: 웹 모듈에 대한 배포 설명자이다.
  • `classes/`: 컴파일된 자바 클래스가 포함되어 있다.
  • `lib/`: 웹 모듈에서 사용하는 라이브러리 JAR 파일이 포함되어 있다.
  • '''RAR 파일''' : 일반적으로 엔터프라이즈 정보 시스템(EIS)에 연결하는 데 사용되는 리소스 어댑터를 포함한다.

2. 2. 1. application.xml

`META-INF` 디렉터리에는 최소한 자카르타 EE 배포 설명자라고 알려진 `application.xml` 배포 서술자가 포함되어 있다. 여기에는 다음의 XML 엔티티가 포함된다.

  • `icon`: 애플리케이션을 나타내는 이미지의 위치를 지정한다. `small-icon`과 `large-icon`에 대한 세부 구분이 있다.
  • `display-name`: 애플리케이션을 식별한다.
  • `description`: 애플리케이션에 대한 설명이다.
  • 아카이브의 각 모듈에 대한 `module` 요소
  • 애플리케이션의 전역 보안 역할에 대한 0개 이상의 `security-role` 요소


각 `module` 요소에는 애플리케이션 내의 개별 모듈을 설명하는 `ejb`, `web` 또는 `java` 요소가 포함되어 있다. 웹 모듈은 또한 URL로 웹 모듈을 식별하는 `context-root`를 제공한다.

자카르타 EE 배포 설명자 외에도 0개 이상의 런타임 배포 설명자가 있을 수 있다. 이는 구현별 자카르타 EE 매개변수를 구성하는 데 사용된다.

3. 클래스 로더 격리

대부분의 애플리케이션 서버는 배포된 EAR 파일에서 자바 클래스 로더의 격리된 트리 형태로 클래스를 로드하여 애플리케이션을 다른 애플리케이션과 격리시키지만, 배포된 모듈 간에는 클래스를 공유한다. 예를 들어, 배포된 WAR 파일은 포함하는 EAR 파일에도 포함된 JAR 파일에 정의된 클래스의 인스턴스를 생성할 수 있지만, 다른 EAR 파일의 JAR 파일에 있는 클래스의 인스턴스는 생성할 수 없을 수 있다. 이러한 동작의 주요 이유는 정적 싱글톤(예: Log4J)을 사용하는 애플리케이션 간의 완전한 분리를 허용하기 위함인데, 그렇지 않으면 별도의 애플리케이션 간의 구성이 혼란스러워질 수 있다. 또한 이를 통해 다양한 버전의 애플리케이션과 라이브러리를 나란히 배포할 수 있다.

JBoss 애플리케이션 서버는 버전 5 이전에는 배포된 컴포넌트를 격리하지 않는다는 점에서 주목할 만했다. 하나의 EAR 파일에 배포된 웹 애플리케이션은 다른 EAR 및 WAR 파일의 클래스에 접근할 수 있었다. 이는 다소 논란이 되는 정책이었다. ''Unified Classloader'' 디자인은 실행 중인 애플리케이션 간의 통신 오버헤드를 줄여 클래스 데이터를 참조 또는 간단한 복사본으로 공유할 수 있게 한다. 또한 개발자가 클래스로더 트리가 생성할 수 있는 문제를 이해해야 할 필요성을 줄여준다. 그러나 서로 다른 애플리케이션에 의존적인 라이브러리의 다른 버전을 배포하는 것을 방지한다. JBoss 4.0.2는 계층적 클래스로더로 전환했지만, 버전 4.0.3에서는 이전 버전과의 호환성 때문에 Unified Classloader로 되돌아갔다. 현재는 이 동작을 변경하는 구성 옵션이 있다. JBoss 5.x, 6.x 및 7.x는 더 이상 Unified Classloading을 사용하지 않는다.



본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com