Nghiên cứu cấu trúc ứng dụng phân tán và áp dụng xây dựng hệ thống quản lý yêu cầu khách hàng tại bưu điện hà nội

Chương 2 Nghiên cứu giải pháp cho bài toán Quản lý yêu cầu khách hàng Hình 2.1 : Mô hình 1 lớp – toàn bộ chương trình chạy trên 1 máy tính Khi các máy tính bắt đầu được kết nối với nhau

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

-

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

-

NGƯỜI HƯỚNG DẪN KHOA HỌC:

MỤC LỤC

DANH M ỤC CÁC HÌNH VẼ 5

DANH M ỤC CÁC BẢNG 7

M Ở ĐẦU 8

CHƯƠNG 1 TỔNG QUAN 10

1.1 Giới thiệu về hệ thống quản lý yêu cầu khách hàng của Bưu điện Hà Nội 10

1.2 Các hạn chế của hệ thống chương trình hiện tại 10

1.3 Phạm vi của đồ án 12

1.4 Phương pháp nghiên cứu 12

CHƯƠNG 2 NGHIÊN CỨU GIẢI PHÁP CHO BÀI TOÁN QU ẢN LÝ YÊU CẦU KHÁCH HÀNG 13

2.1 Kiến trúc ứng dụng 13

2.1.1 Các kiến trúc ứng dụng truyền thống và ưu nhược điểm 13

2.1.1.1Kiến trúc 1 lớp (1-tier) 13

2.1.1.2Kiến trúc 2 lớp (2-tier) 14

2.1.2 Những điểm hạn chế trong mô hình 2 lớp 15

2.1.2.1Hạn chế trong công tác triển khai và bảo hành bảo trì hệ thống15 2.1.2.2Hạn chế về năng lực xử lý của hệ thống 16

2.1.2.3Hạn chế về khả năng tích hợp (integration) 17

2.1.2.4Hạn chế về khả năng cung cấp dịch vụ cho khách hàng 17

2.1.2.5Hạn chế về tính mềm dẻo của hệ thống 17

2.1.2.6Hạn chế về chi phí cấu hình hệ thống 18

2.1.3 Kiến trúc ứng dụng phân tán (kiến trúc nhiều lớp) 18

2.1.3.1Vấn đề triển khai và bảo hành bảo trì hệ thống 19

2.1.3.2Vấn đề năng lực xử lý của hệ thống 20

2.1.3.3Vấn đề tích hợp 20

2.1.3.4Vấn đề cung cấp dịch vụ cho khách hàng 20

2.1.3.5Vấn đề tính mềm dẻo và khả chuyển của hệ thống 21

2.1.3.6Vấn đề chi phí cấu hình hệ thống 21

2.1.4 Lựa chọn kiến trúc ứng dụng 21

2.2 Giải pháp công nghệ 21

2.2.1 Java 21

2.2.1.1Java với tư cách là một ngôn ngữ lập trình 22

2.2.1.2Java với tư cách là một công nghệ nền (platform) 23

2.2.1.3Ứng dụng nhiều lớp trên Java 23

2.2.1.4Đánh giá 25

2.2.2 NET 27

2.2.2.1Các ngôn ngữ lập trình của NET 27

2.2.2.2.NET với tư cách là một công nghệ nền (platform) 28

2.2.2.3Ứng dụng nhiều lớp trên NET 29

2.2.2.4Đánh giá 30

2.2.3 Lựa chọn công nghệ nền 31

2.3 Một số công cụ khác 32

2.3.1 Hệ quản trị cơ sở dữ liệu 32

2.3.2 Ngôn ngữ lập trình 32

CHƯƠNG 3 XÂY DỰNG ỨNG DỤNG PHÂN TÁN TRÊN NET PLATFORM .34

3.1 Giới thiệu 34

3.2 Cấu trúc ứng dụng phân tán trên NET 34

3.3 Giao tiếp giữa các thành phần của ứng dụng trên môi trường NET 38

3.3.1 Các phương pháp truyền thống trên các môi trường phi NET 38

3.3.2 Các phương pháp giao tiếp trên môi trường NET 39

3.3.2.1ASP.NET Webservice 39

3.3.2.2.NET Remoting 39

3.3.2.3So sánh ASP.NET Webservice và NET Remoting 40

3.3.2.4Lựa chọn phương thức giao tiếp cho hệ thống Quản lý yêu cầu khách hàng 42

3.4 Cấu trúc giao tiếp khách - chủ trên NET Remoting 43

3.5 An toàn hệ thống 46

3.5.1 Các nguy cơ gây mất an toàn cho hệ thống 46

3.5.2 Nhận thực 48

3.5.3 Kiểm tra quyền 48

3.5.3.1Các đặc điểm của việc kiểm tra quyền trên môi trường ứng dụng phân tán 49

3.5.3.2Đồng bộ ngữ cảnh an ninh của tiến trình chủ với tiến trình khách

3.5.4 Mã hóa dữ liệu trên kênh truyền 53

3.5.4.1Cấu trúc 53

3.5.4.2Cơ bản về các thuật toán mã hóa 55

3.5.4.3Cơ chế trao đổi thông tin mã hóa trong chương trình 57

CHƯƠNG 4 PHÂN TÍCH VÀ THIẾT KẾ HỆ THỐNG 60

4.1 Khảo sát bài toán 60

4.1.1 Mô hình tổ chức của Bưu điện Hà Nội 60

4.1.2 Cấu trúc hệ thống 62

4.1.2.1Mô hình nghiệp vụ chính của hệ thống 62

4.1.2.2Các đơn vị thực hiện 64

4.1.2.3Mô hình khai thác dữ liệu 66

4.1.2.4Đối với khách hàng 66

4.1.2.5Đối với các đơn vị của TT DVKH 66

4.1.2.6Đối với các đơn vị khác của Bưu điện Hà Nội 67

4.1.3 Các nhóm chức năng của chương trình 67

4.1.4 Sự cần thiết của việc xây dựng hệ thống 68

4.1.5 Mục tiêu chính cần đạt được 69

4.1.6 Các nghiệp vụ cơ bản trong bài toán 69

4.1.6.1Tiếp nhận yêu cầu 69

4.1.6.2Kiểm tra tính khả thi của yêu cầu 69

4.1.6.3Ký kết hợp đồng 69

4.1.6.4Thanh toán hợp đồng 70

4.1.6.5Thực hiện hợp đồng 70

4.1.6.6Hoàn thành hợp đồng 70

4.2 Phân tích bài toán 71

4.2.1 Sơ đồ luồng dữ liệu mức ngữ cảnh 71

4.2.2 Sơ đồ phân cấp chức năng 73

4.2.3 Sơ đồ luồng dữ liệu các mức 76

4.2.3.1Sơ đồ luồng dữ liệu mức đỉnh 76

4.2.3.2Sơ đồ luồng dữ liệu mức dưới đỉnh – Tiếp nhận yêu cầu 78

4.2.3.3Sơ đồ luồng dữ liệu mức dưới đỉnh – Thu phí 79

4.2.3.4Sơ đồ dữ liệu mức dưới đỉnh – Phát triển thuê bao 81

4.2.3.5Sơ đồ phân rã luồng dữ liệu mức hai 82

4.2.4 Chức năng báo cáo 85

4.2.5 Chức năng hệ thống 86

4.3 Phát triển chương trình 86

CHƯƠNG 5 KẾT LUẬN 87

5.1 Đánh giá hệ thống mới so với hệ thống cũ 87

5.1.1 Tiêu chí đánh giá 87

5.1.2 Kết quả đánh giá 87

5.1.2.1Đáp ứng đối với yêu cầu nghiệp vụ 87

5.1.2.2Đáp ứng đối với yêu cầu tốc độ 87

5.1.2.3Đáp ứng đối với yêu cầu an toàn hệ thống 88

5.1.2.4Mức độ thuận tiện khi triển khai hệ thống 88

5.1.2.5Khả năng mở rộng hệ thống 88

5.1.2.6Đòi hỏi cấu hình phần cứng của hệ thống 88

5.2 Kiến nghị về các nghiên cứu tiếp theo 89

TÀI LI ỆU THAM KHẢO 90

PH Ụ LỤC 1 CÁC SƠ ĐỒ QUAN HỆ THỰC THỂ CHÍNH 91

PHỤ LỤC 2 CÁC GIAO DIỆN CỦA CHƯƠNG TRÌNH 117

Dan h mục các hình vẽ

