가이드라인: J2EE 응용프로그램의 런타임 아키텍처 설명
이 가이드라인은 J2EE 응용프로그램의 런타임 아키텍처를 모델링하는 방법에 대해 설명합니다.
관계
기본 설명

소개

응용프로그램의 런타임 아키텍처는 시스템의 동시 요소를 설명하는 아키텍처 보기인 프로세스 보기에서 설명됩니다. 이 가이드라인에서는 J2EE 응용프로그램의 프로세스 보기를 모델링하는 방식에 대한 특정 안내를 제공합니다.

또한 개념: 프로세스 보기를 참조하십시오.

프로세스 보기 모델링

J2EE 컴포넌트(개념: J2EE 개요: J2EE 컴포넌트)는 컨테이너 환경에 배치됩니다. J2EE에서 정의한 각 컨테이너 유형에 대한 설명은 개념: J2EE 개요: J2EE 컨테이너를 참조하십시오.

각 컨테이너는 동시 요소이므로 아키텍처의 프로세스 보기에 표시되어야 합니다. 보통 상위 레벨 프로세스 보기에 표시되는 기타 중요한 동시 요소는 외부 시스템입니다.

다음은 J2EE 응용프로그램에 대한 상위 레벨 프로세스 보기의 일반 다이어그램입니다.

함께 표시된 텍스트에서 설명되는 다이어그램.

실제 예에서 특정 레거시 시스템 및 응용프로그램 클라이언트는 물론, 표시된 특정 벤더의 MOM(Message Oriented Middleware)이 표시됩니다. 그러나 웹 컨테이너 및 EJB 컨테이너는 모든 J2EE 프로세스 보기에 표시해야 하는 표준 컨테이너입니다.

이 다이어그램이 특정 하드웨어 노드에서 이 시스템의 실제 분배를 표시하지 않음을 참고하십시오. 이 다이어그램은 배치 모델에 표시됩니다(기법: J2EE 응용프로그램의 분배 설명 참조).

이 예에서 컨테이너 간에 사용되는 선택된 프로세스 간 커뮤니케이션 메커니즘이 표시됩니다. J2EE는 특정 프로세스 간 커뮤니케이션 메커니즘을 제공합니다. 지원합니다.

  • Java 클래스 간의 동기 커뮤니케이션을 위한 Java RMI(Remote Method Invocation)
  • CORBA 클라이언트에서 상호 운영을 위한 RMI-IIOP(보통 레거시 응용프로그램)
  • 웹 기반 클라이언트에서의 통신을 위한 HTTP/HTTPS(XML 웹 서비스와 상호 작용할 때와 같이 기타 웹 프로토콜도 지원될 수 있음)
  • MOM(Message Oriented Middleware)에서의 메시지 전달 및 상호 작용을 위한 JMS(Java Message Service)

프로세스 보기 정의에서 한 가지 중요한 결정은 JMS 대 RMI 또는 RMI-IIOP를 사용하는 시기입니다. 이 예에서 응용프로그램 클라이언트, EJB 컨테이너 및 다른 레거시 시스템은 통신하기 위해 메시지 전달을 사용합니다. 그러나 어떤 요소가 어떤 요소와 통신하는지 명확하지 않습니다. 모호성을 해결하려면, 다이어그램에서 MOM 시스템 삭제를 고려하고 메시지 전달에 의해 통신하는 요소 간의 연관으로 JMS를 표시하는 것을 고려하십시오.

다른 모호성은 메시지 전달을 통해 EJB가 서로 통신할지 여부입니다. 이것은 EJB 컨테이너에서 자체로 JMS 연관을 표시하여 명확해질 수 있습니다. 그러면 최종 다이어그램이 다음과 같이 됩니다.

함께 표시된 텍스트에서 설명되는 다이어그램.

그러나 프로세스 보기는 단지 컨테이너 및 상위 레벨 시스템 이상입니다. 또한 이 컨테이너와 시스템에서 동시성을 처리합니다.

