서비스 아키텍처 : 서비스 모델의 필요성 : 개념, 정의, 개요

서비스 기반 모델링

먼저 이 비즈니스 도메인 자체를 잘 이해하고 시뮬레이션 할 수 있어야 합니다. 그러한 것을 잘하기 위해서는 먼저 사용자가 사용해야 되는 서비스가 무엇이고 그 주요 특성과 기능들이 무엇인지를 먼저 잘 표현해야 합니다. 그래서 서비스 기반의 모델링이라는 것은 엔터프라이즈 시스템 구축의 문제를 체계적이고 전략적으로 풀기 위해서 소프트웨어 모델링의 원칙과 기술을 효과적으로 활용하는 것을 의미합니다.

세 가지 원칙이 있습니다. 첫째는 Virtualization, 즉 가상화입니다. 가상화의 원칙은 서비스의 행위, 구조, 관계를 매우 높은 수준에서 모델링해야 한다는 의미를 말합니다.

두 번째는 서비스 모델링의 원칙은 Metamorphosis, 즉 변화에 대한 반영이 필요하다는 것입니다. 비즈니스 환경은 매우 다양한 요소에 의해 영향을 받습니다. 이러한 요인들에 대해서 모델링을 하고, 그러한 요인들의 서비스의 행위, 구조, 관계의 변형에 대해서 어떻게 영향을 미치는지 모델링해야 합니다.

세 번째 모델링 원칙은 Literate Modeling입니다. 서비스를 사람, 사용자 관점에서 모델링하라는 의미입니다. 즉, 사용자의 특성, 특히 사용자의 행위나 사용자 간의 상호작용과 협업 관계를 서비스 모델링에 반영해야 합니다. 이러한 이 개념은 Literate Programming은 일반적인 전산학에서 사람 중심으로 사람이 이해하기 쉬운 프로그램을 만들라는 Literate Programming의 개념에서 유래되었습니다.

 

 

Service Identification

서비스 모델링 과정에서 가장 중요한 것은 비즈니스에 꼭 필요로 하는 서비스를 식별해내는 것입니다. 중요한 서비스를 잘 식별해내는 것이 좋은 SOA 시스템을 구축하는 성공요인입니다. 가장 중요한 것은 비즈니스 골을 명확히 파악하고 그것을 기반으로 활용 가능한 서비스를 레거시 시스템들로부터 얻어올 것인지 아니면 파트너로부터 받을 것인지를 찾습니다.

어떠한 새로운 서비스가 새로 개발돼야 하는지 그러한 결정을 내리는 것입니다. 그리고 이러한 서비스 식별 과정은 한 번에 일어나는 것이 아니라 점진적으로 반복을 해서 더 상세하고 더 중요한 서비스를 도출하는 과정이 이루어집니다.

 

 

서비스 모델링 방법 및 절차

가장 널리 사용되는 서비스 모델링 방법으로 SOMA, 즉 Service-Oriented Modeling and Architecture이 있습니다. SOMA 방법론은 2004년에 IBM에서 효과적인 SOA 구축을 위해 개발한 것으로서 점진적이고 반복적인 모델링 방법입니다. 이 방법론에서는 비즈니스 관점에서 점진적으로 서비스를 도출하는 Top-down 기법과 기존의 레거시 시스템으로부터 서비스를 점진적으로 도출하는 Bottom-up 기법이 함께 사용됩니다.

 

서비스 아키텍처 : 서비스 모델의 필요성 : 개념, 정의, 개요

 

그러한 Top-down과 Bottom-up 서비스 도출 과정을 보여줍니다. 비즈니스 관점에서는 맨 상위에 있는 서비스 소비자들이 어떠한 Goal을 달성해야 하는 건지 분석해서 그 Goal 달성에 필요로 하는 비즈니스 프로세스들을 파악합니다. 그리고 그러한 비즈니스 프로세스를 정의한 이후에 그 수행에 필요한 서비스를 도출하는 단계로 Top-down 서비스 식별 과정이 이루어지게 됩니다.

