머리말

SOA(서비스 지향 아키텍처)는 수년 동안 많은 반복을 통해서 진화해온 비교적 새로운 패러다임이다. SOA는 웹 서비스 개념을 중심으로 진화하고, 이는 오늘날 IT 부서들의 수행 방식을 변형시키고 있다. 웹 서비스는 네트워크를 통해서 액세스 할 수 있는 정의가 잘 되어 있는 기능을 가진 모듈식의, 독립적인 코드 조각이라 할 수 있다. SOA의 핵심 컴포넌트는 서비스 공급자, 서비스 소비자, 서비스 레지스트리이다. UDDI(Universal Description, Discovery and Integration)는 XML 기반 표준으로서, 사용자들은 연락처 정보, 제공하는 서비스, 서비스의 기술 정보 등을 등록하는 장소인 레지스트리를 만든다. ("UDDI Spec TC"-참고자료) 서비스 요청자들은 레지스트리를 검색하여, 원하는 서비스를 찾으며, 서비스와 인터랙팅 한다. 웹 서비스는 주로 인터넷을 통해 사용되고, UDDI 레지스트리는 웹 서비스에 위치 제약조건을 만든다. UDDI 레지스트리는 특정 태스크를 수행하고, 사용자들이 특별한 상황에 맞는 것을 선택할 수 있도록 하는 서비스 컬렉션을 제공할 수 있다. UDDI는 서비스 등록을 위한 표준이 되고 있다. 장점은 두 가지이다. 우선, 기업들은 지리적 위치, 비즈니스 단위와 부서에 관계 없이 모든 서비스에 대한 레지스트리를 갖는다. 두 번째는, 시스템 자산들을 통합하여, 비즈니스 비용과 시간을 줄일 수 있다.

웹 서비스는 기반 구현과는 독립된 추상 비즈니스 인터페이스를 가진 독립적인 단위이다. 개발 프로세스는 쉬워야 하며, 클라이언트가 쉽게 액세스 할 수 있어야 한다. 서버 관점에서 볼 때, 커스텀 웹 서비스를 만들고, 여기에 연결할 수 있는 클라이언트에게 WSDL(웹 서비스용 메타데이터 디스크립션)을 노출해야 한다. 아키텍처는 쉬운 표준 방식으로 수정 또는 변경을 수락하고 공유하는 메커니즘이 있어야 한다. UDDI는 이러한 아키텍처의 중심이다. 따라서, 이것으로 충분하다. 하지만, UDDI는 보안성이 취약하고, 비즈니스 서비스 변경 사항을 트래킹 하는 전략이 없다.

오늘날 비즈니스는 전보다 더 동적인 성향이 강해지고, 상황에 빠르게 적응해야 한다. 다시 말해서, 비즈니스 프로세스는 민첩(agile)해야 한다. 웹 서비스가 비즈니스 프로세스를 구현하면, 그 프로세스는 동시에 사용할 수 있는 여러 버전들을 가질 수 있다. 오래된 버전들은 쓸모 없는 것으로 치부되지만, 여전히 관리된다. 예를 들어, 금융 비즈니스는 특정 년도와 달의 이자율을 디스플레이 하는 솔루션을 갖고 있다. 변화된 비즈니스 서비스 트랜드에 맞게 형식을 관리하려면 다양한 버전들이 필요하다. 엔터프라이즈 아키텍처는 서버와 클라이언트가 버전 컨트롤이라는 난제로부터 자유로워질 수 있도록 설정 관리 솔루션을 마련해야 한다. 모든 고객들에게 버전 변화에 대해 알려줄 필요는 없다.

스테이크홀더들이 조직 레벨의 비즈니스 통합에 참여할 수 있도록 더 낫고, 더 단순한 프로토콜을 제공하는 표준들이 만들어지고 있다. UDDI를 사용하는 서비스 공급자들을 위해 UDDI 기능을 확장시킨다. 우선, 각 서비스의 보안 상세를 공유하여 클라이언트가 올바른 프로토콜과 정책을 사용하여 서비스에 액세스 하는 방법을 알 수 있도록 한다. 두 번째로, 서비스의 설정 관리에 맞게끔 UDDI를 확장한다.

