목적

EJB 설계의 목적은 EJB(Enterprise JavaBean)를 구성하는 설계 클래스를 식별하고 지정하는 것입니다.   

활동: 클래스 설계와 마찬가지로 다음과 같은 목적이 있습니다.

  • 모호하지 않게 EJB를 구현하기 위해 충분한 정보가 제공되었는지 확인합니다.
  • EJB와 관련된 비기능적인 요구사항을 처리합니다.
  • EJB에서 사용하는 설계 메커니즘을 통합합니다. 특히, 설계 중인 EJB의 종류에 고유한 설계 메커니즘을 통합합니다.
역할:  설계자 
빈도  초기 이후에 모든 반복 중 반복적으로 발생합니다. 프로토타입 활동이 있는 경우 초기에 발생할 수도 있습니다.
단계
입력 결과물:    결과 결과물:   
툴 강좌:   
자세한 정보:   

워크플로우 세부사항:   

EJB 식별 페이지 맨 위

분석 클래스 및/또는 초기 설계 모델 요소에서 EJB를 식별하십시오. 또한 EJB는 설계 패턴의 일부분으로 식별될 수 있습니다. 패턴 통합은 이 활동(새 클래스, 조작, 속성 및 관계 추가)에서 많은 단계를 효과적으로 수행하지만, 패턴에서 정의한 규칙을 준수합니다. J2EE 패턴의 예는 Core J2EE 패턴([ALU01])을 참조하십시오.

작성할 몇 가지 주요 결정사항이 있습니다.

  • "비즈니스 논리"를 EJB 및 비EJB 클래스로 맵핑하는 방식 - 필요한 클래스 수 및 종류. 예를 들어, 지속할 필요가 있는 "상태" 정보를 포함하는 객체를 표시하는 클래스는 엔티티 EJB로 맵핑되어야 합니다. 서비스를 수행하고 자체 지속적인 데이터가 없는 클래스는 세션 또는 메시지 EJB로 맵핑되어야 합니다.
  • 세션 Bean의 경우, stateful 또는 stateless 세션 Bean을 사용할 지 여부(stateful 대 stateless 세션 Bean 사용에 대한 결정은 세션 Bean 대 기타 식별된 클래스의 책임을 식별하는 중요한 파트임). 비연속인 요청 간에 인스턴스를 공유할 수 있으므로 특정 활동 세션으로 "결합"하기 보다는 Stateless 세션 Bean이 더 효과적입니다. 또한 EJB가 웹 서비스 엔드포인트로 사용되는 경우 반드시 stateless이어야 합니다.
  • Bean이 사용하거나 관여해야 하는 설계 패턴 및 메커니즘. 특정 패턴 및 메커니즘의 사용은 식별되는 EJB의 수와 유형에 영향을 미칩니다.
    주:
    소프트웨어 아키텍트는 보통 프로젝트에서 사용해야 하는 패턴 및 메커니즘을 결정하고 설계자에서 따라야 하는 가이드라인을 결정합니다.

EJB 식별에 대한 자세한 정보는 가이드라인: EJB 식별을 참조하십시오.

속성 정의 페이지 맨 위

EJB의 속성을 식별하십시오.

특히, 각 엔티티 Bean에 대해 지속적 속성 및 1차 키를 식별하십시오.

엔티티 EJB 속성 정의에 대한 자세한 정보는 가이드라인: 엔티티 Bean 설계를 참조하십시오.

조작 정의 페이지 맨 위

이 단계는 세션 및 엔티티 Bean에 적용할 수 있습니다. 메시지 구동 Bean에 적용할 수 없습니다.

조작의 설계는 활동: 클래스 설계, 특히 조작 정의 단계에서 다루어집니다.

