Architecture Styles

Batch Sequential Style

정의

• 데이터 흐름 아키텍처 스타일
  • 시스템은 데이터 셋을 조작하고 순차적으로 실행되는 독립 컴포넌트로 구성됨
  • 한 컴포넌트는 이전 컴포넌트가 완료되어야 다음이 시작됨
• 데이터는 컴포넌트 간에 whole batch로 전송됨

동기

• 여러 단계에서 데이터 셋을 조작해야 할 때
• 하나의 컴포넌트로 전체 기능을 처리하기 어려울 때 (컴포넌트들의 시퀀스에 대한 수요)
• 시스템을 재구성해야 할 때 
  • 컴포넌트를 쉽게 삽입, 제거 또는 재 정렬해야 할 때

Applicable Situation 

• 독립적인 데이터 조작 컴포넌트로 구성된 시스템(즉, 데이터 조작 집약적인 시스템)
• 컴포넌트는 데이터 흐름의 순서에 따라 순차적으로 연결됨 (병렬 처리는 지원하지 않음)
• 전체 배치에서 컴포넌트에서 다음 컴포넌트로의 데이터 전송
  
  • 결과적으로, 현재 컴포넌트가 완료되어야 다음 컴포넌트가 시작됨
• 데이터 조작 중 사용자와 상호작용이 없음

구조

• Component (컴포넌트) : 데이터 조작 단위
• Data Flow (데이터 흐름) : 컴포넌트 간 연결

장점

• 높은 재사용성 : 컴포넌트 재사용 용이
• 높은 유지 보수성 : 유지보수 및 신규 추가 또는 컴포넌트 교체 용이
• 컴포넌트 간 상호작용의 복잡성이 낮음 : 프로세싱 모듈은 블랙박스임

단점

• Interactive Application 모델링에는 적용 불가 (기능 실행 중간에 개입할 수 없음)
• 낮은 성능 및 효율성 ( 순차 처리(Sequential processing)만 지원하기 때문에)
• 사용자가 결과를 얻기 전에 시스템을 통해 모든 데이터를 준비해야 함

 

Pipe-and-Filter Style

정의 

: 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송하는 패턴

• Data-flow Architecture Style
  • 시스템은 데이터 조작 컴포넌트로 구성됨
  • 컴포넌트는 Stream에서 데이터 셋을 전송
  • 여러 컴포넌트가 병렬로 실행될 수 있음

동기 

• 데이터 스트림으로 작업해야 함
• 시스템 재구성 필요 (컴포넌트를 쉽게 삽입, 제거 또는 재정렬해야 함)
• 사용자와의 상호작용을 지원함

Applicable Situation

• 독립적인 데이터 조작 컴포넌트들로 구성된 시스템 (즉, 데이터 조작 집약적 시스템)
• 다음 컴포넌트로 전송되는 데이터 스트림
  • 결과적으로 컴포넌트는 입력 데이터 스트림이 전달될 때 기능을 시작
• 컴포넌트는 병렬로 실행될 수 있음
• 데이터 조작 중 사용자와의 상호작용 지원
• 각 컴포넌트를 쉽게 재구성할 수 있음 : 처리 단계를 교환하거나 재정렬함

Structure

- Filter 

• 독립적인 기능 단위
• 입력에서 데이터 스트림을 읽고 출력에서 데이터 스트림 생성
• 입력 스트림에 로컬 변환을 적용하고 데이터를 점진적으로 처리

- Pipe

• 컴포넌트 간에 데이터 스트림을 전송
• 서로의 존재에 대한 사전 지식 없이 필터들을 결합하는 것

- Data source

• 타깃 시스템의 입력

- Data Sink

• 마지막 필터의 출력

장점

