내보내기(0) 인쇄
모두 확장

2012년 10월 릴리스의 새로운 기능

업데이트 날짜: 2015년 3월

2012년 10월 Microsoft Azure 서비스 버스 릴리스에는 새로운 기능이 다양하게 포함되어 있습니다. 이 항목에서는 새 기능에 대해 간략하게 살펴보고 자세한 내용을 참조할 수 있는 링크를 제공합니다.

서비스 버스에서는 메시지 잠금 설정에 제한된 범위의 값만 지원됩니다. 시나리오에 따라서는 임대 연장이나 더 높은 기본값을 사용하여 메시지 잠금 기간을 더 길게 해야 할 경우도 있습니다. 이제는 메시지 잠금을 갱신할 수 있습니다. 다음과 같은 기능이 지원됩니다.

  • 메시지 잠금을 갱신할 수 있습니다.

  • 메시지 잠금은 세션에 바인딩됩니다.

  • 잠금은 기본적으로 60초 동안 이루어지며 최대 기간은 5분입니다. 이 동작은 이전과 동일합니다.

RenewLock 호출은 메시지 잠금을 업데이트하며 RenewLock이(가) 완료된 후 LockedUntilUtc 속성을 업데이트합니다.

메시지 세션의 경우, AcceptMessageSession과(와) 같은 클라이언트 메서드 중 하나 또는AcceptMessageSession과(와) 같은 팩터리 메서드 중 하나를 사용하여 세션을 받아들일 때 LockedUntilUtc 속성이 채워집니다.

이제 서비스 버스에서는 큐 및 구독에 대한 메시지 세션을 찾아볼 수 있는 기능이 지원됩니다. 지정된 시간에 상태가 업데이트된 세션을 검색해 볼 수도 있습니다.

자세한 내용은 TechNet의:

ODATA 필터를 지정하여 일련의 항목, 큐 또는 구독을 검색할 수 있습니다. 예를 들어 다음과 같습니다.

IEnumerable<QueueDescription> qList = namespaceClient.GetQueues("startswith(path, 'I') eq true" );
foreach (QueueDescription qd in qList)
{
    Console.WriteLine("qd : {0}", qd.Path);
}

REST API를 사용할 경우 구문은 다음과 같습니다.

?$Filter=encoded_odata_filter_string_here

다음과 같은 시나리오가 지원됩니다.

  • 경로(예: /test1/test2) 아래의 모든 항목을 나열합니다.

  • 최근 5분 동안에 업데이트된 모든 항목을 나열합니다.

  • 최근 5분 동안에 액세스된 모든 항목을 나열합니다.

  • 최근 5분 동안에 만들어진 모든 규칙을 나열합니다.

  • /test1/test2 경로에 있으며 메시지가 하나 이상 있는 모든 구독을 나열합니다.

  • /test1/test2 경로에 있으며 메시지가 하나 이상 있는 모든 항목을 나열합니다.

이 기능을 사용하면 두 엔터티에 걸친 트랜잭션이 가능합니다(단일 트랜잭션에서 수신, 처리, 발신 및 완료). 예를 들어 다음과 같습니다.

var msftSubscription = "MSFT";
var stocksTopic = "stocks";
var messageReceiver = factory.CreateMessageReceiver(msftSubscription);
var messageSender = factory.CreateMessageSender(stocksTopic,VIAENTITYPATH);
//…
var brokeredMessage1 = messageReceiver.Receive();
//…
using (var scope = new TransactionScope())
{
    //…
    var brokeredMessage2 = ProcessMessage(brokeredMessage1);
    //…
    messageSender.Send(brokeredMessage2);
    brokeredMessage1.Complete();
    scope.Complete();
}

이 기능은 일반적인 상태 비저장 워크플로 처리 패턴을 지원합니다(단일 트랜잭션에서 수신, 처리, 발신 및 완료). 자세한 내용은 TechNet의 자동 전달을 사용하여 Service Bus 엔터티 연결.

이 기능을 사용하면 엔터티 예를 들어 다음과 같습니다.

QueueDescription destinationQ = new QueueDescription("myQ2");
QueueDescription sourceQ = new QueueDescription("myQ1");
sourceQ.ForwardTo = “myQ2";
NamespaceManager nm = NamespaceManager.Create();
nm.CreateQueue(destinationQ);
nm.CreateQueue(sourceQ);

