For my take on when you would use a tool like Jasper, see How Should Microservice’s Communicate?

“Jasper” is the codename for a new messaging and command execution framework that my shop has been building out to both integrate with and eventually replace our existing messaging infrastructure as we migrate applications to Netstandard 2.0, ASP.Net Core, and yes, adopt a microservices architecture. While we’ve been working very hard on it over the past 6 months, I’ve been hesitant to talk about it too much online. That ends today with the release of the first usable alpha (0.5.0) to Nuget today.

We’ve already done a great deal of work and it’s fairly feature rich, but I’m really just hoping to start drumming up some community interest and getting whatever feedback I can. Production-worthy versions of Jasper should hopefully be ready this spring.

Okay, so what problems does it solve over just using queues?

It’s ostensibly about NServiceBus (for right now, let’s call that the most similar competitor to Jasper), but Sure, You Can Just Use RabbitMQ sums it up perfectly. Jasper already supports functionality to:

• Route messages between services
• Execute commands within the services
• Deal with message versioning
• Deal with service discovery
• Provide error handling policies
• Apply message handling middleware for common cross cutting concerns
• Write reliable, automated tests against Jasper applications

Why would you want to use Jasper over [fill in the blank tool]?

I hate this part of talking about any kind of OSS activity or choice, but I know it’s coming, so let’s get to it:

• Jasper’s execution pipeline is leaner than any other .Net framework that I’m aware of, and we’re theorizing that this will lead to Jasper having better performance, less memory utilization, less GC thrashing, and easier to understand stacktraces than other .Net frameworks. My very next blog post will be showing off our “special sauce” usage of Roslyn code generation and runtime compilation that makes this all possible.
• Jasper requires much less coupling from your application code to the framework, especially compared to the typical .Net framework that requires you to implement their own interfaces or base classes, tangle your code with fluent interfaces, or force you to spray attributes all over your code. Some of you aren’t going to like that, but my preference is always cleaner code. There’s plenty of room in the world for both of us;)
• It’s FOSS
• Jasper plays nicely with ASP.Net Core and even comes with recipes for quick integration into ASP.Net Core applications

Ping/Pong Hello World

The obligatory “hello, world” project in messaging is to send a “ping” message from one service to another, with the expectation that the receiving system will send back a “pong.” So let’s start by saying we have a couple message types like these:

    public class PingMessage
    {
        public string Name { get; set; }
    }

    public class PongMessage
    {
        public string Name { get; set; }
    }

Note: Jasper does not require you to share .Net types between systems, but it’s the easiest way to get started so here you go.

Starting with the “Ponger” service (if the code is cut off in the blog post, it’s all in this project on GitHub), just follow these steps:

1. “dotnet new console” to create a new console app
2. Add a Nuget reference to Jasper.CommandLine that will also bring in the core Jasper Nuget as well

From there, the entire “Ponger” service is the following code:

    class Program
    {
        static int Main(string[] args)
        {
            return JasperAgent.Run(args, _ =>
            {
                _.Logging.UseConsoleLogging = true;

                _.Transports.LightweightListenerAt(2601);
            });
        }
    }

    public class PingHandler
    {
        public object Handle(PingMessage message)
        {
            ConsoleWriter.Write(ConsoleColor.Cyan, "Got a ping with name: " + message.Name);

            var response = new PongMessage
            {
                Name = message.Name
            };

            // Send a Pong response back to the original sender
            return Respond.With(response).ToSender();
        }
    }

Now, moving on to the “Pinger” service. Follow the same steps to start a new .Net console project and add a reference to the Jasper.CommandLine Nuget.

From there, we can utilize ASP.Net Core’s support for background services to send a new ping message every second:

    public class PingSender : BackgroundService
    {
        private readonly IServiceBus _bus;

        public PingSender(IServiceBus bus)
        {
            _bus = bus;
        }

        protected override Task ExecuteAsync(CancellationToken stoppingToken)
        {
            int count = 1;

            return Task.Run(async () =>
            {
                while (!stoppingToken.IsCancellationRequested)
                {
                    Thread.Sleep(1000);

                    await _bus.Send(new PingMessage
                    {
                        Name = "Message" + count++
                    });
                }
            }, stoppingToken);
        }
    }

Next, we need a simple message handler that receives the pong replies and writes the receipt to the console output:

    // Handles the Pong responses
    public class PongHandler
    {
        public void Handle(PongMessage message)
        {
            ConsoleWriter.Write(ConsoleColor.Cyan, "Got a pong back with name: " + message.Name);
        }
    }