• 전체 기능을 여러 컴포넌트로 잘게 나누어서 순차적으로 개발할 수 있다.
• 필터 유지 및 재사용 용이
  • 필터는 기능적으로 독립적이다. 
  • 다른 시스템 요소에 영향을 주지 않고 필터 구현을 쉽게 변경할 수 있도록 한다.
  • 필터의 순서를 재구성할 수 있다.
• 병렬 처리에 의한 효율성
  • 여러 필터가 동시에 실행되는 병렬 처리 지원

단점

• 상태 정보를 공유하는 데 비용이 많이 들거나 inflexibile 하다. 
• 데이터 변환 오버헤드

Batch-Sequential vs. Pipe-and-Filter

Similarity 

• 데이터 조작의 컴포넌트
• 일련의 컴포넌트는 전체 기능을 수행하기 위해 실행

Differences

	Batch-Sequential	Pipe-and-Filter
언제 입력 데이터를 처리?	모든 입력 데이터가 전달되면	입력 데이터의 스트림이 전달될 때
어떻게 데이터를 처리?	각 컴포넌트는 배치 방식으로 기능을 수행	각 컴포넌트는 기능을 점진적으로 수행
동시성 지원 여부?	동시성 없음 (순차 처리만)	동시성 가능
상호작용 지원 여부	Interactive 안됨(입력 데이터가 시스템에 전달되면 모든 컴포넌트가 실행을 중지할 수 없음)	Interactive 가능(다소 어려움)

 

Layered Architecure Style

정의

: 시스템을 계층으로 구분하여 구성하는 고전적 방법 중 하나

• 타깃 시스템은 계층 스택으로 구성
• 각 계층은 상위 계층에 서비스를 제공하고 하위 계층에 서비스를 요청함
• 레이어는 추상화 수준에 따라 정렬됨
• 각 계층은 고유한 기능을 제공
  • 상위 레이어는 "버츄얼 머신"
  • 가장 하위 레이어는 하드웨어/커널

Motiviation

• 독립적인 추상화 계층 필요(별도의 관심사, 종속성 제한, 대체 허용)

Layer vs. Tier

Layer 

• 응집력 있게 관련된 기능 단위
• 기계의 다른 폴더나 디렉터리에 있는 컴포넌트로 구성

Tier

• 여러 기계에 배치된 컴포넌트로 구성
• 일반적으로 계층은 물리적 하드웨어를 나타냄

Applicable Situation

• 타겟 시스템이 여러 레이어들로 계층적으로 잘 구성될 수 있다.
• 각 레이어는 상위 레이어에 기능을 제공하고 하위 레이어에 대한 클라이언트 역할을 한다.
• 레이어는 가상 머신으로 간주된다.
  • 인접한 상위 레이어를 제외한 다른 레이어에서 내부 레이어를 숨길 필요가 있을 때 

Structure

Layer

• 특정 추상 수준의 기능을 그 위의 레이어 또는 레이어에 제공하는 컴포넌트 모음을 포함한다.
• 레이어 간의 관계
  • 레이어에서 다음 레이어로의 호출
  • 동기 및 비동기 모두 가능("이벤트", "콜백")

장점 

• 레이어 재사용
  • 표준 인터페이스를 생성해야 한다.
  • 다른 플랫폼으로 쉽게 이식
• 레이어를 통해 위로 올라갈수록 추상화 수준 증가
  • 복잡한 문제를 쉽게 분할
• 관심사들을 알맞게 분리할 수 있다.
• 레이어별 구현이 분리되어 있어 유지보수가 상대적으로 용이
  • 한 레이어를 새 레이어로 대체하여 쉽게 수정

단점 

• 잠재적인 성능 문제
  • 레이어 간 통신으로 인한 성능 저하
  • 레이어를 통해 아래로 통신하고 백업하므로 효율성을 위해 바이패스가 발생할 수 있다.
• 적절한 추상화 수준을 찾기 어려움
  • 특히 기존 시스템이 여러 레이어를 교차하는 경우
• 구현 유연성 감소
  • 시스템 구성이 어려울 수 있다.

 

