WAMP use cases

236 zobrazení
Preskočiť na prvú neprečítanú správu

Konstantin Burkalev

neprečítané,
16. 1. 2017, 11:36:0816. 1. 2017
komu: WAMP
Hi all, WAMP implementators and users! 

I'm planning to submit a talk about WAMP to one of our developer conferences in late spring or summer. 
And i want to ask you to spend a few minutes and write here your thoughts about WAMP:
  • Why 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?

Of course, i have my own thoughts about this but i want to talk about different WAMP use cases. To provide developers, who don't know about WAMP yet or just have heard that word, with information not about WAMP protocol architecture itself but rather with real world examples and possible use cases.

It would be great, if you post you thoughts, links to applications, that use WAMP under the hood or some project schemas, that you are developing using WAMP.

Thanks a lot!

Jordi Mariné Fort

neprečítané,
16. 1. 2017, 15:34:3616. 1. 2017
komu: WAMP
Hi Konstantin,

I used WAMP for a web game to play draughts and chess between online users.
More information at:
https://wgs-jmarine.rhcloud.com/webgl8x8boardgames/
https://github.com/jmarine/wgs

Previously (to the websocket spec), i had used a message-oriented middleware with XMPP and Bidirectional-streams Over Synchronous HTTP protocols, to send messages to group members  (comparable to pub/sub in WAMP). But initial connection/authentication and general response time was too slow (it required XML processing, and it involved too many HTTP connection establishments, because HTTP keep-alive connections where considered too expensive for XMPP/BOSH servers and their use was limited).

So, I wanted to upgrade to websockets communications. Although, i waited some time for the XMPP over websockets protocol specification, the popular XMPP servers weren't adopting the early drafts (and I couldn't easily test the possible improvements). Also, i wished to use the same websocket connection to speed up RPCs (to persist game state, calculate rankings, etc.).

Then, i learned about WAMP (v1), that used JSON messages (instead of XML), provided pub/sub and RPC features, and used a websocket subprotocol that was easy to understand/implement. And i was really happy with the results. So much, that I've also adopted new WAMP v2 spec.

Finally, I think WAMP over websockets was faster/better than classic AJAX communications over HTTP/1.x (but unfortunately not so popular).
And I wish WAMP could be also used in the future over new HTTP/2 protocol (that will also allow multiplexing requests/responses).
But, i think HTTP/2 doesn't support websockets. So, WAMP subscriptions may have to be mapped as HTTP/2 SSE, publications/RPC messages as regular HTTP/2 requests, etc.
(but this is another topic to discuss).


Regards.

Konstantin Burkalev

neprečítané,
17. 1. 2017, 11:43:5717. 1. 2017
komu: WAMP
Hi, Jordi! Thanks for your answer! 

btw, i think http2 is pretty young, and we still may have a some kind of websockets on top of http2.

David Ford

neprečítané,
18. 1. 2017, 12:48:0918. 1. 2017
komu: wam...@googlegroups.com
WAMP (crossbar io) package makes everything semantically the same with very identical looking function and method calls regardless of platform or language. it makes development very fast and easy. having everything implemented under the hood with intelligent design means it's by far and large, a magic shovel that takes my block of data and ferries it exactly where i want it to go and i don't have to worry about encapsulation, encoding, decoding, et cetera.

i've taken all my disparate methods of not-so-unified message and content dispatch systems systems and unified them into a streamlined process which uses encrypted routed courier and delivery.

ButterflyDNS is a package i'm writing that is an html5 driven UI for nearly all aspects of a DNS management system, structured on top of WAMP. i also use WAMP for centralized message notification systems from all my servers.

-d

--
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.

Konstantin Burkalev

neprečítané,
18. 1. 2017, 15:37:1318. 1. 2017
komu: WAMP
Thanks, David! Great thoughts!

Johan 't Hart

neprečítané,
25. 1. 2017, 18:56:0825. 1. 2017
komu: WAMP

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,

Johan




Konstantin Burkalev

neprečítané,
26. 1. 2017, 8:20:5626. 1. 2017
komu: WAMP
Hi, Johan! 

Thank you for such a detailed response! Great to hear about your thoughts and examples!

Konstantin Burkalev

neprečítané,
12. 10. 2017, 11:10:4012. 10. 2017
komu: WAMP
Hi all!

Just wanna say, that i’m planing to speak at conference “Highload++ 2017” (http://highload.co/, http://www.highload.ru/) in November 
It’s one of the biggest conferences in Russia. This time there are 153 presentations, 10 simultaneous streams, 15 sections, over 2000 attendees :)
And my talk proposal “WAMP-proto as a basis for composite SOA applications and its implementation in Lua” was accepted! Yahoo!

Now it’s time to prepare. I have 45 min available for my talk. 

I want to talk about WAMP protocol itself, its conceptions, core features, how it works.
But first of all, i need to setup a problem, that can be resolved by WAMP. May be you have some thoughts about this? Why have you chosen WAMP

Than i plan to show some use cases. I have some my own use cases, also, thanks to you, provided more use cases.
May be you know about some new projects, using WAMP? 
Of course there is no need in names, just type of projects, systems and WAMP place it there architecture. Will be great to hear!

