SlideShare a Scribd company logo

Luận văn tìm hiểu Spring

An Nguyen, profile picture
An Nguyen

Luận văn này nghiên cứu về framework Spring và xây dựng ứng dụng quản lý nhạc phía client để giải quyết các vấn đề liên quan đến tỷ lệ thất bại cao trong các dự án phần mềm do sự phụ thuộc và chồng chéo giữa các thành phần. Tài liệu đề cập đến việc tạo ra các thành phần độc lập, dễ tái sử dụng và giới thiệu các công nghệ hiện tại như JMS, MongoDB, AngularJS, Bootstrap, trong quá trình phát triển hệ thống. Ứng dụng quản lý nhạc được thiết kế với hai module chính: module client và module server.

Technology
1 of 93
Downloaded 684 times
1
2
3
4
5
6
7
Most read
8
9
10
11
12
13
14
Most read
15
16
17
18
19
20
21
Most read
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
TRƯỜNG ĐẠI HỌC AN GIANG KHOA KỸ THUẬT - CÔNG NGHỆ - MÔI TRƯỜNG NGUYỄN THIỆN AN – DTH114081 KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC NGÀNH CÔNG NGHỆ THÔNG TIN TÌM HIỂU FRAMEWORK SPRING VÀ XÂY DỰNG ỨNG DỤNG QUẢN LÝ NHẠC PHÍA CLIENT AN GIANG – 05/2015
TRƯỜNG ĐẠI HỌC AN GIANG KHOA KỸ THUẬT - CÔNG NGHỆ - MÔI TRƯỜNG NGUYỄN THIỆN AN – DTH114081 KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC NGÀNH CÔNG NGHỆ THÔNG TIN TÌM HIỂU FRAMEWORK SPRING VÀ XÂY DỰNG ỨNG DỤNG QUẢN LÝ NHẠC PHÍA CLIENT Giảng viên hướng dẫn Thạc sĩ Huỳnh Lý Thanh Nhàn AN GIANG – 05/2015
iii LỜI CẢM ƠN Trước hết tôi xin tỏ lòng biết ơn sâu sắc đến Thạc sĩ Huỳnh Lý Thanh Nhàn, thầy đã tận tình hướng dẫn, giúp đỡ tôi rất nhiều trong suốt quá trình thực hiện luận văn này. Sự hiểu biết sâu sắc về khoa học cũng như kinh nghiệm của thầy chính là tiền đề giúp tôi hoàn thành luận văn. Tôi cũng xin chân thành cảm ơn Tiến sĩ Nguyễn Văn Hòa, thầy đã hướng dẫn và chỉ ra con đường tốt để tôi có thể được làm luận văn tại TMA và đồng thời học hỏi kinh nghiệm thực tế từ dự án đang hoạt động. Giúp tôi không còn bở ngỡ và lo lắng sau khi ra trường. Tôi chân thành cảm ơn quý thầy, cô Khoa Kỹ thuật – Công nghệ - Môi trường, Trường Đại học An Giang đã tận tình truyền đạt kiến thức trong bốn năm học tập. Với vốn kiến thức được tiếp thu trong quá trình học không chỉ là nền tảng cho quá trình nghiên cứu khóa luận mà còn là hành trang để tôi bước vào đời một cách vững chắc và tự tin. Tôi chân thành cảm ơn chị Nguyễn Ngọc Tuyền – giám đốc DC4 và anh Nguyễn Hải Âu – senior manager của TMA đã cho phép và tạo điều kiện thuận lợi để tôi được làm luận văn tại công ty. Đồng thời tôi xin gởi lời cảm ơn chân thành đến anh Nguyễn Hoàng Diệu là người đã giúp đỡ tôi rất nhiều về mặt kỹ thuật trong suốt thời gian tại TMA. Tôi cũng xin gửi lời cảm ơn đến các bạn lớp DH12TH đã chia sẽ và giúp đỡ tôi trong quá trình học tập tại Đại học An Giang. Đặc biệt tôi xin cảm ơn bạn Lê Thành Được đã cùng tôi nghiên cứu, làm việc nhóm trong suốt quá trình thực hiện luận văn. Cuối cùng, tôi xin cảm ơn chân thành với lòng biết ơn sâu sắc đến ba mẹ, chị hai và gia đình đã nuôi dưỡng và dạy bảo tôi nên người và tạo cho tôi có điều kiện tốt để được học tập và phát triển. Với vốn kiến thức hạn hẹp và thời gian thực hiện có hạn nên không tránh khỏi những thiếu sót. Rất mong nhận được những ý kiến đóng góp của quý thầy cô và anh chị trong TMA, đó sẽ là hành trang quý giá giúp tôi hoàn thiện kiến thức của mình sau này. Xin chân thành cảm ơn! An Giang, ngày 20 tháng 05 năm 2015 Sinh viên thực hiện Nguyễn Thiện An
iv NHẬN XÉT CỦA GIẢNG VIÊN HƯỚNG DẪN ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... Giảng viên hướng dẫn (Ký và ghi rõ họ tên) Nội dung nhận xét: - Đồng ý hay không đồng ý cho sinh viên báo cáo TTCK; Nếu không đồng ý cần ghi rõ lý do. - Kết quả đạt được so với yêu cầu. - Ý kiến khác (nếu có).
v TÓM TẮT Ngày nay tỷ lệ các dự án phần mềm thất bại hoặc không đáp ứng được các yêu cầu ban đầu là rất cao với hơn 83,8%. Bên cạnh đó chi phí cho việc bảo trì và mở rộng hệ thống luôn lớn hơn nhiều lần so với các pha khác trong quy trình phát triển một hệ thống. Một trong những nguyên nhân cơ bản nhất khiến các dự án thất bại là do các thành phần quá phụ thuộc lẫn nhau, chồng chéo, không có tính sử dụng lại. Vì vậy trong quy trình phát triển phần mềm hiện đại, xây dựng và phát triển một hệ thống bao giờ cũng đặt việc tạo ra các thành phần riêng rẽ độc lập, có sự phân biệt rõ ràng về trách nhiệm, có tính sử dụng lại cao lên làm ưu tiên hàng đầu. Tuy nhiên, điều này là không dễ dàng bởi tính độc lập của các thành phần sẽ bị giảm đi do cách mà chúng liên kết với nhau. Luận văn này sẽ tập trung tìm hiểu và giới thiệu sơ lược về Spring, những đặc tính vượt trội, ưu việt của nó trong việc tạo ra các ứng dụng đòi hỏi sự module hóa và có khả năng sử dụng lại cao. Đồng thời trình bày thêm về một số công nghệ như JMS, MongoDB, AngularJS, Bootstrap hiện đang được các công ty phần mềm sử dụng để cùng với Spring tạo nên một ứng dụng web enterprise. Sau khi tìm hiểu chúng tôi sẽ vận dụng kết quả tìm hiểu được vào việc xây dựng một ứng dụng nhằm mục đích minh họa cho phần lý thuyết đã trình bày. Chúng tôi sẽ xây dựng một ứng dụng quản lý nhạc trên nền web. Ứng dụng sẽ được thiết kế thành hai module chính là module client và module server. Trong luận văn này chúng tôi sẽ trình bày chi tiết phần thiết kế và xây dựng module client. Module server sẽ được đề cập trong luận văn của bạn Lê Thành Được.
vi ABSTRACT Nowadays, the percentage of software project fails or does not meets the original requirements which are very high with more than 83.3%. Besides, the cost for maintaining and expanding the system is much bigger than another phases of the process of developing a system. One of the most basic reasons for project failure is due to components that is too interdependent, overlapping and non-reusable. Therefore, in the process of modern software development, building and developing a system that always put the creative independent separating components, there is a clear distinction of responsibility, taking into using again high up as top priority. However, this is not easy because the independence of the components will be reduced by the way that it link together. These thesis will focus on understanding and briefing introduction about Spring framework, superior properties, outstanding features in creative application that requires modularizing and capacity of reusing high. Beside that, further description of some technologies such as JMS, MongoDB, AngularJS and Bootstrap which are currently software companies use to create a web application enterprise with Spring framework. After studying, we are going to use the result of the studying to build an application. It aims to illustrate the theoretical part presented. We are going to build a Music Manager application on the web. Application is going to be designed in two main modules: client module and server module. In this thesis we will present about details of the designing and building client module. Server module is going to be discussed in thesis of Le Thanh Duoc.
vii MỤC LỤC LỜI CẢM ƠN ........................................................................................................ iii NHẬN XÉT CỦA GIẢNG VIÊN HƯỚNG DẪN ................................................iv TÓM TẮT ................................................................................................................v ABSTRACT............................................................................................................vi MỤC LỤC............................................................................................................. vii DANH MỤC HÌNH................................................................................................ix DANH MỤC BẢNG...............................................................................................xi DANH SÁCH TỪ VIẾT TẮT.............................................................................. xii Chương 1 TỔNG QUAN ..................................................................................1 1.1 LÝ DO CHỌN ĐỀ TÀI............................................................................1 1.2 ĐẶT VẤN ĐỀ VÀ HƯỚNG GIẢI QUYẾT...........................................2 1.3 PHẠM VI ĐỀ TÀI....................................................................................3 1.4 PHƯƠNG PHÁP NGHIÊN CỨU............................................................4 1.5 BỐ CỤC LUẬN VĂN..............................................................................4 Chương 2 CƠ SỞ LÝ THUYẾT.......................................................................5 2.1 NGÔN NGỮ LẬP TRÌNH JAVA............................................................5 2.1.1 Java và lịch sử phát triển..................................................................5 2.1.2 Java Reflection .................................................................................5 2.2 SPRING FRAMEWORK.........................................................................9 2.2.1 Tổng quan về Spring ........................................................................9 2.2.2 Lịch sử phát triển..............................................................................9 2.2.3 Một số khái niệm chính..................................................................10 2.2.4 Các module.....................................................................................14 2.2.5 Spring Core.....................................................................................15 2.2.6 Spring MVC ...................................................................................27 2.2.7 Spring Security...............................................................................34 2.3 JAVA MESSAGE SYSTEM (JMS) ......................................................37 2.3.1 Hệ thống gửi nhận thông điệp (messaging system).......................37 2.3.2 Tổng quan về JMS..........................................................................38 2.3.3 Các mô hình gửi nhận thông điệp trong JMS................................39 2.4 ANGULARJS .........................................................................................41 2.4.1 Tổng quan về AngularJS................................................................41 2.4.2 Các đặc trưng của AngularJS.........................................................42
viii 2.5 MONGODB............................................................................................46 2.5.1 Tổng quan về NoSQL ....................................................................46 2.5.2 MongoDB .......................................................................................48 2.6 BOOTSTRAP VÀ RESPONSIVE.........................................................49 Chương 3 THIẾT KẾ VÀ CÀI ĐẶT CHƯƠNG TRÌNH..............................50 3.1 MÔ HÌNH ỨNG DỤNG ........................................................................50 3.2 THIẾT KẾ MESSAGE...........................................................................53 3.3 THIẾT KẾ CƠ SỞ DỮ LIỆU.................................................................54 3.4 RESTful API...........................................................................................56 3.5 CƠ CHẾ BẢO MẬT ỨNG DỤNG........................................................57 3.6 SƠ ĐỒ USECASE..................................................................................57 3.7 GIAO DIỆN VÀ CHỨC NĂNG............................................................60 3.7.1 Một số giao diện chính...................................................................60 3.7.2 Một số chức năng nổi bật của ứng dụng........................................64 Chương 4 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN.....................................66 4.1 KẾT QUẢ ĐẠT ĐƯỢC.........................................................................66 4.2 HẠN CHẾ...............................................................................................66 4.3 HƯỚNG PHÁT TRIỂN .........................................................................66 TÀI LIỆU THAM KHẢO .....................................................................................67 PHỤ LỤC 1: HƯỚNG DẪN TRIỂN KHAI ỨNG DỤNG..................................68 PHỤ LỤC 2: GIỚI THIỆU MAVEN....................................................................77
ix DANH MỤC HÌNH Hình 1.1: Chi phí cho các pha phát triển một hệ thống...........................................1 Hình 2.1: Kiến trúc tổng quát Java Reflaction API.................................................6 Hình 2.2: Luồng điều khiển của chương trình bình thường..................................11 Hình 2.3: Servlet Container ...................................................................................12 Hình 2.4: Kiểm thử đơn vị với JUnit.....................................................................12 Hình 2.5: Mô hình ứng dụng áp dụng IoC ............................................................13 Hình 2.6: Các module của Spring framework.......................................................14 Hình 2.7: Singleton scope......................................................................................18 Hình 2.8: Prototype scope......................................................................................19 Hình 2.9: Spring IoC Container.............................................................................20 Hình 2.10: Kiến trúc module Spring MVC ...........................................................27 Hình 2.11: Sơ đồ luồng xử lý của Spring MVC....................................................28 Hình 2.12: Luồng xử lý một request trong Spring MVC......................................29 Hình 2.13: Mô hình hệ thống gửi nhận thông điệp...............................................37 Hình 2.14: Mô hình tổng quát JMS .......................................................................39 Hình 2.15: Hai mô hình gửi nhận message trong JMS .........................................40 Hình 2.16: Mô hình point - to - point ....................................................................40 Hình 2.17: Mô hình publish - subscribe ................................................................41 Hình 2.18: Single Page Application ......................................................................42 Hình 2.19: Kiến trúc MVC trong AngularJS.........................................................43 Hình 2.20: One-way binding và Two-way binding...............................................43 Hình 3.1: Mô hình ứng dụng .................................................................................50 Hình 3.2: Mô hình chi tiết của ứng dụng...............................................................51 Hình 3.3: Luồng thực thi của ứng dụng.................................................................52 Hình 3.4: Module client .........................................................................................53 Hình 3.5: Sơ đồ class Message ..............................................................................54 Hình 3.6: Document trong giao diện RoboMongo................................................55 Hình 3.7: RESTful API về bài hát.........................................................................56 Hình 3.8: RESTful API về user .............................................................................56 Hình 3.9: Cơ chế bảo mật ứng dụng......................................................................57 Hình 3.10: Sơ đồ use case của actor user ..............................................................58 Hình 3.11: Sơ đồ use case của actor Role_User....................................................59 Hình 3.12: Sơ đồ use case của actor Role_Admin ................................................59 Hình 3.13: Giao diện đăng ký người dùng............................................................60 Hình 3.14: Giao diện đăng nhập............................................................................60 Hình 3.15: Giao diện play nhạc .............................................................................61 Hình 3.16: Giao diện bài hát được chia sẻ.............................................................61 Hình 3.17: Giao diện danh sách bài hát.................................................................61 Hình 3.18: Giao diện tìm kiếm bài hát ..................................................................62 Hình 3.19: Giao diện sửa thông tin bài hát............................................................62 Hình 3.20: Giao diện sửa thông tin user................................................................62 Hình 3.21: Giao diện quản lý user.........................................................................63 Hình 3.22: Giao diện thống kê các thông tin.........................................................63 Hình 3.23: Giao diện đổi password .......................................................................63
x Hình 3.24: Giao diện sửa thông tin user của admin..............................................64 Hình 3.25: Email kích hoạt tài khoản khi đăng ký thành công.............................64 Hình 3.26: Tài khoản trước và sau khi kích hoạt ..................................................64 Hình 3.27: Ứng dụng với ngôn ngữ Tiếng Việt ....................................................65 Hình 3.28: Ứng dụng với ngôn ngữ Tiếng Anh ....................................................65
xi DANH MỤC BẢNG Bảng 2-1: Phạm vi của bean ..................................................................................17 Bảng 2-2: So sánh các thành phần giữa RDBMS và MongoDB ..........................48 Bảng 3-1: Danh sách các actor ..............................................................................57 Bảng 3-2: Danh sách các usecase..........................................................................57
xii DANH SÁCH TỪ VIẾT TẮT AJAX Asynchronous JavaScript and XML AOP Aspect – oriented programming API Application programming interface CSDL Cở sở dữ liệu DAO Data Access Object DI Dependency Injection DOM Document Object Model EJB Enterprise Java Bean HTML HyperText Markup Language IoC Inversion of Control JSM Java Message System JVM Java Virtual Machine MOM Message - Oriented Middleware OOP Object – oriented programming ORM Object Relational Mapping POJO Plain Old Java Object RDBMS Relational database management system SPA Single page application URL Uniform Resource Locator
1 Chương 1 TỔNG QUAN 1.1 LÝ DO CHỌN ĐỀ TÀI Trong một khảo sát với khoảng 8.000 dự án phần mềm, Standish Group cho biết có chỉ có 16.2% dự án là hoàn thành đúng hạn và nằm trong giới hạn ngân sách, đáp ứng đầy đủ tất cả các tính năng như cam kết ban đầu. Và hơn 83.8% dự án thất bại hoặc không đáp ứng được những yêu cầu ban đầu, trong đó có tới 52.7% dự án được hoàn thành và đi vào hoạt động nhưng không hoàn thành đúng hạn và bội chi, thêm nữa không đáp ứng đầy đủ tính năng và đặt tính như thiết kế ban đầu. Bên cạnh đó chi phí cho việc bảo trì và mở rộng hệ thống luôn lớn hơn nhiều lần so với các pha khác trong quy trình phát triển một hệ thống. Những rủi ro dẫn đến hủy hoặc đình trệ của các dự án phần mềm tăng nhanh tỉ lệ thuận với việc gia tăng kích thước của dự án; 25% với các dự án > 100.000 LOC (line of code), 50% với các dự án > 500.000 LOC và 65% với các dự án > 1.000.000 LOC. Việc phát triển các hệ thống với hơn 5.000 function point (tương đương 500.000 LOC) được xem là một trong những nhiệm vụ rủi ro nhất. Một trong những nguyên nhân cơ bản nhất để các dự án thất bại là do các thành phần quá phụ thuộc lẫn nhau, chồng chéo, không có tính sử dụng lại. Vì vậy trong quy trình phát triển phần mềm hiện đại, xây dựng và phát triển một hệ thống bao giờ cũng đặt việc tạo ra các thành phần riêng rẽ độc lập, có sự phân biệt rõ ràng về trách nhiệm, có tính sử dụng lại cao lên làm ưu tiên hàng đầu. Bởi vì một khi đã tạo ra các thành phần như vậy, chúng ta sẽ tiết kiệm được rất nhiều thời gian và công sức trong quá trình bảo trì và mở rộng hệ thống sau này. Tuy nhiên, điều này quả là không dễ dàng bởi vì tính độc lập của các thành phần sẽ bị giảm đi do cách các thành phần liên kết với nhau. Mặt khác, ngày nay hầu hết các hệ thống đều được phát triển trên nền web bởi vì các ứng dụng web đem lại khả năng phát triển và triển khai sản phẩm nhanh chóng, giảm thời gian đưa sản phẩm ra thị trường, có khả năng cập nhật tính năng liên tục hàng ngày. 3 3 5 7 15 67 Xác định yêu cầu Đặt tả Thiết kế Lập trình Kiểm thử Bảo trì Hình 1.1: Chi phí cho các pha phát triển một hệ thống
2 Ứng dụng web có thời gian phát triển nhanh, với chi phí phát triển và triển khai thấp, tin cậy, có thể truy cập từ bất cứ đâu, mọi người có thể sử dụng mà không mất thời gian tìm hiểu nhờ giao diện trực quan. Hơn nữa công nghệ di động đang ngày càng trở nên phổ biến, trong những năm gần đây số lượng người sử dụng và truy cập qua các thiết bị di động tăng một cách nhanh chóng, xu hướng thiết kế và viết các ứng dụng thích hợp với các thiết bị di động đang trở thành một xu hướng tất yếu. Các hệ thống đã được phát triển để có thể sẵn sàng cho các trang web phù hợp với thiết bị di động và các ứng dụng trên thiết bị di động. Chính vì những lý do trên nên chúng tôi chọn đề tài “Tìm hiểu Framework Spring và xây dựng ứng dụng quản lý nhạc phía client”. Nội dung luận văn này sẽ tập trung tìm hiểu và giới thiệu về Spring, một framework với những đặc tính vượt trội và ưu việt trong việc tạo ra các hệ thống đòi hỏi sự module hóa và có khả năng sử dụng lại cao. Đồng thời tìm hiểu thêm một số framework và kỹ thuật khác hiện đang được các công ty phần mềm sử dụng để tích hợp với Spring tạo nên một ứng dụng web enterprise như: AngularJS, Bootstrap, JMS, MongoDB. 1.2 ĐẶT VẤN ĐỀ VÀ HƯỚNG GIẢI QUYẾT Mặc dù EJB được sử dụng rộng rãi, tuy nhiên nó có một số hạn chế như khả năng sử dụng lại code thấp tạo gánh nặng cho việc phát triển [1, tr1]. Spring framework khi sử dụng với JavaEE làm cho quá trình phát triển ứng dụng enterprise dễ dàng hơn [1, tr1]. Do đó Spring framework ra đời như là một lựa chọn thay thế cho mô hình chuẩn EJB [4, tr1] đã đánh dấu một bước ngoặt trong lịch sử phát triển của Enterprise Java. Spring là một trong những framework của Java được sử dụng phổ biến nhất tính đến thời điểm này. Và nó được giới thương mại công nhận như một nền tảng kiến trúc có tầm quan trọng trong chiến lược kiến tạo phần mềm chính là do framework này có cách tạo và liên kết các thành phần rất riêng và hữu ích. Trong các hệ thống lớn việc xây dựng các thành phần một cách độc lập, riêng rẽ là một yêu cầu quan trọng và nó phụ thuộc rất lớn vào việc lựa chọn công nghệ và kỹ thuật để phát triển hệ thống này. Tính độc lập, riêng rẽ giữa các thành phần được xem xét trên 2 khía cạnh khác nhau. Một là xét về khía cạnh mã nguồn (code). Giảm sự kết dính của code (writing loosely coupled code) có nghĩa là sự phụ thuộc, liên kết giữa các class, đối tượng trong hệ thống càng “lỏng lẻo” (loosely coupled) càng tốt. Để giải quyết cho việc “writing loosely coupled code” thì có khá nhiều kĩ thuật nổi tiếng như là: Dependencies Injection, Isolate Dependencies, Reversing Dependencies. Và Spring là một trong những framework mạnh về Dependencies Injection. Ngoài ra Spring là một framework mạnh trong việc xây dựng các ứng dụng enterprise. Nó cũng có thể dễ dàng tích hợp với các framework khác Struts, Hibernate làm cho việc phát triển các ứng dụng enterprise hiệu quả hơn do đó làm giảm sự phụ thuộc và có sự tách biệt rõ ràng giữa các thành phần [1, tr8]. Hai là xét về khía cạnh các thành phần, module trong hệ thống. Nền tảng cơ bản của việc thiết kế hướng đối tượng là việc các đối tượng thao tác với nhau qua việc gửi thông điệp (sending message). Do đó việc thiết kế một phần mềm sẽ xoay quanh việc
3 chúng ta thiết kế sao cho các thành phần, module giao tiếp thông qua một giao diện mà không cần phải biết quá nhiều về nhau và phụ thuộc lẫn nhau. Để giải quyết vấn đề này chúng tôi áp dụng mô hình hệ thống gửi nhận thông điệp để làm thành phần giao tiếp giữa các module trong các hệ thống. Áp dụng mô hình gửi nhận thông điệp sẽ giúp cho nhiều thành phần dễ dàng giao tiếp với nhau và giảm sự phụ thuộc vào nhau rất nhiều. Trong luận văn này chúng tôi sẽ trình bày về Java Message System (JMS) như là một công nghệ áp dụng cho việc xây dựng hệ thống gửi nhận thông điệp. Ngày nay khi dịch vụ web bùng nổ phần lớn các hệ thống đều được xây dựng trên nền tảng như một ứng dụng web hơn là các ứng dụng chạy độc lập trên các máy tính cá nhân. Tuy nhiên một trong những giới hạn của các ứng dụng web là cách thức nó tương tác với người dùng. Khác với các ứng dụng desktop có những khả năng dường như vô tận trong cách thức tương tác với người dùng. Các ứng dụng web tương tác với người dùng chậm hơn so với các ứng dụng desktop bởi chính nguyên lý hoạt động của nó: tất cả các giao dịch phải thực hiện thông qua giao thức HTTP. Việc áp dụng công nghệ Ajax đóng vai trò cốt lõi thực hiện các tương tác trung gian giữa người dùng và máy chủ sẽ giúp chúng ta khắc phục một phần hạn chế này. Và để mang lại cho người dùng trải nghiệm giống như trên ứng dụng desktop một số framework JavaScript sẽ giúp chúng ta phát triển ứng dụng web dạng SPA. Trong luận văn này chúng tôi sẽ trình bày về AngularJS và áp dụng framework này để xây dựng một ứng dụng web minh họa. Ngày nay với số lượng người dùng các thiết bị di động ngày càng tăng, những hệ thống được triển khai trên nền web luôn đảm bảo yêu cầu là phải thích nghi được trên từng loại thiết bị di động này nhằm tăng thêm thị phần, tạo sự thuận lợi cho người dùng. Viêc hiển thị bố cục phù hợp cho từng loại thiết bị sẽ do CSS hoặc Javascript đảm nhận việc nhận diện kích thước màn hình và hiển thị với thiết lập CSS của giao diện dành cho thiết bị đó. Trong luận văn này chúng tôi sẽ sử dụng Bootstrap để thiết kế giao diện responsive. 1.3 PHẠM VI ĐỀ TÀI Luận văn sẽ tập trung trình bày kết quả nghiên cứu của chúng tôi về các nội dung sau: Spring framework, Java Message System, AngularJS framework, MongoDB, Boostrap và Maven. Mỗi phần chúng tôi sẽ giới thiệu sơ lược và trình bày những nội dung cơ bản nhất, những điểm mạnh hay lợi ích mà nó mang lại cho các nhà phát triển phần mềm. Cụ thể về Spring framework chúng tôi sẽ tập trung tìm hiểu và trình bày 3 module: Spring core, Spring MVC và Spring Security. Một số module khác được trình bày trong luận văn của bạn Lê Thành Được. Sau khi tìm hiểu chúng tôi sẽ vận dụng kết quả tìm hiểu được vào việc xây dựng một ứng dụng nhằm mục đích minh họa cho phần lý thuyết đã trình bày. Chúng tôi sẽ xây dựng một ứng dụng quản lý nhạc trên nền web. Ứng dụng sẽ được thiết kế thành 2 module chính là module client và module server. Trong luận văn này chúng tôi sẽ trình
4 bày phần thiết kế và xây dựng module client. Module server sẽ được trình bày trong luận văn của bạn Lê Thành Được. 1.4 PHƯƠNG PHÁP NGHIÊN CỨU Tìm kiếm và nghiên cứu các tài liệu về Spring Framework và các công nghệ có liên quan đến việc phát triển một ứng dụng web enterprise như JMS, AngularJS, MongoDB, Maven của các tác giả trong và ngoài nước, các bài báo, thông tin trên mạng,… sau đó chọn lọc và sắp xếp lại theo ý tưởng của mình. Dựa trên kết quả tìm hiểu được để xây dựng một ứng dụng web quản lý nhạc có áp dụng tất cả những nội dung đã nghiên cứu nhằm mục đích minh họa cho phần cơ sở lý thuyết sẽ trình bày trong nội dung luận văn này. 1.5 BỐ CỤC LUẬN VĂN Trong phần này chúng tôi sẽ trình bày ngắn gọn về nội dung chính của từng phần trong luận văn nhằm giúp cho người đọc dễ dàng theo dõi. Chương 1: Giới thiệu tổng quan về cơ quan thực tập; lý do và tính cấp thiết để thực hiện đề tài này. Trong chương này còn trình bày về các vấn đề cụ thể cần phải giải quyết và hướng giải quyết cho từng vấn đề; phạm vi cũng như phương pháp nghiên cứu đề tài. Chương 2: Trình bày về cơ sở lý thuyết được sử dụng trong đề tài bao gồm các nội dung về ngôn ngữ lập trình Java, Spring framework, Java Message System, AngularJS, MongoDB và Bootstrap: - Trong phần Spring framework chúng tôi sẽ giới thiệu sơ lược về framework này và một số khái niệm liên quan, tiếp theo sẽ trình bày về 3 module là Spring Core, Spring MVC và Spring Security. - Phần Java Message System sẽ giới thiệu tổng quan về hệ thống gửi nhận thông điệp, về JMS và 2 mô hình gửi nhận thông điệp trong JMS. - Phần AgularJS sẽ trình bày tổng quan về framework này và những đặc trưng nổi bật của nó. - Phần tiếp theo trình bày về NoSQL, các dạng của NoSQL; giới thiệu về MongoDB và ưu điểm của hệ quản trị CSDL này. - Phần cuối cùng sẽ giới thiệu về Bootstrap và tính năng responsive mà Bootstrap hỗ trợ trong việc xây dựng giao diện người dùng cho ứng dụng web. Chương 3: Sau khi tìm hiểu về Spring, JMS, AngularJS, MongoDB và Bootstrap chương này trình bày phần phân tích, thiết kế và cài đặt ứng dụng quản lý nhạc phía client sử dụng các công nghệ vừa nêu. Chương 4: Những kết quả đạt được, thảo luận những vấn đề khó khăn và đưa ra hướng phát triển trong tương lai. Phần cuối cùng là tài liệu tham khảo và một số phụ lục về hướng dẫn triển khai ứng dụng; phụ lục giới thiệu về Maven.
5 Chương 2 CƠ SỞ LÝ THUYẾT 2.1 NGÔN NGỮ LẬP TRÌNH JAVA 2.1.1 Java và lịch sử phát triển Java là một ngôn ngữ lập trình dạng lập trình hướng đối tượng (OOP). Khác với phần lớn ngôn ngữ lập trình thông thường, thay vì biên dịch mã nguồn thành mã máy hoặc thông dịch mã nguồn khi chạy, Java được thiết kế để biên dịch mã nguồn thành bytecode, bytecode sau đó sẽ được môi trường thực thi (runtime environment) chạy. Cú pháp Java được vay mượn nhiều từ C và C++ nhưng có cú pháp hướng đối tượng đơn giản hơn và ít tính năng xử lý cấp thấp hơn. Do đó việc viết một chương trình bằng Java dễ hơn, đơn giản hơn, đỡ tốn công sửa lỗi hơn. Java được khởi đầu bởi James - Gosling và bạn đồng nghiệp ở Sun Microsystems năm 1991. Ban đầu ngôn ngữ này được gọi là Oak (có nghĩa là cây sồi) do bên ngoài cơ quan của ông Gosling có trồng nhiều loại cây này. Java được phát hành vào năm 1994. Sau khi Oracle mua lại công ty Sun Microsystems năm 2009 - 2010, Oracle đã mô tả họ là "người quản lý công nghệ Java với cam kết không ngừng để bồi dưỡng một cộng đồng tham gia và minh bạch". Lịch sử phiên bản java:  JDK 1.0 (23 tháng 01, 1996)  JDK 1.1 (19 tháng 2, 1997)  J2SE 1.2 (Playground) 08 tháng 12, 1998  J2SE 1.3 (Kestrel) 08 tháng 5, 2000  J2SE 1.4.0 (Merlin) 06 tháng 02, 2002  J2SE 5 (1.5.0) (Tiger) 30 tháng 9, 2004  Java SE 6 (còn gọi là Mustang), được công bố 11 tháng 12 năm 2006.  Java SE 7 (còn gọi là Dolphin), được bắt đầu từ tháng 8 năm 2006 và công bố ngày 28 tháng 7 năm 2011.  JDK 8, 18 tháng 3 năm 2014  Phiên bản dự kiến tiếp theo: Java 9 dự kiến ra đời năm 2016 2.1.2 Java Reflection Trong phần này sẽ trình bày về Reflection trong Java. Java reflection là nền tảng cho cách thức làm việc của tất cả các dependency injection framework trong Java như Dagger, Google Guice, PicoContainer và Spring, chính vì vậy việc hiểu về Java reflection sẽ giúp chúng ta dễ dàng tiếp cận Spring hơn. Reflection là kĩ thuật rất cần thiết để lấy các thông tin của một kiểu dữ liệu. Dựa vào đó ta có thể kích hoạt (gọi các phương thức) hoặc tạo thể hiện của kiểu dữ liệu đó. Một ứng dụng quan trọng của reflection mà chúng ta có thể biết là Java Bean. Nhờ đó, các IDE (như NetBeans) hoặc các framework có thể lấy được các thông tin và thiết lập giá trị cho các đối tượng trong môi trường run-time. Kiến trúc của Java Reflection API
6 Các lớp được dùng trong reflection nằm trong hai package là java.lang và java.lang.reflect. Package java.lang.reflect bao gồm ba lớp chính mà chúng ta cần biết là Constructor, Field và Method: - Class<T>: Lớp này đại diện cho các lớp, interface và chứa các phương thức dùng để lấy các đối tượng kiểu Constructor, Field, Method. - AccessibleObject: Các kiểm tra về phạm vi truy xuất (public, private, protected) của field, method, constructor sẽ được bỏ qua. Nhờ đó chúng ta có thể dùng reflection để thay đổi, thực thi các thành phần này mà không cần quan tâm đến phạm vi truy xuất của nó. - Constructor: Chứa các thông tin về một constructor của lớp. - Field: chứa các thông tin về một field của lớp, interface. - Method: chứa các thông tin về một phương thức của lớp, interface. Dưới đây là một ví dụ đơn giản dùng để in ra thông tin của một lớp trong môi trường run time chỉ cần chúng ta biết được tên đầy đủ (bao gồm cả phần package) của lớp đó. Giả sử chúng ta có class User như sau: User.java package com.nthienan; public class User { private String username; private String password; public User() { } public User(String username, String password) { this.username = username; this.password = password; } public void printHello(String fullName){ System.out.println("Hello" + fullName); } Hình 2.1: Kiến trúc tổng quát Java Reflaction API
7 Hàm main như sau: public String getUsername() { return username; } public void setUsername(String username) { this.username = username; } public String getPassword() { return password; } public void setPassword(String password) { this.password = password; } } Main.java package com.nthienan; import java.lang.reflect.Constructor; import java.lang.reflect.Field; import java.lang.reflect.Method; public class Main { public static void main(String[] args) { try { Class<?> c = Class.forName("com.nthienan.User"); System.out.println("*****Class name*****"); System.out.println("Name: " + c.getName()); System.out.println("Simple name: " + c.getSimpleName()); Field[] fields = c.getDeclaredFields(); System.out.println("n*****Field*****"); for (Field f : fields) { System.out.println(f); } Constructor[] constructors = c.getConstructors(); System.out.println("n*****Constructor*****"); for (Constructor constructor : constructors) { System.out.println(constructor); } Method[] methods = c.getDeclaredMethods(); System.out.println("*****Method*****"); for (Method m : methods) { System.out.println(m); } } catch (ClassNotFoundException e) { e.printStackTrace(); } }
8 Kết quả: Chúng ta có thể tạo ra một thể hiện (instance) của class này một cách dễ dàng bằng một trong hai cách như ví dụ sau. Vì phương thức newInstance( ) trả về một đối tượng kiểu Object nên cần phải ép kiểu đối tượng này về kiểu User. Để thực thi một phương thức cụ thể, chúng ta cần sử dụng hai phương thức sau: Class.getMethod(String name, Class[] parameterTypes): trả về đối tượng Method đại diện cho một phương thức của lớp. Phương thức này được xác định qua tên và các kiểu tham số. Method.invoke(Object obj, Object[] args) thực thi phương thức tương ứng của đối tượng obj với các tham số args. Ví dụ sau thực thi phương thức printHello(String fullName) của lớp User bằng cách tạo một đối tượng User và truyền vào làm tham số đầu tiên trong phương thức Method.invoke( ). Nếu phương thức printHello( ) là static chỉ cần truyền null vào làm tham số đầu tiên của phương thức Method.invoke( ). } *****Class name***** Name: com.nthienan.User Simple name: User *****Field***** private java.lang.String com.nthienan.User.username private java.lang.String com.nthienan.User.password *****Contructor***** public com.nthienan.User() public com.nthienan.User(java.lang.String,java.lang.String) *****Method***** public java.lang.String com.nthienan.User.getPassword() public void com.nthienan.User.printHello(java.lang.String) public void com.nthienan.User.setPassword(java.lang.String) public java.lang.String com.nthienan.User.getUsername() public void com.nthienan.User.setUsername(java.lang.String) Class<?> c = Class.forName("com.nthienan.User"); //tạo một đối tượng với constructor không có tham số User instance = (User) c.newInstance(); //tạo đối tượng với constructor có tham số Constructor<?> con = c.getConstructor(String.class, String.class); User instance1 = (User) con.newInstance("nthienan", "123"); //tạo một đối tượng với constructor không có tham số User instance = (User) c.newInstance();
9 Kết quả: 2.2 SPRING FRAMEWORK 2.2.1 Tổng quan về Spring Spring framework, hay ngắn hơn là Spring, là một cấu trúc dùng để xây dựng chương trình ứng dụng mã nguồn mở dành cho ngôn ngữ lập trình Java. Phiên bản đầu tiên của nó do Rod Johnson viết và đã được ông xuất bản cùng với quyển sách đầu tay Expert One-on-One JavaEE Design and Development (Nhà xuất bản Wrox Press, Tháng 10 năm 2002). Kiến trúc của Spring framework được ra mắt công chúng lần đầu tiên hồi tháng 6 năm 2003 dưới Giấy phép Apache - phiên bản 2.0. Phiên bản 1.0 đánh dấu mốc thành đạt đầu tiên được xuất bản vào tháng 3 năm 2004 và tiếp đó vào tháng 9 năm 2004, tháng 3 năm 2005. Tuy Spring framework không bắt buộc người ta phải tuân theo một mô hình lập trình cụ thể nào, song nó lan truyền rộng rải trong cộng đồng những người viết chương trình dùng Java, như một hình thức chủ yếu thay thế cho mô hình Enterprise Java Bean. Theo thiết kế, bộ framework này giải phóng lập trình viên dùng Java, cho phép họ nhiều quyền tự do hơn và đồng thời cung cấp một giải pháp tiện lợi, đầy đủ dẫn chứng bằng tài liệu, dễ dàng sử dụng, phù hợp với những thực hành thông dụng trong công nghệ phần mềm. Bên cạnh những đặc trưng nền tảng của Spring framework là những cái có thể dùng được trong bất cứ một chương trình ứng dụng Java nào, rất nhiều các mở rộng và tiến bộ trong việc kiến tạo các trình ứng dụng dành cho nền tảng mạng web (web-based application) dựa trên nền Java Enterprise cũng tồn tại nữa. Spring framework nổi tiếng cũng một phần do chính đặc thù kể trên và được giới thương mại công nhận như một nền tảng kiến trúc có tầm quan trọng trong chiến lược kiến tạo phần mềm. 2.2.2 Lịch sử phát triển Phần đầu tiên của Spring framework ban đầu nguyên được Rod Johnson viết vào năm 2000. Vào năm 2001, những mô hình lập trình cho các trình ứng dụng Web được đại đa số sử dụng đều do Java Servlet API và Enterprise Java Bean cung cấp. Năm 2003 thành lập dự án phát tại Sourceforge để phát triển Spring. Sau khi phát triển trên nền tảng ban đầu hơn một năm họ đã phát hành phiên bản đầu tiên (1.0) vào tháng 3 năm 2004. Spring framework đã làm cho những kỹ thuật vốn không được biết đến mấy trở nên những kỹ thuật được mọi người ưa chuộng trong một thời gian ngắn ngủi. Một trong Method method = c.getMethod("printHello", String.class); method.invoke(instance, "World"); Hello World
10 những kỹ thuật nổi tiếng hơn cả là kỹ thuật “đảo ngược quyền điều khiển” (Inversion of Control, IoC). Năm 2005 cho thấy mức độ hưởng ứng nâng cao hơn những năm trước, nguyên do cũng vì những phiên bản mới được giới thiệu với những cột mốc đáng kể và những tính năng mới được thêm vào. Diễn đàn Spring (Spring Forum) ra đời cuối năm 2004 cũng góp phần không nhỏ trong việc nâng cao tính phổ biến của bộ framework và từ đó đến nay đã sinh trưởng trở thành một nguồn thông tin quan trọng, giúp đỡ cho người sử dụng. Vào tháng 12 năm 2005, hội thảo đầu tiên về Spring Framework đã được tổ chức tại Miami, Florida thu hút 300 nhà phát triển trong 3 ngày và tiếp theo đó cuộc hội thảo ở Antwerp vào tháng 6 năm 2006, thu hút hơn 400 người. 2.2.3 Một số khái niệm chính Hai trong những thành phần chủ chốt và là nền tảng tạo nên sức mạnh của Spring chính là IoC và DI. 2.2.3.1 Inversion of Control (IoC) IoC Container trong Spring được xây dựng dựa trên nguyên lý Inversion of Control (đảo ngược điều khiển) đã xuất hiện khá lâu trong các mẫu hình thiết kế (design pattern), và được phổ biến rộng rãi nhờ Robert C. Martin và Martin Fowler. Để hiểu về Spring, trước tiên chúng ta cần hiểu khái niệm IoC là gì? Muốn vậy, chúng ta cần trả lời câu hỏi: Control (điều khiển) trong chương trình phần mềm là gì, và Inversion (sự đảo ngược) đối với điều khiển trong ngữ cảnh này được hiểu như thế nào? Khái niệm Control Flow (tạm dịch là luồng thực thi) được sử dụng cho trình tự thực hiện các câu lệnh, chỉ thị hoặc lời gọi hàm trong một chương trình, khi chương trình này thực thi. Do chương trình ngày càng phức tạp, nên các lập trình viên áp dụng phương pháp lập trình hướng đối tượng nhằm phân loại, chia tách các chức năng và gom thành các đối tượng. Các lập trình viên còn tạo dựng các thư viện tạo sẵn để có thể sử dụng lại. Luồng thực thi của chương trình, trong những tình huống cần xem xét ở mức tổng thể, không còn quan tâm đến các bước thực thi câu lệnh cụ thể nữa, mà chỉ xem xét đến quá trình gọi phương thức của các đối tượng trong ứng dụng cũng như các đối tượng của thư viện dựng sẵn. Các lập trình viên, khi xây dựng ứng dụng từ đầu, đã thực hiện hai nhiệm vụ: trực tiếp điều khiển luồng thực thi của chương trình và xây dựng các chức năng để đáp ứng nghiệp vụ của ứng dụng. Thực tế, có nhiều chương trình hoặc bộ phận trong chương trình có luồng thực thi rất giống nhau, chẳng hạn phần tương tác với HTTP trong các ứng dụng web, phần unit testing trong các ứng dụng,… Việc trực tiếp tạo dựng và kiểm soát luồng thực thi của chương trình lặp đi lặp lại khi xây dựng nhiều ứng dụng sẽ làm mất nhiều công sức, chi phí, tạo ra sự nhàm chán và dễ phát sinh lỗi. Điều này tạo ra động lực cũng như môi trường để nguyên lý đảo ngược điều khiển nảy nở và phát triển.
11 Vậy sự “đảo ngược” (inversion) luồng điều khiển chương trình trong ngữ cảnh này được hiểu như thế nào? Chúng ta hãy xem xét 2 ví dụ dưới đây. Ví dụ 1: Ứng dụng web trong Java với JavaServlet Khi lập trình ứng dụng web bằng JavaServlet cần thực hiện các bước lập trình như sau: - Tạo lớp đối tượng kế thừa từ HttpServlet, override các phương thức doGet(), doPost(),… - Đăng ký trong file cấu hình Deployment Descriptor tương ứng Servlet này với đường dẫn xác định. - Lớp đối tượng Servlet chúng ta tạo ra sẽ được gọi đến khi có một truy vấn HTTP có đường dẫn “khớp” với đường dẫn khai báo trong Deployment Descriptor. Vậy ai kích hoạt ứng dụng chúng ta viết để đáp ứng mỗi khi có HTTP Request gửi đến? Ai chịu trách nhiệm chuyển đổi các thông điệp HTTP (HTTP Request và HTTP Response) thành các đối tượng Java (HttpServletRequest và HttpServletResponse) để truyền cho các hàm doGet(), doPost()? Đó chính là Servlet Container. Hình 2.2: Luồng điều khiển của chương trình bình thường
12 Ví dụ 2: Lập trình kiểm thử đơn vị (Unit testing) với Junit Trong quá trình phát triển các thành phần chức năng của ứng dụng, chúng ta thường áp dụng kiểm thử đơn vị để đảm bảo chức năng đó vẫn chạy đúng trong suốt quá trình ứng dụng được mở rộng và phát triển thêm. Để tạo bộ unit test, chúng ta chỉ cần tạo một lớp đối tượng, định nghĩa các phương thức khởi tạo, phương thức kết thúc và các phương thức test. Sau đó, chúng ta chỉ việc chạy bộ test để kiểm thử. Việc điều khiển trình tự thực thi các phương thức được giao cho thư viện bên ngoài đảm nhiệm chẳng hạn như TestNG hoặc JUnit. Hình 2.3: Servlet Container Hình 2.4: Kiểm thử đơn vị với JUnit
13 Với hai ví dụ trên, chúng ta nhận thấy trong các ứng dụng đã có sự thay đổi vai trò. Ứng dụng không còn ôm đồm vừa trực tiếp tạo dựng và kiểm soát luồng thực thi, vừa xây dựng chức năng nghiệp vụ. Việc kiểm soát luồng thực thi được tách khỏi chức năng nghiệp vụ và bị đẩy ra bên ngoài. Người lập trình đã ủy thác việc kiểm soát luồng thực thi ứng dụng cho một thành phần (thường là thư viện dựng sẵn) bên ngoài đảm nhiệm, chỉ còn tập trung vào chức năng chính của ứng dụng. Như vậy, khái niệm “đảo ngược” ở đây chính là chuyển nhiệm vụ kiểm soát lưu trình thực thi từ ứng dụng cho một thành phần chuyên trách (thường là một thư viện phần mềm khung – framework – dựng sẵn ở bên ngoài). Ứng dụng chính chúng ta quan tâm phát triển không kiểm soát việc điều khiển luồng thực thi nữa, mà chỉ tập trung vào việc định nghĩa chức năng. Thư viện phần mềm khung chuyên trách kiểm soát điều khiển sẽ dựa trên mô tả trong cấu hình của ứng dụng để thay mặt ứng dụng điều phối luồng thực thi trong chương trình. Dễ dàng nhận thấy thư viện phần mềm khung này khác với các thư viện thông thường ở chỗ: thư viện thông thường cung cấp các chức năng và chờ được ứng dụng gọi đến, còn thư viện phần mềm khung tạo dựng luồng thực thi và gọi đến các chức năng của ứng dụng. Nói một cách ngắn gọn IoC là một design pattern và tập hợp các kỹ thuật lập trình liên quan, trong đó luồng thực thi của một hệ thống bị đảo ngược so với cách tương tác truyền thống [4, tr1]. IoC trong Spring cũng hoàn toàn mang ý nghĩa như trên. Trong Spring các đối tượng chính để xây dựng ứng dụng thì được quản lý bởi Spring IoC container. Và IoC container gọi các đối tượng đó là các bean. Một bean chỉ đơn giản là một đối tượng được khởi tạo và quản lý bởi Spring IoC container. 2.2.3.2 Dependency Injection (DI) Dependency Injection là khả năng liên kết giữa các thành phần lại với nhau, đó chính là việc các thuộc tính trong một đối tượng được “tiêm chích” (injection) để tham Hình 2.5: Mô hình ứng dụng áp dụng IoC
14 chiếu lần lượt đến các đối tượng khác. Dependency Injection trong Spring hoạt động dựa trên Java Reflection. 2.2.4 Các module Spring được xây dựng với 7 module chính (Hình 2-6). - Spring Core: Core package là phần cơ bản nhất của Spring, cung cấp những đặc tính như IoC (Inversion of Control) và DI (Dependency Injection). Khái niệm cơ bản là BeanFactory, một cài đặt của Factory pattern, cho phép “móc nối” sự phụ thuộc giữa các đối tượng trong file cấu hình. - Spring Context: Spring context là một file cấu hình để cung cấp thông tin ngữ cảnh của Spring. Spring context cung cấp các service như JNDI access, EJB integration, e-mail, internalization, validation, và scheduling functionality. - Spring AOP (Aspect – Oriented Programming): Spring AOP module tích hợp chức năng lập trình hướng khía cạnh vào Spring framework thông qua cấu hình của nó. Spring AOP module cung cấp các dịch vụ quản lý giao dịch cho các đối tượng trong bất kỳ ứng dụng nào sử dụng Spring. Với Spring AOP chúng ta có thể tích hợp declarative transaction management vào trong ứng dụng mà không cần dựa vào EJB component. Spring AOP module cũng đưa lập trình metadata vào trong Spring. Sử dụng cái này chúng ta có thể thêm annotation vào source code để hướng dẫn Spring nơi và làm thế nào để liên hệ với aspect. - Spring DAO (Data Access Object): Tầng JDBC và DAO đưa ra một cây phân cấp exception để quản lý kết nối đến database, điều khiển exception và thông báo lỗi được ném bởi vendor của database. Tầng exception đơn giản điều khiển lỗi và giảm khối lượng code mà chúng ta cần viết như mở và đóng kết nối. Hình 2.6: Các module của Spring framework
15 Module này cũng cung cấp các dịch vụ quản lý giao dịch cho các đối tượng trong ứng dụng Spring. - Spring ORM (Object Relational Mapping): Spring có thể tích hợp với một vài ORM framework để cung cấp Object Relation tool bao gồm: JDO, Hibernate, OJB và iBatis SQL Maps. - Spring Web: Nằm trên application context module, cung cấp context cho các ứng dụng web. Spring cũng hỗ trợ tích hợp với Struts, JSF và Webwork. Web module cũng làm giảm bớt các công việc điều khiển nhiều request và gắn các tham số của request vào các đối tượng domain. - Spring MVC: MVC Framework thì cài đặt đầy đủ đặc tính của MVC pattern để xây dựng các ứng dụng Web. MVC framework thì cấu hình thông qua giao diện và chứa được một số kỹ thuật view bao gồm: JSP, Velocity, Tiles và generation of PDF và Excel file. 2.2.5 Spring Core 2.2.5.1 Bean Trong Spring các object được quản lý bởi IoC container và được gọi là bean. Một bean thì đơn giản là một đối tượng được khởi tạo, phân phát và được quản lý bởi IoC container [6, tr27]. Sự phụ thuộc giữa chúng được phản ánh trong configuration metadata. Một Spring container sẽ quản lý một hoặc nhiều bean. Các bean được tạo ra nhờ vào thông tin cấu hình được chỉ ra trong thẻ <bean /> nếu sử dụng XML config. Bên trong container các bean được biểu diễn như một đối tượng của lớp BeanDefinition, nó chứa các thông tin sau: - Class của đối tượng mà bean được cấu hình (bao gồm cả phần package) - Các thông số cấu hình hành vi của bean như: phạm vi (scope), vòng đời (lifecycle),… - Các tham chiếu đến các bean khác, các tham chiếu này được gọi là collaborators hoặc dependencies - Các thiết lập khác như số connection kết nối đến bean,… Các thuộc tính sau đây thường được sử dụng để định nghĩa một bean: class (instantiating beans), name (naming beans), scope, constructor arguments, properties, autowiring mode, lazy-initialization mode, initialization method, destruction method 2.2.5.1.1 Tên bean (Naming beans) Mỗi bean có một hoặc nhiều định danh (indentifiers), các định danh này phải là duy nhất trong một container. Một bean thường chỉ có duy nhất một định danh, tuy nhiên nếu cần nhiều hơn một định danh thì có thể sử dụng bí danh (alias). Trong cấu hình dạng XML, có thể sử dụng thuộc tính id và/hoặc name để chỉ định định danh cho bean. Thuộc tính id cho phép chỉ định chính xác một định danh duy nhất cho bean. Chúng ta có thể không cần chỉ định id hoặc name cho bean, khi đó container sẽ tự tạo ra một định danh duy nhất cho bean. Tuy nhiên nếu muốn sử dụng tham chiếu ở bean khác bằng cách sử dụng thuộc tính ref thì cần phải chỉ định một cách rõ ràng.
16 Thông thường các bean được đặt tên giống như khai báo biến trong Java, theo quy ước camel-cased. Ví dụ như: accountManager, userDao, loginController…Đặt tên cho bean sẽ giúp file cấu hình dễ đọc và hiểu hơn và nếu sử dụng Spring AOP nó sẽ giúp rất nhiều khi thêm các advice vào bean thông qua tên của bean. 2.2.5.1.2 Khởi tạo bean Một bean thực chất là một “công thức” cho việc tạo ra một hoặc nhiều đối tượng [6, tr34]. Nếu sử dụng configuration metadata dạng XML (XML-based configuration metadata) cần phải chỉ định rõ class của đối tượng sẽ được bean quản lý và khởi tạo khi có yêu cầu. Có 3 cách để khởi tạo một bean: Khởi tạo bean với hàm dựng (constructor) Thông thường khi tạo một bean bằng phương pháp sử dụng constructor, tất cả các class đều có thể dùng được và phù hợp với Spring [6, tr34]. Có nghĩa là các class không cần phải thực thi (implement) bất kỳ giao diện (interface) cụ thể nào. Tuy nhiên, tùy thuộc vào loại IoC có thể cần một constructor mặc định (không đối số). Spring IoC container có thể quản lý hầu như bất kỳ class nào mà chúng ta muốn nó quản lý [6, tr34]. Hầu hết người dùng Spring thích sử dụng cách tạo một bean bằng việc sử dụng một constructor mặc định (không có đối số) và các setter và getter [6, tr34]. Khởi tạo bean với phương thức tĩnh (static factory method) Để tạo một bean sử dụng phương thức tĩnh, thuộc tính class chỉ ra lớp chứa phương thức tĩnh và thuộc tính factory-name chỉ ra tên của phương thức này được định nghĩa bên trong class vừa chỉ định. Ví dụ dưới đây sẽ cho thấy rõ việc tạo một bean bằng cách gọi phương thức tĩnh. Lưu ý thuộc tính class trong tag bean không phải chỉ định kiểu (class) của đối tượng mà thật ra chỉ là chỉ định class chứa phương thức tĩnh được chỉ định ở thuộc tính factoty-method được gọi để tạo ra đối tượng mà thôi, trong ví dụ này chính là phương thức createInstance() trong lớp MusicService. Khởi tạo bean sử dụng phương thức của đối tượng (instance factory method) public class MusicService { private static MuisicService musicService = new MuisicService(); private MuisicService() { } public static MuisicService createInstance() { return musicService; } } <bean id="musicService" class="com.nthienan.MusicService" factory-method="createInstance" />
17 Tương tự như việc sử dụng phương thức tĩnh, với phương pháp này sử dụng một phương thức non-static của một bean để tạo ra bean mới. Để sử dụng cách này thuộc tính class của tag bean sẽ không được chỉ định, thay vào đó thuộc tính factory-bean chỉ ra tên của bean mà có chứa phương thức dùng để tạo ra đối tượng. Tên của phương thức này được chỉ định trong thuộc tính factory-method. Ví dụ dưới đây sẽ chỉ ra cách sử dụng phương pháp này. 2.2.5.1.3 Phạm vi của bean (Bean scopes) Khi định nghĩa một bean chúng ta đã đưa ra một “công thức” cho việc tạo một thể hiện thực sự của một class [6, tr57]. Việc khởi tạo một hay nhiều thể hiện, khi nào thì một thể hiện được tạo ra sẽ phụ thuộc vào phạm vi của bean. Spring đưa ra năm phạm vi của một bean, trong đó ba phạm vi chỉ có khi xây dựng các ứng dụng web. Năm phạm vi của một bean được trình bày tóm tắt trong bảng dưới đây: Bảng 2-1: Phạm vi của bean Phạm vi Giải thích Singleton Chỉ có một thể hiện duy nhất được tạo ra cho bean trong mỗi Spring IoC container. Đây là phạm vi mặc định của mỗi bean Prototype Ngược lại với singleton, prototype cho phép nhiều hơn một đối tượng được tạo ra trên mỗi container. Request Một thể hiện cụ thể sẽ được tạo ra cho mỗi HTTP request. Phạm vi này chỉ có trong container của các ứng dụng web (WebApplicationContext) Session Tương tự như request nhưng, một thể hiện cụ thể sẽ được tạo ra cho mỗi HTTP session. Phạm vi này chỉ có trong container của các ứng dụng web (WebApplicationContext) public class MusicService { private static SongService songService = new SongService(); private MuisicService() { } public SongService createSongServiceInstance() { return songService; } } <!-- factory bean --> <bean id="musicService" class="com.nthienan.MusicService"> <!-- các cấu hình khác cho bean này ở đây --> </bean> <!-- bean được tạo thông qua factory bean --> <bean id="songService" factory-bean="musicService" Factory-method="createSongServiceInstance" />
18 Global session Một thể hiện cụ thể sẽ được tạo ra cho một global HTTP session. Phạm vi này chỉ có trong container của các ứng dụng web. Appplication Một thể hiện cụ thể sẽ được tạo ra cho một Servlet context. Phạm vi này chỉ có trong container của các ứng dụng web. Thông thường thì singleton và prototype là hai phạm vi của bean được sử dụng nhiều nhất. Dưới đây xin trình bày chi tiết về 2 phạm vi này. Singleton scope. Khi khai báo một bean với phạm vi là singleton điều này có nghĩa là chỉ có duy nhất một thể hiện của class được chỉ ra trong bean trong một container. Thể hiện này sẽ được lưu trữ trong cache của Spring IoC container, tất cả các yêu cầu tiếp theo tham chiếu đến bean này thì thể hiện được lưu trữ trong cache sẽ được trả về. Ví dụ dưới đây cho thấy cách khai báo một bean với phạm vi singleton trong XML: Prototype scope <bean id="accountDao" class="com.nthienan.AccountDao"></bean> <!-- hoặc --> <bean id="accountDao" class="com.nthienan.AccountDao" scope="singleton"></bean> Hình 2.7: Singleton scope
19 Ngược lại với singleton, một bean với phạm vi là prototype thì mỗi khi có một yêu cầu tham chiếu đến bean này thì một thể hiện cụ thể của bean sẽ được tạo ra. Khai báo một bean với phạm vi prototype trong XML như sau: 2.2.5.2 Spring IoC Container Spring là một framework thực thi theo nguyên tắc Inversion of Control, IoC cũng được biết đến như Dependency Injection [6, tr27]. Nó là một quá trình xử lý ở nơi các object định nghĩa sự phụ thuộc (dependency). Khi các đối tượng hoạt động với nhau chỉ thông qua các tham số của constructor, tham số của các method hoặc các property để thiết lập thể hiện sau khi được khởi tạo. Container sau đó “tiêm” các đối tượng phụ thuộc khi nó được tạo ra từ các bean. Quá trình này về cơ bản là sự đảo ngược, các bean sẽ điều khiển các thể hiện hoặc vị trí phụ thuộc bằng cách khởi tạo trực tiếp từ class của chúng. Package org.springframework.beans và org.springframework.context là 2 package cơ bản cho IoC container của Spring. Interface BeanFactory cung cấp kỹ thuật để cấu hình nâng cao và quản lý bất kỳ loại object nào. ApplicationContext kế thừa BeanFactory, ApplicationContext thêm vào một số tính năng như tích hợp để dễ dàng hoạt động với các tính năng của Spring AOP (Aspect Oriented Programming) như Message resource handling, event publication; và một số lớp context đặc biệt như WebApplicationContext được sử dụng trong các ứng dụng web. Nói một cách ngắn gọn, BeanFactory cung cấp cơ chế cấu hình cho framework và các chức năng cơ bản. ApplicationContext thêm vào một số chức năng nâng cao. Trong phần này sẽ sử dụng ApplicationContext để để mô tả cho IoC container của Spring. Interface org.springframework.context.ApplicationContext chịu trách nhiệm khởi tạo, cấu hình và phân phát các bean. Container lấy các chỉ dẫn cho việc khởi tạo, cấu hình và phân phát bằng cách đọc các configuration metadata. Các configuration <bean id="accountDao" class="com.nthienan.AccountDao" scope="prototype"></bean> Hình 2.8: Prototype scope
20 metadata được trình bày bằng nhiều cách khác nhau như trong file XML, Java annotaion hoặc trong Java code. Điều này cho phép biểu diễn các đối tượng và sự phụ thuộc lẫn nhau giữa chúng trở nên phong phú hơn. Một số class thực thi (implementation) interface ApplicationContext như Class PathXmlApplicationContext, FileSystemXmlApplicationContext, AnnotationConfigApplicationContext,… XML là cách truyền thống và thường được sử dụng để định nghĩa các configuration metadata, chúng ta cũng có thể khai báo để container sử dụng các annotation như configuration metadata hoặc trực tiếp trong code Java bằng cách cấu hình thêm trong file XML cho phép sử dụng các annotation như sau: <context:annotation-config/> Hình 2-9 mô tả cách thức làm việc của Spring. Các class trong ứng dụng sẽ kết hợp với các configuration metadata để sau khi ApplicationContext được tạo ra và khởi tạo chúng ta có được một cấu hình đầy đủ và có thể thực thi được. Như hình chúng ta thấy các configuration metadata sẽ nói với Spring container khởi tạo, cấu hình và phân phối các object trong ứng dụng của chúng ta như thế nào. Thông thường các configuration metadata được biểu diễn dưới dạng XML, vì vậy trong phần này sẽ sử dụng configuration metadata dưới dạng này để nói về các khái niệm và tính năng của IoC container. Lưu ý rằng không phải chỉ có các configuration metadata dưới dạng XML mới được Spring container chấp nhận, như đã nói ở phần trên ngoài các metadata dạng XML chúng ta còn có thể sử dụng Java annotaion hoặc trực tiếp trong code Java (Java config). Kể từ phiên bản 2.5 Spring đã hổ trợ kiểu cấu hình dựa trên các Java annotation. Và kể từ Spring 3.0 nhiều tính năng đã được cung cấp bằng cách sử dụng Java config và nó trở thành một phần của Spring core. Vì vậy chúng ta có thể định nghĩa bean bên ngoài các Hình 2.9: Spring IoC Container
21 class của ứng dụng bằng cách sử dụng Java code hơn là file XML. Để sử dụng tính năng này xem thêm các annotation như @Configuration, @Bean, @Import và @DependOn. Cấu hình trong Spring bao gồm ít nhất là một và thường là nhiều hơn một định nghĩa bean mà container cần phải quản lý [6, tr28]. Trong metadata dạng XML để khai báo và cấu hình một bean ta sử dụng thẻ <bean /> bên trong thẻ <beans />. Nếu sử dụng dạng Java config thông thường sẽ sử dụng annotaion @Bean bên trong một class với annotaion @Configuration. Ví dụ dưới đây là sẽ cho thấy cấu trúc cơ bản của một file XML trình bày các configuration metadata. Thuộc tính id chỉ ra định danh của bean đó, thuộc tính class chỉ ra class của bean này (lưu ý sử dụng tên đầy đủ của class bao gồm cả phần package). Giá trị của thuộc tính id sẽ được các bean khác sử dụng nếu cần thiết. 2.2.5.2.1 Khởi tạo container Việc khởi tạo một Spring container đơn giản như việc chúng ta khởi tạo một đối tượng, cần chỉ rõ đường dẫn của file XML cấu hình trong khi khởi tạo một container. Ví dụ dưới đây sẽ cho chúng ta thấy rõ hơn: Trong đó file config “services.xml” như sau: <?xml version=”1.0” encoding=”UTF-8”?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="http://www.springframework.org/schema/context http://www.springframework.org/schema/beans/spring-beans-3.0.xsd"> <bean id="bean1" class="com.nthienan.Bean1"> <!-- cấu hình cho bean ở đây --> </bean> <bean id="bean2" class="com.nthienan.Bean2"> <!-- cấu hình cho bean ở đây --> </bean> </beans> ApplicationContext context = new ClassPathXmlApplicationContext(new String[] {"services.xml", "daos.xml"} );
22 Và file config “daos.xml” như sau: Ở ví dụ trên class MusicServicesIpml được cấu hình trong file “services.xml” và có hai thuộc tính truy cập dữ liệu thuộc hai lớp là AccountDao và SongDao. Thẻ <property /> dùng để tham chiếu đến một bean khác, trong đó thuộc tính name là tên của thuộc tính trong class MusicServicesIpml và giá trị của ref là id của bean cần tham chiếu đến. Thường thì mỗi file cấu hình XML sẽ cấu hình cho một tầng hoặc một module trong ứng dụng. Việc chia nhỏ như thế giúp dễ dàng kiểm soát hơn. 2.2.5.2.2 Sử dụng container Ví dụ dưới đây sẽ chỉ ra cách đọc các định nghĩa của bean và truy cập đến chúng. <?xml version=”1.0” encoding=”UTF-8”?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="http://www.springframework.org/schema/context http://www.springframework.org/schema/beans/spring-beans-3.0.xsd"> <bean id="musicService" class="com.nthienan.MusicServicesImpl"> <property name="accountDao” ref=”accountDao" /> <property name="songDao" ref="songDao" /> <!-- các cấu hình khác ở đây --> </bean> </beans> <?xml version=”1.0” encoding=”UTF-8”?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="http://www.springframework.org/schema/context http://www.springframework.org/schema/beans/spring-beans-3.0.xsd"> <bean id="accountDao" class="com.nthienan.AccountDao"> </bean> <bean id="songDao" class="com.nthienan.SongDao"> </bean> </beans> ApplicationContext context = new ClassPathApplicationContext(new String[] {"services.xml", "daos.xml"} ); //nhận về đối tượng đã được config MusicServicesImpl services = (MusicServicesImpl)context.getBean("musicService"); //sử dụng đối tượng List<String> songs = services.getSongList();
23 2.2.5.3 Dependency Injection 2.2.5.3.1 Constructor – based dependency injection Constructor – based DI là phương pháp “tiêm sự phuộc” cho các đối tượng bằng cách gọi hàm tạo (constructor method) với các tham số chính là các “sự phụ thuộc” (dependentcies) của đối tượng. Ví dụ sau đây sẽ đưa ra một class chỉ có thể tiêm sự phụ thuộc bằng phương pháp này. Khi đó để tiêm sự phụ thuộc cho lớp MessageSender cần khai báo các bean như sau: Thẻ <constructor-arg /> trong ví dụ này sẽ cho Spring container biết đây là một bean mà các dependentcy sẽ được tiêm vào bằng cách gọi hàm tạo của lớp này. Đối với các hàm tạo với nhiều đối số thì thứ tự của các thẻ <constructor-arg /> sẽ giống với thứ tự các đối số của hàm, giống như ví dụ dưới đây public class MessageSender { private Message message; public MessageSender(Message message) { this.message = message; } } public class Message { public Message() { } } <bean id="message" class="com.nthienan.Message" /> <bean id="sender" class="com.nthienan.MessageSender"> <constructor-arg ref="message" /> </bean> public class A { private B b; private C c; public A(B b, C c) { this.b = b; this.c = c; } } <bean id="a" class="com.nthienan.A"> <constructor-arg ref="b" /> <constructor-arg ref="c" /> </bean>
24 Ở các ví dụ trên các dependentcy là những kiểu dữ liệu do người dùng định nghĩa nên thẻ <constructor-arg /> sử dụng thuộc tính ref để tham chiếu đến bean khác. Riêng đối với các kiểu dữ liệu nguyên thủy (int, boolean, string,…) thì khai báo bean đơn giản hơn. Các khai báo bean dưới đây là tương tự nhau. <bean id="b" class="com.nthienan.B" /> <bean id="c" class="com.nthienan.C" /> public class Z { private int b; private String c; private boolean d; public A(B b, C c, D d) { this.b = b; this.c = c; this.d = d; } } <bean id="z" class="com.nthienan.Z"> <constructor-arg value="123" /> <constructor-arg value="abc" /> <constructor-arg value="true" /> </bean> <!-- hoặc --> <bean id="z" class="com.nthienan.Z"> <constructor-arg value="123" type="int"/> <constructor-arg value="abc" type="java.lang.String"/> <constructor-arg value="true" type="boolean"/> </bean> <!-- hoặc --> <bean id="z" class="com.nthienan.Z"> <constructor-arg index="0" value="123" /> <constructor-arg index="1" value="abc" /> <constructor-arg index="2" value="true" /> </bean> <!-- hoặc --> <bean id="z" class="com.nthienan.Z"> <constructor-arg name="b" value="123" /> <constructor-arg name="c" value="abc" /> <constructor-arg name="d" value="true" /> </bean>
25 2.2.5.3.2 Setter – based dependency injection Thông thường với mỗi thuộc tính XXX trong một lớp, sẽ có các phương thức getXXX() và setXXX() tương ứng với nó. Qua phương thức setXXX(), thuộc tính XXX sẽ được gán cho một giá trị nào đó (giá trị này có thể thuộc kiểu primitive hay kiểu tham chiếu). Spring cũng cung cấp cho chúng ta phương pháp để gán giá trị đến một thuộc tính qua phương thức setter của nó. Setter – based DI là phương pháp tiêm sự phuộc cho các đối tượng bằng cách gọi các setter của một class sau khi hàm dựng mặc định (không đối số) được gọi để khởi tạo bean. Ví dụ dưới đây sẽ đưa ra một class chỉ có thể tiêm sự phụ thuộc bằng các setter. Khi đó để tiêm sự phụ thuộc cho lớp Person cần khai báo các bean như sau: Thẻ <property> được dùng để biểu diễn cho một phương thức setter. Thuộc tính name của thẻ <property /> chỉ định thuộc tính mà setter của nó sẽ được gọi để gán giá trị được chỉ định trong thẻ <value /> (hoặc thuộc tính value như cách khai báo bean thứ 2). Thuộc tính name phải khớp với phần đuôi của phương thức setter. Ví dụ ta có phương thức là setAField(), thì lúc khai báo sẽ tương ứng là name=”aField”. Chúng ta có thể kết hợp cả 2 phương pháp DI này trong khai báo một bean. Thông thường Constructor – based DI được sử dụng cho những dependency bắt buộc và Setter – based DI cho những dependency tùy chọn. public class Person { private String fullName; private int age; public void setFullName(String fullName) { this.fullName = fullName; } public void setAge(int age) { this.age = age; } } <bean id="person" class="com.nthienan.Person"> <property name="fullName"> <value>Nguyen Thien An</value> </property> <property name="age"> <value>22</value> </property> </bean> <!-- hoặc ngắn gọn hơn --> <bean id="person" class="com.nthienan.Person"> <property name="fullName" value="Nguyen Thien An" /> <property name="age" value="22" /> </bean>
26 Dễ dàng nhận thấy rằng tất cả các class ở những ví dụ trên đều là những POJOs (những class Java bình thường), chúng hoàn toàn không kế thừa từ bất cứ một class hoặc thực thi một interface đặc biệt nào, đều này cho thấy được sức mạnh của Spring trong việc xây dựng một ứng dụng từ các POJOs là nhờ vào DI và IoC container. Spring container xử lý việc tiêm sự phụ thuộc cho các bean như sau: - Spring container ApplicationContext được tạo ra và khởi tạo những siêu dữ liệu cấu hình (configuration metadata) cho tất cả các bean. Các configuration metadata có thể là XML, code Java hoặc các annotaion. - Đối với từng bean các dependency của nó được thể hiện dưới dạng là các property, các đối số của hàm tạo. Những dependency này sẽ phải được cung cấp cho bean khi bean thực sự được khởi tạo. - Đối với từng property hoặc các đối số của hàm được gán giá trị để thiết lập cho bean hoặc được tham chiếu đến một bean khác trong container. - Giá trị của từng property và đối số của hàm tạo sẽ được chuyển thành kiểu dữ liệu phù hợp, Spring sẽ chuyển chúng từ kiểu String sang các kiểu dữ liệu khác như int, long, String, boolean,… Spring container sẽ kiểm tra tính hợp lệ của các thông tin cấu hình cho mỗi bean khi container được tạo. Tuy nhiên các thuộc tính của bean sẽ không được thiết lập cho đến khi bean thật sự được tạo ra và một bean chỉ được tạo khi có một yêu cầu đến nó. 2.2.5.3.3 Autowiring Khi một bean A cần tham chiếu đến bean B (B là một dependency của A) chúng ta cần phải cấu hình cho bean A để có thể “tiêm” B vào thông qua Constructor – based DI hoặc Setter – based DI. Tuy nhiên nếu chúng ta cấu hình cho bean A autowire thì Spring container có thể thực hiện việc này một cách “tự động” bằng cách Spring container sẽ kiểm tra trong ApplicationContext để tìm ra B và “tiêm” cho A. Autowiring thực sự hữu ích khi phát triển một ứng dụng mà việc chỉnh sửa mã nguồn là thường xuyên [6, tr52], ví dụ khi thêm một thuộc tính mới cho một class, nếu sử dụng autowire thì cấu hình bean của class này không cần phải thay đổi. Để cấu hình cho một bean có thể autowire chỉ cần thêm thuộc tính autowire trong thẻ <bean />. Autowire có 4 loại vì vậy cần phải chỉ rõ loại của autowire đối với mỗi bean. Dưới đây là 4 loại của autowire: - Autowire by name. Spring sẽ tìm kiếm bean có tên giống như tên của property cần autowire. Ví dụ nếu bean A được chỉ định là autowire by name có property tên master (class A cần phải có phương thức setMasster(…)) , Spring sẽ tìm một bean có tên (id) là master và tiêm nó vào bean A. - Autowire by type. Autowire by type cho phép một property được autowire nếu có một bean có kiểu (class) là kiểu của property này. Nếu có nhiều hơn một bean thì một exception được ném ra, ngược lại nếu không tồn tại bất cứ bean nào phù hợp thì không có exception nào được ném ra và property này không được thiết lập (set) giá trị. - Autowire by constructor. Tương tự như autowire by type, tuy nhiên autowire by constructor chỉ áp dụng cho các đối số của hàm tạo. Nếu không có chính xác
27 một bean có kiểu là kiểu của các đối số trong hàm tạo thì một exception sẽ được ném ra. - No autowire. Không autowire, đây là thiết lập mặc định của các bean. Các bean tham chiếu đến nhau thông qua thuộc tính ref. No autowire được khuyến cáo nên sử dụng, bởi vì việc chỉ định các dependency một cách rõ ràng sẽ tốt hơn và ở một mức độ nào đó nó được xem như tài liệu cho cấu trúc của hệ thống. Lưu ý là các dependency được chỉ định một cách tường minh sẽ ghi đè lên lên autowire. Đối với các property có kiểu dữ liệu nguyên thủy như String, Classes… thì không thể autowire. 2.2.6 Spring MVC 2.2.6.1 Tổng quan về Spring MVC Spring MVC là một module con trong Spring framework, cung cấp kiến trúc Model-View-Controller và các components sẵn có để sử dụng và phát triển ứng dụng web một cách linh hoạt. Hình 2.10: Kiến trúc module Spring MVC
28 Mô hình MVC là kết quả của việc tách các khía cạnh khác nhau của ứng dụng (logic đầu vào, các xử lý logic, UI) trong khi đó cung cấp một sự kết hợp giữa các thành phần đó một cách “lỏng lẻo”. Model: đóng gói dữ liệu ứng dụng và bao gồm các POJO. View: Chịu trách nhiệm nhận giá trị của model và vẽ ra trang HTML mà trình duyệt có thể hiển thị được. Controller: Chịu trách nhiệm nhận và xử lý các yêu cầu từ người dùng và tạo các model phù hợp và trả về cho view. Spring MVC được thiết kế xung quanh DispatcherServlet để xử lý tất cả các HTTP request và HTTP response. Luồng xử lý các yêu cầu của DispatcherServlet được minh họa theo hình: Đây là chuỗi sự kiện tương ứng khi nhận một yêu cầu HTTP gửi đến DispatcherServlet: 1. Sau khi nhận một HTTP request, DispatcherServlet gửi yêu cầu đến HandlerMapping (một bản đồ cấu hình URL) để xác định controller nào sẽ xử lý yêu cầu này. 2. Controller sẽ nhận các request và gọi các phương thức dịch vụ (service methods) phù hợp dựa trên việc sử dụng các method GET/POST… Nếu yêu cầu đó cần truy xuất cơ sở dữ liệu thì Controller sẽ ủy nhiệm cho một business logic hay nhiều hơn một model để lấy thông tin và gửi dữ liệu về cho Controller. Lúc này Controller đóng gói mô hình dữ liệu và tên của một view sẽ được tải lên thành đối tượng ModelAndView và gửi trả về cho DispathcherServlet 3. DispatcherServlet gửi gói ModelAndView cho ViewResolver để tìm xem view (thông thường là một trang JSP, HTML) nào sẽ được load lên. 4. Sau khi hoàn tất, DispatcherServlet sẽ chuyển dữ liệu từ model đến view và cuối cùng hiển thị trên trình duyệt. Hình 2.11: Sơ đồ luồng xử lý của Spring MVC
29 2.2.6.2 DispathcherServlet DispathcherServlet là thành phần tiếp nhận tất cả các request từ browser, điều khiển luồng xử lý và trung chuyển giữa các thành phần (components) trong MVC. Hơn thế nữa, nó còn tích hợp các Spring IoC container, cho phép ta sử dụng đến tất cả các tính năng của Spring [6, tr439]. Hình 2-11 sẽ cho chúng ta thấy luồng xử lý một request trong Spring MVC và DispatcherServlet chính là Front controller. DispatcherServlet thực sự là một Servlet (nó thừa kế từ lớp cơ sở HttpServlet), và được khai báo trong tập tin web.xml của ứng dụng web. Các requests muốn DispatcherServlet xử lý sẽ phải được ánh xạ bằng cách sử dụng một bộ ánh xạ URL trong cùng một tập tin web.xml. Dưới đây là ví dụ về khai báo và định nghĩa DispatcherServlet Hình 2.12: Luồng xử lý một request trong Spring MVC
30 Như ta thấy, tất cả các requests bắt đầu bằng /music sẽ được DispatcherServlet ‘music-manager’ xử lý. Khi DispatcherServlet được khởi tạo, Spring sẽ gọi file có tên [tên-servlet]- servlet.xml trong thư mục WEB-INF. Với ví dụ trên, Spring sẽ gọi file music- manager-servlet.xml. 2.2.6.3 Controllers Controllers là các thành phần được DispatcherServlet gọi để xử lý các nghiệp vụ business. Tất cả các Controller trong Spring đều implement từ Controller interface trong package org.springframework.web.servlet.mvc Controller interface định nghĩa ra 1 phương thức chịu trách nhiệm xử lí 1 request và trả về model và view thích hợp. Ba khái niệm này chính là nền tảng của Spring MVC framework : Model – View – Controller. Sau đây là các Controller sử dụng được trong Spring: - SimpleFormController - AbstractController - AbstractCommandController - CancellableFormController - AbstractCommandController - MultiActionController - ParameterizableViewController - ServletForwardingController - ServletWrappingController <?xml version=”1.0” encoding=”UTF-8”?> <webapp> <servlet> <servlet-name>music-manager</servlet-name> <servlet-class> org.springframework.web.servlet.DispatcherServlet </servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>music-manager</servlet-name> <url-pattern>/music/*</url-pattern> </servlet-mapping> </webapp> package org.springframework.web.servlet.mvc; public interface Controller { ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception; }
31 - UrlFilenameViewController Kể từ khi Spring 2.5 giới thiệu và đưa vào mô hình lập trình cho các MVC controller dựa trên các annotation như @Controller, @RequestMapping, @RequestParam, @PathVariable,… thì việc tạo ra một controller trở nên vô cùng đơn giản. Để tạo ra một controller chúng ta không cần kế thừa từ một lớp cơ sở hoặc thực thi bất kỳ một interface nào. Hãy xét 2 ví dụ dưới đây để thấy rõ hơn. Ví dụ 1: Tạo controller bằng cách thực thi giao diện AbstractController Khi sử dụng AbstractController làm baseclass cho các controller, chỉ cần override hàm handleRequestInternal (HttpServletRequest, HttpServletResponse), viết code xử lý, và trả về một đối tượng ModelAndView Controller này sẽ trả về một view “hello” được code cứng. Ví dụ 2: Tạo controller sử dụng các annotation Như chúng ta thấy với 2 annotation @Controller và @RequestMapping đã có thể tạo ra 1 controller như ví dụ 1 một cách dễ dàng. Ngoài ra dễ nhận thấy khi có một request với phương thức GET được gửi đến URL “/home/welcome” thì hàm hello( ) của lớp HomeController sẽ được gọi để xử lý và trả kết quả về cho browser. Trong ví dụ này sẽ trả về view “hello” cho browser. public class HomeController implements AbstractController { @Override public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception { ModelAndView modelAndView = new ModelAndView(); model.addObject("message", "This is welcome page!"); model.setViewName("hello"); return modelAndView; } } package com.nthienan.controller; @Controller @RequestMapping(value = "/home") public class HomeController { @RequestMapping(value = "/welcome", method = RequestMethod.GET) public ModelAndView hello() { ModelAndView model = new ModelAndView(); model.addObject("message", "This is welcome page!"); model.setViewName("hello"); return model; } }
32 Nếu chúng ta tạo ra các controller như ví dụ 1 thì cần phải khai báo và định nghĩa các HandlerMapping. 2.2.6.4 Handler Mapping Sử dụng Handler Mapping để có thể ánh xạ từng requests đến các handler thích hợp. Các chức năng cơ bản của một HandlerMapping là đưa ra một Handler Execution Chain (chuỗi hành động), và có thể chứa một số bộ chặn. Khi requests đến, các DispatcherServlet sẽ trao cho các HandlerMapping để nó kiểm tra và xuất ra HandlerExecutionChain thích hợp. Sau đó, các DispatcherServlet sẽ gọi handler và bộ chặn trong hệ thống (nếu có). Một Handler Mapping đơn giản nhưng rất mạnh mẽ là Bean Name Url Handler Mapping, nó ánh xạ các HTTP requests đến tên của các beans, được định nghĩa trong bối cảnh ứng dụng web. Ví dụ chúng ta muốn cho phép một người dùng tạo một tài khoản, ở đây ta đã có một form controller thích hợp và một trang JSP để hiển thị. Khi sử dụng Bean Name Url Handler Mapping, ta có thể ánh xạ HTTP requests với địa chỉ http://samples.com/editaccount vào form Controller như sau: Tất cả requests gửi đến yêu cầu địa chỉ /editaccount bây giờ sẽ được xử lý bởi form Controller ở trên. Cơ chế handler mapping của Spring có khái niệm xử lý đánh chặn, nó có thể cực kỳ hữu ích khi chúng ta muốn áp dụng các chức năng cụ thể cho một request xác định, ví dụ kiểm tra điều kiện chẳng hạn. Ví dụ dưới đây tạo ra một bộ chặn, nó chặn tất cả các requests và redirect người dùng đến một trang xác định nếu thời gian truy cập không nằm từ 9h sáng đến 6h tối. <beans> <bean id="handlerMapping" class="org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping"/> <bean name="/editaccount" class="org.springframework.web.servlet.mvc.SimpleFormController"> <property name="formView" value="account"/> <property name="successView" value="account-created"/> <property name="commandName" value="account"/> <property name="commandClass" value="samples.Account"/> </bean> <beans> <beans> <bean id="handlerMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"> <property name="interceptors"> <list> <ref bean="officeHoursInterceptor"/> </list> </property> <property name="mappings">
33 2.2.6.5 ViewResolver Views trong Spring được gán “view name” và được phân giải bởi ViewResolver. Sau đây là các ViewResolver trong Spring: - BeanNameViewResolver - FreeMarkerViewResolver - InternalResourceViewResolver - JasperReportsViewResolver - ResourceBundleViewResolver - UrlBasedViewResolver - VelocityLayoutViewResolver <value> /*=editAccountFormController </value> </property> </bean> <bean id="officeHoursInterceptor" class="samples.TimeBasedAccessInterceptor"> <property name="openingTime" value="9"/> <property name="closingTime" value="18"/> </bean> <beans> public class TimeBasedAccessInterceptor extends HandlerInterceptorAdapter { private int openingTime; private int closingTime; public void setOpeningTime(int openingTime) { this.openingTime = openingTime; } public void setClosingTime(int closingTime) { this.closingTime = closingTime; } public boolean preHandle( HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Calendar cal = Calendar.getInstance(); int hour = cal.get(0); if (openingTime <= hour && hour < closingTime) { return true; } else { response.sendRedirect("http://host.com/outsideOfficeHours"); return false; } } }
34 - VelocityViewResolver - XmlViewResolver - XsltViewResolver Ở đây xin trình bày Internal Resource View Resolver vì nó thường được sử dụng nhiều nhất. View Resolver này sẽ ánh xạ Logical name của Resource (ModelAndView object được trả về bởi Controller) đến một Physical View (myView.jsp,…). Chúng ta có controller như sau: Chúng ta cần phải khai báo một Internal Resource View Resolver trong file web.xml như sau: Khi đó nếu như request của người dùng thỏa condition1(), thì view “myView.jsp” trong thư mục /WEB-INF/views sẽ được hiển thị, nếu không thì hoặc “myView2.jsp” hoặc “myView3.jsp” sẽ được hiển thị. 2.2.7 Spring Security 2.2.7.1 Tổng quan về Spring Security Spring Security cung cấp một giải pháp bảo mật toàn diện cho các ứng dụng enterprise dựa trên J2EE, Spring Security cố gắng để cung cấp cho chúng ta một hệ thống bảo mật hữu ích và dễ dàng để cấu hình cho các dự án được phát triển dựa trên Spring framework [2, tr2]. Vào năm 2003, Spring Security ban đầu chỉ là một dự án nhỏ và độc lập với Spring với tên gọi là “The Acegi Security System for Spring”. Đến tháng 3/2004 một dự án chính thức được thành lập để phát triển nó. Khoảng một năm sau khi dự án được giới thiệu Acegi Security chính thức trở thành một dự án con (subproject) của Spring Framework. Phiên bản 1.0.0 được giới thiệu vào tháng 5/2006 sau hơn hai năm rưỡi phát triển với hàng trăm cải tiến đáng kể. Cuối năm 2007 Acegi Security chính thức trở thành một project của Spring và được đổi tên thành Spring Security. public class MyController { public ModelAndView handle(){ if(condition1()){ return new ModelAndView("myView1"); }else if (condition2()){ return new ModelAndView("myView2"); } return new ModelAndView("myView3"); } } <bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix"> <value>/WEB-INF/views</value> </property> <property name="suffix"> <value>.jsp</value> </property> </bean>
35 Hai nhiệm vụ chính của việc bảo mật ứng dụng là "xác thực" (authentication) và "ủy quyền" (authorization) hay "kiểm soát truy cập" (access-control) [2, tr2], đây cũng chính là hai phần chính của Spring Security. Xác thực là quá trình xác nhận và chứng thực một principal (một principal thường có nghĩa là một người sử dụng, thiết bị hoặc một số hệ thống khác mà có thể thực hiện một hành động trong ứng dụng) [2, tr2]. Uỷ quyền đề cập đến quá trình quyết định có một principal được phép thực hiện những hành động gì trong phạm vi ứng dụng của chúng ta [2, tr2]. Để được ủy quyền thì quá trình xác thực là cần thiết và phải được thực hiện trước, ủy quyền chỉ được thực hiện khi xác thực thành công [2, tr2]. Đây là những khái niệm rất phổ biến cho hầu hết các ứng dụng và nó không phải là riêng của Spring Security. Ở một mức độ xác thực, Spring Security hỗ trợ một loạt các mô hình xác thực. Hầu hết các mô hình xác thực này hoặc được cung cấp bởi bên thứ ba, hoặc được phát triển bởi các cơ quan như IETF (Internet Engineering Task Force) [2, tr2]. Ngoài ra, Spring Security còn cung cấp các mô hình xác thực riêng cho mình. Cụ thể, Spring Security hiện đang hỗ trợ tích hợp xác thực với tất cả các công nghệ này: - HTTP BASIC authentication headers (an IEFT RFC-based standard) - HTTP Digest authentication headers (an IEFT RFC-based standard) - HTTP X.509 client certificate exchange (an IEFT RFC-based standard) - LDAP (một phương pháp xác thực cross-platform phổ biến thường được sử dụng trong các môi trường lớn) - Form-based authentication - OpenID authentication - Authentication based on pre-established request headers (such as Computer Associates Siteminder) - JA-SIG Central Authentication Service (hay còn gọi là CAS, một mã nguồn mở single sign) - Transparent authentication context propagation for Remote Method Invocation (RMI) and HttpInvoker (a Spring remoting protocol) - Automatic "remember-me" authentication - Anonymous authentication - Run-as authentication - Java Authentication and Authorization Service (JAAS) - JEE container autentication - Kerberos - Java Open Source Single Sign On (JOSSO) - OpenNMS Network Management Platform - AppFuse - AndroMDA - Mule ESB - Direct Web Request (DWR) - Grails - Tapestry - Jtrac
36 - Jasypt - Roller - Elastic Path - Atlassian Crowd Nhiều công ty phần mềm áp dụng Spring Security vì nó cung cấp những mô hình xác thực một cách linh hoạt [2, tr3]. Làm như vậy cho phép các công ty phần mềm nhanh chóng tích hợp các giải pháp của họ với bất cứ khách hàng nào, mà không thực hiện rất nhiều kỹ thuật hoặc yêu cầu khách hàng phải thay đổi môi trường. Nếu không có cơ chế xác thực phù hợp với nhu cầu của khách hàng, Spring Security là một nền tảng mở và nó thực sự đơn giản để viết cơ chế xác thực của riêng chúng ta [2, tr3]. Đôi khi chỉ xác thực là không đủ, chúng ta cũng cần phải quan tâm đến việc nó tích hợp vào ứng dụng như thế nào. Ví dụ, chúng ta có thể muốn đảm bảo rằng tất cả các request chỉ đến qua HTTPS, để bảo vệ mật khẩu khỏi bị nghe trộm hay từ các cuộc tấn công man-in-the-middle. Điều này đặc biệt hữu ích để bảo vệ quá trình phát hiện mật khẩu từ các cuộc tấn công brute force, hoặc chỉ đơn giản là để làm cho nó khó khăn hơn cho người dùng để sao chép nội dung quan trọng của ứng dụng. Để giúp chúng ta đạt được những mục tiêu này, Spring Security hỗ trợ "channel security", cùng với JCaptcha để giải quyết những yêu cầu trên. 2.2.7.2 Các module của Spring Security Spring Security được chia thành 7 module nhỏ dựa trên chức năng của từng module và các thành phần yêu cầu từ bên thứ 3: - spring-security-core.jar: Bao gồm các class và interface cơ bản cho quá trình xử lý xác thực và ủy quyền, hổ trợ các API cơ bản mà các ứng dụng sử dụng Spring Security cần. Bao gồm các package sau: + org.springframework.security.core + org.springframework.security.access + org.springframework.security.authentication + org.springframework.security.provisioning + org.springframework.security.remoting - spring-security-web.jar: Module này chứa các filter và những thành phần khác có liên quan đến việc bảo mật một ứng dụng web, bất cứ thành phần nào có liên quan đến Servlet. Chúng ta cần phải sử dụng module này nếu muốn xác thực trên các dịch vụ web và điều khiển truycập thông qua URL. Package chính của module này là: org.springframework.security.config - spring-security-config.jar: Module này là cần thiết nếu chúng ta cấu hình cho Spring Security bằng file XML. Nó chứa các namspace dùng để parse chúng sang code. Package chính của lớp này org.springframework.security.config - spring-security-ldap.jar: Đây là module dành cho việc xác thực theo mô hình LDAP (Lightweight Directory Access Protocol). Package chính của lớp này là org.springframework.security.ldap - spring-security-acl.jar: ACL (Access Control List) là một danh sách các quyền gắn liền với một đối tượng. Một ACL xác định người dùng hoặc các quá trình của hệ thống được cấp quyền truy cập, cũng như những gì được cho phép hoạt
37 động trên các đối tượng nhất định. Mỗi mục trong một ACL điển hình xác định một chủ thể và một hoạt động. Ví dụ, nếu một tập tin có chứa ACL (Alice: read, write; Bob: read), điều này sẽ cho phép Alice đọc và ghi các file và Bob chỉ đọc nó. Module này sẽ cho phép chúng ta tạo ra một mô hình xác thực như trên. Package chính của module này là org.springframework.security.acls - spring-security-cas-client.jar: Module này chứa các thành phần cần thiết để tích hợp Spring Security và CAS client (Central Authentication Service) nếu chúng ta sử dụng một CAS single sign-on server. Pakage chính chính của module này là: org.springframework.security.cas - spring-security-openid.jar: Module này hổ trợ mô hình xác thực OpenID, sử dụng để chứng thực người dùng bên ngoài hệ thống với một OpenID server. Pakage chính chính của module này là: org.springframework.security.openid 2.3 JAVA MESSAGE SYSTEM (JMS) 2.3.1 Hệ thống gửi nhận thông điệp (messaging system) Trong những năm qua, các hệ thống thông tin đã phát triển đáng kể về độ phức tạp và 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, và linh hoạt hơn trước đã làm nảy sinh những kiến trúc phức tạp và tinh vi. Đáp ứng với nhu cầu gia tăng này để cho ra đời các hệ thống tốt hơn và nhanh hơn, các nhà thiết kế và 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. Hệ thống gởi nhận thông điệp giữa ứng dụng và ứng dụng thường được gọi chung là hệ thống gởi nhận thông điệp hoặc phần mềm trung gian hướng thông điệp (Message - Oriented Middleware (MOM)) (Hình 2-12). Hệ thống gởi nhận thông điệp cho phép hai hay nhiều ứng dụng trao đổi thông tin dưới dạng thông điệp (message). 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 và 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. Trong hệ thống gởi nhận thông điệ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. Hình 2.13: Mô hình hệ thống gửi nhận thông điệp
38 Trong tất cả các hệ thống gởi nhận thông điệ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 và các ứng dụng gửi tin nhắn được tách riêng. Bên gửi và bên nhận không bị ràng buộc với nhau trong bất kỳ hoàn cảnh nào và có thể gửi và nhận thông điệp theo bất kỳ cách nào phù hợp. Hay nói một cách khác 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 mô hình thông tin ngang hàng (peer-to-peer). Một máy khách có thể gởi thông điệp đi và 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 agent cung cấp công cụ truyền thông để tạo, gởi,nhận và đọc 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), và bên nhận có thể thu được thông điệp này từ đích. Tuy nhiên, bên gửi và 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 và bên nhận chỉ cần biết khuôn dạng thông điệp và đích (destination) để sử dụng. 2.3.2 Tổng quan về JMS JMS là một API dùng cho việc gởi nhận thông điệp được Sun phát triển từ JSR- 914. JMS không phải là một hệ thống gởi nhận thông điệp mà chỉ là một trừu tượng hóa (abstraction) của những interface và class được dùng bởi messaging client khi giao tiếp với messaging system. Giống như cách JDBC trừu tượng hóa truy cập tới CSDL quan hệ và JNDI trừu tượng hóa truy cập tới dịch vụ đặt tên và đường dẫn (naming and directory services), JMS cũng trừu tượng hóa truy cập tới các messaging provider. Trong JMS, các client gởi nhận thông điệp được gọi là JMS client, và 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 và thường là một JMS provider. 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 là message consumer. Một JMS client có thể vừa là message producer vừa là message consumer. JMS API có thể được chia làm 3 phần chính: API tổng quát, API P2P và API pub/sub. API tổng quát có thể được dùng để gởi nhận message từ queue hoặc topic. API P2P chỉ được dùng với queue còn API pub/sub chỉ được dùng với topic. Trong API tổng quát có 7 interface chính để gởi nhận JMS message: - ConnectionFactory - Destination - Connection - Session - Message - MessageProducerMessageConsumer
39 ConnectionFactory và Destination phải được lấy từ provider qua JNDI. Các interface khác được tạo ra bằng factory method trong nhiều API interface. Ví dụ: khi đã có ConnectionFactory, chúng ta có thể tạo Connection. Khi đã có Connection, có thể tạo Session. Khi đã có Session, chúng ta có thể tạo Message, Message Producer và Message Receiver. 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ư 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 API cho phép gởi nhận thông điệp không chỉ “liên kết lỏng lẻo” mà còn không đồng bộ. 2.3.3 Các mô hình gửi nhận thông điệp trong JMS JMS hỗ trợ hai loại mô hình gởi nhận thông điệp: point – to - point và publish – 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 và publish – subscribe thường được viết tắt là p2p và pub/sub. Hiểu theo nghĩa đơn giản nhất, publish – subscribe là việc gởi thông điệp từ một tới nhiều, còn point – to - point là việc gởi thông điệp một - một. Hình 2.14: Mô hình tổng quát JMS
40 2.3.3.1 Point – to – point Mô hình point – to – point (Hình 2-15) cho phép các JMS client gởi và nhận thông điệp đồng bộ lẫn bất đồng bộ qua các kênh ảo gọi là queue (hàng đợi). Trong mô hình point – to - point, message producer được gọi là sender và message consumers được gọi là receivers. Một điểm đặc trưng của mô hình point – to - point là các thông điệp được gửi tới queue chỉ được nhận bởi một và chỉ một receiver, mặc dù có thể có nhiều receiver cùng nghe trên một queue để nhận cùng thông điệp. Point – to - point hỗ trợ gởi nhận thông điệp bất đồng bộ theo kiểu “fire and forget” cũng như gởi nhận thông điệp đồng bộ. Point – to - point có xu hướng chặt chẽ hơn mô hình publish – subscribe vì sender thường biết thông điệp sẽ được sử dụng như thế nào và ai nhận được nó. Mô hình point – to - point hỗ trợ cân bằng tải, cho phép nhiều receiver cùng nghe trên một queue, phân tán được tải trọng. JMS provider quản lý queue, đảm bảo rằng một message chỉ được tiêu thụ một và chỉ một lần bởi receiver tiếp theo trong nhóm. 2.3.3.2 Publish - subscribe Trong mô hình publish – subscribe (Hình 2-16), các thông điệp được publish vào một kênh ảo gọi là topic. Message producer được gọi là publisher và message consumers được gọi là subsciber. Không như mô hình point – to - point, thông điệp được publish vào topic có thể được nhiều subscriber nhận. Kỹ thuật này đôi khi được gọi là “phát sóng” một thông điệp. Mỗi subscriber sẽ nhận được một bản sao của từng thông điệp. Hình 2.15: Hai mô hình gửi nhận message trong JMS Hình 2.16: Mô hình point - to - point
41 Thông điệp trong mô hình publish - subscribe được phát tự động tới các consumer mà không cần chúng yêu cầu thông điệp. Mô hình publish - subscribe có xu hướng thiếu chặt chẽ hơn mô hình point – to - point vì publisher thường không biết có bao nhiêu subscriber hoặc subscriber sẽ làm gì với thông điệp. Ví dụ, giả sử một thông điệp được publish vào topic mỗi khi ứng dụng có exception. Publisher chỉ có trách nhiệm publish mỗi khi có exception. Publisher không biết và thường không quan tâm thông điệp sẽ được sử dụng như thế nào. Có nhiều loại subscriber khác nhau trong mô hình publish - subscribe. Subscriber không lâu dài là những subscriber đăng ký tạm, chỉ nhận thông điệp khi chủ động nghe topic. Subscriber lâu dài sẽ nhận bản sao của tất cả thông điệp được đăng, kể cả khi chúng “offline” lúc thông điệp được đăng. 2.4 ANGULARJS 2.4.1 Tổng quan về AngularJS Công nghệ HTML hỗ trợ tốt cho các trang web tĩnh, kiểu như trước năm 2000 vậy. Khi chúng ta xây dựng 1 trang web với PHP, Node/Express, hay Ruby thì nó cũng chỉ là một trang web tĩnh với nội dung được thay đổi khi chúng ta gửi request về máy chủ, máy chủ sẽ render 1 trang với nội dung tương ứng. Tuy nhiên mọi thứ đã thay đổi nhiều từ sự phát triển của HTML5, nhất là khi có sự hổ trợ từ những tập đoàn công nghệ lớn như Google, Yahoo, Facebook, và sự tập hợp đông đảo của cộng đồng mã nguồn mở. Ngoài ra sự thành công của jQuery đã khiến JavaScript được nhiều người yêu thích vì tính đơn giản và dễ sử dụng. Việc phát triển một website sử dụng AJAX thì không khó, chúng ta có thể dùng jQuery để làm việc này với $.ajax tuy nhiên làm thế nào để xây dựng một phần mềm có thể mở rộng, dễ test, nâng cấp và bảo trì thì không hề đơn giản vì bản thân JavaScript không được thiết kế ngay từ đầu để làm những việc này. Do đó sự ra đời của những framework hỗ trợ lập trình viên xây dựng ứng dụng web 1 cách có hệ thống đã ra đời như Sencha, Ember, Knockout, Backbone, CanJS và AngularJS. AngularJS là framework JavaScript được bắt đầu phát triển từ năm 2009, do lập trình viên Misko Hevery tại Google viết ra như là một dự án kiểu “viết cho vui”. Misko và nhóm lúc này đang tham gia vào 1 dự án của Google tên là Google Feedback. Với AngularJS, Misko đã rút ngắn số dòng code front-end từ 17000 dòng còn chỉ khoảng 1500. Với sự thành công đó, đội ngũ của dự án Google Feedback quyết định phát triển Hình 2.17: Mô hình publish - subscribe
42 AngularJS theo hướng mã nguồn mở. Theo thông số từ Github hiện tại dự án AngularJS đang có gần 11.000 người theo dõi và hơn 2.000 lượt fork. Ngày nay các ứng dụng web hiện đại thường được xây dựng như một Single Page Application (SPA) và AngularJS là một framework tuyệt vời để xây dựng 1 SPA. Một Single Page Application là một ứng dụng web hiển thị vừa vặn trên một mặt của trang với mục đích giúp người dùng có trải nghiệm giống như đang dùng ứng dụng trên desktop và làm tăng hiệu suất của ứng dụng [3, tr7]. Hay nói một cách khác là ứng dụng chạy bên trong trình duyệt mà không yêu cầu phải tải lại toàn bộ trang web mỗi lần sử dụng. 2.4.2 Các đặc trưng của AngularJS Dưới đây là những đặc trưng nổi bật của AngularJS: kiến trúc MVC, Two-way binding, Templates, Expressions, Modules, Scopes, Dependency injection, Directives, Routing, Services, Filters, Form validation, Testing. 2.4.2.1 Kiến trúc MVC trong AngularJS MVC (Model - View - Controller) là một kiến trúc phần mềm hay mô hình thiết kế được sử dụng trong kỹ thuật phần mềm. Nó giúp cho các nhà phát triển tách ứng dụng của họ ra 3 thành phần khác nhau Model (xử lý, truy xuất database), View (giao diện) và Controller (điều hướng yêu cầu từ người dùng). Mỗi thành phần có một nhiệm vụ riêng biệt và độc lập với các thành phần khác. MVC thể hiện tính chuyên nghiệp trong lập trình, phân tích thiết kế. Do được chia thành các thành phần độc lập nên giúp phát triển ứng dụng nhanh, đơn giản, dễ nâng cấp, bảo trì. Hình 2.18: Single Page Application
43 Đối với Angular, View sẽ là DOM, Controller là các lớp JavaScript, còn Model sẽ là dữ liệu được lưu ở thuộc tính của các đối tượng trong JavaScript. 2.4.2.2 Two-way binding Two-way binding cùng với Directive là hai trong những đặc trưng nổi bật mang lại sức mạnh cho AngularJS. Để hiểu rõ hơn về two-way binding ta sẽ xem xét one-way binding trước. Khi làm việc với các mô hình MVC framework khác chúng ta sẽ rơi vào trường hợp model và view chỉ được ghép với nhau một lần duy nhất, vì vậy mọi sự cập nhật dữ liệu từ một trong hai lớp đó đều không liên quan gì đến lớp còn lại. Hệ quả là developer phải viết thêm phần “đồng bộ hóa” giữa hai lớp này. Đó chính là one-way binding. Tuy nhiên AngularJS có thể thực hiện được cả hai chiều, đó chính là two-way binding. Hay nói một cách khác two-way binding trong AngularJS là tính năng đồng bộ hóa giữa model và view. Quá trình đồng bộ luôn xảy ra giữa model và view. Mọi sự thay đổi dữ liệu trong lớp này, ngay lập tức được cập nhật vào lớp kia [7, 11]. Chúng ta chỉ cần “bind” một lần, và mọi thứ hoạt động trơn tru. Hình 2-19 sẽ cho thấy rõ hơn về one-way binding và two-way binding. Cũng vì dữ liệu mà view hiển thị thực chất là sự ánh xạ từ model, nên controller cũng hoàn toàn không cần các thao tác data binding phức tạp và phụ thuộc vào cấu trúc DOM của view, kết quả là controller sẽ không quan tâm xem view của chúng ta là gì. Và dĩ nhiên, logic giữa controller và view được bóc tách rất rõ ràng. Code của chúng ta sẽ rất dễ để debug, viết unit-test. Hình 2.20: One-way binding và Two-way binding Hình 2.19: Kiến trúc MVC trong AngularJS
44 2.4.2.3 Directives Tính năng mới này thực sự là đặc điểm tạo nên một khoảng cách lớn giữa Angular và bất kỳ framework JavaScript khác. Directives đề cập đến một tính năng để mở rộng HTML, việc dùng directive sẽ giảm thiểu được số lượng thẻ HTML, code HTML nhìn sẽ gọn gàng và sáng sủa hơn. Mặc dù HTML có thể có nhiều thẻ, nhưng nó không đủ mạnh để tạo ra một ứng dụng web hiện đại. Với directive, chúng ta có thể tạo ra những thẻ HTML mới hoặc các thuộc tính mới cho tất cả các thẻ trong HTML để trình duyệt hiểu nó có nghĩa là gì và nên làm gì. Ví dụ với Angular chúng ta có thể tạo ra thẻ như sau <draggable> drag me </ draggable >. Các văn bản bên trong tag <draggable></ draggable> bây giờ sẽ trở thành draggable trong trình duyệt, sau đó chỉ cần viết một định nghĩa cho directive draggable này trong ứng dụng Angular của chúng ta là xong. Đây là một ví dụ đơn giản của Angular, nó có thể làm rất nhiều thứ hữu ích hơn. Directtive không chỉ giới hạn một phần tử HTML mà còn có thể là thuộc tính, lớp hoặc các chú thích HTML. AngularJS cung cấp cho chúng ta 3 loại directive: - Directive dạng element (một thẻ HTML) viết tắt là E: - Directive dạng attribute (thuộc tính của một thẻ HTML) viết tắt là A, dạng này là mặc định. - Directive dạng class(class CSS) viết tắt là C. 2.4.2.4 Templates Trong quá trình xây dựng hệ thống lớn, file HTML trở nên rất phức tạp, để giải quyết vấn đề này ta cần chia thành nhiều phần khác nhau, AngularJS cung cấp cho chúng ta một giải pháp hữu ích đó là template. Angular template là một đặc tả dạng declarative, cùng với thông tin từ model và controller, template được render thành một view mà để hiển thị trên trình duyệt. Template bao gồm các static DOM chứa HTML, CSS và các thành phần, thuộc tính riêng của Angular. Các thành phần Angular và các thuộc tính giúp Angular thêm các hành vi và biến đổi template thành dynamic view DOM. Trong Angular, chúng ta có 2 cách để tạo một template: - Dùng file script: Chúng ta có thể tích hợp template vào file HTML hiện hành thông qua thẻ script với type là text/ng-template <my-directive>...</my-directive> <div my-directive>...</div> <div class="my-directive">...</div>
45 - Dùng file ngoài: Chúng ta cũng có thể tạo một file html với nội dung sau: - Sử dụng template: Có nhiều cách để sử dụng template, tuy nhiên trong AngularJS có 2 cách thông dụng để dùng template đó là ng-include và ng-route. Ví dụ dưới đây sẽ dùng ng-include để sử dụng template: Tuy nhiên cách sử dụng ng-include chỉ thích hợp trong các ứng dụng nhỏ, đối với các ứng dụng lớn ng-route (được trình bày trong phần xây dựng ứng dụng) được sử dụng nhiều hơn. 2.4.2.5 Dependency Injection Dependency Injection làm cho ứng dụng Angular dễ dàng hơn để phát triển, có thể sắp xếp mã (code) thành các module. Bằng cách này, chúng ta có thể tạo ra các thành phần tái sử dụng mà có thể được gọi về sau, bất cứ khi nào cần thiết. Ý tưởng này là đặc biệt tốt khi ứng dụng lớn và cần phải được mở rộng, dễ dàng bảo trì và testing. Dependency Injection là một cách để ghép các đoạn code với nhau, điều này đòi hỏi phải phân chia code theo các chức năng riêng biệt như service, controller, hoặc provider. 2.4.2.6 Services Service trong AngularJS là một object hoặc một function phụ trách một tác vụ nào đó. Việc viết service chỉ là việc gom các đoạn xử lý logic vào object hoặc function để dễ quản lý hơn. Cũng giống như mô hình MVC tách phần xử lý, điều hướng và hiển thị riêng biệt. <script type="text/ng-template" id="message.html"> <h3>Hello, {{name}}!</h3> </script> message.html <web-app> <display-name>Music Manager</display-name> index.html <!DOCTYPE html> <html> <head> <script src="http://code.angularjs.org/1.2.12/angular.min.js"> </script> </head> <body> <div ng-controller="ExampleCtrl"> <div ng-include src="message.html"></div> </div> </body> </html>
46 Trong AngularJS service sẽ chứa tất cả các phần xử lý, controller nhận yêu cầu và gọi các service cần thiết để xử lý, model lưu trữ dữ liệu từ các control, view hiển thị dữ liệu, route điều hướng request tới controller. AngularJS cũng xây dựng rất nhiều service vô cùng tiện lợi như: $http, $scope, $window,… 2.4.2.7 Expression Expression được sử dụng trong tất cả các phần của AngularJs, expression được bao bởi kí hiệu {{ }}. Một biến được khởi tạo từ controller thông qua $scope cũng được coi là một expression. Expression được xử lý bởi $parse service. Ví dụ: <body> 2 + 2 = {{2 + 2}} </body>. Angular sẽ tính toán giá trị trong biểu thức và xuất ra màn hình kết quả “2 + 2 = 4”. 2.4.2.8 Fillters Trong AngularJS, một filter cung cấp một định dạng dữ liệu để hiển thị tới người dùng. AngularJS cung cấp một số filter được xây dựng sẵn như: lowercase, date, number, currency, limitTo, orderBy… Một số fillter như: Kết quả: 2.4.2.9 Scope Scope là đối tượng tham chiếu tới model được sử dụng trong controller. Là thành phần gắn kết giữa view và controller. Scope cung cấp các APIs để theo dõi các thay đổi của model (services $watch) và các APIs để truyền bất kỳ thay đổi nào của model tới view (services $apply). Scope giúp tự động đồng bộ dữ liệu giữa model và view. 2.5 MONGODB 2.5.1 Tổng quan về NoSQL 2.5.1.1 NoSQL NoSQL là một dạng CSDL mã nguồn mở không sử dụng T - SQL để truy vấn thông tin. NoSQL viết tắt cho từ None - Relational SQL, hay có nơi thường gọi là Not - Only SQL. {{ "chuỗi kí tự viết thường" | uppercase }} {{ {name: "An", age: 22} | json }} {{ 1504375948024 | date }} {{ 1504375948024 | date:"MM/dd/yyyy @ h:mma" }} CHUỖI KÍ TỰ VIẾT THƯỜNG { "name": "An", "age": 22 } March 23, 2015 03/23/2015 @ 5:39AM
47 NoSQL được phát triển trên Javascript Framework với kiểu dữ liệu là JSON và dạng dữ liệu theo kiểu key và value (một đặc trưng về dữ liệu trong JSON). NoSQL ra đời như một mảnh vá cho những khuyết điểm và thiếu xót cũng như hạn chế của mô hình dữ liệu quan hệ (RDBMS) về tốc độ, tính năng, khả năng mở rộng, memory cache,... Chắc hẳn, chúng đã sử dụng một dạng CSDL quan hệ nào đó có thể là SQL Server, MySQL và không ít lần phải vất vả trong việc chỉnh sửa các bảng dữ liệu khi liên quan tới khóa chính, khóa ngoại hay một loạt các rắc rối khác trong quá trình làm việc. Bởi đó là CSDL quan hệ. Với NoSQL chúng ta có thể mở rộng dữ liệu mà không lo tới những việc như tạo khóa ngoại, khóa chính, kiểm tra ràng buộc, .v.v...Vì NoSQL không hạn chế việc mở rộng dữ liệu nên tồn tại nhiều nhược điểm như: sự phục thuộc của từng bản ghi, tính nhất quán, toàn vẹn dữ liệu,....nhưng chúng ta có thể chấp nhận những nhược điểm đó để khiến ứng dụng cải thiện hiệu suất cao hơn khi giải quyết những bài toán lớn về hệ thống thông tin, phân tán hay lưu trữ dữ liệu. Với các CSDL quan hệ, chi phí triển khai cũng như phát triển các ứng dụng sử dụng CSDL quan hệ cũng rất tốn kém và điều quan trọng được bộc lộ rõ khi truy vấn một lượng bản ghi lớn trong thời gian rất dài. Tiếp đó những thiết bị cầm tay như smartphone thì không phù hợp để triển khai CSDL quan hệ vì dung lượng bộ nhớ thấp và khả năng xử lý kém hơn máy tính. Và còn rất nhiều lí do khác nữa để chúng ta quyết định việc áp dụng NoSQL vào trong dự án của mình. NoSQL được sử dụng ở rất nhiều công ty, tập đoàn lớn, ví dụ như FaceBook sử dụng Cassandra do FaceBook phát triển, Google phát triển và sử dụng BigTable. 2.5.1.2 Các dạng NoSQL cơ bản 2.5.1.2.1 Key – value Dữ liệu lưu dưới dạng cặp key – value. Giá trị được truy xuất thông qua key. Ví dụ như Redis, Dynomite, Project Voldemort. Thường được sử dụng cho “content caching applications”. Ưu điểm là tìm kiếm rất nhanh tuy nhiên dữ liệu không theo khuôn dạng (schema) nhất định. 2.5.1.2.2 Column-based Cơ sở dữ liệu tổ chức dưới dạng các bảng. Gần giống với mô hình RDBMS. Tuy nhiên, chúng lưu dữ liệu bởi các cột chứ không phải bằng các dòng. Nó khá thích hợp để hiển thị bằng các phần mềm quản lý kho dữ liệu. Ví dụ như Apache Hbase, Apache Cassandra, Hypertable. Được sử dụng cho các hệ phân tán file. Ưu điểm là tìm kiếm nhanh, phân tán dữ liệu tốt tuy nhiên có rất ít phần mềm hổ trợ. 2.5.1.2.3 Document-based Dữ liệu được lưu trữ và tổ chức dưới dạng một tập hợp các document. Các document này linh hoạt, mỗi document có một tập nhiều trường. Ví dụ như Apache CouchDB, MongoDB. Thường dùng trong các ứng dụng web. Ưu điểm dùng khi dữ liệu nguồn không được mô tả đầy đủ. Nhược điểm hiệu năng truy vấn, không có cú pháp chuẩn cho câu truy vấn dữ liệu.
48 2.5.1.2.4 Graph-based Những CSDL này áp dụng lý thuyết đồ thị trong khoa học máy tính để lưu trữ và truy xuất dữ liệu. Chúng tập trung vào tính rời rạc giữa các phần dữ liệu. Các phần tử đơn vị dữ liệu được biểu thị như một nút và liên kết với các thành phần khác bằng các cạnh. Ví dụ : Neo4j, InfiniteGraph, DEX. Thường dùng cho Social networking, hệ trợ giúp. Có ưu điểm là ứng dụng các thuật toán trên đồ thị như đường đi ngắn nhất, liên thông. Nhược điểm là phải duyệt nội bộ đồ thị để trả lời lại các truy vấn. Không dễ để phân tán. 2.5.2 MongoDB 2.5.2.1 Tổng quan MongoDB là một hệ CSDL mã nguồn mở được phát triển và hỗ trợ bởi 10gen, là CSDL NoSQL hàng đầu được hàng triệu người sử dụng. Thay cho việc lưu trữ dữ liệu dưới dạng bảng và các tuple như trong các CSDL quan hệ thì MongoDB lưu trữ dữ liệu dưới dạng BSON (dạng binary từ một JSON document). BSON hổ trợ các kiểu dữ liệu cơ bản như boolean, integer, float, date, string,… [5, tr7] Dự án được bắt đầu triển khai vào tháng 10 năm 2007 bởi 10gen trong khi công ty này đang xây dựng một nền tảng như là dịch vụ (Platform as a Service) giống như Google App Engine. Phải đến năm 2009, dự án này được tách độc lập. MongoDB có thể chạy trên Windows, Linux, OS X và Solaris. 2.5.2.2 Ưu điểm Dễ học, có một số nét khá giống với CSDL quan hệ, quản lý bằng command - line hoặc bằng GUI như RoboMongo, RockMongo hoặc phpMoAdmin. Linh động, không cần phải định nghĩa cấu trúc dữ liệu trước khi tiến hành lưu trữ nó, rất tốt khi ta cần làm việc với các dạng dữ liệu không có cấu trúc. Khả năng mở rộng tốt (distributed horizontally), khả năng cân bằng tải cao, tích hợp các công nghệ quản lý dữ liệu vẫn tốt khi kích thước và thông lượng trao đổi dữ liệu tăng. Mã nguồn mở và miễn phí. 2.5.2.3 Kiến trúc tổng quát Một MongoDB Server sẽ chứa nhiều database. Mỗi database lại chứa một hoặc nhiều colection. Đây là một tập các documnents, về mặt logic thì chúng gần tương tự như các table trong CSDL quan hệ. Tuy nhiên, điểm hay ở đây là ta không cần phải định nghĩa trước cấu trúc của dữ liệu trước khi thao tác thêm, sửa dữ liệu… Một document là một đơn vị dữ liệu – một bản ghi (không lớn hơn 16MB). Mỗi document lại chứa một tập các trước hoặc các cặp key – value. Key là một chuỗi ký tự, dùng để truy xuất giá trị dạng: string, integer, double, … Bảng dưới đây đưa ra một so sánh giữa các thành phần trong một RDBMS và MongoDB Bảng 2-2: So sánh các thành phần giữa RDBMS và MongoDB RDBMS MongoDB
49 Database Database Table Collection Tuple/Row Document Column Field Table join Embedded documents Primary key Primary Key ( _id là khóa primary key mặc định) Dưới đây là một ví dụ về MongoDB document: 2.6 BOOTSTRAP VÀ RESPONSIVE Bootstrap là front-end framework, là một bộ sưu tập miễn phí các công cụ để tạo ra các trang web và các ứng dụng web. Bootstrap bao gồm HTML và CSS dựa trên các mẫu thiết kế cho kiểu chữ, hình thức, các button và các thành phần giao diện khác, cũng như mở rộng tùy chọn JavaScript. Boostrap định nghĩa sẵn các class CSS giúp người thiết kế giao diện website tiết kiệm rất nhiều thời gian. Các thư viện Bootstrap có những đoạn mã sẵn sàng cho chúng ta áp dùng vào website của mình mà không phải tốn quá nhiều thời gian để tự viết. Với Bootstrap, việc phát triển giao diện website để phù hợp với đa thiết bị trở nên dễ dàng hơn bao giờ hết. Đây là xu hướng phát triển giao diện website đang rất được ưu chuộng hiện nay. Bootstrap cung cấp tính năng responsive và mobile first, nghĩa là làm cho trang web có thể tự co giãn để tương thích với mọi thiết bị khác nhau, từ điện thoại di động đến máy tính bảng, máy tính xách tay, máy tính để bàn,... Một khía cạnh khác là responsive web design làm cho trang web cung cấp được trải nghiệm tuyệt vời cho người dùng trên nhiều thiết bị, kích thước màn hình khác nhau. Đây là một đặc điểm vô cùng quan trọng vì chúng ta không thể lường trước được các thiết bị, kích thước màn hình sẽ sử dụng để truy cập vào trang web. Một trang có thể hoạt động tốt bất kể sự biến đổi sẽ cung cấp một trải nghiệm người dùng tốt và nhất quán hơn một trang được thiết kế cho một loại thiết bị và kích thước màn hình cụ thể. { "_id" : ObjectId("54b090b1fe90b289da2ac6b8"), "firstName" : "An", "lastName" : "Nguyen", "age" : 22, "sex" : "male", "lastUpdate" : ISODate("2015-03-07T06:39:57.780Z") }
50 Chương 3 THIẾT KẾ VÀ CÀI ĐẶT CHƯƠNG TRÌNH 3.1 MÔ HÌNH ỨNG DỤNG Nhằm mục đích áp dụng các lý thuyết cũng như các kỹ thuật đã nêu ở phần trên, chúng tôi sẽ phân tích và cài đặt một ứng dụng quản lý nhạc trên nền web. Ứng dụng được xây dựng theo mô hình sau (Hình 3-1). Chúng tôi sẽ chia ứng dụng thành 2 module lớn: Module server và module client. Module server sẽ chịu trách nhiệm tương tác với database. Module client bao gồm việc xây dựng các API dưới dạng RESTful web service và giao diện người dùng trên browser. Việc giao tiếp qua lại giữa client và server sẽ được cài đặt theo mô hình một Messaging System. Sơ đồ trang tiếp theo ở trang tiếp theo sẽ cho thấy mô hình chi tiết và luồng thực thi của ứng dụng. Hình 3.1: Mô hình ứng dụng
51 Hình 3.2: Mô hình chi tiết của ứng dụng
52 Hình 3.3: Luồng thực thi của ứng dụng
53 Trong phạm vi luận văn này tôi sẽ tập trung vào việc thiết kế và xây dựng module client. Module server được đề cập đến trong luận văn của bạn Lê Thành Được. Như đã mô tả ở phần trên module client bao gồm 2 nhiệm vụ là thiết kế giao diện người dùng trên nền web và xây dựng các API dưới dạng RESTful web service. HTML, CSS, Bootstrap và AngularJS sẽ được sử dụng để thiết kế giao diện và lập trình phía front- end. Phía back-end sẽ sử dụng Spring framework bao gồm Spring MVC để cài đặt các API RESTful service, Spring Security để xác thực và phân quyền người dùng và Camel Client được sử dụng để giao tiếp với database server thông qua ActiveMQ. Mô hình của module client như hình 3-4. 3.2 THIẾT KẾ MESSAGE Trong một hệ thống gửi nhận thông điệp thì cấu trúc của message là rất quan trọng. Để giao tiếp với nhau các thành phần của hệ thống phải hiểu được cấu trúc của message, vì vậy cấu trúc của nó thường được các thành phần thống nhất với nhau ngay từ khi bắt đầu xây dựng hệ thống. Việc thiết kế message phải đảm bảo được tính mềm dẻo và dễ dàng mở rộng của hệ thống. Phần này sẽ mô tả cấu trúc của message được sử dụng trong ứng dụng. Nếu request của client cần phải thao tác với CSDL thì một message sẽ được controller build và chuyển nó cho producer để gửi nó lên MOM. Module server sẽ chịu trách nhiệm xử lý message này và kết quả sau khi xử lý xong sẽ được gửi lại cho producer đã gửi lên. Dưới đây là sơ đồ class của message. Hình 3.4: Module client
54 Cấu trúc dạng Json của một message: Về mô hình gửi nhận message, message trong hệ thống sẽ được cài đặt theo mô hình point – to – point vì mô hình này có sự đảm bảo chặt chẽ về việc một message thì chỉ được xử lý một lần, điều này là phù hợp với ứng dụng của chúng ta. 3.3 THIẾT KẾ CƠ SỞ DỮ LIỆU Chúng tôi chọn MongoDB để làm hệ quản trị CSDL cho ứng dụng này bởi những lợi ích của nó mang lại mà như chúng tôi đã trình bày trong phần 2.5. Dưới đây là cấu trúc của một số document (record). { "action": "UPDATE", "data": { "artist": "Tokyo Square", "download": 16, "gener": "Rock", "id": "1b8aa99c-8d98-43f0-9469-55b5b7cea944", "lastUpdate": 1425710397780, "musician": "N/A", "name": "That Is Love", "path": "/music/1b8aa99c-8d98-43f0-9469-55b5b7cea944.mp3", "shared": false, "username": "nthienan", "view": 10 }, "method": "PUT" } [ { "_id": "6635f2e6-4455-480c-bae8-5826f6a383e3", "_class": "agu.thesis2015.domain.Song", "name": "Take Me To Your Heart", "gener": "Pop", "artist": "Michael Learns To Rock", "musician": "Stock Aitken Waterman", Hình 3.5: Sơ đồ class Message
55 Hình 3-6 cho thấy 2 document trên được xem trong giao diện RoboMongo "path": "/music/6635f2e6-4455-480c-bae8-5826f6a383e3.mp3", "lastUpdate": "ISODate(2015-03-07T06:38:29.848Z)", "download": 0, "view": 3, "username": "nthienan" }, { "_id": "ac70254b-157f-41d3-98e2-93b93ce844c1", "_class": "agu.thesis2015.domain.Song", "name": "Can't Let Go", "gener": "Pop", "artist": "Tokyo Square", "musician": "N/A", "path": "/music/ac70254b-157f-41d3-98e2-93b93ce844c1.mp3", "lastUpdate": "ISODate(2015-03-07T06:42:38.162Z)", "download": 0, "view": 2, "username": "nthienan", "shared": true } ] Hình 3.6: Document trong giao diện RoboMongo
56 3.4 RESTful API Hình 3.7 và 3.8 trình bày các REST API mà phía back-end (Spring MVC) đã xây dựng để phía fornt-end (AngularJS) sử dụng. Hình 3.7: RESTful API về bài hát Hình 3.8: RESTful API về user
57 3.5 CƠ CHẾ BẢO MẬT ỨNG DỤNG Việc bảo mật ứng dụng sẽ tập trung vào việc bảo vệ các RESTful API bởi vì tất cả các thao tác nghiệp vụ đều được xử lý thông qua các API này. Chúng tôi sẽ sử dụng module Spring Security để xây dựng cơ chế bảo vệ các RESTful API. Hình 3.9 sẽ cho thấy chi tiết cơ chế bảo mật của ứng dụng. Hình 3.9: Cơ chế bảo mật ứng dụng 3.6 SƠ ĐỒ USECASE Bảng 3-1: Danh sách các actor Actor Vai trò User User là đối tượng chính tác động trực tiếp và nhiều nhất vào hệ thống. User có thể thực hiện hầu như các chức năng của ứng dụng. Admin Admin là actor kế thừa actor user và thêm Bảng dưới đây trình bày các chức năng chính của ứng dụng. Bảng 3-2: Danh sách các usecase Chức năng Mô tả Login Xác thực và phân quyền cho người dùng khi họ sử dụng ứng dụng Logout Thoát khỏi phiên làm việc. Sign up Đăng ký tài khoản để sử dụng ứng dụng Change password Thay đổi mật khẩu người dùng
58 Dưới đây là sơ đồ mối quan hệ giữa các actor với actor, actor với use case và use case và use case. Add song Thêm một bài hát mới vào ứng dụng Edit song Chỉnh sửa thông bài hát Delete song Xóa bài hát Play song Phát bài hát Download Tải bài hát Add user Thêm người dùng Edit user Chỉnh sửa thông tin người dùng Delete user Xóa người dùng Reset password Khôi phục mật khẩu Hình 3.10: Sơ đồ use case của actor user
59 Hình 3.11: Sơ đồ use case của actor Role_User Hình 3.12: Sơ đồ use case của actor Role_Admin
60 3.7 GIAO DIỆN VÀ CHỨC NĂNG 3.7.1 Một số giao diện chính Dưới đây là một số giao diện và chức năng chính của ứng dụng. Hình 3.14: Giao diện đăng nhập Hình 3.13: Giao diện đăng ký người dùng
61 Hình 3.17: Giao diện danh sách bài hát Hình 3.15: Giao diện play nhạc Hình 3.16: Giao diện bài hát được chia sẻ
62 Hình 3.19: Giao diện sửa thông tin bài hát Hình 3.18: Giao diện tìm kiếm bài hát Hình 3.20: Giao diện sửa thông tin user
63 Hình 3.23: Giao diện đổi password Hình 3.22: Giao diện thống kê các thông tin Hình 3.21: Giao diện quản lý user
64 3.7.2 Một số chức năng nổi bật của ứng dụng Khi đăng ký thành công tài khoản, một email chứa link để kích hoạt tài khoản được gửi đến người dùng. Tài khoản trước và sau khi kích hoạt (xem trong giao diện quản lý người dùng của admin). Người dùng chỉ có thể đăng nhập vào ứng dụng khi tài khoản đã được kích hoạt. Tính năng đa ngôn ngữ của ứng dụng. Ứng dụng hỗ trợ 2 ngôn ngữ là Tiếng Việt và Tiếng Anh. Hình 3.24: Giao diện sửa thông tin user của admin Hình 3.25: Email kích hoạt tài khoản khi đăng ký thành công Hình 3.26: Tài khoản trước và sau khi kích hoạt
65 Hình 3.28: Ứng dụng với ngôn ngữ Tiếng Anh Hình 3.27: Ứng dụng với ngôn ngữ Tiếng Việt
66 Chương 4 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 4.1 KẾT QUẢ ĐẠT ĐƯỢC Nghiên cứu và trình bày một cách có hệ thống các nội dung cơ bản về Spring framework, AngularJS, JMS, MongoDB và một số công nghệ, kỹ thuật khác trong việc xây dựng một ứng dụng Java enterprise trên nền web. Về mặt lý thuyết: - Nắm được kiến trúc tổng quan của Spring Framework cũng như các nguyên lý cơ bản và cơ chế hoạt động của framework này. - Nắm được mô hình web MVC trong Spring framework và các cơ chế để bảo mật một ứng dụng web được hỗ trợ trong module Spring Security. - Hiểu cơ chế giao tiếp giữa client và server trong mô hình web hiện đại theo hướng RESTful service; cách giao tiếp giữa các thành phần của một hệ thống hoặc giữa các hệ thống với nhau thông qua mô hình Messaging system. Về mặt ứng dụng: - Thiết kế và cài đặt được ứng dụng web với mô hình web server và data server tách biệt nhau, giao tiếp với nhau thông qua ActiveMQ. - Xây dựng được ứng dụng web dạng SPA mà việc giao tiếp với server thông qua RESTful service với sự hỗ trợ của AngularJS. - Thiết kế giao diện người dùng với HTM5 và Bootstrap có hỗ trợ responsive. - Xây dựng thành công ứng dụng quản lý nhạc với đầy đủ các chức năng cơ bản. - Xây dựng thành công một ứng dụng quản lý nhạc trên nền web có áp dụng các công nghệ mới trong quá trình phát triển một ứng dụng Web enterprise hiện đại. 4.2 HẠN CHẾ Các chức năng cơ bản của ứng dụng đã hoàn thành tốt, tuy nhiên do yêu cầu và phạm vi đề tài chỉ dừng lại ở mức demo công nghệ nên ứng dụng chưa hấp dẫn. Hạn chế về vật chất, không có host trên internet có cài đặt đầy đủ các phần mềm cần thiết tạo khó khăn trong việc thực hiện demo chương trình trên internet. Vấn đề triển khai những công nghệ nêu trên không khó về mặt kỹ thuật nhưng phải xây dựng một cơ sở hạ tầng đầy đủ và tốt để có thể thực thi ứng dụng. 4.3 HƯỚNG PHÁT TRIỂN Tiếp tục tìm hiểu về một số cơ chế xác thực và phân quyền trong module Spring Security như cơ chế xác thực Oauth, Oauth2, OpenID,… để xây dựng ứng dụng với cơ chế bảo mật hơn. Bên cạnh đó tiếp tục tìm hiểu các module còn lại của Spring Framework như Spring AOP nhằm tích hợp vào hệ thống để thực hiện một số chức năng đặc biệt như ghi log người dùng. Tìm hiểu về web socket và kết hợp với AngularJS để hướng đến việc xây dựng một ứng dụng web động với thời gian thực.
67 TÀI LIỆU THAM KHẢO [1] Ankur Bawiskar, Prashant Sawant, Vinayak Kankate, B.B. Meshram. Spring Framework A Companion to JavaEE. International Journal of Computational Engineering & Management, Vol. 15 Issue 3, May 2012 [2] Ben Alex, Luke Taylo. Spring Security Reference Documentation [3] Hồ Ngọc Hùng. 2014. Single Page Web Application with Restful API And AngularJS. Helsinki Metropolia University of Applied Sciences [4] Praveen Gupta, Govil. Spring Web MVC Framework for rapid open source J2EE application development a case study. International Journal of Engineering Science and Technology, Vol. 2(6), 2010, 1684-1689 [5] Rick Cattell. 2010. Scalable SQL and NoSQL Data Stores [6] Rod Johnson, Juergen Hoeller, Keith Donald, Colin Sampaleanu, Rob Harrop, Thomas Risberg,... Spring Framework Reference Documentation 4.1.4.RELEASE
68 PHỤ LỤC 1: HƯỚNG DẪN TRIỂN KHAI ỨNG DỤNG Chúng ta cần phải cài đặt và cấu hình tất cả các thành phần như: JDK, Maven, MongoDB, Tomcat và ActiveMQ trước khi có thể chạy được ứng dụng. Bước 1: Cài đặt JDK 1.7 (hoặc cao hơn, trong hướng dẫn này chúng tôi sử dụng JDK 1.8.0_20) Sau khi cài đặt JDK thành công cần kiểm tra biến môi trường JAVA_HOME; nếu như JAVA_HOME chưa có chúng ta thêm vào, hãy chắc chắn JAVA_HOME được thiết lập giống như hình trước khi thực hiện bước tiếp theo. Bước 2: Cài đặt Maven 3.2.5 Tải file apache-maven-3.2.5-bin.zip từ http://maven.apache.org/download.cgi. Giải nén file vừa tải về vào thư mục D:DevApp (có thể chọn thư mục khác). Sau khi giải nén thành công ta được kết quả như hình. Thêm mới biến môi trường M2_HOME:
69 Thêm JAVA_HOME và M2_HOME vào biến môi trường Path: Mở Command Prompt và gõ: mvn –version, nếu kết quả như hình dưới đây là chúng ta đã cài đặt thành công Maven Bước 3: MongoDB 2.6 Tải MongoDB từ http://www.mongodb.org/downloads. Có thể chọn file zip hoặc file MSI, trong hướng dẫn này chúng tôi chọn file zip. Lưu ý là cần chọn phiên bản 32bit hoặc 64bit phù hợp.
70 Giải nén file vừa tải về vào thư mục theo địa chỉ C:Program FilesMongoDB 2.6 Standard (có thể chọn thư mục khác). Sau khi giải nén thành công ta được kết quả như hình Tạo file config.txt trong thư mục E:MongoDB Tạo 2 thư mục data và log tại E:MongoDB. Sau khi thực hiện các bước trên chúng ta được như hình dưới đây: config.txt ##store data dbpath=E:MongoDBdata ##all output go here logpath=E:MongoDBlogmongo.log ##log read and write operations diaglog=3
71 Tiếp theo chúng ta cài đặt MongoDB như một Window Service. Tại thư mục C:Program FilesMongoDB 2.6 Standardbin mở Command Prompt và gõ lệnh: mongod --config E:MongoDBconfig.txt --install Sau khi cài đặt thành công kiểm tra services trong Window chúng ta được 1 services tên MongoDB Bước 4: Cài đặt TomCat 8.0.15 Tải TomCat từ https://tomcat.apache.org/download-80.cgi
72 Giải nén file vừa tải vào thư mục D:DevApp. Sau khi giải nén thành công ta được như hình Cấu hình https cho TomCat tham khảo tại http://java.dzone.com/articles/setting- ssl-tomcat-5-minutes (có thể bỏ qua bước này nếu không muốn sử dụng https) Bước 5: Cài đặt ActiveMQ 5.9.0 Tải ActiveMQ từ http://activemq.apache.org/activemq-590-release.html Giải nén file vừa tải vào thư mục D:DevApp. Sau khi giải nén thành công ta được như hình dưới
73 Bước 6: Lấy source code ứng dụng từ Github và biên dịch với Maven Tải source code từ https://github.com/thienan93/music-manager Giải nén file vừa tải về ta được như hình Biên dịch project MusicManagerShare trước. Mở command Prompt và cd về thư mục MusicManagerShare sau đó gõ lệnh mvn clean install Tương tự biên dịch cho project MusicManagerClient
74 Mở thư mục D:Bitbucketmusic-managerMusicManagerClienttarget copy file ROOT.war sang thư mục D:DevAppapache-tomcat-8.0.15webapps Tiếp theo chúng ta sẽ convert project MusicManagerServer thành eclipse project và import vào Eclipse IDE. Mở command Prompt và cd về thư mục MusicManagerServer sau đó gõ lệnh mvn eclipse:eclipse Mở Eclipse chọn File -> Import -> General -> Existing Project into Workspace. Browse đến thư mục chứa project MusicManagerServer và chọn Finish. Bước 7: Triển khai ứng dụng Start service MongoDB vừa cài đặt ở bước 3.
75 Start ActiveMQ. Vào đường dẫn D:DevAppapache-activemq-5.9.0binwin64 hoặc D:DevAppapache-activemq-5.9.0binwin32 nếu sử dụng hệ điều hành 32bit sau đó double click vào activemq.bat. Sau khi chạy file bat, mở trình duyệt và truy cập vào http://localhost:8161 nếu thành công chúng ta được như hình. Mở Eclipse và run project MusicManagerServer nếu thành công chúng ta được như hình dưới. Start TomCat. Vào đường dẫn D:DevAppapache-tomcat-8.0.15bin và double click vào startup.bat. Mở trình duyệt và truy cập vào https://localhost:8443 hoặc http://localhost:8080. Đăng nhập với các tài khoản: - Role admin: nthienan - 123456
76 - Role user: ltduoc – 123456
77 PHỤ LỤC 2: GIỚI THIỆU MAVEN Maven là công cụ quản lý và thiết lập tự động một dự án phần mềm. Chủ yếu dùng cho các lập trình viên Java, nhưng nó cũng có thể được dùng để xây dựng và quản lý các dự án dùng C#, Ruby, Scala hay ngôn ngữ khác. Maven phục vụ mục đích tương tự như Apache Ant, nhưng nó dựa trên khái niệm khác và cách hoạt động khác. Maven được quản lý bởi Apache Software Foundation, nó là một phần của dự án Jakarta Project. Maven dùng khái niệm Project Object Model (POM) để mô tả việc build project, các thành phần phụ thuộc (dependency) và các module. Nó định nghĩa trước các target cho việc khai báo task, trình biên dịch, đóng gói và thứ tự hoạt động để mọi việc diễn ra tốt nhất. Maven tải các thư viện, plug-in từ một hoặc nhiều repositories. Maven cung cấp việc hỗ trợ tải file từ repository trung tâm của Maven và các repositories khác. Cũng có thể upload các sản phẩm lên repository sau khi đã build xong. Maven được xây dựng dựa trên kiến trúc plugin - cho phép sử dụng bất kỳ ứng dụng điều khiển nào thông qua đầu vào tiêu chuẩn. Về mặt lý thuyết, điều này cho phép bất kỳ ai cũng có thể viết các plugin để giao tiếp với các build tool (trình biên dịch, unit test tool, etc) cho bất kỳ ngôn ngữ nào khác. Nhưng trong thực tế, hỗ trợ và sử dụng cho các ngôn ngữ khác đã bị thu hẹp. Hiện tại thì plugin cho .Net đã có và vẫn được duy trì, và một plugin cho C/C++ cũng được duy trì cho Maven. Một project Maven được cấu hình sử dụng Project Object Model, nó được lưu trong file pom.xml. Một file pom.xml được định nghĩa như dưới đây:
78 Lợi ích của Maven Quản lý các dependencies (các thư viện) trong project một các ưu việt. Tự động cập nhật, mở rộng dễ dàng, đóng gói các thư viện mà project sử dụng. Maven có một repository lớn chứa toàn bộ các thư viện cần thiết (http://mvnrepository.com), nó không pom.xml <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>agu.thesis2015</groupId> <artifactId>MusicManagerClient</artifactId> <packaging>war</packaging> <version>1.0-SNAPSHOT</version> <name>MusicManagerClient Maven Webapp</name> <url>http://maven.apache.org</url> <properties> <jdk.version>1.7</jdk.version> <spring.version>4.1.4.RELEASE</spring.version> </properties> <dependencies> <!-- spring core --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>${spring.version}</version> </dependency> <!-- shared --> <dependency> <groupId>agu.thesis2015</groupId> <artifactId>MusicManagerShared</artifactId> <version>1.0-SNAPSHOT</version> </dependency> </dependencies> <build> <finalName>ROOT</finalName> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.0</version> <configuration> <source>${jdk.version}</source> <target>${jdk.version}</target> </configuration> </plugin> </plugins> </build> </project>
79 chỉ lưu trữ gói mà còn lưu cả version, các version này được cập nhật liên tực bởi người phát triển ra nó. Chính vì thế khi cần thay đổi version thì rất nhanh chóng. Tự động hóa toàn bộ quá trình release project. Một dự án bao gồm các quá trình như khởi tạo, cập nhật thư viện, build & test, release và tạo tài liệu mô tả. Hãy thử tưởng tượng về một dự án lớn, trong đó các hàng chục các module làm các công việc khác nhau. Mỗi team phụ trách một module và quá trình phát triển các module: từ phân tích yêu cầu, đặc tả, đến phát triển, kiểm thử và release là đồng thời và độc lập. Nhưng các module này phụ thuộc vào nhau, cần thiết cho nhau để phát triển. Chỉ cần một sự chậm trễ, sai lầm ở một công đoạn có thể làm đổ vỡ cả quá trình release của project. Cho nên việc tự động hóa toàn bộ là ưu tiên hàng đầu, nhờ đó là việc lên kế hoạch hiệu quả và chính xác hơn, việc tích hợp và triển khai cũng đơn giản hơn rất nhiều. Tự động hóa quá trình test với các plugin. Toàn bộ quá trình test được tự động, từ đó các lỗi được phát hiện sớm hơn. Thậm chí lỗi có thể phát hiện ở giai đoạn phát triển, do các developer đều có thể chạy các test case một cách dễ dàng bằng Maven. Phân chia 1 project lớn thành các module nhỏ. Từ đó cho phép làm việc đồng thời trên các module khác nhau, đồng thời vẫn tạo được tính thống nhất. Không phụ thuộc vào IDE. Cho phép chuyển đổi tử Eclipse sang NetBeans,.. một cách dễ dàng. Maven hỗ trợ một số command để tạo ra project tương thích với IDE muốn sử dụng (ví dụ: mvn eclipse:eclipse – để tạo project với eclipse). Một số Maven command Maven hỗ trợ khá nhiều câu lệnh tùy vào mục đích sử dụng. Maven complie Lần đầu tiên thực thi command này, maven sẽ download toàn bộ các pluins và các dependencies liên quan. Nếu chúng ta thực thi lại lệnh này, maven sẽ không download lại những gì nó đã có từ lần trước, vậy nên command sẽ được thực thi nhanh hơn. Các D:nthienanmusic-manager-client>mvn compile [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building MusicManagerClient Maven Webapp 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] Nothing to compile - all classes are up to date [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1.738s [INFO] Finished at: 2015-03-17T22:20:37+07:00 [INFO] Final Memory: 6M/109M [INFO] ------------------------------------------------------------------------
80 class được compile sẽ được đưa vào ${basedir}/target/classes. Với maven vẫn còn vài lỗi phát sinh, nếu trong quá trình download các gói thư viện được định nghĩa trong pom.xml nhưng phát sinh lỗi do sự cố mạng hay một lỗi nào đó mà gói không được tải trọn vẹn, thì ở lần build sau khi maven tìm thấy gói trong repo trên máy lúc ấy maven sẽ dùng gói đó hỗ trợ build và việc build sẽ faild, trong trường hợp này cần phải tìm đến gói đó và xóa nó đi, thực hiện build lại nếu trong quá trình download lại gói đó không phát sinh lỗi thì build sẽ thành công. Maven package Được dùng khi muốn export project ra 1 gói jar để cho người khác sử dụng. Được định nghĩa trong pom.xml, nếu được định nghĩa jar thì khi export ra gói .jar, nếu không mặc định là .war (web app) Maven install Với command “mvn package” gói jar chỉ được export ra ${basedir}/target, nếu muốn gói jar ấy được đưa lên repo và các project các có thể dependency tới thì cần sử dụng lệnh “mvn install”. D:nthienanmusic-manager-client>mvn package [INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [INFO] Building MusicManagerClient Maven Webapp 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] --- maven-war-plugin:2.2:war (default-war) @ MusicManagerClient --- [INFO] Packaging webapp [INFO] Assembling webapp [MusicManagerClient] in [ D:nthienanmusic-manager- clienttargetROOT] [INFO] Processing war project [INFO] Copying webapp resources [ D:nthienanmusic-manager- clientsrcmainwebapp] [INFO] Webapp assembled in [1062 msecs] [INFO] Building war: D:nthienanmusic-manager-clienttargetROOT.war [INFO] WEB-INFweb.xml already added, skipping [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 17.687 s [INFO] Finished at: 2015-03-17T22:29:42+07:00 [INFO] Final Memory: 24M/269M [INFO] ------------------------------------------------------------------------
81 D:nthienanmusic-manager-client>mvn install [INFO] Scanning for projects... [INFO] --- maven-install-plugin:2.4:install (default-install) @ MusicManagerClient --- [INFO] Installing D:nthienanmusic-manager-clienttargetROOT.war to C:Usersntan.m2repositoryaguthesis2015MusicManagerClient1 .0-SNAPSHOTMusicManagerClient-1.0-SNAPSHOT.war [INFO] Installing D:nthienanmusic-manager-clientpom.xml to C:Usersntan.m2repositoryaguthesis2015MusicManagerClient1.0-SNAPS HOTMusicManagerClient-1.0-SNAPSHOT.pom [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 44.982 s [INFO] Finished at: 2015-03-17T22:41:14+07:00 [INFO] Final Memory: 24M/252M [INFO] ------------------------------------------------------------------------

More Related Content

PDF
Tìm hiểu FRAMEWORK VUEJS, JAVA SPRING và xây dựng Website xem phim online.pdf
Man_Ebook
 
PDF
Nhập môn công nghệ phần mềm
Trần Gia Bảo
 
DOC
Luận Văn Công Nghệ Thông Tin Tìm Hiểu Về Flutter Và Ứng Dụng.doc
sividocz
 
PDF
Bài giảng công nghệ phần mềm PTIT
NguynMinh294
 
PDF
NGHIÊN CỨU XÂY DỰNG ỨNG DỤNG CHO HỆ ĐIỀU HÀNH iOS
Vàng Cao Thanh
 
PPTX
01.1-Quy trinh phat trien phan mem.pptx
TunTrung15
 
PDF
Tìm hiểu framework Spring cho Backend, Reactjs cho frontend và xây dựng websi...
Man_Ebook
 
PDF
Báo Cáo Đề Tài Xây Dựng Phần Mềm Quản Lí Khách Hàng Trên Android
Dlinh Truong
 
Tìm hiểu FRAMEWORK VUEJS, JAVA SPRING và xây dựng Website xem phim online.pdf
Man_Ebook
 
Nhập môn công nghệ phần mềm
Trần Gia Bảo
 
Luận Văn Công Nghệ Thông Tin Tìm Hiểu Về Flutter Và Ứng Dụng.doc
sividocz
 
Bài giảng công nghệ phần mềm PTIT
NguynMinh294
 
NGHIÊN CỨU XÂY DỰNG ỨNG DỤNG CHO HỆ ĐIỀU HÀNH iOS
Vàng Cao Thanh
 
01.1-Quy trinh phat trien phan mem.pptx
TunTrung15
 
Tìm hiểu framework Spring cho Backend, Reactjs cho frontend và xây dựng websi...
Man_Ebook
 
Báo Cáo Đề Tài Xây Dựng Phần Mềm Quản Lí Khách Hàng Trên Android
Dlinh Truong
 

What's hot (20)

PDF
Phân tích thiết kế hệ thống thông tin PTIT
NguynMinh294
 
PPTX
Spring framework
An Nguyen
 
PDF
Báo cáo đồ án tôt nghiệp: Xây dựng Website bán hàng thông minh
nataliej4
 
PDF
Giáo trình phân tích thiết kế hệ thống thông tin
Võ Phúc
 
DOC
Xây dựng biểu đồ use case
Trung Chinh Hà
 
PDF
Phân tích thiết kế hệ thống của hàng bán điện thoại di động
Nguyễn Danh Thanh
 
PDF
Cơ sở dữ liệu PTIT slide 2
NguynMinh294
 
PDF
Đồ án trang web bán văn phòng phẩm
NguynMinh294
 
PDF
Đề tài: Xây dựng phần mềm quản lý quán cà phê, HOT, 9đ
Dịch vụ viết bài trọn gói ZALO 0917193864
 
DOC
PHÂN TÍCH THIẾT KẾ HỆ THỐNG BÁN HÀNG QUA MẠNG
Thùy Linh
 
PDF
Đề tài: Tìm hiểu giải pháp an ninh mạng với firewall, HAY, 9đ
Dịch vụ viết bài trọn gói ZALO 0917193864
 
DOCX
BÁO CÁO CÔNG NGHỆ PHẦN MỀM 8 điểm-QUẢN LÝ CỬA HÀNG BÁN MÁY ẢNH
Hoà Đoàn
 
PDF
Đề tài: Xây dựng website giới thiệu cho sản phẩm phần mềm, 9đ
Dịch vụ viết bài trọn gói ZALO 0917193864
 
PDF
Đề Tài Thiết Kế Phần Mềm Quản Lý Sinh Viên
nataliej4
 
DOCX
Báo Cáo Đồ Án 2 : Thiết Kế Web Bán Đồng Hồ
zDollz Lovez
 
PDF
Đề tài: Xây dựng phần mềm quản lý nhà hàng ăn uống
Dịch Vụ Viết Thuê Khóa Luận Zalo/Telegram 0917193864
 
PPTX
Chuong 6
Ảo Ảo
 
PDF
Bài 7: Thiết kế cơ sở dữ liệu vật lý
MasterCode.vn
 
PDF
Đề tài: Kiểm thử phần mềm trên thiết bị di động, HAY, 9đ
Dịch Vụ Viết Bài Trọn Gói ZALO 0917193864
 
DOCX
Báo cáo đồ án môn công nghệ phần mềm
RiTa15
 
Phân tích thiết kế hệ thống thông tin PTIT
NguynMinh294
 
Spring framework
An Nguyen
 
Báo cáo đồ án tôt nghiệp: Xây dựng Website bán hàng thông minh
nataliej4
 
Giáo trình phân tích thiết kế hệ thống thông tin
Võ Phúc
 
Xây dựng biểu đồ use case
Trung Chinh Hà
 
Phân tích thiết kế hệ thống của hàng bán điện thoại di động
Nguyễn Danh Thanh
 
Cơ sở dữ liệu PTIT slide 2
NguynMinh294
 
Đồ án trang web bán văn phòng phẩm
NguynMinh294
 
Đề tài: Xây dựng phần mềm quản lý quán cà phê, HOT, 9đ
Dịch vụ viết bài trọn gói ZALO 0917193864
 
PHÂN TÍCH THIẾT KẾ HỆ THỐNG BÁN HÀNG QUA MẠNG
Thùy Linh
 
Đề tài: Tìm hiểu giải pháp an ninh mạng với firewall, HAY, 9đ
Dịch vụ viết bài trọn gói ZALO 0917193864
 
BÁO CÁO CÔNG NGHỆ PHẦN MỀM 8 điểm-QUẢN LÝ CỬA HÀNG BÁN MÁY ẢNH
Hoà Đoàn
 
Đề tài: Xây dựng website giới thiệu cho sản phẩm phần mềm, 9đ
Dịch vụ viết bài trọn gói ZALO 0917193864
 
Đề Tài Thiết Kế Phần Mềm Quản Lý Sinh Viên
nataliej4
 
Báo Cáo Đồ Án 2 : Thiết Kế Web Bán Đồng Hồ
zDollz Lovez
 
Đề tài: Xây dựng phần mềm quản lý nhà hàng ăn uống
Dịch Vụ Viết Thuê Khóa Luận Zalo/Telegram 0917193864
 
Chuong 6
Ảo Ảo
 
Bài 7: Thiết kế cơ sở dữ liệu vật lý
MasterCode.vn
 
Đề tài: Kiểm thử phần mềm trên thiết bị di động, HAY, 9đ
Dịch Vụ Viết Bài Trọn Gói ZALO 0917193864
 
Báo cáo đồ án môn công nghệ phần mềm
RiTa15
 
Ad

Viewers also liked (13)

PDF
Live chym kysubrse vs toidicodedao
Huy Hoàng Phạm
 
PDF
Intro to Retrofit 2 and RxJava2
Fabio Collini
 
PPTX
Spring mvc
nagarajupatangay
 
PDF
Reactive Streams and RxJava2
Yakov Fain
 
PDF
Từ Gà Đến Pro Git và GitHub trong 60 phút
Huy Hoàng Phạm
 
PDF
Spring mvc
Ba Big
 
PPT
Lap trinh java hieu qua
Lê Anh
 
PPTX
Sinh viên IT học và làm gì để không thất nghiệp
Huy Hoàng Phạm
 
PPTX
Hành trình trở thành web đì ve lốp pơ
Huy Hoàng Phạm
 
PDF
Từ Sinh Viên IT tới Lập Trình Viên
Huy Hoàng Phạm
 
PPTX
Effective Java
Brice Argenson
 
PDF
Effective java
Haeil Yi
 
PPTX
Effective java
Emprovise
 
Live chym kysubrse vs toidicodedao
Huy Hoàng Phạm
 
Intro to Retrofit 2 and RxJava2
Fabio Collini
 
Spring mvc
nagarajupatangay
 
Reactive Streams and RxJava2
Yakov Fain
 
Từ Gà Đến Pro Git và GitHub trong 60 phút
Huy Hoàng Phạm
 
Spring mvc
Ba Big
 
Lap trinh java hieu qua
Lê Anh
 
Sinh viên IT học và làm gì để không thất nghiệp
Huy Hoàng Phạm
 
Hành trình trở thành web đì ve lốp pơ
Huy Hoàng Phạm
 
Từ Sinh Viên IT tới Lập Trình Viên
Huy Hoàng Phạm
 
Effective Java
Brice Argenson
 
Effective java
Haeil Yi
 
Effective java
Emprovise
 
Ad

Similar to Luận văn tìm hiểu Spring (20)

PDF
Kiểm chứng các chương trình phần mềm hướng khía cạnh, HAY
Dịch vụ viết bài trọn gói ZALO: 0909232620
 
DOC
Phát triển phần mềm quản lý quan hệ khách hàng (CRM) cho Công ty TNHH Phần mề...
lamluanvan.net Viết thuê luận văn
 
PDF
Kỹ thuật mô hình hóa luồng tương tác IFML trong ứng dụng di động
Dịch vụ viết bài trọn gói ZALO 0917193864
 
PDF
Báo cáo thực tập công nghệ thông tin.
ssuser499fca
 
PDF
Luận văn: Ứng dụng giám sát hành trình trên điện thoại, HAY
Dịch vụ viết bài trọn gói ZALO 0917193864
 
DOC
Báo cáo thực tập Khoa Kỹ thuật phần mềm Trường Đại học An Giang.doc
Dịch vụ viết thuê đề tài trọn gói ☎☎☎ Liên hệ ZALO/TELE: 0973.287.149 👍👍
 
DOC
Phân Tích Thiết Kế Hệ Thống Hướng Cấu Trúc Và Hệ Quản Trị CSDL SQL Server 20...
mokoboo56
 
PDF
Luận văn: Xây dựng hệ thống phần mềm giảng dạy kịch hát dân tộc
Dịch vụ viết bài trọn gói ZALO 0917193864
 
DOC
Luận văn Thạc sĩ Phát triển hệ thống quản lý tài liệu điện tử trong doanh ngh...
Dịch vụ viết thuê Luận Văn - ZALO 0932091562
 
PDF
Tính cận trên bộ nhớ Log của chương trình sử dụng giao dịch, 9đ
Dịch Vụ Viết Bài Trọn Gói ZALO 0917193864
 
PDF
Luận văn: Phát triển phần mềm áp dụng các phương pháp SCRUM và EXTREME PROGRA...
Dịch Vụ Viết Thuê Khóa Luận Zalo/Telegram 0917193864
 
PDF
Luận văn: Nghiên cứu và ứng dụng mẫu thiết kế trong phương pháp hướng đối tượng
Dịch Vụ Viết Thuê Khóa Luận Zalo/Telegram 0917193864
 
PDF
Nhom2_20232IT6096005_BM03_Quyen_TKPM.pdf
NguyenVitAnh3
 
PDF
Nhom2_20232IT6096005_BM03_Quyen_TKPM.pdf
NguyenVitAnh3
 
DOCX
Đồ án kiểm thử phần mềm
Nguyễn Anh
 
PDF
Báo cáo thực tập công nghệ thông tin.
ssuser499fca
 
PDF
Quy trình quản lý chất lượng phần mềm của công ty phần mềm, 9đ
Dịch vụ viết bài trọn gói ZALO 0917193864
 
PDF
Luận văn: Mô hình hóa luồng tương tác ifml trong phát triển di động
Dịch Vụ Viết Bài Trọn Gói ZALO 0917193864
 
PDF
Đề tài: Quản lý thu tiền sử dụng Internet, HAY, 9đ
Dịch vụ viết bài trọn gói ZALO 0917193864
 
PPTX
DesignPattern-C4-CD4.3-CacXuHuongMoiTrongThietKeHuongDoiTuong.pptx
quytcam11042005
 
Kiểm chứng các chương trình phần mềm hướng khía cạnh, HAY
Dịch vụ viết bài trọn gói ZALO: 0909232620
 
Phát triển phần mềm quản lý quan hệ khách hàng (CRM) cho Công ty TNHH Phần mề...
lamluanvan.net Viết thuê luận văn
 
Kỹ thuật mô hình hóa luồng tương tác IFML trong ứng dụng di động
Dịch vụ viết bài trọn gói ZALO 0917193864
 
Báo cáo thực tập công nghệ thông tin.
ssuser499fca
 
Luận văn: Ứng dụng giám sát hành trình trên điện thoại, HAY
Dịch vụ viết bài trọn gói ZALO 0917193864
 
Báo cáo thực tập Khoa Kỹ thuật phần mềm Trường Đại học An Giang.doc
Dịch vụ viết thuê đề tài trọn gói ☎☎☎ Liên hệ ZALO/TELE: 0973.287.149 👍👍
 
Phân Tích Thiết Kế Hệ Thống Hướng Cấu Trúc Và Hệ Quản Trị CSDL SQL Server 20...
mokoboo56
 
Luận văn: Xây dựng hệ thống phần mềm giảng dạy kịch hát dân tộc
Dịch vụ viết bài trọn gói ZALO 0917193864
 
Luận văn Thạc sĩ Phát triển hệ thống quản lý tài liệu điện tử trong doanh ngh...
Dịch vụ viết thuê Luận Văn - ZALO 0932091562
 
Tính cận trên bộ nhớ Log của chương trình sử dụng giao dịch, 9đ
Dịch Vụ Viết Bài Trọn Gói ZALO 0917193864
 
Luận văn: Phát triển phần mềm áp dụng các phương pháp SCRUM và EXTREME PROGRA...
Dịch Vụ Viết Thuê Khóa Luận Zalo/Telegram 0917193864
 
Luận văn: Nghiên cứu và ứng dụng mẫu thiết kế trong phương pháp hướng đối tượng
Dịch Vụ Viết Thuê Khóa Luận Zalo/Telegram 0917193864
 
Nhom2_20232IT6096005_BM03_Quyen_TKPM.pdf
NguyenVitAnh3
 
Nhom2_20232IT6096005_BM03_Quyen_TKPM.pdf
NguyenVitAnh3
 
Đồ án kiểm thử phần mềm
Nguyễn Anh
 
Báo cáo thực tập công nghệ thông tin.
ssuser499fca
 
Quy trình quản lý chất lượng phần mềm của công ty phần mềm, 9đ
Dịch vụ viết bài trọn gói ZALO 0917193864
 
Luận văn: Mô hình hóa luồng tương tác ifml trong phát triển di động
Dịch Vụ Viết Bài Trọn Gói ZALO 0917193864
 
Đề tài: Quản lý thu tiền sử dụng Internet, HAY, 9đ
Dịch vụ viết bài trọn gói ZALO 0917193864
 
DesignPattern-C4-CD4.3-CacXuHuongMoiTrongThietKeHuongDoiTuong.pptx
quytcam11042005
 

More from An Nguyen (16)

PPTX
Terraform
An Nguyen
 
PPTX
Introduce to Git and Jenkins
An Nguyen
 
PPTX
CI/CD Overview
An Nguyen
 
PPTX
Introduce to Credstash
An Nguyen
 
PPTX
Introduction To AWS & AWS Lambda
An Nguyen
 
PPTX
Introduction To Docker, Docker Compose, Docker Swarm
An Nguyen
 
PPTX
Secret Management with Hashicorp Vault and Consul on Kubernetes
An Nguyen
 
PDF
Terminal Services and VPN
An Nguyen
 
PPTX
Tân sinh viên TECH - AGU 2014
An Nguyen
 
PDF
Quy tắc thiết kế giao diện và viết code C#
An Nguyen
 
PPTX
Nêu cao tinh thần trách nhiệm, chống chủ nghĩa cá nhân, nói đi đôi với làm
An Nguyen
 
PDF
Hướng dẫn lập trình quản lý c#
An Nguyen
 
PDF
Quản lý quan hệ khách hàng
An Nguyen
 
PPTX
Quản lý quan hệ khách hàng
An Nguyen
 
PDF
RichTetxtBox control
An Nguyen
 
PDF
Hội nghị học tốt CNTT 2013 - An Giang University
An Nguyen
 
Terraform
An Nguyen
 
Introduce to Git and Jenkins
An Nguyen
 
CI/CD Overview
An Nguyen
 
Introduce to Credstash
An Nguyen
 
Introduction To AWS & AWS Lambda
An Nguyen
 
Introduction To Docker, Docker Compose, Docker Swarm
An Nguyen
 
Secret Management with Hashicorp Vault and Consul on Kubernetes
An Nguyen
 
Terminal Services and VPN
An Nguyen
 
Tân sinh viên TECH - AGU 2014
An Nguyen
 
Quy tắc thiết kế giao diện và viết code C#
An Nguyen
 
Nêu cao tinh thần trách nhiệm, chống chủ nghĩa cá nhân, nói đi đôi với làm
An Nguyen
 
Hướng dẫn lập trình quản lý c#
An Nguyen
 
Quản lý quan hệ khách hàng
An Nguyen
 
Quản lý quan hệ khách hàng
An Nguyen
 
RichTetxtBox control
An Nguyen
 
Hội nghị học tốt CNTT 2013 - An Giang University
An Nguyen
 

Luận văn tìm hiểu Spring

  • 1. TRƯỜNG ĐẠI HỌC AN GIANG KHOA KỸ THUẬT - CÔNG NGHỆ - MÔI TRƯỜNG NGUYỄN THIỆN AN – DTH114081 KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC NGÀNH CÔNG NGHỆ THÔNG TIN TÌM HIỂU FRAMEWORK SPRING VÀ XÂY DỰNG ỨNG DỤNG QUẢN LÝ NHẠC PHÍA CLIENT AN GIANG – 05/2015
  • 2. TRƯỜNG ĐẠI HỌC AN GIANG KHOA KỸ THUẬT - CÔNG NGHỆ - MÔI TRƯỜNG NGUYỄN THIỆN AN – DTH114081 KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC NGÀNH CÔNG NGHỆ THÔNG TIN TÌM HIỂU FRAMEWORK SPRING VÀ XÂY DỰNG ỨNG DỤNG QUẢN LÝ NHẠC PHÍA CLIENT Giảng viên hướng dẫn Thạc sĩ Huỳnh Lý Thanh Nhàn AN GIANG – 05/2015
  • 3. iii LỜI CẢM ƠN Trước hết tôi xin tỏ lòng biết ơn sâu sắc đến Thạc sĩ Huỳnh Lý Thanh Nhàn, thầy đã tận tình hướng dẫn, giúp đỡ tôi rất nhiều trong suốt quá trình thực hiện luận văn này. Sự hiểu biết sâu sắc về khoa học cũng như kinh nghiệm của thầy chính là tiền đề giúp tôi hoàn thành luận văn. Tôi cũng xin chân thành cảm ơn Tiến sĩ Nguyễn Văn Hòa, thầy đã hướng dẫn và chỉ ra con đường tốt để tôi có thể được làm luận văn tại TMA và đồng thời học hỏi kinh nghiệm thực tế từ dự án đang hoạt động. Giúp tôi không còn bở ngỡ và lo lắng sau khi ra trường. Tôi chân thành cảm ơn quý thầy, cô Khoa Kỹ thuật – Công nghệ - Môi trường, Trường Đại học An Giang đã tận tình truyền đạt kiến thức trong bốn năm học tập. Với vốn kiến thức được tiếp thu trong quá trình học không chỉ là nền tảng cho quá trình nghiên cứu khóa luận mà còn là hành trang để tôi bước vào đời một cách vững chắc và tự tin. Tôi chân thành cảm ơn chị Nguyễn Ngọc Tuyền – giám đốc DC4 và anh Nguyễn Hải Âu – senior manager của TMA đã cho phép và tạo điều kiện thuận lợi để tôi được làm luận văn tại công ty. Đồng thời tôi xin gởi lời cảm ơn chân thành đến anh Nguyễn Hoàng Diệu là người đã giúp đỡ tôi rất nhiều về mặt kỹ thuật trong suốt thời gian tại TMA. Tôi cũng xin gửi lời cảm ơn đến các bạn lớp DH12TH đã chia sẽ và giúp đỡ tôi trong quá trình học tập tại Đại học An Giang. Đặc biệt tôi xin cảm ơn bạn Lê Thành Được đã cùng tôi nghiên cứu, làm việc nhóm trong suốt quá trình thực hiện luận văn. Cuối cùng, tôi xin cảm ơn chân thành với lòng biết ơn sâu sắc đến ba mẹ, chị hai và gia đình đã nuôi dưỡng và dạy bảo tôi nên người và tạo cho tôi có điều kiện tốt để được học tập và phát triển. Với vốn kiến thức hạn hẹp và thời gian thực hiện có hạn nên không tránh khỏi những thiếu sót. Rất mong nhận được những ý kiến đóng góp của quý thầy cô và anh chị trong TMA, đó sẽ là hành trang quý giá giúp tôi hoàn thiện kiến thức của mình sau này. Xin chân thành cảm ơn! An Giang, ngày 20 tháng 05 năm 2015 Sinh viên thực hiện Nguyễn Thiện An
  • 4. iv NHẬN XÉT CỦA GIẢNG VIÊN HƯỚNG DẪN ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... ........................................................................................................................................... Giảng viên hướng dẫn (Ký và ghi rõ họ tên) Nội dung nhận xét: - Đồng ý hay không đồng ý cho sinh viên báo cáo TTCK; Nếu không đồng ý cần ghi rõ lý do. - Kết quả đạt được so với yêu cầu. - Ý kiến khác (nếu có).
  • 5. v TÓM TẮT Ngày nay tỷ lệ các dự án phần mềm thất bại hoặc không đáp ứng được các yêu cầu ban đầu là rất cao với hơn 83,8%. Bên cạnh đó chi phí cho việc bảo trì và mở rộng hệ thống luôn lớn hơn nhiều lần so với các pha khác trong quy trình phát triển một hệ thống. Một trong những nguyên nhân cơ bản nhất khiến các dự án thất bại là do các thành phần quá phụ thuộc lẫn nhau, chồng chéo, không có tính sử dụng lại. Vì vậy trong quy trình phát triển phần mềm hiện đại, xây dựng và phát triển một hệ thống bao giờ cũng đặt việc tạo ra các thành phần riêng rẽ độc lập, có sự phân biệt rõ ràng về trách nhiệm, có tính sử dụng lại cao lên làm ưu tiên hàng đầu. Tuy nhiên, điều này là không dễ dàng bởi tính độc lập của các thành phần sẽ bị giảm đi do cách mà chúng liên kết với nhau. Luận văn này sẽ tập trung tìm hiểu và giới thiệu sơ lược về Spring, những đặc tính vượt trội, ưu việt của nó trong việc tạo ra các ứng dụng đòi hỏi sự module hóa và có khả năng sử dụng lại cao. Đồng thời trình bày thêm về một số công nghệ như JMS, MongoDB, AngularJS, Bootstrap hiện đang được các công ty phần mềm sử dụng để cùng với Spring tạo nên một ứng dụng web enterprise. Sau khi tìm hiểu chúng tôi sẽ vận dụng kết quả tìm hiểu được vào việc xây dựng một ứng dụng nhằm mục đích minh họa cho phần lý thuyết đã trình bày. Chúng tôi sẽ xây dựng một ứng dụng quản lý nhạc trên nền web. Ứng dụng sẽ được thiết kế thành hai module chính là module client và module server. Trong luận văn này chúng tôi sẽ trình bày chi tiết phần thiết kế và xây dựng module client. Module server sẽ được đề cập trong luận văn của bạn Lê Thành Được.
  • 6. vi ABSTRACT Nowadays, the percentage of software project fails or does not meets the original requirements which are very high with more than 83.3%. Besides, the cost for maintaining and expanding the system is much bigger than another phases of the process of developing a system. One of the most basic reasons for project failure is due to components that is too interdependent, overlapping and non-reusable. Therefore, in the process of modern software development, building and developing a system that always put the creative independent separating components, there is a clear distinction of responsibility, taking into using again high up as top priority. However, this is not easy because the independence of the components will be reduced by the way that it link together. These thesis will focus on understanding and briefing introduction about Spring framework, superior properties, outstanding features in creative application that requires modularizing and capacity of reusing high. Beside that, further description of some technologies such as JMS, MongoDB, AngularJS and Bootstrap which are currently software companies use to create a web application enterprise with Spring framework. After studying, we are going to use the result of the studying to build an application. It aims to illustrate the theoretical part presented. We are going to build a Music Manager application on the web. Application is going to be designed in two main modules: client module and server module. In this thesis we will present about details of the designing and building client module. Server module is going to be discussed in thesis of Le Thanh Duoc.
  • 7. vii MỤC LỤC LỜI CẢM ƠN ........................................................................................................ iii NHẬN XÉT CỦA GIẢNG VIÊN HƯỚNG DẪN ................................................iv TÓM TẮT ................................................................................................................v ABSTRACT............................................................................................................vi MỤC LỤC............................................................................................................. vii DANH MỤC HÌNH................................................................................................ix DANH MỤC BẢNG...............................................................................................xi DANH SÁCH TỪ VIẾT TẮT.............................................................................. xii Chương 1 TỔNG QUAN ..................................................................................1 1.1 LÝ DO CHỌN ĐỀ TÀI............................................................................1 1.2 ĐẶT VẤN ĐỀ VÀ HƯỚNG GIẢI QUYẾT...........................................2 1.3 PHẠM VI ĐỀ TÀI....................................................................................3 1.4 PHƯƠNG PHÁP NGHIÊN CỨU............................................................4 1.5 BỐ CỤC LUẬN VĂN..............................................................................4 Chương 2 CƠ SỞ LÝ THUYẾT.......................................................................5 2.1 NGÔN NGỮ LẬP TRÌNH JAVA............................................................5 2.1.1 Java và lịch sử phát triển..................................................................5 2.1.2 Java Reflection .................................................................................5 2.2 SPRING FRAMEWORK.........................................................................9 2.2.1 Tổng quan về Spring ........................................................................9 2.2.2 Lịch sử phát triển..............................................................................9 2.2.3 Một số khái niệm chính..................................................................10 2.2.4 Các module.....................................................................................14 2.2.5 Spring Core.....................................................................................15 2.2.6 Spring MVC ...................................................................................27 2.2.7 Spring Security...............................................................................34 2.3 JAVA MESSAGE SYSTEM (JMS) ......................................................37 2.3.1 Hệ thống gửi nhận thông điệp (messaging system).......................37 2.3.2 Tổng quan về JMS..........................................................................38 2.3.3 Các mô hình gửi nhận thông điệp trong JMS................................39 2.4 ANGULARJS .........................................................................................41 2.4.1 Tổng quan về AngularJS................................................................41 2.4.2 Các đặc trưng của AngularJS.........................................................42
  • 8. viii 2.5 MONGODB............................................................................................46 2.5.1 Tổng quan về NoSQL ....................................................................46 2.5.2 MongoDB .......................................................................................48 2.6 BOOTSTRAP VÀ RESPONSIVE.........................................................49 Chương 3 THIẾT KẾ VÀ CÀI ĐẶT CHƯƠNG TRÌNH..............................50 3.1 MÔ HÌNH ỨNG DỤNG ........................................................................50 3.2 THIẾT KẾ MESSAGE...........................................................................53 3.3 THIẾT KẾ CƠ SỞ DỮ LIỆU.................................................................54 3.4 RESTful API...........................................................................................56 3.5 CƠ CHẾ BẢO MẬT ỨNG DỤNG........................................................57 3.6 SƠ ĐỒ USECASE..................................................................................57 3.7 GIAO DIỆN VÀ CHỨC NĂNG............................................................60 3.7.1 Một số giao diện chính...................................................................60 3.7.2 Một số chức năng nổi bật của ứng dụng........................................64 Chương 4 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN.....................................66 4.1 KẾT QUẢ ĐẠT ĐƯỢC.........................................................................66 4.2 HẠN CHẾ...............................................................................................66 4.3 HƯỚNG PHÁT TRIỂN .........................................................................66 TÀI LIỆU THAM KHẢO .....................................................................................67 PHỤ LỤC 1: HƯỚNG DẪN TRIỂN KHAI ỨNG DỤNG..................................68 PHỤ LỤC 2: GIỚI THIỆU MAVEN....................................................................77
  • 9. ix DANH MỤC HÌNH Hình 1.1: Chi phí cho các pha phát triển một hệ thống...........................................1 Hình 2.1: Kiến trúc tổng quát Java Reflaction API.................................................6 Hình 2.2: Luồng điều khiển của chương trình bình thường..................................11 Hình 2.3: Servlet Container ...................................................................................12 Hình 2.4: Kiểm thử đơn vị với JUnit.....................................................................12 Hình 2.5: Mô hình ứng dụng áp dụng IoC ............................................................13 Hình 2.6: Các module của Spring framework.......................................................14 Hình 2.7: Singleton scope......................................................................................18 Hình 2.8: Prototype scope......................................................................................19 Hình 2.9: Spring IoC Container.............................................................................20 Hình 2.10: Kiến trúc module Spring MVC ...........................................................27 Hình 2.11: Sơ đồ luồng xử lý của Spring MVC....................................................28 Hình 2.12: Luồng xử lý một request trong Spring MVC......................................29 Hình 2.13: Mô hình hệ thống gửi nhận thông điệp...............................................37 Hình 2.14: Mô hình tổng quát JMS .......................................................................39 Hình 2.15: Hai mô hình gửi nhận message trong JMS .........................................40 Hình 2.16: Mô hình point - to - point ....................................................................40 Hình 2.17: Mô hình publish - subscribe ................................................................41 Hình 2.18: Single Page Application ......................................................................42 Hình 2.19: Kiến trúc MVC trong AngularJS.........................................................43 Hình 2.20: One-way binding và Two-way binding...............................................43 Hình 3.1: Mô hình ứng dụng .................................................................................50 Hình 3.2: Mô hình chi tiết của ứng dụng...............................................................51 Hình 3.3: Luồng thực thi của ứng dụng.................................................................52 Hình 3.4: Module client .........................................................................................53 Hình 3.5: Sơ đồ class Message ..............................................................................54 Hình 3.6: Document trong giao diện RoboMongo................................................55 Hình 3.7: RESTful API về bài hát.........................................................................56 Hình 3.8: RESTful API về user .............................................................................56 Hình 3.9: Cơ chế bảo mật ứng dụng......................................................................57 Hình 3.10: Sơ đồ use case của actor user ..............................................................58 Hình 3.11: Sơ đồ use case của actor Role_User....................................................59 Hình 3.12: Sơ đồ use case của actor Role_Admin ................................................59 Hình 3.13: Giao diện đăng ký người dùng............................................................60 Hình 3.14: Giao diện đăng nhập............................................................................60 Hình 3.15: Giao diện play nhạc .............................................................................61 Hình 3.16: Giao diện bài hát được chia sẻ.............................................................61 Hình 3.17: Giao diện danh sách bài hát.................................................................61 Hình 3.18: Giao diện tìm kiếm bài hát ..................................................................62 Hình 3.19: Giao diện sửa thông tin bài hát............................................................62 Hình 3.20: Giao diện sửa thông tin user................................................................62 Hình 3.21: Giao diện quản lý user.........................................................................63 Hình 3.22: Giao diện thống kê các thông tin.........................................................63 Hình 3.23: Giao diện đổi password .......................................................................63
  • 10. x Hình 3.24: Giao diện sửa thông tin user của admin..............................................64 Hình 3.25: Email kích hoạt tài khoản khi đăng ký thành công.............................64 Hình 3.26: Tài khoản trước và sau khi kích hoạt ..................................................64 Hình 3.27: Ứng dụng với ngôn ngữ Tiếng Việt ....................................................65 Hình 3.28: Ứng dụng với ngôn ngữ Tiếng Anh ....................................................65
  • 11. xi DANH MỤC BẢNG Bảng 2-1: Phạm vi của bean ..................................................................................17 Bảng 2-2: So sánh các thành phần giữa RDBMS và MongoDB ..........................48 Bảng 3-1: Danh sách các actor ..............................................................................57 Bảng 3-2: Danh sách các usecase..........................................................................57
  • 12. xii DANH SÁCH TỪ VIẾT TẮT AJAX Asynchronous JavaScript and XML AOP Aspect – oriented programming API Application programming interface CSDL Cở sở dữ liệu DAO Data Access Object DI Dependency Injection DOM Document Object Model EJB Enterprise Java Bean HTML HyperText Markup Language IoC Inversion of Control JSM Java Message System JVM Java Virtual Machine MOM Message - Oriented Middleware OOP Object – oriented programming ORM Object Relational Mapping POJO Plain Old Java Object RDBMS Relational database management system SPA Single page application URL Uniform Resource Locator
  • 13. 1 Chương 1 TỔNG QUAN 1.1 LÝ DO CHỌN ĐỀ TÀI Trong một khảo sát với khoảng 8.000 dự án phần mềm, Standish Group cho biết có chỉ có 16.2% dự án là hoàn thành đúng hạn và nằm trong giới hạn ngân sách, đáp ứng đầy đủ tất cả các tính năng như cam kết ban đầu. Và hơn 83.8% dự án thất bại hoặc không đáp ứng được những yêu cầu ban đầu, trong đó có tới 52.7% dự án được hoàn thành và đi vào hoạt động nhưng không hoàn thành đúng hạn và bội chi, thêm nữa không đáp ứng đầy đủ tính năng và đặt tính như thiết kế ban đầu. Bên cạnh đó chi phí cho việc bảo trì và mở rộng hệ thống luôn lớn hơn nhiều lần so với các pha khác trong quy trình phát triển một hệ thống. Những rủi ro dẫn đến hủy hoặc đình trệ của các dự án phần mềm tăng nhanh tỉ lệ thuận với việc gia tăng kích thước của dự án; 25% với các dự án > 100.000 LOC (line of code), 50% với các dự án > 500.000 LOC và 65% với các dự án > 1.000.000 LOC. Việc phát triển các hệ thống với hơn 5.000 function point (tương đương 500.000 LOC) được xem là một trong những nhiệm vụ rủi ro nhất. Một trong những nguyên nhân cơ bản nhất để các dự án thất bại là do các thành phần quá phụ thuộc lẫn nhau, chồng chéo, không có tính sử dụng lại. Vì vậy trong quy trình phát triển phần mềm hiện đại, xây dựng và phát triển một hệ thống bao giờ cũng đặt việc tạo ra các thành phần riêng rẽ độc lập, có sự phân biệt rõ ràng về trách nhiệm, có tính sử dụng lại cao lên làm ưu tiên hàng đầu. Bởi vì một khi đã tạo ra các thành phần như vậy, chúng ta sẽ tiết kiệm được rất nhiều thời gian và công sức trong quá trình bảo trì và mở rộng hệ thống sau này. Tuy nhiên, điều này quả là không dễ dàng bởi vì tính độc lập của các thành phần sẽ bị giảm đi do cách các thành phần liên kết với nhau. Mặt khác, ngày nay hầu hết các hệ thống đều được phát triển trên nền web bởi vì các ứng dụng web đem lại khả năng phát triển và triển khai sản phẩm nhanh chóng, giảm thời gian đưa sản phẩm ra thị trường, có khả năng cập nhật tính năng liên tục hàng ngày. 3 3 5 7 15 67 Xác định yêu cầu Đặt tả Thiết kế Lập trình Kiểm thử Bảo trì Hình 1.1: Chi phí cho các pha phát triển một hệ thống
  • 14. 2 Ứng dụng web có thời gian phát triển nhanh, với chi phí phát triển và triển khai thấp, tin cậy, có thể truy cập từ bất cứ đâu, mọi người có thể sử dụng mà không mất thời gian tìm hiểu nhờ giao diện trực quan. Hơn nữa công nghệ di động đang ngày càng trở nên phổ biến, trong những năm gần đây số lượng người sử dụng và truy cập qua các thiết bị di động tăng một cách nhanh chóng, xu hướng thiết kế và viết các ứng dụng thích hợp với các thiết bị di động đang trở thành một xu hướng tất yếu. Các hệ thống đã được phát triển để có thể sẵn sàng cho các trang web phù hợp với thiết bị di động và các ứng dụng trên thiết bị di động. Chính vì những lý do trên nên chúng tôi chọn đề tài “Tìm hiểu Framework Spring và xây dựng ứng dụng quản lý nhạc phía client”. Nội dung luận văn này sẽ tập trung tìm hiểu và giới thiệu về Spring, một framework với những đặc tính vượt trội và ưu việt trong việc tạo ra các hệ thống đòi hỏi sự module hóa và có khả năng sử dụng lại cao. Đồng thời tìm hiểu thêm một số framework và kỹ thuật khác hiện đang được các công ty phần mềm sử dụng để tích hợp với Spring tạo nên một ứng dụng web enterprise như: AngularJS, Bootstrap, JMS, MongoDB. 1.2 ĐẶT VẤN ĐỀ VÀ HƯỚNG GIẢI QUYẾT Mặc dù EJB được sử dụng rộng rãi, tuy nhiên nó có một số hạn chế như khả năng sử dụng lại code thấp tạo gánh nặng cho việc phát triển [1, tr1]. Spring framework khi sử dụng với JavaEE làm cho quá trình phát triển ứng dụng enterprise dễ dàng hơn [1, tr1]. Do đó Spring framework ra đời như là một lựa chọn thay thế cho mô hình chuẩn EJB [4, tr1] đã đánh dấu một bước ngoặt trong lịch sử phát triển của Enterprise Java. Spring là một trong những framework của Java được sử dụng phổ biến nhất tính đến thời điểm này. Và nó được giới thương mại công nhận như một nền tảng kiến trúc có tầm quan trọng trong chiến lược kiến tạo phần mềm chính là do framework này có cách tạo và liên kết các thành phần rất riêng và hữu ích. Trong các hệ thống lớn việc xây dựng các thành phần một cách độc lập, riêng rẽ là một yêu cầu quan trọng và nó phụ thuộc rất lớn vào việc lựa chọn công nghệ và kỹ thuật để phát triển hệ thống này. Tính độc lập, riêng rẽ giữa các thành phần được xem xét trên 2 khía cạnh khác nhau. Một là xét về khía cạnh mã nguồn (code). Giảm sự kết dính của code (writing loosely coupled code) có nghĩa là sự phụ thuộc, liên kết giữa các class, đối tượng trong hệ thống càng “lỏng lẻo” (loosely coupled) càng tốt. Để giải quyết cho việc “writing loosely coupled code” thì có khá nhiều kĩ thuật nổi tiếng như là: Dependencies Injection, Isolate Dependencies, Reversing Dependencies. Và Spring là một trong những framework mạnh về Dependencies Injection. Ngoài ra Spring là một framework mạnh trong việc xây dựng các ứng dụng enterprise. Nó cũng có thể dễ dàng tích hợp với các framework khác Struts, Hibernate làm cho việc phát triển các ứng dụng enterprise hiệu quả hơn do đó làm giảm sự phụ thuộc và có sự tách biệt rõ ràng giữa các thành phần [1, tr8]. Hai là xét về khía cạnh các thành phần, module trong hệ thống. Nền tảng cơ bản của việc thiết kế hướng đối tượng là việc các đối tượng thao tác với nhau qua việc gửi thông điệp (sending message). Do đó việc thiết kế một phần mềm sẽ xoay quanh việc
  • 15. 3 chúng ta thiết kế sao cho các thành phần, module giao tiếp thông qua một giao diện mà không cần phải biết quá nhiều về nhau và phụ thuộc lẫn nhau. Để giải quyết vấn đề này chúng tôi áp dụng mô hình hệ thống gửi nhận thông điệp để làm thành phần giao tiếp giữa các module trong các hệ thống. Áp dụng mô hình gửi nhận thông điệp sẽ giúp cho nhiều thành phần dễ dàng giao tiếp với nhau và giảm sự phụ thuộc vào nhau rất nhiều. Trong luận văn này chúng tôi sẽ trình bày về Java Message System (JMS) như là một công nghệ áp dụng cho việc xây dựng hệ thống gửi nhận thông điệp. Ngày nay khi dịch vụ web bùng nổ phần lớn các hệ thống đều được xây dựng trên nền tảng như một ứng dụng web hơn là các ứng dụng chạy độc lập trên các máy tính cá nhân. Tuy nhiên một trong những giới hạn của các ứng dụng web là cách thức nó tương tác với người dùng. Khác với các ứng dụng desktop có những khả năng dường như vô tận trong cách thức tương tác với người dùng. Các ứng dụng web tương tác với người dùng chậm hơn so với các ứng dụng desktop bởi chính nguyên lý hoạt động của nó: tất cả các giao dịch phải thực hiện thông qua giao thức HTTP. Việc áp dụng công nghệ Ajax đóng vai trò cốt lõi thực hiện các tương tác trung gian giữa người dùng và máy chủ sẽ giúp chúng ta khắc phục một phần hạn chế này. Và để mang lại cho người dùng trải nghiệm giống như trên ứng dụng desktop một số framework JavaScript sẽ giúp chúng ta phát triển ứng dụng web dạng SPA. Trong luận văn này chúng tôi sẽ trình bày về AngularJS và áp dụng framework này để xây dựng một ứng dụng web minh họa. Ngày nay với số lượng người dùng các thiết bị di động ngày càng tăng, những hệ thống được triển khai trên nền web luôn đảm bảo yêu cầu là phải thích nghi được trên từng loại thiết bị di động này nhằm tăng thêm thị phần, tạo sự thuận lợi cho người dùng. Viêc hiển thị bố cục phù hợp cho từng loại thiết bị sẽ do CSS hoặc Javascript đảm nhận việc nhận diện kích thước màn hình và hiển thị với thiết lập CSS của giao diện dành cho thiết bị đó. Trong luận văn này chúng tôi sẽ sử dụng Bootstrap để thiết kế giao diện responsive. 1.3 PHẠM VI ĐỀ TÀI Luận văn sẽ tập trung trình bày kết quả nghiên cứu của chúng tôi về các nội dung sau: Spring framework, Java Message System, AngularJS framework, MongoDB, Boostrap và Maven. Mỗi phần chúng tôi sẽ giới thiệu sơ lược và trình bày những nội dung cơ bản nhất, những điểm mạnh hay lợi ích mà nó mang lại cho các nhà phát triển phần mềm. Cụ thể về Spring framework chúng tôi sẽ tập trung tìm hiểu và trình bày 3 module: Spring core, Spring MVC và Spring Security. Một số module khác được trình bày trong luận văn của bạn Lê Thành Được. Sau khi tìm hiểu chúng tôi sẽ vận dụng kết quả tìm hiểu được vào việc xây dựng một ứng dụng nhằm mục đích minh họa cho phần lý thuyết đã trình bày. Chúng tôi sẽ xây dựng một ứng dụng quản lý nhạc trên nền web. Ứng dụng sẽ được thiết kế thành 2 module chính là module client và module server. Trong luận văn này chúng tôi sẽ trình
  • 16. 4 bày phần thiết kế và xây dựng module client. Module server sẽ được trình bày trong luận văn của bạn Lê Thành Được. 1.4 PHƯƠNG PHÁP NGHIÊN CỨU Tìm kiếm và nghiên cứu các tài liệu về Spring Framework và các công nghệ có liên quan đến việc phát triển một ứng dụng web enterprise như JMS, AngularJS, MongoDB, Maven của các tác giả trong và ngoài nước, các bài báo, thông tin trên mạng,… sau đó chọn lọc và sắp xếp lại theo ý tưởng của mình. Dựa trên kết quả tìm hiểu được để xây dựng một ứng dụng web quản lý nhạc có áp dụng tất cả những nội dung đã nghiên cứu nhằm mục đích minh họa cho phần cơ sở lý thuyết sẽ trình bày trong nội dung luận văn này. 1.5 BỐ CỤC LUẬN VĂN Trong phần này chúng tôi sẽ trình bày ngắn gọn về nội dung chính của từng phần trong luận văn nhằm giúp cho người đọc dễ dàng theo dõi. Chương 1: Giới thiệu tổng quan về cơ quan thực tập; lý do và tính cấp thiết để thực hiện đề tài này. Trong chương này còn trình bày về các vấn đề cụ thể cần phải giải quyết và hướng giải quyết cho từng vấn đề; phạm vi cũng như phương pháp nghiên cứu đề tài. Chương 2: Trình bày về cơ sở lý thuyết được sử dụng trong đề tài bao gồm các nội dung về ngôn ngữ lập trình Java, Spring framework, Java Message System, AngularJS, MongoDB và Bootstrap: - Trong phần Spring framework chúng tôi sẽ giới thiệu sơ lược về framework này và một số khái niệm liên quan, tiếp theo sẽ trình bày về 3 module là Spring Core, Spring MVC và Spring Security. - Phần Java Message System sẽ giới thiệu tổng quan về hệ thống gửi nhận thông điệp, về JMS và 2 mô hình gửi nhận thông điệp trong JMS. - Phần AgularJS sẽ trình bày tổng quan về framework này và những đặc trưng nổi bật của nó. - Phần tiếp theo trình bày về NoSQL, các dạng của NoSQL; giới thiệu về MongoDB và ưu điểm của hệ quản trị CSDL này. - Phần cuối cùng sẽ giới thiệu về Bootstrap và tính năng responsive mà Bootstrap hỗ trợ trong việc xây dựng giao diện người dùng cho ứng dụng web. Chương 3: Sau khi tìm hiểu về Spring, JMS, AngularJS, MongoDB và Bootstrap chương này trình bày phần phân tích, thiết kế và cài đặt ứng dụng quản lý nhạc phía client sử dụng các công nghệ vừa nêu. Chương 4: Những kết quả đạt được, thảo luận những vấn đề khó khăn và đưa ra hướng phát triển trong tương lai. Phần cuối cùng là tài liệu tham khảo và một số phụ lục về hướng dẫn triển khai ứng dụng; phụ lục giới thiệu về Maven.
  • 17. 5 Chương 2 CƠ SỞ LÝ THUYẾT 2.1 NGÔN NGỮ LẬP TRÌNH JAVA 2.1.1 Java và lịch sử phát triển Java là một ngôn ngữ lập trình dạng lập trình hướng đối tượng (OOP). Khác với phần lớn ngôn ngữ lập trình thông thường, thay vì biên dịch mã nguồn thành mã máy hoặc thông dịch mã nguồn khi chạy, Java được thiết kế để biên dịch mã nguồn thành bytecode, bytecode sau đó sẽ được môi trường thực thi (runtime environment) chạy. Cú pháp Java được vay mượn nhiều từ C và C++ nhưng có cú pháp hướng đối tượng đơn giản hơn và ít tính năng xử lý cấp thấp hơn. Do đó việc viết một chương trình bằng Java dễ hơn, đơn giản hơn, đỡ tốn công sửa lỗi hơn. Java được khởi đầu bởi James - Gosling và bạn đồng nghiệp ở Sun Microsystems năm 1991. Ban đầu ngôn ngữ này được gọi là Oak (có nghĩa là cây sồi) do bên ngoài cơ quan của ông Gosling có trồng nhiều loại cây này. Java được phát hành vào năm 1994. Sau khi Oracle mua lại công ty Sun Microsystems năm 2009 - 2010, Oracle đã mô tả họ là "người quản lý công nghệ Java với cam kết không ngừng để bồi dưỡng một cộng đồng tham gia và minh bạch". Lịch sử phiên bản java:  JDK 1.0 (23 tháng 01, 1996)  JDK 1.1 (19 tháng 2, 1997)  J2SE 1.2 (Playground) 08 tháng 12, 1998  J2SE 1.3 (Kestrel) 08 tháng 5, 2000  J2SE 1.4.0 (Merlin) 06 tháng 02, 2002  J2SE 5 (1.5.0) (Tiger) 30 tháng 9, 2004  Java SE 6 (còn gọi là Mustang), được công bố 11 tháng 12 năm 2006.  Java SE 7 (còn gọi là Dolphin), được bắt đầu từ tháng 8 năm 2006 và công bố ngày 28 tháng 7 năm 2011.  JDK 8, 18 tháng 3 năm 2014  Phiên bản dự kiến tiếp theo: Java 9 dự kiến ra đời năm 2016 2.1.2 Java Reflection Trong phần này sẽ trình bày về Reflection trong Java. Java reflection là nền tảng cho cách thức làm việc của tất cả các dependency injection framework trong Java như Dagger, Google Guice, PicoContainer và Spring, chính vì vậy việc hiểu về Java reflection sẽ giúp chúng ta dễ dàng tiếp cận Spring hơn. Reflection là kĩ thuật rất cần thiết để lấy các thông tin của một kiểu dữ liệu. Dựa vào đó ta có thể kích hoạt (gọi các phương thức) hoặc tạo thể hiện của kiểu dữ liệu đó. Một ứng dụng quan trọng của reflection mà chúng ta có thể biết là Java Bean. Nhờ đó, các IDE (như NetBeans) hoặc các framework có thể lấy được các thông tin và thiết lập giá trị cho các đối tượng trong môi trường run-time. Kiến trúc của Java Reflection API
  • 18. 6 Các lớp được dùng trong reflection nằm trong hai package là java.lang và java.lang.reflect. Package java.lang.reflect bao gồm ba lớp chính mà chúng ta cần biết là Constructor, Field và Method: - Class<T>: Lớp này đại diện cho các lớp, interface và chứa các phương thức dùng để lấy các đối tượng kiểu Constructor, Field, Method. - AccessibleObject: Các kiểm tra về phạm vi truy xuất (public, private, protected) của field, method, constructor sẽ được bỏ qua. Nhờ đó chúng ta có thể dùng reflection để thay đổi, thực thi các thành phần này mà không cần quan tâm đến phạm vi truy xuất của nó. - Constructor: Chứa các thông tin về một constructor của lớp. - Field: chứa các thông tin về một field của lớp, interface. - Method: chứa các thông tin về một phương thức của lớp, interface. Dưới đây là một ví dụ đơn giản dùng để in ra thông tin của một lớp trong môi trường run time chỉ cần chúng ta biết được tên đầy đủ (bao gồm cả phần package) của lớp đó. Giả sử chúng ta có class User như sau: User.java package com.nthienan; public class User { private String username; private String password; public User() { } public User(String username, String password) { this.username = username; this.password = password; } public void printHello(String fullName){ System.out.println("Hello" + fullName); } Hình 2.1: Kiến trúc tổng quát Java Reflaction API
  • 19. 7 Hàm main như sau: public String getUsername() { return username; } public void setUsername(String username) { this.username = username; } public String getPassword() { return password; } public void setPassword(String password) { this.password = password; } } Main.java package com.nthienan; import java.lang.reflect.Constructor; import java.lang.reflect.Field; import java.lang.reflect.Method; public class Main { public static void main(String[] args) { try { Class<?> c = Class.forName("com.nthienan.User"); System.out.println("*****Class name*****"); System.out.println("Name: " + c.getName()); System.out.println("Simple name: " + c.getSimpleName()); Field[] fields = c.getDeclaredFields(); System.out.println("n*****Field*****"); for (Field f : fields) { System.out.println(f); } Constructor[] constructors = c.getConstructors(); System.out.println("n*****Constructor*****"); for (Constructor constructor : constructors) { System.out.println(constructor); } Method[] methods = c.getDeclaredMethods(); System.out.println("*****Method*****"); for (Method m : methods) { System.out.println(m); } } catch (ClassNotFoundException e) { e.printStackTrace(); } }
  • 20. 8 Kết quả: Chúng ta có thể tạo ra một thể hiện (instance) của class này một cách dễ dàng bằng một trong hai cách như ví dụ sau. Vì phương thức newInstance( ) trả về một đối tượng kiểu Object nên cần phải ép kiểu đối tượng này về kiểu User. Để thực thi một phương thức cụ thể, chúng ta cần sử dụng hai phương thức sau: Class.getMethod(String name, Class[] parameterTypes): trả về đối tượng Method đại diện cho một phương thức của lớp. Phương thức này được xác định qua tên và các kiểu tham số. Method.invoke(Object obj, Object[] args) thực thi phương thức tương ứng của đối tượng obj với các tham số args. Ví dụ sau thực thi phương thức printHello(String fullName) của lớp User bằng cách tạo một đối tượng User và truyền vào làm tham số đầu tiên trong phương thức Method.invoke( ). Nếu phương thức printHello( ) là static chỉ cần truyền null vào làm tham số đầu tiên của phương thức Method.invoke( ). } *****Class name***** Name: com.nthienan.User Simple name: User *****Field***** private java.lang.String com.nthienan.User.username private java.lang.String com.nthienan.User.password *****Contructor***** public com.nthienan.User() public com.nthienan.User(java.lang.String,java.lang.String) *****Method***** public java.lang.String com.nthienan.User.getPassword() public void com.nthienan.User.printHello(java.lang.String) public void com.nthienan.User.setPassword(java.lang.String) public java.lang.String com.nthienan.User.getUsername() public void com.nthienan.User.setUsername(java.lang.String) Class<?> c = Class.forName("com.nthienan.User"); //tạo một đối tượng với constructor không có tham số User instance = (User) c.newInstance(); //tạo đối tượng với constructor có tham số Constructor<?> con = c.getConstructor(String.class, String.class); User instance1 = (User) con.newInstance("nthienan", "123"); //tạo một đối tượng với constructor không có tham số User instance = (User) c.newInstance();
  • 21. 9 Kết quả: 2.2 SPRING FRAMEWORK 2.2.1 Tổng quan về Spring Spring framework, hay ngắn hơn là Spring, là một cấu trúc dùng để xây dựng chương trình ứng dụng mã nguồn mở dành cho ngôn ngữ lập trình Java. Phiên bản đầu tiên của nó do Rod Johnson viết và đã được ông xuất bản cùng với quyển sách đầu tay Expert One-on-One JavaEE Design and Development (Nhà xuất bản Wrox Press, Tháng 10 năm 2002). Kiến trúc của Spring framework được ra mắt công chúng lần đầu tiên hồi tháng 6 năm 2003 dưới Giấy phép Apache - phiên bản 2.0. Phiên bản 1.0 đánh dấu mốc thành đạt đầu tiên được xuất bản vào tháng 3 năm 2004 và tiếp đó vào tháng 9 năm 2004, tháng 3 năm 2005. Tuy Spring framework không bắt buộc người ta phải tuân theo một mô hình lập trình cụ thể nào, song nó lan truyền rộng rải trong cộng đồng những người viết chương trình dùng Java, như một hình thức chủ yếu thay thế cho mô hình Enterprise Java Bean. Theo thiết kế, bộ framework này giải phóng lập trình viên dùng Java, cho phép họ nhiều quyền tự do hơn và đồng thời cung cấp một giải pháp tiện lợi, đầy đủ dẫn chứng bằng tài liệu, dễ dàng sử dụng, phù hợp với những thực hành thông dụng trong công nghệ phần mềm. Bên cạnh những đặc trưng nền tảng của Spring framework là những cái có thể dùng được trong bất cứ một chương trình ứng dụng Java nào, rất nhiều các mở rộng và tiến bộ trong việc kiến tạo các trình ứng dụng dành cho nền tảng mạng web (web-based application) dựa trên nền Java Enterprise cũng tồn tại nữa. Spring framework nổi tiếng cũng một phần do chính đặc thù kể trên và được giới thương mại công nhận như một nền tảng kiến trúc có tầm quan trọng trong chiến lược kiến tạo phần mềm. 2.2.2 Lịch sử phát triển Phần đầu tiên của Spring framework ban đầu nguyên được Rod Johnson viết vào năm 2000. Vào năm 2001, những mô hình lập trình cho các trình ứng dụng Web được đại đa số sử dụng đều do Java Servlet API và Enterprise Java Bean cung cấp. Năm 2003 thành lập dự án phát tại Sourceforge để phát triển Spring. Sau khi phát triển trên nền tảng ban đầu hơn một năm họ đã phát hành phiên bản đầu tiên (1.0) vào tháng 3 năm 2004. Spring framework đã làm cho những kỹ thuật vốn không được biết đến mấy trở nên những kỹ thuật được mọi người ưa chuộng trong một thời gian ngắn ngủi. Một trong Method method = c.getMethod("printHello", String.class); method.invoke(instance, "World"); Hello World
  • 22. 10 những kỹ thuật nổi tiếng hơn cả là kỹ thuật “đảo ngược quyền điều khiển” (Inversion of Control, IoC). Năm 2005 cho thấy mức độ hưởng ứng nâng cao hơn những năm trước, nguyên do cũng vì những phiên bản mới được giới thiệu với những cột mốc đáng kể và những tính năng mới được thêm vào. Diễn đàn Spring (Spring Forum) ra đời cuối năm 2004 cũng góp phần không nhỏ trong việc nâng cao tính phổ biến của bộ framework và từ đó đến nay đã sinh trưởng trở thành một nguồn thông tin quan trọng, giúp đỡ cho người sử dụng. Vào tháng 12 năm 2005, hội thảo đầu tiên về Spring Framework đã được tổ chức tại Miami, Florida thu hút 300 nhà phát triển trong 3 ngày và tiếp theo đó cuộc hội thảo ở Antwerp vào tháng 6 năm 2006, thu hút hơn 400 người. 2.2.3 Một số khái niệm chính Hai trong những thành phần chủ chốt và là nền tảng tạo nên sức mạnh của Spring chính là IoC và DI. 2.2.3.1 Inversion of Control (IoC) IoC Container trong Spring được xây dựng dựa trên nguyên lý Inversion of Control (đảo ngược điều khiển) đã xuất hiện khá lâu trong các mẫu hình thiết kế (design pattern), và được phổ biến rộng rãi nhờ Robert C. Martin và Martin Fowler. Để hiểu về Spring, trước tiên chúng ta cần hiểu khái niệm IoC là gì? Muốn vậy, chúng ta cần trả lời câu hỏi: Control (điều khiển) trong chương trình phần mềm là gì, và Inversion (sự đảo ngược) đối với điều khiển trong ngữ cảnh này được hiểu như thế nào? Khái niệm Control Flow (tạm dịch là luồng thực thi) được sử dụng cho trình tự thực hiện các câu lệnh, chỉ thị hoặc lời gọi hàm trong một chương trình, khi chương trình này thực thi. Do chương trình ngày càng phức tạp, nên các lập trình viên áp dụng phương pháp lập trình hướng đối tượng nhằm phân loại, chia tách các chức năng và gom thành các đối tượng. Các lập trình viên còn tạo dựng các thư viện tạo sẵn để có thể sử dụng lại. Luồng thực thi của chương trình, trong những tình huống cần xem xét ở mức tổng thể, không còn quan tâm đến các bước thực thi câu lệnh cụ thể nữa, mà chỉ xem xét đến quá trình gọi phương thức của các đối tượng trong ứng dụng cũng như các đối tượng của thư viện dựng sẵn. Các lập trình viên, khi xây dựng ứng dụng từ đầu, đã thực hiện hai nhiệm vụ: trực tiếp điều khiển luồng thực thi của chương trình và xây dựng các chức năng để đáp ứng nghiệp vụ của ứng dụng. Thực tế, có nhiều chương trình hoặc bộ phận trong chương trình có luồng thực thi rất giống nhau, chẳng hạn phần tương tác với HTTP trong các ứng dụng web, phần unit testing trong các ứng dụng,… Việc trực tiếp tạo dựng và kiểm soát luồng thực thi của chương trình lặp đi lặp lại khi xây dựng nhiều ứng dụng sẽ làm mất nhiều công sức, chi phí, tạo ra sự nhàm chán và dễ phát sinh lỗi. Điều này tạo ra động lực cũng như môi trường để nguyên lý đảo ngược điều khiển nảy nở và phát triển.
  • 23. 11 Vậy sự “đảo ngược” (inversion) luồng điều khiển chương trình trong ngữ cảnh này được hiểu như thế nào? Chúng ta hãy xem xét 2 ví dụ dưới đây. Ví dụ 1: Ứng dụng web trong Java với JavaServlet Khi lập trình ứng dụng web bằng JavaServlet cần thực hiện các bước lập trình như sau: - Tạo lớp đối tượng kế thừa từ HttpServlet, override các phương thức doGet(), doPost(),… - Đăng ký trong file cấu hình Deployment Descriptor tương ứng Servlet này với đường dẫn xác định. - Lớp đối tượng Servlet chúng ta tạo ra sẽ được gọi đến khi có một truy vấn HTTP có đường dẫn “khớp” với đường dẫn khai báo trong Deployment Descriptor. Vậy ai kích hoạt ứng dụng chúng ta viết để đáp ứng mỗi khi có HTTP Request gửi đến? Ai chịu trách nhiệm chuyển đổi các thông điệp HTTP (HTTP Request và HTTP Response) thành các đối tượng Java (HttpServletRequest và HttpServletResponse) để truyền cho các hàm doGet(), doPost()? Đó chính là Servlet Container. Hình 2.2: Luồng điều khiển của chương trình bình thường
  • 24. 12 Ví dụ 2: Lập trình kiểm thử đơn vị (Unit testing) với Junit Trong quá trình phát triển các thành phần chức năng của ứng dụng, chúng ta thường áp dụng kiểm thử đơn vị để đảm bảo chức năng đó vẫn chạy đúng trong suốt quá trình ứng dụng được mở rộng và phát triển thêm. Để tạo bộ unit test, chúng ta chỉ cần tạo một lớp đối tượng, định nghĩa các phương thức khởi tạo, phương thức kết thúc và các phương thức test. Sau đó, chúng ta chỉ việc chạy bộ test để kiểm thử. Việc điều khiển trình tự thực thi các phương thức được giao cho thư viện bên ngoài đảm nhiệm chẳng hạn như TestNG hoặc JUnit. Hình 2.3: Servlet Container Hình 2.4: Kiểm thử đơn vị với JUnit
  • 25. 13 Với hai ví dụ trên, chúng ta nhận thấy trong các ứng dụng đã có sự thay đổi vai trò. Ứng dụng không còn ôm đồm vừa trực tiếp tạo dựng và kiểm soát luồng thực thi, vừa xây dựng chức năng nghiệp vụ. Việc kiểm soát luồng thực thi được tách khỏi chức năng nghiệp vụ và bị đẩy ra bên ngoài. Người lập trình đã ủy thác việc kiểm soát luồng thực thi ứng dụng cho một thành phần (thường là thư viện dựng sẵn) bên ngoài đảm nhiệm, chỉ còn tập trung vào chức năng chính của ứng dụng. Như vậy, khái niệm “đảo ngược” ở đây chính là chuyển nhiệm vụ kiểm soát lưu trình thực thi từ ứng dụng cho một thành phần chuyên trách (thường là một thư viện phần mềm khung – framework – dựng sẵn ở bên ngoài). Ứng dụng chính chúng ta quan tâm phát triển không kiểm soát việc điều khiển luồng thực thi nữa, mà chỉ tập trung vào việc định nghĩa chức năng. Thư viện phần mềm khung chuyên trách kiểm soát điều khiển sẽ dựa trên mô tả trong cấu hình của ứng dụng để thay mặt ứng dụng điều phối luồng thực thi trong chương trình. Dễ dàng nhận thấy thư viện phần mềm khung này khác với các thư viện thông thường ở chỗ: thư viện thông thường cung cấp các chức năng và chờ được ứng dụng gọi đến, còn thư viện phần mềm khung tạo dựng luồng thực thi và gọi đến các chức năng của ứng dụng. Nói một cách ngắn gọn IoC là một design pattern và tập hợp các kỹ thuật lập trình liên quan, trong đó luồng thực thi của một hệ thống bị đảo ngược so với cách tương tác truyền thống [4, tr1]. IoC trong Spring cũng hoàn toàn mang ý nghĩa như trên. Trong Spring các đối tượng chính để xây dựng ứng dụng thì được quản lý bởi Spring IoC container. Và IoC container gọi các đối tượng đó là các bean. Một bean chỉ đơn giản là một đối tượng được khởi tạo và quản lý bởi Spring IoC container. 2.2.3.2 Dependency Injection (DI) Dependency Injection là khả năng liên kết giữa các thành phần lại với nhau, đó chính là việc các thuộc tính trong một đối tượng được “tiêm chích” (injection) để tham Hình 2.5: Mô hình ứng dụng áp dụng IoC
  • 26. 14 chiếu lần lượt đến các đối tượng khác. Dependency Injection trong Spring hoạt động dựa trên Java Reflection. 2.2.4 Các module Spring được xây dựng với 7 module chính (Hình 2-6). - Spring Core: Core package là phần cơ bản nhất của Spring, cung cấp những đặc tính như IoC (Inversion of Control) và DI (Dependency Injection). Khái niệm cơ bản là BeanFactory, một cài đặt của Factory pattern, cho phép “móc nối” sự phụ thuộc giữa các đối tượng trong file cấu hình. - Spring Context: Spring context là một file cấu hình để cung cấp thông tin ngữ cảnh của Spring. Spring context cung cấp các service như JNDI access, EJB integration, e-mail, internalization, validation, và scheduling functionality. - Spring AOP (Aspect – Oriented Programming): Spring AOP module tích hợp chức năng lập trình hướng khía cạnh vào Spring framework thông qua cấu hình của nó. Spring AOP module cung cấp các dịch vụ quản lý giao dịch cho các đối tượng trong bất kỳ ứng dụng nào sử dụng Spring. Với Spring AOP chúng ta có thể tích hợp declarative transaction management vào trong ứng dụng mà không cần dựa vào EJB component. Spring AOP module cũng đưa lập trình metadata vào trong Spring. Sử dụng cái này chúng ta có thể thêm annotation vào source code để hướng dẫn Spring nơi và làm thế nào để liên hệ với aspect. - Spring DAO (Data Access Object): Tầng JDBC và DAO đưa ra một cây phân cấp exception để quản lý kết nối đến database, điều khiển exception và thông báo lỗi được ném bởi vendor của database. Tầng exception đơn giản điều khiển lỗi và giảm khối lượng code mà chúng ta cần viết như mở và đóng kết nối. Hình 2.6: Các module của Spring framework
  • 27. 15 Module này cũng cung cấp các dịch vụ quản lý giao dịch cho các đối tượng trong ứng dụng Spring. - Spring ORM (Object Relational Mapping): Spring có thể tích hợp với một vài ORM framework để cung cấp Object Relation tool bao gồm: JDO, Hibernate, OJB và iBatis SQL Maps. - Spring Web: Nằm trên application context module, cung cấp context cho các ứng dụng web. Spring cũng hỗ trợ tích hợp với Struts, JSF và Webwork. Web module cũng làm giảm bớt các công việc điều khiển nhiều request và gắn các tham số của request vào các đối tượng domain. - Spring MVC: MVC Framework thì cài đặt đầy đủ đặc tính của MVC pattern để xây dựng các ứng dụng Web. MVC framework thì cấu hình thông qua giao diện và chứa được một số kỹ thuật view bao gồm: JSP, Velocity, Tiles và generation of PDF và Excel file. 2.2.5 Spring Core 2.2.5.1 Bean Trong Spring các object được quản lý bởi IoC container và được gọi là bean. Một bean thì đơn giản là một đối tượng được khởi tạo, phân phát và được quản lý bởi IoC container [6, tr27]. Sự phụ thuộc giữa chúng được phản ánh trong configuration metadata. Một Spring container sẽ quản lý một hoặc nhiều bean. Các bean được tạo ra nhờ vào thông tin cấu hình được chỉ ra trong thẻ <bean /> nếu sử dụng XML config. Bên trong container các bean được biểu diễn như một đối tượng của lớp BeanDefinition, nó chứa các thông tin sau: - Class của đối tượng mà bean được cấu hình (bao gồm cả phần package) - Các thông số cấu hình hành vi của bean như: phạm vi (scope), vòng đời (lifecycle),… - Các tham chiếu đến các bean khác, các tham chiếu này được gọi là collaborators hoặc dependencies - Các thiết lập khác như số connection kết nối đến bean,… Các thuộc tính sau đây thường được sử dụng để định nghĩa một bean: class (instantiating beans), name (naming beans), scope, constructor arguments, properties, autowiring mode, lazy-initialization mode, initialization method, destruction method 2.2.5.1.1 Tên bean (Naming beans) Mỗi bean có một hoặc nhiều định danh (indentifiers), các định danh này phải là duy nhất trong một container. Một bean thường chỉ có duy nhất một định danh, tuy nhiên nếu cần nhiều hơn một định danh thì có thể sử dụng bí danh (alias). Trong cấu hình dạng XML, có thể sử dụng thuộc tính id và/hoặc name để chỉ định định danh cho bean. Thuộc tính id cho phép chỉ định chính xác một định danh duy nhất cho bean. Chúng ta có thể không cần chỉ định id hoặc name cho bean, khi đó container sẽ tự tạo ra một định danh duy nhất cho bean. Tuy nhiên nếu muốn sử dụng tham chiếu ở bean khác bằng cách sử dụng thuộc tính ref thì cần phải chỉ định một cách rõ ràng.
  • 28. 16 Thông thường các bean được đặt tên giống như khai báo biến trong Java, theo quy ước camel-cased. Ví dụ như: accountManager, userDao, loginController…Đặt tên cho bean sẽ giúp file cấu hình dễ đọc và hiểu hơn và nếu sử dụng Spring AOP nó sẽ giúp rất nhiều khi thêm các advice vào bean thông qua tên của bean. 2.2.5.1.2 Khởi tạo bean Một bean thực chất là một “công thức” cho việc tạo ra một hoặc nhiều đối tượng [6, tr34]. Nếu sử dụng configuration metadata dạng XML (XML-based configuration metadata) cần phải chỉ định rõ class của đối tượng sẽ được bean quản lý và khởi tạo khi có yêu cầu. Có 3 cách để khởi tạo một bean: Khởi tạo bean với hàm dựng (constructor) Thông thường khi tạo một bean bằng phương pháp sử dụng constructor, tất cả các class đều có thể dùng được và phù hợp với Spring [6, tr34]. Có nghĩa là các class không cần phải thực thi (implement) bất kỳ giao diện (interface) cụ thể nào. Tuy nhiên, tùy thuộc vào loại IoC có thể cần một constructor mặc định (không đối số). Spring IoC container có thể quản lý hầu như bất kỳ class nào mà chúng ta muốn nó quản lý [6, tr34]. Hầu hết người dùng Spring thích sử dụng cách tạo một bean bằng việc sử dụng một constructor mặc định (không có đối số) và các setter và getter [6, tr34]. Khởi tạo bean với phương thức tĩnh (static factory method) Để tạo một bean sử dụng phương thức tĩnh, thuộc tính class chỉ ra lớp chứa phương thức tĩnh và thuộc tính factory-name chỉ ra tên của phương thức này được định nghĩa bên trong class vừa chỉ định. Ví dụ dưới đây sẽ cho thấy rõ việc tạo một bean bằng cách gọi phương thức tĩnh. Lưu ý thuộc tính class trong tag bean không phải chỉ định kiểu (class) của đối tượng mà thật ra chỉ là chỉ định class chứa phương thức tĩnh được chỉ định ở thuộc tính factoty-method được gọi để tạo ra đối tượng mà thôi, trong ví dụ này chính là phương thức createInstance() trong lớp MusicService. Khởi tạo bean sử dụng phương thức của đối tượng (instance factory method) public class MusicService { private static MuisicService musicService = new MuisicService(); private MuisicService() { } public static MuisicService createInstance() { return musicService; } } <bean id="musicService" class="com.nthienan.MusicService" factory-method="createInstance" />
  • 29. 17 Tương tự như việc sử dụng phương thức tĩnh, với phương pháp này sử dụng một phương thức non-static của một bean để tạo ra bean mới. Để sử dụng cách này thuộc tính class của tag bean sẽ không được chỉ định, thay vào đó thuộc tính factory-bean chỉ ra tên của bean mà có chứa phương thức dùng để tạo ra đối tượng. Tên của phương thức này được chỉ định trong thuộc tính factory-method. Ví dụ dưới đây sẽ chỉ ra cách sử dụng phương pháp này. 2.2.5.1.3 Phạm vi của bean (Bean scopes) Khi định nghĩa một bean chúng ta đã đưa ra một “công thức” cho việc tạo một thể hiện thực sự của một class [6, tr57]. Việc khởi tạo một hay nhiều thể hiện, khi nào thì một thể hiện được tạo ra sẽ phụ thuộc vào phạm vi của bean. Spring đưa ra năm phạm vi của một bean, trong đó ba phạm vi chỉ có khi xây dựng các ứng dụng web. Năm phạm vi của một bean được trình bày tóm tắt trong bảng dưới đây: Bảng 2-1: Phạm vi của bean Phạm vi Giải thích Singleton Chỉ có một thể hiện duy nhất được tạo ra cho bean trong mỗi Spring IoC container. Đây là phạm vi mặc định của mỗi bean Prototype Ngược lại với singleton, prototype cho phép nhiều hơn một đối tượng được tạo ra trên mỗi container. Request Một thể hiện cụ thể sẽ được tạo ra cho mỗi HTTP request. Phạm vi này chỉ có trong container của các ứng dụng web (WebApplicationContext) Session Tương tự như request nhưng, một thể hiện cụ thể sẽ được tạo ra cho mỗi HTTP session. Phạm vi này chỉ có trong container của các ứng dụng web (WebApplicationContext) public class MusicService { private static SongService songService = new SongService(); private MuisicService() { } public SongService createSongServiceInstance() { return songService; } } <!-- factory bean --> <bean id="musicService" class="com.nthienan.MusicService"> <!-- các cấu hình khác cho bean này ở đây --> </bean> <!-- bean được tạo thông qua factory bean --> <bean id="songService" factory-bean="musicService" Factory-method="createSongServiceInstance" />
  • 30. 18 Global session Một thể hiện cụ thể sẽ được tạo ra cho một global HTTP session. Phạm vi này chỉ có trong container của các ứng dụng web. Appplication Một thể hiện cụ thể sẽ được tạo ra cho một Servlet context. Phạm vi này chỉ có trong container của các ứng dụng web. Thông thường thì singleton và prototype là hai phạm vi của bean được sử dụng nhiều nhất. Dưới đây xin trình bày chi tiết về 2 phạm vi này. Singleton scope. Khi khai báo một bean với phạm vi là singleton điều này có nghĩa là chỉ có duy nhất một thể hiện của class được chỉ ra trong bean trong một container. Thể hiện này sẽ được lưu trữ trong cache của Spring IoC container, tất cả các yêu cầu tiếp theo tham chiếu đến bean này thì thể hiện được lưu trữ trong cache sẽ được trả về. Ví dụ dưới đây cho thấy cách khai báo một bean với phạm vi singleton trong XML: Prototype scope <bean id="accountDao" class="com.nthienan.AccountDao"></bean> <!-- hoặc --> <bean id="accountDao" class="com.nthienan.AccountDao" scope="singleton"></bean> Hình 2.7: Singleton scope
  • 31. 19 Ngược lại với singleton, một bean với phạm vi là prototype thì mỗi khi có một yêu cầu tham chiếu đến bean này thì một thể hiện cụ thể của bean sẽ được tạo ra. Khai báo một bean với phạm vi prototype trong XML như sau: 2.2.5.2 Spring IoC Container Spring là một framework thực thi theo nguyên tắc Inversion of Control, IoC cũng được biết đến như Dependency Injection [6, tr27]. Nó là một quá trình xử lý ở nơi các object định nghĩa sự phụ thuộc (dependency). Khi các đối tượng hoạt động với nhau chỉ thông qua các tham số của constructor, tham số của các method hoặc các property để thiết lập thể hiện sau khi được khởi tạo. Container sau đó “tiêm” các đối tượng phụ thuộc khi nó được tạo ra từ các bean. Quá trình này về cơ bản là sự đảo ngược, các bean sẽ điều khiển các thể hiện hoặc vị trí phụ thuộc bằng cách khởi tạo trực tiếp từ class của chúng. Package org.springframework.beans và org.springframework.context là 2 package cơ bản cho IoC container của Spring. Interface BeanFactory cung cấp kỹ thuật để cấu hình nâng cao và quản lý bất kỳ loại object nào. ApplicationContext kế thừa BeanFactory, ApplicationContext thêm vào một số tính năng như tích hợp để dễ dàng hoạt động với các tính năng của Spring AOP (Aspect Oriented Programming) như Message resource handling, event publication; và một số lớp context đặc biệt như WebApplicationContext được sử dụng trong các ứng dụng web. Nói một cách ngắn gọn, BeanFactory cung cấp cơ chế cấu hình cho framework và các chức năng cơ bản. ApplicationContext thêm vào một số chức năng nâng cao. Trong phần này sẽ sử dụng ApplicationContext để để mô tả cho IoC container của Spring. Interface org.springframework.context.ApplicationContext chịu trách nhiệm khởi tạo, cấu hình và phân phát các bean. Container lấy các chỉ dẫn cho việc khởi tạo, cấu hình và phân phát bằng cách đọc các configuration metadata. Các configuration <bean id="accountDao" class="com.nthienan.AccountDao" scope="prototype"></bean> Hình 2.8: Prototype scope
  • 32. 20 metadata được trình bày bằng nhiều cách khác nhau như trong file XML, Java annotaion hoặc trong Java code. Điều này cho phép biểu diễn các đối tượng và sự phụ thuộc lẫn nhau giữa chúng trở nên phong phú hơn. Một số class thực thi (implementation) interface ApplicationContext như Class PathXmlApplicationContext, FileSystemXmlApplicationContext, AnnotationConfigApplicationContext,… XML là cách truyền thống và thường được sử dụng để định nghĩa các configuration metadata, chúng ta cũng có thể khai báo để container sử dụng các annotation như configuration metadata hoặc trực tiếp trong code Java bằng cách cấu hình thêm trong file XML cho phép sử dụng các annotation như sau: <context:annotation-config/> Hình 2-9 mô tả cách thức làm việc của Spring. Các class trong ứng dụng sẽ kết hợp với các configuration metadata để sau khi ApplicationContext được tạo ra và khởi tạo chúng ta có được một cấu hình đầy đủ và có thể thực thi được. Như hình chúng ta thấy các configuration metadata sẽ nói với Spring container khởi tạo, cấu hình và phân phối các object trong ứng dụng của chúng ta như thế nào. Thông thường các configuration metadata được biểu diễn dưới dạng XML, vì vậy trong phần này sẽ sử dụng configuration metadata dưới dạng này để nói về các khái niệm và tính năng của IoC container. Lưu ý rằng không phải chỉ có các configuration metadata dưới dạng XML mới được Spring container chấp nhận, như đã nói ở phần trên ngoài các metadata dạng XML chúng ta còn có thể sử dụng Java annotaion hoặc trực tiếp trong code Java (Java config). Kể từ phiên bản 2.5 Spring đã hổ trợ kiểu cấu hình dựa trên các Java annotation. Và kể từ Spring 3.0 nhiều tính năng đã được cung cấp bằng cách sử dụng Java config và nó trở thành một phần của Spring core. Vì vậy chúng ta có thể định nghĩa bean bên ngoài các Hình 2.9: Spring IoC Container
  • 33. 21 class của ứng dụng bằng cách sử dụng Java code hơn là file XML. Để sử dụng tính năng này xem thêm các annotation như @Configuration, @Bean, @Import và @DependOn. Cấu hình trong Spring bao gồm ít nhất là một và thường là nhiều hơn một định nghĩa bean mà container cần phải quản lý [6, tr28]. Trong metadata dạng XML để khai báo và cấu hình một bean ta sử dụng thẻ <bean /> bên trong thẻ <beans />. Nếu sử dụng dạng Java config thông thường sẽ sử dụng annotaion @Bean bên trong một class với annotaion @Configuration. Ví dụ dưới đây là sẽ cho thấy cấu trúc cơ bản của một file XML trình bày các configuration metadata. Thuộc tính id chỉ ra định danh của bean đó, thuộc tính class chỉ ra class của bean này (lưu ý sử dụng tên đầy đủ của class bao gồm cả phần package). Giá trị của thuộc tính id sẽ được các bean khác sử dụng nếu cần thiết. 2.2.5.2.1 Khởi tạo container Việc khởi tạo một Spring container đơn giản như việc chúng ta khởi tạo một đối tượng, cần chỉ rõ đường dẫn của file XML cấu hình trong khi khởi tạo một container. Ví dụ dưới đây sẽ cho chúng ta thấy rõ hơn: Trong đó file config “services.xml” như sau: <?xml version=”1.0” encoding=”UTF-8”?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="http://www.springframework.org/schema/context http://www.springframework.org/schema/beans/spring-beans-3.0.xsd"> <bean id="bean1" class="com.nthienan.Bean1"> <!-- cấu hình cho bean ở đây --> </bean> <bean id="bean2" class="com.nthienan.Bean2"> <!-- cấu hình cho bean ở đây --> </bean> </beans> ApplicationContext context = new ClassPathXmlApplicationContext(new String[] {"services.xml", "daos.xml"} );
  • 34. 22 Và file config “daos.xml” như sau: Ở ví dụ trên class MusicServicesIpml được cấu hình trong file “services.xml” và có hai thuộc tính truy cập dữ liệu thuộc hai lớp là AccountDao và SongDao. Thẻ <property /> dùng để tham chiếu đến một bean khác, trong đó thuộc tính name là tên của thuộc tính trong class MusicServicesIpml và giá trị của ref là id của bean cần tham chiếu đến. Thường thì mỗi file cấu hình XML sẽ cấu hình cho một tầng hoặc một module trong ứng dụng. Việc chia nhỏ như thế giúp dễ dàng kiểm soát hơn. 2.2.5.2.2 Sử dụng container Ví dụ dưới đây sẽ chỉ ra cách đọc các định nghĩa của bean và truy cập đến chúng. <?xml version=”1.0” encoding=”UTF-8”?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="http://www.springframework.org/schema/context http://www.springframework.org/schema/beans/spring-beans-3.0.xsd"> <bean id="musicService" class="com.nthienan.MusicServicesImpl"> <property name="accountDao” ref=”accountDao" /> <property name="songDao" ref="songDao" /> <!-- các cấu hình khác ở đây --> </bean> </beans> <?xml version=”1.0” encoding=”UTF-8”?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="http://www.springframework.org/schema/context http://www.springframework.org/schema/beans/spring-beans-3.0.xsd"> <bean id="accountDao" class="com.nthienan.AccountDao"> </bean> <bean id="songDao" class="com.nthienan.SongDao"> </bean> </beans> ApplicationContext context = new ClassPathApplicationContext(new String[] {"services.xml", "daos.xml"} ); //nhận về đối tượng đã được config MusicServicesImpl services = (MusicServicesImpl)context.getBean("musicService"); //sử dụng đối tượng List<String> songs = services.getSongList();
  • 35. 23 2.2.5.3 Dependency Injection 2.2.5.3.1 Constructor – based dependency injection Constructor – based DI là phương pháp “tiêm sự phuộc” cho các đối tượng bằng cách gọi hàm tạo (constructor method) với các tham số chính là các “sự phụ thuộc” (dependentcies) của đối tượng. Ví dụ sau đây sẽ đưa ra một class chỉ có thể tiêm sự phụ thuộc bằng phương pháp này. Khi đó để tiêm sự phụ thuộc cho lớp MessageSender cần khai báo các bean như sau: Thẻ <constructor-arg /> trong ví dụ này sẽ cho Spring container biết đây là một bean mà các dependentcy sẽ được tiêm vào bằng cách gọi hàm tạo của lớp này. Đối với các hàm tạo với nhiều đối số thì thứ tự của các thẻ <constructor-arg /> sẽ giống với thứ tự các đối số của hàm, giống như ví dụ dưới đây public class MessageSender { private Message message; public MessageSender(Message message) { this.message = message; } } public class Message { public Message() { } } <bean id="message" class="com.nthienan.Message" /> <bean id="sender" class="com.nthienan.MessageSender"> <constructor-arg ref="message" /> </bean> public class A { private B b; private C c; public A(B b, C c) { this.b = b; this.c = c; } } <bean id="a" class="com.nthienan.A"> <constructor-arg ref="b" /> <constructor-arg ref="c" /> </bean>
  • 36. 24 Ở các ví dụ trên các dependentcy là những kiểu dữ liệu do người dùng định nghĩa nên thẻ <constructor-arg /> sử dụng thuộc tính ref để tham chiếu đến bean khác. Riêng đối với các kiểu dữ liệu nguyên thủy (int, boolean, string,…) thì khai báo bean đơn giản hơn. Các khai báo bean dưới đây là tương tự nhau. <bean id="b" class="com.nthienan.B" /> <bean id="c" class="com.nthienan.C" /> public class Z { private int b; private String c; private boolean d; public A(B b, C c, D d) { this.b = b; this.c = c; this.d = d; } } <bean id="z" class="com.nthienan.Z"> <constructor-arg value="123" /> <constructor-arg value="abc" /> <constructor-arg value="true" /> </bean> <!-- hoặc --> <bean id="z" class="com.nthienan.Z"> <constructor-arg value="123" type="int"/> <constructor-arg value="abc" type="java.lang.String"/> <constructor-arg value="true" type="boolean"/> </bean> <!-- hoặc --> <bean id="z" class="com.nthienan.Z"> <constructor-arg index="0" value="123" /> <constructor-arg index="1" value="abc" /> <constructor-arg index="2" value="true" /> </bean> <!-- hoặc --> <bean id="z" class="com.nthienan.Z"> <constructor-arg name="b" value="123" /> <constructor-arg name="c" value="abc" /> <constructor-arg name="d" value="true" /> </bean>
  • 37. 25 2.2.5.3.2 Setter – based dependency injection Thông thường với mỗi thuộc tính XXX trong một lớp, sẽ có các phương thức getXXX() và setXXX() tương ứng với nó. Qua phương thức setXXX(), thuộc tính XXX sẽ được gán cho một giá trị nào đó (giá trị này có thể thuộc kiểu primitive hay kiểu tham chiếu). Spring cũng cung cấp cho chúng ta phương pháp để gán giá trị đến một thuộc tính qua phương thức setter của nó. Setter – based DI là phương pháp tiêm sự phuộc cho các đối tượng bằng cách gọi các setter của một class sau khi hàm dựng mặc định (không đối số) được gọi để khởi tạo bean. Ví dụ dưới đây sẽ đưa ra một class chỉ có thể tiêm sự phụ thuộc bằng các setter. Khi đó để tiêm sự phụ thuộc cho lớp Person cần khai báo các bean như sau: Thẻ <property> được dùng để biểu diễn cho một phương thức setter. Thuộc tính name của thẻ <property /> chỉ định thuộc tính mà setter của nó sẽ được gọi để gán giá trị được chỉ định trong thẻ <value /> (hoặc thuộc tính value như cách khai báo bean thứ 2). Thuộc tính name phải khớp với phần đuôi của phương thức setter. Ví dụ ta có phương thức là setAField(), thì lúc khai báo sẽ tương ứng là name=”aField”. Chúng ta có thể kết hợp cả 2 phương pháp DI này trong khai báo một bean. Thông thường Constructor – based DI được sử dụng cho những dependency bắt buộc và Setter – based DI cho những dependency tùy chọn. public class Person { private String fullName; private int age; public void setFullName(String fullName) { this.fullName = fullName; } public void setAge(int age) { this.age = age; } } <bean id="person" class="com.nthienan.Person"> <property name="fullName"> <value>Nguyen Thien An</value> </property> <property name="age"> <value>22</value> </property> </bean> <!-- hoặc ngắn gọn hơn --> <bean id="person" class="com.nthienan.Person"> <property name="fullName" value="Nguyen Thien An" /> <property name="age" value="22" /> </bean>
  • 38. 26 Dễ dàng nhận thấy rằng tất cả các class ở những ví dụ trên đều là những POJOs (những class Java bình thường), chúng hoàn toàn không kế thừa từ bất cứ một class hoặc thực thi một interface đặc biệt nào, đều này cho thấy được sức mạnh của Spring trong việc xây dựng một ứng dụng từ các POJOs là nhờ vào DI và IoC container. Spring container xử lý việc tiêm sự phụ thuộc cho các bean như sau: - Spring container ApplicationContext được tạo ra và khởi tạo những siêu dữ liệu cấu hình (configuration metadata) cho tất cả các bean. Các configuration metadata có thể là XML, code Java hoặc các annotaion. - Đối với từng bean các dependency của nó được thể hiện dưới dạng là các property, các đối số của hàm tạo. Những dependency này sẽ phải được cung cấp cho bean khi bean thực sự được khởi tạo. - Đối với từng property hoặc các đối số của hàm được gán giá trị để thiết lập cho bean hoặc được tham chiếu đến một bean khác trong container. - Giá trị của từng property và đối số của hàm tạo sẽ được chuyển thành kiểu dữ liệu phù hợp, Spring sẽ chuyển chúng từ kiểu String sang các kiểu dữ liệu khác như int, long, String, boolean,… Spring container sẽ kiểm tra tính hợp lệ của các thông tin cấu hình cho mỗi bean khi container được tạo. Tuy nhiên các thuộc tính của bean sẽ không được thiết lập cho đến khi bean thật sự được tạo ra và một bean chỉ được tạo khi có một yêu cầu đến nó. 2.2.5.3.3 Autowiring Khi một bean A cần tham chiếu đến bean B (B là một dependency của A) chúng ta cần phải cấu hình cho bean A để có thể “tiêm” B vào thông qua Constructor – based DI hoặc Setter – based DI. Tuy nhiên nếu chúng ta cấu hình cho bean A autowire thì Spring container có thể thực hiện việc này một cách “tự động” bằng cách Spring container sẽ kiểm tra trong ApplicationContext để tìm ra B và “tiêm” cho A. Autowiring thực sự hữu ích khi phát triển một ứng dụng mà việc chỉnh sửa mã nguồn là thường xuyên [6, tr52], ví dụ khi thêm một thuộc tính mới cho một class, nếu sử dụng autowire thì cấu hình bean của class này không cần phải thay đổi. Để cấu hình cho một bean có thể autowire chỉ cần thêm thuộc tính autowire trong thẻ <bean />. Autowire có 4 loại vì vậy cần phải chỉ rõ loại của autowire đối với mỗi bean. Dưới đây là 4 loại của autowire: - Autowire by name. Spring sẽ tìm kiếm bean có tên giống như tên của property cần autowire. Ví dụ nếu bean A được chỉ định là autowire by name có property tên master (class A cần phải có phương thức setMasster(…)) , Spring sẽ tìm một bean có tên (id) là master và tiêm nó vào bean A. - Autowire by type. Autowire by type cho phép một property được autowire nếu có một bean có kiểu (class) là kiểu của property này. Nếu có nhiều hơn một bean thì một exception được ném ra, ngược lại nếu không tồn tại bất cứ bean nào phù hợp thì không có exception nào được ném ra và property này không được thiết lập (set) giá trị. - Autowire by constructor. Tương tự như autowire by type, tuy nhiên autowire by constructor chỉ áp dụng cho các đối số của hàm tạo. Nếu không có chính xác
  • 39. 27 một bean có kiểu là kiểu của các đối số trong hàm tạo thì một exception sẽ được ném ra. - No autowire. Không autowire, đây là thiết lập mặc định của các bean. Các bean tham chiếu đến nhau thông qua thuộc tính ref. No autowire được khuyến cáo nên sử dụng, bởi vì việc chỉ định các dependency một cách rõ ràng sẽ tốt hơn và ở một mức độ nào đó nó được xem như tài liệu cho cấu trúc của hệ thống. Lưu ý là các dependency được chỉ định một cách tường minh sẽ ghi đè lên lên autowire. Đối với các property có kiểu dữ liệu nguyên thủy như String, Classes… thì không thể autowire. 2.2.6 Spring MVC 2.2.6.1 Tổng quan về Spring MVC Spring MVC là một module con trong Spring framework, cung cấp kiến trúc Model-View-Controller và các components sẵn có để sử dụng và phát triển ứng dụng web một cách linh hoạt. Hình 2.10: Kiến trúc module Spring MVC
  • 40. 28 Mô hình MVC là kết quả của việc tách các khía cạnh khác nhau của ứng dụng (logic đầu vào, các xử lý logic, UI) trong khi đó cung cấp một sự kết hợp giữa các thành phần đó một cách “lỏng lẻo”. Model: đóng gói dữ liệu ứng dụng và bao gồm các POJO. View: Chịu trách nhiệm nhận giá trị của model và vẽ ra trang HTML mà trình duyệt có thể hiển thị được. Controller: Chịu trách nhiệm nhận và xử lý các yêu cầu từ người dùng và tạo các model phù hợp và trả về cho view. Spring MVC được thiết kế xung quanh DispatcherServlet để xử lý tất cả các HTTP request và HTTP response. Luồng xử lý các yêu cầu của DispatcherServlet được minh họa theo hình: Đây là chuỗi sự kiện tương ứng khi nhận một yêu cầu HTTP gửi đến DispatcherServlet: 1. Sau khi nhận một HTTP request, DispatcherServlet gửi yêu cầu đến HandlerMapping (một bản đồ cấu hình URL) để xác định controller nào sẽ xử lý yêu cầu này. 2. Controller sẽ nhận các request và gọi các phương thức dịch vụ (service methods) phù hợp dựa trên việc sử dụng các method GET/POST… Nếu yêu cầu đó cần truy xuất cơ sở dữ liệu thì Controller sẽ ủy nhiệm cho một business logic hay nhiều hơn một model để lấy thông tin và gửi dữ liệu về cho Controller. Lúc này Controller đóng gói mô hình dữ liệu và tên của một view sẽ được tải lên thành đối tượng ModelAndView và gửi trả về cho DispathcherServlet 3. DispatcherServlet gửi gói ModelAndView cho ViewResolver để tìm xem view (thông thường là một trang JSP, HTML) nào sẽ được load lên. 4. Sau khi hoàn tất, DispatcherServlet sẽ chuyển dữ liệu từ model đến view và cuối cùng hiển thị trên trình duyệt. Hình 2.11: Sơ đồ luồng xử lý của Spring MVC
  • 41. 29 2.2.6.2 DispathcherServlet DispathcherServlet là thành phần tiếp nhận tất cả các request từ browser, điều khiển luồng xử lý và trung chuyển giữa các thành phần (components) trong MVC. Hơn thế nữa, nó còn tích hợp các Spring IoC container, cho phép ta sử dụng đến tất cả các tính năng của Spring [6, tr439]. Hình 2-11 sẽ cho chúng ta thấy luồng xử lý một request trong Spring MVC và DispatcherServlet chính là Front controller. DispatcherServlet thực sự là một Servlet (nó thừa kế từ lớp cơ sở HttpServlet), và được khai báo trong tập tin web.xml của ứng dụng web. Các requests muốn DispatcherServlet xử lý sẽ phải được ánh xạ bằng cách sử dụng một bộ ánh xạ URL trong cùng một tập tin web.xml. Dưới đây là ví dụ về khai báo và định nghĩa DispatcherServlet Hình 2.12: Luồng xử lý một request trong Spring MVC
  • 42. 30 Như ta thấy, tất cả các requests bắt đầu bằng /music sẽ được DispatcherServlet ‘music-manager’ xử lý. Khi DispatcherServlet được khởi tạo, Spring sẽ gọi file có tên [tên-servlet]- servlet.xml trong thư mục WEB-INF. Với ví dụ trên, Spring sẽ gọi file music- manager-servlet.xml. 2.2.6.3 Controllers Controllers là các thành phần được DispatcherServlet gọi để xử lý các nghiệp vụ business. Tất cả các Controller trong Spring đều implement từ Controller interface trong package org.springframework.web.servlet.mvc Controller interface định nghĩa ra 1 phương thức chịu trách nhiệm xử lí 1 request và trả về model và view thích hợp. Ba khái niệm này chính là nền tảng của Spring MVC framework : Model – View – Controller. Sau đây là các Controller sử dụng được trong Spring: - SimpleFormController - AbstractController - AbstractCommandController - CancellableFormController - AbstractCommandController - MultiActionController - ParameterizableViewController - ServletForwardingController - ServletWrappingController <?xml version=”1.0” encoding=”UTF-8”?> <webapp> <servlet> <servlet-name>music-manager</servlet-name> <servlet-class> org.springframework.web.servlet.DispatcherServlet </servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>music-manager</servlet-name> <url-pattern>/music/*</url-pattern> </servlet-mapping> </webapp> package org.springframework.web.servlet.mvc; public interface Controller { ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception; }
  • 43. 31 - UrlFilenameViewController Kể từ khi Spring 2.5 giới thiệu và đưa vào mô hình lập trình cho các MVC controller dựa trên các annotation như @Controller, @RequestMapping, @RequestParam, @PathVariable,… thì việc tạo ra một controller trở nên vô cùng đơn giản. Để tạo ra một controller chúng ta không cần kế thừa từ một lớp cơ sở hoặc thực thi bất kỳ một interface nào. Hãy xét 2 ví dụ dưới đây để thấy rõ hơn. Ví dụ 1: Tạo controller bằng cách thực thi giao diện AbstractController Khi sử dụng AbstractController làm baseclass cho các controller, chỉ cần override hàm handleRequestInternal (HttpServletRequest, HttpServletResponse), viết code xử lý, và trả về một đối tượng ModelAndView Controller này sẽ trả về một view “hello” được code cứng. Ví dụ 2: Tạo controller sử dụng các annotation Như chúng ta thấy với 2 annotation @Controller và @RequestMapping đã có thể tạo ra 1 controller như ví dụ 1 một cách dễ dàng. Ngoài ra dễ nhận thấy khi có một request với phương thức GET được gửi đến URL “/home/welcome” thì hàm hello( ) của lớp HomeController sẽ được gọi để xử lý và trả kết quả về cho browser. Trong ví dụ này sẽ trả về view “hello” cho browser. public class HomeController implements AbstractController { @Override public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception { ModelAndView modelAndView = new ModelAndView(); model.addObject("message", "This is welcome page!"); model.setViewName("hello"); return modelAndView; } } package com.nthienan.controller; @Controller @RequestMapping(value = "/home") public class HomeController { @RequestMapping(value = "/welcome", method = RequestMethod.GET) public ModelAndView hello() { ModelAndView model = new ModelAndView(); model.addObject("message", "This is welcome page!"); model.setViewName("hello"); return model; } }
  • 44. 32 Nếu chúng ta tạo ra các controller như ví dụ 1 thì cần phải khai báo và định nghĩa các HandlerMapping. 2.2.6.4 Handler Mapping Sử dụng Handler Mapping để có thể ánh xạ từng requests đến các handler thích hợp. Các chức năng cơ bản của một HandlerMapping là đưa ra một Handler Execution Chain (chuỗi hành động), và có thể chứa một số bộ chặn. Khi requests đến, các DispatcherServlet sẽ trao cho các HandlerMapping để nó kiểm tra và xuất ra HandlerExecutionChain thích hợp. Sau đó, các DispatcherServlet sẽ gọi handler và bộ chặn trong hệ thống (nếu có). Một Handler Mapping đơn giản nhưng rất mạnh mẽ là Bean Name Url Handler Mapping, nó ánh xạ các HTTP requests đến tên của các beans, được định nghĩa trong bối cảnh ứng dụng web. Ví dụ chúng ta muốn cho phép một người dùng tạo một tài khoản, ở đây ta đã có một form controller thích hợp và một trang JSP để hiển thị. Khi sử dụng Bean Name Url Handler Mapping, ta có thể ánh xạ HTTP requests với địa chỉ http://samples.com/editaccount vào form Controller như sau: Tất cả requests gửi đến yêu cầu địa chỉ /editaccount bây giờ sẽ được xử lý bởi form Controller ở trên. Cơ chế handler mapping của Spring có khái niệm xử lý đánh chặn, nó có thể cực kỳ hữu ích khi chúng ta muốn áp dụng các chức năng cụ thể cho một request xác định, ví dụ kiểm tra điều kiện chẳng hạn. Ví dụ dưới đây tạo ra một bộ chặn, nó chặn tất cả các requests và redirect người dùng đến một trang xác định nếu thời gian truy cập không nằm từ 9h sáng đến 6h tối. <beans> <bean id="handlerMapping" class="org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping"/> <bean name="/editaccount" class="org.springframework.web.servlet.mvc.SimpleFormController"> <property name="formView" value="account"/> <property name="successView" value="account-created"/> <property name="commandName" value="account"/> <property name="commandClass" value="samples.Account"/> </bean> <beans> <beans> <bean id="handlerMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"> <property name="interceptors"> <list> <ref bean="officeHoursInterceptor"/> </list> </property> <property name="mappings">
  • 45. 33 2.2.6.5 ViewResolver Views trong Spring được gán “view name” và được phân giải bởi ViewResolver. Sau đây là các ViewResolver trong Spring: - BeanNameViewResolver - FreeMarkerViewResolver - InternalResourceViewResolver - JasperReportsViewResolver - ResourceBundleViewResolver - UrlBasedViewResolver - VelocityLayoutViewResolver <value> /*=editAccountFormController </value> </property> </bean> <bean id="officeHoursInterceptor" class="samples.TimeBasedAccessInterceptor"> <property name="openingTime" value="9"/> <property name="closingTime" value="18"/> </bean> <beans> public class TimeBasedAccessInterceptor extends HandlerInterceptorAdapter { private int openingTime; private int closingTime; public void setOpeningTime(int openingTime) { this.openingTime = openingTime; } public void setClosingTime(int closingTime) { this.closingTime = closingTime; } public boolean preHandle( HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Calendar cal = Calendar.getInstance(); int hour = cal.get(0); if (openingTime <= hour && hour < closingTime) { return true; } else { response.sendRedirect("http://host.com/outsideOfficeHours"); return false; } } }
  • 46. 34 - VelocityViewResolver - XmlViewResolver - XsltViewResolver Ở đây xin trình bày Internal Resource View Resolver vì nó thường được sử dụng nhiều nhất. View Resolver này sẽ ánh xạ Logical name của Resource (ModelAndView object được trả về bởi Controller) đến một Physical View (myView.jsp,…). Chúng ta có controller như sau: Chúng ta cần phải khai báo một Internal Resource View Resolver trong file web.xml như sau: Khi đó nếu như request của người dùng thỏa condition1(), thì view “myView.jsp” trong thư mục /WEB-INF/views sẽ được hiển thị, nếu không thì hoặc “myView2.jsp” hoặc “myView3.jsp” sẽ được hiển thị. 2.2.7 Spring Security 2.2.7.1 Tổng quan về Spring Security Spring Security cung cấp một giải pháp bảo mật toàn diện cho các ứng dụng enterprise dựa trên J2EE, Spring Security cố gắng để cung cấp cho chúng ta một hệ thống bảo mật hữu ích và dễ dàng để cấu hình cho các dự án được phát triển dựa trên Spring framework [2, tr2]. Vào năm 2003, Spring Security ban đầu chỉ là một dự án nhỏ và độc lập với Spring với tên gọi là “The Acegi Security System for Spring”. Đến tháng 3/2004 một dự án chính thức được thành lập để phát triển nó. Khoảng một năm sau khi dự án được giới thiệu Acegi Security chính thức trở thành một dự án con (subproject) của Spring Framework. Phiên bản 1.0.0 được giới thiệu vào tháng 5/2006 sau hơn hai năm rưỡi phát triển với hàng trăm cải tiến đáng kể. Cuối năm 2007 Acegi Security chính thức trở thành một project của Spring và được đổi tên thành Spring Security. public class MyController { public ModelAndView handle(){ if(condition1()){ return new ModelAndView("myView1"); }else if (condition2()){ return new ModelAndView("myView2"); } return new ModelAndView("myView3"); } } <bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix"> <value>/WEB-INF/views</value> </property> <property name="suffix"> <value>.jsp</value> </property> </bean>
  • 47. 35 Hai nhiệm vụ chính của việc bảo mật ứng dụng là "xác thực" (authentication) và "ủy quyền" (authorization) hay "kiểm soát truy cập" (access-control) [2, tr2], đây cũng chính là hai phần chính của Spring Security. Xác thực là quá trình xác nhận và chứng thực một principal (một principal thường có nghĩa là một người sử dụng, thiết bị hoặc một số hệ thống khác mà có thể thực hiện một hành động trong ứng dụng) [2, tr2]. Uỷ quyền đề cập đến quá trình quyết định có một principal được phép thực hiện những hành động gì trong phạm vi ứng dụng của chúng ta [2, tr2]. Để được ủy quyền thì quá trình xác thực là cần thiết và phải được thực hiện trước, ủy quyền chỉ được thực hiện khi xác thực thành công [2, tr2]. Đây là những khái niệm rất phổ biến cho hầu hết các ứng dụng và nó không phải là riêng của Spring Security. Ở một mức độ xác thực, Spring Security hỗ trợ một loạt các mô hình xác thực. Hầu hết các mô hình xác thực này hoặc được cung cấp bởi bên thứ ba, hoặc được phát triển bởi các cơ quan như IETF (Internet Engineering Task Force) [2, tr2]. Ngoài ra, Spring Security còn cung cấp các mô hình xác thực riêng cho mình. Cụ thể, Spring Security hiện đang hỗ trợ tích hợp xác thực với tất cả các công nghệ này: - HTTP BASIC authentication headers (an IEFT RFC-based standard) - HTTP Digest authentication headers (an IEFT RFC-based standard) - HTTP X.509 client certificate exchange (an IEFT RFC-based standard) - LDAP (một phương pháp xác thực cross-platform phổ biến thường được sử dụng trong các môi trường lớn) - Form-based authentication - OpenID authentication - Authentication based on pre-established request headers (such as Computer Associates Siteminder) - JA-SIG Central Authentication Service (hay còn gọi là CAS, một mã nguồn mở single sign) - Transparent authentication context propagation for Remote Method Invocation (RMI) and HttpInvoker (a Spring remoting protocol) - Automatic "remember-me" authentication - Anonymous authentication - Run-as authentication - Java Authentication and Authorization Service (JAAS) - JEE container autentication - Kerberos - Java Open Source Single Sign On (JOSSO) - OpenNMS Network Management Platform - AppFuse - AndroMDA - Mule ESB - Direct Web Request (DWR) - Grails - Tapestry - Jtrac
  • 48. 36 - Jasypt - Roller - Elastic Path - Atlassian Crowd Nhiều công ty phần mềm áp dụng Spring Security vì nó cung cấp những mô hình xác thực một cách linh hoạt [2, tr3]. Làm như vậy cho phép các công ty phần mềm nhanh chóng tích hợp các giải pháp của họ với bất cứ khách hàng nào, mà không thực hiện rất nhiều kỹ thuật hoặc yêu cầu khách hàng phải thay đổi môi trường. Nếu không có cơ chế xác thực phù hợp với nhu cầu của khách hàng, Spring Security là một nền tảng mở và nó thực sự đơn giản để viết cơ chế xác thực của riêng chúng ta [2, tr3]. Đôi khi chỉ xác thực là không đủ, chúng ta cũng cần phải quan tâm đến việc nó tích hợp vào ứng dụng như thế nào. Ví dụ, chúng ta có thể muốn đảm bảo rằng tất cả các request chỉ đến qua HTTPS, để bảo vệ mật khẩu khỏi bị nghe trộm hay từ các cuộc tấn công man-in-the-middle. Điều này đặc biệt hữu ích để bảo vệ quá trình phát hiện mật khẩu từ các cuộc tấn công brute force, hoặc chỉ đơn giản là để làm cho nó khó khăn hơn cho người dùng để sao chép nội dung quan trọng của ứng dụng. Để giúp chúng ta đạt được những mục tiêu này, Spring Security hỗ trợ "channel security", cùng với JCaptcha để giải quyết những yêu cầu trên. 2.2.7.2 Các module của Spring Security Spring Security được chia thành 7 module nhỏ dựa trên chức năng của từng module và các thành phần yêu cầu từ bên thứ 3: - spring-security-core.jar: Bao gồm các class và interface cơ bản cho quá trình xử lý xác thực và ủy quyền, hổ trợ các API cơ bản mà các ứng dụng sử dụng Spring Security cần. Bao gồm các package sau: + org.springframework.security.core + org.springframework.security.access + org.springframework.security.authentication + org.springframework.security.provisioning + org.springframework.security.remoting - spring-security-web.jar: Module này chứa các filter và những thành phần khác có liên quan đến việc bảo mật một ứng dụng web, bất cứ thành phần nào có liên quan đến Servlet. Chúng ta cần phải sử dụng module này nếu muốn xác thực trên các dịch vụ web và điều khiển truycập thông qua URL. Package chính của module này là: org.springframework.security.config - spring-security-config.jar: Module này là cần thiết nếu chúng ta cấu hình cho Spring Security bằng file XML. Nó chứa các namspace dùng để parse chúng sang code. Package chính của lớp này org.springframework.security.config - spring-security-ldap.jar: Đây là module dành cho việc xác thực theo mô hình LDAP (Lightweight Directory Access Protocol). Package chính của lớp này là org.springframework.security.ldap - spring-security-acl.jar: ACL (Access Control List) là một danh sách các quyền gắn liền với một đối tượng. Một ACL xác định người dùng hoặc các quá trình của hệ thống được cấp quyền truy cập, cũng như những gì được cho phép hoạt
  • 49. 37 động trên các đối tượng nhất định. Mỗi mục trong một ACL điển hình xác định một chủ thể và một hoạt động. Ví dụ, nếu một tập tin có chứa ACL (Alice: read, write; Bob: read), điều này sẽ cho phép Alice đọc và ghi các file và Bob chỉ đọc nó. Module này sẽ cho phép chúng ta tạo ra một mô hình xác thực như trên. Package chính của module này là org.springframework.security.acls - spring-security-cas-client.jar: Module này chứa các thành phần cần thiết để tích hợp Spring Security và CAS client (Central Authentication Service) nếu chúng ta sử dụng một CAS single sign-on server. Pakage chính chính của module này là: org.springframework.security.cas - spring-security-openid.jar: Module này hổ trợ mô hình xác thực OpenID, sử dụng để chứng thực người dùng bên ngoài hệ thống với một OpenID server. Pakage chính chính của module này là: org.springframework.security.openid 2.3 JAVA MESSAGE SYSTEM (JMS) 2.3.1 Hệ thống gửi nhận thông điệp (messaging system) Trong những năm qua, các hệ thống thông tin đã phát triển đáng kể về độ phức tạp và 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, và linh hoạt hơn trước đã làm nảy sinh những kiến trúc phức tạp và tinh vi. Đáp ứng với nhu cầu gia tăng này để cho ra đời các hệ thống tốt hơn và nhanh hơn, các nhà thiết kế và 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. Hệ thống gởi nhận thông điệp giữa ứng dụng và ứng dụng thường được gọi chung là hệ thống gởi nhận thông điệp hoặc phần mềm trung gian hướng thông điệp (Message - Oriented Middleware (MOM)) (Hình 2-12). Hệ thống gởi nhận thông điệp cho phép hai hay nhiều ứng dụng trao đổi thông tin dưới dạng thông điệp (message). 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 và 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. Trong hệ thống gởi nhận thông điệ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. Hình 2.13: Mô hình hệ thống gửi nhận thông điệp
  • 50. 38 Trong tất cả các hệ thống gởi nhận thông điệ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 và các ứng dụng gửi tin nhắn được tách riêng. Bên gửi và bên nhận không bị ràng buộc với nhau trong bất kỳ hoàn cảnh nào và có thể gửi và nhận thông điệp theo bất kỳ cách nào phù hợp. Hay nói một cách khác 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 mô hình thông tin ngang hàng (peer-to-peer). Một máy khách có thể gởi thông điệp đi và 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 agent cung cấp công cụ truyền thông để tạo, gởi,nhận và đọc 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), và bên nhận có thể thu được thông điệp này từ đích. Tuy nhiên, bên gửi và 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 và bên nhận chỉ cần biết khuôn dạng thông điệp và đích (destination) để sử dụng. 2.3.2 Tổng quan về JMS JMS là một API dùng cho việc gởi nhận thông điệp được Sun phát triển từ JSR- 914. JMS không phải là một hệ thống gởi nhận thông điệp mà chỉ là một trừu tượng hóa (abstraction) của những interface và class được dùng bởi messaging client khi giao tiếp với messaging system. Giống như cách JDBC trừu tượng hóa truy cập tới CSDL quan hệ và JNDI trừu tượng hóa truy cập tới dịch vụ đặt tên và đường dẫn (naming and directory services), JMS cũng trừu tượng hóa truy cập tới các messaging provider. Trong JMS, các client gởi nhận thông điệp được gọi là JMS client, và 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 và thường là một JMS provider. 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 là message consumer. Một JMS client có thể vừa là message producer vừa là message consumer. JMS API có thể được chia làm 3 phần chính: API tổng quát, API P2P và API pub/sub. API tổng quát có thể được dùng để gởi nhận message từ queue hoặc topic. API P2P chỉ được dùng với queue còn API pub/sub chỉ được dùng với topic. Trong API tổng quát có 7 interface chính để gởi nhận JMS message: - ConnectionFactory - Destination - Connection - Session - Message - MessageProducerMessageConsumer
  • 51. 39 ConnectionFactory và Destination phải được lấy từ provider qua JNDI. Các interface khác được tạo ra bằng factory method trong nhiều API interface. Ví dụ: khi đã có ConnectionFactory, chúng ta có thể tạo Connection. Khi đã có Connection, có thể tạo Session. Khi đã có Session, chúng ta có thể tạo Message, Message Producer và Message Receiver. 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ư 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 API cho phép gởi nhận thông điệp không chỉ “liên kết lỏng lẻo” mà còn không đồng bộ. 2.3.3 Các mô hình gửi nhận thông điệp trong JMS JMS hỗ trợ hai loại mô hình gởi nhận thông điệp: point – to - point và publish – 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 và publish – subscribe thường được viết tắt là p2p và pub/sub. Hiểu theo nghĩa đơn giản nhất, publish – subscribe là việc gởi thông điệp từ một tới nhiều, còn point – to - point là việc gởi thông điệp một - một. Hình 2.14: Mô hình tổng quát JMS
  • 52. 40 2.3.3.1 Point – to – point Mô hình point – to – point (Hình 2-15) cho phép các JMS client gởi và nhận thông điệp đồng bộ lẫn bất đồng bộ qua các kênh ảo gọi là queue (hàng đợi). Trong mô hình point – to - point, message producer được gọi là sender và message consumers được gọi là receivers. Một điểm đặc trưng của mô hình point – to - point là các thông điệp được gửi tới queue chỉ được nhận bởi một và chỉ một receiver, mặc dù có thể có nhiều receiver cùng nghe trên một queue để nhận cùng thông điệp. Point – to - point hỗ trợ gởi nhận thông điệp bất đồng bộ theo kiểu “fire and forget” cũng như gởi nhận thông điệp đồng bộ. Point – to - point có xu hướng chặt chẽ hơn mô hình publish – subscribe vì sender thường biết thông điệp sẽ được sử dụng như thế nào và ai nhận được nó. Mô hình point – to - point hỗ trợ cân bằng tải, cho phép nhiều receiver cùng nghe trên một queue, phân tán được tải trọng. JMS provider quản lý queue, đảm bảo rằng một message chỉ được tiêu thụ một và chỉ một lần bởi receiver tiếp theo trong nhóm. 2.3.3.2 Publish - subscribe Trong mô hình publish – subscribe (Hình 2-16), các thông điệp được publish vào một kênh ảo gọi là topic. Message producer được gọi là publisher và message consumers được gọi là subsciber. Không như mô hình point – to - point, thông điệp được publish vào topic có thể được nhiều subscriber nhận. Kỹ thuật này đôi khi được gọi là “phát sóng” một thông điệp. Mỗi subscriber sẽ nhận được một bản sao của từng thông điệp. Hình 2.15: Hai mô hình gửi nhận message trong JMS Hình 2.16: Mô hình point - to - point
  • 53. 41 Thông điệp trong mô hình publish - subscribe được phát tự động tới các consumer mà không cần chúng yêu cầu thông điệp. Mô hình publish - subscribe có xu hướng thiếu chặt chẽ hơn mô hình point – to - point vì publisher thường không biết có bao nhiêu subscriber hoặc subscriber sẽ làm gì với thông điệp. Ví dụ, giả sử một thông điệp được publish vào topic mỗi khi ứng dụng có exception. Publisher chỉ có trách nhiệm publish mỗi khi có exception. Publisher không biết và thường không quan tâm thông điệp sẽ được sử dụng như thế nào. Có nhiều loại subscriber khác nhau trong mô hình publish - subscribe. Subscriber không lâu dài là những subscriber đăng ký tạm, chỉ nhận thông điệp khi chủ động nghe topic. Subscriber lâu dài sẽ nhận bản sao của tất cả thông điệp được đăng, kể cả khi chúng “offline” lúc thông điệp được đăng. 2.4 ANGULARJS 2.4.1 Tổng quan về AngularJS Công nghệ HTML hỗ trợ tốt cho các trang web tĩnh, kiểu như trước năm 2000 vậy. Khi chúng ta xây dựng 1 trang web với PHP, Node/Express, hay Ruby thì nó cũng chỉ là một trang web tĩnh với nội dung được thay đổi khi chúng ta gửi request về máy chủ, máy chủ sẽ render 1 trang với nội dung tương ứng. Tuy nhiên mọi thứ đã thay đổi nhiều từ sự phát triển của HTML5, nhất là khi có sự hổ trợ từ những tập đoàn công nghệ lớn như Google, Yahoo, Facebook, và sự tập hợp đông đảo của cộng đồng mã nguồn mở. Ngoài ra sự thành công của jQuery đã khiến JavaScript được nhiều người yêu thích vì tính đơn giản và dễ sử dụng. Việc phát triển một website sử dụng AJAX thì không khó, chúng ta có thể dùng jQuery để làm việc này với $.ajax tuy nhiên làm thế nào để xây dựng một phần mềm có thể mở rộng, dễ test, nâng cấp và bảo trì thì không hề đơn giản vì bản thân JavaScript không được thiết kế ngay từ đầu để làm những việc này. Do đó sự ra đời của những framework hỗ trợ lập trình viên xây dựng ứng dụng web 1 cách có hệ thống đã ra đời như Sencha, Ember, Knockout, Backbone, CanJS và AngularJS. AngularJS là framework JavaScript được bắt đầu phát triển từ năm 2009, do lập trình viên Misko Hevery tại Google viết ra như là một dự án kiểu “viết cho vui”. Misko và nhóm lúc này đang tham gia vào 1 dự án của Google tên là Google Feedback. Với AngularJS, Misko đã rút ngắn số dòng code front-end từ 17000 dòng còn chỉ khoảng 1500. Với sự thành công đó, đội ngũ của dự án Google Feedback quyết định phát triển Hình 2.17: Mô hình publish - subscribe
  • 54. 42 AngularJS theo hướng mã nguồn mở. Theo thông số từ Github hiện tại dự án AngularJS đang có gần 11.000 người theo dõi và hơn 2.000 lượt fork. Ngày nay các ứng dụng web hiện đại thường được xây dựng như một Single Page Application (SPA) và AngularJS là một framework tuyệt vời để xây dựng 1 SPA. Một Single Page Application là một ứng dụng web hiển thị vừa vặn trên một mặt của trang với mục đích giúp người dùng có trải nghiệm giống như đang dùng ứng dụng trên desktop và làm tăng hiệu suất của ứng dụng [3, tr7]. Hay nói một cách khác là ứng dụng chạy bên trong trình duyệt mà không yêu cầu phải tải lại toàn bộ trang web mỗi lần sử dụng. 2.4.2 Các đặc trưng của AngularJS Dưới đây là những đặc trưng nổi bật của AngularJS: kiến trúc MVC, Two-way binding, Templates, Expressions, Modules, Scopes, Dependency injection, Directives, Routing, Services, Filters, Form validation, Testing. 2.4.2.1 Kiến trúc MVC trong AngularJS MVC (Model - View - Controller) là một kiến trúc phần mềm hay mô hình thiết kế được sử dụng trong kỹ thuật phần mềm. Nó giúp cho các nhà phát triển tách ứng dụng của họ ra 3 thành phần khác nhau Model (xử lý, truy xuất database), View (giao diện) và Controller (điều hướng yêu cầu từ người dùng). Mỗi thành phần có một nhiệm vụ riêng biệt và độc lập với các thành phần khác. MVC thể hiện tính chuyên nghiệp trong lập trình, phân tích thiết kế. Do được chia thành các thành phần độc lập nên giúp phát triển ứng dụng nhanh, đơn giản, dễ nâng cấp, bảo trì. Hình 2.18: Single Page Application
  • 55. 43 Đối với Angular, View sẽ là DOM, Controller là các lớp JavaScript, còn Model sẽ là dữ liệu được lưu ở thuộc tính của các đối tượng trong JavaScript. 2.4.2.2 Two-way binding Two-way binding cùng với Directive là hai trong những đặc trưng nổi bật mang lại sức mạnh cho AngularJS. Để hiểu rõ hơn về two-way binding ta sẽ xem xét one-way binding trước. Khi làm việc với các mô hình MVC framework khác chúng ta sẽ rơi vào trường hợp model và view chỉ được ghép với nhau một lần duy nhất, vì vậy mọi sự cập nhật dữ liệu từ một trong hai lớp đó đều không liên quan gì đến lớp còn lại. Hệ quả là developer phải viết thêm phần “đồng bộ hóa” giữa hai lớp này. Đó chính là one-way binding. Tuy nhiên AngularJS có thể thực hiện được cả hai chiều, đó chính là two-way binding. Hay nói một cách khác two-way binding trong AngularJS là tính năng đồng bộ hóa giữa model và view. Quá trình đồng bộ luôn xảy ra giữa model và view. Mọi sự thay đổi dữ liệu trong lớp này, ngay lập tức được cập nhật vào lớp kia [7, 11]. Chúng ta chỉ cần “bind” một lần, và mọi thứ hoạt động trơn tru. Hình 2-19 sẽ cho thấy rõ hơn về one-way binding và two-way binding. Cũng vì dữ liệu mà view hiển thị thực chất là sự ánh xạ từ model, nên controller cũng hoàn toàn không cần các thao tác data binding phức tạp và phụ thuộc vào cấu trúc DOM của view, kết quả là controller sẽ không quan tâm xem view của chúng ta là gì. Và dĩ nhiên, logic giữa controller và view được bóc tách rất rõ ràng. Code của chúng ta sẽ rất dễ để debug, viết unit-test. Hình 2.20: One-way binding và Two-way binding Hình 2.19: Kiến trúc MVC trong AngularJS
  • 56. 44 2.4.2.3 Directives Tính năng mới này thực sự là đặc điểm tạo nên một khoảng cách lớn giữa Angular và bất kỳ framework JavaScript khác. Directives đề cập đến một tính năng để mở rộng HTML, việc dùng directive sẽ giảm thiểu được số lượng thẻ HTML, code HTML nhìn sẽ gọn gàng và sáng sủa hơn. Mặc dù HTML có thể có nhiều thẻ, nhưng nó không đủ mạnh để tạo ra một ứng dụng web hiện đại. Với directive, chúng ta có thể tạo ra những thẻ HTML mới hoặc các thuộc tính mới cho tất cả các thẻ trong HTML để trình duyệt hiểu nó có nghĩa là gì và nên làm gì. Ví dụ với Angular chúng ta có thể tạo ra thẻ như sau <draggable> drag me </ draggable >. Các văn bản bên trong tag <draggable></ draggable> bây giờ sẽ trở thành draggable trong trình duyệt, sau đó chỉ cần viết một định nghĩa cho directive draggable này trong ứng dụng Angular của chúng ta là xong. Đây là một ví dụ đơn giản của Angular, nó có thể làm rất nhiều thứ hữu ích hơn. Directtive không chỉ giới hạn một phần tử HTML mà còn có thể là thuộc tính, lớp hoặc các chú thích HTML. AngularJS cung cấp cho chúng ta 3 loại directive: - Directive dạng element (một thẻ HTML) viết tắt là E: - Directive dạng attribute (thuộc tính của một thẻ HTML) viết tắt là A, dạng này là mặc định. - Directive dạng class(class CSS) viết tắt là C. 2.4.2.4 Templates Trong quá trình xây dựng hệ thống lớn, file HTML trở nên rất phức tạp, để giải quyết vấn đề này ta cần chia thành nhiều phần khác nhau, AngularJS cung cấp cho chúng ta một giải pháp hữu ích đó là template. Angular template là một đặc tả dạng declarative, cùng với thông tin từ model và controller, template được render thành một view mà để hiển thị trên trình duyệt. Template bao gồm các static DOM chứa HTML, CSS và các thành phần, thuộc tính riêng của Angular. Các thành phần Angular và các thuộc tính giúp Angular thêm các hành vi và biến đổi template thành dynamic view DOM. Trong Angular, chúng ta có 2 cách để tạo một template: - Dùng file script: Chúng ta có thể tích hợp template vào file HTML hiện hành thông qua thẻ script với type là text/ng-template <my-directive>...</my-directive> <div my-directive>...</div> <div class="my-directive">...</div>
  • 57. 45 - Dùng file ngoài: Chúng ta cũng có thể tạo một file html với nội dung sau: - Sử dụng template: Có nhiều cách để sử dụng template, tuy nhiên trong AngularJS có 2 cách thông dụng để dùng template đó là ng-include và ng-route. Ví dụ dưới đây sẽ dùng ng-include để sử dụng template: Tuy nhiên cách sử dụng ng-include chỉ thích hợp trong các ứng dụng nhỏ, đối với các ứng dụng lớn ng-route (được trình bày trong phần xây dựng ứng dụng) được sử dụng nhiều hơn. 2.4.2.5 Dependency Injection Dependency Injection làm cho ứng dụng Angular dễ dàng hơn để phát triển, có thể sắp xếp mã (code) thành các module. Bằng cách này, chúng ta có thể tạo ra các thành phần tái sử dụng mà có thể được gọi về sau, bất cứ khi nào cần thiết. Ý tưởng này là đặc biệt tốt khi ứng dụng lớn và cần phải được mở rộng, dễ dàng bảo trì và testing. Dependency Injection là một cách để ghép các đoạn code với nhau, điều này đòi hỏi phải phân chia code theo các chức năng riêng biệt như service, controller, hoặc provider. 2.4.2.6 Services Service trong AngularJS là một object hoặc một function phụ trách một tác vụ nào đó. Việc viết service chỉ là việc gom các đoạn xử lý logic vào object hoặc function để dễ quản lý hơn. Cũng giống như mô hình MVC tách phần xử lý, điều hướng và hiển thị riêng biệt. <script type="text/ng-template" id="message.html"> <h3>Hello, {{name}}!</h3> </script> message.html <web-app> <display-name>Music Manager</display-name> index.html <!DOCTYPE html> <html> <head> <script src="http://code.angularjs.org/1.2.12/angular.min.js"> </script> </head> <body> <div ng-controller="ExampleCtrl"> <div ng-include src="message.html"></div> </div> </body> </html>
  • 58. 46 Trong AngularJS service sẽ chứa tất cả các phần xử lý, controller nhận yêu cầu và gọi các service cần thiết để xử lý, model lưu trữ dữ liệu từ các control, view hiển thị dữ liệu, route điều hướng request tới controller. AngularJS cũng xây dựng rất nhiều service vô cùng tiện lợi như: $http, $scope, $window,… 2.4.2.7 Expression Expression được sử dụng trong tất cả các phần của AngularJs, expression được bao bởi kí hiệu {{ }}. Một biến được khởi tạo từ controller thông qua $scope cũng được coi là một expression. Expression được xử lý bởi $parse service. Ví dụ: <body> 2 + 2 = {{2 + 2}} </body>. Angular sẽ tính toán giá trị trong biểu thức và xuất ra màn hình kết quả “2 + 2 = 4”. 2.4.2.8 Fillters Trong AngularJS, một filter cung cấp một định dạng dữ liệu để hiển thị tới người dùng. AngularJS cung cấp một số filter được xây dựng sẵn như: lowercase, date, number, currency, limitTo, orderBy… Một số fillter như: Kết quả: 2.4.2.9 Scope Scope là đối tượng tham chiếu tới model được sử dụng trong controller. Là thành phần gắn kết giữa view và controller. Scope cung cấp các APIs để theo dõi các thay đổi của model (services $watch) và các APIs để truyền bất kỳ thay đổi nào của model tới view (services $apply). Scope giúp tự động đồng bộ dữ liệu giữa model và view. 2.5 MONGODB 2.5.1 Tổng quan về NoSQL 2.5.1.1 NoSQL NoSQL là một dạng CSDL mã nguồn mở không sử dụng T - SQL để truy vấn thông tin. NoSQL viết tắt cho từ None - Relational SQL, hay có nơi thường gọi là Not - Only SQL. {{ "chuỗi kí tự viết thường" | uppercase }} {{ {name: "An", age: 22} | json }} {{ 1504375948024 | date }} {{ 1504375948024 | date:"MM/dd/yyyy @ h:mma" }} CHUỖI KÍ TỰ VIẾT THƯỜNG { "name": "An", "age": 22 } March 23, 2015 03/23/2015 @ 5:39AM
  • 59. 47 NoSQL được phát triển trên Javascript Framework với kiểu dữ liệu là JSON và dạng dữ liệu theo kiểu key và value (một đặc trưng về dữ liệu trong JSON). NoSQL ra đời như một mảnh vá cho những khuyết điểm và thiếu xót cũng như hạn chế của mô hình dữ liệu quan hệ (RDBMS) về tốc độ, tính năng, khả năng mở rộng, memory cache,... Chắc hẳn, chúng đã sử dụng một dạng CSDL quan hệ nào đó có thể là SQL Server, MySQL và không ít lần phải vất vả trong việc chỉnh sửa các bảng dữ liệu khi liên quan tới khóa chính, khóa ngoại hay một loạt các rắc rối khác trong quá trình làm việc. Bởi đó là CSDL quan hệ. Với NoSQL chúng ta có thể mở rộng dữ liệu mà không lo tới những việc như tạo khóa ngoại, khóa chính, kiểm tra ràng buộc, .v.v...Vì NoSQL không hạn chế việc mở rộng dữ liệu nên tồn tại nhiều nhược điểm như: sự phục thuộc của từng bản ghi, tính nhất quán, toàn vẹn dữ liệu,....nhưng chúng ta có thể chấp nhận những nhược điểm đó để khiến ứng dụng cải thiện hiệu suất cao hơn khi giải quyết những bài toán lớn về hệ thống thông tin, phân tán hay lưu trữ dữ liệu. Với các CSDL quan hệ, chi phí triển khai cũng như phát triển các ứng dụng sử dụng CSDL quan hệ cũng rất tốn kém và điều quan trọng được bộc lộ rõ khi truy vấn một lượng bản ghi lớn trong thời gian rất dài. Tiếp đó những thiết bị cầm tay như smartphone thì không phù hợp để triển khai CSDL quan hệ vì dung lượng bộ nhớ thấp và khả năng xử lý kém hơn máy tính. Và còn rất nhiều lí do khác nữa để chúng ta quyết định việc áp dụng NoSQL vào trong dự án của mình. NoSQL được sử dụng ở rất nhiều công ty, tập đoàn lớn, ví dụ như FaceBook sử dụng Cassandra do FaceBook phát triển, Google phát triển và sử dụng BigTable. 2.5.1.2 Các dạng NoSQL cơ bản 2.5.1.2.1 Key – value Dữ liệu lưu dưới dạng cặp key – value. Giá trị được truy xuất thông qua key. Ví dụ như Redis, Dynomite, Project Voldemort. Thường được sử dụng cho “content caching applications”. Ưu điểm là tìm kiếm rất nhanh tuy nhiên dữ liệu không theo khuôn dạng (schema) nhất định. 2.5.1.2.2 Column-based Cơ sở dữ liệu tổ chức dưới dạng các bảng. Gần giống với mô hình RDBMS. Tuy nhiên, chúng lưu dữ liệu bởi các cột chứ không phải bằng các dòng. Nó khá thích hợp để hiển thị bằng các phần mềm quản lý kho dữ liệu. Ví dụ như Apache Hbase, Apache Cassandra, Hypertable. Được sử dụng cho các hệ phân tán file. Ưu điểm là tìm kiếm nhanh, phân tán dữ liệu tốt tuy nhiên có rất ít phần mềm hổ trợ. 2.5.1.2.3 Document-based Dữ liệu được lưu trữ và tổ chức dưới dạng một tập hợp các document. Các document này linh hoạt, mỗi document có một tập nhiều trường. Ví dụ như Apache CouchDB, MongoDB. Thường dùng trong các ứng dụng web. Ưu điểm dùng khi dữ liệu nguồn không được mô tả đầy đủ. Nhược điểm hiệu năng truy vấn, không có cú pháp chuẩn cho câu truy vấn dữ liệu.
  • 60. 48 2.5.1.2.4 Graph-based Những CSDL này áp dụng lý thuyết đồ thị trong khoa học máy tính để lưu trữ và truy xuất dữ liệu. Chúng tập trung vào tính rời rạc giữa các phần dữ liệu. Các phần tử đơn vị dữ liệu được biểu thị như một nút và liên kết với các thành phần khác bằng các cạnh. Ví dụ : Neo4j, InfiniteGraph, DEX. Thường dùng cho Social networking, hệ trợ giúp. Có ưu điểm là ứng dụng các thuật toán trên đồ thị như đường đi ngắn nhất, liên thông. Nhược điểm là phải duyệt nội bộ đồ thị để trả lời lại các truy vấn. Không dễ để phân tán. 2.5.2 MongoDB 2.5.2.1 Tổng quan MongoDB là một hệ CSDL mã nguồn mở được phát triển và hỗ trợ bởi 10gen, là CSDL NoSQL hàng đầu được hàng triệu người sử dụng. Thay cho việc lưu trữ dữ liệu dưới dạng bảng và các tuple như trong các CSDL quan hệ thì MongoDB lưu trữ dữ liệu dưới dạng BSON (dạng binary từ một JSON document). BSON hổ trợ các kiểu dữ liệu cơ bản như boolean, integer, float, date, string,… [5, tr7] Dự án được bắt đầu triển khai vào tháng 10 năm 2007 bởi 10gen trong khi công ty này đang xây dựng một nền tảng như là dịch vụ (Platform as a Service) giống như Google App Engine. Phải đến năm 2009, dự án này được tách độc lập. MongoDB có thể chạy trên Windows, Linux, OS X và Solaris. 2.5.2.2 Ưu điểm Dễ học, có một số nét khá giống với CSDL quan hệ, quản lý bằng command - line hoặc bằng GUI như RoboMongo, RockMongo hoặc phpMoAdmin. Linh động, không cần phải định nghĩa cấu trúc dữ liệu trước khi tiến hành lưu trữ nó, rất tốt khi ta cần làm việc với các dạng dữ liệu không có cấu trúc. Khả năng mở rộng tốt (distributed horizontally), khả năng cân bằng tải cao, tích hợp các công nghệ quản lý dữ liệu vẫn tốt khi kích thước và thông lượng trao đổi dữ liệu tăng. Mã nguồn mở và miễn phí. 2.5.2.3 Kiến trúc tổng quát Một MongoDB Server sẽ chứa nhiều database. Mỗi database lại chứa một hoặc nhiều colection. Đây là một tập các documnents, về mặt logic thì chúng gần tương tự như các table trong CSDL quan hệ. Tuy nhiên, điểm hay ở đây là ta không cần phải định nghĩa trước cấu trúc của dữ liệu trước khi thao tác thêm, sửa dữ liệu… Một document là một đơn vị dữ liệu – một bản ghi (không lớn hơn 16MB). Mỗi document lại chứa một tập các trước hoặc các cặp key – value. Key là một chuỗi ký tự, dùng để truy xuất giá trị dạng: string, integer, double, … Bảng dưới đây đưa ra một so sánh giữa các thành phần trong một RDBMS và MongoDB Bảng 2-2: So sánh các thành phần giữa RDBMS và MongoDB RDBMS MongoDB
  • 61. 49 Database Database Table Collection Tuple/Row Document Column Field Table join Embedded documents Primary key Primary Key ( _id là khóa primary key mặc định) Dưới đây là một ví dụ về MongoDB document: 2.6 BOOTSTRAP VÀ RESPONSIVE Bootstrap là front-end framework, là một bộ sưu tập miễn phí các công cụ để tạo ra các trang web và các ứng dụng web. Bootstrap bao gồm HTML và CSS dựa trên các mẫu thiết kế cho kiểu chữ, hình thức, các button và các thành phần giao diện khác, cũng như mở rộng tùy chọn JavaScript. Boostrap định nghĩa sẵn các class CSS giúp người thiết kế giao diện website tiết kiệm rất nhiều thời gian. Các thư viện Bootstrap có những đoạn mã sẵn sàng cho chúng ta áp dùng vào website của mình mà không phải tốn quá nhiều thời gian để tự viết. Với Bootstrap, việc phát triển giao diện website để phù hợp với đa thiết bị trở nên dễ dàng hơn bao giờ hết. Đây là xu hướng phát triển giao diện website đang rất được ưu chuộng hiện nay. Bootstrap cung cấp tính năng responsive và mobile first, nghĩa là làm cho trang web có thể tự co giãn để tương thích với mọi thiết bị khác nhau, từ điện thoại di động đến máy tính bảng, máy tính xách tay, máy tính để bàn,... Một khía cạnh khác là responsive web design làm cho trang web cung cấp được trải nghiệm tuyệt vời cho người dùng trên nhiều thiết bị, kích thước màn hình khác nhau. Đây là một đặc điểm vô cùng quan trọng vì chúng ta không thể lường trước được các thiết bị, kích thước màn hình sẽ sử dụng để truy cập vào trang web. Một trang có thể hoạt động tốt bất kể sự biến đổi sẽ cung cấp một trải nghiệm người dùng tốt và nhất quán hơn một trang được thiết kế cho một loại thiết bị và kích thước màn hình cụ thể. { "_id" : ObjectId("54b090b1fe90b289da2ac6b8"), "firstName" : "An", "lastName" : "Nguyen", "age" : 22, "sex" : "male", "lastUpdate" : ISODate("2015-03-07T06:39:57.780Z") }
  • 62. 50 Chương 3 THIẾT KẾ VÀ CÀI ĐẶT CHƯƠNG TRÌNH 3.1 MÔ HÌNH ỨNG DỤNG Nhằm mục đích áp dụng các lý thuyết cũng như các kỹ thuật đã nêu ở phần trên, chúng tôi sẽ phân tích và cài đặt một ứng dụng quản lý nhạc trên nền web. Ứng dụng được xây dựng theo mô hình sau (Hình 3-1). Chúng tôi sẽ chia ứng dụng thành 2 module lớn: Module server và module client. Module server sẽ chịu trách nhiệm tương tác với database. Module client bao gồm việc xây dựng các API dưới dạng RESTful web service và giao diện người dùng trên browser. Việc giao tiếp qua lại giữa client và server sẽ được cài đặt theo mô hình một Messaging System. Sơ đồ trang tiếp theo ở trang tiếp theo sẽ cho thấy mô hình chi tiết và luồng thực thi của ứng dụng. Hình 3.1: Mô hình ứng dụng
  • 63. 51 Hình 3.2: Mô hình chi tiết của ứng dụng
  • 64. 52 Hình 3.3: Luồng thực thi của ứng dụng
  • 65. 53 Trong phạm vi luận văn này tôi sẽ tập trung vào việc thiết kế và xây dựng module client. Module server được đề cập đến trong luận văn của bạn Lê Thành Được. Như đã mô tả ở phần trên module client bao gồm 2 nhiệm vụ là thiết kế giao diện người dùng trên nền web và xây dựng các API dưới dạng RESTful web service. HTML, CSS, Bootstrap và AngularJS sẽ được sử dụng để thiết kế giao diện và lập trình phía front- end. Phía back-end sẽ sử dụng Spring framework bao gồm Spring MVC để cài đặt các API RESTful service, Spring Security để xác thực và phân quyền người dùng và Camel Client được sử dụng để giao tiếp với database server thông qua ActiveMQ. Mô hình của module client như hình 3-4. 3.2 THIẾT KẾ MESSAGE Trong một hệ thống gửi nhận thông điệp thì cấu trúc của message là rất quan trọng. Để giao tiếp với nhau các thành phần của hệ thống phải hiểu được cấu trúc của message, vì vậy cấu trúc của nó thường được các thành phần thống nhất với nhau ngay từ khi bắt đầu xây dựng hệ thống. Việc thiết kế message phải đảm bảo được tính mềm dẻo và dễ dàng mở rộng của hệ thống. Phần này sẽ mô tả cấu trúc của message được sử dụng trong ứng dụng. Nếu request của client cần phải thao tác với CSDL thì một message sẽ được controller build và chuyển nó cho producer để gửi nó lên MOM. Module server sẽ chịu trách nhiệm xử lý message này và kết quả sau khi xử lý xong sẽ được gửi lại cho producer đã gửi lên. Dưới đây là sơ đồ class của message. Hình 3.4: Module client
  • 66. 54 Cấu trúc dạng Json của một message: Về mô hình gửi nhận message, message trong hệ thống sẽ được cài đặt theo mô hình point – to – point vì mô hình này có sự đảm bảo chặt chẽ về việc một message thì chỉ được xử lý một lần, điều này là phù hợp với ứng dụng của chúng ta. 3.3 THIẾT KẾ CƠ SỞ DỮ LIỆU Chúng tôi chọn MongoDB để làm hệ quản trị CSDL cho ứng dụng này bởi những lợi ích của nó mang lại mà như chúng tôi đã trình bày trong phần 2.5. Dưới đây là cấu trúc của một số document (record). { "action": "UPDATE", "data": { "artist": "Tokyo Square", "download": 16, "gener": "Rock", "id": "1b8aa99c-8d98-43f0-9469-55b5b7cea944", "lastUpdate": 1425710397780, "musician": "N/A", "name": "That Is Love", "path": "/music/1b8aa99c-8d98-43f0-9469-55b5b7cea944.mp3", "shared": false, "username": "nthienan", "view": 10 }, "method": "PUT" } [ { "_id": "6635f2e6-4455-480c-bae8-5826f6a383e3", "_class": "agu.thesis2015.domain.Song", "name": "Take Me To Your Heart", "gener": "Pop", "artist": "Michael Learns To Rock", "musician": "Stock Aitken Waterman", Hình 3.5: Sơ đồ class Message
  • 67. 55 Hình 3-6 cho thấy 2 document trên được xem trong giao diện RoboMongo "path": "/music/6635f2e6-4455-480c-bae8-5826f6a383e3.mp3", "lastUpdate": "ISODate(2015-03-07T06:38:29.848Z)", "download": 0, "view": 3, "username": "nthienan" }, { "_id": "ac70254b-157f-41d3-98e2-93b93ce844c1", "_class": "agu.thesis2015.domain.Song", "name": "Can't Let Go", "gener": "Pop", "artist": "Tokyo Square", "musician": "N/A", "path": "/music/ac70254b-157f-41d3-98e2-93b93ce844c1.mp3", "lastUpdate": "ISODate(2015-03-07T06:42:38.162Z)", "download": 0, "view": 2, "username": "nthienan", "shared": true } ] Hình 3.6: Document trong giao diện RoboMongo
  • 68. 56 3.4 RESTful API Hình 3.7 và 3.8 trình bày các REST API mà phía back-end (Spring MVC) đã xây dựng để phía fornt-end (AngularJS) sử dụng. Hình 3.7: RESTful API về bài hát Hình 3.8: RESTful API về user
  • 69. 57 3.5 CƠ CHẾ BẢO MẬT ỨNG DỤNG Việc bảo mật ứng dụng sẽ tập trung vào việc bảo vệ các RESTful API bởi vì tất cả các thao tác nghiệp vụ đều được xử lý thông qua các API này. Chúng tôi sẽ sử dụng module Spring Security để xây dựng cơ chế bảo vệ các RESTful API. Hình 3.9 sẽ cho thấy chi tiết cơ chế bảo mật của ứng dụng. Hình 3.9: Cơ chế bảo mật ứng dụng 3.6 SƠ ĐỒ USECASE Bảng 3-1: Danh sách các actor Actor Vai trò User User là đối tượng chính tác động trực tiếp và nhiều nhất vào hệ thống. User có thể thực hiện hầu như các chức năng của ứng dụng. Admin Admin là actor kế thừa actor user và thêm Bảng dưới đây trình bày các chức năng chính của ứng dụng. Bảng 3-2: Danh sách các usecase Chức năng Mô tả Login Xác thực và phân quyền cho người dùng khi họ sử dụng ứng dụng Logout Thoát khỏi phiên làm việc. Sign up Đăng ký tài khoản để sử dụng ứng dụng Change password Thay đổi mật khẩu người dùng
  • 70. 58 Dưới đây là sơ đồ mối quan hệ giữa các actor với actor, actor với use case và use case và use case. Add song Thêm một bài hát mới vào ứng dụng Edit song Chỉnh sửa thông bài hát Delete song Xóa bài hát Play song Phát bài hát Download Tải bài hát Add user Thêm người dùng Edit user Chỉnh sửa thông tin người dùng Delete user Xóa người dùng Reset password Khôi phục mật khẩu Hình 3.10: Sơ đồ use case của actor user
  • 71. 59 Hình 3.11: Sơ đồ use case của actor Role_User Hình 3.12: Sơ đồ use case của actor Role_Admin
  • 72. 60 3.7 GIAO DIỆN VÀ CHỨC NĂNG 3.7.1 Một số giao diện chính Dưới đây là một số giao diện và chức năng chính của ứng dụng. Hình 3.14: Giao diện đăng nhập Hình 3.13: Giao diện đăng ký người dùng
  • 73. 61 Hình 3.17: Giao diện danh sách bài hát Hình 3.15: Giao diện play nhạc Hình 3.16: Giao diện bài hát được chia sẻ
  • 74. 62 Hình 3.19: Giao diện sửa thông tin bài hát Hình 3.18: Giao diện tìm kiếm bài hát Hình 3.20: Giao diện sửa thông tin user
  • 75. 63 Hình 3.23: Giao diện đổi password Hình 3.22: Giao diện thống kê các thông tin Hình 3.21: Giao diện quản lý user
  • 76. 64 3.7.2 Một số chức năng nổi bật của ứng dụng Khi đăng ký thành công tài khoản, một email chứa link để kích hoạt tài khoản được gửi đến người dùng. Tài khoản trước và sau khi kích hoạt (xem trong giao diện quản lý người dùng của admin). Người dùng chỉ có thể đăng nhập vào ứng dụng khi tài khoản đã được kích hoạt. Tính năng đa ngôn ngữ của ứng dụng. Ứng dụng hỗ trợ 2 ngôn ngữ là Tiếng Việt và Tiếng Anh. Hình 3.24: Giao diện sửa thông tin user của admin Hình 3.25: Email kích hoạt tài khoản khi đăng ký thành công Hình 3.26: Tài khoản trước và sau khi kích hoạt
  • 77. 65 Hình 3.28: Ứng dụng với ngôn ngữ Tiếng Anh Hình 3.27: Ứng dụng với ngôn ngữ Tiếng Việt
  • 78. 66 Chương 4 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 4.1 KẾT QUẢ ĐẠT ĐƯỢC Nghiên cứu và trình bày một cách có hệ thống các nội dung cơ bản về Spring framework, AngularJS, JMS, MongoDB và một số công nghệ, kỹ thuật khác trong việc xây dựng một ứng dụng Java enterprise trên nền web. Về mặt lý thuyết: - Nắm được kiến trúc tổng quan của Spring Framework cũng như các nguyên lý cơ bản và cơ chế hoạt động của framework này. - Nắm được mô hình web MVC trong Spring framework và các cơ chế để bảo mật một ứng dụng web được hỗ trợ trong module Spring Security. - Hiểu cơ chế giao tiếp giữa client và server trong mô hình web hiện đại theo hướng RESTful service; cách giao tiếp giữa các thành phần của một hệ thống hoặc giữa các hệ thống với nhau thông qua mô hình Messaging system. Về mặt ứng dụng: - Thiết kế và cài đặt được ứng dụng web với mô hình web server và data server tách biệt nhau, giao tiếp với nhau thông qua ActiveMQ. - Xây dựng được ứng dụng web dạng SPA mà việc giao tiếp với server thông qua RESTful service với sự hỗ trợ của AngularJS. - Thiết kế giao diện người dùng với HTM5 và Bootstrap có hỗ trợ responsive. - Xây dựng thành công ứng dụng quản lý nhạc với đầy đủ các chức năng cơ bản. - Xây dựng thành công một ứng dụng quản lý nhạc trên nền web có áp dụng các công nghệ mới trong quá trình phát triển một ứng dụng Web enterprise hiện đại. 4.2 HẠN CHẾ Các chức năng cơ bản của ứng dụng đã hoàn thành tốt, tuy nhiên do yêu cầu và phạm vi đề tài chỉ dừng lại ở mức demo công nghệ nên ứng dụng chưa hấp dẫn. Hạn chế về vật chất, không có host trên internet có cài đặt đầy đủ các phần mềm cần thiết tạo khó khăn trong việc thực hiện demo chương trình trên internet. Vấn đề triển khai những công nghệ nêu trên không khó về mặt kỹ thuật nhưng phải xây dựng một cơ sở hạ tầng đầy đủ và tốt để có thể thực thi ứng dụng. 4.3 HƯỚNG PHÁT TRIỂN Tiếp tục tìm hiểu về một số cơ chế xác thực và phân quyền trong module Spring Security như cơ chế xác thực Oauth, Oauth2, OpenID,… để xây dựng ứng dụng với cơ chế bảo mật hơn. Bên cạnh đó tiếp tục tìm hiểu các module còn lại của Spring Framework như Spring AOP nhằm tích hợp vào hệ thống để thực hiện một số chức năng đặc biệt như ghi log người dùng. Tìm hiểu về web socket và kết hợp với AngularJS để hướng đến việc xây dựng một ứng dụng web động với thời gian thực.
  • 79. 67 TÀI LIỆU THAM KHẢO [1] Ankur Bawiskar, Prashant Sawant, Vinayak Kankate, B.B. Meshram. Spring Framework A Companion to JavaEE. International Journal of Computational Engineering & Management, Vol. 15 Issue 3, May 2012 [2] Ben Alex, Luke Taylo. Spring Security Reference Documentation [3] Hồ Ngọc Hùng. 2014. Single Page Web Application with Restful API And AngularJS. Helsinki Metropolia University of Applied Sciences [4] Praveen Gupta, Govil. Spring Web MVC Framework for rapid open source J2EE application development a case study. International Journal of Engineering Science and Technology, Vol. 2(6), 2010, 1684-1689 [5] Rick Cattell. 2010. Scalable SQL and NoSQL Data Stores [6] Rod Johnson, Juergen Hoeller, Keith Donald, Colin Sampaleanu, Rob Harrop, Thomas Risberg,... Spring Framework Reference Documentation 4.1.4.RELEASE
  • 80. 68 PHỤ LỤC 1: HƯỚNG DẪN TRIỂN KHAI ỨNG DỤNG Chúng ta cần phải cài đặt và cấu hình tất cả các thành phần như: JDK, Maven, MongoDB, Tomcat và ActiveMQ trước khi có thể chạy được ứng dụng. Bước 1: Cài đặt JDK 1.7 (hoặc cao hơn, trong hướng dẫn này chúng tôi sử dụng JDK 1.8.0_20) Sau khi cài đặt JDK thành công cần kiểm tra biến môi trường JAVA_HOME; nếu như JAVA_HOME chưa có chúng ta thêm vào, hãy chắc chắn JAVA_HOME được thiết lập giống như hình trước khi thực hiện bước tiếp theo. Bước 2: Cài đặt Maven 3.2.5 Tải file apache-maven-3.2.5-bin.zip từ http://maven.apache.org/download.cgi. Giải nén file vừa tải về vào thư mục D:DevApp (có thể chọn thư mục khác). Sau khi giải nén thành công ta được kết quả như hình. Thêm mới biến môi trường M2_HOME:
  • 81. 69 Thêm JAVA_HOME và M2_HOME vào biến môi trường Path: Mở Command Prompt và gõ: mvn –version, nếu kết quả như hình dưới đây là chúng ta đã cài đặt thành công Maven Bước 3: MongoDB 2.6 Tải MongoDB từ http://www.mongodb.org/downloads. Có thể chọn file zip hoặc file MSI, trong hướng dẫn này chúng tôi chọn file zip. Lưu ý là cần chọn phiên bản 32bit hoặc 64bit phù hợp.
  • 82. 70 Giải nén file vừa tải về vào thư mục theo địa chỉ C:Program FilesMongoDB 2.6 Standard (có thể chọn thư mục khác). Sau khi giải nén thành công ta được kết quả như hình Tạo file config.txt trong thư mục E:MongoDB Tạo 2 thư mục data và log tại E:MongoDB. Sau khi thực hiện các bước trên chúng ta được như hình dưới đây: config.txt ##store data dbpath=E:MongoDBdata ##all output go here logpath=E:MongoDBlogmongo.log ##log read and write operations diaglog=3
  • 83. 71 Tiếp theo chúng ta cài đặt MongoDB như một Window Service. Tại thư mục C:Program FilesMongoDB 2.6 Standardbin mở Command Prompt và gõ lệnh: mongod --config E:MongoDBconfig.txt --install Sau khi cài đặt thành công kiểm tra services trong Window chúng ta được 1 services tên MongoDB Bước 4: Cài đặt TomCat 8.0.15 Tải TomCat từ https://tomcat.apache.org/download-80.cgi
  • 84. 72 Giải nén file vừa tải vào thư mục D:DevApp. Sau khi giải nén thành công ta được như hình Cấu hình https cho TomCat tham khảo tại http://java.dzone.com/articles/setting- ssl-tomcat-5-minutes (có thể bỏ qua bước này nếu không muốn sử dụng https) Bước 5: Cài đặt ActiveMQ 5.9.0 Tải ActiveMQ từ http://activemq.apache.org/activemq-590-release.html Giải nén file vừa tải vào thư mục D:DevApp. Sau khi giải nén thành công ta được như hình dưới
  • 85. 73 Bước 6: Lấy source code ứng dụng từ Github và biên dịch với Maven Tải source code từ https://github.com/thienan93/music-manager Giải nén file vừa tải về ta được như hình Biên dịch project MusicManagerShare trước. Mở command Prompt và cd về thư mục MusicManagerShare sau đó gõ lệnh mvn clean install Tương tự biên dịch cho project MusicManagerClient
  • 86. 74 Mở thư mục D:Bitbucketmusic-managerMusicManagerClienttarget copy file ROOT.war sang thư mục D:DevAppapache-tomcat-8.0.15webapps Tiếp theo chúng ta sẽ convert project MusicManagerServer thành eclipse project và import vào Eclipse IDE. Mở command Prompt và cd về thư mục MusicManagerServer sau đó gõ lệnh mvn eclipse:eclipse Mở Eclipse chọn File -> Import -> General -> Existing Project into Workspace. Browse đến thư mục chứa project MusicManagerServer và chọn Finish. Bước 7: Triển khai ứng dụng Start service MongoDB vừa cài đặt ở bước 3.
  • 87. 75 Start ActiveMQ. Vào đường dẫn D:DevAppapache-activemq-5.9.0binwin64 hoặc D:DevAppapache-activemq-5.9.0binwin32 nếu sử dụng hệ điều hành 32bit sau đó double click vào activemq.bat. Sau khi chạy file bat, mở trình duyệt và truy cập vào http://localhost:8161 nếu thành công chúng ta được như hình. Mở Eclipse và run project MusicManagerServer nếu thành công chúng ta được như hình dưới. Start TomCat. Vào đường dẫn D:DevAppapache-tomcat-8.0.15bin và double click vào startup.bat. Mở trình duyệt và truy cập vào https://localhost:8443 hoặc http://localhost:8080. Đăng nhập với các tài khoản: - Role admin: nthienan - 123456
  • 88. 76 - Role user: ltduoc – 123456
  • 89. 77 PHỤ LỤC 2: GIỚI THIỆU MAVEN Maven là công cụ quản lý và thiết lập tự động một dự án phần mềm. Chủ yếu dùng cho các lập trình viên Java, nhưng nó cũng có thể được dùng để xây dựng và quản lý các dự án dùng C#, Ruby, Scala hay ngôn ngữ khác. Maven phục vụ mục đích tương tự như Apache Ant, nhưng nó dựa trên khái niệm khác và cách hoạt động khác. Maven được quản lý bởi Apache Software Foundation, nó là một phần của dự án Jakarta Project. Maven dùng khái niệm Project Object Model (POM) để mô tả việc build project, các thành phần phụ thuộc (dependency) và các module. Nó định nghĩa trước các target cho việc khai báo task, trình biên dịch, đóng gói và thứ tự hoạt động để mọi việc diễn ra tốt nhất. Maven tải các thư viện, plug-in từ một hoặc nhiều repositories. Maven cung cấp việc hỗ trợ tải file từ repository trung tâm của Maven và các repositories khác. Cũng có thể upload các sản phẩm lên repository sau khi đã build xong. Maven được xây dựng dựa trên kiến trúc plugin - cho phép sử dụng bất kỳ ứng dụng điều khiển nào thông qua đầu vào tiêu chuẩn. Về mặt lý thuyết, điều này cho phép bất kỳ ai cũng có thể viết các plugin để giao tiếp với các build tool (trình biên dịch, unit test tool, etc) cho bất kỳ ngôn ngữ nào khác. Nhưng trong thực tế, hỗ trợ và sử dụng cho các ngôn ngữ khác đã bị thu hẹp. Hiện tại thì plugin cho .Net đã có và vẫn được duy trì, và một plugin cho C/C++ cũng được duy trì cho Maven. Một project Maven được cấu hình sử dụng Project Object Model, nó được lưu trong file pom.xml. Một file pom.xml được định nghĩa như dưới đây:
  • 90. 78 Lợi ích của Maven Quản lý các dependencies (các thư viện) trong project một các ưu việt. Tự động cập nhật, mở rộng dễ dàng, đóng gói các thư viện mà project sử dụng. Maven có một repository lớn chứa toàn bộ các thư viện cần thiết (http://mvnrepository.com), nó không pom.xml <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>agu.thesis2015</groupId> <artifactId>MusicManagerClient</artifactId> <packaging>war</packaging> <version>1.0-SNAPSHOT</version> <name>MusicManagerClient Maven Webapp</name> <url>http://maven.apache.org</url> <properties> <jdk.version>1.7</jdk.version> <spring.version>4.1.4.RELEASE</spring.version> </properties> <dependencies> <!-- spring core --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>${spring.version}</version> </dependency> <!-- shared --> <dependency> <groupId>agu.thesis2015</groupId> <artifactId>MusicManagerShared</artifactId> <version>1.0-SNAPSHOT</version> </dependency> </dependencies> <build> <finalName>ROOT</finalName> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.0</version> <configuration> <source>${jdk.version}</source> <target>${jdk.version}</target> </configuration> </plugin> </plugins> </build> </project>
  • 91. 79 chỉ lưu trữ gói mà còn lưu cả version, các version này được cập nhật liên tực bởi người phát triển ra nó. Chính vì thế khi cần thay đổi version thì rất nhanh chóng. Tự động hóa toàn bộ quá trình release project. Một dự án bao gồm các quá trình như khởi tạo, cập nhật thư viện, build & test, release và tạo tài liệu mô tả. Hãy thử tưởng tượng về một dự án lớn, trong đó các hàng chục các module làm các công việc khác nhau. Mỗi team phụ trách một module và quá trình phát triển các module: từ phân tích yêu cầu, đặc tả, đến phát triển, kiểm thử và release là đồng thời và độc lập. Nhưng các module này phụ thuộc vào nhau, cần thiết cho nhau để phát triển. Chỉ cần một sự chậm trễ, sai lầm ở một công đoạn có thể làm đổ vỡ cả quá trình release của project. Cho nên việc tự động hóa toàn bộ là ưu tiên hàng đầu, nhờ đó là việc lên kế hoạch hiệu quả và chính xác hơn, việc tích hợp và triển khai cũng đơn giản hơn rất nhiều. Tự động hóa quá trình test với các plugin. Toàn bộ quá trình test được tự động, từ đó các lỗi được phát hiện sớm hơn. Thậm chí lỗi có thể phát hiện ở giai đoạn phát triển, do các developer đều có thể chạy các test case một cách dễ dàng bằng Maven. Phân chia 1 project lớn thành các module nhỏ. Từ đó cho phép làm việc đồng thời trên các module khác nhau, đồng thời vẫn tạo được tính thống nhất. Không phụ thuộc vào IDE. Cho phép chuyển đổi tử Eclipse sang NetBeans,.. một cách dễ dàng. Maven hỗ trợ một số command để tạo ra project tương thích với IDE muốn sử dụng (ví dụ: mvn eclipse:eclipse – để tạo project với eclipse). Một số Maven command Maven hỗ trợ khá nhiều câu lệnh tùy vào mục đích sử dụng. Maven complie Lần đầu tiên thực thi command này, maven sẽ download toàn bộ các pluins và các dependencies liên quan. Nếu chúng ta thực thi lại lệnh này, maven sẽ không download lại những gì nó đã có từ lần trước, vậy nên command sẽ được thực thi nhanh hơn. Các D:nthienanmusic-manager-client>mvn compile [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building MusicManagerClient Maven Webapp 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] Nothing to compile - all classes are up to date [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1.738s [INFO] Finished at: 2015-03-17T22:20:37+07:00 [INFO] Final Memory: 6M/109M [INFO] ------------------------------------------------------------------------
  • 92. 80 class được compile sẽ được đưa vào ${basedir}/target/classes. Với maven vẫn còn vài lỗi phát sinh, nếu trong quá trình download các gói thư viện được định nghĩa trong pom.xml nhưng phát sinh lỗi do sự cố mạng hay một lỗi nào đó mà gói không được tải trọn vẹn, thì ở lần build sau khi maven tìm thấy gói trong repo trên máy lúc ấy maven sẽ dùng gói đó hỗ trợ build và việc build sẽ faild, trong trường hợp này cần phải tìm đến gói đó và xóa nó đi, thực hiện build lại nếu trong quá trình download lại gói đó không phát sinh lỗi thì build sẽ thành công. Maven package Được dùng khi muốn export project ra 1 gói jar để cho người khác sử dụng. Được định nghĩa trong pom.xml, nếu được định nghĩa jar thì khi export ra gói .jar, nếu không mặc định là .war (web app) Maven install Với command “mvn package” gói jar chỉ được export ra ${basedir}/target, nếu muốn gói jar ấy được đưa lên repo và các project các có thể dependency tới thì cần sử dụng lệnh “mvn install”. D:nthienanmusic-manager-client>mvn package [INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [INFO] Building MusicManagerClient Maven Webapp 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] --- maven-war-plugin:2.2:war (default-war) @ MusicManagerClient --- [INFO] Packaging webapp [INFO] Assembling webapp [MusicManagerClient] in [ D:nthienanmusic-manager- clienttargetROOT] [INFO] Processing war project [INFO] Copying webapp resources [ D:nthienanmusic-manager- clientsrcmainwebapp] [INFO] Webapp assembled in [1062 msecs] [INFO] Building war: D:nthienanmusic-manager-clienttargetROOT.war [INFO] WEB-INFweb.xml already added, skipping [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 17.687 s [INFO] Finished at: 2015-03-17T22:29:42+07:00 [INFO] Final Memory: 24M/269M [INFO] ------------------------------------------------------------------------
  • 93. 81 D:nthienanmusic-manager-client>mvn install [INFO] Scanning for projects... [INFO] --- maven-install-plugin:2.4:install (default-install) @ MusicManagerClient --- [INFO] Installing D:nthienanmusic-manager-clienttargetROOT.war to C:Usersntan.m2repositoryaguthesis2015MusicManagerClient1 .0-SNAPSHOTMusicManagerClient-1.0-SNAPSHOT.war [INFO] Installing D:nthienanmusic-manager-clientpom.xml to C:Usersntan.m2repositoryaguthesis2015MusicManagerClient1.0-SNAPS HOTMusicManagerClient-1.0-SNAPSHOT.pom [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 44.982 s [INFO] Finished at: 2015-03-17T22:41:14+07:00 [INFO] Final Memory: 24M/252M [INFO] ------------------------------------------------------------------------