iMatix Corporation

Overview of RestMS

 Pieter Hintjens, CEO of iMatix Corporation, introduces RestMS, the RESTful Messaging Service, in this article. A new standard for real web messaging called RestMS provides straightforward, scalable, and secure data transfer over normal HTTP.

Why is messaging necessary?

 Messaging, often known as “messaging middleware” or “message-oriented middleware,” joins software programmes that are written in different languages and execute on different platforms via a network.

 The three key related causes for the popularity of messaging are as follows:

 Applications that can reach more users are more valuable. It used to be challenging enough to create software that could run alone. ‘Many users’ these days refers to Internet size. Having a lot of users on a website is one thing. Connecting that website to dozens or even hundreds of other applications can be far more profitable and enable quick and accurate information exchange, trading, and sale.

 In the past, if you modified a single line of code, you had to rebuild the entire system. That ceases to make sense when applications are spread across numerous teams and when changes can be made to any component of the entire system at any time, anywhere. Change is made inexpensively by using loose connections between the elements. No component has a great deal of information about any other; all they know is how to exchange data and what it signifies. This is automated and trustworthy because to messaging.

 The cost of attempting to specify the behaviour of each of the numerous software programmes that collaborate in a sizable network is high. The APIs, which serve as their interfaces, can be defined at a considerably lower cost and with more flexibility. An API called messaging can be extended over a network, where even the physical locations of the various components are dynamic and subject to change at any time.

 In order to design much larger empires, where many of the components are produced by your suppliers, customers, or even users, you need a solid messaging system. It enables you to start small and expand without running the significant risk of having to alter core mechanics in the middle of the game. Additionally, it helps you save money by directing your investment towards the areas where it will be most beneficial.

 The majority of Internet APIs are quite simple: an application asks some data, and the server either provides the requested data or an error in response. Although it’s simple to comprehend and programme, this is how a human would operate: by clicking a link, refreshing an email, and so on. Because the client programme must decide between polling more frequently (and squandering bandwidth) and polling less frequently (and receiving data either late or not at all), it is an unpleasant method of data transmission between apps.

 Most web developers will consider it typical that client applications come begging for data because they are accustomed to seeing their application as the centre of the universe. But it turns out that there is a more effective communications paradigm. We define service messages that are carried by generic interfaces rather than creating specific service interfaces. We build data flows that may be accessed in a generic way rather than polling a service for data. We develop a loosely connected abstract architecture instead of a distributed architecture where services can come and go as needed.

 This change requires us to shift some of the work away from the application and towards a central broker, at least in part.

 The idiomatic expression “feed” works well to describe these general data flows. Consider a feed that lists all available apartments, for illustration. I post an announcement on that feed if I want to rent out my unit. I subscribe to the feed if I wish to look for a flat.

 Streams of data known as feeds are dynamic, ever-evolving rivers that can carry anywhere from a few messages per second to millions. To efficiently obtain the data we require, new paradigms are required. Accessing a feed is more like turning a portion of the river into an irrigation channel if web surfing is putting a fishing line into the river.

 An application-centric approach of messaging is less effective than one that is feed-centric. Without respect to the actual applications involved, we may concentrate on the semantics of publishing, routing, queuing, and delivering data and develop simple and general APIs to do this.

 It is not only more effective, but also considerably more scalable. As soon as they are accessible, messages are sent exactly and quickly. There is no polling, no bandwidth wastage, and no delay wastage. Whole new markets become available to a company that sells time-sensitive information.

 Being very clear about what a messaging product should be and perform is important because numerous products use the term “messaging”:

 Regardless of the programming language or operating system that an application uses, connecting to it should be simple. Messaging that is solely compatible with one programming language or operating system is not only ineffective, but also a trap.

 It ought to be based on a general framework for mining and publishing to feeds, sometimes known as “queues.” Whatever the exact model, it must be asynchronous, like email, to allow senders and recipients to each operate at their own pace.

 It should be data-agnostic so that it can be applied to any situation. Messages should ideally be blobs of any size, from zero to extremely large, with envelopes including routing information and addressing.

 Early filtering should be used, which passes subscriptions as close as feasible to the publisher and pushes just the information that is required downstream. This lessens network traffic, which boosts efficiency and reduces costs.

 A good application should never be constrained by the capabilities of the messaging system since it should be scalable to high numbers of clients and big amounts of traffic.

 There are three fundamental messaging patterns:

 Individual yell, similar to an email. The Housecat pattern is what we refer to as.

shouting one to many, similar to an email list. It is known as the Parrot pattern.

spread from one to many, similar to a printer queue. This is the so-called Wolfpack pattern.