Ứng dụng mô hình kiến trúc hướng dịch vụ xây dựng hệ thống quản lý cơ sở vật chất trường đại học quảng bình

TRANG TÓM TẮT LUẬN VĂN ỨNG DỤNG MÔ HÌNH KIẾN TRÚC HƯỚNG DỊCH VỤ XÂY DỰNG HỆ THỐNG QUẢN LÝ CƠ SỞ VẬT CHẤT TRƯỜNG ĐẠI HỌC QUẢNG BÌNH Học viên: Nguyễn Văn Kiều - Chuyên ngành: Khoa học má

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

NGUYỄN VĂN KIỂU

ỨNG DỤNG MÔ HÌNH KIẾN TRÚC HƯỚNG DỊCH VỤ XÂY DỰNG HỆ THỐNG QUẢN LÝ CƠ SỞ VẬT CHẤT

TRƯỜNG ĐẠI HỌC QUẢNG BÌNH

Chuyên ngành: Khoa học máy tính

Mã số: 8480101

LUẬN VĂN THẠC SĨ KỸ THUẬT

Người hướng dẫn khoa học: TS ĐẶNG HOÀI PHƯƠNG

Đà Nẵng - Năm 2018

LỜI CAM ĐOAN

Tôi xin cam đoan:

- Những nội dung trong luận văn này là do tôi thực hiện dưới sự hướng dẫn

trực tiếp của TS Đặng Hoài Phương

- Mọi tham khảo dùng trong luận văn đều được trích dẫn rõ ràng tên

tác giả, tên công trình, thời gian, địa điểm công bố

- Các số liệu, kết quả nêu trong luận văn là trung thực và chưa từng được ai

công bố trong bất kỳ công trình nào khác

- Mọi sao chép không hợp lệ, vi phạm quy chế đào tạo, hay gian trá, tôi xin

chịu hoàn toàn trách nhiệm

Tác giả

Nguyễn Văn Kiểu

TRANG TÓM TẮT LUẬN VĂN

ỨNG DỤNG MÔ HÌNH KIẾN TRÚC HƯỚNG DỊCH VỤ XÂY DỰNG HỆ THỐNG QUẢN

LÝ CƠ SỞ VẬT CHẤT TRƯỜNG ĐẠI HỌC QUẢNG BÌNH

Học viên: Nguyễn Văn Kiều - Chuyên ngành: Khoa học máy tính

Mã số: 8480101 - Khóa:K34QB- Trường Đại học Bách khoa - ĐHĐN

Tóm tắt - Kiến trúc hướng dịch vụ đang được sử dụng rất rộng rãi và phổ biến trong quy

trình phát triển phần mềm hiện nay Xuất phát từ bài toán thực tế cần phát triển hệ thống quản

lý cơ sở vật chất cho trường Đại học Quảng Bình nhằm nâng cao hiệu quả của hoạt động quản

lý Đồng thời tạo thuận lợi cho việc tích hợp và mở rộng hệ thống trong tương lai, tác giả đã

đề xuất giải pháp xây dựng hệ thống quản lý cơ sở vật chất trường Đại học Quảng Bình trên

cơ sở giải pháp kiến trúc hướng dịch vụ Luận văn tiến hành phân tích giải pháp kiến trúc hướng dịch vụ trong việc phân tích và thiết kế phần mềm, đồng thời tác giả cũng nghiên cứu các công nghệ hỗ trợ xây dựng hệ thống trên cơ sở mô hình kiến trúc hướng dịch vụ: Web Service, Web API và các giao thức giao tiếp giữa các dịch vụ Web (SOAP, REST) Bên cạnh

đó, tác giả cũng tìm hiểu và áp dụng một số công nghệ và thư viện hỗ trợ của NET Framework để xây dựng hệ thống quản lý cơ sở vật chất trường Đại học Quảng Bình: mô hình Model View Controller, Entity Framework & ASP.NET Identity, … Từ đó đã xây dựng thành công hệ thống và triển khai hệ thống trong thực tế, đồng thời đánh giá mức độ hiệu quả của hệ thống mang lại trong thực tế

Từ khóa - Kiến trúc hướng dịch vụ; cơ sở vật chất; Model View Controller; Web Service;

Web API (5 từ khóa)

STUDY OF APPLICATION OF ARCHITECTURAL ARCHITECTURAL MODEL FOR

THE BUILDING OF QUANG BINH UNIVERSITY OF FACILITIES

Abstract - Service-oriented architecture is used widely in the current software development

process Based on the practical problem, it is necessary to develop the management system, for Quang Binh University in order to improve the efficiency of management activities In order to make a facilitate for future integration and expansion of the management system, we proposed a solution to build the infrastructure management system for Quang Binh University, which is based on the basis of service-oriented architecture solution In this thesis,

we analyze service-oriented architecture solutions for analysis and design, and also examines the supporting technologies for building software system based on the service-oriented architecture model: Web Services, Web APIs, and Web-based communication protocols (SOAP, REST) In addition, we also studied and applied some of the technologies and libraries, which are supported by the NET Framework, to build the facilities management system of Quang Binh University: model View Controller, Entity Framework & ASP.NET Identity, and so on It has successfully built the system and deployed the system in real-time, while evaluating the effectiveness of the system

Key words - Service Oriented Architecture; infrastructure; Model View Controller; Web

Service; Web API

MỤC LỤC

TRANG BÌA

LỜI CAM ĐOAN

TRANG TÓM TẮT LUẬN VĂN

MỤC LỤC

DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT

DANH MỤC CÁC HÌNH

MỞ ĐẦU 1

1 Lý do chọn đề tài 1

2 Mục đích nghiên cứu 2

3 Đối tượng và phạm vi nghiên cứu 2

4 Phương pháp nghiên cứu 2

5 Dự kiến kết quả đạt được 2

6 Ý nghĩa khoa học và thực tiễn 3

7 Cấu trúc luận văn 3

CHƯƠNG 1: TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ 4

1.1 Thực trạng hoạt động phát triển phần mềm hiện tại 4

1.2 Tổng quan kiến trúc hướng dịch vụ (Service Oriented Architecture) 7

1.2.1 Tính chất của hệ thống SOA 8

1.2.2 Lợi ích của SOA 13

1.3 Dịch vụ Web 14

1.4 Thực trạng hoạt động quản lý cơ sở vật chất trường Đại học Quảng Bình 17 1.5 Kết luận 18

CHƯƠNG 2: XÂY DỰNG GIẢI PHÁP SOA CHO HỆ THỐNG QUẢN LÝ CSVC TRƯỜNG ĐẠI HỌC QUẢNG BÌNH 19

2.1 Mô hình SOA tổng thể 19

