ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
ĐÀM BÁ NGỌC
NGHIÊN CỨU PHÁT TRIỂN
CỔNG THÔNG TIN ĐIỆN TỬ CHO DOANH NGHIỆP
LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN
Hà Nội - 2019

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
ĐÀM BÁ NGỌC
NGHIÊN CỨU PHÁT TRIỂN
CỔNG THÔNG TIN ĐIỆN TỬ CHO DOANH NGHIỆP
Ngành: Kỹ thuật phần mềm
Chuyên ngành: Kỹ thuật phần mềm
Mã số: 8480103.01
LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN
NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS. Trương Ninh Thuận
Hà Nội - 2019

1
LỜI CAM ĐOAN
Tôi xin cam đoan rằng nội dung đề tài luận văn “Nghiên cứu phát triển cổng
thông tin điện tử cho doanh nghiệp” là do tôi thực hiện dƣới sự hƣớng dẫn của
PGS.TS. Trƣơng Ninh Thuận. Luận văn là kết quả nghiên cứu của cá nhân tôi và có
sử dụng tài liệu tham khảo, tuy nhiên tất cả tài liệu đều đƣợc trích dẫn đầy đủ rõ
ràng hợp pháp.
Hà Nội, tháng năm
Tác giả luận văn
Đàm Bá Ngọc

2
LỜI CẢM ƠN
Để hoàn thành luận văn này, tôi bày tỏ lòng cảm ơn sâu sắc tới PGS.TS.
Trƣơng Ninh Thuận - Đại học Công Nghệ - Đại học Quốc Gia Hà Nội ngƣời đã
định hƣớng và hƣớng dẫn em trong suốt quá trình thực hiện luận văn tốt nghiệp
này. Thầy không chỉ hƣớng dẫn về kiến thức chuyên môn mà còn động viên chia sẻ
cho tôi rất nhiều kiến thức trong công việc và cuộc sống giúp tôi trƣởng thành và
hoàn thiện mình hơn.
Tôi cũng gửi lời cảm ơn tới TS. Lê Hồng Anh, công tác tại khoa Công nghệ
thông tin - Đại học Mỏ-Địa chất đã tận tình hƣớng dẫn, góp ý, giúp đỡ tôi trong quá
trình nghiên cứu hoàn thiện luận văn. Thầy là ngƣời truyền cảm hứng, dạy tôi
những phƣơng pháp nghiên cứu cũng nhƣ tạo kiện cho tôi tiếp cận với nhiều nguồn
tại liệu hay bổ ích.
Tôi cũng xin cảm ơn trân thành tới thầy cô hội đồng phản biện và các thầy cô
trong khoa Công Nghệ Thông Tin, Trƣờng Đại Học Công Nghệ- Đại Học Quốc
Gia Hà Nội đã góp ý, tận tình giảng dạy kiến thức cho em trong thời gian theo học
cao học tại trƣờng.
Mặc dù đã cố gắng, nhƣng chắc hẳn luận văn của tôi vẫn còn nhiều thiếu sót
cần bổ sung về nội dung, cách trình bày, rất mong nhận đƣợc ý kiến đóng góp,
phản hồi của quý thầy cô.
Tôi xin trân thành cảm ơn.
Hà Nội, tháng năm
Tác giả luận văn
Đàm Bá Ngọc

3
Mục lục
Chƣơng 1 Giới thiệu....................................................................................................................... 8
1.1 Tính cấp thiết của đề tài.................................................................................................... 8
1.2 Nội dung và cấu trúc luận văn ............................................................................................ 10
Chƣơng 2 Các giải pháp tích hợp hệ thống và phƣơng pháp phân tích kiến trúc phần mềm....... 11
2.1 Các mô hình tích hợp hệ thống....................................................................................... 11
2.1 1 Mô hình hƣớng dịch vụ................................................................................................. 11
2.1.2 Mô hình kiểu điểm –tới - điểm...................................................................................... 13
2.1 3 Mô hình kiểu đƣờng ống............................................................................................... 14
2.1.4 Mô hình trục bánh xe và nan hoa.................................................................................. 15
2.2 Các phƣơng pháp hỗ trợ tích hợp hệ thống..................................................................... 15
2.2 1 Phƣơng pháp tích hợp dựa trên dịch vụ web................................................................. 15
2.2.2 Phƣơng pháp công nghệ trục tích hợp........................................................................... 17
2.2.3 Phƣơng pháp chia sẻ dữ liệu ......................................................................................... 18
2.3.4 Phƣơng pháp môi giới đối tƣợng .................................................................................. 18
2.3.5 Phƣơng pháp hƣớng thông điệp .................................................................................... 19
2.3 Phƣơng pháp thiết kế kiến trúc phần mềm ..................................................................... 21
2.3.1 Khái niệm kiến trúc phần mềm ..................................................................................... 21
2.3.2 Xem xét các yếu tố đánh giá kiến trúc phần mềm ........................................................ 21
2.2.3 Quy trình thiết kế kiến trúc phần mềm.......................................................................... 27
Chƣơng 3 Phân tích giải pháp tích hợp hệ thống cho doanh nghiệp............................................ 31
3.1 Tổng quan vấn đề và giải pháp cho doanh nghiệp.......................................................... 31
3.1.1 Quản lý khách................................................................................................................ 33
3.1.2 Quản lý cổng xe............................................................................................................. 37
3.1.3 Quản lý hệ thống bãi đỗ xe ........................................................................................... 38
3.1.4 Quản lý đào tạo ............................................................................................................. 40
3.2 Tích hợp đăng nhập với Active Dricectory .................................................................... 41
3.3 Tích hợp và đồng bộ dữ liệu với hệ thống máy chủ thƣ điện tử..................................... 43
3.4 Cung cấp các dịch vụ web giữa các hệ thống................................................................. 45

4
3.4.1 Phía máy chủ ................................................................................................................. 45
3.4.2 Phía máy khách ............................................................................................................. 48
Chƣơng 4 Thiết kế hệ thống và triển khai .................................................................................... 52
4.1 Mô hình ca sử dụng tổng quát............................................................................................. 52
4.2 Các tác nhân của hệ thống .............................................................................................. 52
4.3 Đặc tả các ca sử dụng...................................................................................................... 53
4.4 Biểu đồ tuần tự ca sử dụng phê duyệt............................................................................. 56
4.5 Biểu đồ tuần tự ca sử dụng đăng ký khách ..................................................................... 57
4.6 Biểu đồ tuần tự hệ thống quẹt thẻ an ninh ...................................................................... 58
4.7 Các hình ảnh triển khai hệ thống .................................................................................... 59
Chƣơng 5 Kết luận và hƣớng phát triển ........................................................................................ 65
Tài liệu tham khảo......................................................................................................................... 66

5
Danh sách bảng chữ cái viết tắt
STT Từ Từ đầy đủ Ý nghĩa
1 ADO.NET Active Data Objects
Đối tƣợng dữ liệu trên nền tảng
Microsoft
2
API
Application
Programming Interface
Giao diện lập trình ứng dụng
3
CMTND
Số chứng minh thƣ nhân
dân
Mã định danh của mỗi ngƣời
4 CNTT Công nghệ thông tin Công nghệ thông tin
5 CTTĐT Cổng thông tin điện tử Cổng thông tin điện tử đƣợc
6
ERP
Enterprise Resource
Planning
Hệ thống hoặc định nguồn lực
doanh nghiệp
7 ESB Enterprise Service Bus công nghệ trục tích hợp
8 JDBC
Java Database
Connectivity Kết nối cơ sở dữ liệu
9 JDO Java Data Objects Đối tƣợng dữ liệu
10
MES
Manufacturing
Execution System
Hệ thống điều hành sản xuất
11 MOM
message oriented
middleware
Phƣơng pháp hƣớng thông điệp
12 ODBC
Open Database
Connectivity Mở kết nối cơ sở dữ liệu
13 ORBs
Object Request Brokers Môi giới đối tƣợng
14
RMI
Remote Method
Invocation
Gọi phƣơng thức từ xa
15 RPC Remote Procedure Calls Gọi phƣơng thức từ xa
16
SOA
Service-Oriented
Architecture
Kiến trúc hƣớng dịch vụ
17 VIP Very Important Person Tầm quan trọng

6
Danh sách hình vẽ
Hình 1.1 Tổng quan chức năng cho doanh nghiệp.......................................................................... 9
Hình 2.1 Mô hình tổng quan của dịch vụ web............................................................................... 12
Hình 2.2 Mô hình điểm-tới-điểm ................................................................................................... 13
Hình 2.3 Mô hình đướng ống ........................................................................................................ 14
Hình 2.4 Mô hình bánh xe – trục lan hoa...................................................................................... 15
Hình 2.5 Mô hình một ứng dụng dịch vụ web ............................................................................... 16
Hình 2.6 Kiến trúc của mô hình ORBs.......................................................................................... 19
Hình 2.7 Mô hình truyền thông điệp ............................................................................................. 20
Hình 2.8. Quá trình mở rộng theo chiều dọc- ngang (Scale out -Scale up).................................. 24
Hình 2..9. Mô tả kiểu tích hợp....................................................................................................... 26
Hình 2.10. Quy trình thiết kế kiến trúc.......................................................................................... 28
Hình 2.11. Đầu vào và đầu ra khi xác định kiến trúc................................................................... 28
Hình 2.12. Đầu vào và đầu ra của quá trình thiết kế kiến trúc..................................................... 29
Hình 3.1. Mô hình tổng quan doanh nghiệp.................................................................................. 31
Hình 3.2 Sơ đồ ví dụ về doanh nghiệp........................................................................................... 32
Hình 3.3 Quy trình ra khỏi công ty của nhân viên-khách ............................................................. 34
Hình 3.4 Cửa an ninh .................................................................................................................... 34
Hình 3.5 Hình ảnh tem, thiết bị lưu trữ......................................................................................... 36
Hình 3.6 Quản lý cổng xe VIP ra vào công ty............................................................................... 38
Hình 3.7 Triển khai quản lý bãi đỗ xe máy nhân viên................................................................... 39
Hình 3.8 Đăng nhập với AD.......................................................................................................... 43
Hình 4.1 Biểu đồ ca sử dụng tổng quát......................................................................................... 52
Hình 4.2 Biểu đồ tuần tự phê duyệt............................................................................................... 56
Hình 4.3 Biểu đồ tuần tự đăng ký.................................................................................................. 57
Hình 4.4 Biểu đồ tuần tự hệ thống quẹt thẻ an ninh...................................................................... 58
Hình 4.5 Phân quyền theo nhóm ................................................................................................... 60
Hình 4.6 Phân quyền theo danh mục............................................................................................. 60
Hình 4.7 Trang chủ của ứng dụng................................................................................................. 60
Hình 4.8 Danh mục đăng ký hỗ trợ an ninh .................................................................................. 61
Hình 4.9 Đăng ký khách ................................................................................................................ 61
Hình 4.10 Trạng thái đăng ký khách............................................................................................. 62
Hình 4.11 Đăng ký bãi đỗ xe......................................................................................................... 62
Hình 4.12 Danh mục đăng ký hỗ trợ đào tạo ................................................................................ 63
Hình 4.13 Tạo và quản lý phiếu khảo sát thông tin....................................................................... 63
Hình 4.14 Tư vấn hỏi đáp.............................................................................................................. 64