이 글에서는 외부 세계와 보안 상세와 아키텍처 디자인을 공유해야 하는 필요성에 대해 설명한다. 비즈니스 품질 프로세스를 핵심 프로세스 영역(KPA)로 유지해야 하는 UDDI의 필요성에 대해 논한다. 현재 UDDI 스팩을 사용하여 엔터프라이즈 중심의 서비스 버저닝을 관리하는 솔루션도 설명한다.

위로

UDDI

UDDI는 SOA의 중요한 부분이고, 유명한 Publish -- Find ? Bind 삼총사를 겸비하고 있다. 서비스 공급자는 서비스 요청자가 서비스를 찾을 수 있는 곳에 UDDI로 자신들의 서비스를 퍼블리쉬 하고, 특정 메커니즘을 사용하여 이들을 연결한다. UDDI의 논리적 구조는 세 개의 카테고리로 나뉜다. 각각 화이트 페이지(white pages), 옐로우 페이지(yellow pages), 그린 페이지(green pages)이다. 화이트 페이지는 비즈니스 정보와 연락처 정보가 저장된다. 옐로우 페이지에는 비즈니스가 제공하는 서비스에 관한 정보가 저장된다. 그린 페이지는 서비스에 대한 모든 기술적 정보가 저장된다. UDDI는 네 개의 데이터 구조로 나뉜다.

1. BusinessEntity
2. BusinessService
3. BindingTemplate
4. TModel

BusinessEntity는 서비스를 제공하는 비즈니스로서, BusinessService로서 지정된다. BindingTemplate은 서비스 요청자가 서비스로 연결되는 방법을 설명한다. TModel은 서비스가 순응해야 하는 기술 모델이다. 모든 레지스트리 엔트리에 대해 계층적 구조를 만든다. 범주와 날짜 같은 상세들을 나타내는 다른 엘리먼트와 하위 엘리먼트들도 물론 있다.

위로

개념 입증: “UDDI PoC”

대표적인 J2EE 애플리케이션 서버인 IBM WebSphere Application Server v6을 사용한 솔루션을 분석할 것이다. 이 서버는 UDDI 노드 레지스트리를 사용하여 멀티 버전 및 멀티 보안 정책 서비스 인터랙션을 표방하고 있다. 비즈니스 티어는 .NET 서버이고, 이곳에서 모든 웹 서비스들을 전개한다.

보안 정책 공유 이론을 테스트 하기 위해, 서비스 공급자는 두 개의 다른 보안 정책들을 가진 서비스를 만든다. 버저닝 지원을 확인하기 위해, 다른 구현들을 가진 두 개의 서비스들과, 다른 서명 또는 인터페이스를 가진 또 다른 서비스를 만든다. 이러한 서비스들은 .NET 플랫폼의 다른 박스에 배치된다.

서비스 레지스트리 레벨에서, 우리는 모든 비즈니스 서비스를 등록하고, 이 글에서 설명한 메커니즘에 따라 이들을 설정한다.

서비스 소비자 측면에서는, 클라이언트 컴포넌트를 두 개의 섹션들로 나눈다. 첫 번째 클라이언트 컴포넌트를 구현하여, 클라이언트가 정책 파일들을 이해하고, 서비스 생산자들이 설정한 보안 구현을 따르도록 한다. 그런 다음, 다양한 서비스 버전들에 액세스 하기 위해 클라이언트 컴포넌트를 사용한다. 이 메커니즘에는 예외 핸들링 관리가 있어서, 변하는 버전들에 적응하고, 궁극적으로 웹 서비스에 보다 쉽게 액세스 할 수 있도록 한다. 서비스 레지스트리와 서비스 생산자가 있는 곳과는 다른 자바 플랫폼에 클라이언트 스텁과 커스텀 컴포넌트를 구현할 것이다.

위로

보안 정책 공유

배경

