Tải bản đầy đủ (.pdf) (95 trang)

Công nghệ RESTful web services và hệ thống cổng kết nối với tổng đài tin nhắn cho các dịch vụ thông tin di động

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (2.26 MB, 95 trang )

NGUYỄN THỊ LAN

BỘ GIÁO DỤC VÀ ĐÀO TẠO
VIỆN ĐẠI HỌC MỞ HÀ NỘI

LUẬN VĂN THẠC SỸ
CÔNG NGHỆ THÔNG TIN

CHUYÊN NGÀNH: CÔNG NGHỆ THÔNG TIN

CÔNG NGHỆ RESTFUL WEB SERVICES
VÀ HỆ THỐNG CỔNG KẾT NỐI VỚI TỔNG ĐÀI TIN NHẮN
CHO CÁC DỊCH VỤ THÔNG TIN DI ĐỘNG

NGUYỄN THỊ LAN

2015 - 2017

HÀ NỘI - 2017


BỘ GIÁO DỤC VÀ ĐÀO TẠO
VIỆN ĐẠI HỌC MỞ HÀ NỘI

LUẬN VĂN THẠC SỸ

CÔNG NGHỆ RESTFUL WEB SERVICES
VÀ HỆ THỐNG CỔNG KẾT NỐI VỚI TỔNG ĐÀI TIN NHẮN
CHO CÁC DỊCH VỤ THÔNG TIN DI ĐỘNG

NGUYỄN THỊ LAN


CHUYÊN NGÀNH : CÔNG NGHỆ THÔNG TIN
MÃ SỐ: 60.48.02.018

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS. ĐINH TUẤN LONG

HÀ NỘI - 2017


LỜI CAM ĐOAN
Tôi xin cam đoan luận văn là công trình nghiên cứu của riêng cá
nhân tôi, không sao chép của ai do tôi tự nghiên cứu, đọc, dịch tài liệu, tổng
hợp và thực hiện. Nội dung lý thuyết trong trong luận văn tôi có sử dụng một
số tài liệu tham khảo như đã trình bày trong phần tài liệu tham khảo. Các số
liệu, chương trình phần mềm và những kết quả trong luận văn là trung
thực và chưa được công bố trong bất kỳ một công trình nào khác.
Hà Nội, ngày tháng năm 2017
Học viên thực hiện

Nguyễn Thị Lan

i


LỜI CẢM ƠN
Lời đầu tiên, em xin gửi lời biết ơn sâu sắc đến TS. Đinh Tuấn Long
người đã tận tình hướng dẫn, chỉ bảo, giúp đỡ em trong suốt quá trình làm
luận văn.
Em cũng xin gửi lời cảm ơn đến các thầy cô giảng dạy và các thầy cô
trong Khoa Đào Tạo Sau Đại Học đã truyền đạt những kiến thức và giúp đỡ
em trong suốt quá trình học của mình.

Và cuối cùng em xin gửi lời cảm ơn tới các đồng nghiệp, gia đình và
bạn bè những người đã ủng hộ, động viên tạo mọi điều kiện giúp đỡ để
em có được kết quả như ngày hôm nay.
Hà Nội, ngày tháng năm 2017
Học viên thực hiện

Nguyễn Thị Lan

ii


MỤC LỤC
LỜI CAM ĐOAN ............................................................................................................ i
LỜI CẢM ƠN ................................................................................................................. ii
MỤC LỤC .......................................................................................................................iii
DANH MỤC CÁC THUẬT NGỮ, CHỮ VIẾT TẮT ................................................ vi
DANH SÁCH HÌNH VẼ ..............................................................................................vii
MỞ ĐẦU ....................................................................................................................... viii
CHƯƠNG 1: DỊCH VỤ WEB SERVICE VÀ REST .................................................. 1
1.1 Tổng quan về dịch vụ web ............................................................................ 1
1.2 Kiến trúc và các thành phần của dịch vụ Web service ............................... 4
1.2.1 Khái niệm định dạng XML - eXtensible Markup Language ....... 4
1.2.2 Mô tả các giao thức sử dụng trong dịch vụ web SOAP - Simple
Object Access Protocol ........................................................................... 5
1.2.3 WSDL - Web Service Description Language ............................... 7
1.2.4 Khái niệm UDDI ............................................................................ 9
1.3 XML-RPC ..................................................................................................... 9
1.4 Khái niệm REST ......................................................................................... 10
1.5 Nguyên tắc của REST ................................................................................. 11
1.5.1 Tài nguyên .................................................................................... 12

1.5.2 Khả năng đánh địa chỉ .................................................................. 13
1.5.3 Phi trạng thái ................................................................................. 14
1.5.4 Kết nối ........................................................................................... 14
1.5.5 Giao diện đồng nhất ..................................................................... 15
1.5.6 Khả năng lưu cache ...................................................................... 16
1.6 Dịch vụ web RESTful ................................................................................. 17
iii


