가이드라인: EJB 디자인
이 가이드라인은 J2EE 응용프로그램의 EJB(Enterprise JavaBean)를 디자인하는 방법에 대해 설명합니다.
관계
관련 요소
기본 설명

소개

이 가이드라인은 EJB 디자인에 초점을 둡니다. EJB를 식별하고 모델링하는 방식과 같은 EJB에 대한 추가 안내는 중간 산출물 가이드라인: EJB에서 제공합니다.

EJB의 특정 유형을 디자인하는 것에 대한 특정 가이드가 다음 가이드라인에서 제공됩니다.

로컬 인터페이스 대 원격 인터페이스

로컬 및 원격 인터페이스는 개념: J2EE 개요: 엔터프라이즈 JavaBean에서 설명합니다.

로컬 인터페이스는 원격 인터페이스보다 더 효과적입니다. EJB에 항상 로컬인 특정 클라이언트가 있는 경우 로컬 인터페이스를 제공해야 합니다.

이 주제에 더 특정한 가이드는 특정 유형의 EJB에 대한 가이드라인에서 제공됩니다.

매개변수 전달

성능은 원격 호출 수와 각 호출에서 전송되는 데이터의 양에 의해 극적으로 영향을 받을 수 있습니다. 이것은 원격 클라이언트가 필요로 하는 모든 데이터를 리턴하는 특정 호출을 제공하여 처리될 수 있습니다. 예를 들어, 관련된 엔티티 Bean 세트의 Facade 역할을 하는 세션 Bean은 다중 엔티티 Bean에서 직렬화 가능한 값 오브젝트로 데이터를 복사하고 단일 원격 호출에 이 데이터를 리턴할 수 있습니다. 이것은 Core J2EE 패턴 - 값 오브젝트 패턴([ALU01]에서 자세히 설명됩니다.

이것은 가능한 한 일반적으로 인터페이스를 유지하고 너무 많은 불필요한 데이터를 전송하지 않음으로써 밸런스를 유지해야 합니다.

트랜잭션

트랜잭션을 구분하는 것은 트랜잭션 시작, 확약 및 중단을 의미합니다. EJB 디자이너는 Bean 관리 트랜잭션 구분 또는 컨테이너 관리 트랜잭션 구분을 구현할지 여부를 결정해야 합니다. 응용프로그램에서 수행되는 비즈니스 로직 순서에서 트랜잭션 경계의 위치를 결정해야 합니다. 자세한 정보는 개념: J2EE 개요에서 타스크: 유스 케이스 디자인, 트랜잭션 모델링트랜잭션 관리 섹션을 참조하십시오.

가능한 곳에서 컨테이너 관리 트랜잭션을 사용하십시오. 이것은 코드를 단순하게 유지하며 개발자가 응용프로그램의 비즈니스 로직에 초점을 두게 합니다.

일반적으로, 세분성이 큰 트랜잭션일수록 더 나은 전체 성능을 가져옵니다. EJB에 대한 메소드 호출 순서를 작성한다고 가정하십시오(예: getX, getY 및 setZ). 기본적으로, 각 메소드는 새 트랜잭션에서 실행되어 감소된 성능을 가져옵니다. 동일한 트랜잭션에서 이를 호출하려면, 다른 메소드(예: 세션 EJB의 메소드 processXYZ)를 작성하고 호출된 메소드의 트랜잭션 속성을 필수로 설정하여, 기존 트랜잭션(예: 세션 Bean에서 호출 메소드의 트랜잭션)을 사용할 수 있습니다. 

보안

기본 EJB 보안 개념은 개념: J2EE 플랫폼 개요 - 보안에서 설명합니다.

보안 역할메소드 권한을 정의하여 EJB 보안 요구사항을 정의합니다. 보안 역할 및 메소드 권한은 EJB 배치 설명자에 정의됩니다. 보안 역할을 사용자 또는 사용자 그룹으로 맵핑하는 것은 서버에 달려 있습니다(관리 도구 사용).  

보안 역할은 단일 이름 아래로 그룹화되는 유사한 활동 유형 세트를 정의합니다. 메소드 권한은 특정 보안 역할에 메소드를 호출하는 권한을 부여합니다. 예를 들어, setAddress, setSalary 등의 메소드와 함께 Employee 엔티티 EJB를 고려하십시오. manager의 보안 역할에는 setAddress 및 setSalary 메소드에 대한 메소드 권한이 부여될 수 있지만, employee의 보안 역할에는 setAddress 메소드에 대한 메소드 권한만이 부여될 수 있습니다.  

일부 환경에서는 배치 설명자에서 선언 메소드 권한을 사용하여 응용프로그램의 보안 요구사항을 지원하는 것이 불가능합니다. 이 경우 javax.ejb.EJBContext 인터페이스의 getCallerPrincipal 및 isCallerInRole 메소드를 사용합니다.  

타이머 서비스

J2EE 1.4(더 정확하게 EJB 2.1) stateless 세션 Bean 및 메시지 구동 Bean은 EJB 타이머 서비스를 통해 일괄처리 프로세스를 스케줄하기 위해 타이머를 사용할 수 있습니다.

시간 기반 이벤트용으로 스케줄되는 콜백을 허용하도록 메소드를 제공하는 EJB 타이머 서비스. 컨테이너는 시간 지정된 이벤트의 신뢰성 있는 트랜잭션 알림 서비스를 제공합니다. 타이머 알림은 특정 지속 기간이 경과한 이후에 또는 특정 반복 간격으로 발생하도록 스케줄될 수 있습니다.

타이머 서비스는 EJB 컨테이너로 구현되며 엔터프라이즈 Bean은 EJBContext 인터페이스를 통해 이 서비스에 액세스할 수 있습니다.

EJB 타이머 서비스는 응용프로그램 레벨 프로세스의 모델링에서 사용하도록 디자인되며 실시간 이벤트를 모델링하도록 의도하지 않은 거친 타이머 알림 서비스입니다.

직접 액세스 대 엔티티 Bean

지속적 데이터에 대해 엔티티 Bean을 사용하여 지속적 데이터에 액세스하기 위한 기능이 풍부한 표준 메커니즘을 제공합니다. Bean 관리 지속성 또는 컨테이너 관리 지속성을 사용하려는 결정은 디자인에 유연성을 제공하며 클라이언트에서 숨겨질 수 있습니다. EJB는 트랜잭션, 자원 관리, 로드 밸런싱 및 J2EE 환경에서 제공하는 기타 기능을 이용할 수 있습니다.

그러나 직접 데이터베이스에 액세스하고 엔티티 Bean 사용을 피하려는 상황이 있을 수 있습니다. 예를 들어, 데이터가 단일 클라이언트에 의해 읽기 전용으로 항상 액세스되는 경우, 데이터베이스에 대한 직접 액세스가 더 효과적입니다.

직접 데이터베이스에 액세스하려는 경우(예: stateless 세션 Bean), DAO 클래스에서 모든 데이터베이스 액세스를 캡슐화하십시오. 이것은 단지 기본 기억장치 메커니즘을 숨기고 캡슐화하며 데이터 소스에 대한 인터페이스가 변경될 때 변경사항을 분리시키는 Java 클래스입니다. Core J2EE 패턴 - 데이터 액세스 오브젝트 패턴([ALU01])을 참조하십시오.

데이터베이스 연결

가상적으로 모든 EJB 컨테이너는 클라이언트 간에 이미 작성한 연결 세트를 공유하는 연결 풀링을 위한 지원을 제공합니다. 이 연결은 필요할 때 EJB로 지정됩니다. EJB는 연결을 작성하고 초기화하는 경비 없이 연결을 획득합니다. 연결이 풀로 리턴되면 재순환됩니다. 풀 크기는 사용된 연결을 재순환할 수 있도록 충분히 준비해야 합니다.

컨테이너 관리 지속성이 있는 엔티티 Bean의 경우, 컨테이너는 데이터베이스 연결을 관리하며 데이터베이스 연결 풀에 대한 액세스를 관리합니다.

Bean 관리 지속성이 있는 엔티티 Bean의 경우(또는 데이터베이스에 액세스하는 세션 또는 메시지 구동 EJB의 경우), 개발자가 연결 루틴 코딩에 책임이 있습니다. 다음 가이드라인이 적용됩니다.

  • DAO 클래스에서 데이터베이스 액세스 코드를 분리시키십시오.
  • 데이터베이스의 실제 URL을 하드코드하지 말고, 대신 JNDI(Java Naming and Directory Interface) 찾아보기를 사용하여 검색될 수 있는 논리 이름을 사용하십시오. 이것은 가능한 경우 다른 데이터베이스 이름을 사용하여 다중 응용프로그램에서 EJB를 재사용할 수 있게 합니다.
  • 일반적으로, 연결 풀을 사용하고, 필요하면 가능한 연결을 보유하기만 하십시오. 예를 들어, 엔티티 Bean이 테이블에서 행을 연결, 갱신한 후 연결을 끊을 수 있습니다. 이것은 여러 EJB가 동일한 연결을 공유할 수 있게 합니다. JDBC 스펙은 연결 풀링을 위한 지원을 포함합니다.