Comments on: NServiceBus, Semantic Versioning and events

By: Matt Hinze

Matt Hinze — Thu, 07 Feb 2013 21:58:00 +0000

How does this resolve with the spirit of this guidance? http://support.nservicebus.com/customer/portal/articles/894151-versioning-sample

At any rate, I think tying the .NET type metadata to the message schema is unacceptable platform coupling.

Naively, I expect what’s defined in MessageEndpointMappings to be stored as subscription data.

I think we need to be verrrrry careful with SemVer. I agree with conventional wisdom that it is well thought out and broadly applicable, but should not be shellacked upon every versioning problem.

Finally, the lack of information about this coupling – message schema to .NET type metadata – can lead to confusion .. especially considering the publisher’s behavior when in cases where this suddenly doesn’t match.

By: jbogard

jbogard — Thu, 07 Feb 2013 20:02:00 +0000

So one thing that might throw a wrench into all this is the assumption that the assembly version belongs in the message schema. Assembly versions can be used for a lot of things (identifying releases, dates, etc.) that have little or nothing to do with actual shape of the message.

The behavior we saw was that the year changed from 2012 -> 2013, which we include as our major version (not even set by us, but by the build/deploy group), and all of our subscriptions broke, silently.

Typically, I’d handle versioning much differently. I either add information, or I create new messages. If the message is so different that it would break clients (i.e. version number), it’s a new message.

By: jbogard

jbogard — Thu, 07 Feb 2013 13:35:00 +0000

Type != message, assembly != version. The assumption is that the type IS the message. It’s not. The type is the type, the message is the message. The type is merely a representation of the message, nothing more. If the message looks *exactly the same*, then it is the same message.

In any case, using the assembly version to version messages is a pretty lousy approach. It allows no wiggle room to support existing clients. If clients must upgrade all their DLLs, I’ve increased, not decreased coupling.

By: Edwin G. Castro

Edwin G. Castro — Thu, 07 Feb 2013 05:56:00 +0000

Well put. This is precisely what I was trying to convey but expressed much better than I was able to. This principle applies to all contracts/interfaces regardless of the mechanism used to communicate between parties.

By: Edwin G. Castro

Edwin G. Castro — Thu, 07 Feb 2013 05:53:00 +0000

Using the perspective that the publisher always owns the contract (which is a valid perspective) then you must accept the fact that all subscribers must upgrade whenever the publisher decides to change. When physical assemblies are involved, then change is dictated by both physical structure (the classes themselves) and AssemblyVersion (two classes with the same structure in assemblies with different versions *are* different classes). In the end I don’t think looking at contracts as either Send/Receive versus Publish/Subscribe is very interesting (as you mentioned they are both sources/sinks). What is interesting is your dedication to changing behavior without impacting the other end. If you want all clients to continue to subscribe and react to a particular message when you change behavior, then you must keep the AssemblyName constant (which include AssemblyVersion) because the true full name of the message includes the full AssemblyName. Changing the AssemblyVersion of your messages should require all your subscribers to upgrade. I personally don’t find that strange or odd.

By: Bruce Onder

Bruce Onder — Wed, 06 Feb 2013 00:59:00 +0000

The way one of my developers “solved” this at a previous company was classic: just pass strings around. LOL

By: Udi Dahan

Udi Dahan — Sun, 03 Feb 2013 13:43:00 +0000

The short story here is that you can’t just change a message schema and expect everything to continue to “just work”.

You can change anything else you want about your publishers and subscribers without anything breaking.The schema is the only thing shared between publishers and subscribers so it should be versioned carefully – including changing its version number.

By: Scott Banwart's Blog › Distributed Weekly 192

Scott Banwart's Blog › Distributed Weekly 192 — Fri, 01 Feb 2013 09:35:19 +0000

[...] NServiceBus, Semantic Versioning and events [...]

By: jbogard

jbogard — Fri, 01 Feb 2013 02:31:00 +0000

Consumer/subscriber are two different concepts – I wouldn’t mix the two. Send/Receive is much different than publish/subscribe.

In Send/Receive, the receiver owns the contract.

In Pub/Sub, the publisher owns the contract.

Think of it this way – the IRS – the receiver – owns the tax forms. The magazine publisher owns the magazine. It’s both sources/sinks, but the roles they play are very different.

By: Edwin G. Castro

Edwin G. Castro — Thu, 31 Jan 2013 17:29:00 +0000

I once read that interfaces belong to the consumer of the interface. I can’t remember exactly where I read that but I’ve seen this mistake happen over and over again in distributed scenarios. I work with WCF services and generally speaking I see service implementations defining the contract they implement. So whenever the service implementation changes it forces the contract to change as well. The end result is that the client/consumer also must change even if they wanted to continue to use the old contract. I’ve seen this happen even when the new implementation supports multiple contracts. The same is happening here. The contract is the message. The message truly belongs to the consumer/subscriber. The publisher can specify which version of a message it happens to support. Therefore, if it is impractical to change all of your consumers to subscribe to a newer version of a message then somebody needs to continue to produce that specific version of the message (even if it is a different implementation of the publisher). Contracts/messages/interfaces really should be defined independently of both the subscriber/client that consume them and the publisher/service that implement/generate them. That is the only way to truly keep components loosely decoupled regardless of the mechanism used to communicate (service bus, SOAP, REST, RPC, Remoting, etc.).