0
votes

Trying to implement a MSMQ-backed WCF PubSub. I understand that net.msmq is one-way; however when I use a single service object to implement the net.msmq endpoint for reading from the underlying queue, and a net.tcp endpoint for listeners to subscribe to with callbacks, I'm running into a lot of complaints about one-way vs. two-way, DuplexChannelFactory, DuplexClientBase, etc. etc.

It almost seems like the only way to implement this is to have the net.msmq queue reading service be a client to a net.tcp publisher service, and notify the publisher when the new message is read from the queue, rather than publish the message to subscribers internally. Or, to not use net.msmq on the receiver, and just ready with a plain old MessageQueue object instead.

1
So you want single class which is both one way service for net.msmq and duplex service for net.tcp?Ladislav Mrnka
Can you post those errors / complaints.Ladislav Mrnka
I would need to regress some code, but sure, I'll try to get to that tonight. (All-nighter client install last night, I'm about to crash right now.) And yes, you are correct: one single class implementing one-way net.msmq receive and duplex net.tcp for subscriber/listener callbacks. I want the received queue message to be broadcast to N subscribers without having to touch another process or service in the middle.andrewbadera
Also: I'm aware it is possible to achieve something similar using a custom msmq-based binding, but I'm hoping to stick with net.tcp clients only.andrewbadera

1 Answers

0
votes

After refactoring some interfaces and finding some missing attribution and awkard relationships between subscriber and callback implementor, I have established the intended queue-backed pubsub pattern. So yes, it is possible, previous difficulties were design error on my part.

Edit/footnote: For some reason, messages previously passed to the net.msmq receiver as MsmqMessage are now throwing nullreferenceexceptions; however changing the signature to MyObject works, which it did not initially