Chapter 4 UDDI(Universal Description, Discovery,
and Integration)
상품을 제작하는 회사들이 각각 자기 회사의 상품 정보와 가격 정보를 제공하는 웹 서비스 시스템을 개발했다고 가정하자, 제작 회사는 자사가 제공하는 웹 서비스를 보다 더 많은 주문자들이 이용하도록 UDDI 레지스트리에 웹 서비스를 공개한다. 또한 주문자는 가장 적합한 상품을 주문하기 위해서 UDDI 레지스트리에서 동종 상품을 제작하는 회사를 여러 개 찾아서 기간과 가격 조건을 비교한 다음 최종 주문을 낸다. 여기서 UDDI 레지스트리는 웹 서비스에 대한 정보를 게시하고 검색할 수 있는 수단으로 이용된다.
1. UDDI 소개
2000년 초에 웹 서비스의 아이디어는 커뮤니티에서 주목 받기 시작했고, 웹 서비스 레지스트리는 웹 서비스 개념들을 실현하기 위한 필수 요소로 떠올랐다. 더욱이 이 같은 레지스트리를 위한 표준 인터페이스와 검색 메커니즘은 커뮤니티의 오픈 스탠다드와 부합하는 개념이다.
UDDI의 목적은 설계시점과 실행 시점 모두에 있어 서비스 검색을 쉽게 하는데 있다. UDDI 프로젝트의 결과 2001년 5월 2일 첫 번째 공개 온라인 비즈니스 레지스트리를 운영하게 되었다. 이 레지스트리를 UDDI 비즈니스 레지스트리라고 한다. 대표적인 UDDI 비즈니스 레지스트리는 IBM과 Microsoft사에 의해 운영되고 있으며, 서로간에 복제된다.
2. UDDI 레지스트리
UDDI 레지스트리는 각종 정보들을 생성, 저장, 검색할 수 있는 XML기반의 자료 저장 장치를 말한다. UDDI 레지스트리의 클라이언트가 UDDI 레지스트리에 접근해서 정보를 저장하고, 찾기 위해서는 SOAP 메시지를 이용한다, 또한 SOAP 메시지를 전송용 프로토콜로 인터넷 전용 프로토콜인 HTTP 프로토콜을 사용함으로써 클라이언트의 플랫폼과 구현 언어에 독립적인 UDDI레지스트리를 사용할 수 있다. UDDI 레지스트리의 클라이언트는 UDDI 레지스트리 프로바이더 를 통해서 SOAP 메시지를 생성하고, 전송한다.
3. UDDI 사용 모델
일반적으로 레지스트리는 소프트웨어 컴포넌트, 서비스 또는 그 이외의 것들에 대한 기본적인 요구사항을 포함한다.
· 레지스트리 내에 저장되는 메타데이터를 위한 데이터 구조집합
· 레지스트리 내의 데이터 저장, 질의를 위한CRUD(Create, Read, Udate, Delete) 연산 사양 집합
메타데이터를 위한 레지스트리의 공통 요구사항은 다음과 같다.
· 소유권과 억제권 : 다시 소유권을 할당하지 않는다면 자신이 등록한 데이터와 하위 데이터는 자신이 소유한다.
· 분류 : 데이터는 검색과 조직을 용이하게 하도록 하나 또는 그 이상의 카테고리에 속할 수 있다.
· 논리적인 참조 메커니즘 : 레지스트리의 다른 부분을 가리키는데 참조를 사용할 수 있다.
연산을 위한 레지스트리의 공통 요구 사항
· 정보 변경 연산과 공개 등록을 위한 인증
· 조회와 질의 연산을 위한 공개적인 접근 허용
4. UDDI 레지스트리 제품
UDDI 레지스트리 서비스를 운영하는 회사를 UDDI 운영자라 한다. 운영자들은 UDDI 운영 사이트를 자체적으로 가지고 있다.
· IBM 레지스트리
home page : http://www-306.ibm.com/software/solutions/webservices/uddi/
테스트 레지스트리 : http://www-306.ibm.com/software/solutions/webservices/uddi/
비즈니스 레지스트리 : https://uddi.ibm.com/ubr/registry.html
· Microsoft 레지스트리
비즈니스 레지스트리 : http://uddi.microsoft.com/
테스트 레지스트리 : http://test.uddi.microsoft.com/
사설 레지스트리
특정 회사 내부에서 사용할 목적으로 사설 UDDI 레지스트리를 설치하여 사용할 수도 있다. 보통 다음과 같은 이유로 사설 UDDI 레지스트리를 설치하여 사용한다. 사설 UDDi 레지스트리를 설치하려면 UDDI 제품을 무료 또는 유료로 구입해야 한다.
· 원격의 UDDI 레지스트리보다 빠른 속도를 보장하기 위해서
· 회사 내부에서만 관리되고, 사용하기 위해서
· 정보 자체의 신뢰성을 높이기 위해
5. UDDI 데이터 구조
일반적으로 UDDI 레지스트리에는 웹 서비스에 대한 정보와 웹 서비스를 제공하는 회사에 대한 정보가 담겨 있다. 정보는 화이트, 옐로우, 그린 페이지에 속하는 정보로 분류된다.
· 화이트 페이지 : 회사의 이름, 주소, 전화번호 그리고 회사에 관한 설명이 여기 속한다.
· 옐로우 페이지 : 선업계의 분류 체계별, 생산물과 웹 서비스의 분류 체계별, 그리고 지역별 회사 목록이 여기 속한다.
· 그린 페이지 ; 각 회사에서 제공하는 웹 서비스에 대한 기술적 정보를 말한다. 예를 들어 웹 서비스 시스템의 종점 URL이나 WSDL문서의 URL 등이 여기에 속한다.
엘리먼트 |
용도 |
정보 분류 |
<businessEntity> |
화사 자체에 대한 정보인 회사 이름, 회사 주소, 전화번호 내용을 기술 |
화이트 페이지 |
<publisherAssertion> |
businessEntity 간의 연과 간계를 기술 |
화이트 페이지 |
<identifierBag> |
businessEntity에 대한 대체 식별자로 사용되는 정보를 기술 |
옐로우 페이지 |
<categoryBag> |
분류에 대한 정보를 기술 |
옐로우 페이지 |
<businessService> |
회사에서 제공하는 웹 서비스의 이름 및 설명을 기술 |
그린 페이지 |
<bindingTemplate> |
웹 서비스에 대한 종점(endpoint) URL 정보 및 웹 서비스와 관련된 tModel을 참조하는 내용을 기술 |
그린 페이지 |
<tModel> |
웹 서비스에 대한 메소드의 종류 및 인자의 데이터 타입이 정의된 WSDL 문서의 URL 경로를 기술 |
그린 페이지 |