Bidirectional asynchronous data exchange in web applications
Experts call RIA one of the main features of the modern web, which is often decoded as a trend, when web applications are closer in functionality to desktop applications. However, this approximation is very conditional. The vast majority of "enriched" web applications are still built on the model of "request-response". Those. Client-side events can be reflected on the server side, not the other way around. In order to implement such a banal thing as a chat, you have to resort to sophisticated tricks. Thanks to Alex Russell from Dojo, we even have a name for this technique - Comet.
According to cometdaily.com, there are several solutions to emulate bidirectional data exchange between the client and the server:
In addition, you can use Flash objects or Java applets. And for completeness, we can mention such an ancient technique as Forever GIF.
From myself I would add a couple of high-level solutions:
')
Anyway, any of these approaches is in one way or another a hack, when I would like to use a native solution. The guys from the HTML5 working group obviously understand this situation well, and therefore a standard such as Web Sockets is included in the standard. Its description sounds like a panacea: tolerant to firewalls and routers, allows cross-domain communication, integrates with existing HTTP load balancers, allows binary data exchange, works in secure connections, etc. For all that, the Web Sockets API is very simple (see also habrahabr.ru/blogs/webdev/79038 ).
Hooray, thanks, everyone is free? And no. Currently, Web Sockets is supported only in the Chrome development version (starting with 4.0.249.0 - www.chromium.org/getting-involved/dev-channel ) and Firefox 3.7 support is promised. What to do now? Obviously, you need a facade on the client side, which in the presence of the Web Socket uses its “native” API, in the absence of a workaround. Such a solution could be Kaazing Websocket Gateway ( kaazing.com/download ), if it was not distributed for money, but out of kindness of heart. You could use Orbited ( orbited.org ) in conjunction with io.js ( github.com/mcarter/js.io ) if you absolutely need besides Web Sockets access to amqp, imap, irc, ldap, smtp, ssh, stomp, telnet, xmpp and Python on the server proxying any communication. My choice: WebSocket.js ( github.com/gimite/web-socket-js ). Tiny js library and bridge as a flash object.
Now we only need the WebSocket server and, in our case (the backend is written in Java), Jetty is perfectly suited for this, starting with version 7.0.1 (is it currently at almost stable status, but when did that scare us?). If your server applications are written in php, you can try using phpwebsocket ( code.google.com/p/phpwebsocket ) or phpwebsockets ( code.google.com/p/phpwebsockets ). But at your own peril and risk as both decisions are experimental.
UPDATED: Example of chat implementation on phpDaemon habrahabr.ru/blogs/php/79377
I'm sure the installation of Jetty will not cause you any questions, but you may encounter a problem in WebSocket.js due to the so-called cross-domain policy from Adobe. The flash object must be allowed to open a socket on the server. The most reliable solution is to place the micro server on port 843, which responds to the request for policies with the appropriate XML, as described in www.lightsphere.com/dev/articles/flash_socket_policy.html . The article even presents the simplest XML server on Perl. However, I didn’t like it very much, and I wrote my socket server based on the example from devzone.zend.com/article/1086 .
Now that we have Web Sockets, we can write web applications that can instantly respond to server events. It can be a notification system (notificatior) like on Facebook, it can be services for user interaction in the style of Google Waves, it can be real-time monitors (for example, online users) or integration with third-party event sources, such as incoming SMS or event in the desktop application. As we expect a wide variety of events, from different sources directed to different clients, we need a reliable system for managing message flows on the server. There is a simple but elegant STOMP protocol ( stomp.codehaus.org ). The API has only a few commands (SEND, SUBSCRIBE, UNSUBSCRIBE, BEGIN, COMMIT, ABORT, ACK, DISCONNECT) through which STOMP clients and STOMP brokers communicate. In particular, Zend Queue ( framework.zend.com/manual/en/zend.queue.stomp.html ) has an STOMP adapter. A message broker can be implemented using Apache ActiveMQ ( activemq.apache.org ) or RabbitMQ ( www.rabbitmq.com ).
However, if you are very serious, you should pay attention to the more developed and flexible ( habrahabr.ru/blogs/webdev/62502 ) AMQP protocol ( www.amqp.org ).
Jetty, being a JBOSS container, serves Web Sockets. It remains for us to use another container to broadcast AMQP notifications to Web Sockets. For this, you should install one of the brokers for AMPQ. ZeroMQ ( www.zeromq.org ) is considered the fastest. Qpid ( qpid.apache.org/amqp-brokers.html ) is quite popular, which is to be expected from the Apache project.
According to cometdaily.com, there are several solutions to emulate bidirectional data exchange between the client and the server:
- Long polling - the server does not respond immediately to an XHR request, but only when an event addressed to a given source (a “questioner”) arrives in the queue.
- Forever frame - creates an iframe in which the server constantly appends events as they arrive.
- Script tags are dynamically generated JS blocks, which allows cross-domain communications.
- ActiveXObject ("htmlfile") - method available in IE and using ActiveX
- JSONRequest object ( www.json.org/JSONRequest.html ) - implements a two-way connection, by means of two simultaneous requests (one for transmission, the other for reception).
In addition, you can use Flash objects or Java applets. And for completeness, we can mention such an ancient technique as Forever GIF.
From myself I would add a couple of high-level solutions:
- The Bayeux protocol ( svn.cometd.com/trunk/bayeux/bayeux.html Dojo Foundation) - allows the exchange of events according to the following schemes: one client - many servers, one server - many clients. Particularly used in the project CometD (www.cometd.com).
- BOSH protocol (http://xmpp.org/extensions/xep-0124.html XMPP standards foundation) - emulates bidirectional data flow between a browser and a server using two synchronous HTTP connections
- Lightstreamer ( www.lightstreamer.com ) is a scalable and reliable server for pushing data into an enriched real-time application.
- APE (Ajax Push Engine) ( www.ape-project.org ) is a lightweight open source push server that has found support in MooTools, Dojo, jQuery. More on Habré ( habrahabr.ru/blogs/webdev/60803 ).
')
Anyway, any of these approaches is in one way or another a hack, when I would like to use a native solution. The guys from the HTML5 working group obviously understand this situation well, and therefore a standard such as Web Sockets is included in the standard. Its description sounds like a panacea: tolerant to firewalls and routers, allows cross-domain communication, integrates with existing HTTP load balancers, allows binary data exchange, works in secure connections, etc. For all that, the Web Sockets API is very simple (see also habrahabr.ru/blogs/webdev/79038 ).
Hooray, thanks, everyone is free? And no. Currently, Web Sockets is supported only in the Chrome development version (starting with 4.0.249.0 - www.chromium.org/getting-involved/dev-channel ) and Firefox 3.7 support is promised. What to do now? Obviously, you need a facade on the client side, which in the presence of the Web Socket uses its “native” API, in the absence of a workaround. Such a solution could be Kaazing Websocket Gateway ( kaazing.com/download ), if it was not distributed for money, but out of kindness of heart. You could use Orbited ( orbited.org ) in conjunction with io.js ( github.com/mcarter/js.io ) if you absolutely need besides Web Sockets access to amqp, imap, irc, ldap, smtp, ssh, stomp, telnet, xmpp and Python on the server proxying any communication. My choice: WebSocket.js ( github.com/gimite/web-socket-js ). Tiny js library and bridge as a flash object.
Now we only need the WebSocket server and, in our case (the backend is written in Java), Jetty is perfectly suited for this, starting with version 7.0.1 (is it currently at almost stable status, but when did that scare us?). If your server applications are written in php, you can try using phpwebsocket ( code.google.com/p/phpwebsocket ) or phpwebsockets ( code.google.com/p/phpwebsockets ). But at your own peril and risk as both decisions are experimental.
UPDATED: Example of chat implementation on phpDaemon habrahabr.ru/blogs/php/79377
I'm sure the installation of Jetty will not cause you any questions, but you may encounter a problem in WebSocket.js due to the so-called cross-domain policy from Adobe. The flash object must be allowed to open a socket on the server. The most reliable solution is to place the micro server on port 843, which responds to the request for policies with the appropriate XML, as described in www.lightsphere.com/dev/articles/flash_socket_policy.html . The article even presents the simplest XML server on Perl. However, I didn’t like it very much, and I wrote my socket server based on the example from devzone.zend.com/article/1086 .
Now that we have Web Sockets, we can write web applications that can instantly respond to server events. It can be a notification system (notificatior) like on Facebook, it can be services for user interaction in the style of Google Waves, it can be real-time monitors (for example, online users) or integration with third-party event sources, such as incoming SMS or event in the desktop application. As we expect a wide variety of events, from different sources directed to different clients, we need a reliable system for managing message flows on the server. There is a simple but elegant STOMP protocol ( stomp.codehaus.org ). The API has only a few commands (SEND, SUBSCRIBE, UNSUBSCRIBE, BEGIN, COMMIT, ABORT, ACK, DISCONNECT) through which STOMP clients and STOMP brokers communicate. In particular, Zend Queue ( framework.zend.com/manual/en/zend.queue.stomp.html ) has an STOMP adapter. A message broker can be implemented using Apache ActiveMQ ( activemq.apache.org ) or RabbitMQ ( www.rabbitmq.com ).
However, if you are very serious, you should pay attention to the more developed and flexible ( habrahabr.ru/blogs/webdev/62502 ) AMQP protocol ( www.amqp.org ).
Jetty, being a JBOSS container, serves Web Sockets. It remains for us to use another container to broadcast AMQP notifications to Web Sockets. For this, you should install one of the brokers for AMPQ. ZeroMQ ( www.zeromq.org ) is considered the fastest. Qpid ( qpid.apache.org/amqp-brokers.html ) is quite popular, which is to be expected from the Apache project.
Source: https://habr.com/ru/post/80466/
All Articles