Reverse Ajax, Phần 4: Atmosphere và CometD Giới thiệu Loạt bài này cho bạn thấy cách phát triển các ứng dụng web theo hướng sự kiện bằng cách sử dụng các kỹ thuật Reverse Ajax. Phần 1 đã giới thiệu Reverse Ajax, polling, streaming, Comet và long-polling. Phần 2 đã giải thích cách thực hiện Reverse Ajax bằng cách sử dụng WebSockets và đã thảo luận về những hạn chế của các máy chủ web khi sử dụng Comet và WebSockets. Phần 3 đã cho thấy rằng việc triển khai thực hiện hệ thống truyền thông WebSockets hoặc Comet riêng của bạn có thể khó khăn nếu bạn cần hỗ trợ một số máy chủ hoặc cung cấp một ứng dụng web độc lập cho người dùng để triển khai trên máy chủ của riêng họ. Thậm chí nếu mã JavaScript trên máy khách đơn giản, thì bạn vẫn cần một số cách xử lý trường hợp ngoại lệ, các tính năng kết nối lại và tin báo. Về phía máy chủ, việc thiếu một API chung (global API) và nhiều API máy chủ web dẫn đến nhu cầu cần có các framework để mang lại một sự trừu tượng hóa. Phần 3 cũng đã thảo luận Socket.IO. Trong bài này, hãy tìm hiểu về Atmosphere và CometD. Chúng là các thư viện Reverse Ajax nổi tiếng cho các máy chủ Java. Bạn có thể tải về mã nguồn được sử dụng trong bài này. Điều kiện tiên quyết Để nắm vững kiến thức trong bài này, tốt nhất bạn nên biết trước JavaScript và Java. Để chạy ví dụ mẫu trong bài này, bạn cũng cần có phiên bản Maven và JDK mới nhất (xem phần Tài nguyên). Về đầu trang Framework Atmosphere Atmosphere là một framework Java cung cấp API chung để sử dụng các tính năng Comet và WebSocket của nhiều máy chủ web, gồm có Tomcat, Jetty, GlassFish, WebLogic, Grizzly, JBossWeb, JBoss và Resin. Bất kỳ máy chủ web nào đang hỗ trợ Đặc tả Servlet 3.0 thì cũng sẽ hỗ trợ. Trong số các framework được trình bày trong loạt bài này, Atmosphere hỗ trợ nhiều máy chủ nhất. Atmosphere có thể phát hiện ra các API máy chủ nguyên gốc (cho Comet và WebSockets) và chuyển đổi ngược lại Servlet 3.0, nếu có, cho Comet. Hoặc, cũng với Comet, nó sẽ quay lại một chế độ không đồng bộ "có quản lý" (nhưng không có khả năng co giãn như Jetty Continuations). Atmosphere đã được dùng hơn hai năm và vẫn tiếp tục được phát triển. Nó được sử dụng trong các ứng dụng web lớn như JIRA, một trong những trình dò tìm vấn đề (issue tracker) nổi tiếng nhất. Hình 1 cho thấy kiến trúc của Atmosphere. Hình 1. Kiến trúc của Atmosphere Framework Atmosphere bao gồm Atmosphere runtime, cung cấp một API chung cho tất cả các giải pháp và tiêu chuẩn máy chủ web khác nhau. Trên hết, máy khách có thể truy cập vào các tính năng API và Reverse Ajax thông qua Google Web Toolkit (GWT – Bộ công cụ Web của Google) bằng cách thiết lập chỉ một servlet. Hoặc, bạn cũng có thể sử dụng Jersey, một framework thực hiện JSR-311 (đặc tả JAX-RS). Vì thế, Atmosphere có thể được sử dụng trong các dịch vụ tiện lợi có cung cấp các chú thích bổ sung. Sau khi cấu hình mô đun mà bạn chọn, bạn có thể truy cập Atmosphere runtime bằng cách thực thi một số lớp (được thảo luận sau trong bài này). Bạn cũng có thể tùy chọn sử dụng một số plugin được cung cấp để tăng thêm hỗ trợ cho việc phân cụm (clustering), tạo thông báo, tích hợp phụ thuộc và nhiều hơn nữa. Nếu bạn đang sử dụng một web framework (Wicket, Struts, Spring MVC), bạn có thể thêm vào sự hỗ trợ Reverse Ajax bằng cách sử dụng MeteorServlet của Atmosphere. Servlet này trưng ra một đối tượng Meteor, có thể được lấy ra trong các trình điều khiển và các dịch vụ của bạn để treo (suspend) hoặc tiếp tục (resume) lại các yêu cầu. Sức mạnh của Atmosphere vẫn còn ở phía máy chủ: nó cung cấp một API chuẩn hóa bao gồm tất cả các giải pháp khác nhau và các cách để truyền thông với WebSockets hoặc Comet. Atmosphere không sử dụng một giao thức giữa máy khách và máy chủ, như Socket.IO và CometD. Cả hai thư viện đó đều cung cấp một JavaScript phía máy khách và một servlet phía máy chủ sử dụng cách giao tiếp thông qua giao thức đặc trưng (handshaking, tạo thông báo, tin báo và nhịp hoạt động). Mục tiêu của Atmosphere là cung cấp một kênh truyền dẫn chung bên phía máy chủ. Nếu bạn cần phải sử dụng một giao thức đặc trưng, chẳng hạn như Bayeux (một giao thức được CometD sử dụng), bạn phải phát triển "trình xử lý" riêng của mình theo Atmosphere. Plugin CometD chỉ làm một việc là tận dụng API của Atmosphere để suspend và resume lại các yêu cầu và nó ủy quyền cho các lớp CometD để quản lý truyền thông CometD khi sử dụng giao thức Bayeux. Atmosphere đi kèm với một thư viện máy khách jQuery để giúp cho việc thiết lập kết nối dễ dàng, nó có thể tự động phát hiện ra kiểu truyền tải tốt nhất hiện có (WebSockets hoặc CometD). Việc sử dụng plugin jQuery của Atmosphere cũng tương tự như API WebSockets của HTML5. Đầu tiên, bạn kết nối đến máy chủ, đăng ký một cuộc phản hồi để nhận các thông báo và sau đó bạn có thể đẩy ra dữ liệu nào đó. Mã nguồn kèm theo bài này có chứa một ví dụ mẫu Atmosphere trực tiếp sử dụng một trình xử lý với servlet của Atmosphere. Mã máy khách luôn giống nhau; đó là mã tương tự như mã được sử dụng trong các Phần 1, 2 và 3 của loạt bài này (trong các ví dụ mẫu chat khi sử dụng Comet long-polling). Có thể bạn đang sử dụng plugin jQuery của Atmosphere, nhưng chưa cần thiết vì Atmosphere không thi hành bất kỳ giao thức truyền thông nào. Ngoài ra bạn có thể xem xét các ví dụ khác trong dự án của Atmosphere, nhất là những ví dụ sử dụng các chú thích JSR-311 (Jersey). Chúng thực sự đơn giản hóa việc viết các trình xử lý. Liệt kê 1 cho thấy giao diện của trình xử lý Atmosphere. Liệt kê 1. Giao diện AtmosphereHandler public interface AtmosphereHandler<F, G> { void onRequest(AtmosphereResource<F, G> resource) throws IOException; void onStateChange(AtmosphereResourceEvent<F, G> event) throws IOException; void destroy(); } Phương thức onRequest nhận tất cả các yêu cầu từ máy khách và quyết định xem có suspend hoặc resume lại chúng (hoặc không làm gì) hay không. Mỗi lần suspend hoặc resume lại yêu cầu, một thông báo được phát đi hoặc diễn ra một thời gian chờ timeout, một sự kiện được gửi và nhận bằng phương thức onStateChange. Cách thực hiện phương thức onRequest để chat trong Comet được hiển thị như Liệt kê 2. Liệt kê 2. Giao diện AtmosphereHandler - onRequest Broadcaster broadcaster = BroadcasterFactory.getDefault().lookup( DefaultBroadcaster.class, ChatHandler.class.getName(), true); broadcaster.setScope(Broadcaster.SCOPE.APPLICATION); resource.setBroadcaster(broadcaster); HttpServletRequest req = resource.getRequest(); String user = (String) req.getSession().getAttribute("user"); if (user != null) { if ("GET".equals(req.getMethod())) { resource.suspend(-1, false); } else if ("POST".equals(req.getMethod())) { String cmd = req.getParameter("cmd"); String message = req.getParameter("message"); if ("disconnect".equals(cmd)) { close(resource); } else if (message != null && message.trim().length() > 0) { broadcaster.broadcast("[" + user + "] " + message); } } } Một quy ước điển hình là treo các yêu cầu GET và gửi các thông báo bằng phương thức POST. Khi nhận được một thông báo, nó sẽ được chuyến tiếp (broadcast) đến tất cả các nơi đã được đăng ký trong trình phát quảng bá (broadcaster). Lưu ý rằng ví dụ này không bao giờ gửi bất cứ điều gì tới luồng dữ liệu kết quả HttpServlet. Hành động broadcast và suspend chỉ là gửi các sự kiện đã nhận được khi thực thi các phương thức khác, như thể hiện trong Liệt kê 3: Liệt kê 3. Giao diện AtmosphereHandler - onStateChange Broadcaster broadcaster = BroadcasterFactory.getDefault().lookup( DefaultBroadcaster.class, ChatHandler.class.getName(), true); // Client closed the connection. if (event.isCancelled()) { close(event.getResource()); return; } try { String message = (String) event.getMessage(); if (message != null) { PrintWriter writer = event.getResource().getResponse().getWriter(); writer.write(message); writer.flush(); } } finally { if (!event.isResumedOnTimeout()) { event.getResource().resume(); } } Bây giờ bạn đã có những gì cần thiết để Comet chat hoạt động. Tóm lại, các khái niệm Atmosphere trọng tâm là: đối tượng tài nguyên đại diện cho kết nối và một broadcaster chịu trách nhiệm khởi động các sự kiện đến các tài nguyên và quyết định khi nào suspend hoặc resume lại một yêu cầu. Lưu ý rằng ví dụ này chỉ dùng cho Comet. Để có thể sử dụng WebSockets và Comet, nên sử dụng một thư viện phía máy khách và sẽ cần một trình xử lý phức tạp hơn. Bảng 1 mô tả những lợi ích và hạn chế khi sử dụng framework Atmosphere. Bảng 1. Những lợi ích và hạn chế của khung công tác Atmosphere Lợi ích Hạn chế N ếu bạn phải triển khai một ứng dụng web trong một số máy chủ web mà bạn không thể kiểm soát được. Bạn sẽ có cơ hội tốt là các tính năng Reverse Ajax trong ứng dụng của bạn sẽ hoạt động đúng do số máy chủ web được Atmosphere hỗ trợ. Khi bạn cần một API phổ biến trên một giao tiếp Reverse Ajax, mà không cần định nghĩa bất kỳ giao thức nào, vì có thể bạn muốn phát triển hay mở rộng nó. Thiếu tài liệu hướng dẫn về kiến trúc, dự án, các khái niệm và các API của Atmosphere, những thứ này sẽ rất có ích nếu bạn muốn xem mã nguồn hoặc phân tích một số ví dụ mẫu được cung cấp. API này có kỹ thuật cao và đôi khi mơ hồ, so với các API đơn giản của các framework khác, chẳng hạn nh ư Socket.IO và CometD. Ngay cả khi có sử dụng các chú thích trong Atmosphere, thì một số tên và các thuộc tính của nó vẫn quá mang tính kỹ thuật. Mặc dù có khả năng trừu tượng hóa tốt ở phía máy chủ, nhưng không có một thư viện tốt nào ở phía máy khách. Không có giao thức nào cả, do đó, tất cả các tính năng bổ sung đều được dành cho các nhà phát triển. Nếu bạn yêu cầu một ứng dụng web lớn, có khả năng co giãn và phát hiện timeout, tin báo, back-off, liên miền, v.v nhất là khi làm vi ệc với các thiết bị di động thì thư viện này là quá đơn giản. Trong trường hợp này, CometD cho độ tin cậy hơn rất nhiều; nó sử dụng một giao thức truyền thông để kích hoạt một số luồng điều khiển và phát hiện lỗi, tất cả đều được cung cấp trong CometD. Việc sử dụng máy khách JavaScript của CometD với plugin CometD của Atmosphere có thể là một lựa chọn thay thế tốt nếu bạn cần các tính năng bổ sung. Về đầu trang Framework CometD Framework CometD, một giải pháp truyền thông theo sự kiện dựa trên HTTP, đã được dùng trong nhiều năm. Phiên bản 2 đã thêm sự hỗ trợ cho việc cấu hình chú thích và WebSockets. Framework CometD cung cấp một phần máy chủ Java và một phần máy khách Java, cộng với các thư viện máy khách JavaScript dựa trên jQuery và Dojo. CometD sử dụng một giao thức truyền thông chuẩn hóa được gọi là Bayeux, cho phép bạn kích hoạt một số phần mở rộng cho tin báo, kiểm soát luồng, đồng bộ hóa, phân cụm và v.v. Cách tiếp cận theo sự kiện của CometD hoàn toàn phù hợp với các khái niệm mới về phát triển web theo sự kiện. Như với các giao diện người dùng máy tính để bàn truyền thống, tất cả các thành phần đều truyền thông qua một bus để gửi các khai báo và nhận các sự kiện. Do đó tất cả cách truyền thông đều là không đồng bộ. Framework CometD:  Có đủ tài liệu cần thiết.  Cung cấp các ví dụ mẫu và các nguyên mẫu Maven giúp dễ dàng khởi động một dự án.  API được thiết kế tốt cho phép phát triển mở rộng.  Cung cấp một mô đun phân cụm (clustering), được gọi là Oort, cung cấp cho bạn khả năng chạy nhiều máy chủ web CometD như các nút trong một cụm phía sau một trình cân bằng tải để điều chỉnh co giãn theo một số lượng lớn các kết nối HTTP.  Hỗ trợ các chính sách bảo mật để cho phép thiết lập xem ai có quyền gửi thông báo qua kênh nào.  Tích hợp khá tốt với Spring và Google Guice (các dependency injection framework). Giao thức Bayeux Giao thức truyền thông Bayeux chủ yếu thông qua HTTP. Nó cung cấp không đồng bộ một cách truyền thông đáp ứng hai chiều giữa máy khách và máy chủ. Giao thức Bayeux dựa trên các kênh mà ở đó các thông báo được định tuyến và phân phối từ máy khách đến máy chủ, máy chủ đến máy khách hoặc máy khách đến máy khách (nhưng thông qua máy chủ). Bayeux là một kiểu giao thức đăng ký-xuất bản. CometD thực hiện giao thức Bayeux và do đó cung cấp một tầng trừu tượng hóa dựa trên các kiểu truyền tải Comet và WebSocket để định tuyến các yêu cầu qua Bayeux. Máy chủ và đặc tính của nó CometD được đóng gói với ba kiểu truyền tải: JSON, JSONP và WebSocket. Chúng phụ thuộc vào API Continuations và WebSocket của Jetty. Theo mặc định, có thể sử dụng CometD với Jetty 6, 7, 8, cũng như bất kỳ các máy chủ khác nào hỗ trợ Đặc tả Servlet 3.0. Có thể bổ sung và phát triển các kiểu truyền tải theo cách giống như các phần mở rộng. Bạn có thể viết các kiểu truyền tải hỗ trợ API WebSocket của Grizzly và các API khác, rồi thêm chúng vào bước cấu hình máy chủ CometD. Hình 2 cho thấy một tổng quan về các khối CometD chính. Hình 2. Kiến trúc của CometD Tầng bảo mật để truy cập các kênh thông báo không được hiển thị trong Hình 2. Mã nguồn được cung cấp cùng với bài viết này gồm có một ứng dụng web sử dụng CometD. Trình mô tả ứng dụng web có chứa định nghĩa được mô tả trong ví dụ chat ở Liệt kê 4. Liệt kê 4. web.xml <servlet> <servlet-name>cometd</servlet-name> <servlet-class> org.cometd.java.annotation.AnnotationCometdServlet </servlet-class> <async-supported>true</async-supported> [ ] <init-param> <param-name>services</param-name> <param-value>ChatService</param-value> </init-param> <init-param> <param-name>transports</param-name> <param-value> com.ovea.cometd.websocket.jetty8.Jetty8WebSocketTransport </param-value> </init-param> </servlet> Servlet CometD hỗ trợ một số tùy chọn kiểm soát các thiết lập chung, chẳng hạn như khả năng thiết lập các kiểu truyền tải và các dịch vụ. Trong ví dụ này, giả sử bạn muốn Jetty 8 hỗ trợ WebSocket, lớp dịch vụ ChatService của CometD bên phía máy chủ sẽ kiểm soát phòng chat, nơi mọi người có thể trò chuyện, như thể hiện trong Liệt kê 5: Liệt kê 5. Lớp ChatService của CometD @Service public final class ChatService { @Inject BayeuxServer server; @PostConstruct void init() { server.addListener(new BayeuxServer.SessionListener() { @Override public void sessionAdded(ServerSession session) { [ ] } @Override public void sessionRemoved(ServerSession session, boolean timedout) { [ ] } }); } @Configure("/**") void any(ConfigurableServerChannel channel) { channel.addAuthorizer(GrantAuthorizer.GRANT_NONE); } @Configure("/chatroom") void configure(ConfigurableServerChannel channel) { channel.addAuthorizer(new Authorizer() { @Override public Result authorize( [ ] // check that the user is in session } }); } @Listener("/chatroom") void appendUser(ServerSession remote, ServerMessage.Mutable message) { [ ] } } Liệt kê 5 trình bày một số tính năng quan trọng của CometD, bao gồm:  Tích hợp phụ thuộc (Dependency injection)  Quản lý vòng đời  Cấu hình kênh chung  Quản lý bảo mật  Chuyển đổi thông báo (để thêm tên người dùng trước tất cả các thông báo)  Quản lý phiên làm việc Về phía máy khách, ví dụ này không kích hoạt bất kỳ phần mở rộng nào chỉ cần mã CometD thô, như trong Liệt kê 6: Liệt kê 6. Mã máy khách của CometD // First create t cometd object and configure it var cometd = new $.Cometd('CometD chat client'); cometd.configure({ url: document.location + 'cometd', logLevel: 'debug' }); cometd.websocketEnabled = 'WebSocket' in window; // Then we register some listeners. Meta channels (those with // the form /meta/<name> are specific reserved channels) cometd.addListener('/meta/disconnect', function(message) { [ ] }); cometd.addListener('/meta/connect', function(message) { [ ] }); // Then, starting a connexion can be done using: cometd.handshake(); // And subscriptions with: cometd.subscribe('/chatroom', function(event) { [ ] // event.data holds the message }); // We finally send data to the chatroom like this: cometd.publish('/chatroom', msg); API phía máy khách của CometD dễ dùng và dễ hiểu, trong khi vẫn mạnh mẽ và có thể mở rộng được. Bài này chỉ trình bày các phần chính của ứng dụng web, vì vậy hãy xem ứng dụng ví dụ để có ý tưởng tốt hơn về sức mạnh của CometD. Bảng 2 vạch ra những lợi ích và hạn chế khi sử dụng khung công tác CometD. Bảng 2. Những lợi ích và hạn chế của CometD Lợi ích Hạn chế CometD đưa ra một giải pháp hoàn chỉnh, từ phía máy khách và phía máy chủ, cũng như từ một máy khách Java độc lập đến một máy chủ. Framework này có đủ tài liệu cần thiết, có một API tốt và dễ sử dụng. Trên hết, nó có cách tiếp cận theo hướng sự kiện. CometD và Bayeux là một phần của nhiều ứng dụng web theo sự kiện. Các khung công tác Reverse Ajax khác không cung cấp bất kỳ cơ chế theo sự kiện nào, buộc người dùng cuối phải phát triển giải pháp riêng của mình. CometD hỗ trợ nhiều tính năng cần thiết, chẳng hạn như kết nối lại, phát hiện thời gian chờ tin cậy, back-off, xử lý theo bó, tin báo và nhiều hơn nữa mà bạn sẽ không tìm thấy trong các framework Reverse Ajax khác. CometD cho phép bạn đạt được cách truyền thông có độ trễ thấp, tin cậy nhất có thể. CometD hiện tại không hỗ trợ bất kỳ container Servlet 2.5 nào ngoài Jetty cho Comet (Tomcat) và nó cũng không hỗ trợ WebSocket của Glassfish/Grizzly. Về đầu trang Kết luận Cả Atmosphere và CometD đều là các giải pháp Reverse Ajax nguồn mở, chắc chắn. Với Ovea, sự lựa chọn của chúng tôi là CometD vì chúng tôi phát triển các ứng dụng web theo sự kiện có khả năng co giãn với các thiết bị di động trong một môi trường có phân cụm và chúng tôi có toàn quyền kiểm soát cơ sở hạ tầng (Jetty). Tuy nhiên, do không được tiếp tục phát triển, CometD không thể là sự lựa chọn tốt nhất nếu bạn đang bán các ứng dụng web và muốn các tính năng Reverse Ajax của mình làm việc trên càng nhiều máy chủ càng tốt. Nhưng giờ đây, càng ngày càng có nhiều Web container hỗ trợ Đặc tả Servlet 3.0, nên đã giảm bớt sự hạn chế của CometD. Khi nói về tầng truyền tải, sự khác biệt chính còn lại hiện nay phụ thuộc vào sự hỗ trợ của WebSocket. . Reverse Ajax, Phần 4: Atmosphere và CometD Giới thiệu Loạt bài này cho bạn thấy cách phát triển. các kỹ thuật Reverse Ajax. Phần 1 đã giới thiệu Reverse Ajax, polling, streaming, Comet và long-polling. Phần 2 đã giải thích cách thực hiện Reverse Ajax