1.7 So sánh SOAP và RESTful ........................................................................ 18
KẾT LUẬN CHƯƠNG .................................................................................... 21
CHƯƠNG 2: VẤN ĐỀ BẢO MẬT VỚI WEB SERVICE DỊCH VỤ RESTFUL .. 22
2.1 Vấn đề an toàn bảo mật Web Service ........................................................ 22
2.1.1 Bảo mật Web Service ................................................................... 22
2.1.2 Một số kỹ thuật Web Service Security .......................................... 23
2.2 Vấn đề bảo mật với dịch vụ RESTful ........................................................ 29
2.3 Kiểu kiến trúc REST phù hợp với bộ đệm web ........................................ 30
2.4 Khóa mã hóa nội dung đối xứng ................................................................ 31
2.5 An toàn cho dịch vụ web ............................................................................ 32
2.6 Xây dựng một dịch vụ web ........................................................................ 34
2.7 Tích hợp dịch vụ web theo chuẩn .............................................................. 35
2.8 Thảo luận về giải pháp ................................................................................ 37
2.9 Áp dụng bảo mật dịch vụ web RESTful .................................................... 38
2.9.1 Bảo mật dịch vụ web RESTful bằng cách cấu hình web.xml ... 38
2.9.2 Bảo mật dịch vụ web RESTful bằng cách sử dụng
SecurityContext...................................................................................... 38
2.9.3 Bảo mật dịch vụ web RESTful bằng cách sử dụng ký hiệu ...... 39
KẾT LUẬN CHƯƠNG .................................................................................... 40
CHƯƠNG 3: TÌM HIỂU HỆ THỐNG SMS GATEWAY ........................................ 41
3.1 Tìm hiểu về hệ thống SMSGatewate ......................................................... 41

3.1.1 Giới thiệu chung về hệ thống ....................................................... 41
3.1.2 Nguyên tắc hoạt động của hệ thống SMS ................................... 42
3.1.3 Hệ thống SMSGateway................................................................ 42
3.1.4 Mục tiêu áp dụng REST ............................................................... 44
iv


3.1.5 Tài nguyên .................................................................................... 45
3.1.6 Đánh địa chỉ .................................................................................. 46
3.1.7 Phi trạng thái ................................................................................. 46
3.1.8 Liên kết với nhau .......................................................................... 47
3.1.9 Giao diện đồng nhất ..................................................................... 47
3.1.10 Khả năng cache........................................................................... 49
3.2 Cấu trúc REST API ..................................................................................... 49
3.3 Các lược đồ tuần tự ..................................................................................... 52
3.4 Thử nghiệm API với Google Chrome ....................................................... 64
3.5 Thử nghiệm API với giao diện ứng dụng .................................................. 65
KẾT LUẬN CHƯƠNG .................................................................................... 68
KẾT LUẬN ................................................................................................................... 69
TÀI LIỆU THAM KHẢO ............................................................................................ 70
PHỤ LỤC ...................................................................................................................... 71

v


DANH MỤC CÁC THUẬT NGỮ, CHỮ VIẾT TẮT
TỪ VIẾT TẮT

TIẾNG ANH


TIẾNG VIỆT

REST

Representational State
Transfer

Chuyển đổi trạng thái đại diện

MO

Mobile Originated

Tin nhắn đến

MT

Mobile Terminated

Tin nhắn đi

SMS

Short Message Service

Tin nhắn

XML

Extensible Markup

Langguage

Ngôn ngữ đánh dấu mở rộng

SOAP

Simple Object Access
Protocol

Giao thức truy cập đối tượng đơn
giản

WSDL

Web Service Description
Langguage

Ngôn ngữ mô tả dịch vụ

UDDI

Universal Description,
Discovery và Integration

HTTP

Hypertext Transfer Protocol

Giao thức truyền tải nội dung
siêu văn bản


W3C

World Wide Web Consortium

Tổ chức World Wide Web

RPC

Remote Procedure Call

Triệu gọi thủ tục từ xa

JAX-RS

Java API for RESTful Web
Services

Thư viện API cho dịch vụ web
RESTful

URI

Uniform resource identifier

Xác định tài nguyên đồng nhất

API

Application programming

interface

Giao diện lập trình ứng dụng

vi


DANH SÁCH HÌNH VẼ
Hình 1.1: Kiến trúc dịch vụ web .................................................................................... 4
Hình 1.2: Mô tả hoạt động của SOAP ........................................................................... 6
Hình 1.3: Cấu trúc của một thông điệp SOAP .............................................................. 6
Hình 1.4: Cấu trúc của WSDL ....................................................................................... 7
Hình 1.5:Các thành phần của WSDL ............................................................................ 8
Hình 1.6: Hai uri cùng trỏ đến một tài nguyên ........................................................... 12
Hình 1.7: Minh họa việc gửi địa chỉ ............................................................................ 13
Hình 1.8: Sự liên kết giữa các máy khách ................................................................... 14
Hình 1.9: So sánh SOAP và RESTful ......................................................................... 19
Hình 3.1: Mô hình hệ thống SMS Gateway ................................................................ 42
Hình 3.2: Nguyên tắc hoạt động của hệ thống ............................................................ 42
Hình 3.3: Mô hình hệ thống SMSGateway ................................................................. 43
Hình 3.4: Mô hình REST API trong hệ thống admin ................................................. 44
Hình 3.5: Mô hình REST API trong hệ thống ............................................................ 50
Hình 3.6: Thiết kế cấu trúc REST API trong hệ thống .............................................. 51
Hình 3.7: Lược đồ tuần tự lấy danh sách MO ............................................................. 56
Hình 3.8: Lược đồ tuần tự lấy một MO ....................................................................... 58
Hình 3.9: Lược đồ tuần tự tạo mới một MO ............................................................... 60
Hình 3.10: Lược đồ tuần tự cập nhật một MO ............................................................ 61
Hình 3.11: Lược đồ tuần tự tìm kiếm MO .................................................................. 63
Hình 3.12: Kiểm tra chức năng POST dữ liệu với Postman ...................................... 64
Hình 3.13: Kiểm tra chức năng GET dữ liệu với Postman ........................................ 65