반면에 Bottom-up식 서비스 식별 과정은 이미 기업, 엔터프라이즈에 운용 중인 기존 레거시 시스템들로부터 핵심 컴포넌트들을 뽑아냅니다. 이들로부터 어떻게 보면 그 비즈니스에서 유용하게 사용할 수 있는 서비스를 식별해낼 수 있는지를 모색해서 그런 것들을 Component화합니다. 그 Component로부터 서비스를 제공하기 위한 그런 API들을 정의합니다.

이러한 Top-down과 Bottom-up 서비스 식별 과정은 동시에 일어나면서 또 점진적으로 반복이 됩니다. 이러한 과정의 반복을 통해서 궁극적으로 비즈니스 도메인에서 유용하게 활용할 수 있는 서비스들을 식별하게 됩니다. 그러한 서비스들을 모아서 SOA를 구축합니다.

 

서비스 아키텍처 : 서비스 모델의 필요성 : 개념, 정의, 개요

 

IBM에서 만든 SOMA 방법론에서는 이러한 서비스 식별(Identification)뿐만 아니라 서비스의 명세(Specification)과 실현(Realization) 과정을 계속적으로 반복함으로써 중요한 서비스를 도출해서 SOA를 구축합니다. 서비스 Specification 과정은 Identification 과정에서 식별된 서비스가 무엇인지 그리고 그것을 도출한 근거가 무엇인지를 명세합니다.

Serialization 과정은 식별된 서비스를 어떻게 제공하거나 받을 수 있는지 그 결정을 내립니다. 즉, 식별된 서비스를 과연 기존에 존재하는 레거시 컴포넌트들로부터 받을 것인지 다른 파트너로부터 받을 것인지 아니면 심지어 새롭게 개발할 것인지에 대한 결정을 내립니다. 그리고 이러한 서비스 Identification, Specification, Realization 과정은 순차적으로 반복되면서 중요한 서비스들이 보다 충실하고 정확하게 도출될 수 있습니다.

 

 

Service Identification Process

SOMA 방법론에서는 Top-down과 Bottom-up 과정을 통해서 서비스가 도출됩니다. Top-down 과정에서는 특히 대상으로 하는 비즈니스 도메인을 주요한 기능영역들, 즉 Functional Area라고 합니다. 그것들로 나누고, 즉 Decompose하고, 그것들로부터 서브시스템들을 도출합니다.

그리고 또한 해당 비즈니스 도메인에서 필요로 하는 비즈니스 프로세스를 서브 프로세스, 더 비즈니스 프로세스를 상세한 단위들로 나눕니다. 그것들을 사용자가 실제로 어떻게 활용하는지 그런 관점에서 Use Case, 즉 High-level의 비즈니스 Use Case들로 정의를 해서 도출합니다.

반면에 Bottom-up 과정에서는 이미 존재하고 있는 레거시 시스템들을 분석해서 서비스 기능을 제공할 수 있는 것들이 무엇인지 찾아냅니다. 적합한 것들을 컴포넌트화 시켜서 API를 제공하도록 만드는 절차를 수행합니다. 즉, Top-down 과정에서는 비즈니스 도메인으로부터 시작해서 더 세부적인 요소로 나누어서 서비스를 도출해 가는 과정을 그립니다.

Bottom-up 과정에서는 기존의 레거시 시스템으로부터 서비스 제공에 활용될 수 있는 컴포넌트들을 도출해내는 과정을 수행하는 것입니다. 그리고 이렇게 Top-down과 Bottom-up 과정을 통해서 도출된 서비스는 Goal-Service Modeling이라는 과정을 통해서 그 서비스들이 해당 비즈니스 도메인에 적합한 서비스인지 아닌지를 검증하게 됩니다. 이것을 통해서 비즈니스 도메인에 꼭 필요로 하는 필수적인 서비스를 도출해서 SOA를 구축합니다.

 

 

