2013년 5월 1일 수요일

Comet, WebSocket solution - CometD

이전 블로그에서 이전 함 (원본 글 2013/05/01 작성)

 Welcome to CometD Project @ The Dojo Foundation 
 

☄ CometD Bayeux Ajax Push

CometD is a scalable HTTP-based event routing bus that uses a Ajax Push technology pattern known as Comet. The term 'Comet' was coined by Alex Russell in his post Comet: Low Latency Data for the Browser.
CometD is a Dojo Foundation project to provide implementations of the Bayeux protocol in javascript, java, perl, python and other languages. Other organizations (eg. Sun, IBM and BEA) also have implementations of Bayeux that are not strictly part of the CometD project, but where possible they are linked to from this site.

CometD makes use of an Ajax push technology pattern known as Comet, but also uses emerging web standards such as WebSocket for low latency communication.

The CometD project provides Java and JavaScript libraries that allow you to write low-latency, server-side, event-driven web applications in a simple and portable way. You can therefore concentrate on the business side of your application rather than worrying about low-level details such as the transport (HTTP or WebSocket), the scalability and the robustness. The CometD libraries provide these latter characteristics.


he CometD project provides the Bayeux specification, that defines the protocol used to exchange information between client and server, and provides (eventually) standardized APIs for servers and clients.
Currently the API bindings for JavaScript (on the client) and Java (for both client and server) have reached a stable status.



The CometD framework, an event-driven communication solution based on HTTP, has been around for several years. Version 2 added support for annotation configuration and WebSockets. The CometD framework provides a Java server part and a Java client part, plus JavaScript client libraries based upon jQuery and Dojo. CometD uses a standardized communication protocol called Bayeux, allowing you to activate some extensions for message acknowledgement, flow control, synchronization, clustering, and so on.
CometD's event-driven approach fits very well with the new concept of event-driven web development. As with traditional desktop user interfaces, all of the components communicate through a bus to send notifications and receive events. All communication is therefore asynchronous.
The CometD framework:
  • Is well-documented.
  • Provides samples and Maven archetypes to facilitate the startup of a project.
  • Has a well-designed API that enables extension development.
  • Provides a clustering module, called Oort, that gives you the ability to run multiple CometD web servers as nodes in a cluster behind a load balancer to scale to a larger number of HTTP connections.
  • Supports security policies to allow a fine-grain configuration of who can send messages over which channel.
  • Integrates quite well with Spring and Google Guice (dependency injection frameworks).

CometD is bundled with three transports: JSON, JSONP, and WebSocket. They depend upon Jetty Continuations and the Jetty WebSocket API. By default, CometD can be used in Jetty 6, 7, and 8, as well as any other servers supporting the Servlet 3.0 Specification. 


ProsCons
CometD offers a complete solution, from client and server side, and also from a standalone Java client to a server. The framework is well-documented, has a good API, and is easy to use. Best of all, it has an event-driven approach. CometD and Bayeux are part of many event-driven web applications. Other Reverse Ajax frameworks don't provide any event-driven mechanisms, forcing end users to develop their own custom solution.
CometD supports many required features, such as reconnection, reliable timeout detection, back-off, batching, message acknowledgement, and more that you won't find in other Reverse Ajax frameworks. CometD lets you achieve the most reliable, low-latency communication possible.
CometD currently does not support any Servlet 2.5 containers other than Jetty for Comet (Tomcat), and it does not support Glassfish/Grizzly WebSocket.


[CometD 2 Concepts]

- High level View

 : CometD implements a web messaging system, in particular a web messaging system based on the publish/subscribe paradigm.

For example, let's imagine that clientAB is subscribed to channels /A and /B, and clientB is subscribed to channel /B.
If a publisher publishes a message on channel /A, only clientAB will receive it. On the other hand, if a publisher publishes a message on channel /B, both clientAB and clientB will receive the message. Furthermore, if a publisher publishes a message on channel /C, neither clientAB nor clientB will receive the message, that will just end its journey on the server.
Re-routing broadcast messages is the default behavior of the server, and it does not need any application code to perform the re-routing.

* 좀 burden 인것 같이 보이지만 central server를 두고 각 client들이 server로 subscribe하여 event/message를 받는 구조. 자신이 보낸 메세지가 각 channel(subscribe한)을 통해 모든 client(자신 포함)들에게 전달되는 구조.


- Low Level View

 CometD, at its heart, is a client/server system that communicates via a protocol, the Bayeux protocol.

In the CometD implementation, the client/server communication is captured by the half-object plus protocol pattern: when a half-object on the client establishes a communication conduit with the server, its correspondent half-object is created on the server, and the two may - logically - communicate.

The transport can be based on the HTTP protocol, but in recent CometD versions also on the WebSocket protocol (and more transports can be plugged in).

즉 CometD에서는 messaging 전달을 위해서 server, client단에 half object를 만들어서 서로간에 http, websocket을 사용해서 전달하도록 되어 있다는 얘기 인듯... 이렇게 되면  HOPP의 장점을 받을 수 있을 듯.

 * [참고] half-object plus protocol pattern (HOPP)

 - Divide an object which needs to be accessed from more than one address space into two interdependent half-objects (one in each address space) with a protocol between them. 
 - distribute systems상에서 여러 address spaces(아마도 다른 system들이 되지 않을까? 아님 하나의 system에서 각기 다른 application/component상에서 값들을 받아야 할 경우가 아닐까?)에서 실행이 되어야 할 경우 해당 처리를 위한 객체를 분리(half-object)하여 각 address spaces에서 동작하게 하고 서로간에 data/state 전달을 protocol을 사용하는 구조 인것 같음.
 - 장점으로는 처리해야할 행위를 각기 다른 분산 시스템에서 처리하게 되어 performance나 scalability 측면에서는 장점이겠으나 각 half-object 간 data synchronization 측면에서 optimization이 필요할 것으로 보임.
자세한 것은 책 보세요.




[Bayeux Specification]

- specification :  http://cometd.org/documentation/bayeux/spec (나중에 좀 읽어 봐야 겠다.)

Submitted by gregwilkins on Thu, 06/05/2008 - 01:59. 
The primary purpose of Bayeux is to support responsive bidirectional interactionsbetween web clients using Ajax and the web server.

Bayeux is a protocol for transporting asynchronous messages (primarily over HTTP), with low latency between a web server and a web client.

The messages are routed via named channels and can be delivered:
server to client
client to server
client to client (via the server)
By default, publish/subscribe routing semantics are applied to the channels.

Delivery of asynchronous messages from the server to a web client is often described as"server-push".
The combination of server push techniques with an Ajax web application has been called "Comet".
CometD is a project by the Dojo Foundation to provide multiple implementation of the Bayeux protocol in several programming languages.

The Bayeux protocol seeks to reduce the complexity of developing Comet applications by allowing implementors to more easily interoperate, to solve common message distribution and routing problems, and to provide mechanisms for incremental improvements and extensions.


댓글 1개: