Kaazing Gateway 8.09_2 Atlantis is Now Available


News: Kaazing Gateway 8.09_2 Atlantis is Now Available

  1. Kaazing Gateway 8.09_2 Atlantis is Now Available (2 messages)

    Kaazing Gateway 8.09_2 Atlantis is now available for download at kaazing.org. Kaazing Gateway is an open source HTML 5 WebSocket Server that is available for use under the OSI approved Common Public Attribution License (CPAL)—a derivative of the Mozilla Public License. The HTML 5 WebSocket specification is a standard that attempts to simplify much of the complexity around achieving bi-directional communications between browsers and servers. The specification provides a simple JavaScript interface that enables developers to open a full-duplex socket connection and connect directly to any TCP-based back-end service (for example, JMS, JMX, IMAP, Jabber, and so on). Kaazing Gateway makes it possible for developers to take advantage of WebSockets today by providing a JavaScript library that emulates the HTML 5 WebSocket, making it possible to build applications that leverage the WebSocket interface and that can be deployed to both modern and future browsers. The ultra high-performance server behind Kaazing Gateway can support tens of thousands of concurrent connections on a single node. Multiple instances can be clustered with traditional HTTP load-balancers or DNS round robin, making it possible to support any number of persistent client connections. In addition to large numbers of connections, Kaazing Gateway can also handle high data throughput thanks to its high-performance, staged event driven architecture (SEDA). The Atlantis release of Kaazing Gateway also comes prepackaged with JavaScript clients for popular message services such as Apache ActiveMQ and RabbittMQ as well as clients for XMPP services such as OpenFire, Jabberd, and other popular chat servers. This makes it easy for you to quickly build web-based chat applications or messaging applications such as stock matrixes, online trading platforms, or online games.
  2. Very cool. I tried out the examples, impressive ;-) But in my opinon there are severel security issues. If i'm a bad guy, i could write a webpage that open a TCP connection (e.g. to any Queue-Manager) and for every user who enters the site i start to flood the server... perfect distributed attack :-( In that case the comet alternative is better, isn't it? I've found another Websocket implementation on http://orbited.org/. What are the diffrences between Kaazing Gateway and orbited? Ok orbited is written in python but are there any other differences? cheerz alex
  3. In regard to security, network flooding is no more a security risk than it is in the vanilla Comet case. The general JMS case where we attempt to make the browser a subscriber to a JMS topic is a good example to examine. For Comet, each client browser connection to the Comet server requires the instantiation of a new JMS client. This means that despite having a separation of concerns in terms of the protocol interpreted by the client and the backend service (e.g. Bayuex to the browser and JMS to the Message Queue) there is still a one-to-one ratio between client connections and connections made to the backend service. You can be a little smarter about your connectivity to the JMS Queue by pooling JMS connections so that each Comet client is subscribing and publishing over the same JMS client instance, but this introduces a new security threat in that you allow client browsers to publish and subscribe without authenticating against the destination service. In the case of Kaazing Gateway, each JMS client is instantiated in the browser. This offloads a substantial amount of connection and object management from the traditional Java EE server. Secondly, the browser, in order to publish and subscribe to various topics, must authenticate against the message queue. As an added layer of security, you can also configure the gateway to authenticate users against various credentials stores (e.g. LDAP, database, XML, etc.) prior to attempting to connect to any backend services exposed by the gateway. In addition to layered authentication, the gateway also provides protocol validation, which means that it validates the bytes on the wire to ensure they are compatible with the destination service. This prevents malicious attacks where an end-user could attempt to push random data over a tcp connection in an effort to inundate a backend service. Beyond layered authentication and protocol validation, the gateway also provides an encrypted keyring service that allows you to tie credentials used for HTTP authentication to service authentication, making it easy to integrate SSO logins with service authentication. Thus, in terms of network traffic, poxying connections through Kaazing Gatway does not introduce anymore network traffic than that found in the classic Comet scenario. Furthermore, the gateway provides you with a rich set of security features that help you deture any would-be attackers. In regards to your question about differences between Orbited and Kaazing, both projects provide competing implementations of the HTML 5 WebSocket standard, but beyond high-level APIs the two projects differ substantially. The first major difference is security. The security features outlined above are absent from the Orbited project. The second difference is manageability. Kaazing's gateway is bundled with a number of JMX extensions which allow you to integrate with existing monitoring and management solutions such as OpenView. Another difference is that Kaazing's Entperise Gateway uses a single socket connection as its primary means of emulating the WebSocket interface, while the Orbited project defaults to an emulation mode that requires two HTTP connections. Finally, Orbited is, as you stated, based on Python which unlike Java is not multiprocessor aware. Thanks again for your questions and comments. I look forward to responding to any further questions or comments you may have.