Hình 2.1 : Mô hình 1 lớp – toàn bộ chương trình chạy trên 1 máy tính 13

Hình 2.2 : Mô hình 2 lớp 15

Hình 2.3 : Kiến trúc nhiều lớp 19

Hình 2.4 : Cấu trúc ứng dụng chạy trên Java platform 23

Hình 2.5 : Sơ đồ kiến trúc J2EE 24

Hình 2.6 : Cấu trúc ứng dụng chạy trên Java platform 26

Hình 2.7 : Các ngôn ngữ lập trình trên môi trường NET 28

Hình 2.8 : Cấu trúc ứng dụng chạy trên NET platform 29

Hình 2.9 : Cấu trúc ứng dụng phân tán (nhiều lớp) trên NET 29

Hình 3.1 : Cấu trúc ứng dụng phân tán trên môi trường NET 35

Hình 3.2: Cấu trúc giao tiếp giữa tiến trình khách và tiến trình chủ trong .NET Remoting 45

Hình 3.3: Vị trí của lớp đồng bộ thông tin người dùng trong Cấu trúc giao tiếp khách - chủ của NET Remoting 52

Hình 3.4: Vị trí của lớp bảo mật trong Cấu trúc giao tiếp khách - chủ của .NET Remoting 55

Hình 3.5 : Quá trình mã hóa và giải mã 56

Hình 4.1 : Mô hình tổ chức của Bưu điện Hà Nội 61

Hình 4.2 : Mô hình nghiệp vụ tổng thể hệ thống Quản lý yêu cầu khách hàng 63

Hình 4.3 : Sơ đồ luồng dữ liệu mức ngữ cảnh 71

Hình 4.4 : Cấu trúc phân cấp khách hàng 72

Hình 4.5 : Sơ đồ phân cấp chức năng hệ thống Quản lý yêu cầu khách hàng 74

Hình 4.6 : Sơ đồ luồng dữ liệu mức đỉnh 76

Hình 4.7 : Sơ đồ luồng dữ liệu mức dưới đỉnh – Tiếp nhận yêu cầu 78

Hình 4.8 : Sơ đồ luồng dữ liệu mức dưới đỉnh – Thu phí 79

Hình 4.9 : Sơ đồ dữ liệu mức dưới đỉnh – Phát triển thuê bao 81Hình 4.10 : Sơ đồ phân rã luồng dữ liệu mức hai – chức năng di chuyển - tiếp nhận yêu cầu 83

Hình 4.11 : Phân rã luồng dữ liệu mức hai – Tiếp nhận yêu cầu – Đăng ký dịch vụ gia tăng 84

Hình 4.12 : Phân rã luồng dữ liệu mức hai – Tiếp nhận yêu cầu – Lắp đặt mới 85

Dan h mục các bảng

Bảng 3.1: Quá trình kiểm tra quyền trong hệ thống khách – chủ 50Bảng 3.2: Một phiên giao dịch giữa máy trạm và máy chủ có mã hóa bảo mật 58

Mở đầu

Trong những năm vừa qua, việc ứng dụng tin học phục vụ công tác điều hành sản xuất kinh doanh trong các ngành kinh tế nói chung và trong ngành viễn thông nói riêng đã đem lại những hiệu quả rất to lớn Để thành công, các doanh nghiệp phải không ngừng hợp lý hóa công tác quản lý điều hành, khiến cho quy mô

và độ phức tạp của các hệ thống thông tin hỗ trợ ngày càng tăng Các kiến trúc phần mềm truyền thống, vốn chỉ phù hợp để xây dựng những ứng dụng đơn lẻ, trở nên không còn phù hợp để phát triển những hệ thống thông tin có quy mô doanh nghiệp

và vượt ra ngoài doanh nghiệp

Trong bối cảnh đó, luận văn này đi sâu nghiên cứu áp dụng một kiến trúc ứng dụng mới - kiến trúc ứng dụng phân tán để xây dựng một hệ thống hỗ trợ điều hành sản xuất kinh doanh cho một doanh nghiệp – hệ thống Quản lý yêu cầu khách hàng của Bưu điện Hà Nội

Nội dung của luận văn bao gồm các phần sau:

Chương 2 : Nghiên cứu giải pháp cho bài toán Quản lý yêu cầu khách hàng

Chương 2 thực hiện phân tích lựa chọn các giải pháp cho bài toán, bao gồm kiến trúc ứng dụng, giải pháp công nghệ và một số công cụ khác như cơ sở dữ liệu hay ngôn ngữ lập trình Chương này so sánh giữa các mô hình kiến trúc ứng dụng truyền thống và mô hình kiến trúc ứng dụng phân tán, từ đó xác định mô hình ứng dụng phân tán là giải pháp phù hợp nhất cho bài toán Quản lý yêu cầu khách hàng

Chương 3 : Xây dựng ứng dụng phân tán

Trên cơ sở các phân tích lựa chọn giải pháp đã trình bày trong chương 2,

vấn đề về cấu trúc phân tán, việc giao tiếp giữa các thành phần, các vấn đề bảo mật, tốc độ được đề cập chi tiết trong chương này

Chương 4 : Phân tích và thiết kế hệ thống

Chương 4 trình bày quá trình phân tích và thiết kế hệ thống Quản lý yêu cầu khách hàng mới dựa trên phương pháp phân tích thiết kế có cấu trúc (Structural analysis) Trong chương này, hệ thống được thiết kế từ trên xuống (top down) qua từng bước với các biểu đồ luồng dữ liệu các mức

Chương 5 : Kết luận

Chương 5 đưa ra các đánh giá về hệ thống mới so với hệ thống cũ và các kiến nghị về các nghiên cứu tiếp theo

Phụ lục 1 : Các sơ đồ quan hệ thực thể chính

Phụ lục 1 trình bày các sơ đồ quan hệ thực thể chính của hệ thống

Phụ lục 2 : Các giao diện chính của hệ thống mới

Phụ lục 2 trình bày các giao diện tiêu biểu của hệ thống

Tôi xin trân trọng gửi lời cảm ơn tới giáo viên hướng dẫn - PGS TS Nguyễn Việt Hương Là người hướng dẫn để tài, PGS TS Nguyễn Việt Hương đã tận tình hướng dẫn tôi trong quá trình hoàn thành đề tài luận văn này Tôi cũng xin trân trọng cảm ơn tập thể các cán bộ của Bưu điện Hà Nội, đặc biệt là Trung tâm tin học

và Trung tâm dịch vụ khách hàng đã nhiệt tình giúp đỡ và tạo điều kiện trong quá trình khảo sát thực hiện đề tài tại đây Tôi cũng xin gửi lời cảm ơn tới các đồng nghiệp tại Trung tâm Công nghệ thông tin, Học viện Bưu chính Viễn thông, là những người đã đóng góp công sức trong dự án Quản lý yêu cầu khách hàng của Bưu điện Hà Nội, đồng thời đóng góp những ý kiến hết sức quý báu giúp tôi có thể hoàn thành đề tài luận văn này

Hà Nội, ngày 16 tháng 09 năm 2004

Huỳnh Đức Nghĩa

75 Đinh Tiên Hoàng

Trong vài năm trở lại đây, cùng với sự phát triển của xã hội và sự nâng cao của mức sống người dân, số lượng khách hàng sử dụng các dịch vụ viễn thông ngày càng nhiều Để đáp ứng cho các nhu cầu ngày càng đa dạng của khách hàng, ngành Bưu chính Viễn thông cũng không ngừng gia tăng các loại hình dịch vụ viễn thông

để cung cấp cho khách hàng Bên cạnh đó, cạnh tranh trên thị trường đòi hỏi việc nâng cao chất lượng dịch vụ, chất lượng phục vụ khách hàng Các thông tin đưa tới khách hàng phải chính xác và nhanh nhất cũng như việc đáp ứng các yêu cầu của khách hàng phải nhanh nhất và chính xác Trong bối cảnh đó, việc tiếp nhận, xử lý, thực hiện các yêu cầu dịch vụ từ khách hàng trở thành một công việc phức tạp, đòi hỏi nhiều nhân lực và vật lực của ngành Bưu chính Viễn thông Nhu cầu về một hệ thống chương trình hỗ trợ quản lý các yêu cầu khách hàng trên máy tính trở nên rõ ràng và cấp thiết

Kể từ năm 2000 cho tới nay, việc quản lý yêu cầu khách hàng tại Bưu điện

Hà Nội đã được hỗ trợ thực hiện nhờ chương trình Quản lý yêu cầu khách hàng Chương trình hiện đang sử dụng này được viết bằng Foxpro, chạy trên hệ điều hành DOS

