Java EE란 무엇인가?

Java EE란 무엇인가?

현재 이 질문은 Q&A 형식에 적합하지 않습니다.우리는 답변이 사실, 참고 자료 또는 전문지식에 의해 뒷받침되기를 기대하지만, 이 질문은 토론, 논쟁, 여론 조사 또는 연장된 토론을 요구할 것이다.이 질문이 개선되고 다시 열릴 수 있다고 생각되면헬프센터를 방문하여 안내를 받으십시오.

닫힘9년 전.

Java EE는 젊은 Java 개발자들을 위한 "의문의 장막"을 둘러쌉니다. 이 장막은 제가 오랫동안 노력했지만 거의 성공하지 못했습니다.

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

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

• Java EE 라이브러리가 "표준"이 아니며 정기적인 JVM 다운로드 및/또는 SDK에 포함되어 있지 않은 이유는 무엇입니까?

• 표준 Java는 두 가지 주요 맛(Oracle JVM/SDK | OpenJDK JVM/JDK)밖에 없는데 왜 Java EE 제품이 이렇게 많은가요?

• Java EE에서는 표준 Java에서는 할 수 없는 일을 Java EE에서는 어떻게 할 수 있을까요?

• Java EE에서는 할 수 없는 표준 Java에서는 무엇을 할 수 있을까요?

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

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

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

날 도와줘서 고마워!

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

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

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

따라서 모든 라이브러리(EJB, JPA 등)가 자체 검색을 반복하는 대신 모든 클래스에 대해 주석을 한 번만 검사합니다.또한 CDI 주석을 EJB 콩에 적용하여 JPA 엔티티 매니저를 투입할 수 있습니다.

간단한 코드를 컴파일하여 이메일을 보낼 때 JBoss와 같은 대용량이 필요한 이유는 무엇입니까?

이 질문에는 몇 가지 문제가 있습니다.

1. 컴파일에는 웹 프로파일의 경우 1MB 미만, 전체 프로파일의 경우 1MB를 조금 넘는 API jar만 필요합니다.
2. 실행을 위해 구현이 필요한 것은 분명하지만, "대량"은 과장된 것입니다.예를 들어 OpenJDK는 약 75MB이고 TomEE(메일 지원을 포함하는 웹 프로파일 구현)는 25MB에 불과합니다. GlassFish(풀 프로파일 구현)도 53MB에 불과합니다.
3. Java SE(따라서 Tomcat)로부터의 메일은 스탠드아론 mail.jar 및 activation.jar를 사용하여 완벽하게 동작합니다.

Java EE 라이브러리가 "표준"이 아니며 정기적인 JVM 다운로드 및/또는 SDK에 포함되어 있지 않은 이유는 무엇입니까?

Java EE는 어떤 면에서 이미 대용량인 JDK를 관리와 다운로드가 용이한 청크로 분할하려는 최초의 시도 중 하나였다.사람들은 이미 그래픽 클래스(AWT, Swing)와 애플릿이 헤드리스 서버에서 몇 가지 명령어를 실행하는 것만으로 JRE 내에 있다고 불평하고 있다.그리고 모든 Java EE 라이브러리를 표준 JDK에 포함시키길 원하십니까?

모듈러형 지원의 최종 릴리스에서는, 많은 것을 패키지로 개별적으로 인스톨 할 수 있는 소규모의 베이스 JRE가 제공되게 됩니다.아마도 언젠가는 Java EE를 구성하는 많은 클래스 또는 심지어 모든 클래스도 이러한 패키지가 될 것이다.때가 지나면 알게 될 것이다.

표준 Java는 두 가지 주요 맛(Oracle JVM/SDK | OpenJDK JVM/JDK)밖에 없는데 왜 Java EE 제품이 이렇게 많은가요?

Java SE에는 두 가지 이상의 맛이 있습니다.적어도 IBM JDK, 이전 BEA DK(JRocket, 인수 때문에 Oracle/Sun에 병합됨), 다양한 오픈 소스 구현 및 임베디드 사용을 위한 수많은 구현이 있습니다.

Java SE와 EE가 사양인 이유는 많은 벤더와 조직이 이를 구현할 수 있기 때문에 경쟁이 촉진되고 공급업체의 구속 위험이 완화되기 때문입니다.

이는 C++ 컴파일러와 C++ 컴파일러와 거의 다르지 않습니다.C++ 컴파일러는 많은 경쟁 제품을 갖추고 있으며 모두 C++ 표준을 준수하고 있습니다.

