1. UDDI 소개
UDDI(Universal Description, Discovery, and Integration) 저장소는 각종 정보들을 생성, 저장, 검색할 수 있는 XML 기반의 자료 저장 장치를 말한다.
* 클라이언트의 플랫폼과 구현 언어에 독립적이다.
정보 저장 및 검색을 위해 SOAP 메시지를 사용하고, SOAP 메시지 전송 프로토콜로서 HTTP를 사용하기 때문에 가능하다.
* UDDI 저장소 간의 데이터 교환이 자유롭다.
UDDI 저장소 개발 언어 및 실행 플랫폼과는 상관없이 데이터 교환 포맷으로 XML 문서를 사용하기 때문에 가능하다. 따라서 한 개의 UDDI 저장소에 정보를 저장하더라도 복제 관계에 따라 모든 저장소에 복제가 되어 웹 서비스 정보가 보다 많은 클라이언트에게 홍보될 수 있다.
웹 서비스 제공자는 가능한 많은 웹 서비스 소비자에게 웹 서비스 시스템의 기능을 제공할 수 있어야 한다. 웹 서비스 소비자들 역시 가능한 많은 웹 서비스 시스템을 찾을 수 있어야 한다.
특정한 웹 서비스를 찾기 위해서 엄청난 분량의 인터넷 페이지를 뒤지는 것은 결코 좋은 방법이 될 수 없다. 하지만 만약에 웹 서비스 시스템에 대한 정보가 한 곳에 잘 분류화되어 있다면 훨씬 쉽게 검색될 수 있을 것이다. 물론 서비스 제공자 입장에서도 많은 소비자에게 웹 서비스의 기능을 알릴 수 있을 것이다. 이것이 가능하도록 도와주는 웹 서비스의 중개자 역할을 수행하는 것이 바로 UDDI 저장소이다.
UDDI는 Ariba, IBM, MS 3사에서 시작되었고, 현재 수 백 여개의 회사가 UDDI 커뮤니티에 참여하고 있다. 현재 UDDI의 최신 버전은 3.0이고, http://www.uddi.org를 통해 제공 회사의 UDDI 저장소가 어떤 버전을 지원하는지를 알 수 있다. 현재 몇 몇 공용 UDDI 저장소를 가지고 있는 회사와 URL은 다음과 같다.
| 회사명 | URL |
| IBM | http://www-3.ibm.com/services/uddi/ |
| MS | http://www.microsoft.com/default.aspx |
| IBM 저장소 IBM에서 운영하고 있는 UDDI 버전 2 저장소는 두 종류가 존재한다.
1. 테스트 저장소 비즈니스 저장소에 어떤 정보를 올리기 전에 테스트할 수 있는 저장소로서 모든 이에게 열려 있다.
운영 사이트 : http://uddi.ibm.com/testregistry/registry.html 2. 비즈니스 저장소 실제 비즈니스 거래에서 사용되는 것으로서, 저장소에 저장된 정보가 다른 UDDI 저장소에 복제가 된다는 것이 테스트 저장소와의 차이점이다.
|
| Microsoft 저장소 IBM 저장소와 마찬가지로 테스트 저장소와 비즈니스 저장소가 운영되고 있다.
운영 사이트 테스트 저장소 http://test.uddi.microsoft.com 비즈니스 저장소 http://uddi.microsoft.com |
여러분이 자신의 웹 서비스를 위와 같은 공용 UDDI 저장소에 등록하면, 다른 사용자들이 여러분의 웹 서비스를 쉽게 찾아 사용할 수 있을 것이다. 물론 이러한 공용 저장소 외에 여러분만의 저장소를 만들어 등록할 수도 있다. 실제로 회사나 조직 같은 곳에서는 공용 UDDI 저장소를 사용하는 것보다 사설 UDDI 저장소를 이용하는 것이 더 좋을 수도 있다.
사설 UDDI 저장소는 공용 UDDI 저장소보다 관리나 접근이 용이하며, 그것을 이용하는 회사나 조직만을 위한 웹 서비스를 유지할 수 있다. 또한 공용 UDDI보다 좀 더 신뢰할 수 있는 웹 서비스를 유지할 수 있다. 공용 UDDI를 통해 웹 서비스를 이용할 경우, 누가 해당 웹 서비스가 제대로 기능하는 지 보장할 수 있는가? 하지만 사설 UDDI는 공용 UDDI에서 제공하는 기능 중 일부만 제공할 수도 있다. 자신만을 위한 UDDI를 가진다는 것은 여러 모로 유용하며, 이를 위한 다양한 제품들이 이미 나와 있다.
| * 사설 IBM UDDI 저장소 http://www.alphaworks.ibm.com/tech/UDDIreg/ * MS UDDI 저장소 http://www.microsoft.com/windowsserver2003/technologies/idm/uddi/default.mspx |
웹 서비스 제공자는 UDDI를 통해 자신의 웹 서비스를 등록할 수 있고, 웹 서비스 사용자는 자신이 원하는 웹 서비스에 관한 정보를 UDDI를 통해 추출할 수 있다. UDDI는 단순히 웹 서비스에 관한 정보만이 아니라 웹 서비스 제공자에 대한 정보까지 포함한다. 이를 위해 현재 UDDI 버전 3 스펙까지 발표되었지만, UDDI 저장소를 제작하는 업체에서 출시된 제품과 현재 공개 서비스를 운영하고 있는 대부분의 UDDI 저장소 제품은 UDDI 버전 2 스펙을 가지고 구현된 것이다.
| UDDI 스펙 http://www.uddi.org/specification.html |
① 데이터 구조 스펙
어떤 구조의 XML 문서가 UDDI 저장소에 저장될 수 있는지가 기술되어 있다.
② UDDI 저장소 사용을 위한 API 스펙
프로그래밍 언어에서 UDDI 저장소에 어떻게 접근할 수 있는 지에 대해 기술되어 있다.
③ 복제(replication) 스펙
저장소 간에 정보를 복제하는 방법에 대해 기술되어 있다.
④ UDDI 관리자를 위한 스펙(operator's specification)
UDDI 저장소 제품을 만들 때 구현해야 할 내용(보안, 감시, 데이터 관리 등)이 기술되어 있다.
2. UDDI 데이터 구조
2.1 구성
UDDI 저장소는 웹 서비스에 대한 정보뿐만 아니라 웹 서비스 제공자에 대한 정보도 갖고 있다. 이와 같이 등록된 회사와 서비스를 저장하기 위해서 UDDI 저장소는 전화번호부와 비슷한 구조를 이용하며 다음과 같이 서로 별개인 세 가지 타입의 페이지를 가지고 있다.
① 화이트 페이지 (white page)
일상의 전화번호부와 같이 화이트 페이지는 회사의 이름으로 색인 되어 있다. 여기에는 회사 이름, 연락처, 전화번호와 같은 정보들이 담겨 있다. 추가로 전화번호부에서는 찾을 수 없는 신용 등급과 같은 데이터도 포함하고 있다.
② 옐로우 페이지 (yellow page)
이 페이지는 회사를 종류별로 분류한다. 바꾸어 말하면 옐로우 페이지는 분류법을 나타낸다. 전화번호부의 경우 분류법의 정의는 전화 회사 또는 출판사가 맡고 있지만 이런 해결책은 보편적인 지원의 요구사항을 만족하지 않을 것이다. UDDI 설계자들은 새로운 분류법을 백지 상태에서 만들어내기 보다는 캐나다, 멕시코, 미국의 공통 산업 정의를 제공하는 북미 산업 체계 분류(North America Industry Classification System, NAICS, http://www.census.gov/epcd/www/naics.html)와 같이 잘
정립된 분류 체계를 기반으로 지원하기로 결정했다. 또한 UN이 보증하는 분류법도 지원한다.
③ 그린 페이지 (green page)
이 페이지는 웹 서비스에 관한 사무적인 묘사와 기술적인 묘사를 포함하고 있다. 예를 들어 웹 서비스 시스템의 종점 URL이나 WSDL 문서의 URL 등이 여기에 속한다.
이러한 구성은 UDDI 저장소에 웹 서비스를 등록할 때, 화이트 페이지, 옐로우 페이지, 그린 페이지를 구성하기 위한 모든 정보가 필요하며, 사용자는 이렇게 등록된 웹 서비스를 웹 서비스 제공자 이름, 주소, 표준 산업 분류, 웹 서비스 타입 등을 통해 찾을 수 있다.
2.2 데이터 구조
UDDI 저장소에 들어가는 데이터의 형태를 알아보자. UDDI 저장소 데이터 구조는 다음과 같은 XML 스키마 문서에 정의되어 있다.
http://uddi.org/schema/uddi_v2.xsd
위의 XML 스키마 문서는 한 개의 비즈니스 정보를 생성하는 데 필요한 다음과 같은 7가지의 요소를 정의하고 있다.
| 요소이름 | 용도 | 정보분류 |
| <businessEntity> |
이것은 서비스 제공자에 대한 일반적인 정보(회사 이름, 회사 주소, 전화 번호)와 서비스 목록을 담고 있다. |
화이트 페이지 |
| <publisherAssertion> |
businessEntity 간의 연관 관계를 기술한다. |
|
| <identifierBag> | businessEntity에 대한 대체 식별자로 사용되는 정보를 기술한다. | 옐로우 페이지 |
| <categoryBag> | 분류에 대한 정보를 기술한다. | |
| <businessService> | 회사에서 제공하는 웹 서비스의 이름 및 설명을 기술한다. 레코드는 웹 서비스의 사무적인 묘사와 기술적인 묘사를 포함하고 있기 때문에 그린 페이지의 핵심이다. 이것은 관련된 웹 서비스들의 집합에 대한 컨테이너이다. 관련된 웹 서비스들이란 배송에 관련된 모든 서비스들 또는 고객 관계 관리를 위한 모든 서비스들 같은 것이다. 웹 서비스의 기술적인 설명은 bindingTemplate 컨테이너에 저장된다. |
그린 페이지 |
| <bindingTemplate> | 웹 서비스에 대한 종점 URL 정보 및 웹 서비스와 관련된 tModel을 참조하는 내용을 기술하기 위한 컨테이너이다. | |
| <tModel> | 서비스에 대한 메타 데이터로서, 웹 서비스에 대한 메소드의 종류 및 인자의 데이터 타입이 정의된 WSDL 문서의 URL 경로를 기술한다. |
한 개의 비즈니스 정보를 이루기 위해서 위의 표에서 언급된 요소들 간의 관계는 다음과 같이 표현할 수 있다.
한 개의 비즈니스 정보를 UDDI 저장소에 생성하기 위해서는 <businessEntity> 요소가 작성되며, 웹 서비스의 내용을 담기 위해서 이것의 자식 요소로 <businessService>를 가진다. 한편 <businessService>는 웹 서비스에 대한 종점 URL에 대한 정보를 포함하고 있는 <bindingTemplate> 요소를 자식으로 가진다.
<bindingTemplate> 요소는 웹 서비스에 대한 메소드의 종류 및 인자의 데이터 타입이 정의된 WSDL 문서의 URL 경로가 기술된 <tModel> 요소를 참조한다.
<publisherAssertions> 요소는 두 개의 <businessEntity> 요소 간의 연관 관계를 지어주는 <publisherAssertion> 요소를 여러 개 가질 수 있다.
3. UDDI 요소
3.1 <businessEntity>
이 요소는 UDDI 데이터에서 가장 상위에 나타나며, 웹 서비스 제공자 이름, 주소, 전화번호와 같은 웹 서비스 제공자 자체에 대한 정보를 담고 있다. 또한 이것은 여러 개의 <businessService> 요소를 가질수 있는데, 이는 하나의 웹 서비스 제공자가 여러 개의 서비스를 제공할 수 있다는 것을 의미한다.
<businessEntity>는 제공자에 대한 정보 이외에도 <identifierBag>과 <categoryBag>이라는 요소를 가지는데, <identifierBag>은 businessEntity의 식별자 역할을 하고, <categoryBag>은 businessEntity가 어떠한 표준 산업 분류에 속하는 지 정의한다. 사용자는 이 요소를 통해 자신이 원하는 웹 서비스를 쉽게 찾을 수 있다.
<businessEntity> 요소에 대한 보다 자세한 구조는 UDDI를 정의한 XML 스키마 문서를 통해서 확인하기 바라며, 개략적인 구성을 그림으로 나타내면 다음과 같다.
<businessEntity> 요소의 속성은 다음과 같다.
| 속성명 | 설명 |
| businessKey | UDDI 저장소가 부여하는 <businessEntity> 요소 식별자 |
| operator | <businessEntity>가 공개된 UDDI 저장소 운영 사이트 이름 |
| authorizedName | <businessEntity> 요소가 UDDI 저장소에서 승인된 이름 |
그럼 실제 businessEntity 예제를 살펴보자.
| <businessEntity businessKey="8GJ5GK39-K87S-8FFK-OH98-FKI3MOD8D7D" operator="www.ibm.com/services/uddi" authorizedName="2000004XSS"> <discoveryURLs> <discoveryURL useType="businessEntity"> http://www.ibm.com/services/uddi/uddiget?businessKey=FIK333J4-88FU-2JKJ-UO13-CX3AL343DKJ </discoveryURL> </discoveryURLs> <name>KNOU Webservices</name> <description>This is a good topic</description> <contacts> <contact> <personName>Hong Gil-Dong</personName> <phone>012-345-6789</phone> <email>hong@abc.com</email> <address> <addressLine>Jongno-gu Seoul Korea</addressLine> </address> </contact> </contacts> <identifierBag> <keyedReference tModelKey="KDIR3KJ3-3K0S-FIK3-QQ4K-P4L4M488GGJ" keyName="D-U-N-S" keyValue="12345678"/> </identifierBag> <categoryBag> <keyedReference tModelKey="IDK4K4JF-KKJI-PO33-IJUR-9KFIEJFNFKS" keyName="NAICS" keyValue="3493833"/> </categoryBag> </businessEntity> |
<businessEntity>는 KNOU Webservices에 대한 정보를 담고, businessKey, tModelKey와 같은 여러 종류의 키 정보를 포함하고 있다. UDDI 저장소는 새로운 데이터가 등록되면 항상 이러한 키를 새로 생성해서 데이터를 구분하는 수단을 제공한다.
이 정보 이외에도 <discoveryURL>, <identifierBag>, <categoryBag> 요소를 포함하고 있다.
3.1.1 <discoveryURL>
이 요소는 businessEntity가 UDDI 저장소에 등록될 때 자동으로 생성된다. 여기에 포함되는 URL을 통해 businessEntity에 관련된 문서를 얻을 수 있다. UDDI는 URL 요청 결과로 넘어오는 문서에 대해 따로 정의하지 않는데, 이는 다른 URL을 통해 이 businessEntity에 대한 다른 문서들을 받을 수 있음을 의미한다.
3.1.2 <identifierBag>
이 요소는 <businessEntity>와 <tModel> 요소에 대한 대체 식별자로 사용되는 정보를 기술한다. 대체 식별자는 웹 서비스를 제공하는 회사를 식별할 수 있는 내용으로 미국 기업의 던스 넘버(D-U-N-S) 또는 우리나라의 사업자 등록번호에 해당한다.
웹 서비스 소비자는 웹 서비스를 제공하는 회사를 검색할 때 바로 이 대체 식별자를 가지고 검색할 수 있다.
<identifierBag> 요소는 <businessEntity>와 <tModel> 요소의 자식 요소로 작성된다.
<identifierBag> 요소의 구성을 도식화화면 다음과 같다.
3.1.3 <categoryBag>
UDDI 저장소에서 원하는 정보를 빠르게 찾기 위해서는 비즈니스 정보들의 분류가 잘 되어 있어야 한다. 분류화가 잘 되어 있을수록 UDDI 클라이언트가 요구하는 결과를 빠르고 정확하게 찾을 수 있게 된다.
이 요소는 UDDI의 각 요소를 임의의 종류별로 구별하기 위해 미리 정의된 분류 체계를 가지고 있다.
그래서 비즈니스 정보에 해당하는 <businessEntity>, <businessService>, <tModel> 요소를 작성할 때 <categoryBag> 요소를 사용하여 비즈니스 정보가 특정 분류에 속하도록 지정할 수 있다. 이를 위해 <identifierBag>과 같이 keyName, keyValue, tModelKey 속성이 사용되며, 수행하는 역할 또한 동일하다. UDDI는 UDDI 각 요소를 분류하기 위해, 이미 다음과 같이 표준 산업 분류를 통해 미리 정의된 네임스페이스를 이용하고 있다.
* NAICS (North America Industrial Classification System)
미국, 캐나다, 멕시코 지역에 한정된 산업의 종류에 따른 회사 분류 체계이다.
* UNSPSC (Universal Standard Products and Services Classification)
제품 또는 서비스를 종류별로 분류하여 코드화시킨 분류 체계이다.
* ISO 3166-1999 (GCS: Geographic Classification System)
전세계를 지역적으로 분류시킨 체계이다. 예를 들어 한국은 KR, 미국은 US이다. Microsoft UDDI 저장소는 독자적인 GeoWeb 분류 체계를 사용하는 데, 여기에는 도시 수준까지 분류되어 있다.
<categoryBag> 요소의 구성을 도식적으로 표현하면 다음과 같다.
3.2 <businessService>
이 요소는 businessEntity에서 제공하는 웹 서비스에 대한 정보를 기술하기 위해 사용된다.
<businessService> 요소의 구성은 웹 서비스의 이름, 종점 URL에 대한 바인딩 정보, 그리고 분류 정보로 이루어져 있다. 회사가 여러 개의 웹 서비스를 제공할 경우 <businessService> 요소는 여러 개가 기술되며, 각각은 여러 개의 bindingTemplate을 포함할 수 있다. 그 외에 고유의 서비스 키와 서비스가 속한 분류를 나타내기 위해 <categoryBag> 등이 포함된다.
<businessService> 요소의 구성을 도식적으로 표현하면 다음과 같다.
다음 예제는 BookStore Service라는 이름의 businessService를 나타낸다.
| <businessService serviceKey="FKDIL4QE-9FM3-FIL3-998S-WL38NCMSLDJ" businessKey="8GJ5GK39-K87S-8FFK-OH98-FKI3MOD8D7D"> <name>BookStore Service</name> <description>BookStore Service Description</description> <bindingTemplate> ~~ </bindingTemplate> <categoryBag> <keyedReference tModelKey="FKEN23IL-ELOS-4SL3-IEFR-ERF1457JF32" keyName="Social security code" keyValue="87930230"/> </categoryBag> </businessService> |
3.3 <bindingTemplate>
bindingTemplate은 businessService의 실제 구현을 담고 있다. 하나의 businessService는 여러 개의 bindingTemplate을 포함할 수 있는데, 이는 하나의 businessService가 각기 다른 프로토콜과 네트워크 주소를 사용하는 다수의 bindingTemplate으로 구현될 수 있음을 의미한다.
다음은 <bindingTemplate> 요소의 구성을 표현하는 그림이다.
위와 같은 구성에 따라 작성된 bindingTemplate에 대한 예제이다.
| <bindingTemplate bindingKey="KDJFI3839-3LDS-DLD2-E3L3-309LDHSI2LS" serviceKey="FKDIL4QE-9FM3-FIL3-998S-WL38NCMSLDJ"> <accessPoint URLType="http"> http://www.knou.ac.kr </accessPoint> <tModelInstanceDetails> <tModelInstanceInfo tModelKey="FKDIL4QE-9FM3-FIL3-998S-WL38NCMSLDJ"> <instanceDetails> <overviewDoc> <overviewURL> http://www.knou.ac.kr/wsdl/book-store.wsdl </overviewURL> </overviewDoc> </instanceDetails> </tModelInstanceInfo> </tModelInstanceDetails> </bindingTemplate> |
bindingTemplate은 크게 <accessPoint>와 <tModelInstanceDetails>라는 두 요소로 나뉜다.
<accessPoint>는 서비스에 대한 어떠한 형태의 정보도 올 수 있는데, businessService가 웹 서비스가 아닌 일반 서점에 대한 것이라면 <accessPoint>에는 전화번호 혹은 주소와 같은 서점에 접근할 수 있는 정보가 포함된다. <accessPoint> 다음에는 <tModelInstanceDetails> 요소가 올 수 있는데 <tModelInstanceDetails>는 tModel에 대한 참조를 갖고 있다. 또한 tModel의 부가적인 정보를 위해 <overviewDoc>과 <overviewURL>을 사용할 수 있다.
3.4 <tModel>
UDDI의 핵심 요소는 바로 <tModel> 요소이다. UDDI에서 <tModel>은 두 가지 목적으로 사용된다. 하나는 businessEntity에서 본 것과 같이 식별자를 위한 고유의 네임스페이스를 제공하기 위해서이고, 나머지 하나는 웹 서비스 인터페이스와 같은 기술적인 사항을 언급하기 위해서이다. <tModel>가 언급하는 UDDI 저장소의 기술적인 명세에는 웹 서비스 시스템의 원격 프로시저 이름과 인자에 대한 정보들이 포함된다.
만약 새로운 웹 서비스 시스템을 제작하여 기능을 WSDL 문서로 기술하였다면, 이 WSDL 문서의 URL 경로는 <tModel> 요소에 저장되어야 한다.
<tModel> 요소는 여러 개의 <businessEntity> 요소에서 참조될 수 있다. 이것은 한 개의 웹 서비스 시스템을 여러 회사에서 공유해서 사용할 수 있음을 나타낸다.
<bindingTemplate>는 웹 서비스 시스템의 종점 URL 경로에 대한 정보와 <tModel> 요소를 참조하는 내용으로 구성된다. 기술적인 명세를 <businessEntity> 요소의 자식 요소로 작성하지 않고 <tModel> 요소로 별도로 작성하는 이유는 여러 <businessEntity> 요소에서 연관되는 기술적인 내용을 공유하기 위함이다.
다음은 <tModel> 요소의 구성을 나타낸다.
| <tModel> <name>tModel이름</name> <overviewDoc> <overviewURL> WSDL문서에대한URL경로 <overviewURL> <identifierBag>tModel에대한대체식별자정보</identifierBag> <categoryBag>분류정보</categoryBag> </overviewDoc> </tModel> |
다음은 임의의 웹 서비스에 인터페이스를 정의하고 있는 WSDL이 UDDI에서 tModel을 통해 참조되고 있음을 보여주고 있다.
| <tModel tModelKey="KDIR3KJ3-3K0S-FIK3-QQ4K-P4L4M488GGJ" operator="Administrator" authorizedName="Hong Gil-Dong"> <name>Book Store tModel</name> <overviewDoc> <overviewURL> http://www.knou.ac.kr/wsdl/book-store.wsdl </overviewURL> </overviewDoc> </tModel> |
☞위의 진하게 밑줄 표시된 단어 중의 하나라도 클릭/오버되면 아래 내용을 표시
| <tModel>의 속성 * tModelKey
필수 속성으로 tModel에 배정된 유일한 키를 나타낸다. * Operator UDDI 저장소 사이트 운영자의 이름 * authorizedName tModel을 등록한 사람의 이름 |
3.5 <publisherAssertion>
이 요소는 UDDI 2.0에서 비즈니스 관계를 모델링하기 위해서 새롭게 추가된 요소이다. 이 요소를 통해 서로 다른 두 businessEntity가 서로 묶일 수 있다. 그럼 어떤 경우에 이와 같은 기능이 필요할까? IBM이나 MS와 같은 큰 회사는 여러 기능의 조직으로 나뉘는데, 이를 하나의 businessEntity로 표현하기에는 무리가 따른다. 결국 다른 기능의 조직에 대한 각각의 businessEntity가 필요하게 되는데, 이 개별의 businessEntity는 결국 한 회사의 여러 조직들을 표현하기 때문에, 이들의 관계를 설정하는 적절한 방법이 필요한 것이다. 이 역할을 UDDI에서는 publisherAssertion을 통해 가능하다.
다음은 <publisherAssertion> 요소의 구성을 보여주고 있다.
☞위의 진하게 표시된 부분에 클릭/오버되면 아래 내용을 표시
| <keyedReference> 요소의 keyValue 속성의 속성값으로는 “모회사 자회사(parent-child) 관계”, “파트너(peer-peer) 관계”, 그리고 “동일(identity) 관계”를 나타내는 값들을 사용한다. |
정리하기
⑴ UDDI는 이용 가능한 웹 서비스의 정보를 담고 있는 저장소에 검색/등록하는 여러 가지 방법을 정의하는 XML 형식으로, 웹 서비스 제공자와 웹 서비스 소비자 사이에서 원활한 웹 서비스의 이용이 가능하도록 중개하는 역할을 담당한다.
⑵ UDDI는 데이터 구조, UDDI 저장소 사용을 위한 API, 복제 그리고 UDDI 관리자를 위한 스펙으로 구성된다.
⑶ UDDI 저장소에 웹 서비스를 등록할 때 화이트 페이지, 옐로우 페이지, 그린 페이지를 구성하기 위한 모든 정보가 필요하면, 사용자는 이렇게 등록된 웹 서비스를 웹 서비스 제공자 이름, 주소, 표준 산업 분류, 웹 서비스 타입 등을 통해 쉽게 검색할 수 있다.
⑷ 한 개의 비즈니스 정보를 생성하기 위해서는 <businessEntity>, <publisherAssertion>, <identifierBag>, <categoryBag>, <businessService>, <bindingTemplate>, <tModel> 등의 요소가 필요하다.
⑸ 가장 상위 요소로서 <businessEntity> 요소가 작성되며, 웹 서비스의 내용을 담기 위해서 이것의 자식 요소로 <businessService>를 가진다. 한편 <businessService>는 웹 서비스에 대한 종점 URL에 대한 정보를 포함하고 있는 <bindingTemplate> 요소를 자식으로 가진다.
⑹ <bindingTemplate> 요소는 웹 서비스에 대한 메소드의 종류 및 인자의 데이터 타입이 정의된 WSDL 문서의 URL 경로가 기술된 <tModel> 요소를 참조한다.
⑺ <publisherAssertions> 요소는 두 개의 <businessEntity> 요소 간의 연관 관계를 지어주는 <publisherAssertion> 요소를 여러 개 가질 수 있다.
'정보과학 > 웹서비스특론' 카테고리의 다른 글
| 웹 서비스 보안 (0) | 2023.09.14 |
|---|---|
| 웹 서비스 명세화, WSDL (0) | 2023.09.12 |
| 웹 서비스 클라이언트 개발 (1) | 2023.09.11 |
| 웹 서비스 시스템 개발 (1) | 2023.09.09 |
| SOAP API (0) | 2023.09.08 |