Model-View-Controller Style

정의

: 서브시스템을 3개의 부분으로 구조화하는 패턴

- Layered Architecture style

• 애플리케이션은 3개의 레이어로 나뉩니다.
• View는 사용자와 상호작용한다.
• Controller는 사용자 입력으로 업무처리를 수행한다.
• Model은 영구 데이터 세트를 관리한다.

Motivation

• 원래 GUI 응용 프로그램에 의해 모티브가 됨
  • 사용자 뷰의 'Look and feel'은 시간이 지남에 따라 많이 변하는 경향이 있다.
  • 때로는 기본 기술도 변경이 된다.
  • 변경 사항은 애플리케이션의 전체 기능에 영향을 미칠 수 있다.
  • UI 변경의 영향을 최소화해야 한다.
• 많은 현대 애플리케이션에 적용할 수 있음

Applicable Situation

• 시스템은 사용자 인터페이스 제공, 워크플로 처리 및 데이터 지속성 관리의 3가지 역할로 이상적으로 분할될 수 있는 경우 (View, Control, Model에 각각 해당)
• 시스템은 사용자 인터페이스의 다중 구현이 필요한 경우 
  • 다양한 GUI 플랫폼을 위한 다양한 사용자 인터페이스
  • 기능의 다양한 가용성을 위한 다른 사용자 인터페이스(사용자의 역할, 시간대, 'Look and Fell', 기타)
• 사용자 인터페이스의 변경이 다른 계층에 미치는 영향을 최소해야 하는 경우
• 시스템은 기본 데이터베이스 스키마와 독립적으로 영구 데이터 세트에 액세스 하기 위한 안정적인 인터페이스를 제공해야 한다.

구조

Model

• 데이터 모델을 표현하기 위해
• 애플리케이션의 기능적 핵심을 제공하기 위해
• 데이터 변경 사항에 대해 종속 컴포넌트들에 알리기 위해

View

• 사용자에게 정보를 표시하기 위해
• Model로부터 알림을 받은 후 Model에서 데이터를 가져오기 위해

Controller

• 사용자 입력을 처리하기 위해
• 이벤트(즉, 사용자 입력)를 Model에 대한 서비스 요청으로 변환

장점

• 3가지 관심사의 분리
  • 시스템은 종종 3가지 관심사로 구성된다; 유저 인터랙션, workflow, persistent 데이터 관리
  • MVC는 이러한 문제를 Model, View, Control 레이어에 반영한다.
• 동일한 Model을 사용하는 다중 뷰 구현이 가능
  • 모델 컴포넌트는 구현, 테스트 및 유지 관리가 더 쉽다.
• 새로운 유형의 클라이언트를 추가하는데 더 쉽다.
  • 뷰와 컨트롤러를 작성하여 기존 엔터프라이즈 모델에 연결한다.
• 뷰 및 컨트롤러를 언제든지 교체할 수 있다. (Pluggable)
  • MVC의 개념적 분리를 통해 모델의 뷰 및 컨트롤러 객체를 교환할 수 있다.

단점

• 약간의 설계 복잡성
  • MVC는 모델, 뷰 및 컨트롤러의 분리로 인해 일부 클래스와 코드를 추가해야 함
• 잦은 이벤트에 불편함 (3가지 레이어를 거쳐야 하기 때문에)

 

Shared Repository Architecture Style

정의

• 데이터 중심 아키텍처 스타일
  • 모든 공유 데이터는 모든 컴포넌트에서 액세스 할 수 있는 중앙 DB에 보관된다.
• 각 컴포넌트는 공유 데이터를 통해 데이터를 교환한다.
  • 컴포넌트들은 저장소에 데이터를 쓴다.
  • 컴포넌트들은 저장소에서 데이터를 읽는다.

Applicable Situation

