Java EE spec

https://www.oracle.com/technetwork/java/javaee/tech/index.html

https://jcp.org/en/jsr/detail?id=366

https://github.com/javaee/javaee-spec/blob/master/download/JavaEE8_Platform_Spec_FinalRelease.pdf

//7~8
This chapter provides an overview of the Java™ Platform, Enterprise Edition (Java EE™).
EE.2.1 Architecture
The required relationships of architectural elements of the Java EE platform are shown in Figure EE.2-1. Note that this figure shows the logical relationships of the elements;
it is not meant to imply a physical partitioning of the elements into separate machines, processes, address spaces, or virtual machines.
The Containers, denoted by the separate rectangles, are Java EE runtime environments that provide required services to the application components represented in the upper half of the rectangle.
The services provided are denoted by the boxes in the lower half of the rectangle. For example, the Application Client Container provides Java Message Service (JMS) APIs to Application
Clients, as well as the other services represented. All these services are explained below. See Section EE.2.7, “Java EE Standard Services”.
The arrows represent required access to other parts of the Java EE platform.
The Application Client Container provides Application Clients with direct access to the Java EE required Database through the Java API for connectivity with database systems, the JDBCTM API. Similar access to databases is provided to JSP pages, JSF applications, and servlets by the Web Container, and to enterprise beans by the EJB Container.
As indicated, the APIs of the JavaTM Platform, Standard Edition (Java SE), are supported by Java SE runtime environments for each type of application component.
web profile



이 장에서는 JavaTM Platform, Enterprise Edition(Java EETM)에 대해 간략히 설명합니다.

EE.2.1 아키텍처

Java EE 플랫폼의 구조적 요소에 대한 필수 관계는 그림 EE.2-1에 나와 있습니다. 이 그림은 요소의 논리적 관계를 보여 줍니다.

이는 요소를 별도의 시스템, 프로세스, 주소 공간 또는 가상 시스템으로 물리적으로 분할하는 것을 의미하지는 않습니다.

별도의 사각형으로 표시된 컨테이너는 직사각형 상부에 표시되는 애플리케이션 구성요소에 필요한 서비스를 제공하는 Java EE 런타임 환경입니다.

제공되는 서비스는 직사각형 하단의 상자로 표시됩니다. 예를 들어 Application Client 컨테이너는 애플리케이션에 Java Message Service(JMS) API를 제공합니다.

고객들, 그리고 다른 서비스들. 이러한 모든 서비스는 아래에 설명되어 있습니다. 섹션 EE.2.7 "Java EE 표준 서비스"를 참조하십시오.

화살표는 Java EE 플랫폼의 다른 부분에 대한 필수 액세스를 나타냅니다.

Application Client 컨테이너는 데이터베이스 시스템, JDBCTM API와의 연결을 위해 Java API를 통해 Java EE가 필요한 데이터베이스에 직접 액세스할 수 있는 Application Client를 제공합니다. 데이터베이스에 대한 유사한 접근은 JSP 페이지, JSF 응용프로그램 및 웹 컨테이너의 서블릿과 EJB 컨테이너의 엔터프라이즈 콩에도 제공됩니다.

그림과 같이 JavaTM Platform, Standard Edition(Java SE)의 API는 각 애플리케이션 구성요소 유형에 대해 Java SE 런타임 환경에 의해 지원됩니다.

웹 프로필




정리(?)
WAS는 Web Server(Java EE 스펙인지는 모르겠다)와 Web Container(Java EE Spec)을 구현한 것이다. Web Container의 Service를 모두 구현한 것인 지는 잘모르겠다. 
Web Container의 Component는 JSP와 Servlet이고, 웹 컨테이너는 이 컴포넌트에 EJB, JSTL, WebServices 등의 서비스를 제공한다.




댓글

댓글 쓰기

이 블로그의 인기 게시물

AWS RDS DB 인스턴스에 연결하기 (Oracle Database Instance)