7

8
Chương 1 Giới thiệu
1.1 Tính cấp thiết của đề tài
Cùng với sự phát triển của kinh tế Việt Nam trong những năm gần đây chúng
ta đang dần trở thành một phần của chuỗi cung sản xuất toàn cầu. Với vị trí chiến
lƣợc ở khu vực, chính trị ổn định, chi phí nhân công phù hợp, Việt Nam dần trở
thành điểm đón đầu tƣ hàng đầu trong khu vực. Làn sóng dịch chuyển sản xuất từ
Trung Quốc sang các thị trƣờng có chi phí rẻ hơn của các công ty hàng đầu nhƣ
Samsung, Nokia, Microsoft, Foxcom và hàng loạt các công ty sản xuất khác tạo
điều kiện cho việc hình thành mới các khu công nghiệp công nghệ cao, xây dựng
nhiều nhà máy sản xuất toàn cầu. Công nghệ thông tin và cuộc cách mạng công
nghệ 4.0 cũng không nằm ngoài quá trình này. Ứng dụng CNTT trong quản hành
chính, tin học hóa doanh nghiệp, chính phủ kiến tạo, giảm thủ tục, nâng cao năng
xuất đƣợc chính phủ ƣu tiên lên mức hàng đầu. Với mục tiêu trở thành nƣớc mạnh
về công nghệ thông tin trong tƣơng lai Việt Nam hoàn toàn có đủ tiềm lực và nhân
lực phát triển điều này. Việc quản lý thông tin thƣờng đƣợc dùng chủ yếu bằng
giấy, excel và các dịch vụ miễn phí, đặt ra vấn đề thiếu thống nhất, tính riêng tƣ của
doanh nghiệp.
Các tập toàn sản xuất lớn đầu tƣ vào Việt Nam kèm theo những quy định khắt
khe về quản lý, thủ tục, quy trình thống nhất với các công ty con khác trên toàn
cầu. Đó là lý do việc phát triển hệ thống quản lý quản lý cho doanh nghiệp trở nên
cấp thiết. Hệ thống đóng góp vào việc quản lý thống nhất, tập trung nâng cao quản
lý cho doanh nghiệp. Hiện tại, tại nhiều doanh nghiệp việc quản lý các vấn đề liên
quan tới an ninh, khách, quản lý di chuyển tài sản, quản lý đào tạo chủ yếu đƣợc sử
dụng bởi tài liệu excel, sổ sách, giấy tờ. Việc tài sản, bãi xe, cửa an ninh ít đƣợc
chú ý tới. Các doanh nghiệp vừa và lớn, họ đã triển khai nhiều hệ thống ERP và
MES. Hỗ trợ quản lý doanh nghiệp, lập kế hoạch và quản lý sản xuất. Tuy nhiên hệ
thống ERP (Phần mềm hoạch định nguồn lực doanh nghiệp) và MES (Hệ thống
điều hành sản xuất) chủ yếu tập trung vào các nghiệp vụ hàng tồn kho, tài chính, kế
toán, sản xuất, nhân sự, chuỗi cung, bán hàng, lập kế hoạch, mua hàng hàng.
Để giải quyết vấn đề trên em thực hiện làm luận văn này: Phát triển hệ thống
giúp quản lý công ty giải quyết các vấn đề đề cập ở trên. Nội dung: Nghiên cứu
phát triển hệ thống giúp quản lý, tổng hợp thông tin cho doanh nghiệp, giải quyết
các vấn đề của doanh nghiệp nhƣ: quản lý tài sản, quản lý khách vào ra công ty,

9
quản lý đào tạo, quản lý bãi gửi xe, quản lý giao hàng, quản lý cổng xe VIP, quản
lý đăng ký dán tem thiết bị.
Hình 1.1 Tổng quan chức năng cho doanh nghiệp
Về cơ bản hệ thống đáp đa dạng cho cho nhiều doanh nghiệp. Trong phạm vi
luận văn tập trung nghiên cứu dành cho doanh nghiệp vừa và lớn, các công ty thuộc
khối sản xuất, các nhà máy tại các khu công nghiệp. Các công ty tại khu công
nghiệp Thăng Long (Đông Anh, Hà Nội), khu công nghiệp Yên Phong (Yên
Phong, Bắc Ninh) và các khu công nghiệp khác trên cả nƣớc. Các công ty có quy
mô nhân sự lớn, diện tích lớn, có các chi nhánh sản xuất ở nhiều nơi: Quản lý vận
chuyển hàng hóa từ cơ sở này tới cơ sở sản xuất khác,. Quản lý các xe giao, nhận
hàng ở đâu trong công ty, thời gian cho phép trong công ty. Kiểm soát hàng vận
chuyển bên ngoài công ty, định vị, giám sát địa điểm của hàng đối với các công ty
nhà thầu. Các công ty cần tính bảo mật thông tin, các việc nghiên cứu. Công ty cần
vận chuyển hàng hóa nhiều. Quản lý khách ra vào công ty, lịch sử vào ra của khách
tại các khu vực. Lƣu lại lịch sử quẹt thẻ, lịch sử vào ra, ảnh cho từng khách. Quản
lý chấm công, quẹt thẻ tại các khu vực trong công ty, với từng nhân viên thẻ chỉ có
hiệu lực tại vài vị trí phù hợp với nhu cầu thực tế cũng nhƣ đảm bảo an ninh cho
từng khu vực. Quản lý bãi đỗ xe máy, ô tô cho nhân viên.

10
1.2 Nội dung và cấu trúc luận văn
Nội dung của luận văn, tên luận văn: “Nghiên cứu và phát triển cổng thông
tin điện tử cho doanh nghiệp”. Trong luận văn này, khái niệm “cổng thông tin điện
tử” đƣợc hiểu theo nghĩa là một hệ thống tích hợp các hệ thống con khác với chức
năng nghiệp vụ riêng biệt thành một hệ thống tổng thể và gồm các chức năng quản
lý dựa trên yêu cầu của ngƣời dùng. Từ đó giúp ngƣời dùng sử dụng tài nguyên hệ
thống đƣợc hiệu quả hơn, đáp ứng đƣợc nhu cầu sử dụng của doanh nghiệp.
Về cấu trúc luận văn gồm các phần sau. Chƣơng 1 giới thiệu tổng quan luận
văn, trình bày hiện trạng các vấn đề hiện tại, các cách giải quyết hiện tại của doanh
nghiệp từ đó đƣa ra hƣớng giải quyết mới giải quyết đƣợc vấn đề đã đƣa ra.
Chƣơng 2 trình bày về các giải pháp tích hợp hệ thống và phƣơng pháp phân tích
kiến trúc phần mềm. Các mô hình và các công nghệ tích hợp đƣợc trình bày với ƣu
và nhƣợc điểm của các phƣơng pháp.Sau đó nói về kiến trúc và vai trò của nótrong
quá trình phát triển bất kỳ một hệ thống nào cũng nhƣ trong việc phát triển công
thông tin điện tử. Trong phần này cũng tập trung trình bày về các phƣơng pháp tích
hợp hệ thống con vào cổng thông tin điện tử để tạo thành một hệ thống duy nhất.
Chƣơng 3 nói về tích hợp hệ thống với dịch vụ web: trình bày sử dụng dụng dịch
vụ web để tích hợp, trao đổi dữ liệu giữa các hệ thống con. Chƣơng 4 thiết kế hệ
thống và triển khai, thực hiện phân tích yêu cầu, nghiệp vụ của doanh nghiệp và
đƣa ra các giải pháp phát triển các chức năng và tích hợp giữa các hệ thống liên
quan dựa trên các phƣơng pháp đã đề cập ở chƣơng 2 và chƣơng 3. Phần cuối,
Chƣơng 5 đƣa ra kết luận, từ giải pháp đến thực nghiệm thu đƣợc và định hƣớng
nghiên cứu mở rộng cho việc phát triển về sau.