• 애플리케이션들이 공통 데이터 세트를 공유해야 할 때
• 애플리케이션 간 데이터 셋 공유를 위한 고효율성이 필요할 때 (공유 저장소에 직접 접근)
• 데이터 조작 기능에서 데이터 저장소를 격리해야 할 때

구조

Data Repository

• 컴포넌트들에서 교환해야 하는 모든 데이터를 저장하는 곳

Data Accessor

• 독립 컴퓨팅 컴포넌트
• 공유 데이터 저장소에 직접 액세스(중간 계층 없음)

장점

• 대용량 데이터를 효율적으로 공유하는 방법
  • 한 서브시스템에서 다른 서브시스템으로 데이터를 명시적으로 전송할 필요가 없음
• 컴포넌트 수정 용이
  • 컴포넌트가 서로 의존하지 않고 새로운 컴포넌트 추가가 용이
• 일관된 데이터에 대한 동시 액세스 지원
• 관심사 분리 가능
  • 컴포넌트는 다음 문제에 관심을 두지 않고 주요 기능에 집중할 수 있다(백업, 보안, 접근통제 및 장애 복구)

단점

• Repository의 Data Schema 관리가 어려움
  • 공유 저장소의 구조를 변경하면 컴포넌트들에 큰 영향을 미침
• 잠재적인 성능 문제
  • 컴포넌트들(클라이언트들) 간의 통신이 느릴 수 있다.
• 데이터 보안에 대한 우려
• 가용성에 대한 우려

 

Blackboard Architecture Style

정의

: 모든 컴포넌트들이 공유 데이터 저장소와 블랙보드 컴포넌트에 접근이 가능한 형태

• 데이터 중심 아키텍처 스타일
  • 독립 프로그램을 Blackboard라고 하는 글로벌 데이터 저장소를 통해 독점적으로 통신한다.
  • 전문가가 데이터 셋 또는 문제의 일부를 해결하고 해당 솔루션을 게시한 후 다른 전문가가 문제를 식별한다. (전체 문제가 해결될 때 까지 프로세스가 계속됨)
  • 독립적인 프로그램들은 부분적 또는 대략적인 솔루션을 구축하기 위해 지식을 수집한다.
• 공유 저장소 스타일과의 차이점
  • Shared Repository Style의 Shared Data는 Passive하고 Blackboard는 Active하다.
    • Blackboard는 관심 데이터가 변경될 때 컴포넌트들에게 알림을 보낸다.

Applicable Situation

• 결정론적(deterministic) 솔루션 전략이 알려져 있지 않은 문제
  • 솔루션 전략에 대한 근접한 Approach가 알려져 있지 않거나 실현 가능성이 없는 미성숙한 문제 영역
  • 예시(복잡한 데이터 해석, 신호 처리, 음성/패턴 인식 등)
• 컴포넌트들은 공유 상태를 통해서만 연결되어야 함(통신 컴포넌트들은 서로를 알지 못함, 즉 느슨하게 연결됨)

구조

Blackboard

• 중앙 데이터 저장소를 관리

Knowledge Source

• 새로운 데이터를 생성하고 Blackboard에 업데이트하는 독립 컴포넌트
• 문제를 해결하는 데 필요한 지식을 포함하는 독립 컴포넌트

Control

• Knowledge Source들 간의 전송 제어
  • 문제 해결 과정과 문제 해결 자원의 지출에 대한 런타임 결정을 내림
• 공유 blackboard를 모니터링

장점

• 실행 가능한 deterministic 솔루션이 없는 문제에 적응함(adapted)
• 오픈 데이터 표현 지원 (Supporting Open Data representation)
  • Repository들에서 서로 다른 컴포넌트를 연결하고 작동할 수 있도록 한다.
• Knowledge source 추가가 쉬움
  • Knowledge source 간의 독립성으로 인해

단점

