1. Trang chủ
  2. » Luận Văn - Báo Cáo

Đồ án tìm hiểu JMS và viết ứng dụng trao đổi thông tin

76 2,7K 13

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 76
Dung lượng 1,13 MB

Nội dung

Báo cáo java message service ( JMS ) đầy đủ được tham khảo từ sách java message service của tác giả O''''''''''''''''''''''''''''''''Reilly và nhiều tài liệu khác

     !"# $%&'($ ) '*%+,-. /% 0-1234 56756  89:;< TP.HCM, ngày … tháng … năm Giáo viên hướng dẫn 2  89:= Khóa luận đáp ứng yêu cầu của Khóa luận cử nhân CNTT. TP. HCM, ngày … tháng … năm … Giáo viên phản biện 3 >?@AB3*CDCE>CFGHIEJC 33 /KCLMHNG Trong những năm qua, hệ thống đã phát triển đáng kể về độ phức tạp sự tinh tế. Sự cần thiết phải có một hệ thống với độ tin cậy tốt hơn, tăng khả năng mở rộng, linh hoạt hơn trước đã làm nảy sinh những kiến trúc phức tạp tinh vi hơn. Để đáp ứng với nhu cầu gia tăng này để cho ra đời các hệ thống tốt hơn nhanh hơn, các nhà thiết kế phát triển đã tận dụng gởi nhận thông điệp như một cách để giải quyết những vấn đề phức tạp này. Java Message Service là một phần mềm trung gian hướng thông điệp để gởi nhận thông điệp giữa hai hay nhiều client. Java Message Service đã tận dụng tối đa khái niệm gởi nhận thông điệp, cho phép các thành phần ứng dụng xây dựng trên Java Enterprise Edition tạo, gởi, nhận đọc thông điệp, cho phép các thành phần khác nhau của ứng dụng phân tán giao tiếp hiệu quả bất đồng bộ. Sự giảng dạy của các thầy cô khoa Công Nghệ Thông Tin sự hướng dẫn nhiệt tình, chân thành của thầy hướng dẫn Lăng Uy Tín đã cho chúng em kiến thức động lực để có thể hoàn thành đề tài này.Nhóm em chân thành cảm ơn kính chúc sức khỏe các quý thầy. 31 56ECOGPJA>CFLP5HIEJCEQRABBCSCHRTAE>U6EVWEXEAB>CFW 313 Mục tiêu • Tìm hiểu về công nghệ Java Message Service. • Tìm hiểu về cách lập trình cũng như sử dụng JMS. • Xây dựng ứng dụng để minh họa các hoạt động cơ bản của JMS. 311 Nhiệm vụ • Tìm kiếm bổ sung kiến thức lập trình JMS ActiveMQ cơ bản. • Hoàn thành những chức năng chính cơ bản của ứng dụng. 4 >?@AB1*YABZGSAPIBMCA>VAE>[ABHCFW 13 >\CACFLBMCA>VAE>[ABHCFW Gởi nhận thông điệp được sử dụng rộng rãi để giải quyết những vấn đề về độ tin cậy khả năng mở rộng, nó cũng được sử dụng để giải quyết một loạt các vấn đề khác mà nhiều ứng dụng doanh nghiệp không doanh nghiệp gặp phải. Tích hợp không đồng nhất là một trong những lĩnh vực chính mà gởi nhận thông điệp đóng vai trò quan trọng. Cho dù đóthông qua sáp nhập, mua lại, yêu cầu kinh doanh, hoặc chỉ đơn giản là một sự đổi hướng công nghệ, ngày càng nhiều công ty đang phải đối mặt với vấn đề tích hợp hệ thống không đồng nhất các ứng dụng bên trong giữa các doanh nghiệp. Không phải là bất thường khi gặp phải vô số các công nghệ nền tảng trong một công ty hoặc bộ phận bao gồm Java EE, Microsoft. NET, Tuxedo, thậm chí cả CICS trên mainframe. Gởi nhận thông điệp cũng cung cấp khả năng xử lý các yêu cầu không đồng bộ, cung cấp các kiến trúc sư các nhà phát triển để tìm ra giải pháp giảm thiểu hoặc loại bỏ tắc nghẽn hệ thống, tăng năng suất người dùng cuối khả năng mở rộng tổng thể hệ thống. Vì gởi nhận thông điệp cung cấp một mức độ cao sự tách riêng các thành phần, các hệ thống sử dụng gởi nhận thông điệp cũng cung cấp một mức độ cao tính linh hoạt kiến trúc sự nhanh nhẹn. Hệ thống gởi nhận thông điệp giữa ứng dụng ứng dụng , khi được sử dụng trong các hệ thống kinh doanh, thường được gọi chung là hệ thống gởi nhận thông điệp doanh nghiệp, hoặc phần mềm trung gian hướng thông điệp (Message-Oriented Middleware (MOM)) . Hệ thống gởi nhận thông điệp doanh nghiệp cho phép hai hay nhiều ứng dụng trao đổi thông tin dưới dạng thông điệp. Một thông điệp, trong trường hợp này, là một gói dữ liệu nghiệp vụ (business data) khép kín các header định tuyến mạng . Các dữ liệu nghiệp vụ có trong thông điệp có thể là bất cứ cái gì, tùy thuộc vào tình huống và thường chứa thông tin về một số giao dịch kinh doanh . Trong hệ thống gởi nhận thông điệp doanh nghiệp, thông điệp thông báo cho một ứng dụng về một số sự kiện hoặc sự cố trong hệ thống khác. 5 Sử dụng MOM, các thông điệp được truyền đi từ một ứng dụng này sang một ứng dụng khác qua mạng. Sản phẩm phần mềm trung gian doanh nghiệp đảm bảo rằng thông điệp được phân phối hợp lý giữa các ứng dụng . Ngoài ra, các sản phẩm này thường cung cấp sức chịu lỗi, cân bằng tải, khả năng mở rộng , và hỗ trợ giao dịch cho các doanh nghiệp cần phải trao đổi số lượng lớn các thông điệp một cách tin cậy. Các nhà cung cấp gởi nhận thông điệp doanh nghiệp sử dụng các định dạng thông điệp các giao thức mạng khác nhau cho việc trao đổi thông điệp, nhưng ngữ nghĩa cơ bản là giống nhau. Một API được sử dụng để tạo ra một thông điệp, tải các dữ liệu ứng dụng (tải trọng thông điệp), gán thông tin định tuyến, gửi thông điệp. Cùng một API được sử dụng để nhận thông điệp được tạo ra bởi các ứng dụng khác. Trong tất cả các hệ thống gởi nhận thông điệp doanh nghiệp hiện đại, các ứng dụng trao đổi thông tin thông qua kênh ảo được gọi là các điểm đến (destination). Khi tin nhắn được gửi đi, nó được gửi đến một điểm đến (ví dụ như queue hoặc topic), không phải là một ứng dụng cụ thể . Bất kỳ ứng dụng nào đăng ký quan tâm đến điểm đến cũng có thể nhận được thông báo. Bằng cách này, các ứng dụng nhận tin nhắn các ứng dụng gửi tin nhắn được tách riêng. Bên gửi bên nhận không bị ràng buộc với nhau trong bất kỳ hoàn cảnh nào có thể gửi nhận thông điệp theo bất kỳ cách phù hợp nào . Tất cả các nhà cung cấp gởi nhận thông điệp doanh nghiệp cung cấp cho các nhà phát triển ứng dụng một API cho việc gởi nhận thông điệp. Nhà cung cấp cài đặt giao thức mạng, định tuyến, cơ sở quản trị riêng của mình, ngữ nghĩa cơ bản của API dành cho nhà phát triển được cung cấp bởi các nhà cung cấp khác nhau là như nhau. Sự tương đồng trong các API này làm cho Java Message Service tồn tại được. JMS là một Java API độc lập với nhà cung cấp, có thể được sử dụng với nhiều các nhà cung cấp gởi nhận thông điệp doanh nghiệp khác nhau. JMS tương tự như JDBC ở chỗ các nhà phát triển ứng dụng có thể sử dụng lại cùng một API để truy cập nhiều hệ thống khác nhau . Nếu một nhà cung cấp cung cấp dịch vụ phù hợp cho JMS, JMS API có thể được sử dụng để gửi nhận thông điệp cho nhà cung cấp đó. Ví dụ, bạn có thể sử dụng cùng một JMS 6 API để gửi thông điệp sử dụng SonicMQ như sử dụng WebSphere MQ của IBM. Phần còn lại của chương này đi sâu về tìm hiểu gởi nhận thông điệp doanh nghiệp chi tiết hơn về JMS. Kết luận: Gởi nhận thông điệp (messaging) là cách thức để giao tiếp giữa các thành phần phần mềm hoặc các ứng dụng. Một hệ thống gởi nhận thông điệp là một phương tiện thông tin ngang hàng (peer-to-peer): Một máy khách có thể gởi thông điệp đi nhận thông điệp về từ bất kì máy khách nào. Từng máy khách kết nối tới một đại lí (agent) cung cấp công cụ truyền thông để tạo, gởi, nhận đọc thông điệp. Hình 2.1: Phần mềm trung gian hướng thông điệp Ngoài ra, gởi nhận thông điệp cho phép truyền thông phân tán. Một thành phần có thể gửi một thông điệp cho một đích (destination), bên nhận có thể thu được thông điệp này từ đích. Tuy nhiên, bên gửi bên nhận không cần sẵn sàng cùng lúc để truyền thông. Thực tế, bên gửi không cần biết bất kì điều gì về bên nhận; hay bên nhận không cần biết bất kì điều gì về bên gửi. Bên gửi bên nhận chỉ cần biết khuôn dạng thông điệp đích (destination) để 7 sử dụng. Theo khía cạnh này, truyền thông điệp khác với các công nghệ khác, như Remote Method Invocation (RMI), RMI yêu cầu ứng dụng phải biết rõ các phương thức của ứng dụng ở xa. Hình 2.2: Tính liên kết chặt chẽ của RMI 11 /]C^6>6_SPCF6BMCA>VAE>[ABHCFW Gởi nhận thông điệp giải quyết được nhiều thách thức về mặt kiến trúc như việc tích hợp không đồng nhất, khả năng mở rộng, tắc nghẽn hệ thống, xử lý đồng thời, sự linh hoạt nhanh nhẹn của kiến trúc tổng thể. 113 Tích hợp không đồng nhất Sự giao tiếp tích hợp giữa các nền tảng không đồng nhất là trường hợp kinh điển nhất cần phải sử dụng gởi nhận thông điệp. Sử dụng gởi nhận thông điệp, ta có thể gọi các service từ ứng dụng hệ thống của một nền tảng hoàn toàn khác. Nhiều hệ thống gởi nhận thông điệp cung cấp kết nối liền mạch giữa Java các ngôn ngữ khác, các nền tảng khác bằng cách tận dụng một 8 message bridge đã được tích hợp sẵn, nó sẽ chuyển 1 thông điệp gởi bằng JMS sang 1 định dạng nội bộ chung cho thông điệp. 111 Giảm tắc nghẽn hệ thống Việc nghẽn cổ chai trong hệ thống ứng dụng xảy ra khi có process không đáp ứng kịp yêu cầu được gửi đến process đó. Việc gởi nhận thông điệp có thể được dùng để giảm thiểu hoặc triệt tiêu tắc nghẽn hệ thống. Thay vì để các yêu cầu dồn lại trong lúc một thành phần đồng bộ xử lý chúng, các yêu cầu được gởi đến 1 hệ thống gởi nhận thông điệp để phân phát các yêu cầu tới nhiều thành phần message listener. Bằng cách này các nút cổ chai gặp phải trong kết nối point-to-point đồng nhất sẽ được giảm thiểu hoặc triệt tiêu hoàn toàn. 11` Tăng khả năng mở rộng Cũng giống như việc giảm tắc nghẽn hệ thống, gởi nhận thông điệp cũng có thể được sử dụng để tăng khả năng mở rộng băng thông hệ thống, đồng thời giảm thiểu thời gian phản hồi 1 cách hiệu quả. Khả năng mở rộng trong hệ thống gởi nhận thông điệp được thực hiện bằng cách sử dụng nhiều message receiver để có thể xử lý nhiều thông điệp đồng thời. Khi các thông điệp được dồn lại chờ xử lý, số lượng thông điệp trong hàng đợi (được gọi là độ sâu hàng đợi) tăng dần. Khi độ sâu hàng đợi tăng, thời gian phản hồi của hệ thống cũng tăng theo băng thông giảm. 1 cách để tăng khả năng mở rộng của hệ thống là thêm các message listener đồng thời cho hàng đợi để xử lý được nhiều yêu cầu cùng lúc hơn. 1 cách khác để tăng khả năng mở rộng của hệ thống là tạo ra càng nhiều hệ thống bất đồng bộ càng tốt. Tách các thành phần ra theo cách này cho phép hệ thống phát triển theo chiều ngang, chỉ có tài nguyên phần cứng là yếu tố giới hạn. Tuy nhiên, middlewarer chỉ có thể được mở rộng theo chiều ngang trong phạm vi của database. Ta có thể có hàng ngàn message listener trong 1 hàng đợi cho phép xử lý nhiều thông điệp 1 lúc nhưng database chỉ có thể xử lý các yêu cầu đồng thời 1 cách giới hạn. 9 114 Tăng hiệu suất người dùng cuối Việc gởi nhận thông điệp bất đồng bộ cũng có thể tăng hiệu năng người dùng cuối. Chẳng hạn như khi người dùng cuối gởi yêu cầu đến hệ thống từ một giao diện người dùng trên web hoặc destop mất đến vài phút. Trong khoảng thời gian đó người dùng phải đợi kết quả trả về, không thể làm việc tiếp. Bằng cách gởi nhận thông điệp bất đồng bộ, nguời dùng có thể gửi yêu cầu lên hệ thống nhận được ngay phản hồi báo rằng yêu cầu đã được chấp nhận. Người dùng có thể tiếp tục làm việc khác trên hệ thống trong khi yêu cầu được thực thi. Khi yêu cầu đã hoàn tất, người dùng được thông báo rằng yêu cầu đã được xử lý kết quả được trả về cho người dùng. Bằng việc gởi nhận thông điệp, người dùng có thể hoàn thành nhiều việc hơn với thời gian chờ ít hơn, dẫn đến năng suất cao hơn. 11a Sự linh hoạt nhanh nhẹn của kiến trúc Việc sử dụng gởi nhận thông điệp làm 1 phần giải pháp kiến trúc doanh nghiệp nâng cao sự linh hoạt nhanh nhẹn của kiến trúc. Những ưu điểm này đạt được thông qua việc sử dụng trừu tượng hóa tách biệt các thành phần. Bằng cách gởi nhận thông điệp, các subsystem, thành phần cả dịch vụ đều có thể được trừu tượng hóa tới mức chúng có thể được thay thế bằng thành phần của client mà không cần biết về chúng. Sự nhanh nhẹn của kiến trúc là khả năng đáp ứng nhanh trong 1 môi trường thay đổi liên tục. Bằng việc gởi nhận thông điệp để trừu tượng hóa tách biệt các thành phần, ta có thể nhanh chóng đáp ứng các thay đổi trong phần mềm, phần cứng cả thay đổi về doanh nghiệp. Khả năng thay thế 1 hệ thống này bằng hệ thống khác, thay đổi 1 nền tảng công nghệ, hoặc thay đổi giải pháp từ nhà cung cấp mà không làm ảnh hưởng ứng dụng client có thể đạt được thông qua việc trừu tượng hóa bằng gởi nhận thông điệp. 10 [...]... point-to-point là việc gởi thông điệp một-một Hình 3.1: JMS messaging domains Theo góc nhìn của JMS, các client gởi nhận thông điệp được gọi là JMS client, hệ thống gởi nhận thông điệp được gọi là JMS provider Một ứng dụng JMS là một business system gồm nhiều JMS client thường là một JMS provider Ngoài ra, JMS client tạo ra thông điệp được gọi là message producer, còn JMS client nhận thông điệp được gọi... các ứng dụng tạo, gửi, nhận đọc các thông điệp, JMS • • • • API định nghĩa một tập những interface các ngữ nghĩa liên quan chung cho phép các chương trình viết bằng Java truyền thông được với nhau JMS API tối thiểu hóa các khái niệm mà lập trình viên phải học để có thể sử dụng được các sản phẩm gởi nhận thông điệp nhưng cung cấp đủ tính năng để hỗ trợ các ứng dụng gởi nhận thông điệp phức tạp JMS. .. trúc JMS API JMS provider: là hệ thống truyền thông điệp cài đặt các giao diện JMS cung cấp các tính năng kiểm soát quản trị JMS clients: là các chương trình hoặc các thành phần tạo ra xử lí các Thông điệp Các thông điệp (message): là các đối tượng mang thông tin trao đổi giữa các JMS clients Các đối tượng được quản trị (administered objects) được cấu hình từ ban đầu Đó là các đối tượng JMS. .. Phân phối bất đồng bộ nghĩa là bên gửi không cần phải đợi bên nhận nhận xử lý thông điệp; bên gửi có thể gửi thông điệp tiếp tục xử lý Các thông điệp bất đồng bộ được xem như các đơn vị tự chủ - mỗi thông điệp đều khép kín chứa tất cả dữ liệu cũng như trạng thái mà business logic xử lý nó cần đến Trong gởi nhận thông điệp bất đồng bộ, ứng dụng sử dụng một API đơn giản để tạo ra thông điệp, rồi... TopicConnectionFactory • Bắt đầu của 1 ứng dụng JMS client, bạn thường tiến hành tìm kiếm connection factory Destination • Một đích là một đối tượng được client sử dụng như nơi đến của thông điệp nó tạo ra nguồn của các thông điệp nó xử lí Với mô hình PTP, các đích được gọi là các hàng đợi còn trong mô hình pub/sub, các đích được gọi là topics • Một ứng dụng JMS có thể sử dụng nhiều queues topics Ví dụ sau: Các... factories các đích (destinations) Sessions (Các phiên) Message producers (gửi thông điệp) Message consumers(nhận thông điệp) Messages (các thông điệp) Hình 4.9: Các thành phân trong 1 ứng dụng JMS 4.3.4 Administered objects Có 2 bộ phận của một ứng dụng JMS là các đích connection factories phải luôn được duy trì kiểm soát Việc quản lí những đối tượng này thược về những tác vụ quản trị khác nhau thay đổi. .. phức tạp JMS API cho phép gởi nhận thông điệp không chỉ liên kết lỏng lẻo (loosely coupled) mà còn: Không đồng bộ: nhà cung cấp JMS có thể phân phát thông điệp cho máy khách khi có thông điệp; máy khách không cần yêu cầu các thông điệp mới nhận được chúng Tin cậy: JMS API có thể đảm bảo một thông điệp được phân phát một chỉ một lần 4.1 RPC gởi nhận thông điệp bất đồng bộ RPC (Remote Procedure Call)... Chương 5: Cấu tạo của một JMS message Chương này tập trung vào giải phẫu của một thông điệp : các bộ phận riêng lẻ tạo nên thông điệp (headers, properties, các loại khác nhau của tải trọng thông điệp) Message là phần quan trọng nhất của toàn bộ đặc điểm kỹ thuật JMS Tất cả dữ liệu sự kiện trong một ứng dụng JMS đều giao tiếp bằng những thông điệp , trong khi phần còn lại của JMS tồn tại để tạo thuận... chuyển giao các thông điệp Thông điệp cũng giống như mạch máu của hệ thống Một thông điệp JMS mang dữ liệu ứng dụng cung cấp các thông báo sự kiện Vai trò của nó là độc nhất trong điện toán phân tán Trong hệ thống dựa trên RPC (CORBA, Java RMI , DCOM), tin nhắn là một lệnh để thực hiện một phương pháp hoặc thủ tục, nó chặn bên gửi cho đến khi nhận được trả lời Một thông điệp JMS không phải là... Các mô hình gởi nhận thông điệp JMS hỗ trợ hai loại mô hình gởi nhận thông điệp: point-to-point publishand-subscribe Những mô hình gởi nhận thông điệp đôi khi được gọi là miền gởi nhận thông điệp (messaging domain) Gởi nhận thông điệp point-to-point publish-and-subscribe thường được viết tắt là p2p pub/sub Hiểu theo nghĩa đơn giản nhất, publish-and-subscribe là việc gởi thông điệp từ một tới . một thông điệp, tải các dữ liệu ứng dụng (tải trọng thông điệp), gán thông tin định tuyến, và gửi thông điệp. Cùng một API được sử dụng để nhận thông. được tạo ra bởi các ứng dụng khác. Trong tất cả các hệ thống gởi nhận thông điệp doanh nghiệp hiện đại, các ứng dụng trao đổi thông tin thông qua kênh ảo