11
Chương 2 Các giải pháp tích hợp hệ thống và phương
pháp phân tích kiến trúc phần mềm
Trong chƣơng này sẽ trình bày nội dung về các giải pháp trong việc tích hợp
hệ thống, ngoài ra trong chƣơng này cũng trình bày phƣơng pháp thiết kế kiến trúc
phần mềm. Cổng thông tin điện tử phát triển dựa trên các cơ sở lý thuyết về kiến
trúc phần mềm và các phƣơng pháp tích hợp hệ thống nhằm đạt chất lƣợng và hiệu
quả cao nhất. Ngày nay, các công nghệ tích hợp hệ thống ngày càng nhiều và đổi
mới, tuy nhiên mỗi công nghệ đều có đặc điểm riêng cùng với ƣu, nhƣợc điểm của
mình. Việc lựa chọn công nghệ nào phù hợp trong từng trƣờng hợp cụ thể cũng là
vấn đề mà luận văn đƣa ra.
2.1 Các mô hình tích hợp hệ thống
2.1 1 Mô hình hướng dịch vụ
Khái niệm
Định nghĩa dịch vụ web (thuật ngữ tiếng anh web service) là giao diện hỗ trợ
truy cập mạng đến các chức năng của ứng dụng, nó đƣợc thiết kế theo các công
nghệ chuẩn của Internet nhƣ HTTP, HTTPS. Khi sử dụng dịch vụ web, nó cung cấp
một giao diện chuẩn, các hệ thống sử dụng nó bắt buộc phải tuân theo các giao diện
này, chúng có thể giao tiếp giữa các nền tảng khác nhau miễn sao đáp ứng yêu cầu
cùng tuân theo nguyên tắc nhất định.
Dịch vụ web đƣợc thiết kế và phát triển để chia sẻ dữ liệu logic và truyền tải
các thông điệp qua các API, nó lắng nghe các yêu cầu tại các cổng và phản hồi
thông điệp tới các máy khách. Do đó nó không hỗ trợ các giao diện đồ họa nhƣ
những mô hình khác. Nó cho phép các hệ thống con có thể giao tiếp với nhau mà
không tốn quá nhiều thời gian, các quá trình giao tiếp đều tuân theo chuẩn dữ liệu
XML hoặc JSON. Đó cũng là một ƣu điểm của dịch vụ web khi mà nó không phụ
thuộc vào bất kỳ ngôn ngữ lập trình hay hệ điều hành nào.
Đặc điểm cơ bản dịch vụ web
Máy chủ dịch vụ web và máy khách có giao tiếp với nhau trong cả những môi
trƣờng khác nhau. Đƣợc phát triển dựa trên tuân thủ giao thức HTTP, định dạng dữ
liệu XML, JSON. Dịch vụ web rất linh động: với UDDI và WSDL thì việc mô tả

12
và phát triển dịch vụ web có thể tự động hóa. Gồm nhiều thành phần nhỏ liên kết
với nhau và đƣợc triển khai trên mạng Intranet và Internet. Dịch vụ web bao gồm
nhiều mô đun và có thể công bố trên mạng Internet. Có thể đƣợc chia sẻ và truyền
tải thông tin qua mạng, có tính bảo mật và riêng tƣ cao, tùy theo mô hình cài đặt
Mô hình dịch vụ web
Hình 2.1 Mô hình tổng quan của dịch vụ web
Nhà cung cấp đăng ký dịch vụ web với UDDI. Ngƣời sử dụng (máy khách)
thực hiện tìm kiếm dịch vụ trên UDDI qua một URL phù hợp. Phía UDDI phản hồi
một bản mô tả WSDL cho nhà cung cấp dịch vụ. Tiếp đó ngƣời sử dụng thực hiện
thao tác gọi dịch vụ bằng một lời gọi thông điệp SOAP tới nhà cung cấp. Sau cùng
nhà cung cấp phản hồi lại kết quả của yêu cầu SOAP cho máy máy khách.
Ưu điểm
Các chƣơng trình đƣợc viết bằng nhiều ngôn ngữ và nền tảng khác nhau,
nhƣng có thể giao tiếp đƣợc với nhau thông qua API. Nó là chuẩn để các hệ thống
cùng tuân thủ, do đó có thể trao đổi thông tin với nhau. Sử dụng đơn giản: vì các
API đƣợc định nghĩa thông qua các URI, các tài nguyên máy chủ đƣợc định danh
và truy cập bởi các URI, do đó dịch vụ web đƣợc đánh giá là đơn giản và hiệu quả
hơn. Giao tiếp với nhau qua bởi các giao thức chuẩn HTTP, TCP/IP, XML và tuân
theo các nguyên tắc của các giao thức này do đó nó kế thừa lại những tính chất của
chúng: bảo mật, an toàn, hiệu quả. Nó giúp giảm chi phí trong quá trình tích hợp
giữa các hệ thống.

13
Nhược điểm
Một trong những nhƣợc điểm là chƣa có cơ chế khôi phục để đảm bảo toàn
vẹn giao dịch trong trƣờng hợp xảy ra ngoại lệ bất thƣờng. Dịch vụ web dựa trên
HTTP nên nó tuân thủ tính phi trạng thái của giao thức này, trong những trƣờng
hợp đòi hỏi tính nhất quán dữ liệu, lập trình viên phải tự xây dựng cơ chế khôi phục
thủ công. Dịch vụ web sẽ giảm hiệu suất tối ƣu khi cùng lúc có nhiều ứng dụng gửi
yêu cầu giao tiếp. Khả năng chịu tải: dịch vụ web sử dụng và trao đổi rất nhiều gói
tin, trƣờng hợp xấu nhất xảy ra là số lƣợng giao dịch tăng lên đột biết sẽ làm quá tải
máy chủ và cơ sở hạ tầng của doanh nghiệp. Do sử dụng máy chủ trung gian để
tăng tính giao tiếp của các hệ thống do đó vấn đề băng thông, tốc độ cần đƣợc chú
ý. Cơ sở hạ tầng và thiết bị phần cứng tốt góp phần nâng cao hiệu năng xử lý của
toàn bộ hệ thống dịch vụ web.
2.1.2 Mô hình kiểu điểm –tới - điểm
Mô hình điểm- điểm, (trong tiếng anh Point –to -point) đƣợc thiết kế sao cho
các máy chủ ứng dụng giao tiếp, trao đổi thông tiếp bởi các giao diện (API). Bởi
vậy đặc điểm của mô hình này là các giao tiếp này là không phụ thuộc vào công
nghệ, chỉ phụ thuộc vào các thông điệp gửi đi và nhận lại, chúng đƣợc thực hiện
trong thời gian đồng bộ hóa hoặc đƣợc xử lý tức thời trong thời gian thực. Mỗi ứng
dụng cung cấp một lƣợng API nhất định, khi số hệ thống con tăng lên đòi hỏi số
giao diện ứng dũng cũng tăng theo. Tuy vậy nhƣợc điểm có nó là chỉ phù hợp với
hệ thống có phạm vi các máy chủ ứng dụng tích hợp với nhau không quá nhiều.
Dƣới đây là hình mô tả mô hình theo kiểu điểm – tới –điểm.
Hình 2.2 Mô hình điểm-tới-điểm

14
2.1 3 Mô hình kiểu đường ống
Mô hình kiểu đƣờng ống (mô hình Pipeline) đƣợc đƣa ra dựa trên ý tƣởng
tích hợp các hệ thống một cách độc lập dựa trên một trục thông điệp (gọi là bus).
Các máy chủ ứng dụng 1 – 6 đƣợc tích hợp trên bus (Hình dƣới), các nút trên bus
có thể giao tiếp trực tiếp với các ứng dụng, còn các máy chủ ứng dụng muốn giao
tiếp với nhau bắt buộc phải thông qua các nút trung gian đƣợc phân bố trên trục
thông điệp. Ví dụ ứng dụng 1 giao tiếp trực tiếp với trục thông điệp qua nút 1. Thế
nhƣng ứng dụng 2 muốn giao tiếp với ứng dụng 4 thì bắt buộc phải giao tiếp thông
qua các nút 2, nút 1, nút 4.
Hình 2.3 Mô hình đướng ống
Các ứng dụng giao tiếp với nhau sử dụng thành phần trung gian trên đƣờng
truyền mạng, chúng phải đƣợc chuẩn hóa theo một chuẩn trƣớc khi tham gia vào
quá trình tích hợp. Nó cũng có phần giống với phƣơng pháp mô hình bánh xe- lan
hoa (hun-and-spoke) sẽ trình bày ở phần dƣới. Tuy vậy, mô hình này có rất nhiều
ƣu điểm nhƣ: sƣ linh hoạt về mặt kiến trúc, giá thành giảm, không gây gánh nặng
tài chính cho doanh nghiệp, sự độc lập của các hệ thống con cho phép ngƣời tích
hợp có thể tích hợp hoặc tách riêng một cách dễ dàng. Trong trƣờng hợp dung
lƣợng trao đổi lớn khả năng xảy ra tắc nghẽn là cao, lúc đó chúng ta cần thiết lập
thêm các kênh truyền độc lập để tăng cƣờng tính ổn định.
Mô hình đƣợc ƣu tiên áp dụng cho các hệ thống hƣớng sự kiện, sử dụng các
kênh phân phát dữ liệu kiểu 1 – nhiều, các kho dữ liệu.

15
2.1.4 Mô hình trục bánh xe và nan hoa
Mô hình hub-and-spoke (bánh xe và trục nan hoa) phần lớn đƣợc áp dụng để
tích hợp trong các ứng dụng cho doanh nghiệp (EAI Enterprice Application
Intergration). Phƣơng pháp này đƣợc ghép nối từ bộ xử lý trung tâm của hệ thống.
Các ứng dụng 1, ứng dụng 2, ứng dụng 3 không thể trực tiếp giao tiếp với nhau mà
tất cả trao đổi thông tin qua một ứng dụng trung gian (middlerware) ở giữa. Dữ liệu
hệ thống đƣợc chia sẻ và truy xuất tại nút trung gian của hệ thống. Ứng dụng trung
gian ngoài tác dụng là điểm đầu mối tích hợp các ứng dụng con, nó còn có khả
năng định tuyến các thông điệp gửi và nhận. Mô hình này thƣờng đƣợc sử dụng cho
các hệ thống có số lƣợng các ứng dụng con nhỏ.
Hình 2.4 Mô hình bánh xe – trục lan hoa
2.2 Các phương pháp hỗ trợ tích hợp hệ thống
2.2 1 Phương pháp tích hợp dựa trên dịch vụ web
Cài đặt dịch vụ web với kiến trúc Restful
Ứng dụng web cung cấp các API để truy cập vào các tài nguyên trong hệ thống.
Phía máy trạm máy khách sử dụng các thƣ viện thực hiện gọi API để trao đổi và
tiếp nhận thông tin. Kiến trúc REST (Representational State Transfer) ngày càng
chiếm ƣu thế bởi tính dễ dùng và gọn nhẹ. Các máy khách giao tiếp với ứng dụng
thông qua giao thức HTTP và thực hiện gọi các giao diện ứng dụng (API) để truy
cập vào các tài nguyên, dữ liệu trên ứng dụng máy chủ.

