Please find the answers to this question in the WAMP Compliance section.
This is a difficult question to answer as it all depends on your use cases, quality attributes requirements and your architecture design i.e. the way you will solve the trade-offs between all those quality attribute requirements.
In general, WAMP differs from other messaging platforms in that it natively (and by design) provides an implementation of routed Remote Procedure Calls (RPC) together with Publish & Subscribe.
As is name implies, Publish & Subscribe offers at most once semantics a.k.a fire-and-forget, whereas other messaging platforms provide stronger message delivery guarantees e.g. at least once and exactly once semantics.
Being an extensible protocol means we can extend the message delivery guarantees and we have plans to do so e.g. at least once.
For a further comparison with other products and technologies we invite you to review the WAMP Compared article in the protocol specification website.
Bondy provides a unique sets of features which sets it apart from other WAMP router implementations in terms of scalability, reliability, high-performance and operational simplicity.
Read more about this differences in What is Bondy section.
Bondy is implemented in Erlang, a wonderful programming language and platform for concurrent and (soft) real-time applications.
Because we need Bondy to be scaleable and always-on in the case of inter- and/or intra-datacentre connectivity disruptions.
We think it is really stupid to design super scaleable and fault-tolerant backend platforms using NoSQL databases, eventually consistency and more sophisticated techniques like CRDTs only to then define an message routing and API Gateway that relies on strong consistency for configuration and/or cluster state data replication e.g. SQL database. All the hard work you've done in the backend to provide an always-on system is then hampered by an entry point which is not!
No, Bondy does not depend on any external database server. Every Bondy node embeds a database which at the moment is based on Basho's fork of LevelDB but we plan to support and/or migrate to other backends in the future.
Because we want to provide an always on platform which is also easy to manage.
Most data entities in Bondy are resident in memory to reduce latency e.g. routing tables, authorization checks, access tokens. Using an external database would imply not only the possibility of losing the connection to it and most probably the need to instrument a caching layer.
The answer is "not now" for some data entities while "not ever" for some others.
For example, some data entities could be managed externally and we have plans to enable that capability through plugins e.g. managing user credentials in an external LDAP or database. But for some others it would be in detriment of Bondy's capabilities and the architectural tradeoffs that justify its current design.
Please refer to Why does Bondy use its own embedded database?.
Leapsight Bondy is licensed under the Apache License 2.0, review a copy of the license here.
You can find the answer in the Documentation License page.
Yes, please contact us to understand the service level options.