Now you're just talking Semantics

Semantic is one of the more estoric things in the Neuron world. If you never use the Test Client or the API you may not even know it exists...

Semantic has a couple of effects in Neuron. It controls message path and it influences blocking behavior of the Party Publishing. Most Neuron users are impacted by Semantic in the Service Endpoints.

When you use Request-Reply Messaging Pattern with a Client Connector what occurs under the covers is that the Neuron API publishes the incoming message with a Request Semantic. This will make the Party block in the Send method until it receives a reply or times out.

When you use Request-Reply Messaging Pattern with a Service Connector the Service Connector will pass on messages with a Request semantic to the target service and will ignore messages with a Multicast semantic. When you use a Datagram Messaging Pattern the reverse occurs. The Service Connector will ignore Request Semantic messages.

Controlling Semantic can let you do interesting things.. For instance you can chain service calls merely by flipping from Request to Multicast to Request...(set it to Request in the Service Connector Party's On Receive pipeline and then to Multicast in the On Publish pipeline).

If you want to play with Semantic in the API then you can use CreateReplyMessage()..

But before you go Semantic crazy pause...Do you really need to block? Multicast is asynch messaging and that's usually the way go when you have a choice. Request Reply is the pattern of choice for 90% of WS implementations but if you're using the API then you should probably consider seriously leveraging asynch patterns and architecture.