Use of NServiceBus in Microservices: Avoiding a shared type dll

[Bo Nielsen]

I'm doing a POC on NServiceBus using rabbitmq as broker.

In our setup, we're using microservices, and some of my team members don't like the idea of a shared library for type definitions, as this leads to higher coupling. They would prefer just sending raw xml or json (both for the events and commands) and then let the individual microservice deal with deserialization or extracting the info they need.

Is there a way to accomplish this for both commands and events?

[Sean Feldman]

Hi Bo,

If understood correctly, you don't want to share the messages assembly. You could use message conventions (http://docs.particular.net/nservicebus/messaging/conventions) and redefine messages locally. 

I'm not sure if sharing well agreed contracts is a negative thing, but I probably don't know all the details of your system.

[Adam Tybor]

+1 Bo, spot on, we have those challenges too. A core tenant of soa is share schemas not types, yet nsb makes this extremely difficult. Would love to see a roadmap item to make this more flexible. Interoperability is also a major concern as we are using several non dotnet platforms now and have to hack a lot of stuff to get it to work.

Adam

--
You received this message because you are subscribed to the Google Groups "Particular Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at https://groups.google.com/group/particularsoftware.
To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/80022ec9-beaa-4110-bf57-e2dbe638744e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Udi Dahan]

Adam,

 

Can you help me understand why generating a JSON Schema from the message types wouldn’t be a workable option?

 

https://sixgun.wordpress.com/2012/02/09/using-json-net-to-generate-jsonschema/

 

-- Udi

To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/CAM6ntuq%3Dbpy5DYFiobigvRY5Jo19AvsQZzX109VjTaXQ%3D6pLnA%40mail.gmail.com.

[Adam Tybor]

@Udi because last I checked NSB can't consume that, NSB still requires exact .NET type names and assembly version numbers.  We have to always a master contract via a .NET assembly so other platforms (non .net) can enrich their messages with .NET message types and assembly versions for interop.

To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/029001d19a6c%24013856f0%2403a904d0%24%40particular.net.

[Sean Feldman]

Adam,

I'm curious since know you're on ASB. Type yes, version, not so sure. If you're using message conventions, we only check the type, not the version.

[Adam Tybor]

My team told me they needed to add the fully qualified type name including the assembly version to get the interop to work. I also still assumed that this article https://lostechies.com/jimmybogard/2013/01/31/nservicebus-semantic-versioning-and-events/ was applicable. Would love to see an example and docu about how to do it with schema only.

Adam

On Wed, Apr 20, 2016, 6:35 PM Sean Feldman <sean.f...@particular.net> wrote:

Adam,

I'm curious since know you're on ASB. Type yes, version, not so sure. If you're using message conventions, we only check the type, not the version.

--

You received this message because you are subscribed to the Google Groups "Particular Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftw...@googlegroups.com.
To post to this group, send email to particula...@googlegroups.com.
Visit this group at https://groups.google.com/group/particularsoftware.

To view this discussion on the web visit https://groups.google.com/d/msgid/particularsoftware/d5b89a02-aec0-43a8-a755-ef049711be04%40googlegroups.com.

[John Fly]

Also interested in this.

I've started (barely) on a solution to help with service discovery and integration.

So far its just iterating though the handlers in each process after NSB is configured, collecting the types (messages) handled by a process.  I can then write out DGML or pipe to a "registry" to help see what my system looks like.

Plans included reading the message schema (json) from other languages and being able to submit messages from other non .Net languages..  

Something -similar- to swagger/thrift definitions, where the dll's wouldn't have to be distributed... just the message definition

On Thursday, April 21, 2016 at 6:48:47 AM UTC-5, Adam Tybor wrote:

My team told me they needed to add the fully qualified type name including the assembly version to get the interop to work. I also still assumed that this article https://lostechies.com/jimmybogard/2013/01/31/nservicebus-semantic-versioning-and-events/ was applicable. Would love to see an example and docu about how to do it with schema only.

Adam

On Wed, Apr 20, 2016, 6:35 PM Sean Feldman <sean.f...@particular.net> wrote:

Adam,

I'm curious since know you're on ASB. Type yes, version, not so sure. If you're using message conventions, we only check the type, not the version.

--
You received this message because you are subscribed to the Google Groups "Particular Software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to particularsoftware+unsub...@googlegroups.com.

[Sean Feldman]

Hi Adam,

For ASB, could you please point your team to the following sample: Native Integration with Azure Service Bus Transport (http://docs.particular.net/samples/azure/native-integration-asb/)

When message is constructed, it solely uses the type. Version for ASB is not needed.

string nativeMessage = @"{""Content"":""Hello from native sender"",""SendOnUtc"":""2015-10-27T20:47:27.4682716Z""}";

// message is a BrokeredMessage
message.Properties["NServiceBus.EnclosedMessageTypes"] = "NativeMessage";
message.Properties["NServiceBus.MessageIntent"] = "Send";

For other transport the story is lightly different, and I'd encourage to subscribe to the following GitHub issue: https://github.com/Particular/NServiceBus/issues/1394

[Daniel Marbach]

Hy adam,

Probably two or three years ago I made a presentation in Germany where I showed the interoperability between NServiceBus, ActiveMQ Native and RabbitMQ native with Java. Here is for example the Java producer for RabbitMQ. 

https://github.com/danielmarbach/Transport.Transport/blob/master/RabbitMQ2NServiceBus/src/ch/danielmarbach/rabbitmq2nservicebus/WarehouseRaid.java#L44

I used XmlSerializer. The only required information was the proper root node name and the schema information. 

Daniel