프로세스 보기는 다음과 같은 종류의 활성 클래스를 식별하고 모델링해야 합니다.

  • Java 스레드
  • 메시지 대상
  • 메시지 구동 Bean(메시지를 통해 비동기적으로 호출되므로). 메시지 구동 Bean을 모델링하기 위해 사용되는 특정 스테레오타입은 기법: EJB 식별을 참조하십시오.
  • 전체 시스템 디자인 파트인 추가 프로세스. 별도의 타이머 프로세스는 이러한 프로세스의 예입니다.

JMS 사용 시, 메시지 생성자 및 이용자를 직접 관련시키거나 주제 및 대기열을 모델링하여 더 정확하게 관계를 모델링하도록 선택할 수 있습니다.

상호작용 다이어그램은 디자인 요소 간의 동기 및 비동기 커뮤니케이션 둘 다를 표시하기 위해 사용합니다. 또한 성능 및 로직 문제점의 동시 동작을 분석하기 위해 사용할 수도 있습니다. 특히 소프트웨어 설계자는 네트워크에서 빈번한 메시지 전달이나 높은 볼륨의 데이터 전송을 찾을 수 있습니다. 이것은 설계자가 인터페이스를 다시 디자인하거나 제어 스레드 간, 서버 간 또는 클라이언트 및 서버 간에 디자인 요소를 다시 지정하도록 할 수 있습니다.

EJB 컨테이너에서 스레드 및 프로세스는 EJB 컨테이너에 의해 관리되며, EJB는 스레드를 작성하거나 관리할 수 없음을 참고하십시오. 논리적으로 모든 EJB는 활성 클래스로 간주되어야 하지만, 세션 Bean 및 엔티티 Bean에 대한 호출은 동기 블로킹 호출이므로 이것은 보통 활성 클래스로 모델링되지 않습니다. EJB 컨테이너의 프로세스 보기는 보통 사용 가능한 하나의 동시 메커니즘으로 제한됩니다(JMS 메시지 구동 Bean이 있는 JMS).

세션 Bean 및 엔티티 Bean은 보통 활성 클래스로 모델링되지 않지만, 하나의 EJB가 데이터베이스에 쓰는 동안 또 다른 EJB가 데이터베이스를 읽는 것과 같은 동시성 문제가 있습니다. 이러한 문제는 트랜잭션을 사용하여 처리됩니다. 트랜잭션을 사용하는 접근 방식은 프로젝트 고유의 가이드라인에 문서화되어야 합니다.

활성 클래스에 디자인 요소 할당

타스크: 런타임 아키텍처 설명은 프로세스 및 스레드에 할당된 디자인 요소에 대한 필요성을 설명합니다. J2EE 응용프로그램에서 모든 웹 컴포넌트는 웹 컨테이너로 할당되며, 모든 EJB는 EJB 컨테이너로 할당됩니다. 이 간단한 관계로 인해, 이 할당을 모델링할 필요가 없습니다.

그러나 디자인에 추가적인 동시 프로세스(예: 두 개의 다른 응용프로그램 클라이언트)가 포함되는 경우 각 응용프로그램에서 실행되는 디자인 요소를 지정하는 것이 유용할 수 있습니다.

Java 스레드, 메시지 구동 Bean, JMS 주제 및 대기열의 경우, 문제는 교착 상태, 불일치 데이터 등을 피하기 위해 상호 통신하는 방식과 더 관련이 있습니다. 이것은 이 요소를 포함하는 유스 케이스 구현을 조사하여 최적으로 탐색됩니다.

기타 모델링 대안

프로세스 보기 및 배치 보기는 서로 유사하므로, 종종 이러한 보기의 상위 레벨 다이어그램이 결합됩니다.

또한 각 J2EE 컨테이너는 프로세스뿐만 아니라 실행 환경이기도 하므로, 활성 클래스 대신 "논리 노드"로 모델링될 수 있습니다.