• Optimal Solution(최적 솔루션)은 얻기 어렵다(단, 부분적 솔루션 또는 근사적 솔루션만)
• 변경 또는 진화가 어려운 Blackboard (knowledge source들은 데이터베이스 구조에 동의해야 함)
• 잠재적인 성능 문제
  • 컴포넌트들 (클라이언트들) 간의 통신이 느릴 수 있다.
  • Blackboard는 너무 많은 클라이언트들로 병목 현상이 된다.
• 시스템 디버깅 및 테스트 어려움

 

Broker Architecture Style

정의

: 사용자가 원하는 서비스, 특성을 브로커 컴포넌트에 요청 > 브로커 컴포넌트가 요청에 맞는 컴포넌트와 사용자를 연결

• 로드 밸런싱 아키텍처 스타일
  
  • 분산 컴퓨팅에서 등록된 서버와 클라이언트 간의 통신을 조정하고 용이하게 하는 데 사용
  • 브로커 컴포넌트는 요청 전달과 같은 통신 조정과 결과 및 예외 전송을 담당함 -> 시스템의 유연성 증가
  • 각 클라이언트는 서버 컴포넌트와 직접 통신하지 않고 브로커에 요청을 보냄
  • 클라이언트는 서버의 위치를 알 필요가 없음

Applicable Situation

• 서버들 복제 필요
• 높은 QoS로 서버를 호출해야 함
• 서버에서 클라이언트 분리
  • 분산된 heterogenous (이기종) 환경에서 분리되고 상호 작용하는 컴포넌트 집합으로 복잡한 시스템을 구조화해야 할 때
• 유연성과 변경 가능성을 향상하기 위해

구조

Client

• 사용자 기능 구현
• 조회를 통해 정적으로 또는 동적으로 브로커에게 서버의 서비스를 요청

Stub (Client-side-Proxy)

• 클라이언트와 브로커 사이를 중재
• 프로토콜 수준에서 프로세스 간 통신을 숨김으로써 그들 사이의 투명성을 제공

Server

• 브로커에 인터페이스를 등록하고 게시하여 클라이언트가 사용할 수 있는 서비스를 제공

Skeleton (Service-side Proxy)

• 서버와 브로커를 중재
• 저수준 시스템별 네트워킹 기능을 캡슐화

Broker

• 커뮤니케이션을 조율하는 역할
  • 서비스 요청 중개, 적절한 서버 찾기, 요청 전달 및 발송, 클라이언트에 응답 또는 예외 보내기
  • 클라이언트와 서버 간의 연결을 유지

Bridge (Optional)

• 두 브로커가 상호 운용할 때 구현 세부 정보를 숨김
• 기본 네트워크 세부 구현을 캡슐화하여 로클 브로커와 원격 브로커 브리지 간의 중재

Relationships among Components

• 회신/요청 (메소드 호출 형식)

Constraints

• 서버와 클라이언트는 브로커를 통해 서로 상호 작용

장점

• 위치 투명성
• 컴포넌트들의 변경 가능성 및 확장성
• 브로커 시스템의 Portability
• 서로 다른 브로커 시스템 간의 상호 운용성
• 시스템 재사용성
• QoS가 높아진다 (안정성, 가용성, 성능과 연관)

단점

• 프록시 오버헤드로 인한 제한된 효율성
• 낮은 Fault Tolerance
• 테스트 및 디버깅이 어려움 (관련된 많은 컴포넌트로 인해)

 

Dispatcher Architecture Style

정의

• 로드 밸런싱 아키텍처 스타일
  • 시스템은 세 부분으로 구성된다. 클라이언트, 서버 및 디스패처
• 고가용성, 안정성, 성능 및 확장성을 제공하기 위해 다수의 이중화 서버가 활용됨
• Dispatcher는 서버의 디렉터리와 디렉터리에 있는 서버의 QoS값을 유지관리
• 클라이언트는 서버 조회 시 디스패처는 QoS가 높은 서버를 찾아 서버 참조를 클라이언트에 보냄, 이후 클라이언트는 세션 중에 서버를 직접 호출