Hệ thống quản lý yêu cầu hiện tại của Bưu điện Hà Nội được xây dựng trên phiên bản Foxpro trên hệ điều hành DOS Foxpro for DOS được xây dựng để phát triển các ứng dụng 1 lớp Vì vậy, các nhược điểm mà một ứng dụng xây dựng dựa trên Foxpro bao gồm:

a) Năng lực xử lý

Là một trong những hệ cơ sở dữ liệu ở mức sơ khai, Foxpro không hỗ trợ các tính năng xử lý tương tranh, giao tác (transaction), các ràng buộc dữ liệu (constraints)… Nếu cần đến những tính năng này, người viết chương trình phải thực hiện ở mức ứng dụng Quá trình này thường rất phức tạp và đòi hỏi nhiều công sức của người phát triển chương trình

b) Khả năng mở rộng trong môi trường mạng

Foxpro for DOS được phát triển khi môi trường mạng chưa phải là phổ biến Một ứng dụng Foxpro for DOS thường chỉ nằm trên cùng một máy với file chứa dữ liệu (*.dbf), thực hiện toàn bộ các chức năng nhập dữ liệu, xử lý dữ liệu, xử lý giao tác Trong môi trường mạng LAN, một cơ sở dữ liệu Foxpro cho nhiều người dùng chỉ có thể thực hiện được bằng cách chia sẻ tài nguyên ở mức hệ điều hành, cụ thể

là chia sẻ quyền truy cập file dữ liệu (*.dbf) Khi này việc xử lý tương tranh phụ thuộc hoàn toàn vào ứng dụng Điều này khiến cho việc thực hiện các hệ thống phân tán với cơ sở dữ liệu tập trung quy mô lớn là hầu như không thể thực hiện được Vì vậy, giải pháp chia sẻ tài nguyên file dữ liệu chỉ có thể được coi như là một giải pháp tình thế cho bài toán cơ sở dữ liệu tập trung

c) Bảo mật

Dữ liệu Foxpro được lưu trong file dbf File này hoàn toàn có thể được truy cập, sửa bằng một trình đọc text đơn giản Dữ liệu thậm chí không được bảo vệ bởi mật khẩu khi truy cập trực tiếp như vậy Khả năng truy cập vào dữ liệu một cách dễ dàng mà không phải thông qua lớp ứng dụng như vậy là một tiềm năng cho các cuộc tấn công vào ứng dụng

Với những hạn chế như vậy, hệ thống Quản lý yêu cầu khách hàng hiện tại của Bưu điện Hà Nội đang gặp nhiều khó khăn trong việc đáp ứng số lượng các yêu cầu dịch vụ ngày càng tăng về số lượng và phong phú về loại hình Nhu cầu cho một hệ thống mới thỏa mãn được các yêu cầu về tốc độ, khả năng mở rộng, độ chính xác và an toàn dữ liệu đang được đặt ra một cách cấp bách

1.3 Phạm vi của đồ án

Đồ án này sẽ tập trung vào các vấn đề sau

− Nghiên cứu mô hình ứng dụng phân tán để áp dụng cho bài toán Quản

lý yêu cầu khách hàng

+ Nghiên cứu về các kiến trúc ứng dụng So sánh giữa các mô hình ứng dụng truyền thống và mô hình ứng dụng phân tán Đưa ra các lý do lựa chọn mô hình ứng dụng phân tán

+ Nghiên cứu lựa chọn các giải pháp công nghệ để triển khai mô hình ứng dụng phân tán

+ Dựa trên giải pháp công nghệ đã lựa chọn, đi sâu nghiên cứu, phân tích để đưa ra mô hình cụ thể áp dụng cho bài toán Quản

Phương pháp nghiên cứu được sử dụng xuyên suốt trong quá trình phân tích thiết kế hệ thống Quản lý yêu cầu khách hàng là phương pháp phân tích có cấu trúc (structured analysis) Đây là phương pháp được sử dụng rất phổ biến trong các dự

án Công nghệ Thông tin

Chương 2 Nghiên cứu giải pháp cho bài toán Quản lý yêu cầu khách hàng

Hình 2.1 : Mô hình 1 lớp – toàn bộ chương trình chạy trên 1 máy tính

Khi các máy tính bắt đầu được kết nối với nhau, để tận dụng được các ưu thế của môi trường mạng, một giải pháp tình thế cho các ứng dụng với kiến trúc 1 lớp

là chia sẻ tài nguyên cơ sở dữ liệu Tuy nhiên, việc chia sẻ tài nguyên này thuần túy

là sự chia sẻ ở mức hệ điều hành – cụ thể là chia sẻ file Hệ thống Quản lý yêu cầu khách hàng hiện tại của Bưu điện Hà Nội thuộc nhóm các ứng dụng này

Trong mô hình File server này, máy chủ chỉ đóng vai trò là nơi lưu trữ

chương trình, lưu trữ dữ liệu Thực chất việc xử lý dữ liệu đều do các máy trạm đảm

1 Máy tính

Files Giao

diện

người

sử dụng

Xử lý

nhận Các vấn đề như xử lý tương tranh, bảo mật… chỉ được thực hiện ở máy trạm

Do vậy kiến trúc này có rất nhiều hạn chế về năng lực xử lý, an toàn dữ liệu, giá thành nâng cấp phần cứng, khả năng mở rộng hệ thống… Các nhược điểm của kiến trúc này khiến cho việc phát triển những hệ thống lớn, phức tạp là không thể thực hiện được

Trong kiến trúc này, toàn bộ logic của chương trình chỉ được chạy ở máy trạm, bao gồm việc truy cập dữ liệu, xử lý yêu cầu, hiển thị kết quả Máy chủ chỉ là nơi lưu dữ liệu thuần túy Kiến trúc này được gọi là kiến trúc 1 lớp (1-tier)

2.1.1.2 Kiến trúc 2 lớp (2-tier)

Tiếp sau mô hình File server, người ta thường phát triển các ứng dụng mạng theo mô hình Client/Server Trong mô hình này, khi có yêu cầu thực hiện công việc, client sẽ gửi yêu cầu tới server Chương trình server sẽ thực hiện yêu cầu Khi có kết quả, server sẽ gửi lại cho client

Trong một số ứng dụng, một chương trình ứng dụng khi thì đóng vai trò client, khi thì đóng vai trò server tuỳ theo ngữ cảnh cụ thể thường được coi là các client/server kiểu Peer-to-Peer

Trong mô hình Client/Server, giao diện client trong các hệ thống này thường

là giao diện GUI Application, và một số giao diện đã được cung cấp dưới dạng Web browser với điểm mạnh là tích hợp ngôn ngữ script Mô hình client/server thực chất đồng thời xử lý tác nghiệp (business process) và hiển thị thông tin (data presentation)

Các ứng dụng sử dụng các hệ cơ sở dữ liệu tập trung cũng được xếp vào loại này Khác biệt giữa trường hợp chia sẻ file của kiến trúc 1 lớp và cấu trúc này nằm

ở tính chất chủ động của máy chủ Một cơ sở dữ liệu tiên tiến không chỉ là một tập các file chứa dữ liệu, mà còn bao gồm các tiến trình xử lý phức tạp chạy trên máy chủ để thực hiện các vấn đề xử lý tương tranh, kiểm tra ràng buộc dữ liệu, xử lý dữ liệu… Ví dụ của các hệ thống ứng dụng kiểu này là một chương trình chạy trên máy trạm kết nối tới cơ sở dữ liệu Oracle

Mô hình này đã giải quyết được nhiều điểm hạn chế của mô hình File server Một phần khối lượng xử lý đã được chuyển cho máy chủ thực hiện Tuy vậy, khối

lượng công việc xử lý này thường chỉ ở mức tương đối nhỏ và chủ yếu thực hiện các công việc xử lý có tính kỹ thuật chứ không phải là nghiệp vụ, chẳng hạn xử lý tương tranh trong các hệ cơ sở dữ liệu Điều này khiến cho mô hình 2 lớp, mặc dù

đã giải quyết được nhiều vấn đề của mô hình 1 lớp, vẫn chưa phải là giải pháp thích hợp cho các hệ thống lớn, đòi hỏi khả năng tích hợp, mở rộng cao

Hình 2.2 : Mô hình 2 lớp