현재, UDDI는 웹 서비스 보안 문제를 다루지 않는다. 비즈니스 관점에서 볼 때, 웹 서비스 통신에서 보안은 중요하다. 대부분의 비즈니스 프로세스와 트랜잭션들이 보안화 되지 않은 인터넷을 통해 발생하기 때문이다. 또 다른 제약 사항은 웹 서비스 트랜잭션이 인간 대 프로세스(human-to-process)가 아닌 프로세스 대 프로세스(process-to-process)로 가고 있다는 점이다. 따라서, 동적인 보안 스킴이 훨씬 더 중요해 졌다. 웹 서비스 사용이 늘어나면서, 웹 서비스 환경 참여자들도 늘어나고 있다. 따라서, 확장성 있고, 적응성 있는 보안 메커니즘을 마련해야 한다. WS-Security, Extensible Access Control Markup Language (XACML) Security Assertion Markup Language (SAML) 같은 표준들은 서비스 레이어 상의 보안 구현을 다루고는 있지만, 끊임없이 변화하는 인터랙션 시나리오와 관련하여 보안 정보를 공유하는 효율적인 방식을 제공하지는 못한다.

웹 서비스를 보안화 하려면, username 토큰, XML 토큰, 바이너리 토큰, Kerberos 토큰 같은 보안 토큰과, X.509 인증서 같은 보안 인증서, 서명과 암호화를 사용한다. 두 당사자들 간 SOAP 메시지 통신을 보안화 하는 것이 목표이다. WS-Security와 WS-SecurityPolicy(참고자료) 같은 표준들은 웹 서비스용 보안을 구현하는 메커니즘을 제공한다. WS-Security는 SOAP 메시지를 강화하여 보안 정보를 보낼 수 있다. IBM, Microsoft, Verisign 등 선두 업체에서 제공한 WS-Policy 프레임웍인 WS-SecurityPolicy는 범용 모델과 상응하는 신택스를 제공하여 웹 서비스 정책들을 기술한다. WS-Policy는 다른 웹 서비스 스팩들이 사용할 수 있는 기본 구조를 정의하고, 서비스 요구 사항, 선호도, 기능으로 범위를 확장했다. WS-SecurityPolicy는 웹 서비스가 보안 관련 요구 사항과 제약 조건들을 표현하는 방식을 정의한다. 웹 서비스와 연관된 WS-SecurityPolicy 파일에서는 토큰 유형, 구성 알고리즘, 메커니즘과 관련하여 메시지를 보안화 하는 방법을 설명하고 있다. 전송 레벨 보안은 디자인의 일부이고, 시간이 흐르면서 진화한다. 보안 정책 파일은 서비스 요청자에게 서비스 보안 크리덴셜을 알려주고, 지정된 방식으로 액세스 할 수 있도록 한다. 보안은 다양하기 때문에 실제 비즈니스 서비스 디스크립션과 이를 분리해야 한다.

보안 정책의 동기

일반적으로 통합된 애플리케이션이나 B2B 시스템들은 보안 정책에 대한 매뉴얼 계약을 갖고 있다. 두 애플리케이션 모두 이러한 계약에 종속되기 때문에, 같은 방식으로 관련(종속된) 클라이언트들을 업데이트 한다. 서비스 구현자는 보안 표준을 제공하고, 클라이언트는 이에 따라 서비스에 액세스 한다. 장기적으로 볼 때, 이러한 계약을 유지하는 것은 어려운 일이다. 이유는 다음과 같다.

1. 파트너에게 공지하지 않을 경우에 발생하는 에러가 있을 수 있다.
2. 프로세스를 구현하는 추가 비용이 든다.
3. 서비스 측에서 보안 정책을 수정하기 위해 재고해야 한다.

솔루션 방식

비즈니스가 UDDI 레지스트리에 서비스를 기록하면, 레지스트리는 TModel에 WSDL URL을, 서비스의 바인딩 템플릿에 서비스 엔드포인트를 저장한다. 서비스 소비자는 레지스트리를 검색하고(“UDDI 개념 증명” 참조), 엔드포인트와 WSDL URL에 액세스 한다. 같은 방식으로, 서비스의 보안 정책 파일을 저장할 수 있는 장치도 레지스트리에 넣을 수 있다. 다시 말해서, 서비스 요청자들은 서비스의 보안 정책을 따르는 방법을 알고 있다.