Hình 3.14: Giao diện demo chức năng POST ............................................................. 66
Hình 3.15: Kiểm tra chức năng GET dữ liệu với ứng dụng demo ............................ 67
vii


MỞ ĐẦU
1. Lý do chọn đề tài
Ngày này hệ thống Internet ngày càng phát triển, phần mềm sử dụng hệ
thống Internet ngày càng nhiều. Các phần mềm đa dạng dẫn đến có rất nhiều yêu
cầu cần được đáp ứng. Một số phần mềm đòi hỏi về lượng thông tin lớn, dữ liệu
lớn… nhưng không thể lưu dữ liệu đó tại thiết bị sử dụng, một số loại yêu cầu được
cập nhật realtime (theo thời gian thực) để đảm bảo sự đúng đắn của thông tin
(chứng khoán, tiền tệ ...), một số phần mềm đòi hỏi xử lý nhanh và mạnh, mà các
thiết bị lại không thể thực hiện được do cấu hình không đủ. Thông thường, để sử
dụng các dịch vụ đó thì người dùng cần dùng trình duyệt, truy cập website và thực
hiện. Nhưng người dùng chỉ có thể sử dụng các giao diện mà nhà cung cấp đã thiết
kết sẵn tuy nhiên chúng không đáp ứng những mong muốn của người dùng. Để giải
quyết vấn đề trên chúng ta cần xây dựng một ứng dụng có các tính năng như các
dịch vụ đó nhưng giao diện thân thiện hơn. Vì vậy cần phải sử dụng những dịch vụ
riêng biệt để tương tác với hệ thống cung cấp các dịch vụ nói trên. Công nghệ có
thể hỗ trợ để giải quyết bài toán trên là RESTful, do vậy tôi xin được lựa chọn đề tài
nghiên cứu là: “Công nghệ RESTful web services và hệ thống cổng kết nối với tổng
đài tin nhắn cho các dịch vụ thông tin di động”

2. Mục tiêu và đối tượng nghiên cứu của đề tài
- Mục tiêu nghiên cứu
+ Hiểu được các nguyên tắc của REST.
+ Hiểu được loại dữ liệu được điều khiển bởi các hệ thống dựa trên nền
web.
+ Đưa ra được phương pháp xây dựng cách thức truy cập dữ liệu sử dụng

API REST.
+ Tiến hành cài đặt API RESTful theo phương pháp trên.
+ Cho thấy rằng API vừa cài đặt có thể dùng chung cho cả người và máy.
- Đối tượng và phạm vi nghiên cứu
Đối tượng nghiên cứu:

viii


+ Tìm hiểu nguồn gốc từ REST và ý nghĩa
+ Tìm hiểu về thư viện JAX-RS
+ Nghiên cứu dịch vụ RESTful, các phương pháp bảo mật cơ bản, cũng
như các vấn đề liên quan
Phạm vi nghiên cứu:
+ Tìm hiểu và ứng dụng REST
+ Nghiên cứu một số giải pháp xây dựng “Hệ thống cổng kết nối với
tổng đài tin nhắn cho các dịch vụ thông tin di động”
+ Do có những hạn chế nhất định về cơ sở vật chất và điều kiện tiếp cận
thực tế với lĩnh vực viễn thông nên việc cài đặt ứng dụng chủ yếu
mang tính thử nghiệm.

3. Nội dung
Chương 1: Giới thiệu chung về dịch vụ web, kiến trúc và các thành phần cơ
bản của dịch vụ web như XML, SOAP, WSDL và UDDI từ đó đưa ra mục tiêu phát
triển luận văn, cũng trong chương này sẽ giới thiệu về REST, mô tả từ khóa REST
ngày nay rất phù hợp với nền tảng cơ bản với dịch vụ web, đưa ra lý do tại sao chọn
REST để phát triển dịch vụ web, và phần giới thiệu hệ thống mà sau này tác giả có
ý định phát triển dịch vụ RESTful cũng được giới thiệu trong phần này. Giới thiệu
thư viện JAX-RS và cách sử dụng thư viện vào việc lập trình phát triển dịch vụ
web, các tính năng cũng như các toán tử của thư viện JAX-RS cũng sẽ được trình

bày ở chươn g này.
Chương 2: Chương này giới thiệu các phương pháp bảo mật cơ bản cũng như
cách thực hiện và áp dụng vào hệ thống.
Chương 3: Trong nội dung của chương này sẽ tìm hiểu về hệ thống
SMSGateway, nguyên tắc hoạt động của hệ thống cũng như mục tiêu mà hệ thống
cần đạt được, áp dụng các nguyên tắc của REST và sử dụng thư viện JAX-RS để
thiết kế các dịch vụ web RESTful ứng dụng vào hệ thống SMSGateway. Ngoài ra
sẽ có các thực nghiệm mô tả các tiến trình phát triển ứng dụng và cung cấp một một
vài tool để có thể thực nghiệm ứng dụng thực hiện các yêu cầu REST API.