It will be cool to show real projects (info, business field, may be some screenshots, etc) during presentation.

This message is a kind of repetition of already asked questions, but that was long ago and perhaps you have already started interesting new projects using WAMP, and also we have new members in our community! :)

Thanks to all of you!

Andrew Gillis

neprečítané,
13. 10. 2017, 13:06:2513. 10. 2017
komu: WAMP
Why do you choose WAMP over other related technologies?

WAMP provides the two message patterns that basically all distributed applications converge on (RPC and Pub/Sub), with router to decouple consumers and receivers.  Another reason for choosing WAMP is that it provides a degree of standardization which allows interoperation with other parties without having to provide software. 
 
What problem have you solved with the help of WAMP?
Needed back end services to to notify web applications of updates without having to poll. Also used for long-duration remote procedure calls that may otherwise cause gateway timeouts, or require polling on temporary resource.  Have also used WAMP as a replacement for XMPP, which greatly simplified the RPC implementation and the messaging in general.
 
Your real world projects, using WAMP? What kind of communication do you handle with WAMP?
RPC from web apps to services.  Asynchronous notifications from services to web apps.  Requests and notifications between services.
 
Your wildest thoughts about where and how to apply WAMP?
While there are many communications packages used in IoT, I would like to see WAMP as a standard component of any IoT stack.  WAMP should replace most if not all things that use XMPP and XMLRPC.  I would like to see WAMP used as standard for instant messaging and presence services, which could greatly enhance interoperability.

Konstantin Burkalev

neprečítané,
23. 10. 2017, 10:42:4623. 10. 2017
komu: WAMP
Thanks Andrew for sharing your thoughts! 

Konstantin Burkalev

neprečítané,
13. 12. 2017, 4:32:0813. 12. 2017
komu: WAMP
Hi all! 

I want to thank you again for your thoughts. 
I spoke at the Highload++ conference about WAMP protocol and its Lua implementations. It seems the talk has attracted interest and participants asked questions after the talk.

Talk is in russian, but i've translated slides to english, so if you are interested, have a look. Feel free to ask me any questions!
I think Alex or Tobias can help with that! :)

P.S. If you wanna ask, why slides are posted both to slideshare and speakerdeck — the answer is, thats because slideshare is banned somehow in Russia...

Darren Smith

neprečítané,
13. 12. 2017, 17:24:0613. 12. 2017
komu: WAMP
Hi Konstantin,

Just wondering if you ever considered Google RPC, and if so, how you thought to compared to WAMP.

Johan 't Hart

neprečítané,
13. 12. 2017, 18:39:0113. 12. 2017
komu: WAMP
Hi Darren,

Maybe I can answer this.

gRPC is promising. But

* As far as I can tell, there is no browser support yet. Although I think it is quite usable now via this project: https://github.com/improbable-eng/grpc-web
* WAMP is a higher-level protocol. When gRPC is supported, WAMP can be implemented upon it, instead of upon WebSocket
* WAMP supports service decoupling. With gRPC the client must know to which service (url) it should send the request. With WAMP the router sends the request to whoever registered it.
* I think gRPC doesn't support pubsub

These are my thoughts about it.

At our company we use WAMP to be able to move stuff to the cloud. With it we are able to connect legacy apps to new apps, because of the multiple language support and because of its architecture. And also very important is to be able to write realtime reactive (server event driven) web applications with it.

Greetings
Johan

Konstantin Burkalev

neprečítané,
19. 1. 2018, 8:03:2419. 1. 2018
komu: WAMP
Hi!

четверг, 14 декабря 2017 г., 1:24:06 UTC+3 пользователь Darren Smith написал:
Hi Konstantin,

Just wondering if you ever considered Google RPC, and if so, how you thought to compared to WAMP.

I'm not a gRPC guru. I think, Johan gave a more descriptive answer. Totally agree.

Konstantin Burkalev

neprečítané,
19. 1. 2018, 8:06:4719. 1. 2018
komu: WAMP
I think Tobias and Alexander are far away from our talks...
But may be they will have time to update news on wamp-proto.org site with my slides :)

среда, 13 декабря 2017 г., 12:32:08 UTC+3 пользователь Konstantin Burkalev написал:

Emile Cormier

neprečítané,
7. 2. 2018, 1:37:247. 2. 2018
komu: WAMP
Sorry for not responding sooner.

We are using WAMP for developing a headless building automation controller that provides a web UI. The web clients use RPCs to retrieve information and to perform actions. They use use pub/sub for monitoring the status of the building.

WAMP allowed us to completely decouple backend code written in C++ from frontend code written in Javascript. We don't have to wait for UIs to be implemented to test backend features. We use a rudimentary C++ command interpretor to issues RPCs to our backend for testing and early prototyping purposes.

I wish WAMP would replace the clunky BACnet protocol currently used in building automation.

Konstantin Burkalev

neprečítané,
7. 2. 2018, 4:23:347. 2. 2018
komu: WAMP
Thanks for you case, Emile!
Odpovedať všetkým
Odpovedať autorovi
Poslať ďalej
0 nových správ