Java EE는 실제로 무엇입니까? [닫은]

Java EE는 어린 Java 개발자를 위해이 "신비한 수의"를 가지고 있습니다.이 덮개는 제가 거의 성공하지 못한 채 꽤 오랫동안 제 자신을 들어올 리려고 노력해 왔습니다.

혼란은 다음에서 발생합니다.

• Java EE는 라이브러리이자 플랫폼 인 것 같습니다. 일반적으로 Oracle의 Java EE SDK 다운로드와 같은 방법으로 Java EE 라이브러리를 "가져 오는"여러 방법이 있습니다. 그러나 Java EE 라이브러리는 코드가 Java EE 응용 프로그램 서버 (예 : JBoss, GlassFish, Tomcat 등)에서 실행 중이거나 액세스 권한이없는 경우 작동하지 않으며 컴파일되지 않습니다. 왜? 라이브러리가 애플리케이션 서버 환경 외부에서 작동 할 수 없습니까? 이메일을 보내기 위해 간단한 코드를 컴파일하기 위해 JBoss처럼 거대한 것이 필요한 이유는 무엇입니까?

• Java EE 라이브러리가 "표준"이 아니며 일반 JVM 다운로드 및 / 또는 SDK에 포함 된 이유는 무엇입니까?

• 표준 Java (Oracle JVM / SDK | OpenJDK JVM / JDK)의 두 가지 주요 특징 만 있는데 왜 그렇게 많은 Java EE 제품이 있습니까?

• 표준 Java로는 할 수없는 Java EE로 무엇을 할 수 있습니까?

• Java EE로 할 수없는 표준 Java로 무엇을 할 수 있습니까?

• 개발자는 언제 Java EE가 "필요"하다고 결정합니까?

• 개발자는 언제 Java EE가 필요하지 않다고 결정합니까?

• Java EE 라이브러리 버전이 표준 Java 라이브러리 릴리스 (Java EE 6 대 Java 7)와 동기화되지 않는 이유는 무엇입니까?

플로그 정리를 도와 주셔서 감사합니다!

라이브러리가 애플리케이션 서버 환경 외부에서 작동하지 않는 이유는 무엇입니까?

실제로 그들은 할 수 있습니다. 대부분의 라이브러리는 독립적으로 (Java SE에서) 직접 사용하거나 .war (실제로 거의 항상 Tomcat 임)에 포함될 수 있습니다. JPA와 같은 Java EE의 일부에는 Java SE에서 작동하고 사용하는 방법을 알려주는 명시적인 섹션이 각 사양에 있습니다.

중요한 것은 애플리케이션 서버 환경 자체가 아니라 다른 모든 라이브러리와이를 통합하는 통합 코드의 존재입니다.

이 때문에 주석은 모든 라이브러리 (EJB, JPA 등)가이 스캔을 계속해서 수행하는 대신 모든 클래스에 대해 한 번만 스캔됩니다. 또한 CDI 어노테이션을 EJB 빈에 적용 할 수 있고 JPA 엔티티 관리자를 주입 할 수 있습니다.

이메일을 보내기 위해 간단한 코드를 컴파일하기 위해 JBoss처럼 거대한 것이 필요한 이유는 무엇입니까?

이 질문에는 몇 가지 잘못된 점이 있습니다.

1. 컴파일을 위해서는 웹 프로필의 경우 1MB 미만이고 전체 프로필의 경우 1MB가 약간 넘는 API jar 만 필요합니다.
2. 실행을 위해서는 분명히 구현이 필요하지만 "거대한"것은 과장된 것입니다. 예를 들어 OpenJDK는 약 75MB이고 TomEE (메일 지원을 포함하는 웹 프로필 구현)는 25MB에 불과합니다. GlassFish (전체 프로필 구현)도 53MB에 불과합니다.
3. Mail은 독립형 mail.jar 및 activation.jar을 사용하여 Java SE (및 Tomcat)에서 완벽하게 작동합니다 .

Java EE 라이브러리가 "표준"이 아니며 일반 JVM 다운로드 및 / 또는 SDK에 포함 된 이유는 무엇입니까?

Java EE는 이미 방대한 JDK를 관리 및 다운로드하기 쉬운 청크로 분할하려는 첫 번째 시도 중 하나였습니다. 사람들은 이미 그래픽 클래스 (AWT, Swing) 및 애플릿이 헤드리스 서버에서 일부 명령을 실행하는 경우 JRE 내부에 있다고 불평하고 있습니다. 그리고 표준 JDK에 모든 Java EE 라이브러리를 포함하고 싶습니까?