4. Phương pháp thực hiện đề tài
ix


 Thu thập, phân tích các tài liệu và những thông tin liên quan đề đề tài.
 Tìm hiểu các giải pháp trong việc xây dựng API của một số Website trong và
ngoài nước.
 Kết hợp các nghiên cứu đã có trước đây của các tác giả trong và ngoài nước
cùng với sự chỉ bảo, góp ý của thầy hướng dẫn để hoàn thành nội dung
nghiên cứu.

x


CHƯƠNG 1: DỊCH VỤ WEB SERVICE VÀ REST
Trong nội dung chương này tác giả sẽ tìm hiểu tổng quan về dịch vụ web,
kiến trúc, thành phần cơ bản, cũng trong chương này tác giả sẽ đưa ra những tìm
hiểu nguồn gốc từ REST và ý nghĩa của nó, tại sao chúng ta lựa chọn REST thay
thế mà không phải là cái khác. Trong chương này cũng giới thiệu những ý tưởng cơ
bản của REST, các đặc điểm chính và lý do nên sử dụng REST.


1.1 Tổng quan về dịch vụ web
Dịch vụ Web (Web Service) được coi là một công nghệ mang đến cuộc cách
mạng trong cách thức hoạt động của các dịch vụ B2B (Business to Business) và
B2C (Business to Customer). Giá trị cơ bản của dịch vụ Web 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. Các phần mềm được viết bởi những ngôn ngữ lập trình khác nhau và
chạy trên những nền tảng khác nhau có thể sử dụng dịch vụ Web để chuyển đổi dữ
liệu thông qua mạng Internet theo cách giao tiếp tương tự bên trong một máy tính.
Tuy nhiên, công nghệ xây dựng dịch vụ Web không nhất thiết phải là các công nghệ
mới, nó có thể kết hợp với các công nghệ đã có như XML, SOAP, WSDL, UDDI…
Với sự phát triển và lớn mạnh của Internet, dịch vụ Web thật sự là một công nghệ
đáng được quan tâm để giảm chi phí và độ phức tạp trong tích hợp và phát triển hệ
thống. Chúng ta sẽ xem xét các dịch vụ Web từ mức khái niệm đến cách thức xây
dựng.

1.1.1 Giới thiệu công nghệ
Có rất nhiều những định nghĩa được đưa ra, nhưng theo định nghĩa của
W3C (World Wide Web Consortium) [18] thì một dịch vụ web là một hệ thống
phần mềm được xây dựng sẵn các tính năng cần thiết, hay còn gọi là các phương
thức theo chuẩn để hỗ trợ sự tương tác giữa máy tính và máy tính, giữa người và
máy tính. Dịch vụ web cung cấp một API được mô tả theo một định dạng chung
gọi là ngôn ngữ mô tả dịch vụ web (Web Service Description Language) viết tắt
là WSDL [6]. Trong đó người dùng hoặc máy tính thực hiện tương tác với dịch
vụ web thông qua giao thức SOAP (Simple Object Access Protocol) [9]. Đây là

1


một trong các giao thức được sử dụng để trao đổi thông tin trên mạng phổ biến

nhất hiện nay sử dụng HTTP (Hypertext Transfer Protocol) [12,6,7] kết hợp với
việc sử dụng XML cùng với một số chuẩn khác. Tóm lại qua đây chúng ra dễ
dàng nhận thấy mục đính chính của dịch vụ web là cho phép trao đổi và tương
tác thông tin, các chức năng, dữ liệu, các tài nguyên giữa các ứng dụng một cách
dễ dàng mà không cần quan tâm đến môi trường phát triển cũng như ngôn ngữ
lập trình bởi tất cả đã cả được quy về một định dạng chung. Ngoài ra chúng ta
cần hiểu rõ được bản chất của dịch vụ web là một tập hợp các đối tượng, các
phương thức được thực thi và công bố lên mạng để có thể triệu gọi được từ xa
thông qua các ứng dụng khác nhau.

1.1.2 Các đặc điểm của dịch vụ web
a. Đặc điểm
-

Dịch vụ Web cho phép client và server tương tác được với nhau ngay cả
trong những môi trường khác nhau. Ví dụ, đặt Web server cho ứng dụng trên
một máy chủ chạy hệ điều hành Linux trong khi người dùng sử dụng máy
tính chạy hệ điều hành Windows, ứng dụng vẫn có thể chạy và xử lý bình
thường mà không cần thêm yêu cầu đặc biệt để tương thích giữa hai hệ điều
hành này.

-

Phần lớn kĩ thuật của Dịch vụ Web được xây dựng dựa trên mã nguồn mở và
được phát triển từ các chuẩn đã được công nhận, ví dụ như XML.

-

Một Dịch vụ Web bao gồm có nhiều mô-đun và có thể công bố lên mạng
Internet.


-