2.2 Các công nghệ & kỹ thuật triển khai dịch vụ Web 20

2.2.1 Mô hình Model View Controller (MVC) 20

2.2.2 ASP.NET MVC 22

2.2.3 Entity Framework 23

2.2.4 Web API (.NET Framework) 25

2.2.5 Ứng dụng ASP.NET Identity trong cơ sở dữ liệu 27

2.3 Kết luận 29

CHƯƠNG 3: XÂY DỰNG VÀ TRIỂN KHAI HỆ THỐNG QUẢN LÝ CƠ SỞ VẬT CHẤT TRƯỜNG ĐẠI HỌC QUẢNG BÌNH 30

3.1 Thiết kế hệ thống 30

3.1.1 Sơ đồ phân rã chức năng 30

3.1.2 Biểu đồ ca sử dụng 31

3.1.3 Biểu đồ lớp 32

3.2 Xây dựng cơ sở dữ liệu 36

3.3 Xây dựng Web API 38

3.4 Triển khai hệ thống 41

3.5 Kết luận 43

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 44

TÀI LIỆU THAM KHẢO 45

QUYẾT ĐỊNH GIAO ĐỀ TÀI LUẬN VĂN THẠC SĨ (BẢN SAO) 46 BẢN SAO KẾT LUẬN CỦA HỘI ĐỒNG, BẢN SAO NHẬN XÉT CỦA CÁC

PHẢN BIỆN

DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT

6 CORBA Common Object Request Broker Architecture

10 REST Representational State Transfer

14 EAI Enterprise Architecture Integration

DANH MỤC CÁC HÌNH

Hình 1.1 – Các thành phần của đối tượng CORBA 5

Hình 1.2 – Mô hình tương tác của đối tượng EJB 6

Hình 1.3 – Mô hình tương tác của các đối tượng DCOM 6

Hình 1.4 – Sơ đồ cộng tác trong SOA 8

Hình 1.5 – Tính chất loose-coupling 9

Hình 1.6 – Các đối tượng fine-grained 11

Hình 1.7 – Các đối tượng coarse-grained 12

Hình 1.8 – Dịch vụ Web 15

Hình 1.9 – Giao thức giao tiếp SOAP & REST 16

Hình 1.10 – Ví dụ SOAP request 17

Hình 2.1 – Mô hình SOA tổng thể 19

Hình 2.2 - Mô hình MVC 20

Hình 2.3 - Mẫu Supervising Controller 21

Hình 2.4 - Mẫu Passive View 22

Hình 2.5 - Mô hình Entity Framework 24

Hình 2.6 - Application Programming Interface 25

Hình 2.7 - Cơ sở dữ liệu Identity 28

Hình 3.1 - Sơ đồ phân rã chức năng 30

Hình 3.2 - Biểu đồ ca sử dụng hệ thống quản lý CSVC trường ĐH Quảng Bình 32

Hình 3.3 - Biểu đồ lớp thể hiện chức năng quản lý CSVC & tài sản 33

Hình 3.4 - Biểu đồ lớp thể hiện chức năng quản lý tài khoản người dùng 34

Hình 3.5 - Biểu đồ lớp thể hiện chức năng quản lý yêu cầu 35

Hình 3.6 - Quản lý tài sản 36

Hình 3.7 - Quản lý yêu cầu 37

Hình 3.8 - Quản lý kế hoạch 37

Hình 3.9 - Xử lý tại controller 38

Hình 3.10 - Xử lý tại service 39

Hình 3.11 - Kiểm tra Web API 39

Hình 3.12 - Gọi sử dụng Web API 40

Hình 3.13 – Hiển thị dữ liệu ở view 40

Hình 3.14 – Giao diện tổng quan quản lý tài sản 41

Hình 3.15 – Giao diện quản lý nhóm tài sản 42

Hình 3.16 – Giao diện quản lý kế hoạch 42

Hình 3.17 – Giao diện báo cáo thống kê 43

MỞ ĐẦU

1 Lý do chọn đề tài

Sự phát triển của Internet đã thúc đẩy nhu cầu cộng tác, làm việc qua mạng và sử dụng các dịch vụ trực tuyến dần trở thành một nhu cầu thiết yếu trong cuộc sống của chúng ta Điều này đỏi hỏi các ứng dụng không chỉ là những hệ thống hoạt động đơn

lẻ trên một máy trạm (máy client) và chịu phụ thuộc vào một nền tảng cố định nào nữa,

mà chúng phải là những hệ thống linh động giúp người dùng làm việc “mọi lúc, mọi nơi” Điều đó đã làm các nhà phát triển phải đối mặt với hàng loạt các vấn đề mới như làm sao để tích hợp các thành phần phân tán lại với nhau, hay tái sử dụng những thành phần sẵn có, vấn đề triển khai và bảo trì… đang là một vấn đề làm các nhà phát triển phải suy nghĩ

Tuy vậy, một thực tế hiện nay là phần mềm đang ngày càng trở nên phức tạp quá mức và dường như đang vượt khỏi khả năng kiểm soát của các mô hình phát triển hiện

có Nguyên nhân khiến cho hệ thống có độ phức tạp tăng cao là do sự xuất hiện của nhiều công nghệ mới tạo nên môi trường không đồng nhất, trong khi nhu cầu chia sẽ, trao đổi, tương tác giữa các hệ thống ngày càng tăng và không thể đáp ứng được trong môi trường này Cùng với đó là vấn đề lập trình dư thừa và không thể tái sử dụng gây tốn kém rất nhiều không những trong giai đoạn phát triển hệ thống mà trong cả vận hành bảo trì phần mềm Giải pháp cho các vấn đề này là gì?

Có nhiều giải pháp khác nhau để xây dựng hệ thống quản lý cơ sở vật chất nêu trên, tuy nhiên ứng dụng mô hình Kiến trúc hướng dịch vụ hội tụ đủ các khả năng đáp ứng yêu cầu và có nhiều ưu điểm hơn Hiện nay, Kiến trúc hướng dịch vụ đang rất phát triển và có nhiều ứng dụng Giá trị cơ bản của nó dựa trên việc cung cấp các phương thức theo chuẩn trong việc truy nhập đối với hệ thống đóng gói và hệ thống kế thừa

“Service Oriented Architecture” hay “kiến trúc hướng dịch vụ” là mô hình phát triển kiến trúc phần mềm đang được các nhà chuyên môn quan tâm phát triển hiện nay Với ưu điểm linh hoạt khi mở rộng, kết nối và có thể tái sử dụng dịch vụ

Do đặc thù của các Trường Đại học nói chung và Trường Đại học Quảng Bình nói riêng, khối lượng tài sản khá lớn nhưng giá trị tài sản phần lớn là thấp và nó thuộc