자세한 내용은 TechNet의 자동 전달을 사용하여 Service Bus 엔터티 연결.

이제 서비스 버스에서는 기존의 메시징 엔터티(큐, 항목 또는 구독)를 사용하지 않도록 설정하거나 다시 사용하도록 설정하여 이를 업데이트할 수 있는 기능이 지원됩니다. 사용하지 않도록 설정된 엔터티에서는 메시지를 보내거나 받을 수 없습니다.

이 기능을 사용하려면 EntityStatus 열거를 설정한 후 엔터티 설명 개체가 매개 변수로 포함되어 있는 다음 API 중 하나를 호출합니다.

예를 들어 다음과 같습니다.

QueueDescription qd = namespaceManager.GetQueue("myQ");
qd.Status = EntityStatus.Disabled;
namespaceManager.UpdateQueue(qd);
qd.Status = EntityStatus.Active;
namespaceManager.UpdateQueue(qd);

이전 버전의 서비스 버스에서는 두 가지 유형의 필터를 구독에 사용할 수 있었습니다. 상관 관계 필터는 많은 수로 확장되지만 단일 속성/값으로 제한됩니다. SQL 필터는 항목당 2,000개의 인스턴스로 제한됩니다. 일부 시나리오에서는 여러 개의 속성 이름/값 조합을 지원하기 위해 필터를 추가하려 할 수 있습니다. 이제 이 기능을 사용하면 속성의 여러 동등 절이 포함된 필터를 설정할 수 있습니다. 예를 들어 다음과 같습니다.

PropertyNameOne=’ValueOne’ AND PropertyNameTwo=ValueTwo AND PropertyNameTest=’ValueThree’
CorrelationFilter filter = new CorrelationFilter();
filter.Properties.Add(
new KeyValuePair<string, object>("name", 10));

이 기능을 사용하면 메시지 보내기, 받기 및 처리를 일괄하여 처리할 수 있습니다. 이 기능을 사용하려면 다음 목록의 새 API를 사용합니다. 서비스 버스에서는 보내기 및 받기 API 일괄 처리에 대한 동기 버전과 비동기 버전을 둘 다 제공합니다.

예를 들어 다음과 같습니다.

IEnumerable<BrokeredMessage> messageSet;
messageSender.SendBatch(messageSet);
messageSet = messageReceiver.ReceiveBatch(100); // max message count

이전 버전의 서비스 버스에서는 메시지가 항목에 게시될 때 가입자가 없는 항목 메시지일지라도 항상 성공적으로 게시되었습니다. 즉, 필터 평가는 성공적인 메시지 게시 이후에 비동기적으로 수행되었습니다. 가입자가 없는 메시지의 경우 삭제되거나 정책에 따라 배달 못한 메시지로 분류되었습니다. 일부 시나리오에서는 메시지 게시자가 메시지 게시 시점에 가입자의 존재 여부를 알고 있어야 합니다. 이제 서비스 버스에서는 이러한 시나리오가 지원되어, 메시지 게시 시점에 가입자가 없는 경우 메시지를 게시하지 못합니다.

이 기능을 사용하려면 EnableFilteringMessagesBeforePublishing 속성을 true(으)로 설정합니다. 예를 들어 다음과 같습니다.

TopicDescription td = new TopicDescription("Topic");
td.EnableFilteringMessagesBeforePublishing = true;

이 새 기능을 사용하면 Abandon, Defer 또는 DeadLetter 작업 수행 시 메시지 속성을 추가하거나 수정할 수 있습니다. 이 기능은 응용 프로그램 처리 오류가 발생했으며 이로 인해 메시지가 중단될지를 추적해야 하는 시나리오에 유용합니다. 다음 API의 propertiesToModify 매개 변수에서 메시지 속성을 추가하거나 수정하면 됩니다.

이번 서비스 버스에는 Microsoft.ServiceBus.Messaging.MessageCountDetails라는 새 클래스가 도입되었습니다. 이 클래스에는 기본 메시징 엔터티(큐, 항목, 구독)의 하위 큐에서 메시지 세부 정보를 검색할 수 있는 속성이 포함되어 있습니다. MessageCountDetails 속성은 다음과 같습니다.

