UDDI 버전 3 레지스트리에 대한 조회 API

조회 API는 레지스트리에서 일반적으로 사용되어 소프트웨어의 요구에 일치하는 폭넓게 사용된 전통을 따르는 4가지 양식의 조회를 제공합니다.

네 양식의 조회는 다음과 같습니다.
  • 찾아보기 패턴
  • 드릴다운 패턴
  • 호출 패턴
  • 조회 API 기능

UDDI 레지스트리에 대한 패턴 찾아보기

데이터, 특히 계층 구조 데이터를 탐색하고 조사하는 데 사용된 소프트웨어는 찾아보기 기능을 필요로 합니다. 찾아보기 패턴은 특징적으로 일부 광범위한 정보로 시작, 검색 수행, 일반 결과 세트 찾기, 드릴다운 패턴에 대한 보다 구체적인 정보 선택을 포함합니다.

UDDI API 스펙은 find_xx API 호출로 찾아보기 패턴을 수용합니다. 이 호출은 API가 제공하는 검색 기능을 구성합니다. 호출은 조회 메시지 유형과 연관되어 등록된 정보 및 조회에서 지정된 검색 기준에 대한 개요 정보를 리턴하는 요약 리턴 메시지와 일치합니다.

일반 찾아보기 시퀀스는 아는 비즈니스에 대해 등록된 정보가 있는지 여부를 찾는 것을 포함할 수 있습니다. 이 시퀀스는 find_business에 대한 호출로 시작하며, 아는 비즈니스 이름의 첫 문자를 전달할 수 있습니다. 이 조치는 businessList 결과를 리턴합니다. 이 결과는 키, 이름 및 설명을 포함한 개요 정보로, 등록된 businessEntity 정보에서 분리되며 제공한 이름 단편과 일치합니다. 찾고 있는 비즈니스가 이 목록에 있는 경우, find_service API 호출을 사용하여 해당 businessService 정보로 드릴다운하고 구매나 출하와 같은 특정 기술 모델을 검색할 수 있습니다. 마찬가지로, 특정 소프트웨어 인터페이스의 tModel 서명인 기술 지문을 알고, 검색 중인 비즈니스가 해당 인터페이스를 지원하는 웹 서비스를 제공하는지 알려면, find_binding 조회 메시지를 사용할 수 있습니다.

UDDI 레지스트리에 대한 드릴다운 패턴

UDDI 레지스트리가 관리하는 4개의 기본 데이터 유형 중 하나에 대한 키가 있는 경우, 해당 키를 사용하여 특정 데이터 인스턴스의 전체 등록 세부사항에 액세스할 수 있습니다. UDDI 데이터 유형은 businessEntity, businessService, bindingTemplate 및 tModel입니다. 관련 키 유형을 get_xx API 호출 중 하나로 전달하여 이 구조에 대해 등록된 전체 정보에 액세스할 수 있습니다.

이전 섹션의 예에 이어서 모든 find_x 리턴 세트에서 리턴된 하나의 데이터 항목은 키 정보입니다. 관심 있는 비즈니스의 경우, businessList 구조의 컨텐츠에서 리턴된 businessKey 값은 get_businessDetail 메시지에 대한 인수로 전달될 수 있습니다. 이 메시지에 대한 성공적인 리턴은 전달된 키 값으로 엔티티에 대해 전체 등록된 정보를 포함한 businessDetail 메시지입니다. 이 정보는 전체 businessEntity 구조입니다.

UDDI 레지스트리에 대한 호출 패턴

다른 비즈니스나 엔티티에서 UDDI 레지스트리에 등록된 원격 웹 서비스를 활용하는 애플리케이션의 경우, 호출된 특정 서비스에 대한 레지스트리에 있는 정보를 사용하도록 해당 애플리케이션을 준비해야 합니다.

UDDI 레지스트리에서 얻은 bindingTemplate 데이터는 프로그램이 서비스와 상호작용을 시작하는 위치를 포함하여 지정된 인터페이스 유형의 인스턴스에 대한 특정 세부사항을 표시합니다. 호출 애플리케이션이 서비스 인스턴스와 통신해야 할 때마다 호출 애플리케이션이나 프로그램은 이 정보를 캐시하고 이를 사용하여 등록된 주소의 서비스에 접속합니다.

이전에 많이 사용된 원격 프로시저 기술로, 도구는 캐싱과 연관된 태스크 또는 하드 코딩, 위치 정보를 자동화합니다. 그러나 원격 서비스가 이동하고 호출자가 이 이동에 대해 모르는 경우 문제가 있습니다. 원격 서비스가 이동할 수 있는 여러 이유가 있을 수 있으며, 예를 들어 서버 업그레이드, 재해 복구, 서비스 획득 또는 비즈니스 이름 변경입니다.

이전에 UDDI 레지스트리에서 얻은 캐시된 정보를 사용하여 호출이 실패하면, 올바른 동작은 최신 bindingTemplate 정보에 대한 UDDI 레지스트리를 조회하는 것입니다. 리턴된 데이터가 캐시된 정보와 다른 경우, 서비스 호출은 최신 정보를 사용하여 호출을 다시 자동으로 시도할 수 있습니다. 이 재시도의 결과가 성공하면 새 정보는 캐시된 정보를 대체합니다.

웹 서비스와 이 패턴을 사용하여, UDDI 레지스트리를 사용하는 비즈니스는 불필요한 통신과 조정 비용 없이 다수 파트너의 복구를 자동화할 수 있습니다. 예를 들어, 비즈니스가 재해 복구 사이트를 활성화하면, 실패된 사이트에서 서비스를 호출하려는 경우 파트너로부터의 대부분 호출이 실패합니다. 서비스의 새 주소로 UDDI 정보를 업데이트하여, 호출 패턴을 사용하는 파트너는 자동으로 새 서비스 정보를 찾고 추가 관리 조치 없이 복구합니다.


주제 유형을 표시하는 아이콘 개념 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwsu_inquiry_api
파일 이름:cwsu_inquiry_api.html