Trên Hình 2.2 biểu diễn cấu trúc của mô hình 2 lớp Cải tiến của mô hình này so với mô hình 1 lớp là các xử lý kỹ thuật đã được chuyển lên chung trên máy chủ Tuy nhiên có thể thấy rằng phần xử lý nghiệp vụ vẫn được thực hiện tại máy trạm Vì vậy, mô hình này vẫn còn tồn tại nhiều hạn chế

2.1.2 Những điểm hạn chế trong mô hình 2 lớp

2.1.2.1 Hạn chế trong công tác triển khai và bảo hành bảo trì hệ thống

Đối với các ứng dụng được viết theo mô hình client/server thông thường, cần phải cài chương trình cho từng máy trạm làm việc của người sử dụng Sẽ không có vấn đề gì lớn nếu như số lượng máy trạm làm việc là không đáng kể và nằm tại cùng trong 1 khu vực, tuy nhiên đối với các ứng dụng phục vụ công tác quản lý và

Xử lý giao diện + Xử

Máy chủ Máy trạm 1

Máy trạm 2

điều hành sản xuất kinh doanh của 1 bưu điện tỉnh, số lượng người sử dụng là rất lớn, địa bàn lại trải rộng thì việc cài đặt ứng dụng, cập nhật, quản lý các phiên bản

và khắc phục sự cố rất mất nhiều thời gian, nhân lực và chi phí

Ví dụ: hệ thống Quản lý yêu cầu khách hàng triển khai cho 1 BĐ tỉnh cỡ trung bình sẽ có khoảng 100 người dùng, và cần phải cài đặt tại tại rất nhiều vị trí, trong nội thành có khoảng 2 đến 10 điểm giao dịch, 20 phòng ban và khoảng từ 5 đến 10 huyện (mỗi huyện có ít nhất 1 điểm giao dịch khách hàng)

dữ liệu cần xử lý tăng lên, tốc độ đường truyền thấp thì năng lực xử lý của toàn hệ thống sẽ bị ảnh hưởng nghiêm trọng

Đối với các bài toán có nhiều máy trạm Client (VD như các đầu chương trình tiếp nhận yêu cầu, thu phí của hệ thống Quản lý yêu cầu khách hàng), nếu dùng các ứng dụng Client/Server thông thường, số lượng các kết nối dữ liệu (connection) từ các ứng dụng đến cơ sở dữ liệu thường khá lớn (có thể lên tới vài trăm client) Đặc biệt, khi hệ thống được mở rộng để khách hàng có thể tự chăm sóc qua mạng internet (selfcare), số lượng các kết nối dữ liệu này có thể tới hàng nghìn Tuy vậy, thực tế các hệ quản trị cơ sở dữ liệu lại giới hạn số kết nối Đối với hệ quản trị cơ sở

dữ liệu Oracle, khi số lượng kết nối nhiều, năng lực xử lý của máy chủ dữ liệu sẽ giảm đáng kể

Trong trường hợp khối lượng công việc tại server quá lớn chỉ có cách giải quyết duy nhất là nâng cấp server, tuy nhiên việc nâng cấp là có giới hạn

2.1.2.3 Hạn chế về khả năng tích hợp (integration)

Trong môi trường có rất nhiều nhà cung cấp dịch vụ nhự hiện nay, khách hàng không còn là của riêng 1 doanh nghiệp nào, họ có thể sử dung rất nhiều các dịch vụ khác nhau từ các nhà cung cấp khác nhau Vì vậy hệ thống các ứng dụng của một doanh nghiệp không những phải tương tác, tích hợp được với nhau (trong nội bộ doanh nghiệp) mà còn phải có khả năng tích hợp với ứng dụng của các doanh nghiệp khác, hay nói cách khác các ứng dụng của các doanh nghiệp khác nhau phải liên kết được với nhau để tạo thành một môi trường cộng tác (Collaboration) để cung cấp sự tiện lợi tối đa cho khách hàng khi sử dụng dịch vụ

Trong khi đó nếu sử dụng mô hình client/server khả năng tích hợp là rất yếu

Lý do của các khó khăn trong tích hợp là một tỷ lệ khối lượng xử lý nghiệp vụ của các chương trình vẫn chạy độc lập trên các máy trạm Việc tích hợp giữa các chương trình chỉ có thể thực hiện ở mức cơ sở dữ liệu, chứ chưa thể thực hiện ở mức nghiệp vụ chương trình Các ứng dụng 2 lớp vẫn là những chương trình đóng kín rời rạc và nếu chạy trên cùng một máy, chúng không thể truy cập tới các hàm của nhau – và do đó không thể tích hợp được ở mức ứng dụng

2.1.2.4 Hạn chế về khả năng cung cấp dịch vụ cho khách hàng

Do hạn chế về khả năng tích hợp, các ứng dụng chỉ giải quyết được phần nghiệp vụ trong nội bộ doanh nghiệp của minh mà không kết hợp được với các dịch

vụ do các doanh nghiệp khác cung cấp

Ví dụ: đối với bài toán lắp đặt thuê bao mới, ta có thể cung cấp giao diện web cho khách hàng đăng ký một cách tự động nhưng do không liên kết được với các ứng dụng của ngân hàng để kiểm tra số dư tài khoản của khách hàng, dẫn đến khách hàng vẫn phải đến các điểm giao dịch để nộp tiền hoặc phải có 1 nhân viên đến thu tại nhà khách hàng

2.1.2.5 Hạn chế về tính mềm dẻo của hệ thống

Do tính cạnh tranh rất gay gắt hiện nay, các quy trình nghiệp vụ thường xuyên có sự thay đổi để tạo điều kiện thuận lợi tối đa cho khách hàng,dẫn đến các ứng dụng phần mềm cũng phải được cập nhật và sửa đổi theo, do chưa phân tách

được lớp biểu diễn số liệu, lớp xử lý tác nghiệp và lớp cơ sở dữ liệu nên chi phí chỉnh sửa là rất lớn, thời gian dài và rất dễ gây lỗi

2.1.2.6 Hạn chế về chi phí cấu hình hệ thống

Trong mô hình client/server, phần lớn logic nghiệp vụ được xử lý ở máy trạm Vì vậy, khi triển khai hệ thống, cấu hình của các máy trạm đều phải ở mức cao Số máy trạm trong hệ thống thường từ vài chục tới vài trăm trong một hệ thống nhỏ, nhưng với các hệ thống lớn, số máy trạm có thể lên tới vài nghìn Chi phí cho phần cứng của hệ thống trở nên rất lớn

2.1.3 Kiến trúc ứng dụng phân tán (kiến trúc nhiều lớp)

Mô hình Client/Server truyền thống ở trên thường được gọi là mô hình 2 lớp

Ưu điểm của mô hình này so với mô hình 1 lớp xuất phát ở chỗ, trong mô hình này, máy chủ không chỉ còn là nơi lưu trữ dữ liệu, mà đã trở thành nơi chạy một phần logic của chương trình Tuy nhiên, phần logic này chủ yếu để xử lý các vấn đề kỹ thuật chứ không phải nghiệp vụ của chương trình Điều này là nguyên nhân tạo nên các nhược điểm kể trên của mô hình này Với các điểm hạn chế như vậy, việc xây dựng một hệ thống theo chuẩn mới là điều cần thiết

Kiến trúc phân tán (distributed applications) hay kiến trúc đa lớp (multi-tiers) giải quyết được các vấn đề kể trên Khái niêm “phân tán” hay “nhiều lớp” được sử dụng để chỉ ra sự phân bổ logic của chương trình trên các máy Kiến trúc này là một bước kế tiếp của mô hình 2 lớp ở chỗ: nó phát triển tiếp ý tưởng chuyển logic chương trình lên xử lý tập trung ở máy chủ Điểm khác biệt là ở chỗ, nếu như trong kiến trúc 2 lớp, phần xử lý nghiệp vụ chủ yếu nằm ở máy chủ thì trong kiến trúc phân tán, phần xử lý nghiệp vụ được chuyển lên xử lý ở các máy chủ Máy trạm lúc này chỉ đóng vai trò thiết bị đầu cuối để nhập dữ liệu

Hình 2.3 : Kiến trúc nhiều lớp

Hình 2.3 biểu diễn kiến trúc đơn giản của mô hình nhiều lớp Trong mô hình này, người ta thường sử dụng một hay nhiều lớp trung gian giữa máy trạm (có thể là các trình duyệt web hoặc ứng dụng) và các máy chủ khác (thường là hệ thống máy chủ cơ sở dữ liệu Enterprise Information System EIS ) Các lớp ở giữa này đóng vai trò máy chủ ứng dụng, trên đó các ứng dụng sẽ được triển khai Các mã nguồn cần