모듈화 지원의 최종 릴리스와 함께 우리는 패키지로 개별적으로 설치할 수있는 많은 것들을 가진 작은 기본 JRE를 갖게 될 것입니다. 아마도 언젠가는 Java EE를 구성하는 많은 또는 심지어 모든 클래스도 그러한 패키지가 될 것입니다. 시간이 말해 줄거야.

표준 Java (Oracle JVM / SDK | OpenJDK JVM / JDK)의 두 가지 주요 특징 만 있는데 왜 그렇게 많은 Java EE 제품이 있습니까?

Java SE에는 두 가지 이상의 특징이 있습니다. 최소한 IBM JDK, 이전 BEA (JRocket, 인수로 인해 Oracle / Sun에 병합되는 JRocket), 다양한 기타 오픈 소스 구현 및 임베디드 사용을위한 수많은 구현이 있습니다.

Java SE 및 EE가 사양 인 이유는 많은 공급 업체와 조직이이를 구현할 수 있으므로 경쟁을 장려하고 공급 업체 종속 위험을 완화하기 때문입니다.

C 및 C ++ 컴파일러와 크게 다르지 않습니다. 경쟁 제품이 많고 모두 C ++ 표준을 준수합니다.

Java EE 라이브러리 버전이 표준 Java 라이브러리 릴리스 (Java EE 6 대 Java 7)와 동기화되지 않는 이유

Java EE는 Java SE를 기반으로하므로 뒤처집니다. 그러나 버전은 일치합니다. Java EE 5에는 Java SE 5가 필요합니다. Java EE 6에는 Java SE 6 등이 필요합니다. 대부분 Java SE X가 최신 버전 일 때 Java EE X-1이 최신 버전입니다.

다음은 질문에 대한 몇 가지 빠르게 구성된 답변입니다 ...

• JavaEE 라이브러리는 애플리케이션 서버없이 작동 할 수없는 이유는 무엇입니까? JavaEE에서 제공하는 서비스 (컨테이너 관리 트랜잭션, 컨테이너 관리 종속성 주입, 타이머 서비스 등)는 본질적으로 JavaEE 호환 애플리케이션 서버 (예 : GlassFish, JBoss, WebSphere 등)를 포함합니다. 따라서 JavaEE 라이브러리는 그러한 컨테이너 없이는 아무 목적도 없습니다. " 이메일을 보내기 위해 간단한 코드를 컴파일하기 위해 JBoss만큼 방대한 것이 필요한 이유는 무엇입니까? " JavaEE없이 이메일을 보내는 방법이 있습니다 ...하지만 JavaEE 방식으로 이메일을 보내려면 JavaEE 컨테이너가 필요합니다.

• JavaEE 라이브러리가 JavaSE 다운로드에 포함되지 않는 이유는 무엇입니까? 많은 라이브러리가 포함되지 않은 것과 같은 이유는 과잉 일 것입니다. 응용 프로그램 서버 없이는 JavaEE 라이브러리도 사용할 수 없는데 왜 포함시켜야할까요? 개발자가 응용 프로그램 서버를 설치하고 JavaEE를 사용하기로 결정한 경우 JavaEE를 다운로드해야합니다.

• JavaEE 제품이 많은 이유는 무엇입니까? 정말로 " 너무 많은 "JavaEE 오퍼링이 있습니까? 그렇다면 그중 일부를 나열하십시오. 더 정확하게 는 동일한 API 의 여러 구현 이 있다고 생각 합니다.

• 표준 Java 없이는 할 수없는 JavaEE로 무엇을 할 수 있습니까? 많이. JavaEE없이 트랜잭션 또는 지속성 컨텍스트를 관리하기 위해 애플리케이션 서버에 의존 할 수 없습니다. 애플리케이션 서버가 JavaEE없이 EJB 종속성 주입을 관리하도록 허용 할 수 없습니다. JavaEE 없이는 애플리케이션 관리 타이머 서비스를 사용할 수 없습니다. 이 질문에 대한 답은 첫 번째 질문에 대한 답을 아주 분명하게 만들어줍니다. JavaEE에서 제공하는 대부분의 서비스에는 JavaEE 컨테이너가 필요합니다.

• JavaEE로 할 수없는 JavaSE로 무엇을 할 수 있습니까? 음 .. 모르겠어요.

• 개발자는 언제 JavaEE 가 필요하다고 결정 합니까? 이 질문은 완전히 주관적입니다 ... 그러나 JavaEE에서 제공하는 서비스가 필요하면 이에 대해 생각하기 시작합니다. JavaEE가 무엇인지 모른다면 ... 아마도 필요하지 않을 것입니다.

• 개발자는 언제 JavaEE가 필요하지 않다고 결정합니까? 이전 답변을 참조하십시오.

