Getting Started with Request-Response requires too much messaging domain knowledge

[mikeminutillo]

trafficstars

Problem Definition (Required)

When customers are first getting started with NServiceBus we often try to replace calls to web services with specific integration endpoints. Frequently this involves creating a new endpoint that calls the web service, adding messages for each request/response interaction, and creating a client endpoint to send requests (and optionally, wait for results). This is a non-trivial amount of work and requires getting customers to understand many concepts of NServiceBus before they can even get started.

[mikeminutillo]

Solution Idea:

What if we could generate a scaffold for this code from a WCF Contract. The idea is that we could entirely generate an integration endpoint and all of it's messages from an existing WCF Contract. Each operation would have a Request Message (and optionally a Response message). It would include the callbacks package. This gives us a way to proxy an existing WCF Service BEHIND an NServiceBus endpoint (giving us retries, error handling, audit logging, etc).

We could also generate a client library to call it. It would stand up a new endpoint, send requests to the integration endpoint and wait for responses.

Now all a customer needs to do is start replacing calls to the WCF service with calls to the NServiceBus client library that we've generated for them. Ideally the signatures are the same so this is as simple as replacing one client proxy with another.

Using this we can walk up to an existing distributed system and quickly stand up NServiceBus in between the parts. We can later work to make things more async and remove the callbacks package, etc.