--
You received this message because you are subscribed to the Google Groups "WAMP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wampws+un...@googlegroups.com.
To post to this group, send email to wam...@googlegroups.com.
Visit this group at https://groups.google.com/group/wampws.
To view this discussion on the web visit https://groups.google.com/d/msgid/wampws/ac87442d-39bf-41f1-a0d9-af5fc32b6450%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi Konstantin,
At our company we want to re-implement our main client GUI application which is written in C++ using MFC, which has grown into a horrible unmaintainable mess. For the new GUI we selected WPF as the GUI platform of choice, and we also plan to create a lite web-application.
The server and the old client software both were written in C++, so we used a simple proprietary binary protocol for communication. Because the new client software was not C++, we needed a new cross platform responsive full duplex (2-way RPC) communication protocol. And we didn't want it to be proprietary anymore, and it should also be web-friendly.
We considered SOAP because of internal experience with it, but SOAP is only one-way RPC (for 2-way or pubsub, you need to register callback URLS or some kind of SOAP-long-poll). Also SOAP is bloated, doesn't perform well, and isn't that responsive, with high loads of traffic.
We also considered WCF, the .net interprocess communication protocol. It is fairly easy to use in C#, but turned out not to be multiplatform. It's .net only. Also it is Microsoft proprietary and not standard.
I figured we'd not be the only one looking for a protocol with these specs, so I looked for what is commonly used nowadays. To my surprise, people tend to go for REST as their protocol of choice. REST may be less bloated than SOAP because of the use of JSON, for the rest it has the same shortcomings as SOAP. It is one-way RPC, and one uses long-poll or callback URL's to simulate pubsub. Also it is still bloated because every request needs a complete HTTP header.
I knew about websockets which partly fulfilled our specs because it is web-friendly, not bloated and responsive. We can implement full-duplex RPC on top of it if we want to. The problem is that we needed to design a protocol on it which will then again become proprietary. So I looked whether RPC was already a standard on top of websockets.
Finally google was merciful and popped up WAMP on me. The more I read about it, the more I figured that this is exactly what we need. And not only we, but I'd say a lot of folks who're currently using REST. It fulfilled all our specs and more! It is responsive, web-friendly, multi-platform, not bloated, 2-way (and more!) RPC, pubsub and an open standard. Why such a standard hasn't become popular nowadays still boggles me.
Furthermore there already were implementations for every platform we need: C++, C# and javascript.
It even opened up a door to a new usecase. We also plan to transform our server application into microservices. This would usually require one to create some kind of routing server that knows where all services are reachable. Also services need to communicate to each other. WAMP makes this problem far less painful because it has routing built in. A client application should not have to worry who executes an RPC or who generates an event. Also the server should not have to worry who is calling an RPC and who needs to receive an event. WAMP takes this problem away because it takes care of all the routing in a very simple and straightforward way.
Yes, WAMP has some shortcomings: The router is a single point of failure, all data is sent over the network twice, there is no standard for a contract, and WAMP isn't a complete standard yet. But the benefits far outweigh the downsides. Also I am confident that most downsides will be addressed, because I believe (and hope) WAMP will be discovered by tons of developers soon enough :)
OK, this has become a little long :) I hope it is still usable somehow.
Greetings,
JohanWhy do you choose WAMP over other related technologies?
What problem have you solved with the help of WAMP?
Your real world projects, using WAMP? What kind of communication do you handle with WAMP?
Your wildest thoughts about where and how to apply WAMP?
Hi Konstantin,Just wondering if you ever considered Google RPC, and if so, how you thought to compared to WAMP.