0

I have a requirement to build a NSB subscriber which will subscribe to messages being published by a service which is already live. This service was built with a messages assembly containing the NSB IMessage implementations which I want to subscribe to. So to build my subscriber I need a hard dependency on this assembly.

When my subscriber starts up it sends some messages to the publisher input queue which results in the publisher recording my subscriptions in the database. One of my subscriptions looks like this:

MyNamespace.MyMessageType, MyNamespace, Version=1.0.0.0, Culture=neutral, PublicKeyToken=MyPublicKeyToken

Unfortunately the publisher is publishing messages from an assembly which is not strong named. So when publishing, the subscription evaluation process fails to evaluate successfully against my subscription, because the public key token of the message being published (value = null) does not match my subscription.

My question is: Can I not subscribe to messages by Type and version only? Even better - can I not subscribe to messages based on some external contract (like an XSD) and break this dependency altogether?

Many thanks in advance.

UPDATE: The NSB docs hint at something like this here:

http://www.nservicebus.com/MessagesAsInterfaces.aspx

tom redfern
  • 30,562
  • 14
  • 91
  • 126
  • Is there a strong business case why the messages assembly must be strong-named? – David Boike May 25 '11 at 15:28
  • Well, not a business case, but in general it is safer to go into a production environment with strong named code. If this dependency was third party (it's not) then I would have a real problem because I would have no idea if the assembly came from a trusted source or not. I know what you are saying though. In actual fact I am not blocked by this because I have asked the team developing the messages to simply sign the messages assembly. But my post is still valid. When using NSB pubsub you will always have a hard dependency on your publisher which doesn't exist if you are just using Bus.Send(). – tom redfern May 26 '11 at 10:35

1 Answers1

1

For regular messages you create you can use the XsdGenerator tool in the tools directory of NSB to generate a schema that you can pass along to other endpoints. You will want to use this tool instead of the .NET Framework tool as it does not support interfaces. From there you can use the schema to handle messages.

For subscription messages, if you don't want to use the assembly you could tell NSB to DoNotAutoSubscribe() and subscribe manually(Bus.Subscribe(Type)) passing along the Type of the message however you wish. This could be off the schema or some other configuration.

Adam Fyles
  • 6,030
  • 1
  • 23
  • 29
  • Thanks Adam. However, this is not the answer. I can happily break binary dependencies in a service/consumer point to point messaging solution by simply referencing a local assembly whose type definitions allow clean deserialization of the XML coming off the wire, in this case by having the service run "AsA_Server". The hard dependency is created when the service runs "AsA_Publisher", and the subscriber sends subscription messages which are based on a reflection of a referenced assembly. – tom redfern May 26 '11 at 10:27
  • If you don't want to use the assembly you could tell NSB to DoNotAutoSubscribe() and subscribe manually(Bus.Subscribe(Type)) passing along the Type of the message however you wish. This could be off the schema or some other configuration. Would that work? – Adam Fyles May 26 '11 at 14:15
  • Hi Adam. If you can send a subscription message which is valid for the publisher then I can't see why this wouldn't work. This sounds like the best solution to break the dependency all together. Please make this a proper stackoverflow answer and I will upvote it and mark it as such. Thanks! TC – tom redfern May 27 '11 at 09:41
  • However, it may be quite a challenge to send the correct "valid" subscription message. By valid in this case I mean that the publisher is able to succesfully evaluate against it and send the message out as a result of the evaluation. There is certainly no built in support for this. – tom redfern May 27 '11 at 09:49
  • Edited to include the suggestion from the comments. – Adam Fyles May 27 '11 at 14:20