Java EE 라이브러리 버전이 표준 Java 라이브러리 릴리스와 동기화되지 않는 이유(Java EE 6 vs.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와 같은 대용량이 필요한 이유는 무엇입니까?"넌 아냐.JavaE 없이 이메일을 보낼 수 있는 방법이 있습니다...그러나 JavaEE 방식으로 작업을 수행하려면 JavaEE 컨테이너가 필요합니다.

• JavaE 라이브러리가 JavaSE 다운로드에 포함되지 않는 이유는 무엇입니까?많은 도서관이 포함되어 있지 않은 것과 같은 이유: 그것은 과잉 살상일 것이다.애플리케이션 서버 없이는 JavaEE 라이브러리도 사용할 수 없는데 굳이 포함시킬 필요가 있습니까?개발자가 애플리케이션 서버를 설치하고 JavaEE를 사용하기로 결정한 경우 JavaEE를 다운로드해야 합니다.

• JavaEE 오퍼링이 많은 이유는 무엇입니까?JavaEE 오퍼링이 정말 "수많은"가?그렇다면 몇 가지 목록을 작성해주세요.더 정확히 말하면, 동일한 API를 여러 개 구현하고 있다고 생각합니다.

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

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

• 개발자는 언제 JavaEE가 필요하다고 결정합니까?이 질문은 완전히 주관적이다...그러나 JavaEE에서 제공하는 서비스가 필요한 경우 검토하기 시작합니다.JavaEE가 뭔지 모를 경우...아마 필요 없을 거예요.

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

• JavaEE 라이브러리 버전이 JavaSE 버전과 동기화되지 않는 이유는 무엇입니까?좋은 질문입니다.어떻게 대답해야 할지 아는 척은 안 할 거야근데 정답은 '맞지 않아서'인 것 같아요

Java EE는 우리가 구축할 수 있는 플랫폼입니다.

좀 더 기술적인 관점에서 Java Enterprise Edition 표준은 엔터프라이즈 애플리케이션 구축에 일반적으로 사용되는 API 세트를 정의합니다.이러한 API는 응용 프로그램서버에 의해 구현됩니다.그렇습니다.다양한 응용 프로그램서버는 Java EE API의 다른 구현을 자유롭게 사용할 수 있습니다.

그러나 코드가 Java EE 애플리케이션 서버(JBoss, GlassFish, Tomcat 등)에서 실행 중이거나 액세스 권한이 없는 경우 Java ee 라이브러리는 작동하지 않거나 컴파일되지 않습니다.

Java EE API에 대해 컴파일하기 때문에 컴파일 시에만 이러한 API가 필요합니다.런타임에는 이러한 API(애플리케이션 서버)의 구현도 필요합니다.

간단한 코드를 컴파일하여 이메일을 보낼 때 JBoss와 같은 대용량이 필요한 이유는 무엇입니까?

넌 아냐.그러나 Java EE API를 메일 전송에 사용하려면 런타임에 해당 API를 구현해야 합니다.응용 프로그램 서버에서 제공하거나 클래스 경로에 추가하는 독립 실행형 라이브러리에서 제공할 수 있습니다.

Java EE 라이브러리가 "표준"이 아니며 정기적인 JVM 다운로드 및/또는 SDK에 포함되어 있지 않은 이유는 무엇입니까?

API만 표준화되고 구현은 표준화되지 않기 때문입니다.

Java EE 서비스가 많은 이유는 무엇입니까?

왜냐하면 사람들은 특정 기능을 구현하는 올바른 방법에 대해 동의하지 않기 때문입니다.서로 다른 벤더가 시장 점유율을 놓고 경쟁하기 때문입니다.

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란?

Wiki에서 카노닉리티 정의부터 시작합시다.

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는 단지 프로그램 컨테이너일 뿐이며, 이를 통해 애플리케이션 실행에 필요한 글로벌 컨텍스트를 얻을 수 있습니다.

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

JVM for Java를 예로 들 수 있습니다.

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

나로서는 말하기 어렵다.좀 더 융통성 있게 하려고 한 것 같아요.자바 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(Java transaction API)는 서로 다른 리소스에 대해 분산 트랜잭션을 관리하는 표준 방법을 제공합니다.
특정 JSR에는 일반적으로 많은 다른 구현이 있으며, 사용하는 구현은 컨테이너 공급자에 따라 다르지만 JSR API라는 사전 정의된 계약에 따라 동작하는 것이 확실하기 때문에 그다지 신경 쓰지 않습니다.
따라서 Java EE를 활용하려면 컨테이너 내에서 응용 프로그램을 실행해야 합니다.두 가지 주요 컨테이너는 모두 Java EE 인증 애플리케이션 서버에 있는 EJB 및 서블릿 컨테이너입니다.

이 모든 것의 목적은 id.est라는 필수 요소만 사용하여 응용 프로그램을 패키징할 수 있도록 표준 실행 환경을 정의하는 것입니다.당신의 사업.알 수 없는 다양한 서드파티 라이브러리 세트에 의존하지 않아도 됩니다.이러한 라이브러리는, 애플리케이션의 패키징이나 제공이 필요하기 때문에, 서버의 다른 앱과의 경합이 발생할 가능성이 있습니다.Java EE에서는 보안, 트랜잭션, 확장성, 원격 호출 등과 같은 모든 표준 비기능적 요구 사항이 컨테이너에 의해 제공된다는 것을 알고 있으며 컨테이너 내에서 실행되는 모든 앱에 대해 계수로 분류되어 있으므로 이를 기반으로 작업을 수행해야 합니다.

언급URL : https://stackoverflow.com/questions/15774924/just-what-is-java-ee-really