Là sự kết hợp của việc phát triển theo hướng từng thành phần với những lĩnh
vực cụ thể và cơ sở hạ tầng Web, đưa ra những lợi ích cho cả doanh nghiệp,
khách hàng, những nhà cung cấp khác và cả những cá nhân thông qua mạng
Internet.

-

Một ứng dụng khi được triển khai sẽ hoạt động theo mô hình client-server.
Nó có thể được triển khai bởi một phần mềm ứng dụng phía server ví dụ như
PHP, Oracle Application server hay Microsoft.Net…

2


-

Ngày nay dịch vụ Web đang rất phát triển, những lĩnh vực trong cuộc sống
có thể áp dụng và tích hợp dịch vụ Web là khá rộng lớn như dịch vụ chọn lọc
và phân loại tin tức (hệ thống thư viện có kết nối đến web portal để tìm kiếm
các thông tin cần thiết); ứng dụng cho các dịch vụ du lịch (cung cấp giá vé,
thông tin về địa điểm…), các đại lý bán hàng qua mạng, thông tin thương
mại như giá cả, tỷ giá hối đoái, đấu giá qua mạng…hay dịch vụ giao dịch
trực tuyến (cho cả B2B và B2C) như đặt vé máy bay, thông tin thuê xe…

-

Các ứng dụng có tích hợp dịch vụ Web đã không còn là xa lạ, đặc biệt trong

điều kiện thương mại điện tử đang bùng nổ và phát triển không ngừng cùng
với sự lớn mạnh của Internet. Bất kì một lĩnh vực nào trong cuộc sống cũng
có thể tích hợp với dịch vụ Web, đây là cách thức kinh doanh và làm việc có
hiệu quả bởi thời đại ngày nay là thời đại của truyền thông và trao đổi thông
tin qua mạng. Do vậy, việc phát triển và tích hợp các ứng dụng với dịch vụ
Web đang được quan tâm phát triển là điều hoàn toàn dễ hiểu.
b. Ưu và nhược điểm
Ưu điểm

-

Dịch vụ Web cung cấp khả năng hoạt động rộng lớn với các ứng dụng phần
mềm khác nhau chạy trên những nền tảng khác nhau.

-

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 (text), giúp các lập trình viên dễ dàng hiểu được.

-

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

-

Thúc đẩy đầu tư các hệ thống phần mềm đã tồn tại bằng cách cho phép các
tiến trình/chức năng nghiệp vụ đóng gói trong giao diện dịch vụ Web.

-


Tạo mối quan hệ tương tác lẫn nhau và mềm dẻo giữa các thành phần trong
hệ thống, dễ dàng cho việc phát triển các ứng dụng phân tán.

-

Thúc đẩy hệ thống tích hợp, giảm sự phức tạp của hệ thống, hạ giá thành
hoạt động, phát triển hệ thống nhanh và tương tác hiệu quả với hệ thống của
các doanh nghiệp khác.

3


Nhược điểm
-

Những thiệt hại lớn sẽ xảy ra vào khoảng thời gian chết của Dịch vụ Web,
giao diện không thay đổi, có thể lỗi nếu một máy khách không được nâng
cấp, thiếu các giao thức cho việc vận hành.

-

Có quá nhiều chuẩn cho dịch vụ Web khiến người dùng khó nắm bắt.

-

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

1.2 Kiến trúc và các thành phần của dịch vụ Web service
Trong lĩnh vực công nghệ thông tin thì công nghệ dịch vụ web không phải là
một công nghệ mới, mà công nghệ này đã được ra đời dựa trên các nền tảng công

nghệ sẵn có trước đó. Nó sự kết hợp của các ứng dụng dựa trên nền web sử dụng
được sử dụng để mô tả dữ liệu, SOAP đóng vai trò giao thức truyền tải dữ
liệu, WSDL đóng vài trò mô tả cho dịch vụ web còn UDDI đóng vai trò cung cấp
danh sách các dịch vụ web đang hoạt động. Về chi tiết các chuẩn mở này như đặc
điểm... sẽ được làm rõ hơn trong phần sau của luận văn. Dựa vào sơ đồ dưới có thể
thấy các thành phần cơ bản của dịch vụ web.

Hình 1.1: Kiến trúc dịch vụ web

1.2.1 Khái niệm định dạng XML - eXtensible Markup Language
-

XML (Extensible Markup Langguage) là một chuẩn do W3C đề ra và được
phát triển từ SGML, XML được xem là một ngôn ngữ đánh dấu mở rộng với
4


cấu trúc do lập trình viên phát triển dịch vụ tự định nghĩa. Về hình thức thì
XML hoàn toàn có cấu trúc thẻ giống như HTML, nhưng HTML định nghĩa
thành phần được hiện thị như thế nào thì XML lại định nghĩa những thành
phần đó chứa những cái gì. Hay nói cách khác XML có cú pháp tương tự
HTML nhưng không tuân theo một đặc tả quy ước như HTML. Người sử
dụng hoặc các chương trình có thể quy ước định dạng các thẻ XML.
Về cơ bản có thể thấy dịch vụ web là sự kết hợp của nhiều thành phần khác
nhau, và dịch vụ này hỗ trợ tương tác giữa các hệ thống được cài đặt trên
môi trường khác nhau. Do đó cần phải sử dụng một loại tài liệu đồng nhất
giúp giải quyết được vấn đề tương thích và XML hoàn toàn phù hợp với yêu
cầu trên. Có thể hiểu đơn giản XML giải quyết Blues Middleware truyền
thống kết hợp với kết nối chặt chẽ. XML làm cho webservice linh hoạt và
thích nghi. XML đã trở thành nền tảng cho việc xây dựng các dịch vụ web và

