Who pays the bill?
While presenting the concept of Exalate to a group of venture capitalists for the first time, we came across a rather unexpected problem - namely the issue of who foots the bill for synchronization
Leaving aside any free solutions (as if they have ever existed), there are two ways of resolving the payment - either one party pays or both of them have to pay.
The second way might lead to some awkward discussions centred around the cost. After all, both parties have to procure a licence and they have to get it through their accounting departments. And don't forget that agreeing about the pricing (and how to split it), usually takes loads of time.
One might imagine that both parties agree to make only one of them pay for the licences on either end. Yet, this may lead to awkward questions, like 'why should we pay for enhancing the environment of the other party'. Just as if you bought a telephone plan for your neighbours, so that they could be calling you whenever they need it.
Actually, the venture capitalists were completely right. It might take days of hard effort to persuade both sides into paying.
There is also another approach, in which only one end pays for the communication. This is similar to phone calls - it is usually the caller who foots the bill for the talk (unless it is some exceptional situation, you would never expect the receiver to pay for it, would you?)
As a supplier, you are obviously looking to increase your customer service levels, so you link your issue tracker with the ones used by customers. The single-sided payment model, where only one side pays for the synchronization cost, allows you to keep a close eye on the budget and money spent on this technology. Plus to that, the customers won't have to bother about contacting the purchasing department at their company.
How does Exalate implement single sided connection based subscriptions
The payment model is an integral part of the agreement between the two synchronization nodes.
Sync can happen, provided that one of the parties decides to take care of the payment.
This implementation allows us to implement the single-sided, connection-based subscriptions.
Only one side pays for the connection.
The unit for charging is connection-based. The link between two trackers is considered as a connection, regardless of the number of people actively using the tracker on either end.