3.1 아키텍쳐 뷰(architecture view)
SOA 기반의 레퍼런스 아키텍처(SOA-based Reference Architecture)는 다음과 같이 크게 3개의 아키텍처로 구성된다.
● 애플리케이션 아키텍쳐(application architecture)
하나 이상의 여러 서비스 공급자(service provider)가 제공하는 서비스를 사용하여 비즈니스가 직면해 있는 문제에 대하여 솔루션을 구성한다.
● 서비스 아키텍처(service architecture)
비즈니스의 핵심 기능을 표현하는 비즈니스 서비스 집합의 논리적인 관점을 제공하며, 서비스 구현과 소비자 애플리케이션 사이를 연결하는 역할을 한다.
● 컴포넌트 아키텍처(component architecture)
구현된 애플리케이션, 비즈니스 객체 및 구현 등을 지원하는 다양한 환경을 표현한다.
3.2 서비스 아키텍처(service architecture)
SOA 기반 레퍼런스 아키텍처의 중심에는 서비스 아키텍처(service architecture)가 있다. 서비스 아키텍처는 공유 비즈니스 서비스의 공급자 관점에서 비즈니스의 핵심 기능을 표현하는 비즈니스 서비스 집합의 논리적인 관점을 제공하며, 비즈니스 프로세스 레이어 (business process layer)와 비즈니스 서비스 레이어(business service layer), 그리고 이들 서비스 레이어에 기반구조(infras-tructure)를 제공하는 인프라 서비스(infra service) 등 3개의 레이어로 구분된다.
비즈니스 프로세스 레이어 (business process layer)는 비즈니스 프로세스 로직에 다라 비즈니스 서비스를 통합하는 서비스를 제공한다. 따라서 비즈니스 프로세스 레이어에는 프로세스 서비스(process-centric service)가 놓이게 된다.
비즈니스 서비스의 통합구성에는 두 가지 접근 방법이 있다. 하나는 오케스트레이션(orchestration)이고, 다른 하나는 코리오그라피(choreography)이다. 이들 두 개념은 비즈니스 서비스의 통합이라는 면에서 어느 정도 중첩된다. 그러나 오케스트레이션은 비즈니스 프로세스 관점에서 비즈니스 서비스를 통합하지만, 코리오그라피는 비즈니스 협업(business collaboration)이란 관점에서 비즈니스 서비스를 통합한다는 점에서 다르다.
오케스트레이션은 주로 기존의 비즈니스 서비스를 재사용하는 복합 서비스(composite service) 또는 프로세스 서비스(process service)를 정의하기 위해서 사용한다. 이에 대하여 코리오그라피는 여러 참여자가 보다 큰 비즈니스 트랜잭션(business transaction)의 일부로서 거래 파트너끼리 메시지를 교환함으로써 피어-투-피어(peer to-peer) 방식으로 협업하는 방식을 정의하기 위해 사용된다.
오케스트레이션과 코리오그라피 사이의 커다란 차이점은 오케스트레이션이 비즈니스 프로세스를 주도하는 하나의 참여자 관점에서 여러 비즈니스를 통합하는 계층적인 요청자/공급자(hierarchical requester/provider) 모델을 사용하는 반면에, 코리오그라피는 비즈니스 프로세스 안에서 다수의 참여자가 피어-투-피어(peer-to-peer) 방식으로 협업하는 모델을 사용한다는 것이다. 따라서 기업 내부 프로세스 통합을 위해서는 오케스트레이션을 사용하고, 기업사이의 프로세스 통합에는 코리오그라피를 사용하는 것이 바람직하다.
비즈니스 서비스 레이어(business service layer)는 비즈니스의 핵심 기능을 표현하는 비즈니스 서비스를 제공한다. 따라서 비즈니스 서비스 레이어에는 기본 서비스(basic service)와 공개 서비스(public enterprise service), 그리고 중개 서비스(intermeriary service)가 놓인다. 비즈니스 서비스 레이어의 서비스들은 스스로 비즈니스 로직을 구현함으로써 서비스를 제공하기도 하지만, 주로 컴포넌트 아키텍처(component architecture)에 컴포넌트로 구현되어 있는 서비스 구현과 소비자 애플리케이션 사이를 연결하는 역할을 한다. 또한, 중개 서비스를 통해서 메인 프레임이나 ERP(enterprise resource planning) 등 기존의 IT 리소스에 접근하여 게이트웨이나 어댑터, 또는 퍼
사드 등의 역할을 수행함으로써 레거시 시스템을 재사용할 수 있게 한다.
인프라 서비스(infra service)는 이들 레이어의 서비스들의 배포를 위한 공통적인 기반을 제공하며, 여기에는 위치 독립성(location independence), 실패 복구(fail over), 서비스 및 프로세스 관리, 그리고 기타 QoS(quality of service) 특성들을 제공하기 위한 서비스들이 포함된다.
공통 서비스(common service)에는 로깅(logging), 감사(auditing), 보안(security), 에러처리(error handling)와 같이 모든 서비스에 필요한 핵심 기능이 제공된다. 서비스 버스(service bus)는 일반적인 미들웨어 솔루션에서의 전통적인 메시지 브로커(message broker) 또는 소프트웨어 버스(software bus)와 같은 방식으로 라우팅(routing)과 변형(transformation) 서비스를 제공하며, ESB(enterprise service bus)
개념을 활용할 수 있다. 서비스 관리(service management)에는 비즈니스 서비스와 비즈니스 프로세스를 관리하고 모니터링하는 기능이 제공되며, 여기에는 비즈니스 서비스 레파지토리(repository) BPM(business process management), BAM(business activity monitoring) 등이 포함된다. 이들 인프라 서비스는 많은 기업에 있어서 새로운 개념이 되겠지만, 서비스 지향 엔터프라이즈(service-oriented enterprise)를 성공적으로 구축하기 위한 핵심이 된다.
3.3 애플리케이션 아키텍처(application architecture)
애플리케이션 아키텍처(application architecture)는 서비스 아키텍처의 소비자 관점에서 정의되는 개별 애플리케이션의 솔루션을 표현한다. 일반적으로 애플리케이션 아키텍처에서는 서비스 아키텍처에서 제공하는 공유 비즈니스 서비스를 사용하여 비즈니스가 직면해 있는 문제에 대하여 솔루션을 구성하게 된다. 그러나 공유 비즈니스 서비스가 제공하지 않는 솔루션에 대해서는 애플리케이션 아키텍처 자체에서 개별적으로 구현할 수 있으며, 자체 구현을 위한 데이터의 정보를 별도의 데이터베이스를 통해 관리할 수 있다.
3.4 컴포넌트 아키텍처(component architecture)
컴포넌트 아키텍처(component architecture)는 서비스 아키텍처의 구현 관점에서 공유 비즈니스 서비스의 구현 기능을 제공한다. 컴포넌트 아키텍처 도입의 가장 큰 이점은 기존의 IT 리소스를 재사용할 수 있게 한다는 사실이다. 이전까지 주류를 이루던 CBD(component-based development) 환경에서 구현되었던 비즈니스 서비스의 구현 세부사항을 애플리케이션 아키텍처에게 감춤으로써, 애플리케이션 아키텍처에 독립적으로 컴포넌트 아키텍처를 자유롭게 변경 및 구성할 수 있게 된다.
[출처: 06/04/29 MSDN 세미나 - 전병선]
[출처] SOA로 가는길 - 3. SOA 기반 레퍼런스 아키텍처|작성자 마음대로
덧글