để trao đổi thông tin hoặc để có thể tái sử dụng sẽ được lưu giữ trên máy chủ ứng dụng này Mô hình máy trạm/ máy chủ ứng dụng/ máy chủ cơ sở dữ liệu sẽ giải quyết tất cả các yếu tố hạn chế trông mô hình client/server thuần tuý

2.1.3.1 Vấn đề triển khai và bảo hành bảo trì hệ thống

Trong phần lớn các hệ thống, phần logic xử lý nghiệp vụ chiếm thành phần rất lớn Với mô hình nhiều lớp, phần xử lý nghiệp vụ được triển khai tập trung tại một số ít máy chủ có cấu hình mạnh Còn lại phần xử lý giao diện chiếm tỷ trọng nhỏ có thể được chạy theo 2 dạng: trình duyệt web đối với các ứng dụng thin client

và Chương trình giao diện đối với các ứng dụng thick client Đối với dạng thứ nhất,

sở dữ liệu)

hoàn toàn không cần triển khai gì trên máy trạm Với dạng thứ hai, Chương trình xử

lý giao diện thường ít phải thay đổi và nâng cấp, trong trường hợp phải thay đổi thì khối lượng cũng không nhiều Vì vậy việc triển khai, bảo trì hệ thống sẽ tập trung ở phần xử lý nghiệp vụ tại các máy chủ, khiến cho công việc cài đặt, sửa chữa, nâng cấp có thể tiến hành dễ dàng

sử dụng với chế độ dành riêng và có tốc độ cao

Trên các kết nối giữa máy trạm và máy chủ ứng dụng, thông tin truyền đi thường là các thông tin đã được xử lý để hiển thị hay là các thông tin nhập liệu đầu vào, vì vậy lưu lượng trên các kết nối này rất thấp so với mô hình 2 lớp

2.1.3.3 Vấn đề tích hợp

Trong mô hình nhiều lớp, phần xử lý nghiệp vụ được tập trung ở máy chủ ứng dụng Điều này khiến cho việc tích hợp có thể được thực hiện ở mức ứng dụng, thay vì dừng lại ở mức cơ sở dữ liệu như trong mô hình 2 lớp Việc gọi hàm giữa các tiến trình trên máy chủ ứng dụng có thể được thực hiện bởi rất nhiều kỹ thuật như Web service, NET Remoting… tùy thuộc vào hệ điều hành Ranh giới giữa các ứng dụng nhờ vậy trở nên trong suốt đối với người dùng

2.1.3.4 Vấn đề cung cấp dịch vụ cho khách hàng

Giải quyết được vấn đề tích hợp, việc các nhà sản xuất ứng dụng phối hợp với nhau để xây dựng nên những hệ thống lớn trở nên khả thi Vì vậy, các ứng dụng cung cấp cho khách hàng cũng trở nên đơn giản, thuận tiện và chính xác hơn

2.1.3.5 Vấn đề tính mềm dẻo và khả chuyển của hệ thống

Các quy trình nghiệp vụ được xử lý tập trung tại các máy chủ Vì vậy, khi cần thay đổi quy trình nghiệp vụ, nói chung chỉ cần xử lý tập trung tại máy chủ mà người sử dụng ở máy trạm vẫn có thể sử dụng giao diện cũ quen thuộc

2.1.3.6 Vấn đề chi phí cấu hình hệ thống

Trong mô hình nhiều lớp, các thiết bị đầu cuối chỉ cần sử dụng để thực hiện công việc xử lý giao diện, vì vậy không cần đòi hỏi cấu hình mạnh Khi triển khai các hệ thống, khối lượng các thiết bị đầu cuối là lớn hơn rất nhiều so với số lượng máy chủ, có thể tới vài trăm hoặc vài ngàn Vì vậy, mặc dù chi phí cho các máy chủ tăng lên, chi phí cho toàn bộ hệ thống vẫn được giảm đi đáng kể

2.1.4 Lựa chọn kiến trúc ứng dụng

Qua các phân tích ở trên, có thể thấy rõ đặc điểm của mỗi kiến trúc ứng dụng Kiến trúc 1 lớp (file server) chỉ phù hợp với các ứng dụng nhỏ, chạy trên 1 máy tính Kiến trúc 2 lớp mặc dù đã giải quyết được một số vấn đề của kiến trúc 1 lớp, vẫn chưa đáp ứng được các điều kiện cho một hệ thống lớn, có quy mô triển khai tương đối rộng, đòi hỏi tính tích hợp cao như hệ thống Quản lý yêu cầu khách hàng Trong các mô hình, mô hình ứng dụng phân tán (mô hình nhiều lớp) tỏ ra thích hợp hơn cả và là mô hình được lựa chọn để phát triển hệ thống

Hiện nay có rất nhiều các công nghệ để xây dựng ứng dụng theo kiến trúc phân tán Đứng đầu trong danh sách này có thể kể đến 2 nhóm công nghệ: nhóm công nghệ Java của Sun Microsystems và nhóm công nghệ Windows của Microsoft

2.2.1 Java

Java được giới thiệu đầu tiên vào năm 1995 bởi James Gosling và Henry McGilton và được xem là một kết quả tất yếu do phát triển mạnh mẽ của Internet

Java thường hay nhắc tới với tư cách là một ngôn ngữ lập trình Tuy nhiên, đầy đủ hơn, nó cần phải được hiểu là một hệ thống các công nghệ nền hỗ trợ phát triển ứng dụng

2.2.1.1 Java với tư cách là một ngôn ngữ lập trình

Java là một ngôn ngữ bậc cao với nhiều ưu điểm:

o Đơn giản, hướng đối tượng và thân thiện: Một trong những mục tiêu chính của Java là cung cấp 1 ngôn ngữ đơn giản dễ sử dụng và phát triển Do sự phức tạp ngày càng cao của môi trường tính toán và xử lý trên mạng, Java cung cấp mô hình phát triển hướng đối tượng với các đặc điểm như: đa hình, có tính kế thừa, cơ chế trao đổi qua message

và có khả năng tái sử dụng Java được cài đặt với các thư viện gồm nhiều đối tượng đã được kiểm tra cung cấp đầy đủ các chức năng cho

người phát triển ví dụ như: vào ra, giao tiếp mạng, quản lý bảo mật, giao diện người dùng, các đối tượng này có thể sử dụng trực tiếp đồng thời cũng có thể mở rộng theo nhu cầu riêng của người phát triển Với cú pháp giống C++ nhưng một số điểm phức tạp dễ mắc lỗi

đã được loại bỏ đã giúp cho java thân thiện với người dùng hơn

o An toàn: các đặc điểm của java định hướng và giúp người lập trình có một thói quen lập trình có độ tin cậy cao Mô hình quản lý bộ nhớ đã được đơn giản hóa, không có các kiểu dữ liệu con trỏ và các phép tính

số học trên con trỏ như trong C++ Việc loại bỏ con trỏ đã tạo ra cho Java một số ưu điểm : cơ chế tự động giải phóng bộ nhớ, loại bỏ được các lỗi gây treo hệ thống như khi làm việc với C và C++ Tuy nhiên, điều này cũng đồng nghĩa với việc giảm khả năng tác động sâu vào hệ thống của người lập trình, do đó ít nhiều làm giảm sức mạnh của Java

o Kiến trúc dung hòa và có tính khả chuyển: môi trường mạng hiện nay rất đa dạng về các chủng loại thiết bị phần cứng cũng như hệ điều hành Để hỗ trợ khả năng chạy trên các nền tảng và hệ điều hành

trung gian dung hòa về mặt cấu trúc để chuyển mã sang các phần cứng và các hệ hiều hành khác nhau một cách có hiệu quả Đặc điểm thông dịch của java giải quyết được các vấn đề liên quan tới việc: phân phối mã lệnh nhị phân và quản lý phiên bản, điều này giúp cho java có thể chạy trên mọi nền tảng khác nhau Có thể nói đây là một trong những ưu điểm lớn nhất của Java

2.2.1.2 Java với tư cách là một công nghệ nền (platform)

Một công nghệ nền là môi trường phần cứng hoặc phần mềm để các ứng dụng có thể chạy trên đó, ví dụ như các hệ điều hành: Windows 2000, Linux, Solaris, and MacOS Phần lớn các công nghệ nền đều là sự kết hợp giữa hệ điều hành và phần cứng Java platform thuần tuý là phần mềm, chạy ở lớp trên của các