16
Hình 2.5 Mô hình một ứng dụng dịch vụ web
Phía máy chủ
REST viết tắt của từ REpresentational State Transfer. Là một chuẩn kiến trúc
cung cấp dịch vụ web dựa trên giao thức Http. Kiến trúc REST đƣợc cung cấp với
tính đơn giản để truy cập và sửa đổi tài nguyên của máy chủ máy chủ. Trong đó
mỗi tài nguyên máy chủ đƣợc định danh bởi một URIs hoặc một Ids toàn cầu.
REST đƣợc sử dụng phổ biến vì tính đơn giản và cung cấp nhiều định dạng dữ
liệu phổ biến nhƣ text, JSON, XML. Điểm mạnh của REST đƣợc biết đến là phát
triển dựa trên HTTP, là nền tảng hạ tầng phổ biến và sẵn có nhất. Do đó dễ đƣợc
tiếp nhận và sử dụng bởi các kiến trúc sƣ phần mềm. Thêm vào đó HTTP là giao
thức mở và đƣợc khai triển trên rất nhiều loại hệ thống, hiện nay mọi tổ chức công
ty đều đồng ý cho phép trao đổi thông tin dựa trên giao thức HTTP.
Ngày nay, Spring MVC đƣợc sử dụng phổ biến để phát triển và cung cấp dịch
vụ web, nó đƣợc cung cấp để phát triển dịch vụ web theo kiến trúc RESTful. Máy
chủ dịch vụ cung cấp các giao diện dƣới dạng URI và trả về dữ liệu chủ yếu dƣới
dạng JSON, từ đó máy khách thực hiện xử lý nghiệp vụ theo mẫu dữ liệu trả về.
Phía máy khách
Một REST API trả về định dạng kiểu JSON đƣợc sử dụng phổ biến với ƣu điểm
nhẹ và dễ sử dụng. Các hệ thống con tích hợp trong hệ thống đều sử dụng chuẩn dữ
liệu JSON để trao đổi dữ liệu. Dƣới đây là cách thức gọi và thực thi các dịch vụ
phía máy khách. Máy khách thực hiện gọi một yêu cầu dƣới dạng HTTP Post, yêu
cầu cho biết nhiệt độ của thành phố Paris là bao nhiêu độ C, máy chủ lắng nghe và
phản hồi thông tin nhiệt độ thấp nhất là 16 độ C, nhiệt độ cao nhất là 23 độ C.

17
Hình 2.6 Gọi API từ máy khách
Trong hệ thống các hệ thống con sử dụng gọi API tới máy chủ để lấy và xử lý
thông tin bao gồm các hệ thống: Hệ thống cổng xe chính, hệ thống bãi đỗ xe, hệ
thống quẹt thẻ cửa an ninh, hệ thống đăng ký dán tem thiết bị. Tại hệ thống quản lý
cổng xe chính, hệ thống bãi xe, hệ thống cửa an ninh gọi dịch vụ cung cấp từ hệ
thống. Sử dụng giao thức HTTP để gửi các yêu cầu và nhận đƣợc kết quả phản hồi.
2.2.2 Phương pháp công nghệ trục tích hợp
Phƣơng pháp trục tích hợp (Enterprise Service Bus- ESB) là một giải pháp
cho ở hạ tầng phần mềm dựa trên cơ chế hoạt động nhƣ là một lớp trung gian xử lý
vấn đề yêu cầu mở rộng hệ thống sau khi triển khai mà mô hình dịch vụ web không
làm đƣợc, hoặc xử lý chƣa tốt. Cụ thể là khi tích hợp giữa các dịch vụ web với các
ứng dụng trung gian khác, cũng nhƣ giải quyết các vấn đề về an ninh, quản lý,
kiểm soát các dịch vụ truyền thông. ESB cung cấp giải pháp cho các vấn đề trên,
nó cũng hỗ trợ tăng khả năng linh hoạt trong giao tiếp giữa các máy chủ cung cấp
dịch vụ, hỗ trợ đơn giản hóa về sau khi muốn tái sử dụng các dịch vụ sẵn có. ESB
cũng đảm bảo cơ sở hạ tầng truyền thông đáng tin cậy, thực sự mạnh mẽ và an
toàn, khả năng mở rộng tốt. Vấn đề kiểm soát giao tiếp và lƣu vết sử dụng dịch vụ.
Một tính năng khác nữa là cung cấp tính năng điều hƣớng và định tuyến các thông
điệp tới các máy chủ dịch vụ khác căn cứ vào nguồn gốc, nội dung hoặc các đặc
điểm khác và khả năng chuyển đổi để đóng gói, mở gói khi thông điệp trong quá
trình gửi và nhận thông điệp.
Phƣơng pháp ESB hỗ trợ khả năng quản lý quá trình triển khai, bảo trì, sử
dụng dịch vụ, bên cạnh đó nó còn đảm bài toán cân bằng tải, tối ƣu hóa, giảm thiểu
chi phí, quản lý trực tuyến, triển khai phân tán. Thêm vào đó nó còn đảm bảo các
tiêu chuẩn về bảo mật, tính tin cậy khi trao đổi thông tin.

18
2.2.3 Phương pháp chia sẻ dữ liệu
Phƣơng pháp này hỗ trợ tối đa việc truy xuất vào cơ sở dữ liệu qua một lớp
trừu tƣợng sẵn có, nó tạo điều kiện cho việc thay đổi hệ quản trị cơ sở dữ liệu mà
không phải thay đổi và xây dựng lại mã nguồn của ứng dụng. Bởi vậy, phƣơng
pháp này cực kỳ hiệu quả để truy cập vào dữ liệu từ các hệ quản trị khác nhau.
Thực tế sử dụng phổ biến nhất các công nghệ sau: đứng đầu là công nghệ Java
Database Connectivity (JDBC) và Java Data Objects (JDO) trên nền tảng Java, còn
trong nền tảng .Net của Microsoft là các công nghệ Open Database Connectivity
(ODBC) và Active Data Objects (ADO.NET).
2.3.4 Phương pháp môi giới đối tượng
ORBs (Object Request Brockers) là một trong những phƣơng pháp phân tách
tính rõ ràng về trị trí, hệ điều hành, giao thức và ngôn ngữ lập trình, nó nâng cao
việc quản lý và trao đổi thông điệp giữa các hệ thống phân tán hoặc các ứng dụng
con có các thành phần khác nhau mà không cần quan tâm tới nội dung của quá
trình truyền thông điệp.
Phƣơng thức đƣợc dùng để giao tiếp giữa các đối tƣợng là qua các giao diện
(interfaces), nó là ƣu điểm của phƣơng pháp này, nó giúp nâng cao việc bảo trì và
che dấu thông tin đảm bảo an ninh của hệ thống.
ORB là công nghệ khá phức tạp, nó hầu hết kết nối với các dịch vụ cung cấp
khả năng định vị các thành phần trong kết nối mạng. Ví dụ nhƣ nó cung cấp một trị
trí không có thật sau đó mô hình hóa xung quanh nó cùng với các thành phần địa
phƣơng, tuy nhiên thực tế các thành phần con này có thể đặt ở đâu đó trong mạng.
Ƣu điểm của nguyên tắc này là tăng tính đơn giản khi pháp triển hệ thống nhƣng đó
cũng là nhƣợc điểm của nó, điều đó gây ảnh hƣởng tới hiệu năng chung của kiến
trúc.

19
Hình 2.6 Kiến trúc của mô hình ORBs
Những hệ thống thiết kế tuân thủ ORB có tính linh hoạt cao, chúng khả năng
di chuyển một vài các hàm về phía máy khách và thực hiện các chức năng từ phần
của máy chủ. Bên cạnh đó nó có thể cung cấp thêm những chức năng này một tiến
trình riêng biệt, có trƣờng hợp còn có thể tích hợp sâu vào tận lõi nhân của hệ điều
hành. Theo quy chuẩn hiện tại tồn tại ba chuẩn sau: tƣơng thích với CORBA ORB,
Java RMI và RMI-IIOP, và cuối cùng là Microsoft COM / DCOM và COM/.NET
và Remoting/WCF. Hiện nay có rất nhiều sản phẩm ORB hoạt động tốt đáp ứng
yêu cầu kỹ thuật của CORBA, hơn nữa nó cònkế thừa các tính năng của RMI.
Trong đó chú ý tới RMI-IIOP là khá quan trọng bởi lý do nó có sử dụng đến giao
thức trao đổi qua lại giữa những thành phần khác của CORBA chính là IIOP
(Internet Inter-ORB Protocol). Đó là lý do kiến RMI-IIOP trở lên hoạt động tốt với
CORBA.
2.3.5 Phương pháp hướng thông điệp
Phƣơng thức hƣớng thông điệp (từ gốc tiếng anh là message oriented
middleware - MOM) nguyên tắc hoạt động dựa trên việc trao đổi thông điệp một
cách không đồng bộ, ví dụ nhƣ máy khách có thể tiếp tục gửi yêu cầu tới máy chủ
ứng dụng mà không cần đợi trả lời của máy chủ. Ở đó, các phƣơng thức không trực
tiếp giao tiếp với nhau mà chúng làm việc với nhau thông qua một hàng đợi gián
tiếp.
Hàng đợi gián tiếp là một tập các gói tin đƣợc chia sẻ giữa nhiều đối tƣợng
máy chủ/khách, các đoạn mã nguồn xử lý công việc trên đƣợc gọi là chƣơng trình