WS-SecurityPolicy 파일은 특정 웹 서비스가 따르는 보안 정책을 지정하는 웹 서비스와 제휴된다. 서비스 요청자는 요청할 때 정책을 준수하며 웹 서비스를 호출한다. UDDI 레지스트리는 사용자가 웹 서비스의 보안 정책을 검색할 수 있는 메커니즘을 필요로 한다. 이것은 WSDL 검색과 비슷하다. UDDI 레지스트리는, TModel에 WSDL URL을 저장하듯, 보안 정책 파일의 URL을 저장한다. TModel에서, OverviewURL로 WSDL URL을 저장한다. 어떤 수의 OverviewURL도 가질 수 있기 때문에, 같은 TModel에 두 번째 OverviewURL에 보안 정책 파일을 저장할 수도 있다. 그림 1은 IBM WebSphere App Server 6 Test UDDI 노드에 있는 같은 TModel에 두 개의 OverviewURL 모습이다.

WSDL에서 하는 것처럼 정책 파일을 프로그래밍 방식으로 가져올 수 있고, 웹 서비스를 호출하면서, 런타임 시 클라이언트에서 이를 사용할 수 있다. 클라이언트는 정책 파일이 제안하는 대로 보안 정책을 다룰 수 있어야 한다.

이는 특정 비즈니스 필요를 염두하고, 두 당사자들이 보안 정책을 설계할 수 있는 유연성을 준다. 정보를 공유하기 위해 서비스 레벨 계약(SLA)를 정의할 필요가 없다. 이 프로세스는 아키텍처에 사전 구현되어있기 때문에, 두 당사자 모두 완벽히 연결된다. 통신하는 당사자들은 긴밀히 연결된 환경에서 엔드포인트 정보의 유연하고 동적인 교환을 통해서 특정 정책이나 프로토콜에 대한 공통적인 생각을 공유한다.

사용자와 클라이언트는 UDDI를 통해 WSDL 파일과 정책 파일을 공유할 수 있다. (그림 2)

이러한 방식으로 비즈니스는 WSDL을 공유하고, 보안 정책도 공유한다.

성과

우리는 현재의 UDDI 버전에 보안 관리 솔루션을 만들었다. 차기 UDDI 버전에는 이러한 변화들이 적용될 것이다.

위로

설정 관리 역할을 하는 UDDI

배경

웹 서비스 버저닝과 관련하여 수년 동안 많은 시도들이 있었다. 그 중 하나인, WS-Versioning은 사용자에게 버전 관련 정보 변경을 공지하는 고조를 정의한다. WS-Addressing은 BEA, IBM, Microsoft, SAP, Sun Microsystems의 합작품으로(참고자료), 상호 운용 방식으로 정보를 전달하는 두 개의 구조를 정의한다. 전송 프로토콜과 메시징 시스템이 이를 제공한다. 이러한 구조들은, 여러분이 전송 또는 애플리케이션과는 독립적으로 처리할 수 있도록 통일된 포맷으로 기반 정보를 표준화 한다. 이 두 개의 구조들은 엔드포인트 레퍼런스와 메시지 정보 헤더이다. WS-Addressing은 또한 WS-Versioning 표준을 향상하여 버저닝 메커니즘도 다루고 있다.

UDDI v3 스팩에 따르면, “등록(Subscription)은 등록자(subscriber)로 알려진 클라이언트에게, UDDI 레지스트리에서 이루어진 변경과 관련한 정보를 받을 때 그들의 관심사를 등록할 수 있는 기능을 제공한다. 변경 사항들은 요청에서 제공하는 선호도에 따라 지정될 수 있다.” 따라서, UDDI는 정보 변경 사항에 대해 사용자에게 알리지만, 버전 정보는 보여주지 않는다.

설정 관리 솔루션의 동기

웹 서비스는 시간이 흐르면서 변한다. 예를 들어, 소득세를 계산하는 웹 서비스는 해마다 변한다. 따라서, 서비스 레지스트리를 만들 때 이를 고려해야 한다. 사용자들은 최신 웹 서비스 버전을 파악해야 하고, 필요할 때면 언제든 오래된 버전에 액세스 할 수 있어야 한다. 그림 1은 이를 묘사하고 있다.