• JavaEE 라이브러리 버전이 JavaSE 버전과 동기화되지 않는 이유는 무엇입니까? 좋은 질문. 대답하는 방법을 아는 척하지는 않겠습니다.하지만 대답은 "동기화되지 않았기 때문에"라고 생각합니다.

조감도에서 Java EE는 플랫폼, 즉 우리가 구축 할 수있는 것입니다.

보다 기술적 인 관점에서 Java Enterprise Edition 표준은 엔터프라이즈 응용 프로그램을 빌드하는 데 일반적으로 사용되는 API 집합을 정의합니다. 이러한 API는 응용 프로그램 서버에 의해 구현됩니다. 예, 다른 응용 프로그램 서버는 Java EE API의 다른 구현을 자유롭게 사용할 수 있습니다.

그러나 Java ee 라이브러리는 코드가 Java EE 응용 프로그램 서버 (예 : JBoss, GlassFish, Tomcat 등)에서 실행 중이거나 액세스 권한이없는 경우 작동하지 않으며 컴파일되지 않습니다.

Java EE API에 대해 컴파일하므로 컴파일 타임에만 해당 API가 필요합니다. 런타임시 이러한 API의 구현, 즉 응용 프로그램 서버도 필요합니다.

이메일을 보내기 위해 간단한 코드를 컴파일하기 위해 JBoss처럼 거대한 것이 필요한 이유는 무엇입니까?

당신은하지 않습니다. 그러나 메일 보내기에 Java EE API를 사용하려면 런타임에 해당 API를 구현해야합니다. 이는 애플리케이션 서버에서 제공하거나 클래스 경로에 추가 한 독립 실행 형 라이브러리에서 제공 할 수 있습니다.

Java EE 라이브러리가 "표준"이 아니며 일반 JVM 다운로드 및 / 또는 SDK에 포함 된 이유는 무엇입니까?

구현이 아닌 API 만 표준화 되었기 때문입니다.

Java EE 제품이 많은 이유

사람들은 특정 기능을 구현하는 올바른 방법에 동의하지 않기 때문입니다. 서로 다른 공급 업체가 시장 점유율을 놓고 경쟁하기 때문입니다.

표준 Java로는 할 수없는 Java EE로 무엇을 할 수 있습니까?

Java EE 구현은 "표준 Java"로 빌드되었으므로 : 없음. 그러나 기존 라이브러리를 활용하면 일반적인 엔터프라이즈 문제를 해결하는 경우 많은 노력을 절약 할 수 있으며 표준화 된 API를 사용하면 공급 업체 종속을 방지 할 수 있습니다.

Java EE로 할 수없는 표준 Java로 무엇을 할 수 있습니까?

Java EE에는 Java SE가 포함되어 있으므로 아무것도 없습니다.

개발자는 언제 Java EE가 "필요"하다고 결정합니까? 개발자는 언제 Java EE가 필요하지 않다고 결정합니까?

일반적으로 Java EE API는 엔터프라이즈 컴퓨팅에서 일반적이고 반복되는 문제를 해결합니다. 이러한 문제가있는 경우 일반적으로 표준 솔루션을 사용하는 것이 합리적이지만 다른 문제가있는 경우 다른 솔루션이 필요할 수 있습니다. 예를 들어 관계형 데이터베이스와 통신해야하는 경우 JPA 사용을 고려해야합니다. 그러나 관계형 데이터베이스가 필요하지 않은 경우 JPA는 도움이되지 않습니다.

Java EE 란 무엇입니까?

위키의 캐 노니 티 정의부터 시작하겠습니다.

Java Platform, Enterprise Edition 또는 Java EE는 Oracle의 엔터프라이즈 Java 컴퓨팅 플랫폼입니다. 이 플랫폼은 네트워크 및 웹 서비스, 기타 대규모의 다중 계층, 확장 가능, 안정적이고 안전한 네트워크 애플리케이션을 포함한 엔터프라이즈 소프트웨어를 개발하고 실행하기위한 API 및 런타임 환경을 제공합니다.

여기서 요점은 Java EE가 특정 라이브러리가 아닌 API를 제공하는 플랫폼이라는 것입니다.

Java EE에 필요한 것은 무엇입니까?

Java EE의 주요 범위는 단순한 네트워크 지원으로 데스크톱 애플리케이션 개발을 지향하는 Java SE와 달리 네트워크 기반 애플리케이션입니다. 이것이 그들 사이의 주요 차이점입니다. 확장 성, 메시징, 트랜잭션, 모든 애플리케이션에 대한 DB 지원 ...이 모든 요구 사항은 네트워크의 발전과 함께 증가했습니다. 물론 Java SE가 제공하는 많은 준비된 솔루션은 네트워크 개발에 유용하므로 Java EE는 Java SE를 확장합니다.

