저는 SOA에 대해서 읽고 있습니다. 그리고 서비스 레지스트리/UDDI는 정기적으로 언급됩니다. 그것은 좋은 소리지만 어떻게 현실에서 사용됩니까?SOA 서비스 검색 (UDDI)은 실제로 어떻게 작동합니까?
- 레지스트리는 논리적 서비스를 '실제 구현 (포트, URL 등)에서 분리합니까?
- 재미있는 서비스를 찾고있는 사람이 레지스트리를 탐색해야합니까?
- 응용 프로그램 을 하드 와이어로 연결하는 것이 바람직하지 않습니까?
저는 SOA에 대해서 읽고 있습니다. 그리고 서비스 레지스트리/UDDI는 정기적으로 언급됩니다. 그것은 좋은 소리지만 어떻게 현실에서 사용됩니까?SOA 서비스 검색 (UDDI)은 실제로 어떻게 작동합니까?
실용적인 것보다 이론적으로 유용하다는 것을 알았습니다. 드물게 구현되고 자주 사용되지 않습니다. 실제로 DNS는 네트워크상의 리소스 위치에 대한 충분한 추상화 도구를 제공합니다.
서비스 레지스트리는 사용 가능한 모든 서비스, 주로 인터페이스 설명 및 현재 URI (IP, 포트 등)에 대한 정보를 저장하고 게시합니다. 이 방법으로 응용 프로그램은 레지스트리에 필요한 서비스를 요청하고 피팅 서비스 구현의 세부 정보를 얻고 연결할 수 있습니다.
UDDI가 서비스를위한 레지스트리를 얻는 유일한 방법은 아닙니다. 그러나 UDDI는 웹 서비스만을위한 것이므로 SOA가 웹 서비스로만 구성된 경우에만 유용합니다.
1) 수정하십시오.
2) 아니오, 실제로 인간의 눈을위한 것이 아닙니다. 물론, 디렉토리를 탐색 할 수있는 도구가 있지만, 레지스트리에 필요한 서비스가 있는지 여부를 찾는 것이 주로 목적입니다. 실제 사용은 응용 프로그램/서비스와 레지스트리간에 직접 발생합니다.
3) 원하는 목표에 따라 다릅니다. SOA를 구축하고 싶다면 SOA의 느슨한 결합 패러다임과 모순되기 때문에 '틀린 것'이라고 생각합니다. 이것이 유일한 서비스 인 경우이를 사용하는 유일한 응용 프로그램이며 서비스가 URI를 변경하지 않을 가능성이 높습니다. 하드 배선에 문제가 없습니다. 그러나이 서비스를 분리 할 필요는 없습니다.
멀티 캐스트를 사용하여 서비스를 비활성화하는 방법은 어떻습니까? jgroups 또는 SLP를 사용하는 것처럼? 모든 서비스는 서로를 발견하고 필요한 정보를 프록시에 주입합니다. 그런 다음 실제 전송 구현에 대한 추상화를 작성합니다. (예 : 휴식, 비누, rmi)
로컬 네트워크에서 미세하게 표시되지만 크기는 조정되지 않습니다. – stimms