EJB의 일부 주요 결정사항은 다음과 같습니다.

  • 특정 조작이 로컬 또는 원격 클라이언트에 사용 가능해야 하는지 여부. 일반적으로, EJB에는 로컬 또는 원격 컴포넌트 인터페이스만 있습니다. J2EE 1.3 이상의 버전에서 작업 중인 경우, 로컬 컴포넌트 인터페이스를 통해 동일한 JVM에서 엔티티 EJB를 조작하는 세션 EJB를 통해 모든 원격 클라이언트 액세스를 처리하는 것이 보통입니다.
  • get/set 조작을 위해 값 객체로 속성을 그룹화하는 방식. 엔티티 EJB의 원격 인터페이스를 제공하는 경우, 양방향에서 한 번에 Bean 데이터의 스냅샷을 전달하기 위해 사용되는 "값 객체" 클래스를 정의하는 것이 가장 좋습니다. 이것은 각 Bean 필드의 반복된 get/set 호출에 비교되는 네트워크 오버헤드를 최소화합니다. 자세한 정보는 Core J2EE 패턴([ALU01]을 참조하십시오.

EJB 조작 정의에 대한 자세한 정보는 가이드라인: EJB 설계를 참조하십시오.

작동 정의페이지 맨 위

클래스 작동의 설계는 활동: 클래스 설계에서 다루어집니다.

EJB가 처음 식별될 때 아직 지정되지 않은 경우, EJB를 설계하는 주요 단계는 사용할 EJB 메커니즘을 식별하는 것입니다. 결정사항에는 다음이 포함됩니다.

  • 트랜잭션을 사용할지 여부, 사용할 경우 Bean 관리 또는 컨테이너 관리 트랜잭션 사용 여부.
  • 보안 정책을 제공할 필요가 있는지 여부, 제공할 필요가 있는 경우 정책은 무엇이며, 보안 정책이 Bean에서 제공하는 각 메소드와 관련되는 방식 및 각 정책과 연관된 사용자 "역할". 또한 설계자는 프로그램적 또는 선언적 권한 부여를 사용할지 여부를 결정해야 합니다.
  • 엔티티 Bean의 경우, 컨테이너 관리 또는 Bean 관리 지속성 사용 여부. Bean 관리 지속성은 더 많은 유연성을 제공하지만, 개발자의 파트에서 더 많은 작업을 수행합니다. 컨테이너 관리 지속성은 많은 작업을 자동화하지만, 유연성이 떨어집니다.

이 메커니즘의 대부분은 프로젝트 레벨의 소프트웨어 아키텍트에서 작성되고, 어느 경우에나 설계자은 프로젝트 가이드라인을 따릅니다.

EJB 작동의 파트는 메소드에 의해 제공되지만, 추가 작동은 EJB 협업을 통해 제공됩니다. EJB 간에 참조를 작성할 수 있지만, CMP 2.0 엔티티 EJB의 경우 그들 간의 컨테이너 관리 관계(CMR)를 작성할 수 있습니다.

EJB 작동 설계에 대한 세부 가이드라인은 가이드라인: EJB 설계에서 제공됩니다.

지원 클래스 설계 페이지 맨 위

이 단계는 모든 EJB에 적용할 수 있습니다.

이것은 EJB 설계를 지원하는 추가 설계 클래스가 식별되는 곳입니다. 일반 지원 클래스는 1차 키 클래스(PK 클래스), DAO(Data Accessor Object) 및 VO(Value Objects)를 포함합니다. 데이터베이스 조작 세부사항을 숨기기 위해 BMP 엔티티 EJB 구현시 DAO가 사용됩니다. 이것은 하나의 데이터베이스 서버에서 다른 데이터베이스 서버로 어플리케이션을 더 쉽게 포트하게 합니다. VO는 효과적인 방식으로 컴포넌트 간에 데이터 값을 전달하고 투명하게 데이터를 액세스하는 데 사용됩니다.

EJB 간의 참조 및 EJB 간의 컨테이너 관리 관계(CMR)를 작성할 수 있습니다.

패턴의 적용을 통해 추가 지원 클래스를 정의할 수 있습니다. J2EE 패턴의 자세한 정보는 Core J2EE 패턴([ALU01])을 참조하십시오.

클래스 설계에 대한 일반 지침은 활동: 클래스 설계를 참조하십시오.



Rational Unified Process   2003.06.15