답변:
웹 서비스를 사용하면 클라이언트와 서버가 있습니다.
RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo와 같은 메시지 큐를 사용하면 다른 내결함성 결과를 기대할 수 있습니다.
Message Queues에는 훨씬 더 많은 기능이 있지만 이는 오류 조건을 직접 처리 할 것인지 아니면 Message Queue에 남겨 둘 것인지 결정하는 몇 가지 규칙입니다.
REST HTTP 호출이 메시지 큐 개념을 대체 할 수있는 방법을 고려한 최근의 많은 연구가있었습니다.
프로세스 및 작업 개념을 리소스로 도입하면 중간 메시징 계층에 대한 필요성이 사라지기 시작합니다.
전의:
POST /task/name
- Returns a 202 accepted status immediately
- Returns a resource url for the created task: /task/name/X
- Returns a resource url for the started process: /process/Y
GET /process/Y
- Returns status of ongoing process
작업에는 여러 단계의 초기화가있을 수 있으며 프로세스는 폴링시 상태를 반환하거나 완료되면 콜백 URL로 POST 할 수 있습니다.
이것은 매우 간단하며, 중간 계층없이 실행중인 모든 프로세스 및 작업의 rss / atom 피드에 가입 할 수 있다는 것을 알게되면 매우 강력 해집니다. 모든 큐잉 시스템에는 어쨌든 일종의 웹 프론트 엔드가 필요하며이 개념은 다른 사용자 정의 코드 계층없이 내장되어 있습니다.
리소스는 삭제할 때까지 존재하므로 프로세스 및 작업이 완료된 후 오랫동안 기록 정보를 볼 수 있습니다.
복잡한 프로토콜없이 여러 단계를 수행하는 작업에 대해서도 서비스 검색 기능이 내장되어 있습니다.
GET /task/name
- returns form with required fields
POST (URL provided form's "action" attribute)
서비스 검색은 HTML 형식으로, 사람이 읽을 수있는 범용 형식입니다.
전체적으로 사용되는 도구를 사용하여 프로그래밍 방식으로 또는 사람이 전체 흐름을 사용할 수 있습니다. 클라이언트 중심이므로 RESTful입니다. 웹용으로 작성된 모든 도구는 비즈니스 프로세스를 이끌 수 있습니다. 별도의 로그 서버 배열에 비동기식으로 POST하여 대체 메시지 채널이 계속 있습니다.
잠시 동안 생각해 본 후, 휴식을 취하고 REST가 메시징 큐와 ESB의 필요성을 완전히 제거 할 수 있음을 깨닫기 시작합니다.
메시지 대기열은 처리하는 데 시간이 오래 걸릴 수있는 요청에 이상적입니다. 요청은 대기열에 있으며 클라이언트를 차단하지 않고 오프라인으로 처리 할 수 있습니다. 클라이언트에게 완료 알림을 받아야하는 경우 클라이언트가 요청 상태를 주기적으로 확인하는 방법을 제공 할 수 있습니다.
메시지 대기열을 사용하면 시간이 지남에 따라 더 잘 확장 할 수 있습니다. 실제 처리가 시간에 따라 분산 될 수 있기 때문에 많은 활동의 버스트를 처리하는 능력이 향상됩니다.
메시지 대기열과 웹 서비스는 직교 개념입니다. 즉 상호 배타적이지 않습니다. 예를 들어, 메시지 큐에 대한 인터페이스 역할을하는 XML 기반 웹 서비스를 가질 수 있습니다. 나는 당신이 찾고있는 차이점은 Message Queues 대 Request / Response라고 생각합니다. 후자는 요청이 동 기적으로 처리 될 때입니다.
메시지 대기열은 비동기식이며 배달이 실패하면 여러 번 재 시도 할 수 있습니다. 요청자가 응답을 기다릴 필요가없는 경우 메시지 큐를 사용하십시오.
"웹 서비스"라는 문구는 HTTP를 통한 분산 구성 요소에 대한 동기 호출을 생각합니다. 요청자에게 응답이 필요한 경우 웹 서비스를 사용하십시오.