소프트웨어 디자인을 컴포넌트 또는 서브시스템으로 분해하는 작업에 대한 많은 문서가 작성되어 있습니다. 또한 올바른 아키텍처 결정을 내리기 위해 라이프사이클 초기에 응용프로그램에서 필요한 배치 토폴로지를 이해해야
하는 요구에 대한 문서도 많이 작성되었습니다. 그러나 오늘날 아키텍처 분석 시 논리적인 시스템 파티션에 필요한 메커니즘은 거의 식별되거나 사용되지 않고 있습니다. 따라서 솔루션의 논리 토폴로지에 대한 결정과
비기능적 요구사항에 의해 부과된 제한조건은 세부 디자인 및 구현 중간 산출물을 생성하기 전에 모델 레벨에서 쉽게 다룰 수 있습니다. 다음 페이지에서는 이러한 추론을 허용하는 단순 모델 요소 세트를 개략적으로
설명합니다. 이러한 요소는 서비스 지향 솔루션을 기반으로 개발되었으므로 모든 소프트웨어 아키텍처 모델링에 적용할 수 있습니다.
다음 정의는 RUP(Rational Unified Process) 용어집에서 발췌한 내용이며 계층 및 파티션 개념을 비교합니다. 흥미로운 사실은 층이라는 용어는 솔루션의 논리 아키텍처를 설명하는 데
일반적으로 사용되지만 RUP 용어집에는 나와 있지 않다는 것입니다.
-
계층
-
(1) 동일한 추상 레벨에서 모델에 패키지를 그룹화하는 구체적인 방법
-
(2) 동일한 추상 레벨의 클래스류 또는 패키지 조직. 계층은 아키텍처의 수평 분할을 나타내는 반면 파티션은 수직 분할을 나타냅니다.
-
파티션
-
(1) 활동 그래프: 조치의 책임을 구성하는 활동 그래프의 일부. 스윔레인도 참조하십시오.
-
(2) 아키텍처: 동일한 추상 레벨의 클래스류 또는 패키지 서브세트. 파티션은 아키텍처의 수직 분할을 나타내는 반면 계층은 수평 분할을 나타냅니다.
따라서 파티션에는 특정 아키텍처 파트를 나타내는 요소 세트가 포함됩니다. 소프트웨어 설계자가 모델을 분할하는 방법은 설명상으로는 간단합니다. 즉, 파티션과 계층은 조직적인 구조로서, 아키텍처 레벨에서는
논리 조직만 나타냅니다. 또한 솔루션 조직에서 나타낼 측면을 이해해야 합니다. 예를 들어, 개발 대상 모델 보기가 보안과 관련이 있는 경우, 신뢰 영역을 나타낼 수 있습니다[JOHNSTON].
자세한 정보는 계층화 및 분배
패턴 개념을 참조하십시오.
파티션의 의미
앞에서 말한 것처럼 파티션은 설계자가 중요시하는 특정 조직 관심사항을 나타내는 데 사용됩니다. 다음은 모델에 구성되는 공통 보기입니다. 파티션의 중요 측면 중 하나는 파티션이 소유권/포함을 의미하지 않으므로 하나의
서비스가 여러 파티션에 동시에 나타날 수 있다는 것입니다.
논리 솔루션 조직: 이 경우 파티션은 특정 솔루션의 논리 요소 클러스터링을 나타냅니다. 예를 들어, 비즈니스 응용프로그램의 경우 파티션을 사용하여 통합 서비스, 비즈니스 서비스 및 하부 구조 서비스로의
분할을 나타낼 수 있습니다. 이러한 보기는 RUP에서 응용프로그램 층을 설명하기 위해 계층을 사용하는 것에 해당합니다. 그러나 컴포넌트 또는 오브젝트 기반 솔루션과 동일한 방식으로도 서비스 계층을 쉽게 지정할 수
없으므로 파티션을 사용합니다. 이 서비스 분류에 대한 자세한 정보는 개념:
서비스 포트폴리오를 참조하십시오.
상위 레벨 실제 분배: 이 경우 파티션은 로컬 대 원격 서비스를 나타내는 데 사용됩니다(최소한 실제 거리로 아키텍처에 제한조건을 부과하는 경우). 예를 들어, 고객, 계정 및 주문 서비스를 기본 데이터
센터에서 호스팅하고 전자 데이터 교환(EDI) 게이트웨이를 보조 데이터 센터에서 호스팅한다는 사실은 이 센터 간 대역폭 연결을 관리하고 이 파티션 간 통신을 주의깊게 제어해야 할 때 중요합니다.
비즈니스 응용프로그램/소유권 경계: 이 경우 파티션은 비즈니스 영역 또는 응용프로그램 영역으로 서비스 소유권을 나타내는 데 사용됩니다. 예를 들어, 특정 서비스는 인사 부서에서 "소유"하고 다른 일부는
각각 영업 부서와 마케팅 부서에서 소유하는 것으로 표시할 수 있습니다. 이제 이는 아키텍처 관심사항이 아니지만 대부분의 프로젝트는 조직의 기술 또는 아키텍처 측면이 아닌 사회, 정치적 측면을 다루어야 합니다.
이러한 측면에서 파티션을 사용하여 경계 간 서비스 상호작용 방법을 확인할 수 있으며, 이해 당사자(stakeholder)가 조직 간 변경을 지원해야 하므로 개발 프로세스에 영향을 줄 수 있습니다. 이 경우 비즈니스
분석에서 식별된 아티팩트: 비즈니스 시스템에서는 이 모델의 카테고리를 형성합니다.
비즈니스 프로세스 경계: 이 경우 파티션으로 엔드 투 엔드 프로세스 영역을 나타내고, 결과적으로 지원하는 프로세스로 서비스를 그룹화합니다. 아래 다이어그램은 프로세스 보기(어두운 부분)와 수직 막대로
표시되는 비즈니스 시스템 보기를 비교합니다. 많은 경우에 있어 이미 배치된 서비스의 이 두 보기와 프로젝트에서 계획한 서비스를 연결해야 합니다.
수직 비즈니스 영역과 교차 비즈니스 프로세스 간의 이 관계는 각 비즈니스 영역이 실제로 비즈니스를 실행하는 프로세스에 서비스를 제공하는 방법을 이해하는 데 중요합니다. 이 문서 예제의 경우, 이 보기는
이전에 식별한 서비스를 아래와 같이 새 파티션으로 다시 그룹화합니다.
프로세스 모델링과 서비스 식별 간 연결에 대한 자세한 정보는 활동: 기존 자산 분석을 참조하십시오.
서비스 모델에서는 특정 모델 요소인 서비스 파티션을 사용하여 논리 파티션을 모델링합니다. 파티션의 UML 2.0 표시는 클래스 모델 요소의 사용을
기반으로 하며(일부 사용자는 클래스의 하위 유형(예: 사용자의 요구에 더 맞는 컴포지트 또는 노드)을 사용) 컴포지트 구조를 사용하여 파티션의 서비스 및 서비스 간 통신을 정의합니다. 서비스 파티션 요소는 위의 그림에 표시되어 있으며 서비스 제공자의 인스턴스 및 기타 파티션의 인스턴스를 포함하여 원하는 위치에 작성됩니다. 서비스 파티션은 또한 하나
이상의 서비스 게이트웨이를 지정할 수 있습니다. 서비스 게이트웨이는 UML 2.0 포트로 이름 및 유형이 지정됩니다. 이
포트는 서비스와 같은 방식으로 서비스 스펙으로 유형이 지정되므로 파티션에 대한 인터페이스를 지정하는 가상 서비스로 인식될 수 있습니다.
따라서 예를 들어, 주문 관리 프로세스 영역을 위 다이어그램의 주문 입력 서비스 제공자와 동일한 인터페이스로 액세스하는 것이 올바른 방법일 수 있습니다. 이 방법은 서비스에서 파티션으로 인터페이스를 승격시키는
방법입니다. 다음 다이어그램은 이 방법과 함께, 주문 입력 서비스 제공자가 파티션 내 다른 서비스와 통신을 수행하는 방법을 보여줍니다.
서비스 게이트웨이의 기능 중 하나는 파티션 외부의 클라이언트와 내부 서비스 간의 통신 바인딩을 중개하는 것입니다. 이 기능을 사용하면 서비스가 파티션 내 특정 프로토콜 바인딩만 처리할 수 있습니다. 예를 들어,
경계 내에서 고성능 또는 보다 안전한 프로토콜을 사용하고 다른 프로토콜을 통해 클라이언트에 특정 기능을 제공할 수 있습니다. 자세한 정보는 가이드라인 서비스 중개를 참조하십시오.
또한 파티션은 UML 2.0 컴포지트 구조 사용을 기반으로 하므로 파티션과 서비스 간에 "포함" 관계가 존재하지 않으며 위에서 설명한 대로 여러 파티션 또는 보기에 동일한 서비스를 나타낼 수 있습니다. 이러한
유연성이 서비스 게이트웨이의 기능과 연결되는 경우 소프트웨어 설계자 및 디자이너는 논리 그룹 단위로 서비스 클러스터를 작성하여 서비스 게이트웨이에서 클라이언트 관련 인터페이스만 제공하도록 할 수 있습니다.
엄격한 파티션은 파티션 외부의 클라이언트/서비스가 서비스 게이트웨이를 통해 파티션 내 모든 서비스에 액세스하는 파티션입니다. 이는 서비스 파티션이 고유한 인터페이스 세트를 가지며 이에 따라 논리 상위 레벨 서비스
제공자로 표시될 수 있음을 의미합니다. 이는 특히 비즈니스 응용프로그램 경계 또는 비즈니스 프로세스 경계를 나타내는 파티션에 유용합니다. 또한 해당 프로세스에서 나머지 비즈니스에 제공하는 인터페이스와 프로세스
영역을 지원하는 서비스를 공적으로 사용 가능하게 만드는 인터페이스를 식별할 수 있습니다. 위의 주문 관리 파티션은 엄격한 파티션이지만 "엄격성"의 개념은 파티션 평가로만 평가할 수 있으며 모델 요소 자체의 특성이
아닙니다.
아래의 예제에서 왼쪽 파티션은 엄격하다고 간주되는데 이는 클라이언트(파티션 밖)가 게이트웨이를 통해 순서 지정 항목 제공자(파티션 안)와만 통신할 수 있기 때문입니다. 반면에 다이어그램의 오른쪽에 표시된 파티션은
클라이언트가 파티션 안쪽의 순서 지정 항목 제공자와 직접 통신하므로 엄격한 파티션으로 여겨지지 않습니다.
엄격한 파티션(적어도 게이트웨이에서의 사용)의 모델링은 선택적이고 파티션 간의 명시적 통신을 모델링하는(무엇을 표시하든지) 도구로 여겨져야 하며 여러 가지 목적 때문에 추가 오버헤드가 보증되지는 않는다는
것을 명심하십시오.
[JOHNSTON] Simon Johnston, Modeling Security Concerns in Service-Oriented Architecture. IBM
developerWorks 2004.
|