버저닝의 필요를 이해할 수 있도록 실제 예를 들어보도록 하겠다. 금융 회사는 투자된 돈에 대해 이자를 지불한다. 보편적으로 채택된 알고리즘 또는 이 회사만 따르는 특정 알고리즘을 사용하여 발생된 이자를 계산한다. 이것이 월 단위로 계산되고 두 개의 값에 기반하고 있다고 생각해 보자. 언제나 일정한 기본 값과 매달 변하는(특정 알고리즘에 기반함) 유동 값이다. 사용자는 인터넷에서 그 회사의 웹 서비스를 사용하여 해당 월의 이자를 계산할 수 있다. 사용자가 현재(월)의 이자를 체크하고 싶다면, 최신 웹 서비스 버전을 사용할 것이다. 지난 달에 받았던 이자를 체크하고 싶다면 유동 값으로 인해서 이자율이 변경되기 때문에 오래된 웹 서비스 버전을 체크해야 한다. 어떻게 하면, 회사는 UDDI 레지스트리에 모든 웹 서비스 버전들을 명확히 광고하여, 사용자들이 언제나 현재 버전을 사용할 수 있도록 할까? 여러분도 알다시피, 버전 지원은 비즈니스와 엔드 유저에게 있어서 중요한 기능이다. UDDI는 웹 서비스의 주요 표준이고 든든한 업계 지원도 받고 있지만, 보안과 웹 서비스 버저닝 지원은 충분하지 못하다.

엔터프라이즈 레벨 솔루션을 지원하기 위해서는, 웹 서비스도 자연스럽게 점점 복잡해 진다. 추가 정보를 사용하여, 웹 서비스는 모든 정보를 전달하는 무거운 컴포넌트가 되고 있고, 이는 웹 서비스를 등록하는 티어에게로 분산될 수 있다.

웹 서비스 표준에는 중대한 단점이 있다.

1. 웹 서비스 표준은 메시지 구조를 복잡하고 무겁게 만든다.
2. 웹 서비스는 세분화 된 비즈니스 로직을 다루기 보다는 서비스 관리 기술로 분화된다.

솔루션

UDDI 데이터 구조에서, BusinessEntity에는 한 개 이상의 BusinessService 엘리먼트가 포함되어 있고, 여기에는 BindingTemplates가 포함되어 있으며, 또 이곳에는 TModel이 포함된다. BusinessEntity, BusinessService, TModel에는 IdentifierBag과 CategoryBag 엘리먼트가 포함된다. IdentifierBag은 특정 서비스나 비즈니스를 규명하고, CategoryBag은 구조화된 방식으로 UDDI 엔트리들을 구성한다. 이것을 UNSPSC, NAICS, ISO 3166 같은 일반적인 분류 스킴에 기반하여 분류한다. IdentifierBag 또는 CategoryBag을 이용하여 BindingTemplate과 TModel 사이를 매핑한다. WebSphere Application Server v6을 사용하기 때문에, CategoryBag을 사용하고 관리 GUI를 통해서 분류 정보를 추가할 수 있다.

키네임(keyname) "Version"과 버전 넘버 같은 키 값을 사용하여 CategoryBag에 버저닝 정보를 추가한다. BindingTemplate이 이미 특정 BusinessService로 연결되기 때문에, 이들을 매핑할 필요가 없다. 하지만, BindingTemplate에 CategoryBag을 갖고 있는 UDDI v3에서는, BindingTemplate의 CategoryBag에 서비스 이름을 넣어서 BindingTemplate과 BusinessService를 명확히 매핑한다.

TModel이 BindingTemplate으로 연결되기 때문에, 서비스 소비자(“UDDI 개념 입증” 참조)는 어떤 서비스 버전을 사용하고 싶은지를 명령할 수 있다. 그런 다음 우리는 버전 넘버에 기반하여 TModel(WSDL URL)을 검색할 수 있다. 런타임 동안, 서비스 소비자는 특정 BindingTemplate과 제휴된 TModel을 검색하고, CategoryBag에서 특정 버전 넘버를 검색할 수 있다.

성과

UDDI는 엔터프라이즈 솔루션의 설정 관리 중 Capability Maturity Model's (CMM) KPA 역할을 수행한다. WS-* 표준과는 달리, UDDI는 레지스트리에 여러 버전의 웹 서비스 디스크립션을 포함시킬 수 있다. 따라서 서비스 공급자는 최신 버전을 광고할 수 있고, 비즈니스 요구 사항에 따라, 다양한 웹 서비스 버전들간 선택할 수 있는 유연성도 제공할 수 있다. 요약하면 다음과 같다.

