0
나는 깨끗한 SOA 방식으로 해결할 수없는 실생활 SOA 문제가 있습니다.SOA/SEDA - 순환 아키텍처
"물건 관리자"가 소비하는 "업데이트 대상"메시지의 많은 분산 된 제작자가 있습니다.
"물건 관리자"의 기능 중 하나는 "물건"이 변경되었다는 내용의 알림을 게시하는 것입니다. 이렇게하면 다른 관심있는 서비스가 변경에 반응 할 수 있습니다.
"업데이트 대상"제작자 중 하나는 그 자체로 해당 주제에 대한 청취자입니다. 다른 시스템의 "물건 업데이트"에만 관심이 있습니다. 하지만 그 자체가 처음부터 (그리고 이미 알고있는) "원인 매니저"로부터 업데이트를 소비하고 처리한다는 것을 알게됩니다. 다행히 그 시점에서 피드백 루프가 깨졌습니다.
깨끗한 SOA 방식으로이 문제를 해결하는 가장 좋은 방법은 무엇입니까? 메시지 소스에 깨끗한 해결책임을 나타내는 메타 데이터를 추가하는 것을 클래스로하지 않습니다. 메시지 소비자는 메시지의 출처 또는 출처를 알 필요가 없습니다.
감사합니다. Kevin - 데이터의 특성은 원본과 동일합니다. 그러므로 선택적인 소비를 가능하게하는 데이터 구조 자체에 대해서는 아무 것도 없습니다. 제 생각에 당신은 원래 업데이트의 창시자가 메시지 헤더를 마크 업할 것이라고 생각합니다. 이는 SOA 관점에서 저에게 잘못된 것입니다. 이유 중 하나는 이벤트 원점과 기능 관리자 사이에 많은 프로세스가 있으며 각 프로세스가 메타 데이터를 전달하고 자신의 ID로 대체하지 않아야한다는 것입니다. – Mike
메시지 헤더에 들어가야합니다. "물건 관리자"는 메시지를 보낼 사람을 알기위한 구독 목록이 있어야합니다. 이 목록에서 호출 할 다른 서비스를 식별합니다. 이것을 데이터 구조에 포함 시키십시오. 통제를 벗어난 서비스로 작업하면서 변경이 불가능한 계약을 잘 정의한 경우 처음부터 설계하는 시스템과는 다른 문제가 발생합니다. 그리고 아마 당신이 게시/구독 디자인 패턴을 사용하고 있다는 거대한 가정을하고 있습니다. –
아,하지만 그것은 point-to-point 아키텍처 일 것이고 불행하게도 우리는 pub/sub (주제 기반, 큐 기반이 아님) 아키텍처를 가지고 있습니다. 물건 관리자는 물건에 대해 말할 필요가있는 사람이 누구인지 알 필요가 없으며 단지 일을 처리하고 기분이 좋다면 물건을 구독하고 반응합니다. 어쩌면 이것이 주제 기반의 pub/sub가 대규모 SOA 시스템의 관점에서 좋은지 나쁜지 여부에 대한 질문이 될 것입니다. P2P는 취약하지만 워크 플로를 쉽게 추적하고 모니터링 할 수 있습니다. Pub/Sub는 시스템을 덜 진화 시키지만 더 쉽게 진화시킵니다. 하지만 분명히 피드백 루프를 도입하는 것도 쉽습니다 ... – Mike