20
trung gian hƣớng thông điệp (MOM Message-oriented middleware). Nguyên lý
hoạt động của nó đƣợc gửi và nhận yêu cầu dƣới dạng hàng chờ (queue). Mỗi
thông điệp đều phải có địa chỉ nhận và địa chỉ gửi, trong trƣờng hợp thông điệp
chƣa đƣợc gửi tới đúng địa chỉ thì nó có cơ chế để gửi lại sớm nhất có thể
Hình 2.7 Mô hình truyền thông điệp
Cấu tạo của MOM thành phần gồm có hàng đợi/kênh đƣợc sử dụng để
truyền tải thông điệp. Có hai loại hàng đợi, hàng đợi điểm-tới-điểm để đại diện cho
các điểm nhận và gửi thông điệp, hàng đợi đẩy – theo dõi (push and subcribe) hoạt
động theo có chế lan tỏa thông tin, thông điệp đƣợc gửi cho tất cả các máy theo dõi
mà tại đó mỗi thông điệp đƣợc lƣu nhƣ một bản sao và ngƣời gửi không cần biết
máy khách nào đang đợi nhận thông điệp.
Cấu tạo mỗi thông điệp (message) bao gồm phần đầu (header) bao gồm các
thông tin định hƣớng địa chỉ đích, địa chỉ gửi .. và phần thân gói tin (body) chứa
chi tiết nội dung của thông điệp. Các điểm kết nối end point cung cấp phƣơng thức
cho phép các máy chủ/ máy khác giao tiếp với MOM để nhận thông điệp hoặc gửi
đi một thông điệp. Về cơ bản phƣơng pháp này giúp việc nâng cao khả năng mở
rộng của hệ thống tích hợp, nó giải quyết đƣợc vấn đề quan trọng đó là độ tin cậy,
truyền tải chính xác trong quá trình truyền dữ liệu. Tuy vậy nhƣợc điểm của nó là
nếu dùng nhiều MOM cùng một thời điểm sẽ gây ra vấn đề không đồng nhất trong
giao thức HTTP hoặc HTTPS.

21
2.3 Phương pháp thiết kế kiến trúc phần mềm
2.3.1 Khái niệm kiến trúc phần mềm
Trong quá trình phát triển phần mềm, kiến trúc phần mềm cực kỳ quan trọng,
trong những năm gần đây xuất hiện sự phát triển của một phân ngành trong kỹ
thuật phần mềm, đó là kiến trúc phần mềm. Trong công nghiệp phần mềm Kiến
trúc sƣ công nghệ, kiến trúc sƣ trƣờng là một trong những công việc quan trọng.
Qua thời gian việc gia tăng độ phức tạp của phần mềm dẫn đến việc nghiên cứu,
phát triển cơ sở kiến trúc và công nghệ cho các hệ thống lấy đó làm cơ sở thiết kế.
Kiến trúc phần mềm cho thấy nhiều mặt cấu trúc và hành vi hệ thống, sau đây là
một ví dụ về định nghĩa kiến trúc phần mềm: “Kiến trúc phần mềm của của hệ
thống máy tính hay chƣơng trình chính là cấu trúc của hệ thống, bao gồm các
thành phần phần mềm, các thuộc tính, đặc tính có thể nhìn thấy bên ngoài của các
yếu tố đó các yếu tố, và các mối quan hệ giữa chúng” [1]
Từ định nghĩa trên ta thấy, kiến trúc đã tạo ra các thiết kế các thành phần của hệ
thống có thể đƣợc coi là các bộ phận cơ bản của kiến trúc/các khối xây dựng nên
kiến trúc. Các cấu tạo chi tiết bên trong của một thiết kế và thực thi thiết kế phần
mềm thƣờng không liên quan đến các thành phần còn lại của hệ thống, ta coi một
phần mềm nhƣ một hộp đen. Hộp đen sẽ có những thuộc tính nhất định mà nó thể
hiện, các thành của phần phần mềm còn lại cũng có thể đƣợc sử dụng để thực hiện
cho các đích nghiệp vụ hoặc công nghệ thông tin. Kiến trúc phần mềm chỉ ra các
khối kiến trúc cơ bản và với độ chi tiết thích hợp. Nó cũng chỉ ra việc viết tƣ liệu
việc các bộ phận cơ bản liên quan lẫn nhau nhƣ thế nào.
Kiến trúc phần mềm là công việc phân tích hoặc phân vùng một hệ thống đơn
độc thành một tập các thành phần mà có thể đƣợc phát triển theo kiểu lặp lại, gia
tăng, độc lập. Các thành phần riêng lẻ có khả năng kết nối với nhau thành một thể
thống nhất tạo nên kiến trúc của hệ thống, tổ chức, hoặc ứng dụng. Kiến trúc bắt
buộc ứng dụng bằng cách sử dụng các thành phần kiến trúc đơn giản mà đáp ứng
đƣợc các mục tiêu nghiệp vụ và chất lƣợng. Những thành viên trong tổ chức phải
có khả năng đọc và hiểu đƣợc nội dung kiến trúc. Do vậy điều quan trọng là một
bản kiến trúc phải đƣợc viết tài liệu cẩn thận, chính xác
2.3.2 Xem xét các yếu tố đánh giá kiến trúc phần mềm
Các chuyên gia thiết kế phần mềm dành phần lớn công việc của mình để thiết kế
các hệ thống đảm bảo yêu cầu của ngƣời sử dụng, đáp ứng trong hệ thống. Ngoài ra

22
họ còn tập trung đến những yếu tố khác dƣới góc độ của nhà phát triển. Đó là các
vấn đề chất lƣợng của bản thiết kế, nó đƣợc biết đến nhƣ các yêu cầu phi chức năng
của hệ thống. Dƣới đây đề cập tới các tiêu chí mà các nhà thiết kế luôn hƣớng tới
để đảm bảo một thiết kế đƣợc coi là tốt, đảm bảo yêu cầu:
Vấn đề hiệu năng
Vấn đề hiệu năng cho thấy một đơn vị xác định các công việc một ứng dụng cần
phải làm trong khoảng thời gian nhất định. Bình thƣờng các hệ thống phải có khả
năng xử lí hàng nghìn, đặc biết với hệ thống phức tạp xử lý vạn giao dịch
(transactions) trên mỗi giây, các yêu cầu này thƣờng xảy ra trong các hệ thống ứng
dụng lớn của các tổ chức doanh nghiệp lớn, chủ yếu trong các công ty tài chính,
viễn thông và cơ quan quản lý nhà nƣớc.
Yêu cầu về khả năng xử lý
Throughput là việc đo lƣờng lƣợng khối lƣợng công việc mà một ứng dụng phải
xử lý và thực hiện trong một đơn vị thời gian. Thông thƣờng, nó đƣợc tính bằng
tổng số giao dịch mỗi giây (pts) hoặc tổng số thông điệp đƣợc xử lí mỗi giây (mps).
Trong thực tế, một ứng dụng trực tuyến của ngân hàng A (tên ngân hàng) cần phải
đảm bảo có thể thực hiện đƣợc tối thiểu một nghìn giao dịch trực tuyến mỗi giây
(1000pts), một hệ thống quản lí bán hàng B (tên nhà hàng) phải xử lý năm mƣơi
yêu cầu cầu mua hàng của khách hàng mỗi giây (50mps).
Yêu cầu về thời gian phản hồi
Là thời gian đáp ứng của một yêu cầu, nó chỉ ra độ trễ về thời gian khi hệ thống
xử lý thành công một giao dịch. Thời gian phản hồi thƣờng đƣợc gắn liền với thời
gian hệ thống sử dụng để phản hồi lại một yêu cầu nào đó. Khoảng thời gian này
càng ngắn chứng tỏ hiệu quả làm việc của hệ thống càng cao. Trong thực tế, hệ
thống quản lý bán hàng đƣợc áp dụng phổ biến ở các cửa hàng ngày nay, nhân viên
bán hàng thực hiện quét mã tra thông tin của sản phẩm tại quầy thanh toán, hệ
thống xử lý và hiển thị giá kèm thông tin của sản phẩm. Thời gian đáp ứng càng
ngắn thì chứng tỏ hệ thống đƣợc thiết kế tốt và giúp cho nhân viên phục vụ khách
hàng đƣợc tốt hơn. Đó cũng là mong muốn của cả cửa hàng và bản thân ngƣời thiết
kế phần mềm.
Yêu cầu về thời hạn hoàn thành

