UBND T Ỉ NH QU Ả NG NAM TRƯ Ờ NG Đ Ạ I H Ọ C QU Ả NG NAM KHOA: TOÁN – TIN ----- ----- PH Ạ M PHÚ HUY NGHIÊN C Ứ U CÔNG C Ụ PHÁT TRI Ể N HƯ Ớ NG D Ị CH V Ụ WCF TRONG C# Đ Ể XÂY D Ự NG PH Ầ N M Ề M QU Ả N LÝ KHÁCH S Ạ N KHÓA LU Ậ N T Ố T NGHI Ệ P Đ Ạ I H Ọ C Qu ả ng Nam, tháng 0 5 năm 2022 UBND T Ỉ NH QU Ả NG NAM TRƯ Ờ NG Đ Ạ I H Ọ C QU Ả NG NAM KHOA: TOÁN – TIN ----- ----- KHÓA LU Ậ N T Ố T NGHI Ệ P Đ Ạ I H Ọ C Tên đ ề tài: NGHIÊN C Ứ U CÔNG C Ụ PHÁT TRI Ể N HƯ Ớ NG D Ị CH V Ụ WCF TRONG C# Đ Ể XÂY D Ự NG PH Ầ N M Ề M QU Ả N LÝ KHÁCH S Ạ N Sinh viên th ự c hi ệ n PH Ạ M PHÚ HUY MSSV: 2118100112 CHUYÊN NGÀNH: CÔNG NGH Ệ THÔNG TIN KHÓA 20 18 – 20 22 Cán b ộ hư ớ ng d ẫ n ThS Nguy ễ n Th ị Minh Châu MSCB: ……… Qu ả ng Nam, tháng 05 năm 20 22 M Ụ C L Ụ C Ph ầ n 1 PH Ầ N M Ở Đ Ầ U 1 1 Lý do ch ọ n đ ề tài 1 2 M ụ c tiêu c ủ a đ ề tài 1 3 Đ ố i tư ợ ng và ph ạ m vi nghiên c ứ u 2 4 Phương pháp nghiên c ứ u 2 5 L ị ch s ử nghiên c ứ u 2 6 Đóng góp c ủ a đ ề tài 2 7 C ấ u trúc đ ề tài 2 Ph ầ n 2 PH Ầ N N Ộ I DUNG 4 Chương 1: T Ổ NG QUAN V Ề L Ậ P TRÌNH SOCKET VÀ MÃ HÓA BÍ M Ậ T TRONG C# 4 1 1 T ổ ng quan v ề mô hình Client/Server 4 1 1 1 Khái ni ệ m mô hình Client/Server 4 1 1 2 Nguyên t ắ c ho ạ t đ ộ ng c ủ a mô hình Client/Server 5 1 1 2 1 Client 5 1 1 2 2 Server 5 1 1 3 Ưu và như ợ c đi ể m c ủ a mô hình Client/Server 5 1 1 3 1 Ưu đi ể m 5 1 1 3 2 Như ợ c đi ể m 6 1 2 L ậ p trình Client/Server v ớ i Socket trong C# 7 1 2 1 Gi ớ i thi ệ u v ề Socket 7 1 2 2 S ố hi ệ u c ổ ng c ủ a Socket 8 1 2 3 Xây d ự ng ứ ng d ụ ng Client/Server v ớ i Socket 9 1 2 3 1 Mô hình Client/Server s ử d ụ ng socket ở ch ế đ ộ có k ế t n ố i (TCP) 9 1 2 3 2 Mô hình Client/Server s ử d ụ ng socket ở ch ế đ ộ không k ế t n ố i (UDP) 10 1 2 4 L ậ p trình Socket trong C# 11 1 3 Mã hóa bí m ậ t 13 1 3 1 Gi ớ i thi ệ u v ề b ả o m ậ t thông tin 13 1 3 2 Gi ớ i thi ệ u v ề mã hóa thông tin 13 1 3 3 Mã hóa bí m ậ t 14 1 3 4 Mã hóa bí m ậ t trong C# 14 Chương 2: GI Ớ I THI Ệ U V Ề KI Ế N TRÚC HƯ Ớ NG D Ị CH V Ụ SOA VÀ CÔNG C Ụ PHÁT TRI Ể N HƯ Ớ NG D Ị CH V Ụ WCF 16 2 1 Gi ớ i thi ệ u v ề ki ế n trúc hư ớ ng d ị ch v ụ SOA 16 2 1 1 M ộ t s ố khái ni ệ m 16 2 1 1 1 Service 16 2 1 1 2 Hư ớ ng Service 17 2 1 1 3 Ki ế n trúc hư ớ ng d ị ch v ụ SOA 1 7 2 1 1 4 Ki ế n trúc t ổ ng th ể SOA 18 2 1 2 Nh ữ ng đ ặ c đi ể m và l ợ i ích c ủ a SOA 19 2 1 2 1 Các đ ặ c đi ể m c ủ a SOA 19 2 1 2 2 L ợ i ích c ủ a SOA 20 2 1 3 Tính ch ấ t c ủ a SOA 20 2 1 3 1 K ế t n ố i l ỏ ng l ẻ o 20 2 1 3 2 Tái s ử d ụ ng d ị ch v ụ 21 2 1 3 3 Qu ả n lý chính sách 22 2 1 3 4 T ự đ ộ ng dò tìm và ràng bu ộ c đ ộ ng 22 2 1 3 5 Kh ả năng t ự h ồ i ph ụ c 23 2 1 4 Ưu và như ợ c đi ể m c ủ a SOA 24 2 1 4 1 Ưu đi ể m 24 2 1 4 2 Như ợ c đi ể m 24 2 2 Công c ụ phát tri ể n hư ớ ng d ị ch v ụ WCF 25 2 2 1 Khái ni ệ m 25 2 2 2 T ạ i sao l ạ i s ử d ụ ng WCF 25 2 2 3 Ki ế n trúc WCF 26 2 2 3 1 Contracts 26 2 2 3 2 Runtime service 27 2 2 3 3 Message 28 2 2 3 4 Host và activation 28 2 2 4 Các tính năng c ủ a WCF 29 2 2 4 1 Transaction 29 2 2 4 2 Host 29 2 2 4 3 B ả o m ậ t 29 2 2 5 Công c ụ phát tri ể n v ớ i WCF 30 Chương 3: KH Ả O SÁT VÀ PHÂN TÍCH H Ệ TH Ố NG 31 3 1 Kh ả o sát h ệ th ố ng 31 3 1 1 Mô t ả bài toán 31 3 1 2 Yêu c ầ u ch ứ c năng 31 3 1 3 Mô hình Ri 32 3 1 4 Đ ặ c tính t ừ ng ngư ờ i dùng 34 3 1 5 Yêu c ầ u phi ch ứ c năng 35 3 2 Phân tích h ệ th ố ng 35 3 2 1 Phân tích ch ứ c năng 35 3 2 1 1 Actor 35 3 2 1 2 Usecase 36 3 2 1 3 Object và class 44 3 2 1 4 Sơ đ ồ tu ầ n t ự 45 3 2 1 5 Sơ đ ồ c ộ ng tác 51 3 2 1 6 Sơ đ ồ tr ạ ng thái 55 3 2 1 7 Sơ đ ồ ho ạ t đ ộ ng 59 3 2 2 Phân tích d ữ li ệ u 65 3 2 2 1 Sơ đ ồ E – R 65 3 2 2 2 Sơ đ ồ d ữ li ệ u quan h ệ 66 Chương 4: THI Ế T K Ế VÀ TRI Ể N KHAI H Ệ TH Ố NG 67 4 1 Thi ế t k ế h ệ th ố ng 67 4 1 1 Thi ế t k ế cơ s ở d ữ li ệ u 67 4 1 2 Thi ế t k ế ch ứ c năng 71 4 1 3 Thi ế t k ế giao di ệ n 73 4 2 Tri ể n khai h ệ th ố ng 74 4 2 1 M ộ t s ố đo ạ n code quan tr ọ ng 74 4 2 2 M ộ t s ố giao di ệ n c ủ a ph ầ n m ề m 75 Ph ầ n 3 PH Ầ N K Ế T LU Ậ N VÀ KI Ế N NGH Ị 79 Ph ầ n 4 TÀI LI Ệ U THAM KH Ả O 80 DANH M Ụ C HÌNH Ả NH Hình 1 1 Mô hình Client/Server 4 Hình 1 2 Mô hình Socket 7 Hình 1 3 C ổ ng trong Socket 8 Hình 1 4 Mô hình Client/Server s ử d ụ ng Socket ở ch ế đ ộ có k ế t n ố i (TCP) 9 Hình 1 5 Mô hình Client/Server s ử d ụ ng socket ở ch ế đ ộ không k ế t n ố i (UDP) 10 Hình 1 6 Lập trình Socket trong C# 13 Hình 2 1 Mô t ả đ ị nh nghĩa Service 16 Hình 2 2 Các thành ph ầ n trong đ ị nh nghĩa c ủ a SOA 18 Hình 2 3 Ki ế n trúc t ổ ng t ổ ng SOA 19 Hình 2 4 K ế t n ố i l ỏ ng l ẻ o 21 Hình 2 5 Ki ế n trúc WCF 26 Hình 3 1 Sơ đ ồ usecase t ổ ng quát 36 Hình 3 2 Sơ đ ồ class 45 Hình 3 3 Sơ đ ồ tu ầ n t ự UC_Đăng nh ậ p 45 Hình 3 4 Sơ đ ồ tu ầ n t ự UC_Thêm nhân viên 46 Hình 3 5 Sơ đ ồ tu ầ n t ự UC_Tìm ki ế m nhân viên 46 Hình 3 6 Sơ đ ồ tu ầ n t ự UC_C ậ p nh ậ p thông tin nhân viên 47 Hình 3 7 Sơ đ ồ tu ầ n t ự UC_Xóa nhân viên 47 Hình 3 8 Sơ đ ồ tu ầ n t ự UC_Đ ặ t phòng 48 Hình 3 9 Sơ đ ồ tu ầ n t ự UC_Thuê phòng 48 Hình 3 10 Sơ đ ồ tu ầ n t ự UC_Tr ả phòng 49 Hình 3 11 Sơ đ ồ tu ầ n t ự UC_G ọ i d ị ch v ụ 49 Hình 3 12 Sơ đ ồ tu ầ n t ự UC_C ậ p nh ậ p d ị ch v ụ 50 Hình 3 13 Sơ đ ồ tu ầ n t ự UC_H ủ y d ị ch v ụ 50 Hình 3 14 Sơ đ ồ tu ầ n t ự UC_Báo cáo lương nhân viên 51 Hình 3 15 Sơ đ ồ c ộ ng tác UC_Đăng nh ậ p 51 Hình 3 16 Sơ đ ồ c ộ ng tác UC_Thêm nhân viên 51 Hình 3 17 Sơ đ ồ c ộ ng tác UC_Tìm ki ế m nhân viên 52 Hình 3 18 Sơ đ ồ c ộ ng tác UC_C ậ p nh ậ p thông tin nhân viên 52 Hình 3 19 Sơ đ ồ c ộ ng tác UC_Xóa nhân viên 52 Hình 3 20 Sơ đ ồ c ộ ng tác UC_Đ ặ t phòng 53 Hình 3 21 Sơ đ ồ c ộ ng tác UC_Thuê phòng 53 Hình 3 22 Sơ đ ồ c ộ ng tác UC_Tr ả phòng 53 Hình 3 23 Sơ đ ồ c ộ ng tác UC_G ọ i d ị ch v ụ 54 Hình 3 24 Sơ đ ồ c ộ ng tác UC_C ậ p nh ậ p d ị ch v ụ 54 Hình 3 25 Sơ đ ồ c ộ ng tác UC_H ủ y d ị ch v ụ đã g ọ i 54 Hình 3 26 Sơ đ ồ c ộ ng tác UC_Báo cáo lương nhân viên 55 Hình 3 27 Sơ đ ồ tr ạ ng thái class ngư ờ i dùng 55 Hình 3 28 Sơ đ ồ tr ạ ng thái class nhân viên 55 Hình 3 29 Sơ đ ồ tr ạ ng thái class thi ế t b ị 56 Hình 3 30 Sơ đ ồ tr ạ ng thái class đơn v ị cung c ấ p 56 Hình 3 31 Sơ đ ồ tr ạ ng thái class d ị ch v ụ 56 Hình 3 32 Sơ đ ồ tr ạ ng thái class phòng 57 Hình 3 33 Sơ đ ồ tr ạ ng thái class lo ạ i phòng 57 Hình 3 34 Sơ đ ồ tr ạ ng thái class khách hàng 57 Hình 3 35 Sơ đ ồ tr ạ ng thái class hóa đơn nh ậ p 58 Hình 3 36 Sơ đ ồ tr ạ ng thái class phi ế u đ ặ t phòng 58 Hình 3 37 Sơ đ ồ tr ạ ng thái class hóa đơn thuê 58 Hình 3 38 Sơ đ ồ ho ạ t đ ộ ng UC_Đăng nh ậ p 59 Hình 3 39 Sơ đ ồ ho ạ t đ ộ ng UC_Thêm nhân viên 59 Hình 3 40 Sơ đ ồ ho ạ t đ ộ ng UC_Tìm ki ế m nhân viên 60 Hình 3 41 Sơ đ ồ ho ạ t đ ộ ng UC_C ậ p nh ậ p thông tin nhân viên 60 Hình 3 42 Sơ đ ồ ho ạ t đ ộ ng UC_Xóa nhân viên 61 Hình 3 43 Sơ đ ồ ho ạ t đ ộ ng UC_Đ ặ t phòng 61 Hình 3 44 Sơ đ ồ ho ạ t đ ộ ng UC_Thuê phòng 62 Hình 3 45 Sơ đ ồ ho ạ t đ ộ ng UC_Tr ả phòng 62 Hình 3 46 Sơ đ ồ ho ạ t đ ộ ng UC_G ọ i d ị ch v ụ 63 Hình 3 47 Sơ đ ồ ho ạ t đ ộ ng UC_C ậ p nh ậ p d ị ch v ụ 63 Hình 3 48 Sơ đ ồ ho ạ t đ ộ ng UC_C ậ p nh ậ p d ị ch v ụ đã g ọ i 64 Hình 3 49 Sơ đ ồ ho ạ t đ ộ ng UC_Báo cáo lươn g nhân viên 64 Hình 3 50 Sơ đ ồ E – R 65 Hình 3 51 Sơ đ ồ d ữ li ệ u quan h ệ 66 Hình 4 1 M ố i quan h ệ gi ữ a các b ả ng trong cơ s ở d ữ li ệ u 71 Hình 4 2 Giao di ệ n h ộ p tho ạ i 73 Hình 4 3 Giao di ệ n nh ậ p d ữ li ệ u d ạ ng đi ề n 73 Hình 4 4 Giao di ệ n nh ậ p d ữ li ệ u d ạ ng tùy ch ọ n 73 Hình 4 5 Giao di ệ n bi ể u m ẫ u d ạ ng b ả ng 73 Hình 4 6 Giao di ệ n bi ể u m ẫ u d ạ ng bi ể u đ ồ 74 Hình 4 7 Code t ạ o service WCF trong C# theo giao th ứ c HTTP 74 Hình 4 8 Code Client truy c ậ p service WCF trong C# theo giao th ứ c HTTP 74 Hình 4 9 Code x ử lý đa lu ồ ng c ủ a Socket trong C# 75 Hình 4 10 Giao di ệ n form đăng nh ậ p 75 Hình 4 11 Giao di ệ n form h ệ th ố ng 76 Hình 4 12 Giao di ệ n form h ệ th ố ng 76 Hình 4 13 Giao di ệ n form thuê/đ ặ t phòng 7 7 Hình 4 14 Giao di ệ n form thuê/đ ặ t phòng 77 Hình 4 15 Giao di ệ n form g ọ i d ị ch v ụ 78 Hình 4 16 Giao di ệ n form báo cáo/th ố ng kê 78 CÁC T Ừ VI Ế T T Ắ T STT T ừ vi ế t t ắ t T ừ hoàn ch ỉ nh 1 API Application Programming Interface 2 CNTT Công Ngh ệ Thông Tin 3 IIS Internet Information Services 4 SOA Service Oriented Architecture 5 SOAP Service Oriented Architecture Protocol 6 TTTN Th ự c T ậ p T ố t Nghi ệ p 7 WAS Windows Activation Services 8 WCF Windows Communication Foudation L Ờ I C Ả M ƠN Trong su ố t quá trình làm khóa lu ậ n t ố t nghi ệ p c ủ a mình, tôi luôn đư ợ c s ự quan tâm giúp đ ỡ t ậ n tình đ ế n t ừ cô T h S Nguy ễ n Th ị Minh Châu , chính s ự giúp đ ỡ t ậ n tình ấ y đã giúp tôi hoàn thành t ố t khóa lu ậ n này Tôi xin g ử i l ờ i c ả m ơn chân thành và sâu s ắ c nh ấ t đ ế n cô ! Tôi xin chân thành c ả m ơn quý th ầ y giáo, cô giáo khoa Toán – Tin , trư ờ ng Đ ạ i h ọ c Qu ả ng Nam đã t ậ n tình dìu d ắ t và truy ề n đ ạ t ki ế n th ứ c cho tôi trong su ố t 4 năm h ọ c v ừ a qua 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 qúy báu đ ể tôi bư ớ c vào đ ờ i m ộ t cách v ữ ng ch ắ c và t ự tin Xin chân thành c ả m ơ n gia đình, b ạ n bè đã là ch ỗ d ự a v ữ ng ch ắ c, giúp tôi t ự tin hơn trong quá trình h ọ c t ậ p Trong quá trình làm bài khóa lu ậ n t ố t nghi ệ p này do trình đ ộ còn h ạ n h ẹ p, đ ề tài r ộ ng, th ờ i gian có h ạ n, khó tránh kh ỏ i sai sót, kính mong quý th ầ y cô giáo góp ý ki ế n đ ể tôi có th ể h ọ c h ỏ i thêm nhi ề u kinh nghi ệ m Xin chân thành c ả m ơn! 1 Phần 1 PH Ầ N M Ở Đ Ầ U 1 Lý do ch ọ n đ ề tài Trong nh ữ ng năm g ầ n đây du l ị ch là m ộ t trong nh ữ ng ngành có đ ộ tăng trư ở ng cao nh ấ t c ả nư ớ c R ấ t nhi ề u khách s ạ n đua nhau phát tri ể n liên t ụ c và nhanh chóng theo s ự phát tri ể n c ủ a xã h ộ i v ề quy mô và ch ấ t lư ợ ng Hi ệ n nay, các khách s ạ n ph ả i tr ự c ti ế p ti ế p nh ậ n, qu ả n lý m ộ t kh ố i lư ợ ng l ớ n và thư ờ ng xuyên nhi ề u lo ạ i khách, cùng v ớ i hàng lo ạ t d ị ch v ụ phát sinh theo nhu c ầ u c ủ a khách hàng Do đó, công vi ệ c qu ả n lý ho ạ t đ ộ ng kinh doanh c ủ a khách s ạ n ngày càng ph ứ c t ạ p hơn Hơn n ữ a, công tác qu ả n lý không ch ỉ đơn thu ầ n là qu ả n lý v ề lưu lư ợ ng khách đ ế n v ớ i khách s ạ n, s ử d ụ ng các lo ạ i hình d ị ch v ụ ,… mà công vi ệ c qu ả n lý còn ph ả i đáp ứ ng nhu c ầ u v ề vi ệ c báo cáo các lo ạ i hình doanh thu, tình hình kinh doanh c ủ a khách s ạ n,… đ ể t ừ đó có th ể đưa ra đ ị nh hư ớ ng và l ậ p k ế ho ạ ch phát tri ể n cho công vi ệ c kinh doanh đó Nhưng v ớ i vi ệ c lưu tr ữ và x ử lý b ằ ng th ủ công như hi ệ n nay thì s ẽ t ố n r ấ t nhi ề u th ờ i g ian và nhân l ự c mà không đem l ạ i hi ệ u qu ả cao Do đó c ầ n ph ả i tin h ọ c hóa hình th ứ c qu ả n lý, c ụ th ể là xây d ự ng m ộ t ph ầ n m ề m đ ể đáp ứ ng nhu c ầ u qu ả n lý toàn di ệ n, th ố ng nh ấ t và đ ạ t hi ệ u qu ả cao nh ấ t cho ho ạ t đ ộ ng kinh doanh c ủ a khách s ạ n Do nh ữ ng nhu c ầ u trên nên em quy ế t đ ị nh ch ọ n đ ề tài: “Nghiên c ứ u công c ụ phát tri ể n hư ớ ng d ị ch v ụ WCF trong C# đ ể xây d ự ng ph ầ n m ề m qu ả n lý khách s ạ n” làm đ ề tài khóa lu ậ n t ố t nghi ệ p c ủ a mình Xây d ự ng ph ầ n m ề m qu ả n lý khách s ạ n là m ộ t đi ề u thi ế t y ế u đáp ứ ng nhu c ầ u ứ ng d ụ ng công ngh ệ thông tin vào qu ả n lý, kinh doanh c ủ a khách s ạ n, qu ả n lý khách s ạ n như là m ộ t chính y ế u cho nhu c ầ u ứ ng d ụ ng công ngh ệ thông tin vào kinh doanh 2 M ụ c tiêu c ủ a đ ề tài Tìm hi ể u v ề l ậ p trình socket và mã hóa bí m ậ t trong C# Nghiên c ứ u công c ụ phát tri ể n hư ớ ng d ị ch v ụ WCF trong C# Phân tích thi ế t k ế h ệ th ố ng theo hư ớ ng đ ố i tư ợ ng Xây d ự ng ph ầ n m ề m qu ả n lý khách s ạ n d ự a trên WCF 2 3 Đ ố i tư ợ ng và ph ạ m vi nghiên c ứ u Công c ụ phát tri ể n hư ớ ng d ị ch v ụ WCF trong C# Phân tích h ệ th ố ng ph ầ n m ề m qu ả n lý khá ch s ạ n theo hư ớ ng đ ố i tư ợ ng L ậ p trình ph ầ n m ề m qu ả n lý khách s ạ n b ằ ng công c ụ phát tri ể n hư ớ ng d ị ch v ụ WCF trong C# 4 Phương pháp nghiên c ứ u Phương pháp ph ỏ ng v ấ n Phương pháp kh ả o sát Phương pháp phân tích h ệ th ố ng thông tin theo hư ớ ng đ ố i tư ợ ng Phương pháp ứ ng d ụ ng 5 L ị ch s ử nghiên c ứ u Trư ớ c đây, đã có r ấ t nhi ề u đ ề tài nghiên c ứ u v ề v ấ n đ ề này, ch ẳ ng h ạ n: Báo cáo Qu ả n lý khách s ạ n c ủ a Nguy ễ n Th ị Thương Báo cáo bài t ậ p l ớ n Qu ả n lý khách s ạ n c ủ a Tr ầ n Tư ờ ng Tu ấ n, Trư ờ ng Cao đ ẳ ng Ngô Gia T ự , B ắ c Giang Tuy nhiên, t ấ t c ả các đ ề tài đó ch ỉ d ừ ng ở vi ệ c phân tích và thi ế t k ế h ệ th ố ng theo hư ớ ng đ ố i tư ợ ng chưa có s ử d ụ ng công c ụ phát tri ể n hư ớ ng d ị ch v ụ WCF 6 Đóng góp c ủ a đ ề tài Đ ề tài có th ể giúp cho các b ạ n đ ọ c hi ể u rõ hơn v ề công c ụ phát tri ể n hư ớ ng d ị ch v ụ WCF và ứ ng d ụ ng xây d ự ng ph ầ n m ề m qu ả n lý khách s ạ n 7 C ấ u trúc đ ề tài PH Ầ N 1 M Ở Đ Ầ U PH Ầ N 2 N Ộ I DUNG NGHIÊN C Ứ U Chương 1: T ổ ng quan v ề l ậ p trình socket và mã hóa bí m ậ t trong C# Chương 2: Gi ớ i thi ệ u v ề ki ế n trúc hư ớ ng d ị ch v ụ SOA và công c ụ phát tri ể n hư ớ ng d ị ch v ụ WCF Chương 3: Kh ả o sát và phân tích h ệ th ố ng Chương 4: Thi ế t k ế và tri ể n khai h ệ th ố ng 3 PH Ầ N 3 K Ế T LU Ậ N VÀ KI Ế N NGH Ị PH Ầ N 4 TÀI LI Ệ U THAM KH Ả O 4 Phần 2 PH Ầ N N Ộ I DUNG Chương 1: T Ổ NG QUAN V Ề L Ậ P TRÌNH SOCKET VÀ MÃ HÓA BÍ M Ậ T TRONG C# 1 1 T ổ ng quan v ề mô hình Client/Server 1 1 1 Khái ni ệ m mô hình Client/Server Client /S erver là mô hình m ạ ng máy tính g ồ m có 2 thành ph ầ n chính đó là máy khách ( C lient) và máy ch ủ ( S erver) Server chính là nơi giúp lưu tr ữ tài nguyên cũng như cài đ ặ t các chương trình d ị ch v ụ theo đúng như yêu c ầ u c ủ a C lient Ngư ợ c l ạ i, Client bao g ồ m máy tính cũng như các lo ạ i thi ế t b ị đi ệ n t ử nói chung s ẽ ti ế n hành g ử i yêu c ầ u đ ế n S erver Hình 1 1 Mô hình Client/Server Mô hình m ạ ng Client / Server s ẽ cho phép m ạ ng t ậ p trung các ứ ng d ụ ng có cùng ch ứ c năng t ạ i m ộ t ho ặ c nhi ề u d ị ch v ụ file chuyên d ụ ng Chúng s ẽ tr ở thành trung tâm c ủ a h ệ th ố ng H ệ đi ề u hành c ủ a mô hình Client /S erver s ẽ cho phép ngư ờ i dùng chia s ẻ đ ồ ng th ờ i cùng m ộ t lo ạ i tài nguyên mà không gi ớ i h ạ n v ị trí đ ị a lý 5 1 1 2 Nguyên t ắ c ho ạ t đ ộ ng c ủ a mô hình Client/Server 1 1 2 1 Client Ngư ờ i dùng đưa ra yêu c ầ u t ạ i Client Máy Client ch ạ y m ộ t chương trình ứ ng d ụ ng có ch ứ c năng : - Cung c ấ p giao di ệ n cho ngư ờ i dùng - Đ ị nh d ạ ng yêu c ầ u cung c ấ p d ữ li ệ u - Hi ể n th ị d ữ li ệ u nó nh ậ n l ạ i t ừ máy Server Trong môi trư ờ ng C lient/Server, máy Server không ch ứ a ph ầ n m ề m giao di ệ n ngư ờ i dùng Máy Client có nhi ệ m v ụ trình bày d ữ li ệ u theo hình th ứ c h ữ u ích Ch ẳ ng h ạ n v ớ i giao di ệ n ngư ờ i dùng và l ậ p báo bi ể u Chương trình ứ ng d ụ ng trên máy Server ti ế p nh ậ n nh ữ ng ch ỉ th ị t ừ ngư ờ i d ùng, chu ẩ n b ị chúng cho máy Server, r ồ i g ở i m ộ t yêu c ầ u cung c ấ p thông tin c ụ th ể đ ế n máy Server Máy Server x ử lý yêu c ầ u, đ ị nh v ị thông tin tích h ợ p, r ồ i g ở i thông tin tìm đư ợ c qua m ạ ng đ ế n máy Client Máy Client sau đó s ẽ “đ ẩ y” thông tin ra giao di ệ n đ ể hi ể n th ị thông tin trư ớ c ngư ờ i dùng 1 1 2 2 Server Máy Server trong môi trư ờ ng Client/Server chuyên dùng đ ể lưu tr ữ và qu ả n lý d ữ li ệ u Đây là nơi x ả y ra h ầ u h ế t ho ạ t đ ộ ng th ự c c ủ a cơ s ở d ữ li ệ u Máy Server ti ế p nh ậ n các yêu c ầ u có c ấ u trúc t ừ phía máy Client, x ử lý chúng, r ồ i g ử i tr ả thông tin đư ợ c yêu c ầ u và tr ở l ạ i máy Client qua m ạ ng 1 1 3 Ưu và như ợ c đi ể m c ủ a mô hình Client/Server 1 1 3 1 Ưu đi ể m - T ậ p trung: Ưu đi ể m đ ầ u tiên c ủ a mô hình Client / Server ki ể u m ạ ng khách ch ủ đó chính là kh ả năng ki ể m soát t ậ p trung (Centralization) đã đư ợ c tích h ợ p s ẵ n Theo như mô hình này thì t ấ t c ả m ọ i thông tin c ầ n thi ế t đ ề u s ẽ đư ợ c đ ặ t ở m ộ t v ị trí duy nh ấ t Đây là m ộ t ưu đi ể m vô cùng h ữ u ích đư ợ c nh ữ ng ngư ờ i qu ả n tr ị viên m ạ ng yêu thích b ở i vì h ọ có th ể toàn quy ề n qu ả n lý cũng như đi ề u hành m ọ i vi ệ c Tính năng này giúp cho m ọ i s ự c ố trong m ạ ng đ ề u s ẽ đư ợ c gi ả i quy ế t ở cùng m ộ t nơi th ố ng nh ấ t Đ ồ ng th ờ i, vi ệ c c ậ p nh ậ t cơ s ở tài nguyên, d ữ li ệ u cũng s ẽ d ễ dàng hơn r ấ t nhi ề u 6 - B ả o m ậ t: Trong m ạ ng Client / Server, t ấ t c ả các d ữ li ệ u đ ề u s ẽ đư ợ c b ả o v ệ m ộ t cách t ố i đa nh ờ vào h ệ th ố ng ki ế n trúc t ậ p trung c ủ a m ạ ng Thông qua đó, nó s ẽ giúp ngư ờ i dùng ki ể m soát truy c ậ p đ ể ch ỉ có nh ữ ng ai đư ợ c c ấ p quy ề n truy c ậ p thì m ớ i đư ợ c th ự c hi ệ n các thao tác c ầ n thi ế t Mu ố n làm như v ậ y, chúng ta c ầ n ph ả i áp đ ặ t thông tin đăng nh ậ p cũng như Username hay Password Bên c ạ nh đó, n ế u d ữ li ệ u c ủ a chúng ta b ị m ấ t thì các file s ẽ đư ợ c khôi ph ụ c m ộ t cách vô cùng d ễ dàng ch ỉ t ừ m ộ t b ả n sao lưu duy nh ấ t mà thôi - Kh ả năng m ở r ộ ng: Mô hình m ạ ng k ế t n ố i Client / Serv er có kh ả năng m ở r ộ ng vô cùng t ố t Ch ỉ c ầ n ngư ờ i dùng c ầ n s ử d ụ ng b ấ t c ứ lúc nào thì h ọ cũng có th ể tăng đư ợ c s ố lư ợ ng tài nguyên c ủ a mình Ví d ụ như s ố Client ho ặ c Server Nh ờ đó mà chúng ta có th ể tăng kích thư ớ c c ủ a Server m ộ t cách d ễ dàng mà không b ị gián đo ạ n nhi ề u - Kh ả năng truy c ậ p: Hoàn toàn không h ề có s ự phân bi ệ t gi ữ a các v ị trí hay n ề n t ả ng v ớ i nhau T ấ t c ả m ọ i Client đ ề u có kh ả năng đăng nh ậ p đư ợ c vào h ệ th ố ng m ạ ng máy tính Đi ề u này s ẽ giúp cho t ấ t c ả các nhân viên đ ề u có th ể truy c ậ p thông t in c ủ a công ty m ộ t cách d ễ dàng mà không c ầ n ph ả i dùng m ộ t terminal mode ho ặ c m ộ t b ộ x ử lý nào khác 1 1 3 2 Như ợ c đi ể m - T ắ c ngh ẽ n lưu lư ợ ng: Nói v ề như ợ c đi ể m l ớ n nh ấ t c ủ a mô hình m ạ ng Client/Server đó chính là t ắ c ngh ẽ n lưu lư ợ ng Trong trư ờ ng h ợ p có quá nhi ề u Cl ient t ạ o request t ừ cùng m ộ t Server thì nó có th ể s ẽ làm cho k ế t n ố i ch ậ m hơn Trong trư ờ ng h ợ p x ấ u nh ấ t còn có th ể xu ấ t hi ệ n hi ệ n tư ợ ng crash Khi m ộ t Server b ị quá t ả i thì s ẽ t ạ o ra nhi ề u v ấ n đ ề khi truy c ậ p thông tin - Đ ộ b ề n: Client/Server là m ạ ng t ậ p t rung chính vì th ế , khi Server chính x ả y ra s ự c ố ho ặ c b ị nhi ễ u thì cũng đ ồ ng nghĩa v ớ i vi ệ c toàn b ộ h ệ th ố ng m ạ ng s ẽ b ị gián đo ạ n Như v ậ y, b ạ n c ầ n chú ý đó là m ạ ng thi ế u tính ổ n đ ị nh và đ ộ b ề n B ạ n c ầ n chú ý khi th ự c hi ệ n - Chi phí: Chi phí đư ợ c s ử d ụ ng đ ể thi ế t l ậ p và b ả o trì Server trong Client/Server thư ờ ng s ẽ khá cao Lý do là vì các h ệ th ố ng m ạ ng có s ứ c m ạ nh r ấ t 7 l ớ n cũng đ ồ ng nghĩa v ớ i vi ệ c giá đ ể chi cho vi ệ c này là r ấ t đ ắ t Chính vì v ậ y, không ph ả i ai cũng có kh ả năng chi tr ả và s ử d ụ ng - B ả o trì: Khi các Server th ự c hi ệ n tri ể n khai đ ể làm vi ệ c thì nó cũng s ẽ ho ạ t đ ộ ng m ộ t cách không ng ừ ng ngh ỉ Đi ề u này đ ồ ng nghĩa v ớ i vi ệ c chúng ta c ầ n ph ả i quan tâm đ ế n vi ệ c b ả o trì h ệ th ố ng đúng m ứ c Khi x ả y ra b ấ t c ứ v ấ n đ ề gì cũng c ầ n ph ả i gi ả i quy ế t ngay l ậ p t ứ c V ậ y nên, c ầ n ph ả i có m ộ t nhà qu ả n lý m ạ ng chuyên bi ệ t đ ể ti ế n hành duy trì ho ạ t đ ộ ng c ủ a Server khi chúng đư ợ c đưa vào và s ử d ụ ng - Tài nguyên: M ộ t đi ề u mà chúng ta r ấ t c ầ n ph ả i lưu ý đó chính là không ph ả i t ấ t c ả tài nguyên hi ệ n có trên Server đ ề u s ử d ụ ng đư ợ c Ví d ụ m ộ t cách đơn gi ả n đó chính là chúng ta không th ể in tr ự c ti ế p đư ợ c tài li ệ u t ừ trên web cũng như ti ế n hành ch ỉ nh s ử a b ấ t k ỳ m ộ t thông tin nào trên ổ c ứ ng c ủ a Client c ả 1 2 L ậ p trình Client/Server v ớ i S ocket trong C# 1 2 1 Gi ớ i thi ệ u v ề S ocket Socket là m ộ t giao di ệ n l ậ p trình ứ ng d ụ ng (API – Application Programming Interface) Nó đư ợ c gi ớ i thi ệ u l ầ n đ ầ u tiên trong ấ n b ả n UNIX – BSD 4 2 dư ớ i d ạ ng các hàm h ệ th ố ng theo cú pháp ngôn ng ữ C (socket(), bind(), connect(), send(), receive(), read(), write(), clo se(), ) Ngày nay, Socket đư ợ c h ỗ tr ợ trong h ầ u h ế t các h ệ đi ề u hành như MS Windows, Linux và đư ợ c s ử d ụ ng trong nhi ề u ngôn ng ữ l ậ p trình khác nhau: như C, C++, Java, Visual Basic, Visual C++, Socket cho phép thi ế t l ậ p các kênh giao ti ế p mà hai đ ầ u kênh đư ợ c đánh d ấ u b ở i hai c ổ ng (port) Thông qua các c ổ ng này m ộ t quá trình có th ể nh ậ n và g ở i d ữ li ệ u v ớ i các quá trình khác Hình 1 2 Mô hình Socket 8 1 2 2 S ố hi ệ u c ổ ng c ủ a S ocket Để có thể thực hiện các cuộc giao tiếp, một trong hai quá trình phải công bố số hiệu cổng của socket mà mình sử dụng Mỗi cổng giao tiếp thể hiện một địa chỉ xác định trong hệ thống Khi quá trình được gán một số hiệu cổng, nó có thể nhận dữ liệu gởi đến cổng này từ các quá trình khác Quá trình còn lại cũng được yêu cầu tạo ra một socket Ngoài số hiệu cổng, hai bên giao tiếp còn phải biết địa chỉ IP của nhau Địa chỉ IP giúp phân biệt máy tính này với máy tính kia trên mạng TCP/IP Trong khi số hiệu cổng dùng để phân biệt các quá trình khác nhau trên cùng một máy tính Hình 1 3 Cổng trong Socket Trong hình trên, địa chỉ của quá trình B1 được xác định bằng 2 thông tin: (Host B, Port B1): Địa chỉ máy tính có thể là địa chỉ IP dạng 203 162 36 149 hay là địa chỉ theo dạng tên miền như www cit ctu edu vn Số hiệu cổng gán cho Soc ket phải duy nhất trên phạm vi máy tính đó, có giá trị trong khoảng từ 0 đến 65535 (16 bits) Trong đó, các cổng từ 1 đến 1023 được gọi là cổng hệ thống được dành riêng cho các quá trình của hệ thống Các cổng mặc định của 1 số dịch vụ mạng thông dụng: Số hiệu cổng Quá trình hệ thống 7 Dịch vụ Echo 21 Dịch vụ FTP 23 Dịch vụ Telnet 9 25 Dịch vụ E – mail (SMTP) 80 Dịch vụ web (HTTP) 110 Dịch vụ E – mail (POP) 1 2 3 Xây d ự ng ứ ng d ụ ng C lient / S erver v ớ i S ocket 1 2 3 1 Mô hình Client / Server s ử d ụ ng socket ở ch ế đ ộ có k ế t n ố i (TCP) Hình 1 4 Mô hình Client / Server s ử d ụ ng S ocket ở ch ế đ ộ có k ế t n ố i (TCP) Có thể phân thành 4 giai đoạn như sau: Giai đoạn 1 : Server tạo Socket, gán số hiệu cổng và lắng nghe yêu cầu nối kết Server sẵn sàng phục vụ Client socket(): Server yêu cầu tạo một socket để có thể sử dụng các dịch vụ của tầng vận chuyển o bind(): Server yêu cầu gán số hiệu cổng (port) cho socket o listen(): Server lắng nghe các yêu cầu nối kết từ các C lient trên cổng đã được gán Giai đoạn 2 : Client tạo Socket, yêu cầu thiết lập một nối kết với Server o socket(): Client yêu cầu tạo một socket để có thể sử dụng các dịch vụ của tầng vận chuyển, thông thường hệ thống tự động gán một số hiệu cổng còn rảnh cho socket của Client o connect(): Client gởi yêu cầu nối kết đến S erve r có địa chỉ IP và Port xác định 10 o accept(): Server chấp nhận nối kết của C lient, khi đó một kênh giao tiếp ảo được hình thành, Client và S erver có thể trao đổi thông tin với nhau thông qua kênh ảo này Giai đoạn 3 : Trao đổi thông tin giữa Client và Server o Sau khi chấp nhận yêu cầu nối kết, thông thường S erver thực hiện lệnh read() và nghẽn cho đến khi có thông điệp yêu cầu (Request Message) từ C lient gởi đến o Server phân tích và thực thi yêu cầu Kết quả sẽ được gởi về C lient bằng lệnh write() o Sau khi gởi yêu cầu bằng lệnh write(), client chờ nhận thông điệp kết quả (ReplyMessage) từ S erver bằng lệnh read() Giai đoạn 4 : Kết thúc phiên làm việc o Các câu lệnh read(), write() có thể được thưc hiện nhiều lần (ký hiệu bằng hình ellipse) o Kênh ảo sẽ bị xóa khi Server hoặc Client đóng socket bằng lệnh close() 1 2 3 2 Mô hình Client / Server s ử d ụ ng socket ở ch ế đ ộ không k ế t n ố i (UDP) Hình 1 5 Mô hình Client / Server s ử d ụ ng socket ở ch ế đ ộ không k ế t n ố i (UDP) 11 Có thể phân thành 3 giai đoạn như sau: Giai đoạn 1: Server tạo Socket – gán số hiệu cổng o socket(): Server yêu cầu tạo một socket để có thể sử dụng các dịch vụ của tầng vận chuyển o bind(): Server yêu cầu gán số hiệu cổng cho socket Giai đoạn 2: Client tạo Socket o socket(): Client yêu cầu tạo một socket để có thể sử dụng các dịch vụ của tầng vận chuyển, thông thường hệ thống tự động gán một số hiệu cổng còn rảnh cho socket của Client Giai đoạn 3: Trao đổi thông tin giữa Client và Server o Sau khi tạo Socket xong, Client và Server có thể trao đổi thông tin q ua lại với nhau thông qua hai hàm send() và receive() o Đơn vị dữ liệu trao đổi giữa Client và Server là các Datagram Package (Gói tin thư tín) o Protocol của ứng dụng phải định nghĩa khuôn dạng và ý nghĩa của các Datagram Package Mỗi Datagram Package có ch ứa thông tin về địa chỉ người gởi và người nhận (IP, Port) 1 2 4 L ậ p trình S ocket trong C# Các l ớ p NET cơ b ả n trong l ậ p trình m ạ ng Các lớp này được cung cấp trong hai System Net và System Net Sockets Hai namespace này chứa rất nhiều lớp dùng trong lập trình mạng, nhưng ta chỉ quan tâm đến các lớp sau: Class Namespace Desciption IPAddress System Net Provides an Internet Protocol (IP) address IPEndPoint System Net Represents a network endpoint as an IP add ress and a port number TcpListener System Net Sockets Listens for connections from TCP network clients 12 Socket System Net Sockets Implements the Berkeley sockets interface TcpClient System Net Sockets Provides C lient connections for TCP network services NetworkStream System Net Sockets Provides the underlying stream of data for network acces s K ế t n ố i Server / Client v ớ i TCP/IP Khi được chạy, S erver cần được xác định rõ địa chỉ IP và sẽ “lắng nghe” trên một port cụ thể Server sẽ nằm trong trạng thái này cho đến khi C lient gửi đến một yêu cầu kết nối Sau khi được S erver chấp nhận, một connection sẽ hình thành cho phép S erver và C lient giao tiếp với nhau Cụ thể hơn, các bước tiến hành trên S erver và C lient mà ta cần thực hiện sử dụng giao thức TCP/IP trong C# (có thể chạy S erver và C lient trên cùng một máy): Server: 1 Tạo một đối tượng System Net Sockets TcpListener để bắt đầu “lắng nghe” trên một cổng cục bộ 2 Đợi và chấp nhận kết nối từ C lient với phương thức AccepSocket() Phương thức này trả về một đối tượng System Net Sockets Socket dùng để gửi và nhận dữ liệu 3 Thực hiện giao tiếp với C lient 4 Đóng Socket Thông thường quy trình này sẽ đư ợc đặt trong một vòng lặp (lặp lại bước 2) để chấp nhận nhiều kết nối cùng lúc (sử dụng Thread) hoặc các kết nối lần lượt Client: 1 Tạo một đối tượng System Net Socket s TcpClient 2 Kết nối đến S erver với địa chỉ và port xác định với phương thức TcpClient Connect() 3 Lấy luồng (stream) giao tiếp bằng phương thức TcpClient GetStream() 13 4 Thực hiện giao tiếp với S erver 5 Đóng luồng và S ocket Quy trình này có thể được minh họa theo mô hình sau: Hình 1 6 Lập trình Socket trong C# 1 3 Mã hóa bí m ậ t 1 3 1 Gi ớ i thi ệ u v ề b ả o m ậ t thông tin Bảo mật thông tin là duy trì tính bảo mật, tính toàn vẹn toàn diện và tính sẵn sàng cho toàn bộ thông tin Ba yếu tố không thể tách rời trong việc bảo mật từ A đến Z thông tin là: Tính bảo mật: Đảm bảo thông tin đó là duy nhất, những người muốn tiếp cận phải được phân quyền truy cập Tính toàn vẹn: Bảo vệ sự hoàn chỉnh toàn diện cho hệ thống thông tin Tính chính xác: Thông tin đưa ra phải chính xác, đầy đủ , không được sai lệch hay không được vi phạm bản quyền nội dung Tính sẵn sàng: Việc bảo mật thông tin luôn phải sẵn sàng, có thể thực hiện bất cứ đâu, bất cứ khi nào 1 3 2 Gi ớ i thi ệ u v ề mã hóa thông tin Mã hóa thông tin là một hình thức biến đổi dữ liệu thành một dạng dữ liệu khác có ý nghĩa khác với dữ liệu trước khi bị biến đổi ban đầu, với mục đích chỉ 14 cho phép một số người nhất định có thể đọc được dữ liệu ban đầu, thông qua việc giải mã dữ liệu sau khi biến đổi Hay nói cách khác, mã hóa là biến dữ liệu ban đầu A thành dữ liệu B, và việc đọc dữ liệu A sẽ thông qua việc giải mã dữ liệu B về A 1 3 3 Mã hóa bí m ậ t Mã hóa khóa bí mật , còn gọi là mã hóa đối xứng hay mã hóa khóa riêng , là sử dụng một khóa cho cả quá trình mã hó a (được thực hiện bởi người gửi thông tin) và quá trình giải mã (được thực hiện bởi người nhận) Quá trình mã hóa khóa bí mật được thực hiện như sau: Một khách hàng (Anne) muốn gửi tới người bán hàng (Bob) một đơn đặt hàng, nhưng chỉ muốn một mình Bob có thể đọc được Anne mã hóa đơn đặt hàng (dưới dạng văn bản gốc) của mình bằng một mã khóa rồi gửi đơn đặt hàng đã mã hóa đó cho Bob Tất nhiên, ngoài Bob và Anne ra, không ai có thể đọc được nội dung thông điệp lộn xộn đã mã hóa Khi nhận được thông điệp mã hóa, Bob giải mã thông điệp này bằng khóa giải mã và đọc các thông tin của đơn đặt hàng Điều đáng chú ý là trong kĩ thuật mã hóa khóa bí mật, khóa để mã hóa thông điệp và khóa để giải mã thông điệp giống như nhau Người gửi thông điệp sử dụng một khóa mật mã để mã hóa thông điệp và người nhận thông điệp cũng sử dụng một khóa như vậy để đọc mật mã hoặc giải mã thông điệp Kĩ thuật mã hóa khóa bí mật này đã được IBM phát triển, áp dụng cho các cơ quan của Chính Phủ Mỹ năm 1977 được gọi là Tiêu chuẩn mã h óa dữ liệu (DES – data encryption standard) 1 3 4 Mã hóa bí m ậ t trong C# Trong mã hóa thông tin, C# h ỗ tr ợ thư vi ệ n System Security Cryptography có ch ứ a r ấ t nhi ề u phương th ứ c v ề mã hóa, trong đó có mã hóa bí m ậ t Các bư ớ c c ủ a quá trình mã hóa: 15 Khai báo 2 đ ố i t ư ợ ng TripleDESCryptoServiceProvider và MD5CryptoService Provider Chuy ể n chu ỗ i c ầ n mã hóa và key v ề ki ể u byte[] Gán thu ộ c tính key c ủ a đ ố i tư ợ ng TripleDESCryptoServiceProvider là key v ừ a chuy ể n đ ổ i v ề byte[] và thu ộ c tính mode là CipherMode ECB S ử d ụ ng phương th ứ c CreateEncryptor đ ể mã hóa Chuy ể n đ ổ i đ ố i tư ợ ng đã mã hóa v ề ki ể u chu ỗ i Các bư ớ c c ủ a quá trình gi ả i mã: Khai báo 2 đ ố i tư ợ ng TripleDESCryptoServiceProvider và MD5CryptoService Provider Chuy ể n chu ỗ i c ầ n mã hóa và key v ề ki ể u byte[] Gán thu ộ c tín h key c ủ a đ ố i tư ợ ng TripleDESCryptoServiceProvider là key v ừ a chuy ể n đ ổ i v ề byte[] và thu ộ c tính mode là CipherMode ECB S ử d ụ ng phương th ứ c CreateDecryptor đ ể gi ả i mã Chuy ể n đ ổ i đ ố i tư ợ ng đã gi ả i mã v ề ki ể u chu ỗ i 16 Chương 2: GI Ớ I THI Ệ U V Ề KI Ế N TRÚC HƯ Ớ NG D Ị CH V Ụ SOA VÀ CÔNG C Ụ PHÁT TRI Ể N HƯ Ớ NG D Ị CH V Ụ WCF 2 1 Gi ớ i thi ệ u v ề ki ế n trúc hư ớ ng d ị ch v ụ SOA 2 1 1 M ộ t s ố khái ni ệ m Ki ế n trúc hư ớ ng d ị ch v ụ (SOA – Service Oriented Architecture) là ch ủ đ ề m ớ i trong lĩnh v ự c công ngh ệ thông tin và đư ợ c s ự quan tâm c ủ a nhi ề u nhà cung c ấ p d ị ch v ụ Công ngh ệ thông tin (CNTT) và truy ề n thông l ớ n trên th ế gi ớ i như IBM, HP, BEA, Oracle, SAP và Microsoft SOA có th ể xây d ự ng và th ự c thi các h ệ th ố ng CNTT m ộ t cách d ễ dàng và nhanh chóng b ằ ng cách tr ự c ti ế p đáp ứ ng và ti ế p c ậ n các m ụ c đích c ủ a m ộ t t ổ ch ứ c SOA tích h ợ p quy trình nghi ệ p v ụ và CNTT vào m ộ t framework m ở , ở đó ngư ờ i ta có th ể thêm v ào các d ị ch v ụ 2 1 1 1 Service Service là thao tác nghi ệ p v ụ đơn gi ả n, đư ợ c th ự c hi ệ n l ặ p l ạ i nhi ề u l ầ n Service cung c ấ p m ộ t giá tr ị hay m ộ t n ộ i dung xác đ ị nh, có th ể là d ị ch v ụ hay ch ứ c năng VD: tra c ứ u thuê bao, m ở tài kho ả n m ớ i, hay truy c ậ p 1 th ự c th ể tron g CSDL Ta có th ể hình dung service như sau: Hình 2 1 Mô t ả đ ị nh nghĩa Service 17 M ỗ i service có th ể ch ỉ là m ộ t công vi ệ c (task) đư ợ c th ự c hi ệ n b ở i m ộ t cá nhân hay là m ộ t quy trình con ho ặ c cũng có th ể là toàn b ộ m ộ t quy trình logic, đư ợ c vi ệ n d ẫ n đ ế n nhi ề u l ầ n 2 1 1 2 Hư ớ ng Service Cách th ứ c phân tích, thi ế t k ế xây d ự ng các ứ ng d ụ ng ph ầ n m ề m l ấ y service làm trung tâm, làm thành ph ầ n cơ b ả n, c ố t lõi Vi ệ c xây d ự ng các ứ ng d ụ ng ph ầ n m ề m hư ớ ng d ị ch v ụ th ự c hi ệ n b ằ ng cách phân tích, thi ế t k ế và l ắ p ráp các service v ớ i nhau 2 1 1 3 Ki ế n trúc hư ớ ng d ị ch v ụ SOA Trong vài năm g ầ n đây SOA đã b ắ t đ ầ u đư ợ c nh ắ c đ ế n nhi ề u hơn và có r ấ t nhi ề u khái ni ệ m SOA đư ợ c bi ế t đ ế n như: SOA – mô hình ki ế n trúc hư ớ ng d ị ch v ụ là t ậ p h ợ p c ủ a các Service, ở đó chúng giao ti ế p v ớ i nhau SOA là m ộ t c ấ u trúc tích h ợ p các service l ạ i v ớ i nhau SOA đư ợ c hi ể u là m ộ t c ấ u trúc h ỗ tr ợ cho vi ệ c giao ti ế p gi ữ a các service, d ự a trên các n ộ i dung chính v ề các ứ ng d ụ ng frontend, d ị ch v ụ , kho lưu tr ữ d ị ch v ụ , và các k ế t n ố i d ị ch v ụ SOA đư ợ c hi ể u là f ramework (n ề n t ả ng) cho vi ệ c xây d ự ng và tích h ợ p các quy trình nghi ệ p v ụ , các ứ ng d ụ ng dư ớ i s ự h ỗ tr ợ c ủ a cơ s ở h ạ t ầ ng CNTT Theo khái ni ệ m c ủ a IBM thì: SOA là ki ế n trúc hư ớ ng d ị ch v ụ cho phép kh ả năng linh ho ạ t trong vi ệ c th ể hi ệ n các thành ph ầ n c ủ a qu y trình nghi ệ p v ụ và cơ s ở h ạ t ầ ng CNTT, có th ể đư ợ c tái s ử d ụ ng và k ế t h ợ p v ớ i nhau Ngoài ra, tài li ệ u “Enterprise SOA - SOA Best Practices” trình bày đ ị nh nghĩa SOA thông qua 4 thành ph ầ n cơ b ả n như sau: Ki ế n trúc hư ớ ng d ị ch v ụ SOA là ki ế n trúc công ng h ệ thông tin c ủ a doanh nghi ệ p bao g ồ m 4 thành ph ầ n: application frontends, service, service repository và service bus Trong đó, m ộ t service bao g ồ m contract, 1 ho ặ c nhi ề u interface và implementation 18 Hình 2 2 Các thành ph ầ n trong đ ị nh nghĩa c ủ a SOA App lication frontend (Các ứ ng d ụ ng giao ti ế p v ớ i ngư ờ i dùng): là ứ ng d ụ ng giao ti ế p v ớ i ngư ờ i s ử d ụ ng Chúng kh ở i t ạ o và đi ề u khi ể n các ho ạ t đ ộ ng c ủ a h ệ th ố ng ph ầ n m ề m doanh nghi ệ p Service (D ị ch v ụ ): là thành ph ầ n ph ầ n m ề m th ự c hi ệ n m ộ t ch ứ c năng riêng bi ệ t, đ ộ c l ậ p Bao g ồ m cài đ ặ t c ụ th ể đ ể cung c ấ p logic nghi ệ p v ụ , d ữ li ệ u đư ợ c th ự c hi ệ n b ằ ng các ngôn ng ữ và k ỹ thu ậ t l ậ p trình khác nhau Service repository (Kho lưu tr ữ các service): cung c ấ p kh ả năng lưu tr ữ , tìm ki ế m các services và có đư ợ c các thông tin mô t ả và s ử d ụ ng service t ừ service contract Service bus: Thành ph ầ n cung c ấ p kh ả năng k ế t n ố i linh ho ạ t, l ỏ ng l ẻ o các thành ph ầ n tham gia SOA, bao g ồ m các services và các ứ ng d ụ ng không đ ồ ng nh ấ t 2 1 1 4 Ki ế n trúc t ổ ng th ể SOA Đ ể có cái nhìn t ổ ng quát v ề SOA, chúng ta cùng tìm hi ể u ki ế n trúc t ổ ng th ế c ủ a nó Ki ế n trúc SOA là m ộ t ki ể u ki ế n trúc phân t ầ ng, đư ợ c th ể hi ệ n qua hình v ẽ sau: 19 Hình 2 3 Ki ế n trúc t ổ ng t ổ ng SOA Nhìn t ừ dư ớ i lên ta có th ể th ấ y đư ợ c ki ế n trúc SOA như sau: T ầ ng dư ớ i cùng là t ầ ng ch ứ a các ứ ng d ụ ng con trong h ệ th ố ng CNTT c ủ a doanh nghi ệ p T ầ ng phía trên nó là t ầ ng ch ứ a service th ự c thi T ầ ng ti ế p theo là t ầ ng Orchestration (k ế t h ợ p) là s ự k ế t h ợ p các service th ự c thi theo m ộ t quy trình T ầ ng trên c ủ a t ầ ng Orchestration là t ầ ng ch ứ a các ser vice nghi ệ p v ụ T ầ ng trên c ủ a t ầ ng các service nghi ệ p v ụ th ể hi ệ n toàn b ộ quy trình hay lu ồ ng công vi ệ c c ủ a h ệ th ố ng doanh nghi ệ p T ầ ng trên cùng trong ki ế n trúc SOA là t ầ ng các ứ ng d ụ ng front - end 2 1 2 Nh ữ ng đ ặ c đi ể m và l ợ i ích c ủ a SOA 2 1 2 1 Các đ ặ c đi ể m c ủ a SOA T ăng kh ả năng c ộ ng tác Tăng cư ờ ng tính m ề m d ẻ o c ủ a quy trình nghi ệ p v ụ Cung c ấ p th ố ng nh ấ t thao tác truy c ậ p d ữ li ệ u Tăng cư ờ ng kh ả năng k ế t n ố i không đ ồ ng nh ấ t Tăng kh ả năng tái s ử d ụ ng các services 20 2 1 2 2 L ợ i ích c ủ a SOA V ớ i các đ ặ c đi ể m trên c ủ a ki ế n trúc hư ớ ng d ị ch v ụ SOA, ki ế n trúc SOA s ẽ mang l ạ i cho doanh nghi ệ p r ấ t nhi ề u l ợ i ích khi doanh nghi ệ p tri ể n khai thành công ki ế n trúc này: V ề công ngh ệ thông tin Gi ả m th ờ i gian và công s ứ c xây d ự ng l ạ i ứ ng d ụ ng ph ầ n m ề m Tăn g tính linh ho ạ t đ ể thay đ ổ i ho ạ t đ ộ ng c ủ a h ệ th ố ng ph ứ c Gi ả m thi ể u chi phí v ề th ờ i gian, nhân l ự c, v ậ t l ự c đ ể b ả o trì các ứ ng d ụ ng ph ầ n m ề m Gi ả m thi ể u r ủ i ro đ ố i v ớ i các d ự án l ớ n, ph ứ c t ạ p V ề quy trình nghi ệ p v ụ M ề m d ẻ o trong vi ệ c xây d ự ng quy trình n ghi ệ p v ụ Tăng cư ờ ng kh ả năng trao đ ổ i thông tin gi ữ a doanh nghi ệ p và các khách hàng và đ ố i tác thương m ạ i D ễ dàng và nhanh chóng c ả i ti ế n quy trình nghi ệ p v ụ , góp ph ầ n nâng cao hi ệ u qu ả s ả n xu ấ t, kinh doanh c ủ a doanh nghi ệ p 2 1 3 Tính ch ấ t c ủ a SOA 2 1 3 1 K ế t n ố i l ỏ ng l ẻ o V ấ n đ ề k ế t n ố i (coupling) ám ch ỉ đ ế n m ộ t s ố ràng bu ộ c gi ữ a cách module v ớ i nhau Có hai lo ạ i coupling là r ờ i (loose) và ch ặ t (tight) Các module có tính loose coupling có m ộ t s ố ràng bu ộ c đư ợ c mô t ả rõ ràng trong khi các module có tính tight coupl ing l ạ i có nhi ề u ràng bu ộ c không th ể bi ế t trư ớ c H ầ u như m ọ i ki ế n trúc ph ầ n m ề m đ ề u hư ớ ng đ ế n tính loose coupling gi ữ a các module M ứ c đ ộ k ế t dính c ủ a m ỗ i h ệ th ố ng ả nh hư ở ng tr ự c ti ế p đ ế n kh ả năng ch ỉ nh s ử a h ệ th ố ng c ủ a chính nó K ế t dính càng ch ặ t bao nhi êu thì càng có nhi ề u thay đ ổ i liên quan c ầ n ch ỉ nh s ử a ở phía s ử d ụ ng d ị ch v ụ m ỗ i khi có thay đ ổ i nào đó x ả y ra M ứ c đ ộ coupling tăng d ầ n khi khi bên s ử d ụ ng d ị ch v ụ càng c ầ n bi ế t nhi ề u thông tin ng ầ m đ ị nh c ủ a bên cung c ấ p d ị ch v ụ đ ể s ử d ụ ng d ị ch v ụ đư ợ c cu ng c ấ p Nghĩa là n ế u bên s ử d ụ ng d ị ch v ụ bi ế t v ị trí và chi ti ế t đ ị nh d ạ ng d ữ li ệ u c ủ a 21 bên cung c ấ p d ị ch v ụ thì quan h ệ gi ữ a hai bên càng ch ặ t Ngư ợ c l ạ i, n ế u bên s ử d ụ ng d ị ch v ụ không c ầ n bi ế t m ọ i thông tin chi ti ế t c ủ a d ị ch v ụ trư ớ c khi tri ệ u g ọ i nó thì quan h ệ gi ữ a hai bên càng có tính loose coupling SOA h ỗ tr ợ loose coupling thông qua vi ệ c s ử d ụ ng h ợ p đ ồ ng và liên k ế t (contract and binding) M ộ t ngư ờ i s ử d ụ ng truy v ấ n đ ế n nơi lưu tr ữ và cung c ấ p thông tin d ị ch v ụ (registry) đ ể l ấ y thông tin v ề lo ạ i d ị c h v ụ c ầ n s ử d ụ ng Registry s ẽ tr ả v ề t ấ t c ả nh ữ ng d ị ch v ụ tho ả i tiêu chu ẩ n tìm ki ế m T ừ bây gi ờ ngư ờ i dùng ch ỉ vi ệ c ch ọ n d ị ch v ụ mà mình c ầ n, và th ự c thi phương th ứ c trên đó theo mô t ả d ị ch v ụ nh ậ n đư ợ c t ừ registry Bên s ử d ụ ng d ị ch v ụ không c ầ n ph ụ thu ộ c tr ự c ti ế p vào cài đ ặ t c ủ a d ị ch v ụ mà ch ỉ d ự a trên h ợ p đ ồ ng mà d ị ch v ụ đó h ỗ tr ợ Hình 2 4 K ế t n ố i l ỏ ng l ẻ o Tính loose coupling giúp g ỡ b ỏ nh ữ ng ràng bu ộ c đi ề u khi ể n gi ữ a nh ữ ng h ệ th ố ng đ ầ u cu ố i M ỗ i h ệ th ố ng có th ể t ự qu ả n lý đ ộ c l ậ p nh ằ m tăng hi ệ u su ấ t, kh ả năng m ở r ộ ng và kh ả năng đáp ứ ng cao Nh ữ ng thay đ ổ i cài đ ặ t cũng đư ợ c che d ấ u đi Loose coupling đem đ ế n s ự đ ộ c l ậ p gi ữ a bên cung c ấ p và bên s ử d ụ ng nhưng nó đòi h ỏ i các interface ph ả i theo chu ẩ n và c ầ n m ộ t thành ph ầ n trung gian qu ả n lý, trung c huy ể n yêu c ầ u gi ữ a các h ệ th ố ng đ ầ u cu ố i 2 1 3 2 Tái s ử d ụ ng d ị ch v ụ B ở i vì các d ị ch v ụ đư ợ c cung c ấ p lên trên m ạ ng và đư ợ c đăng ký ở m ộ t nơi nh ấ t đ ị nh nên chúng d ễ dàng đư ợ c tìm th ấ y và tái s ử d ụ ng N ế u m ộ t d ị ch v ụ 22 không có kh ả năng tái s ử d ụ ng, nó cũng không c ầ n đ ế n interface mô t ả Các d ị ch v ụ có th ể đư ợ c tái s ử d ụ ng l ạ i b ằ ng cách k ế t h ợ p l ạ i v ớ i nhau theo nhi ề u m ụ c đích khác nhau Tái s ử d ụ ng l ạ i các d ị ch v ụ còn giúp lo ạ i b ỏ nh ữ ng thành ph ầ n trùng l ặ p và tăng đ ộ v ữ ng ch ắ c trong cài đ ặ t, nó còn giúp đơn gi ả n hó a vi ệ c qu ả n tr ị Th ự c ra tái s ử d ụ ng d ị ch v ụ l ạ i d ễ dàng hơn tái s ử d ụ ng thành t ố hay l ớ p Nh ữ ng d ị ch v ụ đư ợ c dùng chung b ở i t ấ t c ả các ứ ng d ụ ng c ủ a m ộ t h ệ th ố ng SOA g ọ i là shared infrastructure service 2 1 3 3 Qu ả n lý chính sách Khi s ử d ụ ng các d ị ch v ụ chia s ẻ t rên m ạ ng, tùy theo m ỗ i ứ ng d ụ ng s ẽ có m ộ t lu ậ t k ế t h ợ p riêng g ọ i là các policy Các policy c ầ n đư ợ c qu ả n lý các áp d ụ ng cho m ỗ i d ị ch v ụ c ả khi thi ế t k ế l ẫ n khi trong th ờ i gian th ự c thi Vi ệ c này tăng kh ả năng t ạ o ra các d ị ch v ụ có đ ặ c tính tái s ử d ụ ng B ở i vì các policy đư ợ c thi ế t k ế tách bi ệ t, và tùy vào m ỗ i ứ ng d ụ ng nên gi ả m t ố i đa các thay đ ổ i ph ầ n m ề m N ế u không s ử d ụ ng các policy, các nhân viên phát tri ể n ph ầ n m ề m, nhóm đi ề u hành và nhóm h ỗ tr ợ ph ả i làm vi ệ c v ớ i nhau trong su ố t th ờ i gian phát tri ể n đ ể cài đ ặ t và ki ể m tra nh ữ ng policy Ngư ợ c l ạ i, n ế u s ử d ụ ng policy, nh ữ ng nhân viên phát tri ể n ph ầ n m ề m gi ờ ch ỉ c ầ n t ậ p trung vào quy trình nghi ệ p v ụ trong khi nhóm đi ề u hành và nhóm h ỗ tr ợ t ậ p trung vào các lu ậ t k ế t h ợ p 2 1 3 4 T ự đ ộ ng dò tìm và ràng bu ộ c đ ộ ng SOA h ỗ tr ợ khái ni ệ m truy tìm d ị ch v ụ (service discovery) M ộ t ngư ờ i s ử d ụ ng c ầ n đ ế n m ộ t d ị ch v ụ nào đó có th ể tìm ki ế m d ị ch v ụ d ự a trên m ộ t s ố tiêu chu ẩ n khi c ầ n Ngư ờ i s ử d ụ ng ch ỉ c ầ n h ỏ i m ộ t registry v ề d ị ch v ụ nào tho ả yêu c ầ u tìm ki ế m Ví d ụ , m ộ t h ệ th ố ng chuy ể n kho ả n (consumer) yêu c ầ u m ộ t registry tìm t ấ t c ả các d ị ch v ụ có kh ả năng ki ể m tra th ẻ tín d ụ ng Registry tr ả v ề m ộ t t ậ p các entry tho ả yêu c ầ u Các entry ch ứ a thông tin v ề d ị ch v ụ , bao g ồ m c ả phí giao d ị ch Bên s ử d ụ ng s ẽ ch ọ n m ộ t d ị ch v ụ có phí gi ao d ị ch th ấ p nh ấ t trong danh sách các d ị ch v ụ tr ả v ề , k ế t n ố i đ ế n nhà cung c ấ p d ị ch v ụ đó d ự a trên thông tin registry entry đ ể s ử d ụ ng d ị ch v ụ ki ể m tra th ẻ tín d ụ ng Trong ph ầ n mô t ả d ị ch v ụ kèm theo đã có t ấ t c ả các tham s ố c ầ n thi ế t dùng đ ể th ự c thi d ị ch v ụ , bên 23 s ử d ụ ng ch ỉ c ầ n đ ị nh d ạ ng d ữ li ệ u yêu c ầ u đúng theo mô t ả cung c ấ p và g ử i đi Nhà cung c ấ p d ị ch v ụ s ẽ th ự c thi ki ể m tr ả th ẻ tín d ụ ng và tr ả v ề m ộ t thông đi ệ p có đ ị nh d ạ ng đúng như trong ph ầ n mô t ả d ị ch v ụ M ố i ràng bu ộ c duy nh ấ t gi ữ a bên cung c ấ p và bên s ử d ụ ng là b ả n h ợ p đ ồ ng đư ợ c cung c ấ p b ở i registry trung gian M ố i ràng bu ộ c này là ràng bu ộ c trong th ờ i gian ch ạ y ch ứ không ph ả i ràng bu ộ c trong lúc biên d ị ch T ấ t c ả thông tin c ầ n thi ế t v ề d ị ch v ụ đư ợ c l ấ y v ề và s ử d ụ ng trong khi ch ạ y Ví d ụ trên cho th ấ y cách bên s ử d ụ ng tri ệ u g ọ i d ị ch v ụ m ộ t cách “đ ộ ng” Đây là m ộ t th ế m ạ nh c ủ a SOA V ớ i SOA, bên s ử d ụ ng d ị ch v ụ không c ầ n bi ế t đ ị nh d ạ ng c ủ a thông đi ệ p yêu c ầ u và thông đi ệ p tr ả v ề ,cũng như đ ị a ch ỉ d ị ch v ụ cho đ ế n khi c ầ n 2 1 3 5 Kh ả năng t ự h ồ i ph ụ c V ớ i kích c ỡ và đ ộ ph ứ c t ạ p c ủ a nh ữ ng ứ ng d ụ ng Client/Server ngày nay, kh ả năng ph ụ c h ồ i c ủ a m ộ t h ệ th ố ng sau khi b ị l ỗ i tr ở thành m ộ t y ế u t ố quan tr ọ ng M ộ t h ệ th ố ng t ự h ồ i ph ụ c (self – healing) là m ộ t h ệ th ố ng có kh ả năng t ự h ồ i ph ụ c sau khi b ị l ỗ i mà không c ầ n s ự can thi ệ p c ủ a con ngư ờ i Đ ộ tin c ậ y (reliability) là m ứ c đ ộ đo kh ả năng m ộ t h ệ th ố ng x ử lý t ố t như th ế nao trong tình tr ạ ng h ỗ n lo ạ n Trong ki ế n trúc hư ớ ng d ị ch v ụ , các d ị ch v ụ luôn có th ể ho ạ t đ ộ ng hay ng ừ ng b ấ t k ỳ lúc nào, nh ấ t là đ ố i v ớ i nh ữ ng ứ ng d ụ ng t ổ ng h ợ p t ừ nh ữ ng t ừ nhi ề u d ị ch v ụ c ủ a nhi ề u t ổ ch ứ c khác nhau Đ ộ tin c ậ y ph ụ thu ộ c vào kh ả năng ph ụ h ồ i c ủ a ph ầ n c ứ ng sau khi b ị l ỗ i H ạ t ầ ng m ạ ng ph ả i cho phép các k ế t n ố i đ ộ ng t ừ nhi ề u h ệ th ố ng khác nhau k ế t n ố i đ ế n trong khi ch ạ y M ộ t khía c ạ nh khác ả nh hư ở ng đ ế n đ ộ tin c ậ y là ki ế n trúc mà d ự a trên đó ứ ng d ụ ng đư ợ c xây d ự ng M ộ t ki ế n trúc h ỗ tr ợ k ế t n ố i và th ự c thi đ ộ ng khi ch ạ y s ẽ có kh ả năng t ự ph ụ c h ồ i hơn m ộ t h ệ th ố ng không h ỗ tr ợ nh ữ ng tính năng trên Thêm vào đó, b ở i vì nh ữ ng h ệ th ố ng d ự a t rên d ị ch v ụ yêu c ầ u s ự tách bi ệ t gi ữ a interface và cài đ ặ t, nên có th ể có nhi ề u cài đ ặ t khác nhau cho cùng m ộ t interface N ế u m ộ t th ể hi ệ n service nào đó không ho ạ t đ ộ ng thì m ộ t th ể hi ệ n khác v ẫ n có th ể hoàn t ấ t giao d ị ch cho khách hàng mà không b ị ả nh hư ở ng gì Kh ả năng này ch ỉ có đư ợ c khi C lient ch ỉ tương tác v ớ i interface c ủ a d ị ch v ụ ch ứ 24 không tương tác tr ự c ti ế p cài đ ặ t c ủ a d ị ch v ụ Đây là m ộ t trong nh ữ ng tình ch ấ t cơ b ả n c ủ a các h ệ th ố ng hư ớ ng d ị ch v ụ 2 1 4 Ưu và như ợ c đi ể m c ủ a SOA 2 1 4 1 Ưu đi ể m Về bản chất thì SOA chỉ đơn thuần là sự đáp ứng đối với một thách thức ngày càng lớn Đó cũng là yêu cầu thực tế của doanh nghiệp ngày càng thay đổi tới mức các cấu trúc ứng dụng kiểu truyền thống khó có thể giải quyết được SOA xuất hiện nhằm giải quyết các yêu cầu đó bằ ng cách trợ giúp cho hoạt động doanh nghiệp dễ dàng quản lý, linh hoạt và sẵn sàng với bất kỳ thay đổi nào Theo chia sẻ của một chuyên gia IBM từng nói thì: "SOA được xây dựng để thay đổi chứ không phải chỉ để tồn tại" SOA sở hữu nhiều ưu điểm nổi trội n hư: Khả năng tái sử dụng phần mềm : Nếu như một dịch vụ có quy mô và kích thước phù hợp sau đó nó sẽ được tái sử dụng cho những lần tiếp theo Công ty phần mềm Groove Technolog y (app & software company) nhận định rằng điều này cũng đồng nghĩa với việc giảm công sức phát triển cũng như chi phí về mặt tài chính cho nhà phát triển phần mềm và các khách hàng (công ty/doanh nghiệp) Đảm bảo tính linh hoạt khi mở rộng, kết nối và tích hợp : Giả sử rằng các dịch vụ của SOA không được tái sử dụng, bạn có thể đưa ra nhiều giá trị nếu như làm cho hệ thống công nghệ thông tin chỉnh sửa một cách dễ dàng hơn Tiết kiệm thời gian, tăng năng suất làm việc : Đối với một công ty thường xuyên xây dự ng những hệ thống mới dựa trên các chức năng tương tự sẽ tiết kiệm được thời gian phát triển, kiểm thửu và tích hợp đó vào trong các phần mềm nhỏ tương tự Hơn nữa, hiệu suất làm việc cũng được gia tăng nếu như các lập trình viên tái sử dụng các dịch vụ củ a SOA 2 1 4 2 Như ợ c đi ể m Hạn chế chính của kiến trúc hướng dịch vụ là sự phức tạp của nó Mỗi dịch vụ phải đảm bảo rằng tin nhắn được gửi kịp thời Số lượng các tin nhắn này có 25 thể lên tới hơn một triệu lần, khiến việc quản lý tất cả các dịch vụ trở thành một thá ch thức lớn Phát triển SOA đòi hỏi một sự đầu tư lớn về nguồn nhân lực, công nghệ và nguồn lập trình viên Trong SOA, tất cả các đầu vào được xác nhận trước khi một dịch vụ tương tác với một dịch vụ khác Khi sử dụng nhiều dịch vụ, điều này làm tăng thời gian phản hồi và giảm hiệu suất tổng thể 2 2 Công c ụ phát tri ể n hư ớ ng d ị ch v ụ WCF 2 2 1 Khái ni ệ m WCF là công ngh ệ n ề n t ả ng nh ằ m th ố ng nh ấ t nhi ề u mô hình l ậ p trình giao ti ế p đư ợ c h ỗ tr ợ trong NET 2 0 thành m ộ t mô hình duy nh ấ t Vào tháng 11 năm 2005, NET 2 0 đư ợ c Microsoft phát hành trong đó có cung c ấ p các hàm API riêng bi ệ t cho các liên l ạ c d ự a trên SOAP đ ể t ố i đa hoá s ự làm vi ệ c gi ữ a các n ề n t ả ng s ử d ụ ng Web Services, đ ồ ng th ờ i NET 2 0 còn cung c ấ p các API đ ể t ố i ưu vi ệ c liên l ạ c d ự a trên mã nh ị phân gi ữ a các ứ ng d ụ ng ch ạ y trên h ệ th ố ng Windows g ọ i là NET Remoting, các API cho các giao d ị ch, và API cho liên l ạ c d ị b ộ WCF th ố ng nh ấ t các API này thành m ộ t mô hình duy nh ấ t nh ằ m đáp ứ ng mô hình l ậ p trình hư ớ ng d ị ch v ụ WCF có th ể s ử d ụ ng các b ả n tin SOAP gi ữ a hai ti ế n trình, do đó làm cho các ứ ng d ụ ng d ự a trên WCF có th ể làm vi ệ c v ớ i các ti ế n trình khác thông qua vi ệ c giao ti ế p s ử d ụ ng b ả n tin SOAP Khi m ộ t ti ế n trình WCF liên l ạ c v ớ i m ộ t ti ế n trình không là WCF, các b ả n tin SOAP đư ợ c mã hoá trên cơ s ở XML, nhưng khi nó liên l ạ c v ớ i m ộ t ti ế n trình WCF khác, b ả n tin SOAP có th ể đư ợ c t ố i ưu hoá d ự a trên mã hoá nh ị phân 2 2 2 T ạ i sao l ạ i s ử d ụ ng WCF Như ph ầ n trên đã trình bày, NET 2 0 h ỗ tr ợ r ấ t nhi ề u phương pháp liên l ạ c gi ữ a các ứ ng d ụ ng khác nhau nh ằ m vào các m ụ c tiêu khác nhau Các phương pháp liên l ạ c này khá ph ứ c t ạ p và ph ả i m ấ t nhi ề u th ờ i gian đ ể làm ch ủ đư ợ c công ngh ệ Tuy nhiên ki ế n th ứ c thu đư ợ c t ừ vi ệ c tri ể n khai m ộ t phương pháp ít có kh ả năng dùng đư ợ c khi làm vi ệ c v ớ i phương pháp khác 26 V ớ i vi ệ c ra đ ờ i c ủ a WCF , m ọ i phương pháp liên l ạ c trư ớ c kia đ ề u có th ể th ự c hi ệ n trên WCF Do v ậ y nhà phát tri ể n ch ỉ c ầ n làm ch ủ đư ợ c công ngh ệ WCF là có th ể xây d ự ng các ứ ng d ụ ng m ộ t cách nhanh chóng WCF là m ộ t mô hình l ậ p trình cho phép nhà phát tri ể n xây d ự ng các gi ả i pháp d ị ch v ụ đ ả m b ả o tính ổ n đ ị nh, và b ả o m ậ t và th ậ m chí là đ ả m b ả o giao d ị ch Nó làm đơn gi ả n hoá vi ệ c phát tri ể n các ứ ng d ụ ng n ố i k ế t và đưa ra cho nhà phát tri ể n nh ữ ng giá tr ị mà có th ể h ọ chưa nh ậ n ra ngay, đó là cách ti ế p c ậ n phát tri ể n h ệ th ố ng Client/Se rver th ố ng nh ấ t, đơn gi ả n, và qu ả n lý đư ợ c Do WCF đư ợ c xây d ự ng trên cơ s ở c ủ a NET Framework 2 0 CLR, nó là t ậ p các l ớ p cho phép các nhà phát tri ể n xây d ự ng các ứ ng d ụ ng hư ớ ng d ị ch v ụ b ằ ng môi trư ờ ng l ậ p trình quen thu ộ c c ủ a h ọ như VB NET hay C# 2 2 3 Ki ế n trúc WCF Hình sau mô t ả các l ớ p ch ủ y ế u trong ki ế n trúc c ủ a Windows Communication Foundation (WCF) Hình 2 5 Ki ế n trúc WCF 2 2 3 1 Contracts Các contract trong WCF cũng gi ố ng như các h ợ p đ ồ ng/hi ệ p đ ị nh mà b ạ n ký trong đ ờ i s ố ng th ậ t M ộ t h ợ p đ ồ ng b ạ n ký có th ể ch ứ a các thông tin như ki ể u công vi ệ c b ạ n s ẽ làm, và nh ữ ng thông tin mà b ạ n mu ố n đưa ra cho các bên khác WCF contract cũng ch ứ a các thông tin tương t ự như v ậ y Contract đ ị nh nghĩa các đ ặ c t ả trong h ệ th ố ng b ả n tin Thông thư ờ ng có các lo ạ i contract sau: 27 C ontract d ữ li ệ u mô t ả các tham s ố cho các b ả n tin mà m ộ t d ị ch v ụ có th ể t ạ o ra hay s ử d ụ ng Các tham s ố b ả n tin đư ợ c đ ị nh nghĩa b ằ ng các tài li ệ u s ử d ụ ng ngôn ng ữ đ ặ c t ả XML Schema (XSD), đi ề u này cho phép các h ệ th ố ng hi ể u XML có th ể x ử lý tài li ệ u d ễ dàn g Các d ị ch v ụ khi liên l ạ c v ớ i nhau có th ể không c ầ n đ ồ ng ý v ớ i nhau v ề các ki ể u, nhưng c ầ n đ ồ ng ý v ề contract d ữ li ệ u, nghĩa là đ ồ ng ý v ề các tham s ố và các ki ể u tr ả v ề Contract b ả n tin đ ị nh nghĩa các ph ầ n có trong b ả n tin s ử d ụ ng các giao th ứ c SOAP, và nó cho phép đi ề u khi ể n sâu hơn t ớ i các ph ầ n trong b ả n tin khi có yêu c ầ u s ự chính xác như v ậ y Contract d ị ch v ụ đ ặ c t ả chi ti ế t các phương th ứ c c ủ a d ị ch v ụ , và đư ợ c phân ph ố i như là m ộ t giao di ệ n trong các ngôn ng ữ l ậ p trình như Visual Basic hay Visual C# Có th ể hình dung v ề contract d ị ch v ụ m ộ t cách gián ti ế p như sau: “Đây là các ki ể u d ữ li ệ u c ủ a các b ả n tin c ủ a tôi, đây là nơi tôi cung c ấ p, và đây là các giao th ứ c mà tôi có th ể liên l ạ c” Các chính sách và các k ế t n ố i (bindings) mô t ả các đi ề u ki ệ n c ầ n có đ ể giao ti ế p v ớ i m ộ t d ị ch v ụ Các chính sách s ẽ bao g ồ m c ả các yêu c ầ u v ề b ả o m ậ t và các đi ề u ki ệ n khác c ầ n ph ả i có khi k ế t n ố i v ớ i m ộ t d ị ch v ụ 2 2 3 2 Runtime service L ớ p d ị ch v ụ th ự c thi ch ứ a các hành x ử s ẽ x ả y ra trong quá trình th ự c hi ệ n c ủ a d ị ch v ụ , nghĩa là các hành x ử th ự c thi c ủ a d ị ch v ụ Ta s ẽ th ấ y m ộ t s ố các hành x ử như sau: Throttling behavior: Đi ề u khi ể n lu ồ ng nh ằ m quy đ ị nh xem có bao nhiêu b ả n tin đư ợ c x ử lý Error behavior: Hành x ử l ỗ i quy đ ị nh nh ữ ng hành đ ộ ng khi l ỗ i x ả y ra trong h ệ th ố ng Metada ta behavior: Hành x ử v ớ i các siêu d ữ li ệ u quy đ ị nh xem làm th ế nào và khi nào thì các siêu d ữ li ệ u đư ợ c đưa ra bên ngoài d ị ch v ụ Instance behavior: Hành x ử th ự c th ể quy đ ị nh xem có bao nhiêu th ự c th ể c ủ a d ị ch v ụ đó đư ợ c ch ạ y 28 Transaction behavior: Hành x ử giao d ị ch cho phép vi ệ c rollback các giao d ị ch n ế u x ả y ra l ỗ i Message ins
PHẦN MỞ ĐẦU
Lý do chọn đề tài
Trong những năm gần đây du lịch là một trong những ngành có độ tăng trưởng cao nhất cả nước Rất nhiều khách sạn đua nhau phát triển liên tục và nhanh chóng theo sự phát triển của xã hội về quy mô và chất lượng
Hiện nay, các khách sạn phải trực tiếp tiếp nhận, quản lý một khối lượng lớn và thường xuyên nhiều loại khách, cùng với hàng loạt dịch vụ phát sinh theo nhu cầu của khách hàng Do đó, công việc quản lý hoạt động kinh doanh của khách sạn ngày càng phức tạp hơn
Hơn nữa, công tác quản lý không chỉ đơn thuần là quản lý về lưu lượng khách đến với khách sạn, sử dụng các loại hình dịch vụ,… mà công việc quản lý còn phải đáp ứng nhu cầu về việc báo cáo các loại hình doanh thu, tình hình kinh doanh của khách sạn,… để từ đó có thể đưa ra định hướng và lập kế hoạch phát triển cho công việc kinh doanh đó Nhưng với việc lưu trữ và xử lý bằng thủ công như hiện nay thì sẽ tốn rất nhiều thời gian và nhân lực mà không đem lại hiệu quả cao Do đó cần phải tin học hóa hình thức quản lý, cụ thể là xây dựng một phần mềm để đáp ứng nhu cầu quản lý toàn diện, thống nhất và đạt hiệu quả cao nhất cho hoạt động kinh doanh của khách sạn
Do những nhu cầu trên nên em quyết định chọn đề tài: “Nghiên cứu công cụ phát triển hướng dịch vụ WCF trong C# để xây dựng phần mềm quản lý khách sạn” làm đề tài khóa luận tốt nghiệp của mình Xây dựng phần mềm quản lý khách sạn là một điều thiết yếu đáp ứng nhu cầu ứng dụng công nghệ thông tin vào quản lý, kinh doanh của khách sạn, quản lý khách sạn như là một chính yếu cho nhu cầu ứng dụng công nghệ thông tin vào kinh doanh.
Mục tiêu của đề tài
Tìm hiểu về lập trình socket và mã hóa bí mật trong C#
Nghiên cứ u công cụ phát triển hướng dịch vụ WCF trong C#
Phân tích thiết kế hệ thống theo hướng đối tượng
Xây dựng phần mềm quản lý khách sạn dựa trên WCF
Đối tượng và phạm vi nghiên cứu
Công cụ phát triển hướng dịch vụ WCF trong C#
Phân tích hệ thống phần mềm quản lý khách sạn theo hướng đối tượng
Lập trình phần mềm quản lý khách sạn bằng công cụ phát triển hướng dịch vụ WCF trong C#
Phương pháp nghiên cứu
Phương pháp phân tích hệ thống thông tin theo hướng đối tượng
Lịch sử nghiên cứu
Trước đây, đã có rất nhiều đề tài nghiên cứu về vấn đề này, chẳng hạn:
Báo cáo Quản lý khách sạn của Nguyễn Thị Thương
Báo cáo bài tập lớn Quản lý khách sạn của Trần Tường Tuấn, Trường Cao đẳng Ngô Gia Tự, Bắc Giang
Tuy nhiên, tất cả các đề tài đó chỉ dừng ở việc phân tích và thiết kế hệ thống theo hướng đối tượng chưa có sử dụng công cụ phát triển hướng dịch vụ WCF.
Đóng góp của đề tài
Đề tài có thể giúp cho các bạn đọc hiểu rõ hơn về công cụ phát triển hướng dịch vụ WCF và ứng dụng xây dựng phần mềm quản lý khách sạn
Cấu trúc đề tài
PHẦN 2 NỘI DUNG NGHIÊN CỨU
Chương 1: Tổng quan về lập trình socket và mã hóa bí mật trong C#
Chương 2: Giới thiệu về kiến trúc hướng dịch vụ SOA và công cụ phát triển hướng dịch vụ WCF
Chương 3: Khảo sát và phân tích hệ thống
Chương 4: Thiết kế và triển khai hệ thống
PHẦN 3 KẾT LUẬN VÀ KIẾN NGHỊ
PHẦN 4 TÀI LIỆU THAM KHẢO
PHẦN NỘI DUNG
1.1 Tổng quan về mô hình Client/Server
1.1.1 Khái niệm mô hình Client/Server
Client/Server là mô hình mạng máy tính gồm có 2 thành phần chính đó là máy khách (Client) và máy chủ (Server) Server chính là nơi giúp lưu trữ tài nguyên cũng như cài đặt các chương trình dịch vụ theo đúng như yêu cầu của Client Ngược lại, Client bao gồm máy tính cũng như các loại thiết bị điện tử nói chung sẽ tiến hành gửi yêu cầu đến Server
Hình 1.1 Mô hình Client/Server
Mô hình mạng Client/Server sẽ cho phép mạng tập trung các ứng dụng có cùng chức năng tại một hoặc nhiều dịch vụ file chuyên dụng Chúng sẽ trở thành trung tâm của hệ thống Hệ điều hành của mô hình Client/Server sẽ cho phép người dùng chia sẻ đồng thời cùng một loại tài nguyên mà không giới hạn vị trí địa lý.
TỔNG QUAN VỀ LẬP TRÌNH SOCKET VÀ MÃ HÓA BÍ MẬT TRONG C#
Tổng quan về mô hình Client/Server
1.1.1 Khái niệm mô hình Client/Server
Client/Server là mô hình mạng máy tính gồm có 2 thành phần chính đó là máy khách (Client) và máy chủ (Server) Server chính là nơi giúp lưu trữ tài nguyên cũng như cài đặt các chương trình dịch vụ theo đúng như yêu cầu của Client Ngược lại, Client bao gồm máy tính cũng như các loại thiết bị điện tử nói chung sẽ tiến hành gửi yêu cầu đến Server
Hình 1.1 Mô hình Client/Server
Mô hình mạng Client/Server sẽ cho phép mạng tập trung các ứng dụng có cùng chức năng tại một hoặc nhiều dịch vụ file chuyên dụng Chúng sẽ trở thành trung tâm của hệ thống Hệ điều hành của mô hình Client/Server sẽ cho phép người dùng chia sẻ đồng thời cùng một loại tài nguyên mà không giới hạn vị trí địa lý
1.1.2 Nguyên tắc hoạt động của mô hình Client/Server
Người dùng đưa ra yêu cầu tại Client Máy Client chạy một chương trình ứng dụng có chức năng :
- Cung cấp giao diện cho người dùng
- Định dạng yêu cầu cung cấp dữ liệu
- Hiển thị dữ liệu nó nhận lại từ máy Server
Trong môi trường Client/Server, máy Server không chứa phần mềm giao diện người dùng Máy Client có nhiệm vụ trình bày dữ liệu theo hình thức hữu ích Chẳng hạn với giao diện người dùng và lập báo biểu
Chương trình ứng dụng trên máy Server tiếp nhận những chỉ thị từ người dùng, chuẩn bị chúng cho máy Server, rồi gởi một yêu cầu cung cấp thông tin cụ thể đến máy Server Máy Server xử lý yêu cầu, định vị thông tin tích hợp, rồi gởi thông tin tìm được qua mạng đến máy Client Máy Client sau đó sẽ “đẩy” thông tin ra giao diện để hiển thị thông tin trước người dùng
Máy Server trong môi trường Client/Server chuyên dùng để lưu trữ và quản lý dữ liệu Đây là nơi xảy ra hầu hết hoạt động thực của cơ sở dữ liệu Máy Server tiếp nhận các yêu cầu có cấu trúc từ phía máy Client, xử lý chúng, rồi gửi trả thông tin được yêu cầu và trở lại máy Client qua mạng
1.1.3 Ưu và nhược điểm của mô hình Client/Server
- Tập trung: Ưu điểm đầu tiên của mô hình Client/Server kiểu mạng khách chủ đó chính là khả năng kiểm soát tập trung (Centralization) đã được tích hợp sẵn Theo như mô hình này thì tất cả mọi thông tin cần thiết đều sẽ được đặt ở một vị trí duy nhất Đây là một ưu điểm vô cùng hữu ích được những người quản trị viên mạng yêu thích bởi vì họ có thể toàn quyền quản lý cũng như điều hành mọi việc Tính năng này giúp cho mọi sự cố trong mạng đều sẽ được giải quyết ở cùng một nơi thống nhất Đồng thời, việc cập nhật cơ sở tài nguyên, dữ liệu cũng sẽ dễ dàng hơn rất nhiều
- Bảo mật: Trong mạng Client/Server, tất cả các dữ liệu đều sẽ được bảo vệ một cách tối đa nhờ vào hệ thống kiến trúc tập trung của mạng Thông qua đó, nó sẽ giúp người dùng kiểm soát truy cập để chỉ có những ai được cấp quyền truy cập thì mới được thực hiện các thao tác cần thiết Muốn làm như vậy, chúng ta cần phải áp đặt thông tin đăng nhập cũng như Username hay Password Bên cạnh đó, nếu dữ liệu của chúng ta bị mất thì các file sẽ được khôi phục một cách vô cùng dễ dàng chỉ từ một bản sao lưu duy nhất mà thôi
- Khả năng mở rộng: Mô hình mạng kết nối Client/Server có khả năng mở rộng vô cùng tốt Chỉ cần người dùng cần sử dụng bất cứ lúc nào thì họ cũng có thể tăng được số lượng tài nguyên của mình Ví dụ như số Client hoặc Server Nhờ đó mà chúng ta có thể tăng kích thước của Server một cách dễ dàng mà không bị gián đoạn nhiều
- Khả năng truy cập: Hoàn toàn không hề có sự phân biệt giữa các vị trí hay nền tảng với nhau Tất cả mọi Client đều có khả năng đăng nhập được vào hệ thống mạng máy tính Điều này sẽ giúp cho tất cả các nhân viên đều có thể truy cập thông tin của công ty một cách dễ dàng mà không cần phải dùng một terminal mode hoặc một bộ xử lý nào khác
- Tắc nghẽn lưu lượng: Nói về nhược điểm lớn nhất của mô hình mạng Client/Server đó chính là tắc nghẽn lưu lượng Trong trường hợp có quá nhiều
Client tạo request từ cùng một Server thì nó có thể sẽ làm cho kết nối chậm hơn Trong trường hợp xấu nhất còn có thể xuất hiện hiện tượng crash Khi một Server bị quá tải thì sẽ tạo ra nhiều vấn đề khi truy cập thông tin
- Độ bền: Client/Server là mạng tập trung chính vì thế, khi Server chính xảy ra sự cố hoặc bị nhiễu thì cũng đồng nghĩa với việc toàn bộ hệ thống mạng sẽ bị gián đoạn Như vậy, bạn cần chú ý đó là mạng thiếu tính ổn định và độ bền Bạn cần chú ý khi thực hiện
- Chi phí: Chi phí được sử dụng để thiết lập và bảo trì Server trong Client/Server thường sẽ khá cao Lý do là vì các hệ thống mạng có sức mạnh rất
7 lớn cũng đồng nghĩa với việc giá để chi cho việc này là rất đắt Chính vì vậy, không phải ai cũng có khả năng chi trả và sử dụng
- Bảo trì: Khi các Server thực hiện triển khai để làm việc thì nó cũng sẽ hoạt động một cách không ngừng nghỉ Điều này đồng nghĩa với việc chúng ta cần phải quan tâm đến việc bảo trì hệ thống đúng mức Khi xảy ra bất cứ vấn đề gì cũng cần phải giải quyết ngay lập tức Vậy nên, cần phải có một nhà quản lý mạng chuyên biệt để tiến hành duy trì hoạt động của Server khi chúng được đưa vào và sử dụng
- Tài nguyên: Một điều mà chúng ta rất cần phải lưu ý đó chính là không phải tất cả tài nguyên hiện có trên Server đều sử dụng được Ví dụ một cách đơn giản đó chính là chúng ta không thể in trực tiếp được tài liệu từ trên web cũng như tiến hành chỉnh sửa bất kỳ một thông tin nào trên ổ cứng của Client cả.
Lập trình Client/Server với Socket trong C#
Socket là một giao diện lập trình ứng dụng (API – Application Programming Interface) Nó được giới thiệu lần đầu tiên trong ấn bản UNIX – BSD 4.2 dưới dạng các hàm hệ thống theo cú pháp ngôn ngữ C (socket(), bind(), connect(), send(), receive(), read(), write(), close(), ) Ngày nay, Socket được hỗ trợ trong hầu hết các hệ điều hành như MS Windows, Linux và được sử dụng trong nhiều ngôn ngữ lập trình khác nhau: như C, C++, Java, Visual Basic, Visual C++,
Socket cho phép thiết lập các kênh giao tiếp mà hai đầu kênh được đánh dấu bởi hai cổng (port) Thông qua các cổng này một quá trình có thể nhận và gởi dữ liệu với các quá trình khác
1.2.2 Số hiệu cổng của Socket Để có thể thực hiện các cuộc giao tiếp, một trong hai quá trình phải công bố số hiệu cổng của socket mà mình sử dụng Mỗi cổng giao tiếp thể hiện một địa chỉ xác định trong hệ thống Khi quá trình được gán một số hiệu cổng, nó có thể nhận dữ liệu gởi đến cổng này từ các quá trình khác Quá trình còn lại cũng được yêu cầu tạo ra một socket
Ngoài số hiệu cổng, hai bên giao tiếp còn phải biết địa chỉ IP của nhau Địa chỉ IP giúp phân biệt máy tính này với máy tính kia trên mạng TCP/IP Trong khi số hiệu cổng dùng để phân biệt các quá trình khác nhau trên cùng một máy tính
Trong hình trên, địa chỉ của quá trình B1 được xác định bằng 2 thông tin: (Host B, Port B1): Địa chỉ máy tính có thể là địa chỉ IP dạng 203.162.36.149 hay là địa chỉ theo dạng tên miền như www.cit.ctu.edu.vn
Số hiệu cổng gán cho Socket phải duy nhất trên phạm vi máy tính đó, có giá trị trong khoảng từ 0 đến 65535 (16 bits) Trong đó, các cổng từ 1 đến 1023 được gọi là cổng hệ thống được dành riêng cho các quá trình của hệ thống Các cổng mặc định của 1 số dịch vụ mạng thông dụng:
Số hiệu cổng Quá trình hệ thống
1.2.3 Xây dựng ứng dụng Client/Server với Socket
1.2.3.1 Mô hình Client/Server sử dụng socket ở chế độ có kết nối (TCP)
Hình 1.4 Mô hình Client/Server sử dụng Socket ở chế độ có kết nối (TCP)
Có thể phân thành 4 giai đoạn như sau:
Giai đoạn 1: Server tạo Socket, gán số hiệu cổng và lắng nghe yêu cầu nối kết Server sẵn sàng phục vụ Client.socket(): Server yêu cầu tạo một socket để có thể sử dụng các dịch vụ của tầng vận chuyển o bind(): Server yêu cầu gán số hiệu cổng (port) cho socket o listen(): Server lắng nghe các yêu cầu nối kết từ các Client trên cổng đã được gán
Giai đoạn 2: Client tạo Socket, yêu cầu thiết lập một nối kết với Server o socket(): Client yêu cầu tạo một socket để có thể sử dụng các dịch vụ của tầng vận chuyển, thông thường hệ thống tự động gán một số hiệu cổng còn rảnh cho socket của Client o connect(): Client gởi yêu cầu nối kết đến Server có địa chỉ IP và Port xác định
10 o accept(): Server chấp nhận nối kết của Client, khi đó một kênh giao tiếp ảo được hình thành, Client và Server có thể trao đổi thông tin với nhau thông qua kênh ảo này
Giai đoạn 3: Trao đổi thông tin giữa Client và Server o Sau khi chấp nhận yêu cầu nối kết, thông thường Server thực hiện lệnh read() và nghẽn cho đến khi có thông điệp yêu cầu (Request Message) từ Client gởi đến o Server phân tích và thực thi yêu cầu Kết quả sẽ được gởi về Client bằng lệnh write() o Sau khi gởi yêu cầu bằng lệnh write(), client chờ nhận thông điệp kết quả (ReplyMessage) từ Server bằng lệnh read()
Giai đoạn 4: Kết thúc phiên làm việc o Các câu lệnh read(), write() có thể được thưc hiện nhiều lần (ký hiệu bằng hình ellipse) o Kênh ảo sẽ bị xóa khi Server hoặc Client đóng socket bằng lệnh close()
1.2.3.2 Mô hình Client/Server sử dụng socket ở chế độ không kết nối (UDP)
Hình 1.5 Mô hình Client/Server sử dụng socket ở chế độ không kết nối
Có thể phân thành 3 giai đoạn như sau:
Giai đoạn 1: Server tạo Socket – gán số hiệu cổng o socket(): Server yêu cầu tạo một socket để có thể sử dụng các dịch vụ của tầng vận chuyển o bind(): Server yêu cầu gán số hiệu cổng cho socket
Giai đoạn 2: Client tạo Socket o socket(): Client yêu cầu tạo một socket để có thể sử dụng các dịch vụ của tầng vận chuyển, thông thường hệ thống tự động gán một số hiệu cổng còn rảnh cho socket của Client
Giai đoạn 3: Trao đổi thông tin giữa Client và Server o Sau khi tạo Socket xong, Client và Server có thể trao đổi thông tin qua lại với nhau thông qua hai hàm send() và receive() o Đơn vị dữ liệu trao đổi giữa Client và Server là các Datagram Package (Gói tin thư tín) o Protocol của ứng dụng phải định nghĩa khuôn dạng và ý nghĩa của các Datagram Package Mỗi Datagram Package có chứa thông tin về địa chỉ người gởi và người nhận (IP, Port)
Các lớp NET cơ bản trong lập trình mạng
Các lớp này được cung cấp trong hai System.Net và System.Net.Sockets Hai namespace này chứa rất nhiều lớp dùng trong lập trình mạng, nhưng ta chỉ quan tâm đến các lớp sau:
IPAddress System.Net Provides an Internet Protocol (IP) address
IPEndPoint System.Net Represents a network endpoint as an IP address and a port number
TcpListener System.Net.Sockets Listens for connections from TCP network clients
Socket System.Net.Sockets Implements the Berkeley sockets interface
TcpClient System.Net.Sockets Provides Client connections for TCP network services
NetworkStream System.Net.Sockets Provides the underlying stream of data for network access
Kết nối Server/Client với TCP/IP
Mã hóa bí mật
1.3.1 Giới thiệu về bảo mật thông tin
Bảo mật thông tin là duy trì tính bảo mật, tính toàn vẹn toàn diện và tính sẵn sàng cho toàn bộ thông tin Ba yếu tố không thể tách rời trong việc bảo mật từ A đến Z thông tin là:
Tính bảo mật: Đảm bảo thông tin đó là duy nhất, những người muốn tiếp cận phải được phân quyền truy cập
Tính toàn vẹn: Bảo vệ sự hoàn chỉnh toàn diện cho hệ thống thông tin
Tính chính xác: Thông tin đưa ra phải chính xác, đầy đủ, không được sai lệch hay không được vi phạm bản quyền nội dung
Tính sẵn sàng: Việc bảo mật thông tin luôn phải sẵn sàng, có thể thực hiện bất cứ đâu, bất cứ khi nào
1.3.2 Giới thiệu về mã hóa thông tin
Mã hóa thông tin là một hình thức biến đổi dữ liệu thành một dạng dữ liệu khác có ý nghĩa khác với dữ liệu trước khi bị biến đổi ban đầu, với mục đích chỉ
14 cho phép một số người nhất định có thể đọc được dữ liệu ban đầu, thông qua việc giải mã dữ liệu sau khi biến đổi
Hay nói cách khác, mã hóa là biến dữ liệu ban đầu A thành dữ liệu B, và việc đọc dữ liệu A sẽ thông qua việc giải mã dữ liệu B về A
Mã hóa khóa bí mật, còn gọi là mã hóa đối xứng hay mã hóa khóa riêng, là sử dụng một khóa cho cả quá trình mã hóa (được thực hiện bởi người gửi thông tin) và quá trình giải mã (được thực hiện bởi người nhận)
Quá trình mã hóa khóa bí mật được thực hiện như sau:
Một khách hàng (Anne) muốn gửi tới người bán hàng (Bob) một đơn đặt hàng, nhưng chỉ muốn một mình Bob có thể đọc được Anne mã hóa đơn đặt hàng (dưới dạng văn bản gốc) của mình bằng một mã khóa rồi gửi đơn đặt hàng đã mã hóa đó cho Bob
Tất nhiên, ngoài Bob và Anne ra, không ai có thể đọc được nội dung thông điệp lộn xộn đã mã hóa
Khi nhận được thông điệp mã hóa, Bob giải mã thông điệp này bằng khóa giải mã và đọc các thông tin của đơn đặt hàng Điều đáng chú ý là trong kĩ thuật mã hóa khóa bí mật, khóa để mã hóa thông điệp và khóa để giải mã thông điệp giống như nhau
Người gửi thông điệp sử dụng một khóa mật mã để mã hóa thông điệp và người nhận thông điệp cũng sử dụng một khóa như vậy để đọc mật mã hoặc giải mã thông điệp
Kĩ thuật mã hóa khóa bí mật này đã được IBM phát triển, áp dụng cho các cơ quan của Chính Phủ Mỹ năm 1977 được gọi là Tiêu chuẩn mã hóa dữ liệu (DES – data encryption standard)
1.3.4 Mã hóa bí mật trong C#
Trong mã hóa thông tin, C# hỗ trợ thư viện System.Security.Cryptography có chứa rất nhiều phương thức về mã hóa, trong đó có mã hóa bí mật
Các bước của quá trình mã hóa:
Khai báo 2 đối tượng TripleDESCryptoServiceProvider và
Chuyển chuỗi cần mã hóa và key về kiểu byte[]
Gán thuộc tính key của đối tượng TripleDESCryptoServiceProvider là key vừa chuyển đổi về byte[] và thuộc tính mode là CipherMode.ECB
Sử dụng phương thức CreateEncryptor để mã hóa
Chuyển đổi đối tượng đã mã hóa về kiểu chuỗi
Các bước của quá trình giải mã:
Khai báo 2 đối tượng TripleDESCryptoServiceProvider và MD5CryptoService Provider
Chuyển chuỗi cần mã hóa và key về kiểu byte[]
Gán thuộc tính key của đối tượng TripleDESCryptoServiceProvider là key vừa chuyển đổi về byte[] và thuộc tính mode là CipherMode.ECB
Sử dụng phương thức CreateDecryptor để giải mã
Chuyển đổi đối tượng đã giải mã về kiểu chuỗi
GIỚI THIỆU VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ SOA VÀ CÔNG CỤ PHÁT TRIỂN HƯỚNG DỊCH VỤ WCF
Giới thiệu về kiến trúc hướng dịch vụ SOA
Kiến trúc hướng dịch vụ (SOA – Service Oriented Architecture) là chủ đề mới trong lĩnh vực công nghệ thông tin và được sự quan tâm của nhiều nhà cung cấp dịch vụ Công nghệ thông tin (CNTT) và truyền thông lớn trên thế giới như IBM, HP, BEA, Oracle, SAP và Microsoft
SOA có thể xây dựng và thực thi các hệ thống CNTT một cách dễ dàng và nhanh chóng bằng cách trực tiếp đáp ứng và tiếp cận các mục đích của một tổ chức SOA tích hợp quy trình nghiệp vụ và CNTT vào một framework mở, ở đó người ta có thể thêm vào các dịch vụ
Service là thao tác nghiệp vụ đơn giản, được thực hiện lặp lại nhiều lần Service cung cấp một giá trị hay một nội dung xác định, có thể là dịch vụ hay chức năng
VD: tra cứu thuê bao, mở tài khoản mới, hay truy cập 1 thực thể trong CSDL
Ta có thể hình dung service như sau:
Hình 2.1 Mô tả định nghĩa Service
Mỗi service có thể chỉ là một công việc (task) được thực hiện bởi một cá nhân hay là một quy trình con hoặc cũng có thể là toàn bộ một quy trình logic, được viện dẫn đến nhiều lần
Cách thức phân tích, thiết kế xây dựng các ứng dụng phần mềm lấy service làm trung tâm, làm thành phần cơ bản, cốt lõi Việc xây dựng các ứng dụng phần mềm hướng dịch vụ thực hiện bằng cách phân tích, thiết kế và lắp ráp các service với nhau
2.1.1.3 Kiến trúc hướng dịch vụ SOA
Trong vài năm gần đây SOA đã bắt đầu được nhắc đến nhiều hơn và có rất nhiều khái niệm SOA được biết đến như:
SOA – mô hình kiến trúc hướng dịch vụ là tập hợp của các Service, ở đó chúng giao tiếp với nhau
SOA là một cấu trúc tích hợp các service lại với nhau
SOA được hiểu là một cấu trúc hỗ trợ cho việc giao tiếp giữa các service, dựa trên các nội dung chính về các ứng dụng frontend, dịch vụ, kho lưu trữ dịch vụ, và các kết nối dịch vụ
SOA được hiểu là framework (nền tảng) cho việc xây dựng và tích hợp các quy trình nghiệp vụ, các ứng dụng dưới sự hỗ trợ của cơ sở hạ tầng CNTT Theo khái niệm của IBM thì: SOA là kiến trúc hướng dịch vụ cho phép khả năng linh hoạt trong việc thể hiện các thành phần của quy trình nghiệp vụ và cơ sở hạ tầng CNTT, có thể được tái sử dụng và kết hợp với nhau
Ngoài ra, tài liệu “Enterprise SOA - SOA Best Practices” trình bày định nghĩa SOA thông qua 4 thành phần cơ bản như sau: Kiến trúc hướng dịch vụ SOA là kiến trúc công nghệ thông tin của doanh nghiệp bao gồm 4 thành phần: application frontends, service, service repository và service bus Trong đó, một service bao gồm contract, 1 hoặc nhiều interface và implementation
Hình 2.2 Các thành phần trong định nghĩa của SOA
Application frontend (Các ứng dụng giao tiếp với người dùng): là ứng dụng giao tiếp với người sử dụng Chúng khởi tạo và điều khiển các hoạt động của hệ thống phần mềm doanh nghiệp
Service (Dịch vụ): là thành phần phần mềm thực hiện một chức năng riêng biệt, độc lập Bao gồm cài đặt cụ thể để cung cấp logic nghiệp vụ, dữ liệu được thực hiện bằng các ngôn ngữ và kỹ thuật lập trình khác nhau
Service repository (Kho lưu trữ các service): cung cấp khả năng lưu trữ, tìm kiếm các services và có được các thông tin mô tả và sử dụng service từ service contract
Service bus: Thành phần cung cấp khả năng kết nối linh hoạt, lỏng lẻo các thành phần tham gia SOA, bao gồm các services và các ứng dụng không đồng nhất
2.1.1.4 Kiến trúc tổng thể SOA Để có cái nhìn tổng quát về SOA, chúng ta cùng tìm hiểu kiến trúc tổng thế của nó Kiến trúc SOA là một kiểu kiến trúc phân tầng, được thể hiện qua hình vẽ sau:
Hình 2.3 Kiến trúc tổng tổng SOA
Nhìn từ dưới lên ta có thể thấy được kiến trúc SOA như sau:
Tầng dưới cùng là tầng chứa các ứng dụng con trong hệ thống CNTT của doanh nghiệp
Tầng phía trên nó là tầng chứa service thực thi
Tầng tiếp theo là tầng Orchestration (kết hợp) là sự kết hợp các service thực thi theo một quy trình
Tầng trên của tầng Orchestration là tầng chứa các service nghiệp vụ
Tầng trên của tầng các service nghiệp vụ thể hiện toàn bộ quy trình hay luồng công việc của hệ thống doanh nghiệp
Tầng trên cùng trong kiến trúc SOA là tầng các ứng dụng front-end
2.1.2 Những đặc điểm và lợi ích của SOA
2.1.2.1 Các đặc điểm của SOA
Tăng khả năng cộng tác
Tăng cường tính mềm dẻo của quy trình nghiệp vụ
Cung cấp thống nhất thao tác truy cập dữ liệu
Tăng cường khả năng kết nối không đồng nhất
Tăng khả năng tái sử dụng các services
Với các đặc điểm trên của kiến trúc hướng dịch vụ SOA, kiến trúc SOA sẽ mang lại cho doanh nghiệp rất nhiều lợi ích khi doanh nghiệp triển khai thành công kiến trúc này:
Về công nghệ thông tin
Giảm thời gian và công sức xây dựng lại ứng dụng phần mềm
Tăng tính linh hoạt để thay đổi hoạt động của hệ thống phức
Giảm thiểu chi phí về thời gian, nhân lực, vật lực để bảo trì các ứng dụng phần mềm
Giảm thiểu rủi ro đối với các dự án lớn, phức tạp
Về quy trình nghiệp vụ
Mềm dẻo trong việc xây dựng quy trình nghiệp vụ
Tăng cường khả năng trao đổi thông tin giữa doanh nghiệp và các khách hàng và đối tác thương mại
Dễ dàng và nhanh chóng cải tiến quy trình nghiệp vụ, góp phần nâng cao hiệu quả sản xuất, kinh doanh của doanh nghiệp
Vấn đề kết nối (coupling) ám chỉ đến một số ràng buộc giữa cách module với nhau Có hai loại coupling là rời (loose) và chặt (tight) Các module có tính loose coupling có một số ràng buộc được mô tả rõ ràng trong khi các module có tính tight coupling lại có nhiều ràng buộc không thể biết trước Hầu như mọi kiến trúc phần mềm đều hướng đến tính loose coupling giữa các module Mức độ kết dính của mỗi hệ thống ảnh hưởng trực tiếp đến khả năng chỉnh sửa hệ thống của chính nó Kết dính càng chặt bao nhiêu thì càng có nhiều thay đổi liên quan cần chỉnh sửa ở phía sử dụng dịch vụ mỗi khi có thay đổi nào đó xảy ra Mức độ coupling tăng dần khi khi bên sử dụng dịch vụ càng cần biết nhiều thông tin ngầm định của bên cung cấp dịch vụ để sử dụng dịch vụ được cung cấp Nghĩa là nếu bên sử dụng dịch vụ biết vị trí và chi tiết định dạng dữ liệu của
Công cụ phát triển hướng dịch vụ WCF
WCF là công nghệ nền tảng nhằm thống nhất nhiều mô hình lập trình giao tiếp được hỗ trợ trong NET 2.0 thành một mô hình duy nhất Vào tháng 11 năm
2005, NET 2.0 được Microsoft phát hành trong đó có cung cấp các hàm API riêng biệt cho các liên lạc dựa trên SOAP để tối đa hoá sự làm việc giữa các nền tảng sử dụng Web Services, đồng thời NET 2.0 còn cung cấp các API để tối ưu việc liên lạc dựa trên mã nhị phân giữa các ứng dụng chạy trên hệ thống Windows gọi là NET Remoting, các API cho các giao dịch, và API cho liên lạc dị bộ WCF thống nhất các API này thành một mô hình duy nhất nhằm đáp ứng mô hình lập trình hướng dịch vụ
WCF có thể sử dụng các bản tin SOAP giữa hai tiến trình, do đó làm cho các ứng dụng dựa trên WCF có thể làm việc với các tiến trình khác thông qua việc giao tiếp sử dụng bản tin SOAP Khi một tiến trình WCF liên lạc với một tiến trình không là WCF, các bản tin SOAP được mã hoá trên cơ sở XML, nhưng khi nó liên lạc với một tiến trình WCF khác, bản tin SOAP có thể được tối ưu hoá dựa trên mã hoá nhị phân
2.2.2 Tại sao lại sử dụng WCF
Như phần trên đã trình bày, NET 2.0 hỗ trợ rất nhiều phương pháp liên lạc giữa các ứng dụng khác nhau nhằm vào các mục tiêu khác nhau Các phương pháp liên lạc này khá phức tạp và phải mất nhiều thời gian để làm chủ được công nghệ Tuy nhiên kiến thức thu được từ việc triển khai một phương pháp ít có khả năng dùng được khi làm việc với phương pháp khác
Với việc ra đời của WCF, mọi phương pháp liên lạc trước kia đều có thể thực hiện trên WCF Do vậy nhà phát triển chỉ cần làm chủ được công nghệ WCF là có thể xây dựng các ứng dụng một cách nhanh chóng
WCF là một mô hình lập trình cho phép nhà phát triển xây dựng các giải pháp dịch vụ đảm bảo tính ổn định, và bảo mật và thậm chí là đảm bảo giao dịch Nó làm đơn giản hoá việc phát triển các ứng dụng nối kết và đưa ra cho nhà phát triển những giá trị mà có thể họ chưa nhận ra ngay, đó là cách tiếp cận phát triển hệ thống Client/Server thống nhất, đơn giản, và quản lý được Do WCF được xây dựng trên cơ sở của NET Framework 2.0 CLR, nó là tập các lớp cho phép các nhà phát triển xây dựng các ứng dụng hướng dịch vụ bằng môi trường lập trình quen thuộc của họ như VB.NET hay C#
Hình sau mô tả các lớp chủ yếu trong kiến trúc của Windows Communication Foundation (WCF)
Hình 2.5 Kiến trúc WCF 2.2.3.1 Contracts
Các contract trong WCF cũng giống như các hợp đồng/hiệp định mà bạn ký trong đời sống thật Một hợp đồng bạn ký có thể chứa các thông tin như kiểu công việc bạn sẽ làm, và những thông tin mà bạn muốn đưa ra cho các bên khác WCF contract cũng chứa các thông tin tương tự như vậy Contract định nghĩa các đặc tả trong hệ thống bản tin Thông thường có các loại contract sau:
Contract dữ liệu mô tả các tham số cho các bản tin mà một dịch vụ có thể tạo ra hay sử dụng Các tham số bản tin được định nghĩa bằng các tài liệu sử dụng ngôn ngữ đặc tả XML Schema (XSD), điều này cho phép các hệ thống hiểu XML có thể xử lý tài liệu dễ dàng Các dịch vụ khi liên lạc với nhau có thể không cần đồng ý với nhau về các kiểu, nhưng cần đồng ý về contract dữ liệu, nghĩa là đồng ý về các tham số và các kiểu trả về
Contract bản tin định nghĩa các phần có trong bản tin sử dụng các giao thức SOAP, và nó cho phép điều khiển sâu hơn tới các phần trong bản tin khi có yêu cầu sự chính xác như vậy
Contract dịch vụ đặc tả chi tiết các phương thức của dịch vụ, và được phân phối như là một giao diện trong các ngôn ngữ lập trình như Visual Basic hay Visual C# Có thể hình dung về contract dịch vụ một cách gián tiếp như sau:
“Đây là các kiểu dữ liệu của các bản tin của tôi, đây là nơi tôi cung cấp, và đây là các giao thức mà tôi có thể liên lạc”
Các chính sách và các kết nối (bindings) mô tả các điều kiện cần có để giao tiếp với một dịch vụ Các chính sách sẽ bao gồm cả các yêu cầu về bảo mật và các điều kiện khác cần phải có khi kết nối với một dịch vụ
Lớp dịch vụ thực thi chứa các hành xử sẽ xảy ra trong quá trình thực hiện của dịch vụ, nghĩa là các hành xử thực thi của dịch vụ Ta sẽ thấy một số các hành xử như sau:
Throttling behavior: Điều khiển luồng nhằm quy định xem có bao nhiêu bản tin được xử lý
Error behavior: Hành xử lỗi quy định những hành động khi lỗi xảy ra trong hệ thống
Metadata behavior: Hành xử với các siêu dữ liệu quy định xem làm thế nào và khi nào thì các siêu dữ liệu được đưa ra bên ngoài dịch vụ
Instance behavior: Hành xử thực thể quy định xem có bao nhiêu thực thể của dịch vụ đó được chạy
Transaction behavior: Hành xử giao dịch cho phép việc rollback các giao dịch nếu xảy ra lỗi
Message inspection: Kiểm tra bản tin đem lại cho dịch vụ khả năng kiểm tra tất cả hay một số phần của bản tin
Dispatch behavior: Khi một bản tin được xử lý bởi nền tảng WCF, dịch vụ
Dispatch behavior xác định xem bản tin được xử lý như thế nào
Concurrency behavior: Hành xử đồng thời xác định xem việc xử lý thế nào với việc đa luồng của mỗi dịch vụ hay mỗi thực thể của dịch vụ Hành xử này giúp cho việc điều khiển số lượng luồng có thể truy nhập tới một thực thể của dịch vụ
KHẢO SÁT VÀ PHÂN TÍCH HỆ THỐNG
Khảo sát hệ thống
Một khách sạn ở tại Tam Kỳ cần một phần mềm quản lý nhằm giúp nhân viên và chủ dễ dàng cho thuê và quản lý phòng Khách sạn ấy được xây dựng theo kiểu nhà nhiều tầng, chia làm nhiều phòng nhỏ và 4 loại phòng khác nhau Ngoài chủ thì còn có 2 nhân viên Chủ khách sạn là người được quyền thống kê doanh thu và thêm nhân viên vào phần mềm khi cần thiết Còn khách hàng thì do nhân viên thực hiện thao tác dữ liệu Ngoài ra, phần mềm cần có những chức năng chính sau:
Quản lý đơn vị cung cấp
Xem/Hủy phiếu đặt phòng
Xem hóa đơn thuê phòng
Ngoài những yêu cầu về chức năng, hệ thống còn phải đảm bảo các yêu cầu phi chức năng:
Hệ thống phải hoạt động theo mô hình Client/Server
Lập trình bằng công cụ phát triển hướng dịch vụ WCF trong C# và hệ quản trị cơ sở dữ liệu SQL Server 2019
Hệ thống phải xử lý dữ liệu theo thời gian thực
Quản lý đơn vị cung cấp
Xem/Hủy phiếu đặt phòng
Xem hóa đơn thuê phòng
R2.3 Cập nhập thông tin nhân viên
R3 Quản lý lương nhân viên
R3.2 Cập nhập thông tin lương
R3.3 Xóa tất cả lương trong tháng
R4.3 Cập nhập thông tin loại phòng
R4.5 Xem danh sách loại phòng
R5.3 Cập nhập thông tin phòng
R5.6 Xem danh sách thiết bị
R6.3 Cập nhập thông tin thiết bị
R7 Quản lý đơn vị cung cấp
R7.1 Thêm đơn vị cung cấp
R7.2 Tìm kiếm đơn vị cung cấp
R7.3 Cập nhập thông tin đơn vị cung cấp
R7.4 Xóa đơn vị cung cấp
R8.3 Cập nhập thông tin dịch vụ
R8.5 Xem danh sách dịch vụ
R10.3 Cập nhập thông tin khách hàng
R10 Quản lý phiếu đặt phòng
R11.1 Tìm kiếm phiếu đặt phòng
R11.2 Cập nhập phiếu đặt phòng
R11 Xem hóa đơn thuê phòng
R12 Xem hóa đơn nhập dịch vụ
R13 Quản lý đặt, thuê/trả phòng
R15.1 Báo cáo lương nhân viên
R15.3 Thống kê loại phòng khách hay thuê
R15.4 Thống kê hóa đơn thuê phòng
R15.5 Thống kê lượng tiền ra vào
3.1.4 Đặc tính từng người dùng
Người quản lý: là người chủ của khách sạn, quản lý tất cả các thông tin về nhân viên, lương nhân viên, loại phòng, phòng, thiết bị, dịch vụ và báo cáo/thống kê
Nhân viên: là người làm trong khách sạn, quản lý thông tin về khách hàng, phiếu đặt phòng, hóa đơn, đặt/thuê/trả phòng cho khách
Người dùng: là đại diện cho nhân viên và người quản lý trong phần mềm để thực hiện các chức năng quản lý hệ thống
Khách hàng: là người đến ở tại khách sạn, chọn phòng, thuê, thanh toán và nhận hóa đơn
3.1.5 Yêu cầu phi chức năng
Hoạt động hoạt động theo mô hình Client – Server:
Các máy Client dành cho nhân viên và người quản lý chỉ chứa phần mềm để sử dụng và mọi thao tác phải gửi về máy Server để xử lý
1 máy Server chứa service và cơ sở dữ liệu để xử lý tất cả yêu cầu của các máy Client gửi đến và gửi kết quả xử lý về cho máy Client
Lập trình bằng công cụ phát triển hướng dịch vụ WCF trong C#
Hệ quản trị cơ sở dữ liệu: SQL Server 2019
Hệ thống xử lý dữ liệu theo thời gian thực và có sự đồng bộ dữ liệu giữa các máy Client khi người dùng cập nhập dữ liệu.
Phân tích hệ thống
Quản lý lương nhân viên
Quản lý đơn vị cung cấp
Xem thông tin thiết bị
Quản lý phiếu đặt phòng
Xem hóa đơn thuê phòng
Quản lý đặt/thuê, trả phòng
Hình 3.1 Sơ đồ usecase tổng quát Đặc tả usecase:
Bước 1: Mở form đăng nhập
Bước 2: Nhập tên đăng nhập và mật khẩu
Bước 3: Bấm nút đăng nhập
Bước 4: Yêu cầu service kiểm tra tên đăng nhập và mật khẩu
Bước 5: Kiểm tra tên đăng nhập và mật khẩu
Bước 7: Thông báo cho người dùng
Bước 8: Chuyển sang form hệ thống
UC_Quản lý nhân viên
Bước 1: Đăng nhập vào hệ thống
Bước 2: Chuyển sang form hệ thống
Bước 3: Chọn chức năng thêm nhân viên
Bước 4: Chuyển sang form thêm nhân viên
Bước 5: Nhập đầy đủ thông tin của tất cả nhân viên
Bước 7: Yêu cầu service thêm tất cả nhân viên
Bước 9: Tạo tài khoản cho nhân viên
Bước 11: Thông báo cho người quản lý
UC_Tìm kiếm nhân viên
Bước 1: Đăng nhập vào hệ thống
Bước 2: Chuyển sang form hệ thống
Bước 3: Chọn chức năng tìm kiếm nhân viên
Bước 4: Chuyển sang form tìm kiếm nhân viên
Bước 5: Nhập tên nhân viên cần tìm kiếm
Bước 6: Bấm nút tìm kiếm
Bước 7: Yêu cầu service tìm kiếm nhân viên theo tên
Bước 8: Tìm kiếm nhân viên theo tên
Bước 9: Gửi kết quả tìm kiếm
Bước 10: Hiển thị kết quả
UC_Cập nhập thông tin nhân viên
Bước 1: Đăng nhập vào hệ thống
Bước 2: Chuyển sang form hệ thống
Bước 3: Chọn chức năng tìm kiếm nhân viên
Bước 4: Chuyển sang form tìm kiếm nhân viên
Bước 5: Tìm kiếm nhân viên cần cập nhập
Bước 7: Chuyển sang form cập nhập nhân viên
Bước 8: Load thông tin nhân viên
Bước 9: Chỉnh sửa thông tin nhân viên
Bước 11: Yêu cầu đến service cập nhập thông tin nhân viên
Bước 12: Cập nhập thông tin nhân viên
Bước 14: Thông báo cho người quản lý
Bước 15: Load lại danh sách nhân viên đã tìm kiếm
Bước 1: Đăng nhập vào hệ thống
Bước 2: Chuyển sang form hệ thống
Bước 3: Chọn chức năng tìm kiếm nhân viên
Bước 4: Chuyển sang form tìm kiếm nhân viên
Bước 5: Tìm kiếm nhân viên cần xóa
Bước 7: Hiển thị thông báo xác nhận xóa
Bước 9: Yêu cầu đến service xóa nhân viên
Bước 11: Hủy phiên đăng nhập của nhân viên
Bước 13: Thông báo cho người quản lý
Bước 14: Load lại danh sách nhân viên đã tìm kiếm
UC_Quản lý đặt, thuê/trả phòng
Actor: Nhân viên, khách hàng
Bước 1: Yêu cầu đặt phòng
Bước 2: Đăng nhập vào hệ thống
Bước 3: Chuyển sang form hệ thống
Bước 4: Chọn phòng khách đặt
Bước 5: Hiển thị thông báo xác nhận có thêm mới khách hàng
Bước 6: Xác nhận có thêm mới khách hàng
Bước 7: Chuyển sang form đặt, thuê phòng
Bước 8: Nhập đầy đủ thông tin
Bước 9: Bấm nút đặt phòng
Bước 10: Yêu cầu service đặt phòng
Bước 12: Load lại phòng ở máy nhân viên
Bước 14: Trở về form hệ thống
Actor: Nhân viên, khách hàng
Bước 1: Yêu cầu thuê phòng
Bước 2: Đăng nhập vào hệ thống
Bước 3: Chuyển sang form hệ thống
Bước 4: Chọn phòng khách thuê
Bước 5: Hiển thị thông báo xác nhận có thêm mới khách hàng
Bước 6: Xác nhận có thêm mới khách hàng
Bước 7: Chuyển sang form đặt, thuê phòng
Bước 8: Chuyển sang tab thuê phòng
Bước 9: Nhập đầy đủ thông tin
Bước 10: Bấm nút thuê phòng
Bước 11: Yêu cầu service thuê phòng
Bước 13: Load lại phòng ở máy nhân viên
Bước 15: Trở về form hệ thống
Actor: Nhân viên, khách hàng
Bước 1: Yêu cầu trả phòng
Bước 2: Đăng nhập vào hệ thống
Bước 3: Chuyển sang form hệ thống
Bước 4: Chọn phòng khách muốn trả
Bước 5: Chuyển sang form gọi dịch vụ
Bước 6: Yêu cầu service load thông tin các dịch vụ đã gọi
Bước 7: Load thông tin các dịch vụ đã gọi
Bước 9: Hiển thị kết quả
Bước 10: Bấm nút thanh toán
Bước 11: Hiển thị thông báo xác nhận
Bước 13: Yêu cầu đến service trả phòng
Bước 16: Chuyển sang form in hóa đơn
Bước 17: Yêu cầu service lấy dữ liệu hóa đơn
Bước 18: Lấy dữ liệu hóa đơn
Bước 20: Hiển thị hóa đơn
Bước 23: Đưa hóa đơn cho khách hàng
Actor: Nhân viên, khách hàng
Bước 1: Yêu cầu gọi dịch vụ
Bước 2: Đăng nhập vào hệ thống
Bước 3: Chuyển sang form hệ thống
Bước 5: Chuyển sang form gọi dịch vụ
Bước 6: Yêu cầu service load thông tin các dịch vụ đã gọi
Bước 7: Load thông tin các dịch vụ đã gọi
Bước 9: Hiển thị kết quả
Bước 10: Chọn dịch vụ cần gọi
Bước 12: Yêu cầu đến service gọi dịch vụ
Bước 15: Yêu cầu service load thông tin các dịch vụ đã gọi
Bước 16: Load thông tin các dịch vụ đã gọi
Bước 18: Hiển thị kết quả
UC_Cập nhập dịch vụ
Actor: Nhân viên, khách hàng
Bước 1: Yêu cầu cập nhập dịch vụ đã gọi
Bước 2: Đăng nhập vào hệ thống
Bước 3: Chuyển sang form hệ thống
Bước 5: Chuyển sang form gọi dịch vụ
Bước 6: Yêu cầu service load thông tin các dịch vụ đã gọi
Bước 7: Load thông tin các dịch vụ đã gọi
Bước 9: Hiển thị kết quả
Bước 10: Chọn dịch vụ cần cập nhập
Bước 11: Chỉnh sửa thông tin
Bước 13: Yêu cầu đến service cập nhập dịch vụ đã gọi
Bước 14: Cập nhập dịch vụ đã gọi
Bước 16: Yêu cầu service load thông tin các dịch vụ đã gọi
Bước 17: Load thông tin các dịch vụ đã gọi
Bước 19: Hiển thị kết quả
UC_Hủy dịch vụ đã gọi
Actor: Nhân viên, khách hàng
Bước 1: Yêu cầu hủy dịch vụ đã gọi
Bước 2: Đăng nhập vào hệ thống
Bước 3: Chuyển sang form hệ thống
Bước 4: Chọn phòng khách muốn hủy dịch vụ
Bước 5: Chuyển sang form gọi dịch vụ
Bước 6: Yêu cầu service load thông tin các dịch vụ đã gọi
Bước 7: Load thông tin các dịch vụ đã gọi
Bước 9: Hiển thị kết quả
Bước 10: Chọn dịch vụ muốn hủy
Bước 12: Hiển thị thông báo xác nhận
Bước 14: Yêu cầu đến service hủy dịch vụ
Bước 17: Yêu cầu service load thông tin các dịch vụ đã gọi
Bước 18: Load thông tin các dịch vụ đã gọi
Bước 20: Hiển thị kết quả
UC_Báo cáo lương nhân viên
Bước 1: Đăng nhập vào hệ thống
Bước 2: Chuyển sang form hệ thống
Bước 3: Chọn chức năng báo cáo lương nhân viên
Bước 4: Chuyển sang form thống kê
Bước 5: Yêu cầu service lấy dữ liệu lương nhân viên
Bước 6: Lấy dữ liệu lương nhân viên
Bước 8: Hiển thị kết quả
Chi tiết hóa đơn nhập
Chi tiết hóa đơn thuê
Hình 3.2 Sơ đồ class 3.2.1.4 Sơ đồ tuần tự
Hình 3.3 Sơ đồ tuần tự UC_Đăng nhập
UC_Quản lý nhân viên
Hình 3.4 Sơ đồ tuần tự UC_Thêm nhân viên
UC_Tìm kiếm nhân viên
Hình 3.5 Sơ đồ tuần tự UC_Tìm kiếm nhân viên
UC_Cập nhập thông tin nhân viên
Hình 3.6 Sơ đồ tuần tự UC_Cập nhập thông tin nhân viên
Hình 3.7 Sơ đồ tuần tự UC_Xóa nhân viên
UC_Quản lý đặt, thuê/trả phòng
Hình 3.8 Sơ đồ tuần tự UC_Đặt phòng
Hình 3.9 Sơ đồ tuần tự UC_Thuê phòng
Hình 3.10 Sơ đồ tuần tự UC_Trả phòng
Hình 3.11 Sơ đồ tuần tự UC_Gọi dịch vụ
UC_Cập nhập dịch vụ
Hình 3.12 Sơ đồ tuần tự UC_Cập nhập dịch vụ
UC_Hủy dịch vụ đã gọi
Hình 3.13 Sơ đồ tuần tự UC_Hủy dịch vụ
UC_Báo cáo lương nhân viên
Hình 3.14 Sơ đồ tuần tự UC_Báo cáo lương nhân viên 3.2.1.5 Sơ đồ cộng tác
Hình 3.15 Sơ đồ cộng tác UC_Đăng nhập
UC_Quản lý nhân viên
Hình 3.16 Sơ đồ cộng tác UC_Thêm nhân viên
UC_Tìm kiếm nhân viên
Hình 3.17 Sơ đồ cộng tác UC_Tìm kiếm nhân viên
UC_Cập nhập thông tin nhân viên
Hình 3.18 Sơ đồ cộng tác UC_Cập nhập thông tin nhân viên
Hình 3.19 Sơ đồ cộng tác UC_Xóa nhân viên
UC_Quản lý đặt, thuê/trả phòng
Hình 3.20 Sơ đồ cộng tác UC_Đặt phòng
Hình 3.21 Sơ đồ cộng tác UC_Thuê phòng
Hình 3.22 Sơ đồ cộng tác UC_Trả phòng
Hình 3.23 Sơ đồ cộng tác UC_Gọi dịch vụ
UC_Cập nhập dịch vụ
Hình 3.24 Sơ đồ cộng tác UC_Cập nhập dịch vụ
UC_Hủy dịch vụ đã gọi
Hình 3.25 Sơ đồ cộng tác UC_Hủy dịch vụ đã gọi
UC_Báo cáo lương nhân viên
Hình 3.26 Sơ đồ cộng tác UC_Báo cáo lương nhân viên
Hình 3.27 Sơ đồ trạng thái class người dùng
Hình 3.28 Sơ đồ trạng thái class nhân viên
Hình 3.29 Sơ đồ trạng thái class thiết bị
Hình 3.30 Sơ đồ trạng thái class đơn vị cung cấp
Hình 3.31 Sơ đồ trạng thái class dịch vụ
Hình 3.32 Sơ đồ trạng thái class phòng
Hình 3.33 Sơ đồ trạng thái class loại phòng
Hình 3.34 Sơ đồ trạng thái class khách hàng
Hình 3.35 Sơ đồ trạng thái class hóa đơn nhập
Hình 3.36 Sơ đồ trạng thái class phiếu đặt phòng
Hình 3.37 Sơ đồ trạng thái class hóa đơn thuê
Hình 3.38 Sơ đồ hoạt động UC_Đăng nhập
UC_Quản lý nhân viên
Hình 3.39 Sơ đồ hoạt động UC_Thêm nhân viên
UC_Tìm kiếm nhân viên
Hình 3.40 Sơ đồ hoạt động UC_Tìm kiếm nhân viên
UC_Cập nhập thông tin nhân viên
Hình 3.41 Sơ đồ hoạt động UC_Cập nhập thông tin nhân viên
Hình 3.42 Sơ đồ hoạt động UC_Xóa nhân viên
UC_Quản lý đặt, thuê/trả phòng
Hình 3.43 Sơ đồ hoạt động UC_Đặt phòng
Hình 3.44 Sơ đồ hoạt động UC_Thuê phòng
Hình 3.45 Sơ đồ hoạt động UC_Trả phòng
Hình 3.46 Sơ đồ hoạt động UC_Gọi dịch vụ
UC_Cập nhập dịch vụ
Hình 3.47 Sơ đồ hoạt động UC_Cập nhập dịch vụ
UC_Hủy dịch vụ đã gọi
Hình 3.48 Sơ đồ hoạt động UC_Cập nhập dịch vụ đã gọi
UC_Báo cáo lương nhân viên
Hình 3.49 Sơ đồ hoạt động UC_Báo cáo lương nhân viên
3.2.2.2 Sơ đồ dữ liệu quan hệ
Hình 3.51 Sơ đồ dữ liệu quan hệ
THIẾT KẾ VÀ TRIỂN KHAI HỆ THỐNG
Thiết kế hệ thống
4.1.1 Thiết kế cơ sở dữ liệu
Cơ sở dữ liệu bảng nguoidung:
Tên thuộc tính Kiểu dữ liệu Mô tả
Tendangnhap Varchar(50) Tên đăng nhập
Cơ sở dữ liệu bảng nhanvien:
Tên thuộc tính Kiểu dữ liệu Mô tả
Manv Varchar(10) Mã nhân viên
Tennv Nvarchar(100) Tên nhân viên
SDT Varchar(10) Số điện thoại
Calamviec Int Ca làm việc
Luongcoban Decimal(18,0) Lương cơ bản
Hesoluong Float Hệ số lương
Tendangnhap Varchar(50) Tên đăng nhập
Cơ sở dữ liệu bảng khachhang:
Tên thuộc tính Kiểu dữ liệu Mô tả
Makh Varchar(50) Mã khách hàng
Tenkh Nvarchar(100) Tên khách hàng
CMND Varchar(50) Chứng minh nhân dân
Cơ sở dữ liệu bảng phong:
Tên thuộc tính Kiểu dữ liệu Mô tả
Cơ sở dữ liệu bảng loaiphong:
Tên thuộc tính Kiểu dữ liệu Mô tả
Cơ sở dữ liệu bảng thietbi:
Tên thuộc tính Kiểu dữ liệu Mô tả
Matb Varchar(50) Mã thiết bị
Tentb Nvarchar(100) Tên thiết bị
DVT Nvarchar(100) Đơn vị tính
Cơ sở dữ liệu bảng tttp:
Tên thuộc tính Kiểu dữ liệu Mô tả
Matb Varchar(50) Mã thiết bị
Cơ sở dữ liệu bảng dichvu:
Tên thuộc tính Kiểu dữ liệu Mô tả
Madv Varchar(50) Mã dịch vụ
Tendv Nvarchar(100) Tên dịch vụ
DVT Nvarchar(100) Đơn vị tính
Cơ sở dữ liệu bảng luong:
Tên thuộc tính Kiểu dữ liệu Mô tả
Mapluong Varchar(50) Mã phiếu lương
Manv Varchar(50) Mã nhân viên
Ngaytinhluong Smalldatetime Ngày tính lương
Songaynghi Int Số ngày nghỉ
Cơ sở dữ liệu bảng phieudatphong:
Tên thuộc tính Kiểu dữ liệu Mô tả
Makh Varchar(50) Mã khách hàng
Cơ sở dữ liệu bảng hoadon:
Tên thuộc tính Kiểu dữ liệu Mô tả
Sohd Varchar(50) Số hóa đơn
Makh Varchar(50) Mã khách hàng
Manv Varchar(50) Mã nhân viên
Cơ sở dữ liệu bảng cthd:
Tên thuộc tính Kiểu dữ liệu Mô tả
Sohd Varchar(50) Số hóa đơn
Madv Varchar(50) Mã dịch vụ
Cơ sở dữ liệu bảng donvicungcap:
Tên thuộc tính Kiểu dữ liệu Mô tả
Madv Varchar(50) Mã đơn vị
Tendv Nvarchar(100) Tên đơn vị
Sdt Varchar(10) Số điện thoại
Cơ sở dữ liệu bảng hoadonnhap:
Tên thuộc tính Kiểu dữ liệu Mô tả
Sohd Varchar(50) Số hóa đơn
Madv Varchar(50) Mã đơn vị
Cơ sở dữ liệu bảng cthdnhap:
Tên thuộc tính Kiểu dữ liệu Mô tả
Sohd Varchar(50) Số hóa đơn
Madv Varchar(50) Mã dịch vụ
Mối quan hệ giữa các bảng trong cơ sở dữ liệu:
Hình 4.1 Mối quan hệ giữa các bảng trong cơ sở dữ liệu
STT Tên chức năng Ý nghĩa
Các chức năng về quản lý phòng: Sửa thông tin phòng, thêm mới phòng, tìm kiếm phòng, sắp xếp thiết bị trong phòng
Các chức năng về quản lý loại phòng: Sửa thông tin loại phòng, thêm loại phòng, tìm kiếm loại phòng
Các chức năng về quản lý thiết bị: Sửa thông tin thiết bị, thêm mới thiết bị, xóa thiết bị, tìm kiếm thiết bị
Các chức năng về quản lý dịch vụ: Sửa thông tin dịch vụ, thêm mới dịch vụ, tìm kiếm dịch vụ, nhập dịch vụ
5 Quản lý nhân viên Các chức năng về quản lý nhân viên: Sửa thông tin nhân viên, thêm mới nhân viên, xóa
72 nhân viên, tìm kiếm nhân viên
6 Quản lý lương nhân viên
Các chức năng về quản lý lương nhân viên: Tính lương nhân viên, tìm kiếm và cập nhập lương, xóa tất cả lương trong tháng
Các chức năng về cập nhập khách hàng: Sửa thông tin khách hàng, thêm mới khách hàng, tìm kiếm khách hàng
8 Quản lý đơn vị cung cấp
Các chức năng về quản lý khách hàng: Sửa thông tin đơn vị, thêm mới đơn vị, tìm kiếm đơn vị
9 Cập nhập phiếu đặt phòng
Các chức năng về cập nhập phiếu đặt phòng: Sửa thông tin phiếu đặt phòng, hủy phiếu đặt phòng, tìm kiếm phiếu đặt phòng
10 Xem hóa đơn Các chức năng về xem hóa đơn: xem chi tiết hóa đơn, tìm kiếm hóa đơn
Các chức năng về đặt phòng: đặt phòng cho khách cũ (không thêm mới khách hàng) và khách mới (tự động thêm mới khách hàng)
Các chức năng về thuê phòng: thuê phòng cho khách cũ (không thêm mới khách hàng) và khách mới (tự động thêm mới khách hàng)
13 Trả phòng Các chức năng về trả phòng: tính tổng tiền, in hóa đơn
Các chức năng về thống kê: báo cáo lương nhân viên, thống kê và tự động lập biểu đồ doanh thu của khách sạn theo tháng, năm và khoảng thời gian xác định, thống kê loại phòng khách thuê nhiều
Hình 4.2 Giao diện hộp thoại
Giao diện nhập dữ liệu
Hình 4.3 Giao diện nhập dữ liệu dạng điền
Hình 4.4 Giao diện nhập dữ liệu dạng tùy chọn
Hình 4.5 Giao diện biểu mẫu dạng bảng
Hình 4.6 Giao diện biểu mẫu dạng biểu đồ
Triển khai hệ thống
4.2.1 Một số đoạn code quan trọng
Hình 4.7 Code tạo service WCF trong C# theo giao thức HTTP
Biến tĩnh toàn cục url là đường dẫn của service để các Client có thể truy cập vào theo đường dẫn đó Đường dẫn có dạng: http://[ip của Server]:[Cổng]/QLKS
Hình 4.8 Code Client truy cập service WCF trong C# theo giao thức HTTP
Hình 4.9 Code xử lý đa luồng của Socket trong C# Đối với Socket thì không sử dụng đường dẫn mà sử dụng địa chỉ IP và cổng để lắng nghe nên cần tạo đối tượng IpAddress để chuyển String về kiểu IPAddress Khi Client gọi thì thêm đối tượng socket đó vào 1 list để Server có thể gửi dữ liệu đi để thực hiện đồng bộ dữ liệu Socket phải xử lý ở 1 luồng khác vì luồng chính là để cho WCF thực hiện các hàm xử lý
4.2.2 Một số giao diện của phần mềm
Muốn sử dụng phần mềm thì người sử dụng phải có một tài khoản và phải nhập chính xác vào Form đăng nhập (Lưu ý: tên đăng nhập và mật khẩu không phân biệt chữ hoa và chữ thường)
Hình 4.10 Giao diện form đăng nhập
Form hệ thống Đây là giao diện chính của phần mềm tất cả các chức năng chính của phần mềm đều ở đây Đối với người quản lý thì có các chức năng để quản lý nhân viên, phòng,…
Hình 4.11 Giao diện form hệ thống Đối với nhân viên thì có các chức năng chủ yếu để phục vụ khách hàng
Hình 4.12 Giao diện form hệ thống
Form thuê/đặt phòng Đây là form để nhân viên đặt hoặc thuê phòng cho khách hàng
Hình 4.13 Giao diện form thuê/đặt phòng
Hình 4.14 Giao diện form thuê/đặt phòng
Form gọi dịch vụ Đây là form để nhân viên gọi dịch vụ cho khách hàng, bên phải có bảng giá để dễ dàng sử dụng
Hình 4.15 Giao diện form gọi dịch vụ
Form báo cáo/thống kê Đây là form mà người quản lý dùng để theo dõi tình hình kinh doanh của khách sạn
Hình 4.16 Giao diện form báo cáo/thống kê