về công cụ, dụng cụ… nên cần thiết phải có một hệ thống đáp ứng được các yêu cầu nghiệp vụ của hoạt động quản lý cơ sở vật chất theo yêu cầu đặt ra của nhà trường Hơn nữa, là một Trường Đại học địa phương khả năng tài chính còn hạn chế nên việc

sở hữu một phần mềm thương mại để quản lý CSVC của nhà trường là điều rất khó khăn

Xuất phát từ những lý do trên, tác giả đề xuất lựa chọn đề tài “Ứng dụng mô hình kiến trúc hướng dịch vụ xây dựng hệ thống quản lý cơ sở vật chất Trường Đại học Quảng Bình” làm đề tài tốt nghiệp luận văn cao học

2 Mục đích nghiên cứu

Mục đích nghiên cứu của đề tài là nghiên cứu, ứng dụng kiến trúc hướng dịch vụ

phát triển hệ thống quản lý cơ sở vật chất Trường Đại học Quảng Bình

3 Đối tượng và phạm vi nghiên cứu

- Nghiên cứu lập trình phân tán;

- Nghiên cứu mô hình kiến trúc hướng dịch vụ;

- Xây dựng cơ sở dữ liệu phục vụ hoạt động quản lý cơ sở vật chất trường Đại học Quảng Bình;

- Ứng dụng Web Services, Web API phát triển hệ thống quản lý cơ sở vật chất trường Đại học Quảng Bình;

Đề tài tập trung vào nghiên cứu nắm vững lý thuyết của kiến trúc hướng dịch vụ, cách giải quyết vấn đề trong kiến trúc hướng dịch vụ Vận dụng vào hệ thống quản lý

cơ sở vật chất tại trường Đại học Quảng Bình

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

4.1 Phương pháp lý thuyết

- Nghiên cứu cơ sở lý thuyết về kiến trúc hướng dịch vụ

- Nghiên cứu công nghệ Web service & Web API;

- Nghiên cứu mô hình logic Model View Controller (MVC) trong phát triển ứng dụng Web

4.2 Phương pháp thực nghiệm

- Xây dựng cơ sở dữ liệu về cơ sở vật chất trường Đại học Quảng Bình

- Hiện thực hóa hệ thống Website quản lý cơ sở vật chất trường Đại học Quảng Bình trên cơ sở mô hình kiến trúc hướng dịch vụ sử dụng Web API và mô hình MVC

5 Dự kiến kết quả đạt được

5.1 Về lý thuyết

- Hiểu được mô hình kiến trúc hướng dịch vụ

- Hiểu được mô hình MVC, Web Services, Web API, SOAP, REST…

5.2 Về thực nghiệm

- Xây dựng phần mềm quản lý cơ sở vật chất tại Trường Đại học Quảng Bình

- Ứng dụng chạy trên website Trường Đại học Quảng Bình

6 Ý nghĩa khoa học và thực tiễn

Xây dựng mô hình giải pháp quản lý cơ sở vật chất theo hướng dịch vụ Xây dựng chương trình ứng dụng trên cơ sở mô hình giải pháp để quản lý tài sản và nâng cao tính chính xác, chất lượng trong công tác quản lý

Đề xuất áp dụng mô hình cho các hệ thống phần mềm quản lý khác được cung cấp

7 Cấu trúc luận văn

Luận văn gồm có phần mở đầu, kết luận và 3 chương

Chương 1: Tổng quan về kiến trúc hướng dịch vụ (SOA)

Chương 2: Xây dựng giải pháp SOA cho hệ thống quản lý cơ sở vật chất trường Đại học Quảng Bình

Chương 3: Xây dựng và triển khai hệ thống quản lý cơ sở vật chất trường Đại học Quảng Bình

CHƯƠNG 1: TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ

1.1 Thực trạng hoạt động phát triển phần mềm hiện tại

Phần mềm ngày nay đang ngày càng trở nên phức tạp và dường như đang vượt khỏi khả năng kiểm soát của các mô hình phát triển phần mềm hiện có Albert Einstein

đã nói : “Mọi việc nên thực hiện theo cách đơn giản đến mức có thể…” , Hiện nay có nhiều hệ thống phần mềm được xây dựng với kiến trúc quá phức tạp, chi phí phát triển

và bảo trì cao, đặc biệt là với các hệ thống phần mềm cao cấp Độ phức tạp của các hệ thống kiến trúc phần mềm ngày một tăng do các nguyên nhân sau:

Sự xuất hiện của nhiều công nghệ mới tạo nên môi trường không đồng nhất trong khi nhu cầu chia sẻ, tương tác, trao đổi của các hệ thống không thể tiến hành trong môi trường như thế Giải quyết vấn đề này nghĩa là cần phải thay đổi hệ thống theo một chuẩn thống nhất chung nào đó Điều chủ yếu là hệ thống cũ cần được sử dụng lại chứ không phải gỡ bỏ thay mới bởi vấn đề chi phí cho thiết lập một hệ thống quản lý mới tốn kém hơn nhiều so với chuyển đổi cái cũ Vấn đề này đưa đến một khái niệm là “Tích hợp hệ thống” (Enterprise Architecture Integration - EAI)

Một nguyên nhân khác cũng góp phần dẫn đến tình trạng khó khăn như thế chính

là vấn đề lập trình dư thừa và không thể tái sử dụng Ví dụ: một doanh nghiệp có nhiều chi nhánh khác nhau, mỗi chi nhánh lại có một hệ thống tách biệt & xây dựng ở những thời điểm khác nhau & cần kết nối lại với nhau sẽ không tránh khỏi việc sử dụng dư thừa tài nguyên, dữ liệu không đồng nhất, …

Do đó, kiến trúc phân tán (CORBA, DCOM và EJB) được áp dụng để xây dựng các hệ thống có khả năng tích hợp nhằm giải quyết vấn đề nêu trên Các kiến trúc này

là sự mở rộng của các hệ thống hướng đối tượng bằng cách cho phép phân tán các đối tượng trên mạng Đối tượng đó có thể có không gian địa chỉ bên ngoài ứng dụng, hoăc

ở một máy khác với máy chứa ứng dụng trong khi vẫn được tham chiếu sử dụng như một phần của ứng dụng

CORBA (Common Object Request Broker Architecture):