Applicable Situation

• Broker 아키텍처 스타일과 유사
  • 서버들 복제 필요
  • 높은 QoS로 서버를 호출해야 함
• 최소한의 디커플링 및 고효율
  • 클라이언트 프로그램은 QoS가 높은 서버와 직접 상호작용
• 유연성과 변경 가능성을 향상하기 위해

구조 

Components

• Server
• Client
• Dispatcher
  • 서버 디렉터리
  • 클라이언트 디렉터리

Connectors

• 제어 흐름 (클라이언트, 서버, 디스패처 사이)

Options

• Single Dispatcher
• Multiple Dispatchers

Elements of Dispatcher

• View Layer
  • Client Interface
  • Server Interface
• Control Layer
  • Server Locator
  • QoS Evaluator
• Model Layer
  • Client 
  • Server

장점

• 고성능
  
  • 단일 서버에서 전체 기능을 실행하는 오버헤드는 여러 서버에 대한 기능 분할로 인해 해결할 수 있음
  • 적절한 서버를 찾고 할당하기 위해 중개자를 고용하면 오버헤드는 최소화된다. 클라이언트는 세션 중에 할당된 서버와 직접 상호작용함
• 고가용성 및 안정성
  • 클라이언트 부하의 로드 밸런싱
  • 클라이언트의 부하를 동적으로 균형 조정하여 한 서버의 오류 또는 오류를 허용할 수 있음
• 높은 확장성
  • 시스템의 다른 부분에 영향을 주지 않고 서버 수를 늘리거나 업데이트할 수 있음

단점

• 최소의 성능 오버헤드
  
  • 적절한 서버를 동적으로 찾고 할당하려면 어느 정도의 오버헤드가 있다. 오버헤드에는 서버의 QoS값을 계산하는 비용이 포함
• 최소의 신뢰성 위험
  • 시스템 신뢰성은 디스패처의 오류 또는 장애에 의해 영향을 받음
  • 이것은 단일 디스패처 모델에서 더 심함

 

Microservice Architecture Style

정의

• 서비스 기반 아키텍처 스타일
  • SOA 스타일의 변형
  • 작고 자율적인 서비스의 집합체로 구성
• 마이크로 서비스
  • 독립적이며 단일 비즈니스 기능을 구현해야 한다.
  • 표준화된 API를 통해 다른 서비스와 커뮤니케이션하며 다른 언어 또는 다른 기술로 작성된 서비스를 실행할 수 있다.

Applicable Situation

• 서비스 소비자
  • 외부 서비스를 통해 충족될 수 있는 기능들이 있을 때
  • 서비스 공급업체가 존재할 때
• 서비스 공급자
  • 공동 서비스에 대한 수요가 높을 때
  • 서비스 소비자가 존재할 때

구조

Microservice

• 작고 독립적이며 느슨하게 결합된 기능 장치
• 단일 소규모 개발자 팀에 의해 개발 및 유지 관리
• 독립적으로 구현됨 (팀은 전체 애플리케이션을 재구축 및 재배포하지 않고도 기존 서비스를 업데이트할 수 있음)
• 자신의 데이터 또는 외부 상태를 유지하는 책임
• 잘 정의된 API를 사용하여 서로 통신
• 서비스는 동일한 기술 스택, 라이브러리 또는 프레임워크를 공유할 필요가 없음

API Gateway

• 클라이언트들을 위한 진입점
  • 서비스를 직접 호출하는 대신 클라이언트가 API 게이트웨이를 호출하여 백엔드의 적절한 서비스로 호출을 전달함
• API 게이트웨이를 사용하는 장점은 다음과 같음
  • 클라이언트를 서비스에서 분리, 모든 클라이언트를 업데이트할 필요 없이 서비스의 버전을 지정하거나 리팩터링 할 수 있음
  • 서비스는 AMQP와 같이 웹 친화적이지 않은 메시징 프로토콜을 사용할 수 있음
  • API Gateway는 인증, 로깅, SSL 종료 및 로드 밸런싱과 같은 다른 교차 기능을 수행할 수 있음

