SOA 서비스의 정의, 특성화, 구현 방법
Average rating: 
(29 ratings) |
Ali Arsanjani, 박사
아키텍트, SOA and Web services Center of Excellence, IBM
2004년 11월 9일
서비스 지향 모델링과 아키텍쳐의 핵심을 논의한다. 서비스
지향 아키텍쳐(SOA)를 구현하는데 필요한 분석과 디자인을 위한 핵심 액티비티를 논의한다. 필자는 서비스의
정의, 특성화, 실현에 필요한 기술을 언급하는 것의 중요성을 강조하고 있다. 또한 서비스의 흐름과 구성,
SOA에 요구되는 서비스의 품질을 실현 및 보증하기 위해 필요한 엔터프라이즈급 컴포넌트의 중요성에 대해서도
이야기 하고 있다.
Introduction
그동안 서비스 지향 아키텍쳐(SOA)와 웹 서비스로서 이를 구현하는 것을 둘러싸고 많은 소문과 가설들 -
이중 몇몇은 사실이고 어떤 것은 전혀 근거 없는 것이었다 - 이 무성했다. 분석가들은 예언했고, 학자들은
가설을 내놓았으며, 교수들은 강의했고, SOA는 제품이 아니라는 중요한 사실을 망각한 기업들은 그들이 가진
것을 SOA로 포장해서 팔기에 급급했다. 디자인 원리, 패턴, 기술을 사용하는 비지니스와 제휴된 IT 서비스를
통해 비지니스와 IT 사이의 차이를 이으려고 한다.
ZDNet은
최근 "Gartner는 2008년 까지, 60 퍼센트 이상의 기업들이 중요한 미션을 수행하는 애플리케이션과
프로세스를 만들 때 "가이드 원리" 로서 SOA를 사용할 것"이라고 발표했다."
SOA의 개발과 구현에 대한 수요는 대단하다. 만일 SOA가 이들을 구현하는 것을 돕는 단순한 제품과
표준에 관한 것이 아니라면, 예를 들어, 웹 서비스 같이, 어떤 추가적인 요소들이 SOA를 구현하는데 필요한가?
서비스 지향 모델링은 전통적인 객체 지향의 분석과 디자인(OOAD)에는 없는 추가적인 액티비티와 가공물들이
필요하다. “Elements
of Service-oriented Analysis and Design" 에서는 OOAD 그 이상의
것이 필요한 이유를 설명하고 있다. 또한 이 글에서는, 비지니스 프로세스 관리 또는 엔터프라이즈 아키텍쳐(EA)와
OOAD가 분석과 디자인을 수행하기에 부적절한지도 설명한다. IBM Redbook, “Patterns:
Service-Oriented Architecture and Web Services"에서는 서비스
지향 모델링 접근방식의 주요 액티비티를 설명하고 있다.
하지만 몇 가지 더 고려해야 할 중요한 사항들이 있다.우선, 현재 OOAD 방식은 SOA의 세 가지 핵심
요소들인 서비스, 플로우, 서비스를 구현하는 컴포넌트를 다루지 않는다. 또한, 서비스의 구분, 특성화,
구현에 필요한 기술과 프로세스, 흐름과 구성, 엔터프라이즈 급의 컴포넌트를 분명히 다룰 필요도 있다.
두 번째, SOA에서 두 가지 핵심 역할들인 서비스 공급자와 서비스 소비자에 대한 분명한 요구사항을 파악하기
위해 패러다임 변화가 필요하다. 셋째로, 하나의 엔터프라이즈 또는 비지니스 라인을 위해 구현될 애플리케이션들은
공급 체인 안에서 사용되어야 하고, 이 애플리케이션들을 새로운 애플리케이션으로 구성, 결합 및 캡슐화 할
비지니스 파트너들에게 노출되어야 한다. 이러한 개념을 서비스 생태계 또는 서비스 밸류 네트(value-net)
라고 한다.
이는 "분산 객체" 보다 약간 올라선 개념이다. 네트워크 효과를 통해 만들어진 가치에
대한 것이다; 예를 들어 Google의 검색 서비스와 Amazon.com을 결합하고, 이들을 eBay 서비스와
결합하여 혼합 솔루션을 구현했다고 해보자. 이런 예도 생각할 수 있다. 여행사가 항공 예약 시스템과 연계하고,
렌트카 에이전시와 호텔 체인과 협업할 때, 기록들이 업데이트 되고 여행 일정이 전자 계획표상에 전송된다.
애플리케이션이 무엇이든 간에, SOA를 성공적으로 구현하기 위해서는 좋은 툴과 표준 그 이상이 필요하다.
SOA의 수명 주기를 지원할 통시적 시각이 필요하다; 분석, 디자인, 서비스 구현, 플로우, 컴포넌트 등에
대한 기술이 필요하다. 따라서 엔터프라이즈 애플리케이션 개발에 관심이 있는 사람이라면 서비스 지향 모델링과
아키텍쳐에 개입된 상세한 단계들을 이해해야 한다.
이들 과정을 자세히 설명하기 전에 여러분이 만들어내고자 하는 것을 이해하도록 하자; SOA가 무엇이고
어떤 모습인가? SOA의 개념을 정의한 후에 SOA의 레이어를 설명하고, 프로젝트, 비지니스 성격, 엔터프라이즈
목적, 밸류 체인에 합당한 SOA의 청사진을 구현할 수 있도록 그러한 레이어들 마다 핵심적인 아키텍쳐 결정을
수립하는 방법을 설명하겠다.
서비스 지향 아키텍쳐:
개념 모델
이 개념은 세 가지 주요 참여자들인 서비스 공급자(서비스 디스크립션의 퍼블리시 및 서비스 구현 공급),
서비스 사용자(서비스 디스크립션의 URI를 직접 사용하거나 서비스 레지스트리에서 서비스 디스크립션을 찾아
호출), 서비스 브로커(서비스 레지스트리의 공급 및 관리) 사이의 인터랙션을 정의하는 아키텍쳐 스타일에
기반하고 있다.
아래 그림 1은 이러한 관계를 보여주는 메타-모델이다.
그림 1: SOA 아키텍쳐 스타일의 개념 모델
아키텍쳐 스타일과 원리
SOA를 정의하는 아키텍쳐 스타일은 약결합된, 비지니스와 연계된 서비스를 만드는 일련의 패턴과 가이드라인을
설명한다. 디스크립션, 구현, 분리의 문제를 해결하지는 못한다. 새로운 비지니스 위협과 기회에 대한 응답에
있어 전례가 없는 유연성을 제공한다.
SOA는 리소스를 "온 디맨드" 방식으로 연결하기 위한 엔터프라이즈급의 IT 아키텍쳐이다.
SOA에서 리소스들은 밸류 네트, 엔터프라이즈, 비지니스 라인에 참여할 수 있다. 한 조직의 비지니스 프로세스
및 목표를 집합적으로 수행하는 비지니스와 제휴된 IT 서비스들로 구성되어 있다. 이러한 서비스들을 합성
애플리케이션으로 구성할 수 있고 표준 프로토콜을 통해 호출할 수 있다.(그림
2)
서비스는 외부화된 서비스 디스크립션을 갖춘 소프트웨어 리소스이다. 서비스 디스크립션은 서비스 소비자들에
의해 검색, 바인딩, 호출될 수 있다. 서비스 공급자는 서비스 디스크립션 구현을 실현하고 서비스 소비자들에게
양질의 서비스 요구 사항들을 제공한다. 서비스들은 선언적 정책에 의해 관리되어 동적으로 재
설정 가능한 아키텍쳐 스타일을 지원하는 것이 이상적이다.
그림 2: SOA의 애트리뷰트
비지니스민첩성은 SOA에 의해 제공되는 인터페이스, 구현, 바인딩(프로토콜)의 분리로 인해 유연해진
IT 시스템을 통해 이룩될 수 있다. 어떤 서비스 공급자가 새로운 비지니스 요구 사항들에 기반하여 주어진
지점과 시간에 적절한지를 선택할 여유도 주어진다. (함수적 요구사항과 비 함수적 요구사항(예를 들어, 퍼포먼스,
보안, 확장성 등)).
fractal realization pattern으로 내부 비지니스단위 또는 비지니스파트너들 사이의
밸류 체인을 통해 서비스들을 재사용할 수 있다. fractal realization은 인터랙션 모델에 참여한
참여자들의 패턴과 역할을 적용하기 위해 아키텍쳐 스타일의 기능을 참조한다. 아키텍쳐 내의 한 티어에 이를
적용할 수 있고 엔터프라이즈 아키텍쳐를 통해 멀티 티어에도 적용할 수 있다. 프로젝트 사이에서는 하나의
밸류 체인 안에서 일관성 및 확장 가능한 방식으로 비지니스 단위들과 비지니스 파트너들 간 존재할 수 있다.
콘텍스트
이 섹션에서는 서비스 지향 모델링의 구분, 특성화, 구현, 가공물의 고급 작동에 대해 소개하겠다. 서비스
지향 모델링은 비지니스분석, 프로세스, 목표와 연계된 SOA의 모델링, 분석, 디자인, 제작을 위한 서비스
지향 분석과 디자인(SOAD) 프로세스 이다.
우선, 구현하려고 하는 것, 주로 SOA와 이것의 레이어를 살펴보자. 그런 다음, SOA를 구현할 때
필요한 주요 액티비티와 기술을 설명하면서 SOA 구현 방법을 설명하겠다.
예를 들어, 여러분이 프로젝트를 진행 중이고 목표는 셀프 서비스 어카운팅 시스템을 갖고 있는 비지니스의
뱅킹 라인의 한 부분을 SOA로 마이그레이션 한다고 생각해보자.
SOA로 마이그레이션 하기 위해서는 서비스 모델링 외에도 몇 가지 추가 요소들이 필요하다:
- 채택과 성숙 모델. SOA와 웹 서비스의 채택에 있어 엔터프라이즈의 상대적 성숙도는 어느 정도인가?
다양한 채택 레벨들은 그 레벨 마다 고유한 필요가 있다.
- 평가. 파일럿을 갖고 있는가? 웹 서비스에 관여해 본 적이 있는가? 결과 아키텍쳐의 상태는 어떠한가?
같은 방향으로 지속적으로 가야하는가? 이것이 엔터프라이즈 SOA로 이끌 것인가? 고려해야 할 사항들을
생각해 보았는가?
- 전략과 플래닝 액티비티. SOA로 마이그레이션하기 위해 어떤 계획을 세웠는가? 절차, 툴, 메소드,
기술, 표준, 교육 등 고려해야 할 사항들은 무엇인가? 로드맵과 전망은 무엇이며, 어떻게 도달 할 것인가?
계획은 무엇인가?
- 관리. 기존 API 또는 기능들이 서비스가 되어야 하는가? 그렇지 않다면 어떤 것이 가능한가?
모든 서비스들은 어떤 방식으로든 비지니스에 가치를 창출하도록 구현되어야 한다. 여기에 개입하지 않고
프로세스를 어떻게 관리하는가?
- 최상의 사용법 구현. 보안을 구현하고, 퍼포먼스를 보장하고, 상호운용성을 위한 표준에 순응하고 변화를
계획하기 위해 시도된 방식은 무엇인가?
이 글에서 설명한 구분, 특성화, 구현 외에도 서비스 지향 모델링 방식에는 SOA의 전체 수명 주기를 지원하는데
필요한 전개, 모니터링, 관리 기술들이 포함된다.
SOA로의 마이그레이션과 구현 후 추가 액티비티에 대한 논의는 다음 글에서 서서히 다루도록 하겠다. 지금은
기존 시스템 또는 서비스를 새로운 시스템과 서비스로 변형하는 것에 초점을 맞추겠다. 서비스 지향 아키텍쳐를
구현하기 위해 서비스 지향 모델링을 시작할 수 있다.
SOA를 위한 아키텍쳐
템플릿
SOA의 추상적인 모습은 비지니스프로세스와 제휴된 합성 서비스들이 부분적으로 레이어 된 아키텍쳐이다.
그림 3은 이러한 유형의 아키텍쳐를 묘사하고 있다.
서비스와 컴포넌트 사이의 관계는 엔터프라이즈급 컴포넌트들(크게 구분된 엔터프라이즈 또는 비지니스 라인
컴포넌트)이 서비스를 실현하고, 기능을 제공하고 서비스의 품질을 관리하는 것이다. 비지니스프로세스 플로우는
이렇게 노출된 서비스들을 합성 애플리케이션에 구성함으로서 지원될 수 있다. 통합 아키텍쳐는 Enterprise
Service Bus (ESB)를 사용하여 서비스, 컴포넌트, 플로우의 라우팅, 중개, 트랜슬레이션을 지원한다.
그림 3: SOA의 레이어
이들 각 레이어의 경우 디자인과 아키텍쳐 결정을 내려야 한다. 따라서 SOA를 문서화하려면 각 레이어에
상응하는 섹션들로 구성된 문서를 만들어야 한다.
다음은 SOA 아키텍쳐 문서를 위한 템플릿이다:
- 범위 <이 아키텍쳐가 필요한 엔터프라이즈 영역은?>
- 연산 시스템 레이어
- 패키지 애플리케이션
- 커스텀 애플리케이션
- 아키텍쳐 결정
- 엔터프라이즈 컴포넌트 레이어
- 엔터프라이즈 컴포넌트로 지원되는 기능 영역
- <이 엔터프라이즈 컴포넌트로 지원되는 비지니스도메인, 목표 프로세스는 무엇인가?>
- 관리와 관련된 결정
- <클라이언트 조직 내에서 엔터프라이즈 컴포넌트로서 선택된 것들의 기준은 무엇인가?>
- 아키텍쳐 결정
- 서비스 레이어
- 서비스 포트폴리오 범주
- 아키텍쳐 결정
- 비지니스프로세스 및 합성 레이어
- 구성법으로 표현되는 비지니스프로세스
- 아키텍쳐 결정
- <어떤 프로세스가 구성법으로 연결되어야 하고 어떤 것이 애플리케이션 안으로 구현되어야
하는가?>
- 액세스 또는 표현 레이어
- <이 레이어 상의 웹 서비스와 SOA의 문서 포함; 예를 들어 사용자 인터페이스 레벨에서
웹 서비스를 호출하는 포틀릿의 사용과 그러한 레이어의 기능에 대한 내용>
- 통합 레이어
- <ESB 고려사항 포함>
- <서비스의 클라이언트가 필요로 하는 서비스 레벨 계약(SLA)와 서비스 품질(QoS)을
어떻게 보장하는가?>
- 보안 문제 및 결정
- 퍼포먼스 문제 및 결정
- 기술과 표준 한계 및 결정
- 서비스의 모니터링과 관리
- 디스크립션과 결정
이제 각 레이어를 상세히 살펴보겠다.
Layer 1: 연산 시스템 레이어. 기존의 커스텀 구현 애플리케이션, 다시 말해서 레거시
시스템들(기존 CRM, ERP 패키지 애플리케이션, 오래된 객체 지향 시스템 구현, 비지니스정보 애플리케이션)로
구성된다. 이 레이어에서는 기존 시스템을 사용하고 이들을 서비스 지향 통합 기술을 사용하여 통합할 수 있다.
Layer 2: 엔터프라이즈 컴포넌트 레이어. 노출된 서비스의 기능을 구현하고 QoS를
관리하는 책임을 맡고 있다. 이 특별한 컴포넌트는 엔터프라이즈 또는 비지니스단위 레벨의 자금 지원을 받는
엔터프라이즈 자산으로 관리된다. 엔터프라이즈급의 자산으로서 애플리케이션을 사용할 때 SLA 순응해야 한다.
이 레이어에서는 애플리케이션 서버 같은 컨테이너 기반의 기술을 사용하여 컴포넌트, 워크로드 관리, 고 가용성,
로드 밸런싱을 구현한다.
Layer 3: 서비스 레이어. 비지니스가 자금을 지원하고 노출하기로 선택한 서비스들이
이 레이어에 있다. 이 서비스들은 발견될 수도 있고 또는 정적으로 바인딩 되어 호출될 수도 있고 또는 합성
서비스로 구성될 수도 있다. 이 서비스 노출 레이어는 엔터프라이즈급 컴포넌트, 비지니스단위 스팩의 컴포넌트,
프로젝트 스팩의 컴포넌트를 가져다가 서비스 디스크립션의 형태로 그들의 인터페이스들의 하위 세트를 외부화하는
메커니즘을 제공한다. 따라서, 엔터프라이즈 컴포넌트는 인터페이스가 제공하는 기능을 사용하여 런타임 시 서비스
구현을 제공한다. 이 레이어에서 인터페이스는 서비스 디스크립션으로서 반출된다. 이곳이 노출되어 사용되는
곳이다. 고립되어 존재할 수도 있고 합성 서비스로서 존재할 수 있다.
Level 4: 비지니스프로세스 합성 및 구성 레이어. Layer 3에서 노출된 서비스들의
합성과 구성이 이 레이어에서 정의된다. 서비스들은 오케스트레이션 또는 구성법을 통해 플로우로 번들되고 따라서
하나의 애플리케이션으로서 함께 작동한다. 이러한 애플리케이션들은 특정 사용 케이스와 비지니스프로세스를
지원한다. IBM® WebSphere® Business Integration Modeler 또는 Websphere
Application Developer Integration Edition 같은 시각적인 플로우 합성 툴은
애플리케이션 플로우의 디자인에 사용될 수 있다.
Layer 5: 액세스 또는 표현 레이어. 이 레이어는 이 글의 범위에서 벗어나지만 점점
관련성이 커지고 있다. Web Services for Remote Portlets Version 2.0
및 기타 기술 같이 애플리케이션 인터페이스 또는 표현 레벨에 웹 서비스를 활용하는 표준으로 집중되기 때문에
다루기로 결정했다. 미래의 솔루션에 고려해야 할 미래형 레이어로 생각해도 좋다. SOA는 사용자 인터페이스와
컴포넌트의 결합을 해제하고 액세스 채널에서 서비스 또는 서비스 합성 까지 엔드투엔드 솔루션을 제공한다.
Level 6: 통합 (ESB). 이 레이어에서는 지능형 라우팅, 프로토콜 중개, 기타
변형 메커니즘 (주로 ESB- 참고자료) 같은 신뢰성 있는
기능들을 도입하여 서비스 통합을 실현한다. Web Services Description Language
(WSDL)는 바인딩을 지정하는데 이는 서비스가 제공되는 위치를 포함하고 있다. 반면 ESB는 위치와 독립적인
통합 메커니즘을 제공한다.
Level 7: QoS. 이 레이어는 보안, 퍼포먼스, 가용성 같은 QoS를 모니터, 관리,
유지에 필요한 기능을 제공한다. 이것은 SOA 애플리케이션의 상태를 감시하는 감지와 반응 메커니즘과 툴을
통한 백그라운드 프로세스이다. SOA의 QoS를 구현하는 WS-Management, 기타 관련 프로토콜,
표준의 구현들이 포함되어 있다.
서비스 지향 모델링과
아키텍쳐에 대한 접근 방법
이 섹션에서는 탑-다운 방식의 비지니스주도형 방식과 기존 투자를 활용하는 바톰-업 방식을 결합하는 방법을
설명하겠다.
서비스 지향 모델링 방식은 SOA의 근본을 정의하는 모델링, 분석, 디자인 기술, 액티비티들을 제공한다.
각 SOA 레이어의 요소들을 정의하고 각 레벨 마다 중요한 아키텍쳐 결정을 내리는 데 도움이 된다. 기존
자산과 시스템을 활용하여 서비스 구분을 수행하는 작업 스트림과 결합된 탑-다운 방식의 비지니스주도적인
방식의 서비스를 사용한다.
이러한 방식으로, 고급 비지니스 프로세스 기능은 서비스를 위해 외부화된다. 고급 서비스를 구현하는 것을
돕는 세분화된 서비스는 기존 레거시 기능을 검토하고 어댑터와 래퍼를 만드는 방법을 결정하거나 시스템 내에서
잠겨진 기능을 외부화하기 위해 레거시를 컴포넌트화하여 구분된다.
마지막으로, goal-service
modeling을 사용하여 크로스 섹션 접근 방식을 통해 이미 확인된 후보 서비스들을 잘라 낼 수
있다. 보다 중립적인 방법은 우선 탑-다운 방식을 수행하는 것이고 그런 다음 goal-service modeling
이고 마지막은 기존 자산의 바톰-업 레거시 분석이다. 프로젝트를 관리 가능하고 현실적인 범주로 빠르게 잡아갈수록
핵심 서비스에 집중된 가치를 더 빨리 실현할 수 있다.
기능적 비지니스목표와 레거시 시스템에 대한 기존 투자의 활용을 결합하면 현대적인 SOA로 엔터프라이즈를
마이그레이션하려는 조직에 놀라운 솔루션을 제공할 수 있다. 서비스 지향 통합을 통한 소프트웨어 애플리케이션의
결합은 가능하다.
서비스 지향 통합은 Enterprise Application Integration (EAI)의 진화이다.
소유권이 있는 커넥션이 ESB 개념을 통해 표준 기반의 연결로 대체된다. ESB는 위치가 투명하고 라우팅,
중개, 변형 기능이 유연하다.
서비스 지향 모델링:
서비스의 분석과 디자인
지금까지 SOA를 설명했다. SOA를 구현하기 위해서는 SOA의 각 레이어에 대한 핵심 아키텍쳐 결정이
이뤄져야 하고, 디자인은 비지니스와 제휴된 서비스들과 구성법을 반영해야 한다는 것을 설명했다.
객체(objects) 라는 편안한 세계와는 달리, SOA의 경우 두 가지 관점을 고려해야 한다; 서비스
소비자와 서비스 공급자에 대한 전망. 서비스 브로커는 현재 주류에 속하지 않아 나중에 다루겠다.
SOA를 위한 디자인 전략은 웹 서비스 기반 방법에서 쓰이는 "바톰-업"으로 시작하지
않는다. SOA는 보다 전략적이고 비지니스와 제휴되어 있다는 것을 기억해야 한다. 웹 서비스는 SOA의
임시적인 구현이다. 중요한 많은 액티비티와 결정들이 통합 아키텍쳐 뿐만 아니라 엔터프라이즈와 애플리케이션
아키텍쳐에 영향을 주고 있다. 여기에는 소비자와 공급자 라는 두 가지 핵심의 액티비티들이 포함된다.(그림
4)
그림 4: 서비스 지향 모델링의 액티비티
그림 4는 공급자와 소비자의 각 역할에 의해 전형적으로 수행되는
액티비티들이다. 공급자의 액티비티는 소비자의 액티비티의 상위세트라는 것에 주목하라. (예를 들어, 공급자는
서비스 구분, 범주 등과 관련되어 있다). 많은 경우 역할의 차이는 소비자가 원하는 서비스를 지정한다는
사실에서 기인한다. 그리고 일단 찾고있는 서비스 스팩과 맞으면 필요한 서비스를 바인드하여 호출한다. 공급자는
지원하고자 하는 서비스를 퍼블리시 해야 한다. 소비자가 요구하는 QoS의 관점에서 가장 중요한 것과 기능을
고려해야 한다. 여기에는 소비자와 공급자가 SLA로 계약을 맺고 있어야 함을 함축하고 있다.
위에 설명된 액티비티는 서비스 지향 모델링과 아키텍쳐 메소드 내에서의 흐름을 설명하고 있다.(그림
5)
그림 5: 서비스 지향 모델링과 아키텍쳐 메소드
서비스 지향 모델링과 아키텍쳐의 프로세스는 세 가지 일반적인 단계로 구성된다: 구분, 서비스의 특성화와
구현, 컴포넌트와 플로우(서비스 구성법).
서비스 구분
이 프로세스는 탑-다운, 바톰-업, 미들-아웃(middle-out) 기술로 도메인 디컴포지션, 기존 자산
분석, goal-service modeling의 결합으로 구성되어 있다. 탑-다운 관점에서, 비지니스사용
케이스의 청사진은 비지니스서비스를 위한 스팩을 제공한다. 이 탑-다운 프로세스는 도메인 디컴포지션(decomposition)이라고
하는데, 이는 비지니스 도메인을 기능 영역과 하위 시스템으로 나눈다. 플로우 또는 프로세스 디컴포지션은
프로세스, 하위 프로세스, 고급 비지니스 사용 케이스로 나누는 것이다. 이 사용 케이스들은 엔터프라이즈의
끝에 노출된 비지니스 서비스에 적합하다. 비지니스 라인을 통해 엔터프라이즈 영역 안에 사용되어도 좋다.
바톰-업 부분의 프로세스 또는 기존 시스템 분석에서, 기존 시스템들은 비지니스프로세스를
지원하는 기저의 서비스 기능의 구현에 저렴한 비용의 솔루션을 제공할 수 있는 후보로서 선택된다. 이 프로세스에서
레거시 애플리케이션과 패키지 애플리케이션에서 API, 트랜잭션, 모듈을 분석 및 활용할 수 있다. 어떤
경우 레거시 시스템의 컴포넌트화는 서비스 기능을 지원하기위해 기존 자산들의 재모듈화에 필요하다.
미들-아웃(middle-out) 뷰는 탑-다운 또는 바톰-업 서비스 구분 방식으로 잡히지
않은 다른 서비스들을 확인하기 위한 goal-service modeling으로 구성된다. 서비스를 목표(goal)와
하위 목표, 핵심 퍼포먼스 인디케이터, 메트릭스로 묶는다.
서비스 구분 또는 범주화
서비스가 구분될 때 이 액티비티가 시작된다. 서비스 구분을 서비스 계층으로 시작하는 것이 중요하다. 서비스의
합성 또는 서비스의 프랙탈 속성을 반영해야 한다: 서비스는 세세하게 가려진 컴포넌트와 서비스들로 구성되어야
한다. 구분은 합성과 레이어링을 결정할 때 도움이 될 뿐만 아니라 계층에 근거한 상호 의존적인 서비스들의
구현을 조정한다. 또한 서비스의 '증식 증후군'을 막는데 도움이 된다. 세분화된 서비스들은 관리를 많이
하지 않고도 정의, 디자인 전개될 수 있어 주요 퍼포먼스, 확장성, 관리가 수월하다. 무엇보다도 중요한
것은 서비스 증식은 비지니스에 유용한 서비스를 제공하지 못한다.
하위시스템 분석
이 액티비티는 도메인 디컴포지션 동안 찾아낸 하위 시스템들을, 하위 시스템들 간 상호 의존성과 플로우를
지정한다. 하위 시스템 인터페이스에 노출된 서비스로서 도메인 디컴포지션 동안 사용 케이스를 구분한다. 하위
시스템 분석은 내부 작동을 나타내는 객체 모델 만들기와 서비스를 노출하고 이를 구현할 하위 시스템을 포함하는
디자인으로 구성된다. "하위시스템"의 디자인 구조는 다음 액티비티에서 서비스를 구현하는
크게 구분된 컴포넌트의 구현 구조로서 실현된다.
컴포넌트 특성화
서비스를 구현하는 상세한 컴포넌트들이 지정된다:
- 데이터
- 규칙
- 서비스
- 설정 가능한 프로파일
- 변수
메시징 및 이벤트 스팩과 관리 정의는 이 단계에서 발생한다.
서비스 할당
서비스 할당은 서비스들을 하위 시스템들로 할당하는 것으로 구성된다. 이 하위 시스템들은 퍼블리시된 기능을
구현하는 엔터프라이즈 컴포넌트를 갖고 있다. 하위 시스템들은 엔터프라이즈 컴포넌트와 일대일 상관관계가 있다고
보면 된다. 컴포넌트를 구현은 패턴을 사용하여 엔터프라이즈
컴포넌트를 다음과 같은 요소들로 만들 때 발생한다:
- 중개
- Facade
- 규칙 객체
- 설정 가능한 프로파일
- 팩토리
서비스 할당은 SOA의 레이어로 실현하는 서비스와 컴포넌트를 할당하는 것으로 구성된다. SOA의 레이어로 컴포넌트와
서비스를 할당하는 것은 핵심 아키텍쳐 디자인의 문서화와 결정을 필요로 하는 핵심 태스크이다. 애플리케이션 아키텍쳐
뿐만 아니라 런타임 시 SOA 실현을 지원하는데 사용되는 작동 아키텍쳐와도 관련되어 있다.
서비스 실현
이 단계는 주어진 서비스를 구현하는 소프트웨어가 선택 또는 커스텀 구현된다는 것을 인식한다. 사용할 수
있는 다른 옵션들에는 통합, 변형, 등록, 아웃소싱 등이 있다. 이 단계에서 주어진 서비스를 실현하는데
어떤 레거시 시스템 모듈이 사용되는 지와 처음부터 구현되어야 할 서비스가 무엇인지 결정해야 한다. 기타
구현 결정 사항으로는 보안, 관리, 서비스 모니터링 등이 있다.
실제로는 모든 것을 부합하기 위해 노력이 들기 대문에 세 가지 흐름을 병렬로 수행하는 것을 권한다.
탑-다운 도메인 디컴포지션 (프로세스 모델링과 디컴포지션, 변수 지향 분석, 정책 및 비지니스규칙 분석,
도메인 스팩의 작동 모델링(문법과 다이어그램 사용))은 기존 자산의 바톰-업 분석과 병행하여 수행된다.
프로젝트 뒤의 비지니스의도를 파악하고 비지니스의도 대로 서비스를 제휴하기 위해 goal-service
modeling이 수행된다.
결론
이 글에서 서비스 지향 아키텍쳐의 기초, 레이어, 관련 유형의 아키텍쳐 결정을 설명했다. 서비스 지향 모델링의
액티비티를 설명하고 서비스 소비자와 공급자 관점에서의 중요한 액티비티를 설명했다. 이 방식은 서비스 지향
아키텍쳐의 세 가지 근본적인 측면(서비스, 플로우, 서비스를 구현하는 컴포넌트)을 결정하기 위한 분석 및
디자인 액티비티에 대한 특정 가이드라인이다. 아키텍쳐 결정에 사용할 수 있는 템플릿도 설명했다.
서비스 구분과 관련해서 탑-다운, 바톰-업, 크로스-섹션, goal-model analysis을 결합하는
것의 중요성을 강조했다. 서비스 스팩과 실현의 주요 활동도 살펴보았다.
다음 칼럼에서는 이 방식을 은행의 어카운트 관리에 적용하여 각 단계를 예시를 들어 설명할 것이다. 구분,
특성화, 구현 외에도 서비스 지향 모델링 방식의 나머지 액티비티를 설명할 것이다. 전개, 모니터링, 관리
등 전체 SOA의 수명 주기를 지원하는데 필요한 것들이다.
감사의 말
조언과 피드백을 아끼지 않은 많은 분들께 감사드립니다. (순서 없음): Luba Cherbakov, Kerrie
Holley, George Galambos, Sugandh Mehta, David Janson, Shankar
Kalyana, Ed Calunzinski, Abdul Allam, Peter Holm, Krishnan
Ramachandran, Jenny Ang, Jonathan Adams, Sunil Dube, Ralph
Wiest, Olaf Zimmerman, Emily Plachy, Kathy Yglesias-Reece,
David Mott.
참고자료
| 