1. 확장된 UDDI는 활성 웹 서비스와 이것의 리파지토리에 대한 디스크립션과 발견이다.
2. 같은 비즈니스 엔터티와 비즈니스 서비스에서, 공급자는 다양한 소비자들에게 같은 웹 서비스의 다양한 버전들을 제공할 수 있다.
3. 공급자는 이전 섹션에서 언급한 독립 보안 정책을 사용하여 다양한 고객들에게 같은 웹 서비스를 제공할 수 있다.
4. 결국, UDDI는 비즈니스가 품질 설정 관리를 관리하는데 도움이 된다.

구현 전략은 UDDI v3 솔루션이다. UDDI는 등록된 서비스들의 버저닝을 지원하지 않는다. 엔터프라이즈 레벨 애플리케이션들은 UDDI가 고유의 웹 서비스 설정 관리를 하도록 위임하고 있다. 차기 UDDI 버전은 이러한 방식을 지원할 것이고, 아키텍트는 양질의, 완전한 방식을 사용하여 SOA 기반 엔터프라이즈 애플리케이션을 구현할 수 있을 것이다.

UDDI 향상

UDDI는 정책과 버전 정보를 소비자에게 제공한다. UDDI는 중앙화 되고 통합된 거버넌스 및 관리 솔루션이 필요하다. 해결책은 기존 표준과 플랫폼에 기반한다. 기존 UDDI 표준에 이러한 기능들을 결합한다면 가능하다.

맺음말

보안과 버저닝은 웹 서비스 구현에 있어서 중요한 측면이고, 비즈니스가 성장하면서, 보안과 버저닝 문제는 점점 더 중요해지고 있다. 기존 표준을 사용하여 이러한 문제들에 대한 솔루션을 검토했고, UDDI를 사용하여 웹 서비스 클라이언트를 보안화 하고 버전 변경을 인지하는 방법을 설명했다. UDDI 스팩을 조금만 변경해도 이상적인 솔루션이 만들어 질 수 있다.

기사의 원문보기

• Enhance UDDI to manage Web services

참고자료

교육

• UDDI Spec TC
  
  
• Web Services Security Policy Language (WS-SecurityPolicy)-Giovanni Della-Libera. (IBM, Microsoft, Verisign, July, 2005)
  
  
• Web Services Addressing- Robin Cover (Cover Pages, December, 2005)
  
  

제품 및 기술 얻기

• UDDI4J: Matchmaking for Web Services - Doug Tidwell (IBM developerworks, 2001)
  
  
• UDDI Inadequate for SOA- Peter Abrahams (IT-director.com, September, 2005)
  
  
• Versioning of Web Services: An UDDI Subscription-Based Approach- Aravilli Srinivasa Rao
  
  

토론

• 웹 서비스의 동적 발견과 호출 (한글) - Damian Hagge (IBM developerworks,2001년 8월)
  
  

필자소개

Bijoy Majumdar는 글로벌 IT 컨설팅 기업인 Infosys Technologies사의 SOA and Web Services COE (Center of Excellence) 소속이다. 왕성한 기고 활동과 컨퍼런스에 참여하여 프레젠테이션도 하며, SOA와 웹 서비스용 표준을 만들고 있다. Infosys에 입사하기 전에, 기술 아키텍트로서 엔터프라이즈 솔루션을 설계했다.

Ambar Verma는 글로벌 IT 컨설팅 기업인 Infosys Technologies사의 SOA and Web Services COE (Center of Excellence) 소속이다. SOA를 주제로 많은 글들을 출간했으며, 다양한 기술 컨퍼런스에서 프레젠테이션도 하고 있다. SOA와 웹 서비스를 위한 표준도 정의하고 있다. 주 업무 영역은 SOA, ESB, 웹 서비스이다.

Ujval Mysore 는 글로벌 IT 컨설팅 기업인 Infosys Technologies사의 SOA and Web Services COE (Center of Excellence) 소속이다. 왕성한 기고 활동과 컨퍼런스에 참여하여 프레젠테이션도 하며, SOA와 웹 서비스용 표준을 만들고 있다. ESB와 웹 서비스 같은 SOA 인에이블링 기술이 주요 분야이다.

아티클 순위

의견

위로

목차

• 머리말
• UDDI
• 개념 입증: “UDDI PoC”
• 보안 정책 공유
• 설정 관리 역할을 하는 UDDI
• 참고자료
• 필자소개
• 의견