장점

• 높은 민첩성
  • 독립적으로 배포되어 버그 수정 및 기능 릴리스 관리 용이
  • 전체 애플리케이션을 재배포하지 않고도 서비스 업데이트 용이
• 소규모 집중 팀이 개발하기 쉬움
  • 마이크로 서비스는 단일 기능 팀이 빌드, 테스트 및 배포할 수 있을 만큼 적당해야 함
  • 소규모 팀 규모는 더 큰 민첩성을 촉진함
• 신기술 적용 용이
  • 팀은 적절하게 혼합된 기술 스택을 사용하여 서비스에 가장 적합한 기술을 선택할 수 있음
• 고립된 장애 덕분에 장애 관리 용이
  • 개별 마이크로서비스를 사용할 수 없게 되더라도 업스트림 마이크로서비스가 오류를 올바르게 처리하도록 설계된 한 전체 애플리케이션을 방해하지 않는다.
• 더 높은 확장성
  • 전체 애플리케이션을 확장하지 않고 독립적으로 확장된다.
• 데이터 격리
  • 단일 마이크로서비스만 영향을 받기 때문에 스키마 업데이트를 수행하기가 더 쉽다.

단점

• 장애 관리가 어렵다
  • 네트워크 혼잡 및 지연
• 잠재적으로 낮은 성능
  • 네트워크를 통한 호출
• 관리 방식의 부재
  • 마이크로 서비스 구축에 대한 분산된 접근 방식
  • 응용 프로그램을 유지 관리하기 어렵게 되는 많은 다른 언어 및 프레임워크
• 데이터 무결성/일관성을 유지하기 어려움
  • 각 마이크로서비스는 자체 데이터 지속성을 책임진다. 결과적으로 데이터 일관성이 문제가 될 수 있음
• 여러 서비스의 어려운 버전 관리
  • 언제든지 업데이트될 수 있으므로 신중하게 설계하지 않으면 이전 버전 또는 이전 버전과의 호환성에 문제가 발생할 수 있음

 

MicroKernel Architecture Style

정의

• 적응형 아키텍처 스타일
  • 핵심 커널과 플러그인 컴포넌트 세트로 대상 시스템을 구성
  • 플러그 앤 플레이 인프라 활용
• 핵심 기능을 가변 부분과 분리
  • Open-Closed 원리 적용

Applicable Situations

• 시스템은 다른 구현에서 동적으로 구성되어야 함
  • 플러그인 컴포넌트들로 가변성을 구현
• 시스템은 변화하는 시스템 요구 사항에 효과적으로 적응할 수 있도록 설계되어야 함
• 애플리케이션/버전 제품군
  • 공통 아키텍처 및 가변 플러그인 컴포넌트를 채택함
  • 낮은 유지 비용

구조

• 코어 시스템, 즉 Microkernel(폐쇄형 설계)
• 플러그인 컴포넌트들 (개방형 설계, 플러그인에 필요한 인터페이스)

장점

• 높은 유연성 및 확장성
  • 플러그인 컴포넌트를 사용하여 수정 또는 확장할 수 있음
• 높은 호환성(Portability)
  • 시스템은 마이크로커널을 수정해야만 새로운 환경에 보고될 수 있음
• 높은 유지 보수성
  • Core System과 Plug-in 분리로 인해

단점

• 호환성을 위한 플러그인 검증 필요
  • 하나의 애플리케이션 실행 내에서 훨씬 더 많은 프로세스 간 통신이 필요함
• 모놀리식 시스템에 비해 복잡한 설계 및 구현

 

Event-Driven Architecture Style

정의