Now, there’s a little more work to configure the Pinger application:

    class Program
    {
        static int Main(string[] args)
        {
            return JasperAgent.Run(args, _ =>
            {
                // Way too verbose logging suitable
                // for debugging
                _.Logging.UseConsoleLogging = true;

                // Listen for incoming messages
                // at port 2600
                _.Transports.LightweightListenerAt(2600);

                // Using static routing rules to start
                _.Publish.Message()
                    .To("tcp://localhost:2601");

                // Just adding the PingSender
                _.Services.AddSingleton<IHostedService, PingSender>();
            });
        }
    }

If I start up the Pinger application with “dotnet run” at the command line, I get output like this:

Running service 'Pinger'
Application Assembly: Pinger, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
Hosting environment: Production
Content root path: /Users/user/code/jasper/src/Pinger/bin/Debug/netcoreapp2.0/
Listening for loopback messages
Listening at tcp://YOURMACHINE:2600/

Active sending agent to ws://default/
Active sending agent to tcp://localhost:2601/
Active sending agent to loopback://replies/
Active sending agent to loopback://retries/
Application started. Press Ctrl+C to shut down.

Which, because the Ponger application hasn’t been started, will start spitting out messages like:

Failure trying to send a message batch to tcp://localhost:2601/

And after enough failures trying to send messages, you’ll finally see this:

Sending agent for tcp://localhost:2601/ is latched

Now, after starting the Ponger service with its own “dotnet run,” you should see the following output back in the Pinger console output after Jasper detects that the downstream system for the Ping messages is available:

Sending agent for tcp://localhost:2601/ has resumed

And finally, a whole bunch of console messages about ping and pong messages zipping back and forth.

Other Common Questions

• Is this in production yet? Yes, a super, duper early version of Jasper is in production in a low volume system.
• Is it ready for production usage? No, it’s not really proven out yet in real usage. I think we’ll be able to start converting applications to Jasper this month, so it hopefully won’t be long. The sooner that folks poke and prod it, then supply feedback, the faster it’s ready to go.
• What .Net frameworks does it support? Netstandard 2.0 only.
• Where’s the code? On GitHub.
• Are there any docs yet? Yeah, but there’s plenty of room for improvement on the Jasper website.
• Where can I ask questions or just make fun of this thing? There’s a Gitter room ready
• What about the license? The permissive MIT license.
• Is it just you? Nope, several of my colleagues have contributed code, ideas, and feedback so far.
• Do you want more contributors? Hell, yeah. The more the merrier.
• Why roll your own? See the first section of this post. We’re not starting from scratch by any means, otherwise I don’t think we would have opted to build something brand new.
• What’s with the boring name? It’s my hometown, it’s easy to remember, and it can’t possibly offend anyone like “fubu” did.
• What’s the story with IoC integration? Uh, yeah, it’s StructureMap 4.5 only just at the moment, but that’s a much longer discussion for another blog post. A huge design goal of Jasper is to try to minimize the usage of an IoC container outside of the initial bootstrapping and application shutdown, so I’m not sure you’re going to care all that much.

What’s next?

I’m actually slowing down on new development on Jasper for awhile, but I’ll be flooding the interwebs with blog posts on Jasper while I also plug holes in the documentation. The next big thing at work is to start the trial conversion of one of our applications to Jasper. For longer term items in our backlog, just see the GitHub issue list. The next development task is probably going to have to be replicating the integration we’ve done with Postgresql and Marten for Sql Server.

RabbitMQ, Kafka, and Azure Service Bus integrations will follow later this year.

Long story short, several of my colleagues and I are building a new framework for managing asynchronous messaging between .Net services with the codename “Jasper” as a modernized replacement for our existing FubuMVC based messaging infrastructure. Once I get a good couple weeks of downtime during the holidays, I’ll be making the first big public alpha nuget of Jasper and start blogging up a storm about the project, but for right now, here’s this post about Jasper’s intended dynamic subscription model.

As part of our larger effort at work to move toward a microservices architecture, some of us did a big internal presentation last week about the progress so far in our new messaging infrastructure we intend to use next year as we transition to Netstandard2 and all the modern .Net stuff. I went over my time slot before we could talk about our proposal for how we plan to handle publish/subscribe messaging and service discovery. I promised this post in the hopes of getting some feedback.

The Basic Architecture

Inside of our applications, when we need to publish or send a message to other systems, we would use some code like this:

public Task SendMessage(IServiceBus bus)
{
    // In this case, we're sending an "InvoiceCreated"
    // message
    var @event = new InvoiceCreated
    {
        Time = DateTime.UtcNow,
        Purchaser = "Guy Fieri",
        Amount = 112.34,
        Item = "Cookbook"
    };

    // Mandatory that there is subscribers for this message
    return bus.Send(@event);

    // or send the message to any subscribers for this type
    // of message, but don't enforce the existence of any
    // subscribers
    return bus.Publish(@event);
    
}

The system publishing messages itself doesn’t need to know or even how to send that message to whatever the downstream system is. The infrastructure code underneath bus.Send() knows how to look up any registered subscribers for the “InvoiceCreated” event message in some kind of subscription storage and route the message accordingly.

The basic architecture is shown below:

Just to make this clear, there’s no technical reason why the “subscription storage” has to be a shared resource — and therefore a single point of failure — between the systems.

Now that we’ve got the barebones basics, here are the underlying problems we’re trying to solve to make that diagram above work in real life.

The Problem Statement

Consider a fairly large scale technical ecosystem composed of many services that need to work together by exchanging messages in an asynchronous manner. You’ve got a couple challenges to consider:

• How do the various applications “know” where and how to send or publish messages?
• How do you account for the potential change in message payloads or representations between systems?
• How could you create a living document that accurately describes how information flows between the systems?
• How can you add new systems that need to publish or receive messages without having to do intrusive work on the existing systems to accomodate the new system?
• How might you detect mismatches in capabilities between all the systems without having to just let things blow up in production?

Before I lay out our working theory about how we’ll do all of the above in our development next year, let’s talk about the downsides of doing all of that very badly. When I was still wet behind the ears as a developer, I worked at a very large manufacturing company (one of the “most admired” companies in the US at the time) that had an absolutely wretched “n-squared” problem where integration between lots of applications was done in an ad hoc manner with more or less hard coded, one off mechanisms between applications. Every time we needed a new integration, we had to effectively do all new work and break into all of the applications involved in the new data exchange.

I survived that experience with plenty of scars and I’m sure many of you have similar experiences. To solve this problem going forward, my shop has come up with the “dynamic subscription” model (the docs in that link are a bit out of date) in our forthcoming “Jasper” messaging framework.

Our Proposed Goals and Approach

A lot of this is already built out today, but it’s not in production yet and now’s a perfect time for feedback (hint, hint colleagues of mine). The primary goals in the Jasper approach is to:

• Eliminate any need for a central broker or any other kind of single point of failure
• Reduce direct coupling and between services
• Make it easy to update, browse, or delete subscriptions
• Provide tooling to validate the subscriptions across services
• Allow developers to quickly visualize how messages flow in our ecosystem between senders and receivers

Now, to put this into action. First, each application should declare the messages it needs to subscribe to with code like this:

    public class MyAppRegistry : JasperRegistry
    {
        public MyAppRegistry()
        {
            // Override where you want the incoming messages
            // to be sent.
            Subscribe.At("tcp://server1:2222");

            // Declare which messages this system wants to 
            // receive
            Subscribe.To();
            Subscribe.To();
        }
    }

Note: the “JasperRegistry” type fulfills the same role for configuring a Jasper application as the WebHostBuilder and Startup classes do in ASP.Net Core applications.

When the application configured by the “MyAppRegistry” shown above is bootstrapped, it calculates its subscription requirements that include:

• The logical name of the message type. By default this is derived from the .Net type, but doesn’t have to be. We use the logical name to avoid forcing you to share an assembly with the DTO message types
• All of the representations of the message type that this application understands and can accept. This is done to enable version messaging between our applications and to enable alternative serialization or even custom reading/writing strategies later
• The server address where the upstream applications should send the messages. We’re envisioning that this address will be the load balancer address when we’re hosting on premises in a single data center, or left blank for when we get to jump to cloud hosting when we’ll do some additional work to figure out the network address of the subscriber that’s most appropriate within the data center where the sender is hosted.

At deployment time, whenever a service is going to be updated, our theory is that you’ll have a step in your deployment process that will publish the subscription requirements to the proper subscription storage. If you’re using the built in command line support, and your Jasper application compiles to an executable called “MyApp.exe,” you could use this command line signature to publish subscriptions:

MyApp.exe subscriptions publish

At this point, we’re working under the assumption that we’ll be primarily using Consul as our subscription storage mechanism, but we also have a Postgresql-backed option as well. We think that Consul is a good fit here because of the way that it won’t create a single point of failure while also allowing us to replicate the subscription information between nodes through its own gossip protocol.

Validating Subscriptions