Rent a car Domain Decomposition Analysis

Top-down으로 서비스로 도출하는 과정에서 DoMain Decomposition을 렌터카 비즈니스에서 하는 예를 살펴봅니다. 먼저 렌터카 비즈니스 도메인을 살펴보면 여러 가지 도메인들이 정의되어 있습니다. Marketing & Customer Management라는 도메인에서 Customer Service라는 Functional Area를 도출하는 모습을 볼 수 있습니다. 

 

서비스 아키텍처 : 서비스 모델의 필요성 : 개념, 정의, 개요

그다음에는 Rental Management라는 도메인으로부터 3개의 Functional Area, Rental, Reservations, Pricing이라는 Functional Area을 도출합니다. 그리고 이렇게 도출된 Functional Area 중에서 Rent와 관련된 비즈니스 프로세스를 이 그림에서는 정의합니다. Reserve Vehicle, Check-out Vehicle 그리고 Check-in Vehicle과 같이 세 개의 활동으로 정의하고 있습니다. Sub-process와 Business Use Case로 나눠져서 정의된 모습을 볼 수 있습니다.

Goal-Service Modeling, 즉 GSM 과정에서는 Top-down과 Bottom-up 과정을 통해서 도출된 서비스들을 해당 비즈니스의 Goal과 Sub-goal들 그리고 주요 성능 지표들, 우리가 Key Performance Indicators, 즉 KPI라고 부릅니다. 그런 것들을 통해서 측정하기 위한 Metric과 연계하게 되는 과정이 있습니다. 그리고 이러한 과정을 통해서 도출된 서비스들이 해당 비즈니스 도메인에 맞는 것인지를 검증하고, 이를 통해서 그 비즈니스에 필수적인 서비스를 식별하게 됩니다.

 

 

Goal service Model Example

그럼 하나의 예로서 은행 도메인에서 Goal Service Modeling을 수행한 것을 한번 살펴봅니다. 먼저 Goal과 Sub-goal들을 도출해야 하는데요. 이 예에서는 Main Goal 중에 하나로 ‘기존의 고객을 유지하고 새로운 고객을 추가로 확보하자’로 정했습니다. 그리고 그것의 Sub-goal들로서 ‘은행 포털과 챗봇을 통해서 편리한 금융서비스를 제공하자’라고 도출이 되었습니다. 또한 그것의 Sub-goal, 즉 Sub-sub-goal로서 ‘공과금 납부, 이체 등을 포털과 챗봇으로 가능하게 함’이라고 설정이 되었습니다.

그리고 이러한 Main Goal의 달성 여부를 확인 할 수 있는 주요한 성능지표, 즉 KPI로서 금융 고객의 수 2% 증대로 설정이 되었습니다. 이를 측정할 수 있는 Metric으로 변화한 고객의 수와 고객들이 소비한 금융 서비스의 수를 계산하는 것으로 정의합니다.

이후 우리는 Top-down과 Bottom-up 과정에서 도출된 서비스들이 이러한 Sub-goal과 Sub-sub-goal을 만족시키는 데 도움이 되는지를 대응시킵니다. 즉, 계좌 개설, 계좌 이체, 계좌 이력 조회 등 이러한 모든 서비스가 모두 Goal들 달성을 위해서 필요함을 우리가 이 분석 과정을 통해서 알 수 있습니다.

 

 

Service Specification

먼저 서비스 명세에는 SOA 설계에 대한 고수준의 High-level의 명세와 SOA를 구성하는 서비스의 요소 상세 설계 내용을 설명합니다. 그러한 서비스 제공을 위해서 어떻게 기존에 존재하는 컴포넌트들을 활용할 수 있는지 설명을 합니다. 그리고 서비스 간의 의존성, 서비스 간의 조합과 연결 Flow, 고려해야 하는 Event와 규칙, 각 서비스에서 제공하는 Operation들, 교환되는 Message와 비기능적 요구사항들이 명세가 됩니다.