hệ điều hành khác nhau Có 2 thành phần tạo nên Java platform:

o Máy ảo Java (Java Virtual Machine -JVM)

o Thư viện Java lập trình Java API:

Hình 2.4 : Cấu trúc ứng dụng chạy trên Java platform

2.2.1.3 Ứng dụng nhiều lớp trên Java

Có 3 thư viện lập trình với Java

o J2SE (Java Standard Second Edition) : là thư viện lập trình cho các ứng dụng Java cơ bản, chạy trên 1 máy Thư viện này chứa các giao diện tới máy ảo Java và là nền cho các ứng dụng Java cũng như cho các thư viện lập trình mức cao khác

o J2ME : Là thư viện lập trình cho các ứng dụng Java chạy trên các thiết bị cầm tay (máy tính bỏ túi Pocket PC, thiết bị hỗ trợ cá nhân PDA, điện thoại di động…) Thư viện này được thiết kế đặc biệt để

phù hợp với những đặc điểm của các thiết bị bỏ túi : yêu cầu phần mềm đơn giản trên một cấu hình không cao

o J2EE (Java Enterprise Second Edition): Là thư viện lập trình cho các ứng dụng triển khai rộng (quy mô doanh nghiệp) J2EE không chỉ là một thư viện lập trình Nó còn là một hệ thống các quy định, khuyến nghị về các thành phần của một ứng dụng phân tán Có thể coi J2EE gồm 2 phần : một thư viện lập trình mức cao xây dựng trên nền J2SE

và một tập các mô tả các thành phần ứng dụng, quy cách trao đổi giữa các thành phần…

Hình 2.5 : Sơ đồ kiến trúc J2EE

Hình 2.5 mô tả các thành phần trong kiến trúc của J2EE platform, lưu ý rằng hình vẽ chỉ mô tả quan hệ logic của các thành phần chứ không đề cập đến kiến trúc

về mặt vật lý, các thành phần có thể được cài đặt trên các máy tính, tiến trình, máy ảo, khác nhau

Các Container được mô tả bởi các hình chữ nhật riêng rẽ là các môi trường chạy cung cấp các dịch vụ cần thiết cho các thành phần ứng dụng được biểu diễn ở nửa phía trên Các dịch vụ được thể hiện qua các hộp ở nửa phía dưới Ví dụ như: Application Client Container cung cấp dịch vụ thư viện Java Messaging Service (JMS API) cho các ứng dụng client

Các mũi tên mô tả nguyên tắc truy nhập, trao đổi giữa các thành phần của J2EE Platform Ví dụ Application Client Container cung cấp khả năng truy nhập trực tiếp tới cơ sở dữ liệu qua thư viện JDBC API, tương tự như vậy đối với các Web Container và EJB container

Các thư viện API được hỗ trợ bởi môi trường chạy J2SE (Java 2 Platform, Standard Edition) cho từng loại thành phần ứng dụng

Có thể thấy rằng kiến trúc của J2EE trên Hình 2.5 tuân theo kiến trúc cơ bản của ứng dụng phân tán trên Hình 2.3, trong đó Java Applet và Java Application đóng vai trò lớp trình diễn, các thành phần chạy trên Web Container và EJB Container đóng vai trò lớp xử lý nghiệp vụ và cơ sở dữ liệu đóng vai trò lớp cơ sở

− Java hỗ trợ tính năng “dịch một lần, chạy mọi nơi” Điều này là do Java được trình biên dịch dịch ra một loại mã trung gian (bytecode) Mã bytecode này sau đó có thể chạy được trên các hệ điều hành khác nhau, nhờ một máy ảo Java (Java Virtual Machine - JVM) cài đặt trên các hệ điều hành này Nhiệm vụ xây dựng máy ảo Java trên các hệ điều hành khác nhau là của Sun Microsystems Đây là một trong những ưu điểm lớn

nhất của Java Tuy nhiên, nó cũng khiến cho các ứng dụng viết bằng Java

có một số nhược điểm được đề cập ở phần sau

− Các thư viện và các chuẩn của Java giúp phát triển nhiều loại ứng dụng : Java Application, Web Application, applets, máy chủ ứng dụng (với EJB – Enterprise Java Beans)

b) Nhược điểm

Ngôn ngữ lập trình Java không có được các tính năng mạnh mẽ như C++ hay C# Điều này chính là do Java không được viết cho một hệ điều hành cụ thể nào, vì vậy không có các tính năng truy cập tới mức sâu của hệ điều hành như xử lý bộ nhớ… Vì vậy, đối với các ứng dụng đòi hỏi các thao tác này, Java không nằm trong danh sách lựa chọn

Như trên đã đề cập, ứng dụng viết bằng Java được dịch ra mã byte code Mã bytecode sau đó được chạy trên máy ảo Java để tương tác với hệ điều hành thực sự (Hình 2.6 vẽ lại từ Hình 2.4 để tiện tham khảo)

Hình 2.6 : Cấu trúc ứng dụng chạy trên Java platform

Trong cấu trúc này có thể thấy rõ mức gián tiếp giữa ứng dụng Java và hệ điều hành Đây là nguyên nhân chính khiến cho các ứng dụng Java thường chạy với tốc độ chậm và không sử dụng được các tính năng đặc biệt của hệ điều hành

Tuy nhiên, với những ứng dụng ở quy mô doanh nghiệp, khi mà tốc độ xử lý,

độ thân thiện của giao diện người sử dụng… là một trong các yêu cầu quan trọng cần được đáp ứng thì Java không phải là lựa chọn số 1 Hơn nữa, trong các môi trường kiểu này, ưu điểm không phụ thuộc nền của Java thường không có cơ hội để phát huy tác dụng

2.2.2 NET

Công nghệ NET đã được Microsoft đưa ra lần đầu tiên vào tháng 7 năm

2000 Kể từ đó, NET đã chứng tỏ được ưu thế của mình trong việc hỗ trợ phát triển các ứng dụng trên môi trường Windows Khả năng hỗ trợ hoàn toàn Unicode, mô hình lập trình hướng đối tượng thông qua nhiều loại ngôn ngữ lập trình cùng với các tính năng mạnh mẽ của bộ công cụ phát triển là các ưu điểm của NET Cam kết hỗ trợ trong mọi hệ điều hành Windows tiếp theo (trong đó có Windows Longhorn) khiến cho môi trường NET trở thành một trong các môi trường phát triển ứng dụng phân tán hứa hẹn nhất

2.2.2.1 Các ngôn ngữ lập trình của NET

Với NET, Microsoft đã phá vỡ rào cản giữa các ngôn ngữ lập trình bằng việc cho phép Common Language Runtime (các dịch vụ chung chạy trên hệ điều hành, tạo môi trường giúp một ứng dụng có thể chạy - CLR) của NET chạy trên ngôn ngữ trung gian (Intermediate Language Bytecode), thay vì trực tiếp trên mã máy (native code) như trước đây Điều này có nghĩa là bất kỳ ngôn ngữ lập trình nào có thể dịch được ra ngôn ngữ trung gian đều có thể chạy được bởi CLR Kết quả là có khoảng 20 ngôn ngữ lập trình khác nhau có thể sử dụng với CLR của NET Như vậy các chương trình viết với các ngôn ngữ khác nhau này có thể cung cấp các giao diện lập trình cho nhau, hay gọi lẫn nhau

Hình 2.7 : Các ngôn ngữ lập trình trên môi trường NET

Trên Hình 2.7, có thể thấy các ngôn ngữ được chia thành 2 nhóm Một bên là các ngôn ngữ được hỗ trợ bởi Visual Studio NET (là bộ công cụ để phát triển các ứng dụng trên NET cung cấp bởi Microsoft) , bao gồm C#, Visual Basic NET, C++ NET, J#… Người lập trình sử dụng Visual Studio NET có thể viết chương trình bằng các ngôn ngữ này Visual Studio NET là bộ công cụ hỗ trợ lập trình mạnh nhất hiện nay, với các tính năng soạn thảo, biên dịch, sửa lỗi…

Nhóm còn lại là các ngôn ngữ lập trình hiện có thể dịch được ra IL Chú ý rằng trên lý thuyết, bất kỳ ngôn ngữ lập trình nào cũng có thể được dịch ra ngôn ngữ cấp thấp hơn Tuy nhiên, trên thị trường phần mềm, vì các lý do bản quyền, cạnh tranh giữa các nhà sản xuất…, các trình dịch đó chỉ được phát triển một cách hạn chế Kết quả là chỉ có một số ngôn ngữ có trình biên dịch có khả năng dịch ra