23
Các ứng dụng yêu cầu nghiêm ngặt về thời gian hoàn thành một yêu cầu ngƣời
dùng thƣờng là các ứng dụng phục vụ các công việc liên quan tới phân phối sản
phẩm hàng hóa, thƣ tín, thực hiện các giao dịch tài chính. Hệ thống ngân hàng, thƣ
tín, tài chính thƣờng có những yêu cầu nghiêm về khoảng thời gian hoàn thành yêu
cầu xử lý của ngƣời dùng. Hệ thống thanh toán trực tuyến nhƣ Samsung Pay, ví
điện tử Momo là một ví dụ. Khách hàng gửi tiền vào ví điện tử, thực hiện giao dịch
thanh toán tiêu dùng thƣờng phải hoàn thành trong một thời gian nhất định. Nó ảnh
hƣởng trực tiếp đến trải nghiệm ngƣời dùng và ảnh hƣởng trực tiếp đến doanh
nghiệp. Nếu thời gian xử lý quá lâu khách hàng sẽ chuyển sang một hệ thống khác.
Yêu cầu khả năng mở rộng hệ thống
Nói đơn giản, nhu cầu của khách hàng ngày càng tăng thêm theo thời gian, do
đó thiết kế kiến trúc tạo điều kiện cho mở rộng về sau là cực kỳ quan trọng. Nếu
thiết kế không tốt, chúng ta bắt buộc phải thiết kế lại hệ thống gây lãng phí về cả
thời gian và tiền bạc. Các phía cạnh sau sẽ thể hiện điều này:
Yêu cầu chịu tải
Trong thực tế, một hệ thống máy chủ đƣợc thiết kế cho phép cung cấp 100 giao
dịch trên 1 giây (100pts) với một kiến trúc nhất định, nhƣng trong trƣờng hợp khi
hệ thống cần phát triển để nó có thể xử lí số lƣợng yêu cầu giao dịch tăng gấp 10
lần hay 100 lần thì kiến trúc này có thể xử lý đƣợc không. Cùng xem xét hai giải
pháp cho vấn đề này, nó đƣợc dùng để nâng cao khả năng xử lý của ứng dụng khi
yêu cầu tải tăng lên nhiều lần: hệ thống đƣợc thiết kế sao cho xử lý đa luồng, đơn
luồng trên cùng máy trạm (scale up works), tuy nhiên yêu cầu về phần cứng sẽ tăng
lên (bộ nhớ, tài nguyên) làm cho tốc độ xử lý tăng lên đáp ứng đƣợc yêu cầu thiết
kế. Cấu hình tải đồng đều tại các máy trạm (scale out works): giúp các máy trạm
làm việc hiệu quả nhƣ nhau nhƣng sẽ xảy ra trong trƣờng hợp có máy trạm làm
việc quá tải trong khi những máy khác lại hoạt động chƣa hết công suất. Điều này
dẫn đến lãng phí tài nguyên phần cứng.
Hình dƣới đây mô tả quá trình mở rộng theo chiều dọc và chiều ngang (scale up
-scale out) [2]

24
Hình 2.8. Quá trình mở rộng theo chiều dọc- ngang (Scale out -Scale up)
Yêu cầu đáp ứng dữ liệu lớn
Kiến trúc tốt đi liền với khả năng mở rộng thiết kế về sau cũng nhƣ yêu cầu về
việc xử lý hệ thống khi dữ liệu ngày càng tăng lên. Một ví dụ của hệ thống gửi tin
nhắn, bình thƣờng hệ thống đƣợc thiết kế để gửi và nhận tin nhắn của ngƣời dùng
với giới hạn số lƣợng ký tự nhất định. Tuy vậy, có khách hàng gửi đi tin nhắn vƣợt
quá giới hạn tin nhắn cho phép thì hệ thống sẽ xử lý nhƣ thế nào ? Trong trƣờng
hợp này hệ thống sẽ chia tin nhắn ra làm nhiều tin nhắn nhỏ và gửi đi. Đó là cách
giải quyết tốt và đơn giản. Tuy nhiên với trƣờng hợp chúng ta không đƣợc chia tin
nhắn thành nhiều tin nhắn nhỏ ? những file có dung lƣợng lớn cần gửi đi thì kiến
trúc hệ thống thiết kế khi đó có cho phép xử lý hay không.
Yêu cầu xử lý lượng lớn kết nối đồng thời
Một tiêu chí quan trọng khác để một kiến trúc là khả năng đáp ứng số lƣợng lớn
yêu cầu cùng lúc. Ban đầu nó đƣợc thiết kế để xử lý hàng nghìn lƣợt yêu cầu trong
cùng thời điểm, hệ thống xử lý rất tốt. Nhƣng khi số lƣợng truy cập bất ngờ thăng
lên hàng trăm nghìn (điều này nằm ngoài khả năng tƣởng tƣợng cầu của khách
hàng lúc yêu cầu), thậm trí hàng triệu yêu cầu thì làm sao để giải quyết nó trong
thời gian sớm nhất. Kiến trúc đã thiết kế có cho phép làm điều này hay không ?
Nếu thiết kế không tốt có thể ta phải thiết kế lại hệ thống gây lãng phí thời gian và
công sức. Để ví dụ cho trƣờng hợp này, ta có thể lấy ví dụ hệ thống mua vé bóng đá
trực tuyến. Hệ thống đƣợc thiết kế nhƣng không chịu đƣợc hàng trăm nghìn yêu
cầu gửi đến cùng một thời điểm, máy chủ luôn ở trong tình trạng quá tải. Tuy vậy

25
do thiết kế chƣa thực sự tốt, họ cũng không thể xử lý thay đổi để nâng cấp cho hệ
thống có thể chịu đƣợc.
Triển khai, cài đặt ứng dụng
Yếu tố đánh giá ở đâu là kiểm tra xem hệ thống có thể đƣợc triển khai hiệu quả
(dù không cần phải thay đổi mã nguồn) khi số lƣợng tài khoản sử dụng tăng lên (số
lƣợng ngƣời dùng). Khi đó hệ thống có thể cài đặt dễ dàng trên nhiều thiết bị khác
nhau, kể cả việc cấu hình, hoặc các thay đổi nhƣ cập nhật các phiên bản mới. Giải
pháp đƣa ra cho vấn đề này là thiết lập tự động cài và cập nhật cho ngƣời sử dụng
dựa trên những thông tin cấu hình của họ. Ý tƣởng này đƣợc áp dụng phổ biến rộng
rãi cho các ứng dụng triển khai trên mạng trực tuyến.
Khả năng sửa đổi
Yêu cầu sửa đổi phần mềm là điểm tất yếu của phần mềm vì yêu cầu nghiệp vụ
của ngƣời dùng cũng thay đổi theo thực tế công việc. Nó là một trong những đặc
điểm đánh giá phần mềm có đƣợc thiết kế tốt để dễ dàng sửa đổi đƣợc không trong
trƣờng hợp các yêu cầu phi chức năng và yêu cầu chức năng thay đổi.
Tính bảo mật
Yếu tốt bảo mật liên quan tới nhiều khía cạnh phức tạp của hệ thống, kiến trúc
phần mềm chỉ là một trong những những khía cạnh của nó. Ta xét các đặc điểm chủ
yếu sau đây: Cơ chế xác thực: ứng dụng cần xác định xem thực thể mà nó đang làm
việc có hợp lệ hay không, thƣờng các ứng dụng làm điều này bằng cơ chế đăng
nhập. Các phiên của quá trình làm việc đƣợc lƣu trong phiên của hệ thống. Cơ chế
phân quyền: những tác nhân đƣợc xác định khi giao tiếp với hệ thống, tuy nhiên
các tác nhân này có thể làm những gì trên hệ thống, truy cập tài nguyên nào, quyền
hạn (đọc, ghi) đến đâu thì đó lại là hành động phần quyền của ứng dụng. Yêu cầu
về mã hóa: các thông tin nhạy cảm của hệ thống phải đƣợc mã hóa khi lƣu trữ
(thông tin mật khẩu, thậm chỉ là tên đăng nhập), mã hóa trong quá trình gửi và
nhận giữa các hệ thống, giữa hệ thống và con ngƣời ( ngày nay phần lớn các hệ
thống điều đƣợc thiết lập mã hóa tầng giao vận). Yêu cầu toàn vẹn: các thông tin
gửi đi không bị sửa đổi ở phía biên nhận. Tính không thoái thác: Một yếu tố thể
hiện rằng ngƣời nhận và ngƣời gửi không thể thoái thác trách nhiệm với gói tin đã

26
trao đổi trên hệ thống. Gói tin đƣợc xác định bởi ngƣời gửi và đích đến (ngƣời
nhận). Yêu cầu này đƣợc thể hiện cụ thể trong bài toán chữ ký số điện tử.
Yêu cầu khả năng sẵn sàng
Khả năng làm việc liên tục không bị ngắt quãng thể hiện độ tin cậy của hệ
thống. Vì lý do nào đó hệ thống không hoạt động khi ngƣời dùng yêu cầu thì nó
chƣa đáp ứng đƣợc tính sẵn sàng của hệ thống. Trong thực tế yêu cầu này đƣợc thể
hiện bởi khả năng sử dụng 24/24 h của hệ thống.
Khả năng tích hợp
Các ứng dụng phải đƣợc thiết kế kiến trúc sao cho dễ dàng tích hợp lại với nhau vì
trong nhiều trƣờng hợp hệ thống có xu hƣớng hoạt động rộng hơn. Nó không chỉ có
giá trị về mặt kỹ thuật, nó cũng làm hệ thống có giá trị cao hơn khi có thể tích hợp
và có thể hoạt động tốt với các hệ thống bên ngoài nó. Một giải pháp đơn giản là
cung cấp API trực tiếp để các hệ thống khác truy cập vào. Tuy nhiên theo kinh
nghiệm ngƣời ta thƣờng sử dụng mô hình dƣới đây để phát triển các API:
Hình 2..9. Mô tả kiểu tích hợp
Giải pháp duy nhất trong trƣờng hợp này là hỗ trợ giao tiếp truy cập tài nguyên
hệ thống thông qua các giao diện lập trình ứng dụng (API). Các API đƣợc cung cấp
bởi các dịch vụ web. Việc tích hợp hệ thống cần phải thực hiện một cách linh hoạt
và đơn giản, các ứng dụng đƣợc viết bằng nhiều ngôn ngữ khác nhau, truy cập các
hệ quản trị dữ liệu khác nhau. Nên việc thiết kế các API chi tiết và đầy đủ sẽ tạo
nền tảng cho việc kiểm soát hệ thống tốt hơn, nâng cao hiệu quả, an toàn khi các hệ
thống giao tiếp với nhau. Ngoài ra ngƣời ta còn xem xét đến các yếu tố khác nhƣ