Ngày đăng: 17/03/2014, 12:58

HÌNH ẢNH LIÊN QUAN

Hình 2.1: Phần mềm trung gian hướng thông điệp - Đồ án tìm hiểu JMS và viết ứng dụng trao đổi thông tin
Hình 2.1 Phần mềm trung gian hướng thông điệp (Trang 7)
Hình 2.2: Tính liên kết chặt chẽ của RMI - Đồ án tìm hiểu JMS và viết ứng dụng trao đổi thông tin
Hình 2.2 Tính liên kết chặt chẽ của RMI (Trang 8)
Hình 2.4: Kiến trúc tập trung hub-and-spoke - Đồ án tìm hiểu JMS và viết ứng dụng trao đổi thông tin
Hình 2.4 Kiến trúc tập trung hub-and-spoke (Trang 13)
Hình 2.5: Kiến trúc phân tán IP multicast - Đồ án tìm hiểu JMS và viết ứng dụng trao đổi thông tin
Hình 2.5 Kiến trúc phân tán IP multicast (Trang 14)
Hình 3.1: JMS messaging domains - Đồ án tìm hiểu JMS và viết ứng dụng trao đổi thông tin
Hình 3.1 JMS messaging domains (Trang 15)
Hình 4.2: RPC đồng bộ liên kết chặt chẽ - Đồ án tìm hiểu JMS và viết ứng dụng trao đổi thông tin
Hình 4.2 RPC đồng bộ liên kết chặt chẽ (Trang 22)
Hình 4.3: JMS cung cấp một môi trường liên kết lỏng lẻo để khi thành phần hệ thống bị lỗi cục bộ không cản trở hoạt động chung của hệ thống - Đồ án tìm hiểu JMS và viết ứng dụng trao đổi thông tin
Hình 4.3 JMS cung cấp một môi trường liên kết lỏng lẻo để khi thành phần hệ thống bị lỗi cục bộ không cản trở hoạt động chung của hệ thống (Trang 23)
Hình 4.4: Cơ chế store-and-forward đảm bảo thông điệp được phân phối - Đồ án tìm hiểu JMS và viết ứng dụng trao đổi thông tin
Hình 4.4 Cơ chế store-and-forward đảm bảo thông điệp được phân phối (Trang 24)
Hình 4.6 mô tả cách mà các bộ phận tương tác. Các công cụ quản trị cho phép bạn kết nối (bind) với các đích (destinations) và connection factories bên  trong không gian tên JNDI (Java Naming and Directory Interface) API - Đồ án tìm hiểu JMS và viết ứng dụng trao đổi thông tin
Hình 4.6 mô tả cách mà các bộ phận tương tác. Các công cụ quản trị cho phép bạn kết nối (bind) với các đích (destinations) và connection factories bên trong không gian tên JNDI (Java Naming and Directory Interface) API (Trang 26)
Hình 4.8: Pub/sub API - Đồ án tìm hiểu JMS và viết ứng dụng trao đổi thông tin
Hình 4.8 Pub/sub API (Trang 27)
Hình 4.9: Các thành phân trong 1 ứng dụng JMS - Đồ án tìm hiểu JMS và viết ứng dụng trao đổi thông tin
Hình 4.9 Các thành phân trong 1 ứng dụng JMS (Trang 28)
Hình 5.1: Cấu tạo một JMS message - Đồ án tìm hiểu JMS và viết ứng dụng trao đổi thông tin
Hình 5.1 Cấu tạo một JMS message (Trang 36)
7.1. Sơ đồ Use case - Đồ án tìm hiểu JMS và viết ứng dụng trao đổi thông tin
7.1. Sơ đồ Use case (Trang 69)

TỪ KHÓA LIÊN QUAN

w