실시간 SOA 애플리케이션을 위한 최고의 메시징 매체?

Question

저는 SOA 스타일(일부 메시징 프로토콜(JMS, MQ 또는 HTTP)을 통해 연결된 느슨하게 결합된 구성 요소 읽기)을 사용하여 구현된 실시간 애플리케이션을 작업하고 있습니다.

이 시스템을 설계한 설계자는 JMS를 사용하여 구성 요소를 연결하기로 결정했습니다.이 시스템은 실시간이므로 한 구성 요소에 오류가 발생하더라도 메시지를 대기열에 추가할 필요가 없습니다(트랜잭션이 시간 초과됨).또한 보장된 전달이나 롤백이 필요하지 않습니다.

이 경우 HTTP 웹 서비스(속도, 리소스 공간 등)보다 JMS를 사용하면 어떤 이점이 있습니까?

제가 생각하는 한 가지는 JMS 접근 방식에서는 스레드 풀 크기(JMS 주제/대기열을 수신하는 구성 요소 수)를 설정해야 하기 때문에 이 추가 구성이 그렇지 않기 때문에 HTTP 서비스가 더 적합하지 않을까 하는 것입니다. 필요합니다(각 HTTP 요청에 대해 새 스레드가 생성되어 서버의 리소스가 부족해질 때까지 응용 프로그램을 "무제한" 요청 수로 확장할 수 있습니다).

뭔가 빠졌나요?

Answer 1

나는 S.Lott의 포인트에 전혀 동의하지 않지만 HTTP 웹 서비스와 관련하여 고려해야 할 몇 가지 요점이 있습니다.

• 고객은 HTTP를 통해 의사 소통하는 방법 만 알아야합니다. JMS는 인기가 있지만 HTTP보다 전문가이므로 상호 연결된 시스템이 사용할 수있는 언어를 제한합니다. 아마도 현재 시스템에 문제가되지 않지만 나중에 JMS 연결을 지원하기 위해 어려움을 겪을 수있는 다른 시스템을 연결해야합니까?

• WSDL 및 SOAP와 같은 표준은 귀하의 서비스를 위해 부과 할 수있는 표준이 많은 Langauges에서 잘 지원되며 WSDL 파일에서 파이프 라인 (클라이언트 및 서버)의 양쪽 끝을 구현하기위한 코드를 생성하는 많은 도구가 있습니다. 당신이해야 할 개발자의 양. 이러한 표준은 또한 시스템간에 전달할 데이터의 사양을 정의하고 게시하는 것이 비교적 간단하게 만들어집니다. JMS와 같은 큐잉 기술을 사용하여 손으로해야 할 것입니다.

• S.Lott가 지적한 바와 같이, JMS는 (Stateless) HTTP 프로토콜을 사용하여 버릴 수있는 기능을 제공합니다 : 보장 된 주문 및 신뢰성; 모니터링; 확장 성; 등.

좋은 질문, btw.

Answer 2

나는 그것이 실제로 상황에 달려 있다고 생각합니다. 내가 일하는 곳에서는 원격, JMS, MQ, HTTP 및 SFTP를 지원합니다. 우리는 원격, JMS, MQ 및 HTTP를 말하는 미들웨어 어플라이언스와 JMS, MQ 및 HTTP를 말하는 소프트웨어 미들웨어 구성 요소를 구현하고 있습니다.

SGREEVE가 위에서 언급 한 것처럼 표준은 우리가 유연 해지는 데 도움이되지만 독점 형식은 더 많은 기능을 허용합니다.

간단히 말해서, 나는 무국적 통화에 HTTP를 사용한다고 말하고 있습니다 (거의 모든 요구 사항을 충족시킬 수 있음), 그리고 상태가 많은 전화에 필요한 독점 형식을 사용합니다. 대기업에서 일하는 경우, 하드웨어 어플라이언스는 일반적으로 중간 압축, 암호화, 변환 및 번역, 총 소유 비용이 매우 낮은 미들웨어와 매우 적합합니다.