IL, trong đó có thể kể đến Perl

Nếu như khả năng hỗ trợ đa ngôn ngữ của NET vượt trội như vậy, khả năng triển khai trên các hệ điều hành khác nhau lại bị hạn chế Điều này là do CLR của NET chỉ được thiết kế để chạy trên môi trường Windows Hiện đã có một số dự án

mã nguồn mở nhằm xây dựng một bộ CLR hỗ trợ đa hệ điều hành Trong số đó có thể kể đến mono (www.oo-mono.com ) Dự án này đã đạt được nhiều bước tiến khả quan

2.2.2.2 NET với tư cách là một công nghệ nền (platform)

CLR viết bằng IL Ngôn ngữ Hệ điều hành

C#, Visual Basic

.NET, C++ NET,…

Các ngôn ngữ có thể dịch ra

IL (Perl,…)

Hình 2.8 : Cấu trúc ứng dụng chạy trên NET platform

.NET cũng thường được nhắc đến với tư cách là một công nghệ nền (platform) Nền NET bao gồm NET Framework (gồm các dịch vụ common language runtime và một bộ thư viện chung cho các ứng dụng NET) và hệ điều hành Windows bên dưới Tuy nhiên, thông thường, hệ điều hành Windows thường được bỏ qua, và NET Framework đóng vai trò platform Như đã đề cập tới ở trên, NET Framework không chạy trực tiếp trên hệ điều hành Windows, mà thông qua một ngôn ngữ trung gian (IL) Vì vậy, NET Framework có thể được sử dụng được bởi bất kỳ ngôn ngữ nào có thể được dịch ra ngôn ngữ IL

2.2.2.3 Ứng dụng nhiều lớp trên NET

Hình 2.9 : Cấu trúc ứng dụng phân tán (nhiều lớp) trên NET

Hệ điều hành CLR Ứng dụng NET

.NET Framework

ASP.NET

.NET Framework

Các đối tượng NET (.NET Components)

.NET Framework

CSDL

Trên Hình 2.9 là cấu trúc cơ bản của ứng dụng trên NET Chú ý rằng dựa trên cấu trúc cơ bản này còn có thể có rất nhiều biến thể Lý do là vì thông qua các phương thức khác nhau, các đối tượng NET, dù ở trong lớp trình diễn hay trong lớp nghiệp vụ đều có thể gọi lẫn nhau, khiến cho cấu trúc trên có thể mở rộng ra thêm nhiều mức Điều này được làm rõ thêm khi tìm hiểu về từng thành phần của cấu trúc

a) Lớp giao diện

Lớp giao diện có thể là một web server cung cấp các trang web tới các trình duyệt, một ứng dụng desktop bình thường với giao diện cửa sổ, hoặc là một web service - cung cấp giao diện sử dụng dịch vụ tới cho các ứng dụng khác

Trong trường hợp là web service, ranh giới giữa lớp giao diện và lớp nghiệp

vụ trở nên mờ nhạt Đó là do web service, đóng vai trò giao diện trong cấu trúc này, lại có thể được gọi bởi một thành phần đóng vai trò bất kỳ trong một cấu trúc khác Trong cấu trúc khác này, có thể coi web service kể trên là một phần của lớp nghiệp

vụ

b) Lớp nghiệp vụ

Lớp nghiệp vụ được thực hiện bởi các đổi tượng, được chứa trong các tiến trình chủ và được truy cập thông qua một số giao thức Có thể có nhiều lựa chọn khi thực hiện lớp nghiệp vụ Một trong các lựa chọn đó là webservice Sự lựa chọn giữa các phương thức được dựa trên các tiêu chí về quy mô của hệ thống, tốc độ đòi hỏi, khả năng hoạt động trên các hệ điều hành khác nhau Web service thường được sử dụng cho các ứng dụng có quy mô rất lớn, thông qua Internet Là một chuẩn được công nhận rộng rãi, Webservice có khả năng vượt qua ranh giới giữa các hệ điều hành khác nhau Tuy nhiên, với quy mô doanh nghiệp, giải pháp gọi hàm từ xa.NET Remoting tỏ ra phù hợp hơn, đáp ứng được các yêu cầu về tốc độ trong khi vẫn đảm bảo được quy mô của hệ thống

2.2.2.4 Đánh giá

a) Ưu điểm

Nền tảng của ứng dụng phân tán là khả năng gọi hàm từ xa, giữa các tiến trình nằm trên cùng một máy tính hay giữa các máy tính khác nhau Trong môi trường NET, khả năng này được cung cấp với nhiều phương án:

− Webservice cung cấp khả năng kết nối qua Internet các tiến trình trên các hệ điều hành khác nhau

− NET Remoting cung cấp khả năng kết nối các tiến trình với rất nhiều lựa chọn về giao thức, khuôn dạng dữ liệu

b) Nhược điểm

Nhược điểm đáng kể nhất của NET platform là sự gắn liền của nó với hệ điều hành Windows Tuy nhiên, hệ điều hành Windows cũng đã là hệ điều hành phổ biến nhất cho các máy trạm và Microsoft đang từng bước xây dựng thành công những phiên bản Windows dành cho các máy chủ Các máy tính sử dụng Windows chiếm một tỷ trọng rất lớn trên thế giới nói chung và tại Việt Nam nói riêng Mặt khác, có thể coi việc NET Framework được chạy trên ngôn ngữ trung gian IL là một bước tiến đưa platform này tới khả năng chạy trên mọi hệ điều hành

2.2.3 Lựa chọn công nghệ nền

Qua một số phân tích kể trên, có thể thấy rằng với Hệ thống quản lý yêu cầu khách hàng, NET platform tỏ ra phù hợp hơn Các máy tính trạm sử dụng tại các bưu điện đều sử dụng hệ điều hành Windows, do vậy , ưu điểm cơ bản của Java là

hỗ trợ nhiều hệ điều hành không phát huy được tác dụng Mặt khác, hệ thống có các đòi hỏi yêu cầu nghiêm ngặt về tốc độ và sự thân thiện của giao diện người dùng, điều này hoàn toàn phù hợp với mô hình phân tán sử dụng NET Remoting với ứng dụng máy trạm theo kiểu desktop Trên NET platform, cũng có thể dễ dàng thực hiện các mở rộng để hỗ trợ webservice, phục vụ cho việc phát triển hệ thống sau này Vì các lý do trên, NET platform được sử dụng để phát triển hệ thống quản lý Quan hệ khách hàng

2.3 Một số công cụ khác

2.3.1 Hệ quản trị cơ sở dữ liệu

Như đã phân tích ở trên, các hệ quản trị cơ sở dữ liệu thế hệ đầu tiên như Foxpro không đáp ứng được các yêu cầu của bài toán Hệ quản trị cơ sở dữ liệu Oracle được chọn với các tiêu chí sau:

− Cung cấp mô hình dữ liệu quan hệ

− Cung cấp các tính năng xử lý phức tạp và mạnh mẽ của một hệ quản trị cơ sở dữ liệu, bao gồm:

o Xử lý tương tranh

o Giao tác (transaction)

o Sao lưu và phục hồi (backup & recovery)

o Các tính năng tiên tiến như cluster, xử lý song song

− Sự quen thuộc đối với các thành viên tham gia nhóm phát triển cũng

là một tiêu chí quan trọng

2.3.2 Ngôn ngữ lập trình

Với công nghệ nền NET, các lựa chọn về ngôn ngữ lập trình khá nhiều, bao gồm:

− Các ngôn ngữ hỗ trợ bởi Microsoft Visual Studio NET

− Các ngôn ngữ khác có thể dịch ra ngôn ngữ MSIL (ngôn ngữ trung gian) để chạy trên CLR của NET

Trong các ngôn ngữ đó, C# được lựa chọn vì thỏa mãn được rất nhiều tiêu chí:

− Ngôn ngữ lập trình hướng đối tượng Đây là một tiêu chí quan trọng khi xây dựng các ứng dụng có quy mô lớn

− Được hỗ trợ bởi Microsoft Visual Studio NET Visual Studio NET được đánh giá là bộ công cụ hỗ trợ phát triển ứng dụng tốt nhất hiện nay với các tính năng gỡ rối, giao diện thiết kế kéo thả (drag and drop) Với Visual

Studio NET, thời gian phát triển ứng dụng được rút ngắn đáng kể, mà vẫn đảm bảo được chất lượng của chương trình

