Most applications doing automated outbound messaging are cluttered with overhead that does not focus on the actual task of getting a message sent. Over the last few months I’ve developed a software for weweave that we’ve named “Tubewarder” (named for tube, warder, and to forward – what a pun!). Tubewarder is a new approach for dealing with automated outbound messaging, especially messages generated by applications. It acts as a outbound message gateway hub for all the different templates and channels (like email, sms, web services, etc.) modern applications require today. In this article, I’d like to introduce the software by outlining problems of traditional approaches and by showing you how Tubewarder aims to eliminate such issues.
If you have developed a (web) application that targets consumers, you’ve probably been in the situation that you needed to send messages to your users from within the application. Be it a Double Opt In confirmation plain text email, a notification sms, a periodically generated report, or an HTML newsletter: Whenever it comes to automated outbound messaging to consumers, you have to deal with different kinds of media, like email, sms, WhatsApp, or Facebook. All the types of messages you send are probably based on some form of template, meaning that you have a structured scaffold of all your messages containing placeholders, loops, if/then/else conditions and so on. The templates probably live on your application’s server, so you have probably faced the challenge that your non-technical staff (the functional product owners of your application) requested to be able to apply ad-hoc changes to the templates, without the need for re-testing your software, application deployments and such annoying things. Your legal department additionally wanted you to archive all the outgoing messages for legal purposes. Last but not least, the systems your application is communicating with for sending texts/mails/… must be reliable, so it must be able to deal with technical difficulties such as temporarily unavailable mail servers.
In the end, your applications probably look a bit like in the the following graphic: All that messaging, templating, error handling, archiving, access management, and logging code lives within all of your applications, whilst all applications establish connections to all systems doing the actual work of delivery (mail servers, sms gateways and so on).
Tubewarder aims to solve these issues by moving that cluttered code into one central place: The Tubewarder server. It acts as an outbound message gateway and comes with a handy web interface for all relevant administrative tasks.
As a system administrator, you define the output channels that can be used to transport messages. For example, you can set up a channel to send emails via your organisation’s SMTP server. Or you can set up a channel for sending text messages to mobile phones using a web service.
As an application developer, you define the templates your application needs and assign them to the available channels. You can assign one template to multiple channels, each with a different form (for example, you can have different forms of a new-user-welcome-message for email and text message output). Tubewarder uses the popular Apache FreeMarker Template template engine. This allows for placeholders, complex control structures, and more.
Next, you connect your application to Tubewarder using a REST service or a SOAP web service (both accessible via the HTTP protocol).
As a member of the non-technical staff, you can manage your templates yourself using the integrated web interface. This allows for changing templates with low effort and without any application deployment.
Tubewarder cares for error handling by retrying to send messages after a certain period if technical difficulties occur, and archives outgoing messages for legal and technical purposes.
Thus, all the overhead that cluttered your application moves into a central place and your infrastructure looks as clean as shown below.
Tubewarder is written in Java and based on Swarm, the micro-service self-contained version of the WildFly application server. You can just start it from scratch using an embedded H2 database, or MySQL/PostgreSQL if you prefer those. Or you can make life even easier by using a pre-built Docker image.
I’d be happy to hear what you think about that approach. Just share your thoughts in the comments and tell me what’s missing.