JasperFx 0.8.2


Next

RabbitMQ Transport

Previous

Local Loopback Transport

HTTP Transport Edit on GitHub


With the ASP.Net team putting so much effort into making Kestrel performant and robust, it seemed to make perfect sense to support an alternative transport based on Kestrel that can be used to send messages between Jasper applications.

Why not just use HTTP services if you're going to use the HTTP transport described here? Because the transport adds all the support for retries, back pressure, durability, and error handling you expect with a service bus that you would have to at least partially build in yourself if you were only using HTTP services for integration.

There's a couple things to note about the HTTP transport option:

  • Sending messages through the HTTP transport is enabled by default in any Jasper application
  • Receiving messages through the HTTP transport requires you to explicitly enable HTTP message listening as shown in the code sample below. You will also need to explicitly add Kestrel hosting through your application bootstrapping as you normally do in ASP.Net Core applications.
  • Enabling the HTTP transport listening adds a pair of new HTTP endpoints to your Jasper application
  • The messages sent are batched similar to the TCP Transport
  • Likewise, the message persistence can be combined with the HTTP transport
  • Jasper itself adds the additional routes from Jasper's own HTTP router. See Adding Jasper to an ASP.Net Core Application for more information on ordering Jasper's middleware within your larger ASP.Net Core application

Configuring the HTTP Transport

You can enable the HTTP transport listening, the relative url of the message endpoint, and the connection timeout for sending message batches with the code shown below:


public class AppUsingHttpTransport : JasperRegistry
{
    public AppUsingHttpTransport()
    {
        // While *sending* by the HTTP transport is enabled by default,
        // you have to explicitly enable the HTTP transport listening
        Transports.Http.EnableListening(true)

            // The default is 10 seconds
            .ConnectionTimeout(2.Seconds())

            // Override the releative Url of the message
            // listening routes. The default is _messages
            .RelativeUrl("_jasper");

        // You'll have to have Kestrel or some other
        // web server for this to function
        Hosting
            .UseUrls("http://*:5000")
            .UseKestrel();




    }
}

By default, the messages are received on a pair of routes in your system:

  1. PUT: /messages -- receives message batches in a non-durable manner
  2. PUT: /messages/durable -- receives message batches and uses the Durable Messaging

As shown above, you can replace the "messages" segment for the base Url of the messaging receiver.

Publishing to the HTTP Transport

Note! Using HTTPS is a little bit of a work in progress. Follow our GitHub issue for progress on this.

To configure messages to be published or received through the HTTP transport, you use the Url to the /messages or /messages/durable endpoint of the downstream system like this:


public class HttpTransportUsingApp : JasperRegistry
{
    public HttpTransportUsingApp()
    {
        Publish.AllMessagesTo("http://server1/messages");

        // Or

        Publish.AllMessagesTo("http://server1/messages/durable");
    }
}

See Routing Messages for more information on configuring publishing rules and subscriptions.

Configuring Authentication with the HTTP Transport

Yeah, this one is a work in progress.