XML có hai chức năng chính:
-

Trao đổi thông tin dữ liệu trong hệ thống sử dụng dịch vụ web

1.2.2 Mô tả các giao thức sử dụng trong dịch vụ web
SOAP - Simple Object Access Protocol
SOAP (Simple Object Access Protocol) là một giao thức dùng để truy
xuất các thông tin từ dịch vụ web thông qua một thông điệp chung. SOAP được
Microsoft đề xuất vào năm 1998, hiện nay SOAP thuộc quyền quản lý và cải
tiến của tổ chức W3C. SOAP là một giao thức dựa trên nền tảng
XML(HTTP/SMTP), mô tả cách định dạng, đóng gói thông tin của các thông
điệp và trao đổi chúng thông qua mạng mà không phụ thuộc bất kỳ môi trường
thực thi hay ngôn ngữ lập trình nào.

5


Hình 1.2: Mô tả hoạt động của SOAP

Đơn vị trao đổi thông tin cơ bản của SOAP là thông điệp SOAP (SOAP
Message). Mỗi thông điệp SOAP sẽ được dùng bởi một thẻ gốc là <Envelope>
trong đó chứa 2 thẻ thành phần là SOAP Header và SOAP Body. SOAP Header
chứa các thông tin cần thiết cho việc thực hiện chuyển thông điệp hay cơ chế
định danh, bảo mật. SOAP Body chứa dữ liệu ứng dụng. Cấu trúc của một thông
điệp SOAP như hình sau:

Hình 1.3: Cấu trúc của một thông điệp SOAP

6



Chúng ta đã hiểu cơ bản Web service như thế nào nhưng vẫn còn một vấn
đề khá quan trọng. Đó là làm thế nào để truy xuất dịch vụ khi đã tìm thấy? Câu
trả lời là các Web service có thể truy xuất bằng một giao thức là Simple Object
Access Protocol – SOAP. Nói cách khác chúng ta có thể truy xuất đến UDDI
registry bằng các lệnh gọi hoàn toàn theo định dạng của SOAP.

1.2.3 WSDL - Web Service Description Language
WSDL (Web Service Description Langguage) là một tài liệu đặc tả dựa
trên chuẩn ngôn ngữ XML để mô tả các dịch vụ web. Ban đầu WSDL được
Microsoft và Ariba đề xuất, nhưng hiện nay WSDL được quản lý và phát triển
bởi W3C. Mỗi một đặc tả WSDL sẽ cung cấp tài liệu cho các hệ thống phân tán
cũng như mô tả chức năng của một dịch vụ web, cách thức tương tác, các thông
điệp tương tác cho các yêu cầu theo request hay response. Sau đây là cấu trúc
cơ bản của một tài liệu:

Hình 1.4:Cấu trúc của WSDL

Một đặc tả WSDL bao gồm 2 phần chính: phần trừu tượng (Abstract
definitions) và phần cụ thể (Concrete definitions), phần trừu tượng bao gồm các
thông tin được chứa trong các thẻ types, message và portypes. Phần cụ thể bao
gồm các thông tin được chứa trong các thẻ bindings và ports. Mỗi thành phần sẽ

7


có một tham chiếu đến một thành phần khác được mô tả như hình sau:

Hình 1.5:Các thành phần của WSDL


Mỗi một thành phần có một chức năng riêng, cụ thể như sau:
-

Types: chỉ ra kiểu dữ liệu cho các thông điệp gửi và nhận

-

Messages: là một thành phần trừu tượng mô tả cách thức giao tiếp
giữa máy khách và máy chủ.

-

Porttypes: mô tả ánh xạ giữa các thông điệp, được mô tả trong phần tử
messages và các phương thức (operations).

-

Binding: xác định giao thức nào được sử dụng khi giao tiếp với dịch
vụ web, định nghĩa kiểu binding và giao thức vận chuyển binding
cũng định nghĩa các

-

operations.

-

Port: chỉ định địa chỉ và cổng kết nối tới dịch vụ web, thường là một
địa chỉ URL đơn giản.


8


1.2.4 Khái niệm UDDI
UDDI (Universal Description, Discovery và Integration) cũng được
Microsoft, IBM và Ariba đề xuất năm 2000. Ngày nay UDDI thuộc quyền sở
hữu và phát triển của tổ chức OASIS (Organization for the Advancement of
Structured Information Standards). UDDI được xây dựng nhằm mục đính cung
cấp khả năng cho phép công bố, tổng hợp và tìm kiếm các dịch vụ web. UDDI
đưa ra một tập hợp các hàm API được chia làm 2 phần: Inquiry API, dùng để
tìm kiếm và truy xuất các dịch vụ web đã đăng ký và Publisher ‘s API, dùng để
công bố các dịch vụ web muốn đăng ký. Thông tin tổ chức trong UDDI được
chia làm 3 phần:
-