CORBA được định nghĩa bởi Object Management Group (OMG) [http://www.corba.org], là một kiến trúc phân tán mở, độc lập nền tảng và độc lập ngôn ngữ CORBA Component Model (CCM) là một cải tiến đáng kể nhằm định nghĩa các mô hình thành phần so với CORBA Nó định nghĩa ra quy trình thiết kế, phát triển, đóng gói, triển khai và thực thi các thành phần phân tán CCM định nghĩa khái niệm Ports cho các thành tố Các port này được sử dụng để kết nối các thành phần

có sẵn với nhau, tạo các hệ thống phân tán phức tạp hơn Mỗi thành phần CCM có một đối tượng Home chịu trách nhiệm quản lý chu kỳ sống của đối tượng và được triển khai bên trong một trình chứa (container)

Hình 1.1 – Các thành phần của đối tượng CORBA

Ưu điểm của CORBA là các lập trình viên có thể chọn bất kỳ ngôn ngữ, nền tảng phần cứng, giao thức mạng và công nghệ để phát triển mà vẫn thoả các tính chất của CORBA Tuy nhiên CORBA số một nhược điểm là nó là ngôn ngữ lập trình cấp thấp, rất phức tạp, khó học và cần một đội ngũ phát triển có kinh nghiệm Ngoài ra các đối tượng CORBA cũng khó có thể tái sử dụng

EJB – Enterprise Java Bean:

Kiến trúc EJB [www.oracle.com] là một kiến trúc thành tố bên phía máy chủ dùng cho việc phát triển và triển khai các ứng dụng phân tán hướng đối tượng cỡ vừa

và lớn Kiến trúc EJB có 3 tầng với tầng đầu tiên là tầng trình diễn, tầng thứ hai là tầng

xử lý nghiệp vụ, và tầng thứ ba là các tài nguyên như cơ sở dữ liệu máy chủ Truyền thông giữa các đối tượng EJB thông qua Remote Method Invocation (RMI) [1] Các client không bao giờ tương tác trực tiếp với các bean Thay vì vậy chúng sẽ sử dụng các phương thức được định nghĩa trong các interface Remote và Home Mỗi bean tồn tại bên trong trình chứa, chịu trách nhiệm việc tạo thể hiện mới, lưu trữ dữ liệu và các quản lý khác Trình chứa sẽ triệu gọi các phương thức callback của mỗi thể hiện bean khi có sự kiện tương ứng Không giống như CCM, EJB không định nghĩa các port kết nối trực tiếp giữa các thành phần liên quan bởi vì mỗi bean bên trong trình chứa là một thực thể độc lập không có bất kỳ ràng buộc nào bên ngoài

Hình 1.2 – Mô hình tương tác của đối tượng EJB EJB là một kiến trúc tốt cho việc tích hợp các hệ thống vì nó độc lập nền tảng nhưng nó cũng gặp vấn đề là nó không phải là một chuẩn mở, khả năng giao tiếp với các chuẩn khác vẫn còn hạn chế

DCOM - Distributed Component Object Model:

DCOM là một mô hình phân tán dễ triển khai với chi phí thấp, hỗ trợ tigh coupling giữa các ứng dụng và hệ điều hành Mô hình Component Object Model (COM) định nghĩa cách thức các các thành phần và client liên lạc trao đổi với nhau trên cùng một máy DCOM mở rộng COM bằng cách sử dụng các giao thức mạng chuẩn khi cần trao đối dữ liệu với máy khác trên mạng DCOM hỗ trợ kết nối giữa các đối tượng và những kết nối này có thể được thay đổi lúc đang chạy Các đối tượng DCOM được triển khai bên trong các gói nhị phân chứa các mã lệnh quản lý chu kỳ sống của đối tượng và việc đăng ký đối tượng

Hình 1.3 – Mô hình tương tác của các đối tượng DCOM

DCOM mang đến nhiều ưu điểm như tính ổn định, không phụ thuộc vị trí địa lý, quản lý kết nối hiệu quả và dễ dàng mở rộng, là một lựa chọn tốt cho các doanh nghiệp

sử dụng công nghệ của Windows để chạy các ứng dụng có yêu cầu cao về sự chính xác

và ổn định Tuy nhiên, các công nghệ của Microsoft có một nhược điểm lớn là chúng

bị giới hạn trên nền tảng Windows

Các kiến trúc phân tán nêu trên đều hướng đến việc xây dựng một hệ thống

“hướng dịch vụ” tuy nhiên chúng vẫn còn gặp phải một số vấn đề:

- Tighly coupled, nghĩa là kiến trúc triển khai cài đặt bên phía nhà cung cấp dịch

vụ và phía sử dụng dịch vụ phải giống nhau Điều này đồng nghĩa với khó khăn mỗi khi có sự thay đổi từ một trong 2 phía bởi vì mỗi thay đổi cần được đánh giá, lên kế hoạch và sửa chữa ở cả 2 phía;

- Những chuẩn trên đa phần là chuẩn đóng, chúng hầu như không thể kết hợp, hoạt động với chuẩn khác Ví dụ như bắt đối tượng Java trao đổi dữ liệu trực tiếp với một đối tượng DCOM là không thể Cuối cùng các đối tượng của các mô hình trên là fine grained, nghĩa là lượng thông tin giữa trong mỗi lần thực hiện giao dịch là ít, và được thực hiện nhiều lần dẫn đến chiếm dụng băng thông sử dụng và tăng thời lượng đáp trả dữ liệu

Một vấn đề đặt ra là làm thế nào để các hệ thống phân tán phát triển trên các công nghệ khác nhau có thể giao tiếp được với nhau? Và cách tiếp cận “kiến trúc hướng dịch vụ” Service Oriented Architecture (SOA) cho phép giải quyết vấn đề nêu trên [1]

1.2 Tổng quan kiến trúc hướng dịch vụ (Service Oriented Architecture)

SOA [2] là một hướng tiếp cận với việc thiết kế và tích hợp các phần mềm, chức năng, hệ thống theo dạng module, trong đó mỗi module đóng vai trò là một “dịch vụ” (service) tự hoạt động và liên kết lỏng lẻo, và có khả năng truy cập thông qua môi trường mạng Hiểu một cách đơn giản thì một hệ thống SOA là một tập hợp các dịch

vụ được chuẩn hóa trên mạng trao đổi với nhau trong một ngữ cảnh tiến trình nghiệp

vụ Một giải pháp SOA bao gồm một tập các dịch vụ nghiệp vụ mà thực hiện một quy trình nghiệp vụ SOA là một kiểu kiến trúc có khả năng mở rộng, bao gồm các service

có khả năng tương tác, khả năng khám phá, tự trị, có thể phục vụ cho nhiều khách hàng khác nhau, và có khả năng sử dụng lại

Trong SOA có 3 đối tượng chính (hình 1.4):

Hình 1.4 – Sơ đồ cộng tác trong SOA Nhà cung cấp dịch vụ (service provider) cần cung cấp thông tin về dịch vụ của mình cho một dịch vụ lưu trữ thông tin dịch vụ (service registry) Người yêu cầu dịch

vụ hay khách hàng (service requestor / consumer) thông qua service registry để tìm kiếm thông tin mô tả về dịch vụ cần tìm và sau đó là xây dựng kênh giao tiếp với phía nhà cung cấp

SOA cung cấp giải pháp để giả quyết các vấn đề tồn tại của các hệ thống hiện nay như: phức tạp, không linh hoạt và không ổn định Một hệ thống triển khai theo mô hình SOA có khả năng dễ mở rộng, liên kết tốt Đây chính là cơ sở và nền tảng cho việc tích hợp, tái sử dụng lại những tài nguyên hiện có

1.2.1 Tính chất của hệ thống SOA

1.2.1.1 Loose coupling

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à lỏng (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 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ịch vụ cần sử dụng Registry sẽ trả về tất cả những dịch vụ thỏa 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 1.5 – Tính chất loose-coupling 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 chuyển yêu cầu giữa các hệ thống đầu cuối

1.2.1.2 Sử dụng lại 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ụ 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 hoá 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à những shared infrastructure service

1.2.1.3 Sử dụng dịch vụ bất đồng bộ

Trong phương thức triệu gọi dịch vụ bất đồng bộ, bên gọi gửi một thông điệp với đầy đủ thông tin ngữ cảnh tới bên nhận Bên nhận xử lý thông tin và trả kết quả về thông qua một “kênh thông điệp”, bên gọi không phải chờ cho đến khi thông điệp được xử lý xong Khi sử dụng kết hợp thông điệp dạng coarse-grained với một dịch vụ chuyển thông điệp, các yêu cầu dịch vụ có thể được đưa vào hàng đợi và xử lý với tốc

độ tối ưu Do bên gọi không phải chờ cho đến khi yêu cầu được xử lý xong và trả về nên không bị ảnh hưởng bởi việc xử lý trễ và lỗi khi thực thi các dịch vụ bất đồng bộ Trên lý thuyết một hệ thống SOA có thể hỗ trợ gửi và nhận cả thông điệp đồng bộ và bất đồng bộ

1.2.1.5 Coarse granularity

Khái niệm granularity trong dịch vụ có thể hiểu theo hai cách Đầu tiên, nó được hiểu trong phạm vi toàn bộ kiến trúc cài đặt của dịch vụ Thứ hai, nó được hiểu trong phạm vi từng phương thức của từng interface triển khai Mức độ granularity cũng được hiểu ở mức tương đối Ví dụ, nếu một dịch vụ cài đặt tất cả chức năng của một hệ

thống ngân hàng, chúng ta xem nó là coarse-grained Nếu nó hỗ trợ chỉ chức năng kiểm tra thẻ tính dụng, chúng ta lại xem nó là finegrained

Trước khi có kiến trúc thành tố và dịch vụ, các hệ thống phân tán chủ yếu dựa trên ý tưởng phân tán đối tượng Những hệ thống phân tán đối tượng chứa bên trong

nó nhiều đối tượng fine-grained trao đổi thông tin với nhau qua mạng Mỗi đối tượng

có những ràng buộc với nhiều đối tượng khác bên trong hệ thống Do truy cập đến một đối tượng phải qua nhiều trung gian mà hiệu quả đạt được không cao nên khuynh

hướng thiết kế hệ thống phân tán đối tượng đang dần chuyển sang thiết kế các grained interface

coarser-Khi một hệ thống phân tán đối tượng với nhiều mối liên kết (hình 1.5), cùng với kích thước và độ phức tạp của hệ thống ngày càng tăng, những ràng buộc này trở nên ngày càng khó quản lý Hiệu suất cũng giảm tương ứng số lượng các kết nối trung gian Khả năng bảo trì cũng giảm khi số lượng ràng buộc giữa những đối tượng ngày một tăng Khi một đối tượng cần được thay đổi ở interface, nó có thể ảnh hưởng đến một lượng lớn những đối tượng phân tán khác Nhân viên phát triển phải biên dịch và triển khai lại toàn bộ đối tượng bị thay đổi và những đối tượng liên quan với chúng

Một hệ thống dựa trên quản lý các truy cập đến đối tượng bên trong dịch vụ thông qua một số coarse-grained interface như hình 1.6 Một dịch vụ có thể được cài đặt như một tập những đối tượng fine-grained nhưng bản thân những đối tượng đó lại được sử dụng trực tiếp qua mạng Trong khi đó một service được cài đặt như những đối tượng có một hoặc nhiều đối tượng coarse-grained hoạt động như những facades phân tán thì những đối tượng này lại có thể được sử dụng qua mạng và cho phép truy cập đến các đối tượng sâu bên trong Tuy nhiên các đối tựơng bên trong service đó bây giờ sẽ trao đối trực tiếp với nhau ở trong cùng một máy chứ không phải trên mạng

Hình 1.6 – Các đối tượng fine-grained

Hình 1.7 – Các đối tượng coarse-grained Mặc dù những service nói chung hỗ trợ coarser-grained interface hơn các hệ thống phân tán đối tượng và các hệ thống hướng thành tố, độ “thô” vẫn hàm chứa bên

trong nó chứa một mức độ granularity nào đó

1.2.1.6 Khả năng cộng tác

Kiến trúc hướng dịch vụ nhấn mạnh đến khả năng cộng tác (Interoperability), khả năng mà các hệ thống có thể giao tiếp với nhau trên nhiều nền tảng và ngôn ngữ khác nhau Mỗi dịch vụ cung cấp một interface có thể được triệu gọi thông qua một dạng kết nối Một kết nối gọi là interoperable chứa bên trong nó một giao thức và một định dạng dữ liệu mà mỗi client kết nối đến nó đều hiểu Interoperability is achieved bằng cách hỗ trợ các giao thức và định dạng dữ liệu chuẩn của dịch vụ và các client Kỹ thuật này đạt được bằng cách ánh xạ mỗi tính chất và ngôn ngữ qua một đặc tả trung gian Đặc tả trung gian sẽ chịu trách nhiệm ánh xạ giữa định dạng của dữ liệu khả kết (interoperable) đến định dạng dữ liệu tùy thuộc vào nền tảng hệ thống Ví dụ Web Service là một đặc tả trung gian cho giao tiếp giữa các hệ thống, JAX-RPC và JAXM chuyển đối tượng dạng Java thành SOAP

1.2.1.7 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í giao 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 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ác 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

1.2.1.8 Tự hồi phục

Với kích cỡ và độ phức tạp của những ứng dụng phân tán 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ế nào 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 trê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 client chỉ tương tác với interface của dịch vụ chứ 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ụ

1.2.2 Lợi ích của SOA

Giải pháp xây dựng các hệ thống phần mềm dựa trên kiến trúc hướng dịch vụ mang lại những ưu điểm sau:

- Sử dụng lại những thành phần có sẵn, kết quả là giảm chi phí cho phần kiến trúc

và tích hợp;

- Giải pháp ứng dụng tổng hợp cho doanh nghiệp: bằng cách kết hợp chức năng

từ những hệ thống có sẵn, cung cấp cho người cuối những chức năng liên kết Ở đây một số tiến trình cũ có thể được kết hợp với nhau bên trong một cổng thông tin (portal) giúp cho người dùng cuối chỉ cần truy cập một lần mà vẫn có thông tin về hàng loạt sản phẩm của doanh nghiệp;

- Tính loose coupling giúp tăng tính linh hoạt và khả năng triển khai cài đặt Thể hiện ở chỗ phía triệu gọi dịch vụ không cần quan tâm đến địa chỉ hoặc công nghệ nền tảng của service;

- Cho phép thích ứng với những thay đổi trong tương lai, phát triển phần mềm có thể tạo nên những quy trình nghiệp vụ uyển chuyển, phức tạp biến đổi tùy “theo yêu cầu” và theo “thời gian thực”;

- Hỗ trợ đa thiết bị và đa nền tảng: SOA cung cấp một tầng giao tiếp trừu tượng

từ các nền tảng bên dưới Điều này cho phép hỗ trợ nhiều loại thiết bị đầu cuối khác nhau bao gồm cả những trình duyệt và thiết bị di động như pager, điện thoại di động, PDA và các thiết bị chuyên dụng khác sử dụng cùng một chức năng mà vẫn có thông tin trả về tùy theo dạng thiết bị;

- Tăng khả năng mở rộng và khả năng sẵn sàng cung cấp bằng cách thêm nhiều thể hiện (instance) của một service Công nghệ chia tải (load-balancing) sẽ tự động tìm

và định tuyến yêu cầu đến thể hiện service thích hợp Tương tự, SOA có thể chuyển tiếp nội dung yêu cầu đến một thể hiện khác khi cần, nhờ đó tăng khả năng sẵn sàng phục vụ

1.3 Dịch vụ Web

Đặc điểm chính của SOA là tách rời phần giao tiếp với phần thực hiện dịch vụ Hiện nay có khá nhiều công nghệ để thực hiện SOA dựa trên dịch vụ Web (Web service)

Web Service (WS) là một khái niệm rộng hơn so với khái niệm web thông thường Nó là sự kết hợp các máy tính cá nhân với các thiết bị khác, các cơ sở dữ liệu

và các mạng máy tính để tạo thành một cơ cấu tính toán ảo mà người sử dụng có thể làm việc thông qua các trình duyệt mạng Các WS thường cung cấp các dữ liệu thô mà

nó khó hiểu đối với đa số người dùng thông thường, chúng thường được trả về dưới dạng XML hoặc JSON

Hình 1.8 – Dịch vụ Web

Ưu điểm của WS:

- Web service cung cấp nền tảng rộng lớn chạy được trên các hệ điều hành khác nhau

- Năng cao khả năng tái sử dụng

- Tạo mối quan hệ tương tác lẫn nhau, dễ dàng cho việc phát triển các ứng dụng phân tán

- Thúc đẩy mạnh mẽ vào hệ thống tích hợp và giảm được sự phức tạp của hệ thống, giảm giá thành phần tương tác tốt với hệ thống doanh nghiệp

- Sử dụng các giao thức và chuẩn mở, giao thức và định dạng dữ liệu dựa trên văn bản giúp các lập trình viên dễ dàng hiểu được

Tuy nhiên, bên cạnh đó WS cũng tồn tại một số nhược điểm:

- Có nhiều chuẩn khiến người dùng khó nắm bắt

- Có thể xảy ra thiệt hại lớn vào khoảng thời gian không hoạt động của web service như: có thể lỗi nếu như máy tính không nâng cấp, thiếu các giao tiếp trong việc vận hành

- Phải quan tâm nhiều hơn đến vấn đề bảo mật

Trong SOA, người ta thường sử dụng hai giải chuẩn giao thức giao tiếp cho Web service là: SOAP (Simple Object Access Protocol) và REST (Representational State Transfer)

Hình 1.9 – Giao thức giao tiếp SOAP & REST

Cả SOAP và REST đều có những điểm tương đồng trên giao thức HTTP, SOAP

là một tổ hợp các pattern truyền tin nghiêm ngặt hơn REST Quy định trong SOAP là rất quan trọng bởi vì nếu thiếu chúng, chúng ta không thể đạt được bất kì level tiêu chuẩn hóa nào REST mang một kiến trúc không yêu cầu quy trình và linh hoạt hơn

SOAP Simple Object Access Protocol:

SOAP […] là một giao thức dựa trên XML […] cho phép các ứng dụng trao đổi thông tin qua HTTP, được thiết kế đơn giản và dễ mở rộng Hiểu đơn giản, SOAP là một giao thức để truy cập Web Services, một giao thức truyền thông hay một định dạng để gửi thông điệp Tất cả các thông điệp SOAP đều được mã hóa sử dụng XML, cho nên không bị ràng buộc bởi bất kỳ ngôn ngữ lập trình nào hoặc công nghệ nào SOAP dựa hoàn toàn vào XML để cũng cấp các services truyền tin Microsoft ban đầu phát triển SOAP để thay thế cho các công nghệ cũ hơn không hoạt động tốt trên Internet như Distributed Component Object Model (DCOM) and Common Object Request Broker Architecture (CORBA) Những công nghệ này không thành công vì chúng dựa vào truyền tin nhị phân, cách truyền tin XML mà SOAP sử dụng làm việc tốt hơn qua Internet

Hình 1.10 – Ví dụ SOAP request REST Representational State Transfer:

REST cung cấp giải pháp thay thế nhẹ hơn Thay vì sử dụng XML để tạo request, REST dựa vào một URL đơn giản Trong một số trường hợp, cần phải cung cấp thông tin bổ sung theo những cách đặc biệt, nhưng hầu hết các Web service sử dụng REST đều dựa hoàn toàn vào việc thu lại các thông tin cần thiết bằng phương pháp URL REST có thể sử dụng bốn hình thái HTTP khác nhau (GET, POST, PUT, và DELETE)

để thực hiện các tasks Không giống như SOAP, REST không phải sử dụng XML để cung cấp response

1.4 Thực trạng hoạt động quản lý cơ sở vật chất trường Đại học Quảng Bình

Đại học Quảng Bình là một địa phương có khối lượng tài sản khá lớn nhưng giá trị tài sản phần lớn là thấp và nó thuộc về công cụ, dụng cụ kinh phí để mua trang thiết

bị chưa được đồng bộ, nên hoạt động quản lý cơ sở vật chất của Nhà trường chủ yếu vẫn áp dụng các công cụ thủ công (Word, Excel, …) Mặc dù Nhà trường cũng đã xây dựng hệ thống tra cứu, quản lý tài sản, tuy nhiên các chức năng của hệ thống chỉ mới dừng lại ở mức độ tra cứu, quản lý thông thường; chưa đáp ứng được yêu cầu về mặt hiệu quả công việc

Bên cạnh đó, với sự thay đổi của các nghiệp vụ trong hoạt động quản lý cơ sở vật chất thì việc thay đổi, bổ sung chức năng cho hệ thống nêu trên cũng gặp nhiều khó khăn do sự không tương thích của các module bổ sung

Vì vậy vấn đề đặt ra là cần thiết phải xây dựng một hệ thống hỗ trợ nghiệp vụ quản lý CSVC trường Đại học Quảng Bình, không những đáp ứng các nhu cầu nghiêp

vụ hiện tại mà còn phải có khả năng mở rộng, thay đổi trong tương lai nhằm nâng cao hiệu quả của hoạt động quản lý cơ sở vật chất của Nhà trường

Do đó tác giả lựa chọn đề tài “Nghiên cứu, ứng dụng kiến trúc hướng dịch vụ xây dựng hệ thống quản lý cơ sở vật chất trường Đại học Quảng Bình”, áp dụng mô hình SOA để phát triển hệ thống nhằm nâng cao khả năng tích hợp linh hoạt, mang lại hiệu quả về mặt kinh tế

CHƯƠNG 2: XÂY DỰNG GIẢI PHÁP SOA CHO HỆ THỐNG QUẢN LÝ CSVC TRƯỜNG ĐẠI HỌC QUẢNG BÌNH

2.1 Mô hình SOA tổng thể

Cơ chế hoạt động quản lý cơ sở vật chất trường Đại học Quảng Bình được thực hiện như sau: đầu mỗi năm, các đơn vị trong nhà trường cần lập kế hoạch mua sắm,

sửa chữa trang thiết bị, phương tiện làm việc hàng năm hoặc đột xuất, phòng

Quản trị sẽ tổng hợp trình Hiệu trưởng xem xét, quyết định phê duyệt Trên cơ

sở kế hoạch đã được duyệt, các đơn vị đề xuất yêu cầu mua sắm 7 sửa chữa chi tiết theo từng thời điểm cụ thể

Các loại thiết bị, máy móc trong trường do Phòng Quản trị quản lý; do đó cần xác định được số lượng, tình trạng, đơn vị sở hữu… của từng thiết bị chi tiết Đồng thời hàng năm cần phải kiểm kê tài sản, thống kê báo cáo tình hình sử dụng trang thiết bị để nhà trường lập kế hoạch mua sắm và sửa chữa chung cho năm tiếp theo cho phù hợp

Do đó vấn đề đặt ra là cần thiết phải xây dựng một hệ thống quản lý cơ sở vật chất trường Đại học Quảng Bình đáp ứng các hoạt động nghiệp vụ nêu trên đồng thời phải có khả năng mở rộng, tích hợp các nghiệp vụ khác trong tương lai Tác giả đề xuất xây dựng hệ thống trên cơ sở mô hình kiến trúc hướng dịch vụ như sau:

Hình 2.1 – Mô hình SOA tổng thể

- Tầng client: bao gồm giao diện hệ thống Website quản lý cơ sở vật chất trường Đại học Quảng Bình

- Tầng service: bao gồm các dịch vụ hỗ trợ nghiệp vụ quản lý cơ sở vật chất (quản lý danh mục, quản lý đề xuất, quản lý thống kế, …)

- Tầng kết nối CSDL: thực hiện việc tương tác với cơ sở dữ liệu của hệ thống

2.2 Các công nghệ & kỹ thuật triển khai dịch vụ Web

2.2.1 Mô hình Model View Controller (MVC)

Mô hình MVC [Model View Controller] đóng vai trò quan trọng trong quá trình xây dựng, phát triển, vận hành và bảo trì một hệ thống hay một ứng dụng phần mềm

Nó tạo ra một mô hình 3 lớp Model – View – Controller tách biệt và tương tác nhau, giúp cho việc trao đổi và xử lý những nghiệp vụ một cách nhanh chóng và dễ dàng

Mô hình MVC chủ yếu áp dụng cho các hệ thống phần mềm Website và được sử dụng với các ngôn ngữ lập trình Web phổ biến hiện nay: PHP, ASP.NET, JSP, …

- Model: là thành phần chứa tất cả các nghiệp vụ logic, phương thức xử lý, truy xuất cơ sở dữ liệu, đối tượng mô tả dữ liệu như các lớp, hàm xử lý, …

- View: là thành phần đảm nhận việc hiển thị thông tin, tương tác với người dùng, nơi chứa tất cả các đối tượng GUI như textbox, images, Có thể hiểu một cách đơn giản, nó là tập hợp các form hoặc các file HTML

- Controller: giữ nhiệm vụ nhận điều hướng các yêu cầu từ người dùng và gọi đúng các phương thức sẽ xử lý chúng Ví dụ: thành phần này sẽ nhận request từ url và form để thao tác trực tiếp với Model

Hình 2.2 - Mô hình MVC Tác giả lựa chọn mô hình MVC để phát triển hệ thống quản lý cơ sở vật chất trường Đại học Quảng Bình vì:

- Mô hình này được sử dụng không phụ thuộc môi trường, nền tảng xây dựng hay ngôn ngữ lập trình phát triển;

- Quy hoạch các class/function vào các thành phần riêng biệt Controller – Model – View, khi đó sẽ dễ dàng xây dựng – phát triển – quản lý – vận hành và bảo trì một

dự án, tạo sự rõ ràng, trong sáng trong quá trình phát triển dự án, kiểm soát được các luồng xử lý và tạo ra các thành phần xử lý nghiệp vụ chuyên biệt hóa;

- Mô hình MVC không phải là một ngôn ngữ, nhưng các đối tượng khác nhau (lập trình viên, nhà quản lý, nhà đầu tư, …) khi cùng nhìn vào thì sẽ tự hiểu nó là gì, khi đó họ có thể trao đổi các yêu cầu và bàn bạc công việc

- Đây là một mô hình chuẩn, nó tối ưu nhất hiện nay so với nhiều mô hình khác

và được sử dụng trong nhiều dự án và nhiều lĩnh vực, đặc biệt trong công nghệ sản xuất ứng dụng – phần mềm Các lập trình viên sử dụng mô hình chuẩn MVC để có thể

dễ dàng phân phối và chuyển giao công nghệ

- Mô hình MVC được chia thành 2 phiên bản là Passive View và Supervising Controller

Hình 2.3 - Mẫu Supervising Controller Trong mẫu Supervising Controller, đầu tiên, phần View sẽ lấy sự kiện từ tương tác người dùng và chuyển giao cho controller xử lý Khi Model thay đổi, để cập nhật được thay đổi này, View dùng data-binding cho các xử lý đơn giản, còn đối với các xử

lý phức tạp, View sẽ nhờ đến Controller lấy dữ liệu từ Model để cập nhật

Hình 2.4 - Mẫu Passive View Trong mẫu Passive View, thành phần View không xử lý cũng như tương tác trực tiếp đến thành phần Model, mà nó chuyển giao các xử lý này cho Controller đảm trách Controller sẽ thay đổi và tương tác lên Model, sau khi Model thay đổi Controller sẽ cập nhật lại thay đổi này cho View Như vậy, Controller trở thành thành phần trung gian liên lạc giữa thành phần View và Model

Passive View và Supervising Controller giống nhau ở việc tách biệt các tác vụ ra khỏi sự phụ thuộc vào tài nguyên và môi trường

Điểm khác nhau giữa Passive View và Supervising Controller đó là quá trình của Supervising Controller thực hiện theo hình tam giác, dữ liệu đến đi từ View đến Controller và từ Controller cập nhật lên Model, khi Model thay đổi sẽ đưa trực tiếp về View để hiển thị Đối với Passive View thì quá tình thực hiện theo chiều dọc, dữ liệu

sẽ đi từ Virew đến Controller, từ Controller đến Model, khi Model thay đổi, dữ liệu sẽ được đưa đến Contrller và đẩy về View Do đó Passive sẽ giúp các thành phần tác vụ tách biệt và chuyên biệt một cách dễ dàng hơn, giúp hệ thống dễ hiểu và hoạt động hiệu quả hơn

2.2.2 ASP.NET MVC

Công nghệ ASP.NET MVC [3] cho phép phân biệt các tác vụ của ứng dụng (logic nhập liệu, business logic, và logic giao diện) do đó dễ dàng kiểm thử Tất cả các tính năng chính của mô hình MVC được cài đặt dựa trên interface và được kiểm thử bằng cách sử dụng các đối tượng mocks (mock object là các đối tượng mô phỏng các

tính năng của những đối tượng thực sự trong ứng dụng) Có thể sử dụng kiểm thử test cho ứng dụng mà không cần chạy controller trong tiến trình ASP.NET MVC, và điều đó giúp unit-test được áp dụng nhanh chóng và tiện dụng

unit-MVC là một nền tảng khả mở rộng (extensible) & khả nhúng (pluggable) Các thành phần của ASP.NET MVC được thiết kể để chúng có thể được thay thế một cách

dễ dàng hoặc dễ dàng tùy chỉnh, do đó có thể nhúng thêm view engine, cơ chế định tuyến cho URL, cách kết xuất tham số của action-method và các thành phần khác ASP.NET MVC cũng hỗ trợ việc sử dụng Dependency Injection (DI) và Inversion of Control (IoC) DI cho phép gắn các đối tượng vào một lớp cho lớp đó sử dụng thay vì buộc lớp đó phải tự mình khởi tạo các đối tượng IoC quy định rằng, nếu một đối tượng yêu cầu một đối tượng khác, đối tượng đầu sẽ lấy đối tượng thứ hai từ một nguồn bên ngoài, ví dụ như từ tập tin cấu hình Và nhờ vậy, việc sử dụng DI và IoC sẽ giúp kiểm thử dễ dàng hơn

ASP.NET MVC có thành phần ánh xạ URL mạnh mẽ cho phép xây dựng những ứng dụng có các địa chỉ URL súc tích và dễ tìm kiếm Các địa chỉ URL không cần phải có phần mở rộng của tên tập tin và được thiết kế để hỗ trợ các mẫu định dạng tên phù hợp với việc tối ưu hóa tìm kiếm (URL) và phù hợp với lập địa chỉ theo kiểu REST

Nền tảng ASP.NET MVC cho phép tạo được các ứng dụng web áp dụng mô hình MVC thay vì tạo ứng dụng theo mẫu ASP.NET Web Form Nền tảng ASP.NET MVC

có đặc điểm nổi bật là nhẹ (lighweigt), dễ kiểm thử phần giao diện (so với ứng dụng Web Forms), tích hợp các tính năng có sẵn của ASP.NET Nền tảng ASP.NET MVC được định nghĩa trong namespace System.Web.Mvc và là một phần của name space System.Web

Tác giả sử dụng công nghệ ASP.NET MVC 4.0 vì phiên bản này bổ sung thêm các ASP.NET Web API giúp hỗ trợ tốt hơn cho các thiết bị di động Đồng thời tác giả

sử dụng thư viện LINQ để thực hiện việc truy xuất dữ liệu

2.2.3 Entity Framework

Entity Framework [1] là một nền tảng được sử dụng để làm việc với CSDL quan

hệ thông qua cơ chế ánh xạ Object Relational Mapping (ORM), qua đó sử dụng LINQ

để truy vấn và cập nhật dữ liệu với sự hỗ trợ của ADO.NET Data Provider

Hình 2.5 - Mô hình Entity Framework Trong hình 2.5, Entity Data Model (EDM) bao gồm ba phần chính: Conceptual model, Mapping và Storage model Conceptual Model (mô hình khái niệm) mô tả các lớp và mối quan hệ tương ứng với cơ sở dữ liệu Storage Model (mô hình lưu trữ) là

mô hình thiết kế cơ sở dữ liệu bao gồm Table, View, Store procedure, Relationship, Key, … Mapping bao gồm thông tin các mô hình khái niệm ánh xạ đến mô hình lưu trữ hay CSDL

LINQ to Entities là ngôn ngữ truy vấn được sử dụng để truy vấn với mô hình đối tượng Object model Giá trị trả về tuỳ thuộc vào Model

Entity SQL là ngôn ngữ truy vấn CSDL giống như LINQ to Entities

Object Service: phục vụ cho việc truy cập, trả giá trị dữ liệu từ cơ sở dữ liệu Object Service cung cấp đầy đủ dịch vụ để quá trình chuyển đổi dữ liệu từ thực thể đến cấu trúc đối tượng dễ dàng hơn

Entity Client Data Provider: giúp chuyển đổi L2E hoặc truy vấn Entity SQL vào truy vấn SQL trong cơ sở dữ liệu Nó sẽ giao tiếp với ADO.NET data provider hoặc lấy dữ liệu từ cơ sở dữ liệu ADO.Net Data Provider: lớp này giao tiếp với cơ sở dữ liệu sử dụng theo chuẩn ADO.NET