또한 서비스 간에 교환되는 Input, Output, Error 메시지들의 설계 및 서비스 간의 메시지 흐름에 대해 설명합니다. 식별된 서비스와 기존에 존재하는 레거시 컴포넌트와의 상세한 매핑에 대해서도 설명합니다. 즉, 어떠한 레거시 컴포넌트를 활용해서 어떠한 서비스를 제공 가능한지 설명합니다.

 

서비스 아키텍처 : 서비스 모델의 필요성 : 개념, 정의, 개요

 

Service Specification 과정에서는 도출 된 서비스 중에서 어떠한 서비스를 어떻게 Publish 해야 하는지도 계획을 합니다. 비즈니스 도메인 분석을 통해 파악된 Functional Area와 그 기능영역에서 필요로 하는 서비스 그리고 각 서비스들이 제공하는 Operation들이 계층적으로 도출되어 정리가 되어 있습니다.

이렇게 도출된 서비스들은 일정한 시나리오에 맞춰서 한정적으로 묶여져서 Publish가 됩니다. 이 그림에 나타난 예에서는 세 가지의 다른 시나리오를 통해서 서비스와 서비스의 Operation들이 서로 묶여 Publish 되는 관계를 보여줍니다.

먼저 시나리오1에서는 첫 번째 서비스 전체를 WSDL로 명세를 해서 Publish 하는 것을 보여주고 있습니다. 시나리오2에서는 두 번째 서비스의 첫 번째 Operation만 한정적으로 Publish 하는 것을 보여 줍니다. 서비스 Specification은 서비스 모델링에서 가장 중요한 부분으로서 다양한 방법을 사용해서 표현되고 문서화 될 수 있습니다.

 

 

Service Exposure Scenarios

지금 설명 드리고 있는 SOMA 방법론에서는 세 번째 Activity로서 Realization 과정을 거칩니다. Realization 과정은 앞서 설명 드렸던 과정을 통해서 식별됩니다. 명세된 서비스들이 실질적으로 제공 가능한지 그것의 Technical Feasibility를 체크합니다. 해당 비즈니스에서 사용될 Reference Architecture를 점진적으로 도출하는 것입니다.

Technical Feasibility는 앞의 과정에서 도출된 서비스와의 Interaction 패턴 각각에 대해서 합니다. 그러한 Interaction 패턴이 해당 비즈니스 도메인에 적합한지, 위험요소는 없는지 파악합니다. 또한 이미 보유하고 있는 컴포넌트를 활용해서 서비스에서 필요로 하는 기능들이 제공될 수 있는지, 또한 기술 환경과 맞는지 등도 같이 검증을 합니다.

 

서비스 아키텍처 : 서비스 모델의 필요성 : 개념, 정의, 개요

 

Realization 과정을 통해서 도출된 금융 도메인에서의 Reference Architecture입니다. 서비스 Identification, Specification, Realization 과정들이 다 표시가 되어 있습니다. 특히 서비스 Identification 과정에서는 비즈니스 Goal을 중심으로 해서 비즈니스 프로세스를 도출합니다. 그것들을 서브프로세스로 나눈 이후에 핵심적인 서비스들이 도출된 모습을 볼 수 있습니다.

또한 서비스 Specification 과정에서는 그러한 서비스들이 일정한 시나리오로 패키징돼서 명세되어 나열되어 있습니다. Realization 과정을 통해는 Technical Feasibility가 검증된 서비스 컴포넌트에 대해서 그것들을 레거시 시스템으로부터 받을 수 있는지 분석이 이루어집니다. 그것들이 실제 Functional Component와 매핑되어 있습니다.

또한 이 Reference Architecture에서 오른편에는 서비스 간의 통신, Interaction들을 원활하게 할 수 있는 요소들 그리고 서비스의 품질, Quality of Service(QoS)를 유지하기 위한 요소들 그리고 보안과 관련된 요소들도 같이 명시됩니다.