코드를 실행하기 위해 애플리케이션 서버가 필요한 이유는 무엇입니까?

운영 체제가 필요한 이유는 무엇입니까? 하드웨어에 대한 많은 고통스러운 작업이 있기 때문에 우리는 가장 간단한 응용 프로그램을 만들기 위해해야합니다. 그리고 OS가 없으면 몇 번이고 반복해야합니다. 지나치게 단순화 된 OS는 애플리케이션을 실행하기위한 글로벌 컨텍스트를 제공하는 프로그래밍 방식의 컨테이너 일뿐입니다.

이것이 바로 애플리케이션 서버입니다. 이를 통해 애플리케이션을 해당 컨텍스트에서 실행할 수 있으며 엔터프라이즈 고부하 네트워크 애플리케이션에 필요한 많은 고급 기능을 제공합니다. 그리고 우리는이 문제를 해결하기 위해 우리 자신의 자전거를 작성하고 싶지 않으며, 우리의 비즈니스 요구를 만족시킬 코드를 작성하고 싶습니다.

여기에 또 다른 예로 Java 용 JVM이 있습니다.

Java EE에 온보드 앱 서버가없는 이유는 무엇입니까?

나에게 말하기 어렵다. 더 많은 유연성을 위해 이루어진 것 같습니다. Java EE는 수행해야 할 작업을 말하고 수행 방법을 결정합니다.

JVM에 Java EE가 포함되지 않은 이유는 무엇입니까?

그들은 다른 시장 부문을 지시했기 때문입니다. Java EE에는 일반적인 데스크톱에 필요하지 않은 많은 기능이 있습니다.

Java EE 제품이 그렇게 많은 이유는 무엇입니까?

Java EE는 동작 만 설명하기 때문입니다. 누구나 구현할 수 있습니다.

Java SE로 할 수없는 Java EE로 무엇을 할 수 있습니까?

인터넷을 정복하기 위해. Java SE 애플릿과 소켓을 사용하는 것은 정말 어렵습니다. :)

Java EE로 할 수없는 Java SE로 무엇을 할 수 있습니까?

위에서 언급했듯이 Java EE는 Java SE를 확장하므로 Java EE를 사용하면 Java SE에서 사용할 수있는 모든 작업을 수행 할 수 있습니다.

개발자는 언제 Java EE가 "필요"하다고 결정합니까?

Java EE의 기능이 필요할 때. 위에 언급 된 모든 것.

개발자는 언제 Java EE가 필요하지 않다고 결정합니까?

일반적인 콘솔 또는 데스크톱 애플리케이션을 작성할 때.

Java SE 및 Java EE 버전이 동기화되지 않은 이유는 무엇입니까?

Java는 항상 이름 지정 및 버전 관리 기술에 문제가있었습니다. 따라서이 상황은 예외가 아닙니다.

Java EE는 컨테이너 개념에 관한 것입니다.
컨테이너는 애플리케이션을 실행하고 마지막 서비스 세트를 제공하는 실행 컨텍스트입니다. 각 서비스 유형은 JSR이라는 사양에 의해 정의됩니다. 예를 들어 JSR 907, JTA (자바 트랜잭션 API)는 다른 리소스에 대해 분산 트랜잭션을 관리하는 표준 방법을 제공합니다.
일반적으로 주어진 JSR에 대한 다양한 구현이 있으며, 사용할 구현은 컨테이너 공급자에 따라 다르지만 동작이 사전 정의 된 계약 인 JSR API를 준수한다고 확신하기 때문에 실제로는 신경 쓰지 않습니다.
따라서 Java EE를 활용하려면 컨테이너 내에서 애플리케이션을 실행해야합니다. 두 가지 주요 항목은 EJB 및 서블릿 컨테이너로, 둘 다 Java EE 인증 애플리케이션 서버에 있습니다.

이 모든 것의 목표는 필수 항목 인 id.est만으로 애플리케이션을 패키징 할 수 있도록 표준 실행 환경을 정의하는 것입니다. 당신의 사업. 그렇지 않으면 앱을 패키징하고 제공해야하며 서버의 다른 앱과 충돌의 원인이 될 수있는 알려지지 않은 다양한 타사 라이브러리 집합에 의존하지 않습니다. Java EE에서는 보안, 트랜잭션, 확장 성, 원격 호출 등과 같은 모든 표준 비 기능적 요구 사항이 컨테이너에서 제공되며 (내부에서 실행되는 모든 앱에 대해 팩터 라이즈 됨) 작업을 기반으로해야한다는 것을 알고 있습니다.