• 이벤트 기반 아키텍처 스타일
  • 프로시저를 직접 호출하는 대신 독립 컴포넌트들은 이벤트 버스를 통해 전달되는 이벤트를 비동기적으로 보내고 받음
  • Publish-Subscribe와 달리 게시자와 구독자의 구분이 없음
  • 시스템의 다른 컴포넌트들은 이벤트와 프로시저를 연결하여 이벤트에 관심을 등록할수 있음
  • 이벤트가 공지되면 방송 시스템(커넥터) 자체에서 이벤트에 등록된 모든 절차를 호출함
• 이벤트 알림은 "암시적으로" 다른 모듈의 프로시저 호출을 유발함

Applicable Situations

• lossely 결합된 이벤트 이미터 및 이벤트 처리기로 시스템을 구성할 때 
• 명확한 관심사 분리
  • Event Source/Emitter
  • Event Handler
• 높은 시스템 구성 가능성
  • Event Handler에 Open Design 적용

장점

• 컴포넌트의 분리 및 자율성
• 높은 재사용성
  • 기존 컴포넌트에 영향을 주지 않고 새로운 컴포넌트를 쉽게 추가할 수 있음
  • 해당 시스템의 이벤트에 등록하기만 하면 컴포넌트를 시스템에 도입할 수 있음
• 높은 유지 보수성
  • 컴포넌트는 시스템의 다른 컴포넌트 인터페이스에 영향을 주지 않고 다른 컴포넌트로 대체될 수 있음
• 이벤트 처리(Event Handling)의 병렬 실행
• 높은 확장성

단점

• 낮은 신뢰성(Reliability)
  • 이벤트의 성공적인 전달을 보장하지 않음
• 불확실성
  • 다른 컴포넌트가 그것에 대해 어떤 반응을 보일지 알기 어려움
  • 응답이 호출되는 순서를 예측하기 어려움
  • 언제 응답이 끝났는지 알기 어려움
• 정확성을 보장하기 어려움
  • Listener들의 응답 및 응답 순서를 예측하고 검증하기 어렵기 때문에 시스템을 테스트하고 디버그하기 어려움
  • 정확성은 컨텍스트와 호출 순서에 따라 다름

 

Service-Oriented Architecture Style

정의 : 

- Service-based Architecture Style

    - To consist of a collection of distributed components that provide and/or consume services

    - Service Provider and Service Comsumer

- Service is a self-contained functionality.

    - Not to depend on state of other services, or of the system it is running on

- Service is black box for its consumers

    - Meaning the consumer does not have to be aware of the service's inner workings

 

Applicable Situations

- A system can be organized with a collection of independent services with well-defined interfaces

- Service are for reusability.

- A service is a group of methods that contain the business logic.

- A service is accessible through the Internet.

 

Structure

- Service Provider 

    - To provide one ore more services thorugh published interfaces

- Service Consumer

    - To invoke services directly or thorugh an intermediary

- Service Registry

    - By providers to register their services

    - By consumers to query and discover services at runtime

- ESB / Orchestration Server

    - Orchestration Server to coordinate interaction between providers and consumers

    - Enterprise Service Bus to route messages

- Relationships among Components

    - Universal message-oriented protocols like SOAP and REST

- Constraints

    - Service consumers are connected to service providers, but intermediary components (such as ESB) may be used.

    - Application is built ad-hoc out of services that communicate in a standardized manner. (via a network)

    - service providers may also be service consumers.

장점 : 

- High Reusability of Services

    - Easy to develop SOA-based business application development much more efficient in terms of time and cost

- Easy to evolve and update the system

   - Due to the loosely coupled connections between clients and services

- High Interoperability

    - Any client or service can access other services regardless of their platform, technology, vendors, or language implementations.

- Loosely-coupled connections

    - Between service, Between service consumers and service providers, Between service interface and implementation

단점 : 

- High Complexity of Design

- Performance Penalty (Due to network latency, Due to the broker)

- Low Fault Management

   - Consumers have limited manageability of services.