27
tính dễ cài đặt trên các nền tảng phần mềm, phần cứng, tính dễ dùng dễ hỗ trợ khi
vận hành thực tế, tính dễ dàng trong quá trình kiểm thử.
2.2.3 Quy trình thiết kế kiến trúc phần mềm
Giai đoạn phác thảo quy trình thiết kế
Kiến trúc sƣ phần mềm ngoài việc đƣa ra thiết kế kỹ thuật họ còn cần phải tham
gia các công việc khác để bổ hoàn thiện cho bản thiết kế đƣợc hoạt động tốt nhất.
Đấy là các công việc một kiến trúc sƣ phần mềm phải làm:
Hợp tác với nhóm phân tích yêu cầu, nhóm phân tích khảo sát yêu cầu ngƣời
dùng lấy thông tin từ khách hàng và tổng hợp lại thành tài liệu yêu cầu đặc tả, từ đó
mô tả chi tiết hệ thống cần những gì từ đó đƣa ra thiết kế cao nhất đảm bảo yêu cầu
đề ra. Cái khó của kiến trúc sƣ phần mềm là tầm nhìn đảm bảo cho hệ thống đáp
ứng tốt cho tƣơng lai nhƣng lại phải cần đáp ứng đƣợc phạm vi tài chính và thời
gian hoàn thành của khách hàng. Kết quả thu đƣợc là bản thiết kế phù hợp nhất với
khách hàng. Trao đổi với các bên liên quan, đảm bảo bản thiết kế đƣợc hiểu đúng,
hiểu đủ yêu cầu khách hàng và đảm bảo nó đã tồn tại trong thiết kế. Những gì kiến
trúc sƣ nghĩ là đúng và cần thiết có khi lại không phải những gì khách hàng mong
muốn. Quản lý đội thiết kế: việc xác định kiến trúc cũng là một phần trong quá
trình thiết kế. Kiến trúc sƣ phần mềm cần lãnh đạo đội ngũ nhỏ hơn trong nhóm,
những dự án lớn đòi hỏi sự tham gia của nhiều kỹ sƣ chƣa có nhiều kinh nghiệm.
Sản phẩm cuối cùng là bản thiết kế chi tiết (tạm dịch là architecture blueprint), nó
đƣợc dùng để thực thi kiến trúc khi triển khai. Trao đổi với đội quản trị dự án, họ
cần phải làm việc với PM (ngƣời quản lý dự án) để hỗ trợ đƣa ra kế hoạch, các
khối lƣợng công việc cần thực hiện và kế hoạch triển khai thực tế của dự án. Dựa
vào kinh nghiệm của thiết kế, thiết kế kiến trúc chia làm ba bƣớc sau: xác định yêu
cầu kiến trúc, thiết kế kiến trúc và thẩm định kiến trúc.

28
Hình 2.10. Quy trình thiết kế kiến trúc
Tìm hiểu yêu cầu của kiến trúc: tạo ra một bản vẽ yêu cầu tầm cao, dựa trên yêu
cầu của hệ thống. Nó là tiền đề, định hƣớng cho bản thảo kiến trúc. Thiết kế kiến
trúc: thực hiện việc làm rõ các thành phần có trong bản thiết kế, vai trò cũng nhƣ
mối liên hệ giữa các thành phần nhỏ. Quá trình đƣợc thực hiện từ bản thảo thiết kế
đến bản thiết kế chi tiết. Thẩm định: đảm bảo kiến trúc đƣa ra là đáp ứng yêu cầu
hệ thống, các yêu cầu chức năng, phi chức năng
Giai đoạn xác định yêu cầu kiến trúc
Để áp dụng một bản kiến trúc thiết kế, ta phải thực hiện đánh giá chi tiết các yêu
cầu kiến trúc mà hệ thống đòi hỏi. Từ hình dƣới đây ta thấy tồn tại hai yêu cầu
quan trọng đó là yêu cầu về chức năng hệ thống và yêu cầu từ các ngƣời liên quan
tới hệ thống [2]:
Hình 2.11. Đầu vào và đầu ra khi xác định kiến trúc
Hai yếu tố này ảnh hƣởng tới việc xác định yêu cầu kiến trúc. Trong thời gian
tìm hiểu yêu cầu kiến trúc sẽ thu đƣợc một danh sách các yêu cầu cụ thể về kiến
trúc của hệ thống. Tuy vậy, những yêu cầu này vẫn ở dạng thô, chƣa đƣợc chƣa
đƣợc đặc tả chi tiết trong tài liệu ở mức này. Do đó các kỹ sƣ kiến trúc phải làm
việc trực tiếp với các stackeholder (ngƣời yêu cầu liên quan tới hệ thống). Điều đó
dẫn đến mỗi kiến trúc sƣ phần mềm đều có kinh nghiệm thiết kế trong một số lĩnh
vực nhất định, thật khó khăn để triển khai một dự án mà chƣa từng làm việc với
nghiệp vụ ở lĩnh vực này.Các bản yêu cầu kiến trúc đƣợc chia làm các mức độ ƣu
tiên khác nhau. Nhiều trƣờng hợp các yêu cầu chỉ dừng lại ở mức độ ƣu tiên thấp

29
hoặc ít quan trọng. Dựa trên mức độ ƣu tiên, ta phân loại chúng thành ba mức sau
đây: mức độ cao: hệ thống đƣợc thiết kế phải hỗ trợ các yêu cầu này, đó là những
yêu cầu quan trọng bậc nhất của hệ thống. Kiến trúc sƣ không thể bỏ qua yêu cầu
này. Mức độ trung bình: những yêu cầu cần thiết ở một trạng thái nào đó của hệ
thống nhƣng tùy từng thời điểm nó có ảnh hƣởng tới hệ thống. Mức độ thấp: chúng
là những yêu cầu nhƣng ở dạng mong đợi của khách hàng và mong đợi của nhà
phát triển, nó không ảnh hƣởng nhiều tới việc thiết kế hệ thống.
Giai đoạn thiết kế kiến trúc
Vai trò của kiến trúc sƣ phần mềm là vô cùng cần thiết, chất lƣợng của bản thiết
kế sẽ quyết định thành bại của cả hệ thống. Việc xây dựng các tài liệu chi tiết, quá
trình làm việc giữa các bên liên quan để lấy đƣợc bản yêu cầu đặc tả sẽ là vô ích
nếu kiến trúc sƣ đƣa ra một bản thiết kế kém chất lƣợng [2] . Hình sau đây cho thấy
đầu vào và đầu ra của quy trình thiết kế kiến trúc:
Hình 2.12. Đầu vào và đầu ra của quá trình thiết kế kiến trúc
Bƣớc đầu tiên của việc thiết kế là chọn ra một kiến trúc tổng thể cho kiến trúc
dựa trên những bộ khung (framework) đã tồn tại. Sau đó là việc xác định các thành
phần con phù hợp với bộ khung đã chọn để tạo lên một hệ thống phù hợp. Kết quả
của bản thiết kế bao gồm khung nhìn kiến trúc và tài liệu giải thích kiến trúc.
Khung nhìn bao gồm các bản vẽ, sơ đồ dƣới góc nhìn tổng quan dành cho đội thiết
kế, bản tài liệu kiến trúc mô tả chi tiết bản khung nhìn kiến trúc.

30
Giai đoạn chuẩn hóa
Sau khi thiết kế kiến trúc, việc đánh giá lại kiến trúc xem xét hiệu quả đánh giá
xem kiến trúc đã thiết kế có đảm bảo mục tiêu ban đầu của hệ thống hay không.
Quá trình chuẩn hóa luôn khó khăn và phức tạp với ngay cả những ngƣời có nhiều
kinh nghiệm trong lĩnh vực thiết kế, nó không thể đánh giá cụ thể, kiểm tra chất
lƣợng, kiểm thử để kiểm tra các tiêu chí đặt ra. Kiến trúc thiết kế có thể bao gồm
các thành phần mới hoặc các thành phần đã đƣợc tồn tại sẵn nhƣ các thƣ viện, ứng
dụng con. [2]

31
Chương 3 Phân tích giải pháp tích hợp hệ thống cho
doanh nghiệp
3.1 Tổng quan vấn đề và giải pháp cho doanh nghiệp
Một doanh nghiệp khi hoạt động ngoài việc quản lý mảng kinh doanh chính
của doanh nghiệp, các mảng kỹ thuật, các bộ phận, phòng ban đều có những phần
mềm quản lý nghiệp vụ riêng. Những phần mềm này mang tính đặc thù: đặc thù kế
toán, kiểm toán, hệ thống SAP (hệ thống quản lý quy trình sản xuất, mua, bán),
MES (Hệ thống quản lý nhà máy). Cổng thông tin doanh nghiệp chú trọng đến đảm
bảo các vấn đề an ninh, hành chính, đào tạo cho doanh nghiệp
Hình 3.1. Mô hình tổng quan doanh nghiệp
Các vấn đề về hành chính tổng hợp bao gồm: quản lý nhân viên vào ra, quản
lý khách vào ra, quản lý tài sản, quản lý xe xe ra vào cổng, quản lý bãi đỗ xe, quản
lý đào tạo, ngoài ra còn các vấn đề về hành chính gồm có: quản lý bảng thông tin,
quản lý làm thêm giờ, quản lý phòng họp, sân bóng, quản lý nhà ăn. Các vấn đề về
đào tạo gồm quản lý đào tạo, quản lý các khóa học, môn học cho nhân viên, quản lý
điểm, tiêu chuẩn đào tạo. Sơ đồ doanh nghiệp sản xuất trong các khu công nghiệp
và chế xuất nhƣ sau:

32
Hình 3.2 Sơ đồ ví dụ về doanh nghiệp
Các phòng bảo vệ B1, B2 (đƣợc đặt bên bên ngoài, trƣớc cửa an ninh, để
đảm bảo ngƣời chƣa đăng ký thông tin, chƣa có thẻ thì không thể vào công ty). Với
những công ty lớn thƣờng có nhiều hơn một phòng bảo vệ đăng ký thông tin để tạo
điều kiện cho nhân viên và khách đến làm việc. Nhiệm vụ của phòng bảo vệ là
kierm tra, đăng ký, cấp phát thẻ cho khách đến làm việc, cấp thẻ tam cho nhân viên
công ty quên thẻ. Sau khi đƣợc cấp thẻ, ngƣời sẽ di chuyển tới khu vực các của an
ninh để vào công ty. Các bãi đỗ xe P2, P3, P4, P5 (bãi ô tô, xe máy, xe đạp) ở Việt
Nam chủ yếu là bãi gửi xe máy, bãi ô tô chỉ chiếm một diện tích nhỏ. Các cửa an
ninh: Cửa an ninh A1, A2, A3, A4 đƣợc bố trí bên trái và bên phải của cổng C1, C2
để đảm bảo an ninh vòng ngoài. Cổng chính C1, C2: phục vụ cho các xe con (xe
bốn chỗ, xe chở ngƣời) di chuyển ra vào công ty, xe chở khách VIP, các lãnh đạo
quản lý cấp cao, các phái đoàn. Cổng phụ dành cho các xe chở hàng, vật liệu, xe

33
tải, xe công phục vụ sản xuất, cấp dỡ hàng hóa. Tại đây thông tin xe, lái xe, sẽ đƣợc
kiểm tra và xác nhận thời gian vào ra công ty. Các nhà ăn R1, R2, R3 phục vụ các
suất ăn sáng, trƣa tối cho nhân viên và khách đến làm việc. Tại nhà ăn, thông tin
các món ăn đã đƣợc đƣa lên hệ thống trƣớc đó để nhân viên có thể xem trƣớc giờ
ăn, nhân viên tiết hành xếp hàng đợi xuất ăn và quẹt thẻ để lấy xuất ăn. Việc đánh
giá chất lƣợng bữa ăn cũng đƣợc thông qua hình thức quẹt thẻ, dữ liệu sẽ đƣợc hệ
thống thu thập và tiến hành phân tích báo cáo sau này. Các sân bóng S1, S2, S3
phục vụ cho nhu cầu hoạt động thể chất của nhân viên công ty, các câu lạc bộ, các
phòng ban thực hiện đặt sân trên hệ thống để đảm bảo thống nhất, không tranh
giành sân. Nhân viên hành chính phụ trách sẽ thực hiện kiểm duyệt những đăng ký
này. Trung tâm y tế H1: giám sát sức khỏe nghề nghiệp cho nhân viên, thực hiện
khám sức khỏe định kỳ, chăm sóc nhân viên khi đau ốm. Thông tin nhân viên tham
gia khám chữa bệnh đƣợc cập nhật lên hệ thống. Nhà kho K1, K2: các kho lƣu trữ
hàng hóa và các vật liệu, kho hàng đƣợc lƣu tại K1, K2 chủ yếu đƣợc sử dụng cho
các kho sản phẩm chờ xuất đi. Trung tâm đào tạo: thực hiện đào tạo cho nhân viên,
hàng năm công ty sẽ có khóa đào tạo định kỳ, các khóa đào tạo cho nhà thầu, đào
tạo chuyên môn. Trung tâm nghiên cứu CN1: gồm trung tâm nghiên cứu và xƣởng
thử nghiệm sản phẩm, những mẫu sản phẩm mới, thử nghiệm đều đƣợc xử lý tại
đây. Tòa xƣởng F1,F2, F3, F4, F5, F6, F7: các xƣởng sản xuất của công ty, tại các
xƣởng làm việc đều đƣợc quẹt thẻ từ để mở cửa, trong xƣởng sản xuất các quy định
về an ninh đƣợc thắt chặt hơn cả.
3.1.1 Quản lý khách
Quản lý vào ra
Việc quản lý đƣợc chia ra thành quản lý nhân viên (đổi tƣợng thƣờng xuyên ra
vào công ty, có thẻ nhân viên) và khách/nhà thầu (đến làm việc tạm thời hoặc
thƣờng xuyên). Nhân viên không cần thực hiện đăng ký tại phòng bảo vệ, việc đăng
ký chỉ thực hiện dành cho đối tƣợng khách. Trong trƣờng hợp nhân viên quên thẻ,
cần đến phòng bảo vệ để đƣợc mƣợn thẻ tạm và kích hoạt thẻ, cuối ngày làm việc
nhân viên phải quay lại phòng bảo vệ để trả thẻ. Để khách vào công ty nhân viên
cần đăng ký khách trên hệ thống trƣớc đó. Nhân viên phòng bảo vệ dựa vào thông
tin đăng ký để thực hiện thủ tục: kiểm tra thông tin, cấp thẻ, chụp ảnh thẻ (nếu là
lần đầu đến công ty). Tại cửa an ninh, dữ liệu đƣợc liên kết với hệ thống để mở cửa
Tải bản FULL (69 trang): https://bit.ly/40vxvwD
Dự phòng: fb.com/TaiHo123doc.net

34
và hiện thị ảnh. Cũng tại đây, dữ liệu kích hoạt các cửa ra vào, thẻ nhà ăn và các
quyền khác phục vụ cho công việc cũng đƣợc xử lý.
Hình 3.3 Quy trình ra khỏi công ty của nhân viên-khách
Tại phòng bảo vệ nhân viên sẽ xác nhận hành động trả thẻ và thu lại thẻ trên
hệ thống quản lý. Dữ liệu của khách sẽ đƣợc sử dụng để lƣu trữ, báo cáo trên hệ
thống. Các loại thẻ khách/nhà thầu/nhân viên: Thẻ nhân viên dành cho đối tƣợng
nhân viên công ty, công ty mẹ, công ty con trong cùng tập đoàn. Thẻ này có dây
màu riêng để phân biệt. Thẻ này không cần trả lại sau khi ra khỏi công ty, với đối
tƣợng nhân viên công ty mẹ, công ty cùng tập đoàn đến làm việc chỉ cần kích hoạt
thẻ để sử dụng các dịch vụ khác tại công ty. Thẻ tạm dành cho nhân viên công ty,
nhân viên công ty con, công ty mẹ đến công ty làm việc nhƣng quên thẻ nhân viên.
Thẻ này có đầy đủ mọi quyền hạn nhƣ thẻ nhân viên nhƣ quẹt thẻ gửi xe, thẻ ra vào
cổng, mở cửa văn phòng, thẻ nhà ăn và các quyền khác nhƣ thẻ nhân viên cũ. Thẻ
khách dành cho khách/nhà thầu vào công ty làm việc, thẻ này chỉ đƣợc giới hạn về
quyền hạn, phần lớn chỉ dành để xác thực khi đi qua cửa an ninh của công ty.
Hình 3.4 Cửa an ninh
Mô tả hình ảnh cửa an ninh bao gồm vị trí quet thẻ (số 1) và thanh chắn (2).
Khi thẻ đƣợc kích hoạt và quẹt vào đầu đọc thẻ, hệ thống của sẽ gọi hàm kiểm tra

35
tính hợp lệ trên CTTĐT và có hành động cụ thể. Nếu thẻ đã đƣợc kích hoạt quyền
thì thanh chắn có thể mở ra và ngƣời đó di chuyển qua thanh chắn. Dƣới đây là API
mô tả phƣơng thức gọi yêu cầu kiểm tra tính hợp lệ của thẻ:
Url: /checkPersonCardId? cardId =100000122311
Parameter: cardId( string)
Type: GET
{
"result": "ok",
"msg": "success",
"record": {
"title": "Playsam Streamliner",
"user_id":"key226654786",
"id_no":"12365423",
"avata": {
"fileName": "quwowooybuqbl6ntboz3.jpg",
"contentType": "image/jpg",
"details": {
"image": {
"width": 600,
"height": 446
},
"size": 27187
},
"url": "//dbn.net/images/visitor/quwowooybuqbl6ntboz3.jpg"
}
}
}
Quản lý tài sản khách
Những tài sản của công ty sẽ đƣợc dán tem để phân biệt với tài sản cá nhân.
Ngoài những tài sản quan trọng khác nhƣ thẻ nhớ, thiết bị lƣu trữ, usb cần phải
quản lý chặt chẽ, đảm bảo an ninh thông tin.
Tải bản FULL (69 trang): https://bit.ly/40vxvwD
Dự phòng: fb.com/TaiHo123doc.net

36
Hình 3.5 Hình ảnh tem, thiết bị lưu trữ
Quy trình xử tài sản: Kiểm tra thông tin khách, thiết bị  Xử dụng hệ thống 
Thực hiện thao tác dán tem  Lưu trên hệ thống Kết thúc. Dƣới đây là mẫu dữ
liệu kiểm tra thông tin đăng ký khác trên CTTĐT, từ đó thực hiện kiểm soát tài sản
của khách mang đến công ty.
Url: dbnVisitor/checkInfo?p_id_no=12313123111
Parameter: p_id_no (string)
Type: GET
{
result: "ok",
msg: "success",
record: {
user_id: "key226654786"
id_no: "122365469",
full_name: "Nguyen Van Nam",
email: "nv.nam@dbn.com",
grade: "Senior Staff",
phone: "0966012522"
}
}
Tiếp đó là hành cộng lƣu thông tin kiểm soát tài sản khách lên CTTĐT, máy
khách gửi tới máy chủ ứng dụng các thông tin bao gồm: mã khách, số CMTND,
tên thiết bị, hãng, số serial, ngày đăng ký.
Url: dbnStempDevice/ajaxSaveReq
Parameter type: Object
{
user_id: "key226654786"
id_no: "122365469",
full_name: "Nguyen Van Nam",
device_name: "IPHONE 6",
branch: "Apple",
serial: "1254SE23644",
device_type: "Phone",
date_req: "2019/01/03"
}
Type: POST
Result: Json Type Content
{
6813150