이미지
이전 포스팅에서 DB 인스턴스를 생성하는 방법 을 알아보았다. DB 인스턴스에 연결하기 위해서 먼저 연결에 사용되는 정보를 확인하는 방법을 알아보고나서, SQL*PLUS와 SQL Developer을 사용하여 DB 인스턴스에 연결하는 각각의 방법을 알아보자. 시작하기전, 현재 생성된 DB Instance는 Oracle EE 이고, 개발환경은 windows 환경임을 밝힌다. DB 인스턴스 연결에 사용되는 정보 확인 Amazon RDS에 생성된 Instance 클릭하여 인스턴스 정보를 확인합니다. ● Connect 섹션의 Endpoint 와 Port 는  dns_name  와  port  에 사용됩니다. ● Details 섹션의 DB Name (SID)은  database_name 에 사용됩니다. SQL*PLUS를 사용하여 DB 인스턴스에 연결 DB 인스턴스에 연결하는 명령어 스니펫은 다음과 같습니다. sqlplus user_name @(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST= dns_name )(PORT= port ))(CONNECT_DATA=(SID= database_name )))            user_name과 비밀번호 입력란에는 DB 인스턴스를 생성할 때 Step 2 : Spectify DB details - Settings - Master username & password에 지정한 값을 입력합니다. user_name ,  dns_name ,  port ,  database_name  를 각각 대체하여 입력하고 비밀번호까지 입력합니다. 그 결과 연결 성공 시 다음과 비슷한 출력이 나타납니다. 다음에 접속됨:              ...
자세한 내용 보기

tomcat server.xml ( 톰캣 서버 설정 )

이미지
server.xml을 통해서 tomcat이라는 web application server를 이해해보고자 한다. server.xml 설정에 목적이 있는 포스팅이 절대 아니다. 참고로 WAS는 J2EE 스펙(Servlet Container와 EJB Container의 기능)을 구현한 서버이지만, tomcat은 Servlet Container만 구현하고 EJB Container 기능은 없어서 WAS가 아니라는 사람도 있다. 그래서 ' 톰캣 == 서블릿 컨테이너 '라고 알고있어도 좋다. 무엇이든 제대로 알려면 공식 문서를 보는 것이 신뢰성도 높고 마음도 편하다. 그래서 아래 아파치 톰캣 config doc을 참조하여 tomcat WAS(서블릿 컨테이너)의 구조를 파악하려고 한다. https://tomcat.apache.org/tomcat-9.0-doc/config/index.html Top Level Elements  -  <Server>  is the root element of the entire configuration file, while  <Service>  represents a group of Connectors that is associated with an Engine. Connectors  - Represent the interface between external clients sending requests to (and receiving responses from) a particular Service. Containers  - Represent components whose function is to process incoming requests, and create the corresponding responses. An Engine handles all requests for a Service, a Host handles all requests fo...
자세한 내용 보기

Git resolving merge conflicts as Mark resolved (mark resolved 옵션으로 해결)

이미지
이전 포스팅 : Git merging branches (브랜치 합치기) 브랜치를 합치는 도중에 충돌이 일어날 수 있다. A브랜치와 B브랜치가 있다고 치자. A와 B브랜치의 같은 부분이 다른 코드로 작성되어 있을 때 두 개의 브랜치를 합치면 충돌이 일어난다. merge conflicts 해결방법 중에서 충돌이 일어난 코드를 자신이 직접 수정하여 해결하는 방법을 알아보자. Resolving merge conflicts - mark resolved 1. master 브랜치를 checkout한 상태(HEAD가 master브랜치인 상태)로 아래와 같이 testbranch2 브랜치를 생성한다. 2. testbranch2 브랜치를 checkout 한다. (HEAD : testbranch2 -> working directory가 testbranch2 상태가 됨 ; 그럴듯한 언어로 어떻게 말해야될 지 모르겠다 ) 3. Working Directory의 wow.java 파일이다. 1번에서 master가 checkout된 상태로 Commit: Working copy parent 옵션을 선택했기 때문에 master의 Working Directory와 동일하다. 4. 소스코드 'teacher' 를 추가한다(HEAD : testbranch2). 그리고 커밋한다. 5. master를 checkout하고 소스코드 'student'를 추가한다(HEAD : master). 그리고 커밋한다. 6. 현재 인덱스이다. 7. master 브랜치에 testbranch2 브랜치를 merge하기위해서, master 브랜치를 checkout하고 testbranch2를 우클릭하여  Merge testbranch2 into current branch 를 클릭한다. 8. Confirm Merge 확인창이 뜨면  확인 을 클릭한다. 9. (4),(5)번에서 소스코드의 같은 부분을 수정했기 때문에 ...
자세한 내용 보기