MSMQ & WCF Сообщения не отображаются в личной очереди - PullRequest
1 голос
/ 06 июня 2011

Было несколько подобных вопросов, и я ОЧЕНЬ новичок в MSMQ.

Я пытался связать ServiceContract и связанный DataContract с MSMQ и настроил конечные точки так, чтобы сообщение DataContact заканчивалось в MSMQ.

Я проверил, что сообщение корректно генерируется службой WCF, и я также вижу, что сообщения находятся в журнале очереди, в которую я отправляю, но не в фактической области сообщений в очереди, где я ожидал бы их .

В данный момент я не использую транзакции, и я установил безопасность ни на один. Я прилагаю соответствующий код, хотя я чувствую, что мне не хватает чего-то фундаментального из-за незнания MSMQ. Любые указатели будут оценены.

Контракты на обслуживание и данные

</p> <pre><code>[DataContract] public class RegistrationMessage : IRegistrationMessage { [DataMember] public string EMailAddress { get; set; } [DataMember] public string FirstName { get; set; } [DataMember] public string LastName { get; set; } } [ServiceContract] public interface IRegistration { [OperationContract(IsOneWay = true)] void Register(RegistrationMessage message); }

app.config хоста WCF

<configuration>
    <system.serviceModel>
        <behaviors>
            <serviceBehaviors>
                <behavior name="MetaDataBehaviour">
                    <serviceMetadata httpGetEnabled="false" />
                </behavior>
            </serviceBehaviors>
        </behaviors>
        <bindings>
            <netMsmqBinding>
                <binding name="msmq" 
                         deadLetterQueue="System" durable="true"
                         exactlyOnce="false" 
                         receiveContextEnabled="false" 
                         useMsmqTracing="true">
                    <security mode="None" />
                </binding>
            </netMsmqBinding>
        </bindings>
        <services>
            <service behaviorConfiguration="MetaDataBehaviour" name="Client.AuthenticationService.RegistrationService">
                <endpoint address="net.msmq://localhost/private/AuthenticationQueue"
                    binding="netMsmqBinding" 
                    bindingConfiguration="msmq" name="msmq"
                    contract="Global.DomainModel.IRegistration" />
                <endpoint address="mex" binding="mexHttpBinding" name="mex" contract="IMetadataExchange" />
                <host>
                    <baseAddresses>
                        <add baseAddress="http://localhost:8080/Registration/" />
                    </baseAddresses>
                </host>
            </service>
        </services>
    </system.serviceModel>
</configuration>

Ответы [ 2 ]

5 голосов
/ 06 июня 2011

Я не знаю WCF, но могу прокомментировать MSMQ.

"Я подтвердил, что сообщение правильно генерируется WCF сервис, и я также вижу, что сообщения в журнале очередь, которую я отправляю, но не в фактическая область сообщений в очереди, где я бы ожидайте их. "

Это означает, что сообщение было доставлено и обработано.
Сообщения журнала, связанные с очередью, создаются только тогда, когда сообщение доставлено И затем прочитано / получено приложением.
Если бы сообщение было только что доставлено, а не прочитано / получено, тогда еще не было бы создано сообщение журнала, а оригинал остался бы в очереди назначения.
Если сообщение было доставлено, но затем удалено / удалено, не будет создано сообщение журнала, поскольку исходное сообщение не было успешно прочитано / получено приложением.

Приветствия
Джон Брейквелл

2 голосов
/ 07 июня 2011

Ну, так как никто, кажется, не имеет ответа на вопрос, почему сообщения используются, я написал обходной путь в реализации службы, которая использует собственные классы System.Messaging.Это позор, потому что в соответствии с документацией можно отправлять сообщение в очередь без кода (при условии, что конечные точки описаны правильно).

Вот код, который я использовал для всехв этом затруднительном положении.

В проекте консоли хоста я изменил конечную точку App.Config, закомментировав net.msmq и добавив wsHttpBinding, чтобы сделать его обычной службой WCF.

        <services>
            <service behaviorConfiguration="MetaDataBehaviour" name="Client.AuthenticationService.RegistrationService">
<!--                <endpoint address="net.msmq://localhost/private/authenticationqueue"
                          binding="netMsmqBinding" 
                          bindingConfiguration="msmq" 
                          name="msmq"
                          contract="Global.DomainModel.IRegistration" /> -->
                <endpoint address="http://localhost:8080/Registration"
                          binding="wsHttpBinding"
                          bindingConfiguration=""
                          contract="Global.DomainModel.IRegistration" /> 
                <endpoint address="mex" 
                          binding="mexHttpBinding" 
                          name="mex" 
                          contract="IMetadataExchange" />
                <host>
                    <baseAddresses>
                        <add baseAddress="http://localhost:8080/Registration/" />
                    </baseAddresses>
                </host>
            </service>

В службеВ качестве реализации я добавил следующее (оставив исходные операторы Console.WriteLine в целях тестирования:

    public void Register(RegistrationMessage message)
    {
        MessageQueue queue = new MessageQueue(@".\private$\authenticationqueue");
        Message msg = new Message();
        msg.ResponseQueue = queue;
        msg.Label = "AuthenticationMessage";
        msg.Body = message;
        queue.Send(msg);
        Console.WriteLine("e-mail: " + message.EMailAddress);
        Console.WriteLine("First Name: " + message.FirstName);
        Console.WriteLine("Last Name: " + message.LastName);
    }

. Это прекрасно работает и работает, как и ожидалось, увлажняя очередь. Теперь я могу написать основную службу рабочего процесса для использованияэто.

Спасибо Джону за подтверждение того факта, что сообщения фактически были израсходованы. Я бы проголосовал, но мой уровень слишком низкий :)

...