 | |
|
난이도 : 초급 Marc-Thomas Schmidt, Distinguished Engineer, Chief Architect Enterprise Service Bus, IBM
Shankar S Kalyana, Executive IT Architect, IBM
2004 년 8 월 24 일 온 디맨드 운영 환경(On Demand operating environment)은 Service Oriented Architecture(SOA)의 개념을 기반으로 하고 있다. SOA는 모든 애플리케이션이나 리소스들을 특정한 (비지니스) 기능을 구현하는 서비스로 간주한다. 이러한 비지니스 기능 외에도 온 디맨드 환경에서의 서비스는 환경의 설정, 운영, 감시에 더욱 폭 넓게 참여하기 위해 관리 인터페이스도 구현한다.
Introduction
서비스들은 구조화된 정보--메시지 또는 문서(비지니스 객체)--를 교환함으로서 서로 통신한다. 서비스가 만들어 내거나 소비할 수 있는 메시지를 선언하는 인터페이스, 제공되는 서비스의 품질을 표명하는 정책 어노테이션, 서비스 인터랙션 시 준수해야 하는 작동상의 제한사항들을 설명하는 구성법 어노테이션 등에 의해 서비스 기능들이 정의된다. 실제 구현은 서비스 요청자들에게는 가려져있다. 따라서 SOA는 신구 애플리케이션들이 새로운 상황으로 빠르게 조합될 수 있도록 하여 애플리케이션 통합을 이룩하는 편리한 방법이다.
기존 애플리케이션들은 서비스 선언에 순응하게 된다. 예를 들어, 어댑터는® Business Integrator model, 모델을 따른다. 이 어댑터는 서비스 인터페이스를 구현하고 메시지를 기존 애플리케이션상의 작동으로 변형한다.
서비스들간 모든 인터랙션은 Enterprise Service Bus (ESB)를 통해 흐른다. 그렇다고 해서 모든 인터랙션에 네트워크 통신과 XML 메시지가 필요한 것은 아니다. ESB는 서비스에 개념적 모델인 "서비스" 을 제공하면서 최적화된 통신과 메시지 인코딩을 가능하게 한다. 극단적인 경우 두 서비스들간 인터랙션은 로컬 프로그램 호출로 바인딩 될 수도 있다.
서비스 요청자들과 공급자들을 매칭하는 것은 전개 시간보다 앞서 매우 빠르게 수행될 수 있다. 또는 동적 발견 메커니즘을 통해 매우 늦게 수행될 수도 있다.
SOA에는 서비스 및 서비스 기능에 대한 정의와 인터랙션을 위한 표준이 필요하다. 구조화된 정보의 구현 표준으로서 점점 XML을 채택하는 추세이고 웹 서비스 표준을 많이 사용함에 따라 이러한 아키텍쳐 접근방식의 채택이 수월해졌다. SOA의 개념적 모델은 비지니스 기능과 물리적 인프라의 구현에 적용된다. 이는 애플리케이션의 구현 뿐만 아니라 전개와 관리까지 확대된다. 클라이언트(사용자 또는 비지니스)는 비지니스 서비스의 모음을 보고 서비스의 품질에 관심을 갖지만, 온 디맨드 운영 환경은 애플리케이션 어셈블리와 서비스 전달의 세세한 부분으로부터 클라이언트를 보호한다.
다음 섹션에서는 온 디맨드 운영 환경의 아키텍쳐와 가이드 원리를 자세히 설명하겠다.
그림 1. 온 디맨드 운영 환경 아키텍쳐 개요
Enterprise Service Bus
온 디맨드 애플리케이션은 비지니스 서비스이다. 비지니스 서비스는 다른 사용자들에게 사용할 것을 광고할 만한 가치가 있는 기능을 제공하는 서비스에서 구현된다. 일반적으로 비지니스 서비스는 구현 시 다른 많은 서비스들에 의존한다. 서비스는 ESB를 통해 인터랙팅하는데, 서비스와 포인트간 중개 인터랙션을 조성한다. ESB는 이벤트기반 인터랙션 뿐만 아니라 서비스 요청 핸들링을 위한메시지 교환도 지원한다. ESB에서 한 가지 혁신적인 사항은 메시지와 이벤트용 공통 모델이다. 서비스를 전개하는 것이 이벤트 공간에서 메시지를 토픽으로 바인딩 한다면 모든 메시지들은 이벤트가 될 수 있다.
이벤트와 메시지 두 경우 모두, 중개는 인터랙션을 활용하여 요청자가 찾는 기능을 제공하는 서비스를 찾거나, 요청자와 공급자 간 부적당한 인터페이스 매치를 관리하기도 한다. 이 글에서 사용하는 서비스라는 용어는 매우 일반적인 개념이다. ESB의 관점에서 보더라도, 모든 애플리케이션 컴포넌트들은 WS-* 표준을 통해 정의될 수 있다. 그렇다고 해도 이들이 모두 SOAP이나 WS-* 프로토콜과 통신한다는 것은 아니다. 그저 ESB에 그들 자신을 설명해야 하는 것 뿐이다. ESB는 버스를 켜고 끄는 광범위한 방식을 지원한다. 또는 B2B 인터랙션 시나리오의 외부 파트너들이 서비스 인터랙션 게임에 참여할 수 있도록하는 비지니스 연결을 지원한다. ( Note 1 참고)
|
Note 1
비지니스 연결은 외부 서비스들이 비지니스 레벨의 (통합) 서비스들과 인프라 서비스들과 인터랙팅 할 수 있도록 한다. (정책에서 표현된 이상적인 서비스의 품질을 달성하기 위해서 이다.)
|
|
서비스들은 ESB의 관점에서 모든 것을 같은 것으로 보지만 전체 온 디맨드 애플리케이션의 다양한 면들을 구현한다. 예를 들어, 기저의 비지니스 프로세스에 개입된 사람들과의 인터랙션을 인식하고 통합되어야 하는 기존 애플리케이션들에 어댑터를 제공하고, 비지니스 목표를 이루기 위해 많은 서비스들의 통합을 구성하고, 프로세스 실행 중에 생길 잠재적 문제들을 살피고, 문제가 발생했을 때 이를 픽스할 준비를 하거나 필요한 비지니스 기능을 수행하는데 필요한 리소스들을 관리할 것이다. 그러므로 서비스 인터랙션을 위한 기본적인 인프라를 제공하는 것 외에도 온 디맨드 운영 환경은 온 디맨드 애플리케이션들의 구현 패턴을 정의하고 그러한 패턴들에서 특별한 역할을 하는 뚜렷한 서비스 카테고리의 실현을 지원한다. 이 두 개의 뚜렷한 서비스 카테고리들은 통합과 인프라 서비스 종류들이다.
통합 서비스
온 디맨드 비지니스 서비스의 프로그래밍 모델은 컴포넌트 (서비스) 어셈블리를 통한 애플리케이션 개발에 기반하고 있다. 온 디맨드 애플리케이션 구현자는 통합 범주 안에 있는 서비스들을 사용하여 새로운 비지니스 서비스를 만든다. 범주 안의 서비스들은 통합을 도울 뿐만 아니라 통합될 비지니스 기능을 제공하기도 한다. 다음은 서비스 리스트들이다.
-
사용자 액세스 서비스들은 1) 디스플레이 사이즈, 메모리, 프로세서 한계 (데스크탑에서 퍼베이시브 장치까지) 같은 엔드 포인트 형식 요소, 2) 기존의 디스플레이와 키보드 인터랙션 뿐만 아니라 스피치 기반 인터랙션 및 조합이 포함된 인터랙션 모드, 3) 완전히 분리된 작동을 포함하여 다양한 커넥션을 통한 P2P 또는 클라이언트-서버 등의 커넥션 유형 등을 핸들한다.
-
사용자 인터랙션 서비스들은 비지니스 프로세스에 개입된 사람들과의 직접적인 인터랙션을 핸들한다. 구성법에서 만들어진 작업 아이템들이나 협업 처리 요소를 처리하는 사람들이 이에 속한다.
-
비지니스 프로세스 구성법 서비스는 프로세스 플로우나 규칙 기술을 사용하면서 작동을 표현하는 다른 서비스들의 실행을 지원한다. 예를 들어, 프로세스 플로우는 새로운(합성 또는 결합) 비지니스 서비스에서 제공하는 기능을 구현하는데 필요한 태스크를 수행하는 다른 서비스의 인터랙션을 설명하는데 사용된다.
-
비지니스 기능 서비스들은 "원자(atomic)" 비지니스 기능들(다른 서비스들로부터 구성되지 않는 것들)을 제공한다. 이들은 전체 비지니스 서비스가 요구하는 것들이고 패키지되어있거나 기존 커스텀 애플리케이션 뿐만 아니라 전혀 새로운 애플리케이션 컴포넌트용 어댑터를 포함하고 있다.
-
일반 서비스들은 유용한 기능 또는 "헬퍼 기능"을 구현한다. 이들은 많은 비지니스 서비스들에 의해 사용되도록 설계되었다. 예제에는 사용자 액세스와 사용자 인터랙션 서비스의 개인화를 구현하고 비지니스 서비스들의 상태와 진행을 보고하는 서비스들이 포함되어 있다.
-
정보 관리 서비스들은 데이터베이스나 레거시 애플리케이션 같은 다양한 데이터 소스들에 호스팅된 정보를 통합하는 것을 돕는다. 이러한 서비스들은 이 정보에 접근(쿼리, 업데이트, 검색)하고 비지니스 정보 시나리오에서 이를 분석하거나 온 디맨드 운영 환경에서 실행중인 비지니스 서비스들에 의해 사용되고 제공되는 정보와 서비스들에 대한 메타데이터를 관리한다.
통합 서비스는 애플리케이션 서비스에 의해 호스팅된다. 애플리케이션 서비스는 다른 통합 서비스들과 온 디맨드 운영 환경 인프라 서비스와 인터랙션에 참여하는 방식을 단순화 하기 위한 컨테이너 장치를 제공한다. 온 디맨드 통합 서비스 개발자들은 그들이 관리하는 비지니스 로직을 실현시키고 필요한 비지니스 기능을 제공하는 통합 서비스들을 모으며 기대치의 서비스 품질을 선언하는데 초점을 맞춘다.
프로그래머와 관리자들은 서비스 품질을 정의하고 있는 정책 선언과 함께 애플리케이션과 서비스들의 주석을 단다. 애플리케이션 컨테이너(그리고 ESB)는 인프라 서비스들과의 인터랙션을 자동화하여 이렇게 발표된 정책을 실현한다. 애플리케이션 컨테이너는 컨테이너가 호스팅하고 있는 서비스들에 대한 보안 또는 트랜잭션 관리 요구 사항들을 관리하는 일반적인 장치를 제공하거나, 비지니스 프로세스 구성법 서비스의 상태와 진행과정을 보고하는 이벤트를 만들어 내는 장치를 제공한다. (Note 2 참고)
|
Note 2
모든 서비스 목록들이 컨테이너에 살아있더라도 온 디맨드 운영환경 프로그래밍 모델의 관점에서 보면 오직 통합 서비스용 컨테이너만이 관심 대상이다. 바로 이것이 비지니스 서비스 구현자들에 의해 매개변수화 되어야 하는 것들이다.
|
|
인프라 서비스
인프라 목록의 서비스들은 비지니스 서비스들과 구성물들이 전개되는 인프라를 제공 및 관리한다. 다음 리스트들은 이러한 서비스들을 설명하고 있다.
-
유틸리티 비지니스 서비스들은 온 디맨드 비지니스 서비스 또는 이것의 컴포넌트를 호스팅할 때 일반적으로 사용되는 빌링, 미터링, 레이팅, 피어링, 결재 같은 기능들을 지원한다.
-
서비스 레벨 자동화와 편성은 비지니스 서비스와 관련된 서비스 품질 정책 선언의 번역을 현실화하는 서비스를 제공한다. 이는 온 디맨드 운영 환경에서 이들이 받는 정책 선언에 따라 서비스의 실행을 감시(Monitor)하는 자동 매니저들을 구현하는 서비스로 실현된다. 이 서비스들은 작동을 분석(Analyze)하고 분석 결과에 문제가 있으면 그 문제에 대한 중요한 대처를 계획(Plan)하고 그 계획을 실행(Execute)한다. 이런 폐쇄된 피드백 루프를 MAPE (Monitor, Analyze, Plan, Execute)루프라고 한다. 가용성, 설정, 관리되는 엘리먼트의 워크로드 등의 관리, 리소스 제공, 문제 관리, 온 디맨드 운영 환경 서비스용 엔드투엔드 보안 핸들링, 데이터의 저장 관리 등 특성화된 서비스들이 많이 존재한다.
-
리소스 구현 서비스는 다양한 데이터 소스들에 있는 구조화된(예를 들어, 관계형) 정보 콘텐트와 구조화되지 않은 정보 콘텐트를 포함하여 서버, 스토리지, 네트워크, 기타 리소스들의 인스트루멘테이션을 제공하여 온 디맨드 운영 환경 리소스 매니저의 통제 하에 그러한 리소스들을 관리 및 실현시킬 수 있도록 한다. 버추얼라이제이션 서비스에는 비지니스 서비스와 이들 컴포넌트의 요구사항들을 서비스의 QoS 선언과 사용 가능한 리소스들의 이용에 대한 지식에 기반한 리소스들로 매핑하는 것이 포함된다. ( Note 3 참고)
|
Note 3
이 글에서 사용하는 리소스(resources)라는 용어는 하드웨어 장치, OS 리소스, 데이터베이스, 애플리케이션 등을 망라하는 일반적인 개념이다.
|
|
다양한 온 디맨드 운영 환경 패턴을 지원하면서 매우 다른 기능들을 구현한다는 사실 외에도 서비스 목록들간 주요 차이점은 어떤 사용자 역할이 이를 구현하고 사용하는 가이다. 미들웨어 공급자와 ISV는 인프라 요소를 구현하는 반면, 온 디맨드 인프라와 애플리케이션 빌더는 통합 요소들을 구현한다.
온 디맨드 운영 환경의 가장 중요한 인식 중 하나는 일반적인 패턴이 애플리케이션 서비스와 인프라 서비스 모두를 지원한다는 점이다. 예를 들면:
- 어댑터로 기존 인프라 컴포넌트를 ESB로 통합하는 것이 가능하다.
- 서비스 구성법은 MAPE 실행 계획을 스크립팅하는데 종종 사용된다.
- ESB는 관리되는 엘리먼트와 자동 매니저 사이의 이벤트 교환을 위한 인프라를 제공한다.
- 사용자들은 "포탈" 사용자 인터랙션 서비스를 통해 인프라 서비스들과 인터랙팅한다.
비지니스 퍼포먼스 관리
온 디맨드 운영 환경(ESB, 통합 서비스, 인프라 서비스)의 세 측면은 비지니스 퍼포먼스 관리를 수행하는데 필요한 기능들을 제공하거나 비지니스 서비스 구현의 분석 단계에서 규명된 핵심 퍼포먼스 인디케이터(KPI) 같은 비지니스 목표를 충족시키기 위한 비지니스 서비스 관리를 제공한다. KPI를 계산하고 기저의 비지니스 서비스의 관리와 관련된 다른 메트릭스를 계산하는데 사용될 수 있는 비지니스 이벤트를 만들어내기 위해 통합 서비스들이 갖추어진다. 게다가, 비지니스 서비스 정책들은 비지니스 서비스의 기대 작동을 기술하고 그러한 기대가 충족되지 못하는 상황을 다루는 규칙을 정의하게된다. 비지니스 이벤트들의 예제들은 비지니스 프로세스 완료, 롤백 또는 수동 개입 등이다. 수동 개입 없이 성공적으로 완료된 모든 구매 주문 절차의 95% 정도가 KPI일 것이다.
인프라 서비스들은 이 서비스들에 의해 만들어지는 비지니스 이벤트들과 연관될 수 있는 리소스 비지니스 서비스 사용을 보고하는 IT 레벨의 이벤트를 만들어낸다. 서비스-레벨 자동화 서비스들은 비지니스와 IT 레벨의 이벤트를 사용하여 그들이 호스팅하고 있는 비지니스 서비스들과 관련된 정책을 실행한다. ESB와 연계된 유틸리티 비지니스 서비스들은 프리젠테이션용 이벤트들을 모으고 평가하여 비지니스 프로세스 비지니스 액티비티 작업공간의 참여자들에게 제공한다.
온 디맨드 비지니스 서비스의 수명 주기
|
Note 4
이 글에서 사용되는 애플리케이션 구현자(application builder)라는 용어는 온 디맨드 서비스를 모델링 및 구현에 개입하는 사용자 역할들을 의미한다.
|
|
온 디맨드 애플리케이션 구현자( Note 4)는 기업의 특정 비지니스 목적을 지원하는 비지니스 서비스들을 개발한다. 온 디맨드 애플리케이션의 특정 측면을 단순히 구현하는 다른 서비스들과는 대조적으로 비지니스 서비스는 독립적일 수 있다. 사용자들(고객은 물론 인프라 기업 사용자들) 또는 기업이 인터랙팅하는 다른 비지니스들에 제공되는 중요한 비지니스 프로세스나 태스크를 구현한다. 비지니스 서비스들은 통합 서비스로부터 만들어지고 그 결과는 온 디맨드 인프라에 전개된다. 온 디맨드 인프라 관리자(Note 5)는 그러한 비지니스 서비스 모음들을 호스팅하고 관리하는데 필요한 비지니스 유틸리티, 서비스 레벨 자동화, 리소스 구현 서비스들이 적재적소에 있는지를 확인한다.
|
Note 5
글에 사용된 인프라 관리자라는 용어는 온 디맨드 인프라를 관리하는 것과 관련된 사용자 역할들을 의미한다.
|
|
온 디맨드 운영 환경 기능, 서비스 종류, 인터랙션을 보다 잘 이해하기 위해 기저의 비지니스 기능과 퍼포먼스 인디케이터를 모델 객체를 구현하는 비지니스 서비스 컴포넌트의 구현과 모음으로 모델링 하는 것부터, 그 컴포넌트를 비지니스 서비스로서 온 디맨드 인프라에 전개하는 것 까지, 온 디맨드 애플리케이션의 수명주기를 따라가 보자.
프로세스 모델 정의하기
비지니스 서비스를 구상하는 방법은 이 글의 범위를 벗어난다. 하지만 일단 구상을 한 후라면 비지니스 서비스 구현자는(예를 들어, 비지니스 분석가) 새로운 비지니스 서비스가 제공하게 될 새로운 기능에 대한 고급 스케치를 제시한다. 그들은 Component Business Model (CBM) 방식(독자적인 스탠드얼론 비지니스 컴포넌트들을 규명함으로서 비지니스를 보는 방식을 단순하게 하는 분석 기술에 중심을 둔 방식이다)를 사용하여 상상해오던 비지니스 서비스를 규정하고 이를 특정 애플리케이션 도메인용 모델에 배치시킨다.
이 모델은 구상된 애플리케이션의 주요 컴포넌트들을 구현과는 거의 독립된 방식으로 구분한다. 이는 원래부터 온 디맨드 운영 환경(어댑터, 프로세스 구성법, 비지니스 객체 등)에서 원래 지원되는 것과 비슷한 패턴을 사용하기 때문에 온 디맨드 운영 환경 서비스 종류의 관점에서 정의된 구현 모델용 템플릿으로 모델을 변환한다.
서비스 분석가들이 개발하는 상상 속 비지니스 모델에는 그 비지니스가 관여하게되는 핵심 퍼포먼스 인디케이터 스팩이 포함된다. 또한 온 디맨드 운영 환경에 호스팅된 다른 서비스들에 의해 수행되는 액티비티들로의 서비스 분할, 이 프로세스로 조작되는 정보를 나타내는 비지니스 엔터티, 원하는 비지니스 기능을 구현하기 위해 수행되는 태스크의 특정 측면들을 책임지고 있는 사용자 또는 비지니스 파트너 구분 등이 포함된다.
그림 2. 온 디맨드 비지니스 서비스의 수명주기
이때 비지니스 레벨의 모델링 툴들은 모델들 내의 인터랙션을 기술하고 액티비티 비용과 리소스 가용성 등에 기반한 실행을 시뮬레이션 할 때 사용된다. 이 단계에서 개발된 고급 모델들은 온 디맨드 운영 환경 툴에서 지원을 받는 비지니스-IT 레벨의 매핑을 위한 패턴을 사용하여 구현 레벨의 모델용 템플릿으로 변형될 수 있다. 많은 경우, "컴포넌트" 또는 "서비스"의 기존 구현들은 모델 안에 있고 이들은 비지니스 레벨 모델에서 선언된 특정 요구사항에 따른 템플릿의 구현 대신 규칙 또는 정책 기반의 커스터마이징을 필요로한다.
신구 컴포넌트 조립하기
비지니스 컴포넌트용 구현 레벨 모델은 보다 추상적인 비지니스 태스크의 디스크립션이나 새로운 비지니스 서비스를 보다 구체적인 애플리케이션 패턴으로 만드는데 필요한 엔터티로 매핑한다.
프로세스 구성법 서비스는 비지니스 레벨 모델에서 구상된 태스크 분할의 라인을 따라 다른 서비스들과의 인터랙션을 조정하여 원하는 비지니스 목표를 달성하고 비지니스 규칙을 공개하여 구성된 서비스들의 작동을 커스터마이징한다. 사용자 액세스 서비스들은 다양한 연결 기능들을 통해 다양한 인터랙션 모드로 다양한 형식 요소 장치를 통해 태스크 실행을 가능하게 한다. 사용자 인터랙션 서비스는 사용자들이 그러한 태스크의 실행에 기여하여 결국 정돈된 프로세스 구성법에 순응하는 협업 기능을 사용하여 덜 형식적인 방식으로 인터랙팅 할 수 있게 한다. 정보 관리 서비스는 비지니스 레벨 모델에서 정의된 비지니스 엔터티들을 구현하고 다양한 종류의 데이터들과 새로운 비지니스 서비스의 액티비티에 의해 프로세스될 수 있는 백엔드 시스템에 의해 호스팅 되는 정보를 만들고, 정보를 변형 및 통합하여, 그러한 정보의 분석을 지원한다. 비지니스 기능 서비스는 ESB 어댑터와 중개 장치 또는 새로운 컴포넌트를 통해 새로운 비지니스 서비스에서 사용될 수 있는 기존 애플리케이션 컴포넌트들을 나타낸다.일반 서비스들은 개별적인 방식으로 사람들과의 인터랙션을 구성하거나 비지니스 퍼포먼스 관리 또는 비지니스 정보를 보고하는 등의 서비스에 의해 사용되는 장치를 캡슐화한다.
온 디맨드 애플리케이션 빌더들은 (ESB에 의해 호스팅 될) 매체를 구성 서비스 컴포넌트들 간 필요한 서비스 인터랙션들과 매치하여 전체 비지니스 서비스 목표를 달성한다.
비지니스 퍼포먼스 관리의 지원으로 비지니스 레벨 모델로 정의된 퍼포먼스 인디케이터와 다른 메트릭스들은 결과 비지니스 서비스 컴포넌트의 엘리먼트들의 기구화로 변형된다. 구현 모델은 그러한 컴포넌트들에게 기대되는 서비스 품질을 나타내는 전체 비지니스 서비스를 구성하는 서비스용 정책 어노테이션을 지정한다. 애플리케이션 컨테이너는 어노테이션을 런타임 작동으로의 매핑을 지원하고 그들이 호스팅하는 컴포넌트용 상태 변경 이벤트를 만들고 정책을 적절한 인프라 서비스들과의 인터랙션들로 번역할 때 핵심적인 역할을 한다.
비지니스 서비스의 수명 주기에서 이 단계에 사용된 온 디맨드 운영 환경 구현 레벨 툴들은 서비스 컴포넌트(신/구 기반)의 생성을 지원하고 기존 컴포넌트들의 커스터마이징과 조정을 지원한다. 서비스 생성에는 기존 애플리케이션들을 위한 어댑터의 개발이 포함되며 종종 기존 애플리케이션 인터페이스의 단순한 "서비스화"를 넘어 애플리케이션 래퍼를 제공한다. 온 디맨드 운영 환경 통합 서비스 개발자들은 커스터마이징을 염두해 두고 컴포넌트를 설계할 수 있다. 이러한 서비스들은 또 다른 컴포넌트들에게 이루어지는 결정을 수행하는 지점에 변이가능성 포인트를 외부화한다. 예제에는 비지니스 규칙에 대한 자문이 포함되어 있어서 실행의 흐름 또는 서비스의 정책 어노테이션으로 나타나는 QoS 변형들을 결정한다. 새로운 비지니스 서비스로 조합되는 컴포넌트들은 다양한 방식으로 실현될 수 있다.
일반적으로, 온 디맨드 운영 환경 모델은 컴포넌트 어셈블리와 컴포넌트 커스터마이징의 혼합을 사용하는 서비스 템플릿 개념을 지원한다. 커스터마이징이 가능한 합성 컴포넌트를 구현하여 이 템플릿으로 구현 될 일반적인 비지니스 서비스들을 만드는 템플릿으로서 사용하기 위함이다. 이 템플릿을 사용하는 비지니스 서비스 구현자들은 커스터마이징 할 컴포넌트의 내부에 대해 걱정하지 않아도 된다. 이 템플릿 방식은 구현 상세를 숨기고, 대신 템플릿의 인스턴스화에 필요한 것만 수행하기 위해 매개변수화 될 수 있는 템플릿의 변이가능성만 나타낸다.
인프라 정의 및 설계
결과 비지니스 서비스와 이것을 지원하는 사용자 액세스와 인터랙션, 비지니스 프로세스 구성법, 정보 관리, 비지니스 기능, 일반적인 서비스들은 필요할 경우 온 디맨드 운영 환경 인프라에 전개될 것이다. 비지니스 서비스 구현자들은 전개 태스크를 수행하는데 필요한 기본 지식이 없어도 된다. 이들은 서비스 어셈블리를 정책 어노테이션으로 매개변수화한다.
온 디맨드 운영 환경은 사용 가능한 리소스와 이들의 관계를 선언하는 전체 리소스 모델의 스팩과 관리를 지원한다. 온 디맨드 비지니스 서비스의 리소스 요구 사항들은 서비스와 이것의 구성물들의 정책 선언에서 파생된다. 이 단계에서 리소스 제공은 새로운 프로세스의 정책 선언이 요구하면 중지한다. 온 디맨드 인프라 관리자는 리소스 모델을 정의하고 필요한 리소스 매니저와 인프라를 설정한다.
비지니스 서비스 어셈블리의 요소들을 엔터프라이즈와 이것의 범위를 벗어난 곳의 온 디맨드 운영 환경으로 전개할 수 있다. 온 디맨드 운영 환경 프로그래밍 모델이 서비스 컴포넌트의 아웃소싱을 투명하게 지원한다.
예견과 응답
마지막으로, 자동화와 오케스트레이션 서비스로 구성된 MAPE 루프는 전체 앙상블을 감시 및 제어한다. 이러한 서비스들은 미들웨어 벤더들과 ISV가 인프라 컴포넌트에 제공하는 기구들과 비지니스 레벨의 메트릭스와 함께 통합 레벨의 기구들도 사용한다. 이 메트릭스는 비지니스 프로세스 서비스 수명 주기 초반에 구상된 퍼포먼스 인디케이터에 의해 영감을 받고 통합 서비스의 관리된 엘리먼트의 기구화로 변환시킨다.
(인프라와 비지니스에 의해 움직이는) 이 두 종류의 이벤트들은 일반적인 이벤트 디스크립션 포맷을 사용하여 인코딩되어, 같은(일반 이벤트) 인프라를 통해 전파되거나 소스와는 별도로 코릴레이션되거나 수집될 수 있다.
비지니스와 IT 레벨의 이벤트를 감시하고 이를 KPI 지향의 폼으로 렌더링하는 것 이외에도, 여기에서 캡쳐 된 이벤트들은 문제들에 대한 반응을 자동화하고 잠재적인 문제들을 가르키는 이벤트 패턴들을 감시하고 이를 피할 액션도 취한다. 해당 비지니스 서비스와 관련된 정책 선언에 근거하여 액션이 취해진다.
온 디맨드 인프라 관리자들은 필요한 서비스 레벨 자동화 및 오케스트레이션 컴포넌트들의 설정을 관리한다. 이는 실행되는 비지니스 서비스 컴포넌트 어셈블리의 요소에 대해 선언된 정책을 이해하고 실행하는 자동 관리자들에게 해당된다.
아키텍쳐 정의
다음 섹션에서는 온 디맨드 운영 환경 아키텍쳐를 시스템 관점에서 설명한다. 그림 1은 용어해설이다.
애플리케이션 서비스
어플리케이션 서비스들은 통합 서비스와 비지니스 서비스를 호스팅하는 컨테이너를 구현하고 다른 통합 서비스들과 온 디맨드 운영 환경 인프라 서비스들과의 인터랙션에 참여하는 것을 단순화 할 수 있는 장치를 제공한다.
비지니스
비지니스는 프로그래밍 방식의 연결을 통해 비지니스 서비스 인터랙션의 정황에서 역할을 수행하는 외부 애플리케이션 시스템이다. 비지니스는 엔터프라이즈 서비스에 대한 소비자가 될 수도 있고 엔터프라이즈에 서비스를 공급하는 공급자가 될 수도 있다. 비지니스는 엔터프라이즈 내부의 엔터티와 외부의 엔터티들을 아우른다. 예를 들어, 지역적으로 분산된 큰 엔터프라이즈는 다양한 지역에 걸쳐 다중 비지니스 단위를 가질 수 있고 이들 각자 고유의 시스템들과 아키텍쳐를 갖고 있다. 다른 지역의 상대방과 비지니스를 수행하는 이들을 사용한다.
고객 컴포넌트는 조직이 공급을 고려중인 서비스와 프로그램 형식으로 통합하는데 관심이 있는 비지니스이다. 외부 시스템으로의 고객 요청은 비동기식 또는 동기식이 될 수 있다.
공급자 컴포넌트는 조직이 프로그래밍 방식의 링크를 만들어서 활용할 특정 비지니스 기능을 제공하는 비지니스이다
비지니스 기능 서비스
비지니스 기능 서비스는 비지니스 기능을 구현하고 구현 상세를 숨긴다. 이것은 비지니스 서비스에 대한 기능의 기초가 되고 이것의 기저 기능들은 서비스로서 노출되거나 구성법에서 사용되는 컴포넌트로서 직접 노출된다. 비지니스 기능 서비스는 근본적으로 조작이 가능하거나 분석적이다.
- 커스텀 애플리케이션은 엔터프라이즈 내에서 만들어진 비지니스 애플리케이션이다. 대부분의 경우, 매우 오래되었고 이들 안에 비지니스 로직이 임베드되어 있다. 이들 애플리케이션 중 일부는 다양한 비지니스 프로세스를 아우르고 한 비지니스 내부에서 다중 기능 분야를 교차하지만 대부분은 비지니스 특정 측면만을 다룬다.
- 패키지 애플리케이션은 은 소스 또는 런타임 코드를 외부 애플리케이션 벤더들로부터 구매한 비지니스 애플리케이션이다. 패키지 애플리케이션 벤더의 예로는 SAP, Oracle®, PeopleSoft® 등이 있다. 이러한 애플리케이션들은 일반적으로 한 비지니스 내에서 다중 기능을 핸들한다. 특별한 패키지 애플리케이션도 존재한다. 이들 애플리케이션 대부분이 비지니스 로직과 비지니스 프로세스를 포함하고 있다.
비지니스 퍼포먼스 관리
비지니스 퍼포먼스 관리 서비스는 비지니스 관리자들이 비지니스 전략을 투명하고 측정 가능한 목표에 맞춰 설계하고, 이러한 전략을 실행 플랜과 비지니스 정책으로 전환하며, 이러한 정책들의 퍼포먼스를 감시하여 KPI에 부합하는지를 확인하며 이들 계획의 결과를 분석하여 보다 향상된 비지니스 퍼포먼스 드라이버로 만들고, 다양한 이해 당사자들과 이러한 결과에 대한 통신을 하도록 한다. 이 비지니스 퍼포먼스 관리 레이어의 전체 목표는 인지를 가능하게 하고 환경에 대응하고 보다 진취적으로 환경을 점유하도록 하는 것이다.
그림 1에서, 비지니스 퍼포먼스 관리는 통합 서비스, ESB, 통합 서비스의 교차점에 위치해있다.
비지니스 프로세스 구성법 서비스
비지니스 프로세스 구성법 서비스는프로세스 흐름 그래프를 사용하여 구현을 표현하여 비지니스 목표를 달성하는데 필요한 다른 서비스들과의 인터랙션을 설명하는 서비스 구현을 지원한다. 이 서비스는 이러한 서비스들에 의해 제공되는 작동의 순서를 정하는 규칙을 인코딩하고 내/외부 프로세스 참여자들의 책임을 인코딩한다. 구성법 서비스는 완전히 자동화된 서비스 스팩을 실행하거나 사용자와 인터랙션이 필요한 인터랙티브 태스크를 포함한다 :
- 구성법은 내/외부 참여자-사용자 또는 비지니스-간 정보 교환 흐름을 정의하여 한 개 이상의 서비스를 구성하는 비지니스 프로세스를 구현한다. 이 서비스들은 전형적인 웹 서비스이지만 일반 서비스도 될 수 있다. 오케스트레이션은 엔터프라이즈 내의 정황속에서 사용되는 반면 구성법은 가상 엔터프라이즈의 정황속에서 사용된다.
- 비지니스 규칙은 프로세스 구성법 스크립트 처럼 서비스로부터 외부화되는 결정을 인코딩한다. 이들은 결정 사항과 서비스에서 발생하거나 외부에서 발생하는 특정 이벤트의 경우 취해지는 액션 세트를 설명함으로서 서비스의 변화하는 특성과 조건적인 특성을 확립한다. 규칙과 정책의 외부화는 온 디맨드 운영 환경에 있어서 중요하다. 기존 서비스들의 커스터마이징을 가능하게 하여 새로운 비지니스 요구사항을 부합할 수 있다. 새로운 서비스와 솔루션을 위해 전체 옷을 갈아입을 필요가 없다.
비지니스 서비스
비지니스 서비스는 다양하게 외부화된 기능 서비스 오퍼링으로서 운영 환경에서 정의, 설정, 전개되었다. 비지니스 서비스는 사용자 또는 외부 시스템에게는 험난한 지점이고 실제로는 기능 서비스 밖에서 구성되는 비지니스 프로세스의 집합적 관점이다. 비지니스 서비스는 Component Business Modeling (CBM) 같은 메커니즘을 통해 정의 및 구분된다.
일반 서비스
일반 서비스는 한 개 이상의 서비스가 사용하는 기능 또는 인프라 서비스이다. 일반 서비스는 그 자체로 획득되어 사용될 수 있고 획득 후에 커스터마이징 되거나 전체적으로 다시 구현될 수 있다. 일반 서비스의 예는 다음과 같다:
- 획득된 서비스는 엔터프라이즈 외부의 엔터티에 의해 제공된다. 일반적으로 그 엔터티에 의해 호스팅된다. 그리고 한 개 이상의 비지니스 프로세스의 엔터프라이즈에 의해 사용된다. 이는 외부 엔터티가 엔터프라이즈에게 제공하는 "유틸리티" 서비스이다.
- 개인화에는 다른 서비스들이 사용자 프로파일과 선호에 대한 이해에 기반한 아웃풋을 구성할 수 있도록 하는 서비스들을 포함한다. 개인화는 커스터마이징과 같은 것은 아니다. 이것은 실제로 사용자가 제어하는 액션으로서 각자의 필요에 맞게 인터랙션을 변경하는 것이다. 시스템에 의해 수행되는 것과는 다른 개념이다.
- 리포팅은 모든 종류의 사용자들을 목표로 한 리포트를 만들어내는 다양한 애플리케이션들을 위해 프레임웍 유형의 서비스를 제공하는 서비스이다. 이 서비스는 작동 유형 리포트와 분석 유형 리포트를 지원한다.
Enterprise Service Bus
ESB는 모든 서비스들 간 중개 인터랙션을 실행하는 인프라를 제공한다. ESB는 이벤트 기반 인터랙션 뿐만 아니라 서비스 요청 핸들링을 위한 메시지 교환을 지원한다. 두 경우 모두, 중개는 요청자가 요청하는 기능을 제공하는 서비스를 찾거나 기능 중심으로 호환되는 요청자와 공급자 사이를 매칭하는 것을 관리하는 등의 인터랙션을 활용하는 것이다. 다음 리스트는 비지니스 커넥션과 중개, 메시징, 이벤트를 설명한다.
- 비지니스 연결은 엔터프라이즈 내부의 어댑터 서비스와 B2B 게이트웨이 서비스를 제공하면서 온 디맨드 서비스들이 엔터프라이즈 내부와 엔터프라이즈 간에 인터랙션을 가능하게 한다. B2B 프로토콜에 필요한 프로세스 조건은 비지니스 프로세스 구성법 레이어에서 제공하는 추가 서비스를 요구한다.
- 중개, 메시징, 이벤트는 ESB가 제공하는 서비스 인터랙션 관리의 다른 측면들이다. 중개는 서비스 요청자와 서비스 공급자를 매칭하여 서비스 공급자와 요청자가 상호 인터랙팅 할 수 있도록 한다. 여기에는 서비스 발견 시나리오의 동적 매치메이이킹에 대한 지원이 포함된다. 서비스 요청자들과 공급자들은 "동기식" 인터랙션으로 메시지들을 교환하여 인터랙팅한다. ESB 서비스는 서비스 공급자부터 서비스 요청자 까지 메시지의 브로커링과 라우팅을 가능하게 한다. 인터랙션은 이벤트를 통해서도 발생 할 수도 있다. 이 경우, "요청자"들은 누가 그것을 받을 지를 모른 채 이벤트를 퍼블리시한다. "공급자"는 특정 필터 기준에 부합하는 이벤트에 그들의 공급하고자 하는 것을 등록시킨다. ESB는 이벤트 생성자와 소비자간 매치메이킹을 사용한다.
정보 관리 서비스
정보 관리 서비스는 이종의 정보 소스들 간 데이터와 콘텐트를 표현, 접근, 유지, 관리, 분석, 통합하는 일관된 방식을 제공한다.
- 분석 서비스는 엔터프라이즈에서 다양한 형태와 스토어(데이터베이스, 플랫 파일, XML 파일, 스프레드시트)로 사용할 수 있는 정보의 분석을 지원한다. 이 서비스에는 스코어링 같은 실시간 분석, 데이터 마이닝 같은 탐구 알고리즘, OLAP와 웨어하우스 리포팅 같은 결정 지원 기능이 포함된다.
- 정보 통합서비스는 이종의 데이터와 콘텐트 소스들을 엔터프라이즈를 통해 통합하는 기능을 지원한다. 또한 데이터 이동,변형, 이종의 분산된 데이터베이스를 통한 동기화를 허용한다.
- 정보 액세스서비스는 애플리케이션들이 광범위한 저장 정보에 JDBC/SQLJ와 ODBC 같은 표준 API를 통해 접근하는 일관된 수단을 제공한다. XML과 콘텐트로 액세스하는 표준들이 개발중이다. 쿼리와 검색은 관계형 소스, XML, 콘텐트, 텍스트 기반 소스를 통해 지원된다.
- 메타데이터 서비스는 데이터 의미와 데이터 관계에 대한 기술과 비지니스 정보를 관리한다. 비지니스와 데이터 관계는 메타데이터에서 계층으로 표현된다. 데이터의 사용자 검색을 지원한다. 정보의 타당성과 품질에 대한 데이터도 저장되며 주파수와 통화 데이터, 스케줄, 일반적인 환경 관리 애트리뷰트가 저장된다. 메타-태깅(Meta-tagging)은 비구조화된 정보의 색인, 분류, 태그 프로세스를 지원하여 일관성을 보장한다.
인프라 서비스
인프라서비스는 온 디맨드 인프라가 제공하는 장치를 구현한다. 유틸리티, 서비스 레벨 자동화, 리소스 구현 서비스로 구분될 수 있다.
앞서 언급했듯이, 인프라 서비스는 통합 서비스와 마찬가지로 애플리케이션 컨테이너에 존재하지만, 통합 서비스와 다른 점은 이러한 컨테이너의 매개변수화는 온 디맨드 운영 환경 애플리케이션 프로그래밍 모델에는 노출되지 않는다. 또한, 인프라서비스는 비지니스 서비스와 같은 원리(그리고 툴)를 사용하여 만들어진다: 프로세스 구성법, 어댑터, 비지니스 규칙, 중재-이 모든 것은 인프라 서비스를 구현 및 연결된다.
리소스 구현 서비스
리소스 구현서비스는 애플리케이션의 물리적 리소스 사용과 물리적 리소스의 실제 할당 간 인다이렉션 레벨을 가능하게 한다.
- 네트워크 구현 서비스는 VPN, VLAN 등의 기능을 사용하여 물리적 네트워크의 구현을 가능하게 한다.
- 리소스 매핑 서비스는 사용자의 레거시 리소스 레파지토리의 추출, 비지니스 서비스 전개를 지원하기 위한 리소스 구성의 표준 리소스 유형으로의 변환, 런타임 시 온 디맨드 리소스들과의 자동 관리 인터랙션을 담당하고 있다.
- 서버 구현 서비스는 클러스터링, 파티셔닝, 가상 머신 같은 기능을 사용하여 인프라 구조를 통해 물리적 서버들을 구현한다.
- 스토리지 구현 서비스는 데이터 그리드 같은 기능을 사용하여 분산 환경을 통해 일관성 있는 정보의 구현을 가능하게 한다.
- 정보 서비스는 문서, 이메일, 이미지, 음악, 기타 비구조화된 데이터를 통해 표현되는 정보를 관리 및 활용하는 수단을 제공한다. 이러한 서비스들은 액세스, 보안, 버저닝, 압축, 보유 등을 포함한 정보의 수명 주기와 관리를 설명하는 정책을 조정 및 실행한다.
서비스 레벨 자동화 및 오케스트레이션
서비스 레벨 자동화 및 오케스트레이션 서비스는 자가 설정, 자가 치료, 자가 최적화, 자가 방어에 대한 시스템 리소스를 실행한다. 이 기능은 자동 매니저와 리소스 매니저가 제공하는 서비스 세트를 통해 실행된다.
자동 매니저는 Monitor 컴포넌트를 통해 원시 리소스 센서 인풋을 받아 처리한다. 이것은 결과 데이터를 Knowledge 베이스에 저장한다. 이 곳은 확립된 정책에 맞게 현재 시스템과 리소스 작동을 평가하기 위해 데이터를 분석 Analyze 하는 모듈로 정비 또는 작동될 수 있다. 시스템 작동이 전체 목표에 맞게 일관되지 않는다면 자동 매니저가 대안 작동 과정을 평가하여 영향 범위에서 설정된 리소스들의 세트에서의 변경을 발효하고 지식 기반에 저장된 정책에 맞게 액션의 계획(Plan)을 선택한다. 자동 매니저는 Execute 이미 관리되는 리소스와 인터랙팅하거나 다른 자동 매니저들과 통신을 통해서 이를 수행한다. 이러한 자동화 작동의 패턴을 MAPE 루프라고 한다.
리소스 관리자는 더 높은 수준의 자동 서비스 레벨 매니저로 부터의 설정 변경 명령에 응대하는 책임이 있다. 리소스 매니저들은 그들이 지원하는 리소스 유형의 인스턴스 생성과 관리를 위한 사실상의 공장이라고 할 수 있다. 이러한 컴포넌트 모델 작동을 통해 기저의 물리적 리소스 토폴로지에 동적으로 묶이는 논리적 리소스 인스턴스를 구현 할 수 있다. 각 논리적 리소스는 그 자체로 서비스이며 분산 상태 관리 및 인터랙션을 위한 ID를 갖고있다. 다음 리스트는 서비스 레벨 자동화 및 오케스트레이션과 관련된 서비스를 설명하고 있다.
- 가용성 서비스는 온 디맨드 환경에서 상황 별로, 가용성과 관련된 서비스 레벨 규약에 따라 다양한 인프라 컴포넌트의 가용성을 관리할 수 있게 한다. 서버 또는 소프트웨어 오류에 대한 간단한 모니터링부터 HACMP 같은 핫 스탠바이 또는 페일오버 솔루션까지 그 범위가 될 수 있다. 가용성 관리에는 백업과 복구(ADSM), 데이터 미러링과 RAID 전개, 비지니스 연속성과 재해 복구 제공 등이 포함된다. 가용성 관리의 궁극적 목표는 정책에서 선언된 복원력을 전개된 솔루션에 제공하는 것이다.
- 설정 서비스는 인프라 구조에서 온 디맨드 환경이 수동 개입을 최소화 하고 오퍼링 관리자가 지정한 목표와 정책에 맞춰 변경을 수용할 수 있도록 하는 기능을 제공한다. 이를 위해서는 최고 레벨의 서비스부터 맨 아래 수준의 리소스 까지 인프라 구조를 스며들도록 해야 한다.
- 문제 관리 서비스는 적절한 로깅과 트레이싱 기능을 제공한다. 이는 정책과 서비스 레벨 관리 컴포넌트 안에서 설계 및 전개되어 SLA가 분명하지 않은 이유로 위법했을 때 시스템 작동의 디버깅을 허용한다.
- 보안 서비스는 온 디맨드 환경이 자가 보호를 수행하도록 하는 기능을 제공한다. 보안은 SLA, SLO, 정책에 기반한 인프라 구조 내에서 제공된 다양한 서비스 인스턴스에 대해 상황에 기반 하여 관리된다. 온 디맨드 환경에서 침입을 감지하는 것은 물론 동적으로 반응하고 추가적인 손상을 막을 수 있다. 각 비지니스 서비스의 보안 아키텍쳐는 감시가 가능하다. 이는 사용자와, 유틸리티 제공자, 범률 지정자를 보호하기 위함이다. 보안을 위해서는 다양한 이벤트(로그온, 로그오프, 웹 히트 등)는 기록되어야 하며 특정 기간동안 보유되어야한다.
- 워크로드 서비스는 모든 전개된 온 디맨드 서비스 인스턴스에 대한 부하가 용량을 초과할 때 인프라 구조 내의 퍼포먼스와 워크로드의 균형을 맞추는 기능을 제공한다. 이 경우 리소스 중재는 어떤 인스턴스가 제한된 리소스를 받아들였는지 어떤 것이 SLA와 정책에 위배되는지를 결정한다. 전체 퍼포먼스 관리는 퍼포먼스 관련 목표를 달성하기 위해 추가 리소스의 밸런싱, 스케쥴링, 제공 등을 조합함으로서 달성된다.
- 데이터 배치 서비스는 데이터 캐시 및 복제의 생성, 관리, 파괴 등을 다룬다. 캐시와 복제를 사용할 기회를 살피면서 시스템의 쿼리 시스템을 감시하여 전체 시스템 퍼포먼스를 향상시킨다. 캐시와 복제의 위치와 특성을 관리하는 배치 정책이 이들 결정을 제어한다.
사용자
사용자는 적절한 액세스 채널 장치를 사용하여 비지니스 서비스 인터랙션 정황에서 역할을 수행하는 인간이다. 이 사용자는 비지니스 서비스와 직접 인터랙팅하는 사용자가 될 수도 있고 사용자를 위한 프록시로서 작동하는 사원이되거나 사용자 그 자체가 사원이 될 수도 있다. 사용자 예제에는 고객, 파트너, 공급자, 사원 등이 포함된다.
사용자 액세스 서비스
사용자 액세스 서비스는 장치 유형, 인터랙션 모드, 연결 토폴로지를 다양화하여 온 디맨드 운영 환경에서 엔드 투 엔드 솔루션에 완벽하게 참여할 수 있도록 한다.
- 채택서비스는 CPU 속도, RAM, 영속 스토어, 디스플레이 크기, OS, 프로세서 명령 세트 등에 기반 하여 장치 기능을 다양하게 한다. 데스크탑, 랩탑, 퍼베이시브 장치들이 포함된다.
- 인터랙션서비스는 사용자 인터랙션 형식(시각적, 수동, 청각적 인터랙션)을 구분한다. 이들을 결합하고 강도를 조절하기도 한다.
- 연결 서비스는 사용자 패턴, 연결 QoS Bearer 네트워크 프로토콜, 기동성, 위치 및 상태 정보, 지역적 범위, 연결 빌링 모델, 도메인, 보안 모델 등에 근거하여 토폴로지 범위를 실행한다.
사용자 인터랙션 서비스
사용자 인터랙션 서비스는 사용자들이 비지니스 서비스와 인터랙팅 할 수 있도록 프리젠테이션 기능을 제공한다. 프리젠테이션 서비스, 협업 서비스, 검색 서비스, 콘텐트 등록 서비스 등이 포함된다.
- 협업 서비스는 사용자들이 다른 사용자들과 인터랙션을 가능하게 하고 인간이 개입하는 고유 영역이다. 채트 협업(이메일, 채팅 등), 팀 협업(e-미팅, 팀룸)으로 크게 구분된다.
- 프리젠테이션 서비스는 비지니스 서비스의 형식을 사용자가 인식하기 쉽고 이해하기 쉽게, 사용자 액세스 서비스와는 독립적인 형식으로 만든다. 사용자가 입력한 데이터를 다양한 서비스들이 처리할 수 있는 정보로 변환하는 것이 이에 포함된다.
유틸리티 비지니스 서비스
유틸리티 비지니스 서비스 레이어는 어떤 리소스 또는 서비스의 사용이 미터링, 정의, 허용되는지를 정의한다:
- 레이팅/빌링 컴포넌트는 기술적 측정을 통화 단위로 변환하여 등록자들에게 청구하는 기능을 제공한다. 이는 레이팅 패키지와 리소스 소비를 측정하는 기존 미터링 기록을 사용하여 리소스의 비용이나 가격을 계산하는 프로세스이다. 또한 SLA 위반에 대한 패널티가 등록자들의 청구서에 포함되기 위해 처리되어야 한다.
- 미터링 서비스는 등록자의 서비스와 리소스 사용과 관련된 정보의 모음을 실행한다. 리소스 사용 또는 소비의 관점으로 표현된다. 모아진 정보는 미터링 서비스에 의해 만들어지며 미터 이벤트로 정의된다. 이 미터 이벤트는 등록자들의 빌링을 위한 기초를 형성하고 가격 책정과 리소스 사용의 기초가 된다.
- 피어링(Peering)/결제는 레이팅과 빌링과 비슷한 프로세스이다. 온 디맨드 비지니스 서비스 사용에 대해 등록자에게 청구하는 대신 비지니스 서비스가 사용하는 리소스와 서비스에 대한 회계 작동을 수행한다. 피어링과 결제는 비지니스 서비스의 등록자 모두에게 투명하다.
감사의 말
이 글은 IBM 내의 팀간 협동 노력의 결과이다. Jim Colson, Angel Luis Diaz, Donald F Ferguson, George Galambos, Ray Harishankar, Shankar S Kalyana, Kristof Kloeckner, Jeffrey Nick, Marc-Thomas Schmidt, Sham Vaidya, Dan Wolfson에게 감사의 말을 전한다.
참고자료
필자소개 | | | Marc-Thomas Schmidt는 IBM에서 Enterprise Service Bus의 엔지니어 및 수석 아키텍트로 일하고 있다. |
| | | Shankar S Kalyana는 IBM의 수석 IT 아키텍트이다. |
기사에 대한 평가
| |