public long ActiveMessageCount { get; set; }
public long DeadletterMessageCount { get; set; }
public long ScheduledMessageCount { get; set; }
public long TransferMessageCount { get; set; }
public long TransferDeadLetterMessageCount { get; set; }

BrokeredMessage 클래스에 새로 포함된 속성인 IsBodyConsumed을(를) 사용하면 메시지 본문이 사용되었는지 확인할 수 있습니다. 예를 들어 보내기 작업에 실패한 경우 동일한 메시지를 다시 보낼 수 있는지 확인할 수 있습니다. 또는 메시지가 수신된 경우에는 메시지 본문이 사용되었는지를 확인할 수 있습니다.

다음 경우 중 하나에 해당되면 IsBodyConsumedtrue로 설정됩니다.

  1. 누군가 메시지 본문을 사용하기 위해 GetBody을(를) 호출했습니다.

  2. 보내기 작업에서 메시지가 사용된 것으로 표시되었습니다.

true로 설정된 경우 해당 메시지에 대해 GetBody 또는 Send 작업을 수행하면 메시지가 이미 사용되었음을 알리는 예외가 반환됩니다. 그런 다음 작업을 다시 수행할 메시지를 만들 수 있습니다(예: Clone을(를) 사용하여, 보낼 메시지 구성).

BrokeredMessage 클래스에는 Clone(이)라는 새 메서드가 포함되어 있습니다. 이 메서드를 사용하면 메시지 복제본을 새 메시지로 보낼 수 있습니다. 시스템 속성은 새 메시지에 선택적으로 복사할 수 있도록 그대로 유지되지만 메시지의 속성과 본문은 복제본에 복사됩니다. 복제 작업 후 MessageId 속성을 수동으로 설정할 수 있습니다.

연결 문자열은 응용 프로그램을 한 환경(예: 테스트 환경)에 배포한 다음 다른 환경(예: 프로덕션 환경)에 배포하려는 시나리오에 유용합니다. 이 기능을 수행하려면 App.config에서 연결 문자열이 새 서비스 네임스페이스를 가리키도록 변경한 다음 응용 프로그램을 다시 시작하면 됩니다.

자세한 내용은 TechNet의 구성 연결 문자열.

이제 WebHttpRelayBinding 바인딩에 JSON 콘텐츠 형식을 사용할 수 있습니다. JSON 메시지를 수신하도록 릴레이 수신기를 업데이트하려면 WebHttpRelayBindingContentTypeMapper 속성을 설정합니다. 예는 WebContentTypeMapper 샘플을 참조하십시오.

이전에는 ConnectionStatusBehavior 동작이 단방향 바인딩에만 기능했습니다. 이제 이 동작을 모든 릴레이 수신기 바인딩에 사용할 수 있습니다.

서비스 버스 릴레이 바인딩은 HTTP 1.1 “청크 방식” 전송 인코딩을 사용합니다. 하지만 일부 레거시 프록시는 HTTP 1.0만 지원하거나 HTTP 1.1 청크 방식 전송 인코딩을 제대로 지원하지 않습니다. 따라서 이러한 레거시 프록시를 통해 접속하는 클라이언트는 서비스 버스 릴레이 연결에 실패할 수 있습니다. 이 문제를 해결하기 위해 서비스 버스 릴레이 바인딩은 이전 연결 시도가 실패하면 HTTPS를 사용하여 연결을 시도합니다. 이 기능을 사용하려면 SystemConnectivity 속성의 Mode 값을 AutoDetect 또는 Http로 설정합니다. ConnectivityMode 열거는 설명서를 자세한 내용은 TechNet의하십시오.

연결은 성공적인 연결에 사용된 프로토콜을 캐시하며 후속 재연결 작업에서는 캐시된 프로토콜 방식을 먼저 사용하도록 시도합니다.

방화벽 뒤에서 호스팅하는 경우 이 기능을 사용하려면 포트 443에서 아웃바운드 HTTPS 연결을 허용해야 합니다.

프록시에 인증이 필요한 경우에는 릴레이 연결이 실패할 수 있습니다. 이제 서비스 버스 릴레이 바인딩은 통합된 Windows 인증 또는 협상으로 구성된 프록시를 통한 연결을 지원합니다.

표시:
© 2015 Microsoft