White pages: liệt kê thông tin của các nhà cung cấp dịch vụ web, bao
gồm địa chỉ, thông tin liên lạc và định danh.

-

Yellow pages: phân loại dịch vụ theo tổ chức hay nhóm dịch vụ hoặc
địa điểm đặt các dịch vụ.

-

Green pages: cung cấp thông tin về các dịch vụ web, cách thức truy
cập cũng như tương tác với các dịch vụ web đó.

1.3 XML-RPC

XML-RPC được kế thừa từ RPC và World Wide Web, sử dụng lại ý tưởng
và nền tảng về việc tạo ra sự giao tiếp giữa con người với nhau để hỗ trợ việc giao
tiếp giữa các chương trình trên máy tính. Mặc dù web là công cụ giao tiếp giữa con
người với con người, sau đó được tiến hóa một cách tinh tế để làm công cụ giao tiếp
giữa con người và máy tính, cuối cùng chuyển sang dạng truyền thông phức tạp
giữa máy tính và máy tính
HTML thực sự đã rất thành công, nhưng thực tế mới chỉ hữu ích cho các
giao dịch hiển thị thông tin cho con người. Vì lý do đó, W3C tổ chức phát triển
eXtensible Markup Language (XML), một ngôn ngữ đánh dấu cung cấp linh hoạt
hơn HTML về việc giao tiếp giữa các chương trình. XML được truyền giữa các
máy tính sử dụng giao thức HTTP thông qua RPC, sử dụng HTTP có nghĩa là các
yêu cầu XML-RPC phải được đồng bộ và phi trạng thái, một yêu cầu XML-RPC
luôn luôn có một trả lời XML-RPC tương ứng, bởi vì yêu cầu và trả lời đều phải
9


xảy ra trên cùng một kết nối HTTP. XML cũng có khả năng thực thi hệ thống
không đồng bộ, nhưng trong nhiều trường hợp chi phí để tạo ra hệ thống đó là điều
không thể. Nói chung các yêu cầu không đồng bộ có khả năng thực hiện nhiều yêu
cầu của tiến trình hơn.
Phi trạng thái (stateless) có nghĩa là không có nội dung được hiểu từ yêu cầu
này đến yêu cầu tiếp theo. Bản thân XML-RPC cũng không có cách khác là xem
chúng như hai yêu cầu riêng biệt không liên quan đến nhau. Điều này nhiều khi có
thể tránh được các chi phí lớn liên quan đến việc bảo trì hệ thống. XML-RPC không
cung cấp hỗ trợ duy trì trạng thái, nhưng với một hệ thống với statefull thì XMLRPC có thể thực hiện hỗ trỡ duy trì trạng thái.
Với các điểm chính về công nghệ liên quan đến XML-RPC như trên thì
XML-RPC có các nhược điểm như sau:
-

Một yêu cầu XML-RPC bao gồm hành động để thực hiện và các tham số

của hành động đó trong yêu cầu gửi lên HTTP khi mà HTTP đã sẵn sàng
đáp ứng yêu cầu và trả lời yêu cầu.

-

Một API XML-RPC thì cần phải định nghĩa mã lỗi riêng của nó, khi đó
sẽ dễ dàng sử dụng trạng thái mã lỗi hơn.

-

Với kiểu API sử dụng XML-RPC thì các chức năng về xác thực và cache
bên phía máy khách không thể thực hiện được trong hệ thống này.

Một giải pháp mới có thế thay thế XML-RPC để khắc phục các nhược điểm
của XMLRPC đó chính là dịch vụ RESTful. Chúng ta sẽ tìm hiểu dịch vụ này chi
tiết hơn trong chương 2 và chương 3 để có thể hiểu REST được thay thế XML-RPC
như thế nào.

1.4 Khái niệm REST
Những khái niệm đầu tiên về REST ( REpresentational State Transfer) được
đưa ra vào năm 2000 trong luận văn tiến sĩ của Roy Thomas Fielding (đồng sáng
lập giao thức HTTP). Trong luận văn ông giới thiệu khá chi tiết về các ràng buộc,
quy ước cũng như cách thức thực hiện với hệ thống để có được một hệ thống REST.
REST (Representational State Transfer) là một kiểu kiến trúc được định
nghĩa bởi Roy Fielding [15]. Mục đính của REST là thiết kế các ứng dụng mạng
10


phân tán sử dụng HTTP như là một giao thức tầng ứng dụng và nó là một mô hình
kiến trúc thực sự cho web.

REST định nghĩa các quy tắc kiến trúc để bạn thiết kế Web services, chú
trọng vào tài nguyên hệ thống, bao gồm các trạng thái tài nguyên được định dạng
như thế nào và được truyền tải qua HTTP, và được viết bởi nhiều ngôn ngữ khác
nhau. Nếu tính theo số dịch vụ mạng sử dụng, REST đã nổi lên trong vài năm qua
như là một mô hình thiết kế dịch vụ chiếm ưu thế. Trong thực tế, REST đã có
những ảnh hưởng lớn và gần như thay thế SOAP và WSDL vì nó đơn giản và dễ sử
dụng hơn rất nhiều.
REST là một bộ quy tắc để tạo ra một ứng dụng Web Service, mà nó tuân
thủ 4 nguyên tắc thiết kế cơ bản sau:
-