Answer 3

귀하의 요구 사항에 대해 충분히 알지 못하지만 관리 효율성, 유연성 및 성능을 간과하고 있을 수 있습니다.

JMS를 사용하면 대기열을 모니터링하고 관리할 수 있습니다.이는 HTTP에 부족한 기능이므로 공급업체로부터 구입하기보다는 직접 구축해야 합니다.

또한 JMS에는 단일 게시자에 대한 여러 구독자를 허용하는 대기열과 항목이 있습니다.HTTP에서는 불가능합니다.

릴리스 1.0에서는 이러한 기능이 필요하지 않을 수도 있지만 나중에는 필요할 수도 있습니다.

또한 JMS는 명명된 소켓과 같은 다른 전송 메커니즘을 사용할 수 있습니다. 이는 (거의) 모든 요청에 ​​대해 소켓 협상이 진행되지 않는 경우 오버헤드를 줄여줍니다.

Answer 4

HTTP 경로를 내려 가서 둘 이상의 기계 또는 어떤 종류의 신뢰성을 지원하려면 사용 가능한 웹 서버를 발견하고 요청을로드 할 수있는로드 밸런서가 필요합니다. 특정 상자/프로세스가 죽는 경우. HTTP 요청을하는 클라이언트는 또한 일부 루프에서 실패하고 재활하는 서버를 처리해야합니다.

이것은 메시지 대기열의 주요 기능 중 하나입니다. 재 시도 로직을 포함하지 않고 생산자와 소비자 간의 장애 조치 및 느슨한 커플 링을 사용한 안정적인로드 밸런싱 - 클라이언트 또는 서버 코드는 이러한 종류에 대해 걱정할 필요가 없습니다. 이것은 메시지 지속성을 원하거나 산성 트랜잭션을 사용하여 메시지를 생산/소비하고 싶은지 여부와 완전히 분리되어 있습니다 (매우 편리한 BTW 일 수 있음).

Java를 사용하여 서버 측에 초점을 맞추면 서블릿 또는 Messagelistener/MDBS에 관계없이 실제로 비슷합니다. 차이점은로드 밸런서입니다.

DNS/NAT/IP/HTTP로드 밸런서 인프라를 설정하는 것보다 JMS 브로커가 설정 및 작업하기가 더 쉬운 일입니까?

Answer 5

나는 그것이 실시간으로 의미하는 바에 달려 있다고 생각합니다 ... 내 의견으로는 JMS 나 HTTP가 "실시간"응용 프로그램을 잘 지원하지 않습니다. 즉, 예측 가능한/결정 론적 성능을 제공하거나 경합이있을 때 흐름을 적절히 우선 순위를 정할 수는 없습니다.

그 중 일부는 이러한 기술이 TCP 위에 구축되어 모든 트래픽을 단일 FIFO로 연속화하는 것이 다른 트래픽 흐름을 쉽게 우선시 할 수 없음을 의미합니다. 또한 TCP 타이머는 쉽게 제어 할 수없는 차단 및 시간 초과가 쉽게 제어되지 않습니다. 이러한 이유로 많은 스트리밍 애플리케이션은 TCP 대신 기본 프로토콜로 UDP를 사용합니다.

JMS의 또 다른 문제는 일반적인 구현이 메시지 발송을 중앙 집중화하는 브로커를 사용한다는 것입니다. 이것은 결정적인 성능을 얻는 최고의 아키텍처가 아닙니다.

JMS와 함께 얻는 신뢰성 보장 및 게시 수용 의미를 제공 할 수있는 미들웨어를 찾고 있다면 실시간 응용 프로그램 도메인에 맞게 개발 된 OMG 데이터 분포 서비스를 살펴 보는 것이 좋습니다. (DDS). DDS.omg.org를 참조하십시오.이 기사를 참조하십시오.이 기사는 왜 DDS가 실시간 SOA를 구현하기에 가장 적합한 미들웨어인지 논쟁했습니다. http://soa.sys-con.com/node/467488