− Kết hợp được các tính năng mạnh mẽ (tương tác trực tiếp với hệ điều hành, truy nhập trực tiếp bộ nhớ, ) của C++ với cú pháp lập trình đơn giản,

rõ ràng của Java

Chương 3 Xây dựng ứng dụng phân tán trên NET platform

Sau các phân tích về công nghệ được trình bày ở Chương 2, công nghệ NET

đã được lựa chọn để phát triển hệ thống Quản lý yêu cầu khách hàng Chương này

đi sâu vào làm rõ các vấn đề về phát triển ứng dụng phân tán trên NET platform

Các vấn đề sẽ được đề cập trong chương này bao gồm:

− Cấu trúc ứng dụng phân tán trên NET

− Giải pháp cho giao tiếp giữa các

− An toàn hệ thống

+ Vấn đề kiểm tra quyền

+ Vấn đề bảo mật kênh truyền

Hình 3.1 : Cấu trúc ứng dụng phân tán trên môi trường NET

Trên Hình 3.1 là cấu trúc điển hình của một ứng dụng phân tán sử dụng NET platform

1) Giao diện nguời dùng

Hầu hết các ứng dụng phần mềm đều cần có một giao diện để người sử dụng

có thể giao tiếp được với ứng dụng Giao diện người dùng có thể thực hiện được bằng Windows Forms, các trang web ASP, các điều khiển hay bất kỳ kỹ thuật nào

có thể sử dụng để hiển thị, định dạng dữ liệu cho người dùng hoặc thu thập và kiểm tra dữ liệu do người dùng nhập vào

2) Các thành phần xử lý tiến trình giao diện

Trong nhiều trường hợp, các thao tác của người dùng với hệ thống được tiến hành theo một tiến trình định trước Ví dụ, tiến trình thực hiện đặt hàng có thể bao gồm: cửa sổ hiển thị thông tin về hàng hóa, cửa sổ cho phép người dùng lựa chọn

Giao diện người dùng

Người dùng

CSDL

Xử lý tiến trình giao diện

Giao diện cung cấp dịch vụ Tiến trình

nghiệp vụ Tác nghiệp Thực thể dữ liệu

Truy xuất cơ sở dữ

liệu Giao diện sử dụng dịch vụ

các sản phẩm, cửa sổ cho phép người dùng nhập các thông tin thanh toán và địa chỉ

để gửi hàng hóa Để thực hiện đồng bộ và tối ưu hóa các quá trình như vậy, có thể

sử dụng các thành phần xử lý tiến trình giao diện Theo cách này, logic điều khiển luồng thực hiện tiến trình (workflow) có thể được tách rời khỏi các thành phần giao diện người dùng Đồng thời, logic điều khiển này có thể được sử dụng lại cho các loại giao diện khác nhau (web, windows form, )

4) Các thành phần tác nghiệp (thực hiện nghiệp vụ)

Đây chính là các bước trong tiến trình nghiệp vụ Chẳng hạn trong ứng dụng bán hàng trực tuyến, có thể sẽ có một hàm thực hiện việc tính tổng giá trị của đơn đặt hàng, cộng thêm chi phí vận chuyển Các thành phần thực hiện nghiệp vụ là các bước làm nên quá trình nghiệp vụ của ứng dụng

5) Các thành phần giao tiếp sử dụng dịch vụ

Khi một thành phần thực hiện nghiệp vụ cần gọi tới một dịch vụ cung cấp bởi một hệ thống khác, sẽ cần thực hiện các công việc kết nối, kích hoạt, truyền tham số, lấy dữ liệu trả về từ dịch vụ đích đó Những công việc đó được thực hiện bởi các thành phần giao tiếp sử dụng dịch vụ Ví dụ, quá trình xử lý đơn đặt hàng có thể tại một thời điểm có nhu cầu gọi dịch vụ kiểm tra tính hợp lệ của tài khoản –

một quá trình được thực hiện bởi một hệ thống khác Quá trình gọi này sẽ được thực hiện bởi một thành phần giao tiếp sử dụng dịch vụ Các thành phần này sẽ tách biệt phần xử lý nghiệp vụ của một ứng dụng với phần logíc phức tạp để kết nối dịch vụ

từ ứng dụng khác Ngoài ra, các thành phần này có thể cung cấp các chức năng như chuyển đổi giữa khuôn dạng dữ liệu mà dịch vụ cung cấp với khuôn dạng dữ liệu

mà ứng dụng cần

6) Các giao diện cung cấp dịch vụ

Một hệ thống cung cấp dịch vụ cho các hệ thống khác thông qua các giao diện cung cấp dịch vụ Giao diện này quy định các cách thức yêu cầu và sử dụng dịch vụ

7) Các thành phần truy xuất dữ liệu

Hầu hết các ứng dụng đều cần truy xuất dữ liệu tại các điểm nào đó trong một tiến trình xử lý nghiệp vụ Chẳng hạn, chương trình bán hàng trên mạng sẽ cần lấy dữ liệu về các mặt hàng trong cơ sở dữ liệu để cung cấp cho khách hàng, và cần nhập dữ liệu về đơn đặt hàng vào cơ sở dữ liệu khi khách hàng quyết định mua hàng Phần công việc truy xuất dữ liệu đó được thực hiện trong các thành phần truy xuất dữ liệu, tách riêng khỏi các phần khác của ứng dụng, nhằm mục đích tránh cho các phần còn lại bị phụ thuộc vào loại hình cơ sở dữ liệu cụ thể

8) Các thực thể dữ liệu

Hầu hết trong các ứng dụng, dữ liệu cần được truyền giữa các thành phần của ứng dụng, qua các lớp ứng dụng Ví dụ, danh sách các sản phẩm cần được truyền từ các thành phần truy xuất dữ liệu tới lớp giao diện của chương trình Các thông tin này được lưu vào trong các thực thể dữ liệu, có thể là các đối tượng DataSet, DataReader, hoặc các luồng XML, hoặc đơn giản là một nhóm các biến thông thường được sắp xếp thành các cấu trúc (structure)

3.3 Giao tiếp giữa các thành phần của ứng dụng trên môi trường NET

3.3.1 Các phương pháp truyền thống trên các môi trường phi NET

Ngày nay, việc xây dựng các ứng dụng phân tán đã trả nên phổ biến Các ứng dụng như vậy bao gồm các thành phần phân bố trong một mạng các máy tính, kết hợp với nhau để hợp thành ứng dụng Trước đây, các ứng dụng phân tán thường

sử dụng một trong các công nghệ quen thuộc, bao gồm Mô hình đối tượng có thành phần phân tán của Microsoft (Microsoft® Distributed Component Object Model -DCOM), Cấu trúc trung gian yêu cầu đối tượng chung (Common Object Request Broker Architecture - CORBA) của OMG hay Kỹ thuật gọi hàm từ xa (Remote Method Invocation - RMI) của Sun Các kỹ thuật này cung cấp các kiến trúc ổn định và có tính mở cho ứng dụng

Các kỹ thuật kể trên hoạt động tương đối tốt trong môi trường mạng nội bộ Tuy nhiên trong môi trường Internet, chúng có 2 nhược điểm cơ bản Thứ nhất, các

kỹ thuật trên không thể kết hợp được với nhau Mặc dù về tổng thể, chúng đều làm việc với đối tượng, nhưng khi đi vào chi tiết lại khác nhau Ví dụ, chúng khác nhau

về sự kiểm soát chu trình sống của đối tượng, về hỗ trợ hàm tạo, cấp độ thừa kế Thứ hai và quan trọng hơn, các kỹ thuật trên đều tập trung vào các phương thức giao tiếp theo kiểu RPC (gọi thủ tục từ xa - Remote Procedure Call) Các giao tiếp theo kiểu này thường dẫn tới việc phụ thuộc chặt chẽ vào nhau giữa các thành phần tham gia vào quá trình giao tiếp

Trái với các công nghệ trên, các ứng dụng Web dựa trên trình duyệt lại có thể kết hợp với nhau khá tốt mà không dẫn tới sự phụ thuộc lẫn nhau Các ứng dụng này giao tiếp với nhau sử dụng HTTP để trao đổi các dữ liệu với các khuôn dạng khác nhau Web service là một sự mở rộng của các phương thức kết nối ứng dụng web Nó có thể được sử dụng cho tất cả các loại ứng dụng, chứ không chỉ ứng dụng Web dựa trên trình duyệt Web service cho phép các đối tác trao đổi các bản tin SOAP sử dụng HTTP và các giao thức Internet khác Vì Web service được xây