Sử dụng các phương thức HTTP một cách rõ ràng

-

Phi trạng thái

-

Hiển thị cấu trúc thư mục như các URls

-

Truyền tải JavaScript Object Notation (JSON), XML hoặc cả hai.

1.5 Nguyên tắc của REST
Như một hệ quả tất yếu của quá trình phức tạp ngày càng lớn của các dịch vụ
web lớn nên RESTful đã được đưa ra như là một giải pháp để thay thế việc thực
hiện triệu gọi từ xa (RPC) thông qua web.
Web dựa vào tài nguyên, nhưng các dịch vụ web lớn lại không dựa vào tài

nguyên. Web dựa vào URI và liên kết nhưng các dịch vụ web lớn lại không dựa vào
chúng. Web dựa vào HTTP và các tính năng của nó, nhưng các dịch vụ web hầu
như không dựa vào bất kỳ tính năng nào của HTTP. Vấn đề này không phải là các
dịch vụ web lớn không nhận ra mà nó cảm thấy không nhận được lợi ích gì từ dịch
vụ web hướng tài nguyên. Chúng không có khả năng đánh địa chỉ, không cache, kết
nối không tốt. Chúng cũng không cần giao diện đồng nhất. Chúng không được rõ
ràng, hiểu được một vấn đề không giúp mình hiểu được vấn đề tiếp theo, trong thực
tế chúng cũng có vấn đề khi tương tác với nhiều khách hàng cùng một lúc.
REST là một kiểu kiến trúc cho hệ thống phân tán như World Wide Web. Để
thực thi kiến trúc RESTful ta cần phải tuân thủ theo hướng dẫn của ROA, kiến trúc
11


hướng tài nguyên, trong tài liệu này sẽ có các quy tắc cho phép ta thiết kế dịch vụ
RESTful [15].
Kiến trúc REST cũng phải dựa vào các nguyên tắc [14,15,16] như mô tả
trong các tài liệu, đó là Tài nguyên(Resources), Khả năng đánh địa
chỉ(Addressability), Phi trạng thái(Statelessness), Kết nối(Connectedness), Giao
diện đồng nhất(Uniform Interface) và Khả năng lưu cache(Cacheability).

1.5.1

Tài nguyên
Mọi thứ mà dịch vụ cung cấp đều là tài nguyên như khách hàng, xe hơi,

tranh ảnh, giọng nói, cửa hàng thương mại điện tử,v.v… tài nguyên có thể là
một đối tượng vật lý cũng có thể là một khái niệm trừu tượng nào đó. Mọi tài
nguyên đều có duy nhất một URI(với một mã duy nhất). Nếu một thông tin nào
đó không có URI thì nó không phải là tài nguyên và không tồn tại trên mạng.
Hai tài nguyên không thể có cùng một URI (xem hình 1.5) nhưng hai

URI có thể trỏ vào cùng một tài nguyên vào cùng một thời điểm (xem hình 1.6).
Ví dụ chúng ta có một URI xác định http://server/last_version và một URI xác
định một tài nguyên khác http://server/last_version_1.3, khi last_version hiện tại
là phiên bản 1.3 thì cả hai URI đều cùng trỏ vào một tài nguyên. Sau một thời
gian thì last_version lên phiên bản mới là 1.4, lúc đó hai URI này sẽ trỏ vào hai
tài nguyên khác nhau.

Hình 1.6: Hai URI cùng trỏ đến một tài nguyên

12


1.5.2 Khả năng đánh địa chỉ
Mọi tài nguyên đều được đánh địa chỉ, mỗi tài nguyên đều được đánh địa
chỉ có nghĩa là sẽ có đủ URI để đánh địa chỉ cho mọi tài nguyên, với khả năng
đánh địa chỉ chúng ta có thể lưu lại các trang thông tin cần thiết, cũng có thể gửi
URI này tới người khác như là một tài nguyên, đặc biệt với khả năng lưu cache,
thì tài nguyên được lưu ở máy khách, sau lần truy cập đầu tiên thì tài nguyên sẽ
được truy cập ở máy khách.
Chúng ta cùng xem xét qua ứng dụng của Google Maps, vào ứng dụng
Google Maps chúng ta gõ “Nguyễn Trãi, Hanoi, Vietnam” hệ thống Google
Maps sẽ hiện thị ra một số địa chỉ mà liên quan đến từ khóa ta vừa gõ, ta thấy
URI của site không thay đổi, điều đó có nghĩa là không
phải Google Maps không có khả năng đánh địa chỉ, có nghĩa rằng ứng dụng web
mà chúng ta đang sử dụng thì không có khả năng đánh địa chỉ mà cái khả năng
đánh địa chỉ chính là dịch vụ web. Nếu chúng ra muốn gửi thông tin bản đồ này
cho người khác thì chúng ta cần yêu cầu ứng dụng một URI mà có thể gửi cho
người khác mà vẫn xem được đúng hình ảnh bản đồ mà mình đang xem. Nếu
không có khả năng đánh địa chỉ thì chúng ta không thể cho người khác xem bản
đồ mà mình đang xem.


Hình 1.7: Minh họa việc gửi địa chỉ
13


×