To take this capability farther, Jasper will allow you to declare what messages are published by a system like so:

    public class MyAppRegistry : JasperRegistry
    {
        public MyAppRegistry()
        {
            Publish.Message();
            Publish.Message();
            Publish.Message();
        }
    }

Note: You can also use an attribute directly on the published message types if you prefer, or use a convention for the braver.

When a Jasper application starts up, it combines the declaration of published message types with the known representations or message versions found in the system, and combines that information with the subscription requirements into what Jasper calls the “ServiceCapabilities” model (think of this as Swagger for Jasper messaging, or OpenAPI just in case Darrel Miller ever reads this;)).

Again, if your Jasper application compiles through dotnet publish to a file called “MyApp.exe”, you’ll get a couple more command line functions. First, to dump a JSON representation of the service to a file system folder, you can do this:

MyApp.exe subscriptions export --directory ~/subscriptions

My thinking here was that you could have a Git repository where all the services export their service capabilities at deployment time, because, that would enable you to use this command later:

MyApp.exe subscriptions validate --file subscription-report.json

The command above would read in all the service capability files in that directory, and analyze all the known message publishing and subscriptions to create a report with:

1. All the valid message routes from sender to receiver by message type, the address of the receiver, and the representation or version of the message
2. Any message types that are subscribed to, but not published by any service
3. Message types that are published by one or more services, but not subscribed to by any other system
4. Invalid message routing through mismatches in either accepted or published versions or transport mismatches (like if the sender can send messages only through TCP, but the receiver can only receive via HTTP)

Future Work

I thought we were basically done with this feature, but it’s not in production yet and we did come up with some additional items or changes before we go live:

• Build a subscription control panel that’ll be a web front end that allows you to analyze or even edit subscriptions in the subscription storage
• Publish the full service capabilities to the subscription storage (we only publish the subscriptions today)
• Get a bit more intelligent with Consul and how we would use message routing if running nodes of the named services are hosted in different data centers
• Create the idea of message “ownership,” as in “only this system should be processing this command message type”
• Some kind of cache busting in the running Jasper nodes to refresh the subscription information in memory whenever the subscription storage changes

I’ve been kicking around the idea for a possible resurrection of FubuMVC as a mostly new framework with the codename “Jasper”  for several years with some of my colleagues. This year myself and several members of our architecture team at work have started making that a reality as the centerpiece of our longer term microservices strategy.

In the end, Jasper will be a lightweight service bus for asynchronous messaging, a high performance alternative to MVC for HTTP API’s, and a substitute for MediatR inside of ASP.Net Core applications (those three usages share much more infrastructure code than you might imagine and the whole thing is still going to be much, much smaller than FubuMVC was at the end). For the moment, we’re almost entirely focused on the messaging functionality.

I haven’t kicked out an up to date Nuget yet, but there’s quite a bit of documentation and I’m just hoping to get some feedback out of that right now. If you’re at all interested in Jasper, feel free to raise GitHub issues or join our Gitter room.

The only thing I’m trying to accomplish in this post is to get a sanity check from other folks on whether or not the bootstrapping looks usable.

Getting Started

This is taken directly from the getting started documentation.

dotnet new console -n MyApp

public class MyAppRegistry : JasperRegistry
{
    public MyAppRegistry()
    {
        // Configure or select options in this constructor function
    }
}

using Jasper.CommandLine;

namespace MyApp
{
    class Program
    {
        static int Main(string[] args)
        {
            // This bootstraps and runs the Jasper
            // application as defined by MyAppRegistry
            // until the executable is stopped
            return JasperAgent.Run<MyAppRegistry>(args);
        }
    }
}

public class MyAppRegistry : JasperRegistry
{
    public MyAppRegistry()
    {
        Http.UseKestrel().UseUrls("http://localhost:3001");
        Transports.Lightweight.ListenOnPort(2222);
    }
}

Hosting environment: Production
Content root path: /Users/jeremill/code/jasper/src/MyApp/bin/Debug/netcoreapp1.1
Listening for messages at loopback://delayed/
Listening for messages at jasper://localhost:2333/replies
Listening for messages at jasper://localhost:2222/incoming
Now listening on: http://localhost:3001
Application started. Press Ctrl+C to shut down.

var host = new WebHostBuilder()
    .UseKestrel()
    .UseJasper<ServiceBusApp>()
    .Build();

host.Run();

public class HomeEndpoint
{
    public string Get()
    {
        return "Hello, world.";
    }
}

public class InvoiceCreated
{
    public Guid InvoiceId { get; set; }
}

public class InvoiceHandler
{
    public void Handle(InvoiceCreated created)
    {
        // do something here with the created variable...
    }
}