2011-12-14 2 views
0

대기중인 메시징 시스템에 대한 세션 컨텍스트 데이터를 구현하려고합니다.비동기식 (대기열) 메시징 및 관련 세션 데이터

세션 처리 방식은 다음과 같습니다. 프론트 엔드 응용 프로그램은 자체를 인증하고 세션 ID를 수신합니다. 그런 다음 세션 ID가 메시지 헤더에 포함되므로 메시지 핸들러에 예를 들어 다음과 같은 컨텍스트가 제공됩니다. 보안 검사 및 감사 로깅. 클라이언트가 충돌 한 경우 세션을 픽업하여 작업을 계속할 수 있습니다.

이제 키/값 쌍을 세션 ID와 연결하려고합니다. 그러나 메시지 처리기에서 사용하는 세션 데이터가 메시지를 전송할 당시의 세션 데이터 여야하므로 세션 데이터가 변경되면 많은 동시성 문제가 발생합니다.

  1. 모든 메시지 헤더
  2. 스토어에서 데이터베이스 버전 세션 데이터를 관련 세션 데이터를 넣고 메시지 헤더에 버전 ID를 사용

    나는 두 가지 솔루션을 참조하십시오.

첫 번째 메시지는 더 커지고 두 번째 메시지는 세션 DB를 더 크게 만들고 많은 인프라 코드를 만듭니다. 양쪽 모두에서 DB에 최신 값을 저장해야하므로 클라이언트가 연결이 끊어 지거나 연결이 끊어진 경우 작업을 계속할 수 있습니다.

다른 해결책이 있습니까? 나는 첫 번째 솔루션을 사용하는 경향이 있지만 먼저 몇 가지 피드백을 원합니다.

다른 사람들이 어떻게 처리합니까 (예 : JMS/NServiceBus/Masstransit)?

대답을 기반으로 한 업데이트 : 팀원에게 프론트 엔드에서만 세션 데이터를 사용하도록 설득하고 메시지 처리기에 필요한 경우이를 메시지에 넣도록 선택했습니다.

답변

1

세션 개념과 키/값 쌍을 연결하려는 이유에 대해 자세히 설명하지 않았습니다.

SOA 및 서비스 경계에 대한 NServiceBus 및 Udi Dahan의 조언에서 비롯된이 세션 유형의 세션 개념은 잘못된 방식으로 문질러납니다. 내 생각에 메시지 처리기는 대부분 시간에 대해 상당히 결정 론적이어야합니다. 즉, 지금 당장은 잘 돌아가거나 잠시 대기열에 앉아서 미래의 어떤 시점에서 똑같은 방식으로 실행해야합니다.

내 조언은 보안상의 이유로 필요할 경우 메시지 헤더를 사용하는 것입니다. NServiceBus에서는 핸들러 체인에서 처음 실행되도록 구성된 IT/Ops Service의 메시지 핸들러를 도입하여 실제 비즈니스 로직과 독립적 인 보안 및 내용을 검증 할 수 있습니다. 이 경우 헤더 정보는 메시지가 처리되거나 거부되는지 여부에만 영향을줍니다.

세션 유형 정보를 얻었 으면 이러한 요구 사항을 신중하게 분석하고 관련 조각을 메시지 스키마 자체에 넣고 싶습니다.

처음에도 세션 데이터의 동기를 파악하는 것이 도움이됩니다. 질문을 편집하면 아마도 이러한 요구 사항을 재구성 할 수있는 방법을 찾을 수 있습니다.

+0

메시지 스키마가 있습니다. 세션 데이터는 프론트 엔드에 있어야하며 복구를 위해서만 저장되어야합니다. 머리말이나 외국 세션 데이터베이스에 관련 비즈니스 데이터를 넣는 것은 잘못되었습니다. – sanosdole