l

























ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ

HÀ QUANG HỒNG






KIẾN TRÚC DỊCH VỤ WEB-MÔ HÌNH CHẤT LƢỢNG
VÀ ÁP DỤNG CHO HỆ THỐNG TRẮC NGHIỆM
THEO CHUẨN QTI


Ngành: Công nghệ thông tin
Chuyên ngành: Công nghệ phần mềm
Mã số: 60480103




LUẬN VĂN THẠC SĨ
NGƢỜI HƢỚNG DẪN KHOA HỌC: PGS.TS. Nguyễn Đình Hóa






Hà Nội - 2014


2

LỜI CẢM ƠN

Trƣớc hết, tôi xin bày tỏ lòng cảm ơn sâu sắc tới thầy giáo PGS.TS. Nguyễn
Đình Hóa ngƣời đã định hƣớng và tận tình chỉ bảo cho tôi trong suốt thời gian làm
luận văn.
Tôi xin chân thành cảm ơn các thầy cô giáo khoa Công nghệ Thông tin, trƣờng
Đại học Công nghệ, Đại học Quốc gia Hà Nội, những ngƣời đã tận tình truyền đạt các
kiến thức, quan tâm, động viên trong suốt thời gian tôi học tập và nghiên cứu tại
Trƣờng;
Tôi cũng xin cảm ơn gia đình, cơ quan, bạn bè, đồng nghiệp đã cổ vũ động viên tôi
trong suốt thời gian học tập vừa qua. Tuy đã có nhiều cố gắng nhƣng do thời gian và trình
độ có hạn nên chắc chắn luận văn vẫn còn những thiếu sót và hạn chế nhất định. Kính
mong nhận đƣợc sự góp ý của thầy cô và các bạn để luận văn đƣợc hoàn thiện hơn.
Tôi xin chân thành cảm ơn!
Học viên



Hà Quang Hồng





3

LỜI CAM ĐOAN


Tôi xin cam đoan: Bản luận văn “Kiến trúc Web Service – Mô hình chất lƣợng
dịch vụ và áp dụng cho hệ thống trắc nghiệm theo chuẩn QTI” là công trình nghiên
cứu của tôi dƣới sự hƣớng dẫn khoa học của PGS.TS Nguyễn Đình Hóa, tham khảo
các nguồn tài liệu đã chỉ rõ trong trích dẫn và danh mục tài liệu tham khảo. Các nội
dung công bố và kết quả trình bày trong luận văn này là trung thực và chƣa từng đƣợc
ai công bố trong bất cứ công trình nào.

Học viên



Hà Quang Hồng

4

MỤC LỤC
LỜI CẢM ƠN 2
LỜI CAM ĐOAN 3
DANH MỤC CÁC HÌNH 7
DANH MỤC CÁC BẢNG 8
DANH MỤC CÁC TỪ VIẾT TẮT 9
GIỚI THIỆU 11
CHƢƠNG 1: CÔNG NGHỆ WEB SERVICE 13
1.1 Kiến trúc hƣớng dịch vụ SOA 13
1.1.1 Khái niệm kiến trúc hƣớng dịch vụ SOA 13
1.1.2 Nguyên tắc thiết kế của SOA 14
1.2 Công nghệ Web Service 14
1.2.1 Khái niệm dịch vụ Web 14
1.2.2 Đặc điểm của Web Service 14

1.2.3 Cơ chế hoạt động của Web Service 15
1.2.4 Kiến trúc phân tầng của Web Service 16
1.3 Các công nghệ của dịch vụ Web 18
1.3.1 Ngôn ngữ XML – RPC 18
1.3.2 Giao thức truyền thông điệp SOAP 18
1.3.2.1 Thông điệp XML 18
1.3.2.2 RPC và EDI 19
1.3.2.3 Thông điệp SOAP 19
1.3.2.4 SOAP Faults 20
1.3.2.5 Vận chuyển SOAP 21
1.3.3 Ngôn ngữ mô tả dịch vụ Web - WSDL 22
1.3.3.1 Khái niệm cơ bản về WSDL 22
1.3.3.2 Các thành phần của WSDL 22
1.3.4 Đăng ký dịch vụ UDDI 24
1.3.4.1 Khái niệm cơ bản về UDDI 24
1.3.4.2 Mô hình dữ liệu của UDDI 24
Chƣơng 2: MÔ HÌNH CHẤT LƢỢNG DỊCH VỤ WEB 26
2.1 Mô hình chất lƣợng dịch vụ Web 26
2.2 Các yếu tố chất lƣợng của dịch vụ Web 27
2.3 Liên kết chất lƣợng của dịch vụ Web 28
2.3.1 Ngƣời đặt hàng (Stakeholder) 29
5

2.3.2 Ngƣời phát triển (Developer) 29
2.3.3 Ngƣời cung cấp (Provider) 29
2.3.4 Ngƣời sử dụng (Consumer) 29
2.3.5 Ngƣời môi giới QoS (Broker) 30
2.3.6 Ngƣời đảm bảo chất lƣợng (Quality Assurer) 30
2.3.7 Ngƣời quản lý chất lƣợng(Quality Manager) 30
2.4 Hoạt động chất lƣợng của web service 31

2.5 Chất lƣợng đo ở mức dịch vụ 32
2.5.1 Khái niệm 32
2.5.2 Các yếu tố chất lƣợng con của chất lƣợng ở mức dịch vụ 32
Chƣơng 3: TỔNG QUAN VỀ CHUẨN IMS QTI 35
3.1 Tổng quan về IMS QTI (Question & Test Interoperability) 35
3.2 Các tài liệu trong đặc tả IMS QTI 36
3.2.1 Hƣớng dẫn thực hiện (Implementation Guide) 36
3.2.2 Mô hình thông tin (Information Model) 36
3.2.3 Siêu dữ liệu và dữ liệu sử dụng (Meta-data and Usage Data) 36
3.2.4 Hƣớng dẫn tích hợp (Intergration Guide) 36
3.2.5 XML Binding 36
3.2.6 Hƣớng dẫn phù hợp (Conformance Guide) 36
3.2.7 Hƣớng dẫn di chuyển(Migration Guide) 37
3.3 Các đối tƣợng cơ bản trong đặc tả IMS QTI 37
3.3.1 Item 37
3.3.2 Assessment 37
3.3.3 Section 37
3.3.4 Object-bank 37
3.3.5 Assessment-bank 38
3.4 Mô hình User Case: 38
3.4.1 Assessment: 39
3.4.2 assessmentItem: 40
Chƣơng 4: XÂY DỰNG MỘT SỐ DỊCH VỤ WEB TRONG HỆ THỐNG SÁT
HẠCH TRẮC NGHIỆM THEO CHUẨN QTI VÀ ĐO ĐẠC THÔNG SỐ
CHẤT LƢỢNG DỊCH VỤ WEB 41
4.1 Xây dựng một số dịch vụ web cung cấp tiện ích phục vụ trắc nghiệm bằng
máy tính theo chuẩn QTI 41
4.1.1 Tạo câu hỏi trắc nghiệm theo chuẩn QTI dạng một lựa chọn 41
4.1.2 Tạo câu hỏi trắc nghiệm theo chuẩn QTI dạng yes/no 41
6


4.1.3 Tạo câu hỏi trắc nghiệm theo chuẩn QTI dạng nhập văn bản 42
4.1.4 Kiểm tra phù hợp chuẩn QTI 42
4.1.5 Hiển thị nội dung câu hỏi lƣu trong tập tin xml (Hƣớng phát triển) 42
4.1.6 Đóng gói câu hỏi theo chuẩn IMS QTI (Hƣớng phát triển) 43
4.2 Xây dựng hệ thống sát hạch trắc nghiệm theo kiến trúc hƣớng dịch vụ 43
4.3 Sử dụng công cụ soapUI để đo chất lƣợng Web Service 44
4.3.1 Giới thiệu công cụ soapUI 44
4.3.2 Điều kiện kiểm thử chất lƣợng Web Service 45
4.3.3 Kiểm thử chức năng (Function Test) 49
4.3.4 Kiểm thử tải (Load Test) 50
KẾT LUẬN 56
TÀI LIỆU THAM KHẢO 57


7

DANH MỤC CÁC HÌNH

Hình 1. 1: Web Service cho phép truy cập tới các code ứng dụng 14
Hình 1. 2 Web Service cung cấp một tầng trừu tƣợng giữa 15
Hình 1. 3 Cơ chế hoạt động của dịch vụ Web 16
Hình 1. 4 Phân tầng công nghệ dịch vụ Web 16
Hình 1. 5 Mô tả cấu trúc của một thông điệp XML 19
Hình 1. 6 Mô tả cấu trúc của một thông điệp SOAP 20
Hình 1. 7 Mô tả việc trao đổi thông điệp SOAP thông qua giao thức HTTP 21

Hình 2. 1 Mô hình chất lƣợng web service 26
Hình 2. 2 Các yếu tố chất lƣợng Web Service 27
Hình 2. 3 Các liên kết chất lƣợng của web services 29


Hình 3. 1 Các thành phần tham gia hệ thống đặc tả IMS QTI 38
Hình 3. 2 Cấu trúc bài thi trong đặc tả IMS QTI 39

Hình 4. 1 Giao diện web service đã tạo 43
Hình 4. 2 Giao diện trang web phía client sử dụng webservice đã tạo 44
Hình 4. 3Kết quả kiểm thử tải của TestCase 1 49
Hình 4. 4 Kết quả kiểm thử tải của TestCase 2 50
Hình 4. 5 Sơ đồ kết quả kiểm thử tải của chức năng createSimpleChoice 51
Hình 4. 6 Sơ đồ kết quả kiểm thử tải của chức năng createTextQuestion 52
Hình 4. 7 Sơ đồ kết quả kiểm thử tải của chức năng createYesNoQuestion 53
Hình 4. 8 Sơ đồ kết quả kiểm thử tải của chức năng validateQti 54
Hình 4. 9 Sơ đồ kết quả kiểm thử tải của TestCase1 55

8

DANH MỤC CÁC BẢNG

Bảng 1. 1 Các thành phần chính trong tài liệu WSDL 22
Bảng 1. 2 Các kiểu thao tác đƣợc WSDL định nghĩa 23


Bảng 4. 1 Bảng kết quả kiểm thử tải của chức năng createSimpleChoice 51
Bảng 4. 2 Bảng kết quả kiểm thử tải của chức năng createTextQuestion 52
Bảng 4. 3 Bảng kết quả kiểm thử tải của chức năng createYesNoQuestion 53
Bảng 4. 4 Bảng kết quả kiểm thử tải của chức năng validateQti 54
Bảng 4. 5 Bảng kết quả kiểm thử tải của TestCase1 55
9

DANH MỤC CÁC TỪ VIẾT TẮT


STT
Viết tắt
Viết đầy đủ
Ý nghĩa
1
API
Application Programming
Interface
Giao diện lập trình ứng dụng
2
CORBA
Common Object Request
Broker Architecture
Kiến trúc môi giới yêu cầu đối
tƣợng chung
3
DARPA
Defense Advanced Research
Projects Agency
Cơ quan các dự án nghiên cứu
quốc phòng tiên tiến
4
DCOM
Distributed Component
Object Model
Mô hình đối tƣợng thành phần
phân tán
5
EDI

Electronic Document
Interchange
Trao đổi tài liệu điện tử
6
HTML
HyperText Markup Language
Ngôn ngữ đánh dấu siêu văn
bản
7
IEEE
Institute of Electrical and
Electronics Engineers
Viện kĩ nghệ điện và điện tử
8
IETF
Internet Engineering Task
Force
Nhóm đặc trách kĩ thuật
Internet
9
LCMS
Learning Content
Management System
Hệ Quản trị nội dung học tập
10
LMS
Learning Management
System
Hệ Quản trị học tập
11

LOM
Learning Object Metadata
Siêu dữ liệu đối tƣợng học tập
12
NASSL
Network Accessible Service
Specification Language
Ngôn ngữ đặc tả dịch vụ có thể
truy cập mạng
13
OASIS
Organization Advancing
Open Standards for the
Information Society
Tổ chức thúc đẩy các tiêu chuẩn
mở cho xác hội thông tin
14
QoS
Quality of Service
Chất lƣợng dịch vụ
15
QTI
Question & Test
Interoperability
Câu hỏi và bài kiểm tra có khả
năng tƣơng tác
16
RDF
Resource Desciption
Framework

Framework mô tả nguồn tài
nguyên
17
RPC
Remote Procedure Call
Thủ tục gọi từ xa
18
SCORM
Sharable Content Object
Reference Model
Mô hình tham khảo đối tƣợng
có thể chia sẻ nội dung
19
SOA
Service Oriented Architecture
kiến trúc hƣớng dịch vụ
10

20
SOAP
Simple Object Access
Protocol
Giao thức truy cập đối tƣợng
đơn giản
21
TCP/IP
Transmission Control
Protocol / Internet Protocol
Giao thức điều khiển truyền
dẫn/giao thức Internet

22
UDDI
Universal Description,
Discovery and Integration
Tích hợp, khám phá và mô tả đa
năng
23
W3C
World Wide Web Consortium
Là một tổ chức lập ra các chuẩn
cho các công nghệ chạy trên
nền Internet, đặc biệt là Word
Wide Web
24
WDS
Web Defined Service
Dịch vụ định nghĩa Web
25
WSDL
Web Services Description
Language (IBM/Microsoft)
Ngôn ngữ mô tả dịch vụ Web
26
XML
eXtensible Markup Language
Ngôn ngữ đánh dấu có thể mở
rộng
11

GIỚI THIỆU


Kiến trúc hƣớng dịch vụ nói chung và dịch vụ Web nói riêng là một mô hình phát
triển ứng dụng Web tiên tiến, cho phép xây dựng một hệ thống hoàn chỉnh từ nhiều
thành phần dịch vụ khác nhau. Tuy nhiên, hiệu năng của hệ thống tổng thể phụ thuộc
rất nhiều vào chất lƣợng của từng dịch vụ thành phần. Đã có nhiều nghiên cứu đề cập
đến mô hình chất lƣợng dịch vụ web (Web Services Quality Model), thỏa thuận chất
lƣợng ở mức dịch vụ và đo lƣờng đánh giá chất lƣợng dịch vụ web.
Trong lĩnh vực giáo dục đào tạo, các ứng dụng web rất hữu ích vì tính tiện lợi và
phổ biến của công nghệ web. Nhiều hệ thống eLearning là ứng dụng trên nền web.
Việc đánh giá kết quả học tập cũng đƣợc thực hiện thông qua ứng dụng web. Nhiều hệ
thống sát hạch trắc nghiệm bằng máy tính đã đƣợc xây dựng. Tƣơng tự nhƣ chuẩn
SCORM đối với các hệ thống eLearning quản trị học tập, nội dung học tập
(LMS/LCMS), chuẩn IMS QTI nhằm tạo điều kiện thuận lợi để chia sẻ nguồn tài
nguyên câu hỏi và bài thi trắc nghiệm giữa các hệ thống sát hạch bằng máy tính.
Chúng tôi chọn đề tài: “Kiến trúc dịch vụ web – Mô hình chất lƣợng và áp dụng
cho hệ thống sát hạch trắc nghiệm theo chuẩn QTI” với mục tiêu nghiên cứu về đánh
giá hiệu năng của hệ thống sát hạch trắc nghiệm bằng máy tính dựa trên kiến trúc web
services. Nội dung nghiên cứu cần thực hiện là tìm hiểu về kiến trúc web services, các
mô hình chất lƣợng dịch vụ web và cách sử dụng phần mềm soapUI để đo lƣờng tham
số, đánh giá chất lƣợng dịch vụ. Nội dung thực hành sẽ là thử nghiệm áp dụng cho một
số dịch vụ web liên quan đến sát hạch trắc nghiệm bằng máy tính theo chuẩn QTI.
Bố cục của luận văn đƣợc trình bày nhƣ sau:
GIỚI THIỆU
Đặt vấn đề về ý nghĩa, tính cấp thiết và tính thực tế của đề tài.
CHƢƠNG 1: CÔNG NGHỆ DỊCH VỤ WEB
Chƣơng này trình bày về kiến trúc hƣớng dịch vụ SOA, tập trung vào tìm hiểu
công nghệ Web service, các thành phần kiến trúc của Web Service cũng nhƣ các lợi
ích khi sử dụng công nghệ này. Sau đó đi sâu tìm hiểu mô hình và các chuẩn công
nghệ áp dụng trong vòng đời của dịch vụ Web, từ bƣớc phát triển cho đến bƣớc xuất
bản, sẵn sàng cung cấp dịch vụ.

CHƢƠNG 2: MÔ HÌNH CHẤT LƢỢNG DỊCH VỤ WEB VÀ ĐO LƢỜNG
CÁC YẾU TỐ CHẤT LƢỢNG
Chƣơng này trình bày mô hình chất lƣợng dịch vụ Web (WSQM) do tổ chức
OASIS [8] đƣa ra, đây là mô hình chất lƣợng dịch vụ đang đƣợc sử dụng phổ biến nhất
hiện nay trên thế giới và là tài liệu cực kỳ hữu ích cho những ai quan tâm đến vấn đề
chất lƣợng web service (ngƣời phát triển, ngƣời sử dụng, ngƣời giám sát và ngƣời
12

quản trị chất lƣợng dịch vụ ) cũng nhƣ là tài liệu quý giá cho những ai muốn phát
triển các công cụ đo và giám sát chất lƣợng Web Service vì WSQM là tài liệu toàn
diện và có hệ thống về chất lƣợng dịch vụ web từ nhiều khung nhìn khác nhau mà
đƣợc sử dụng bởi các bên liên quan mật thiết.
CHƢƠNG 3: TỔNG QUAN VỀ CHUẨN IMS QTI
Chƣơng này trình bày tổng quan về chuẩn IMS QTI, lợi ích của việc sử dụng chuẩn
IMS QTI, đi sâu vào phân tích các đối tƣợng cơ bản trong chuẩn IMS QTI và cấu trúc
của AssessmentItem (Câu hỏi), Assessment (bài kiểm tra), là những nội dung kiến
thức quan trọng cần hiểu rõ khi muốn xây dựng hệ thống sát hạch trắc nghiệm theo
chuẩn IMS QTI.
CHƢƠNG 4: XÂY DỰNG MỘT SỐ DỊCH VỤ WEB TRONG HỆ THỐNG
SÁT HẠCH TRẮC NGHIỆM THEO CHUẨN QTI VÀ ĐO ĐẠC THÔNG SỐ
CHẤT LƢỢNG
Chƣơng này trình bày việc xây dựng một số dịch vụ web có thể sử dụng trong
hệ thống sát hạch trắc nghiệm bằng máy tính theo chuẩn IMS QTI và với mục tiêu
nâng cao hiệu năng hệ thống tổng thể, chúng tôi sẽ thử nghiệm việc áp dụng mô hình
chất lƣợng dịch vụ web, đo lƣờng tham số, đánh giá chất lƣợng dịch vụ cho một số
dịch vụ đã tạo ra bằng công cụ soapUI.
Phần kết luận, tóm tắt các kết quả đã đạt đƣợc và gợi mở những hƣớng nghiên cứu
tiếp theo.



13

CHƢƠNG 1: CÔNG NGHỆ WEB SERVICE


Chương này bắt đầu bằng việc trình bày về kiến trúc hướng dịch vụ SOA, tập trung
vào tìm hiểu công nghệ Web service, các thành phần kiến trúc của Web Service cũng
như các lợi ích khi sử dụng công nghệ này. Sau đó đi sâu tìm hiểu mô hình và các
chuẩn công nghệ áp dụng trong vòng đời của dịch vụ Web, từ bước phát triển cho đến
bước xuất bản, sẵn sàng cung cấp dịch vụ.

1.1 Kiến trúc hƣớng dịch vụ SOA
1.1.1 Khái niệm kiến trúc hƣớng dịch vụ SOA
SOA - viết tắt của thuật ngữ Service Oriented Architecture (kiến trúc hƣớng dịch
vụ) là “Khái niệm về hệ thống trong đó mỗi ứng dụng đƣợc xem nhƣ một nguồn cung
cấp dịch vụ” [10].
Dịch vụ là yếu tố then chốt trong SOA. Có thể hiểu dịch vụ nhƣ là hàm chức năng
(module phần mềm) thực hiện quy trình nghiệp vụ nào đó, một cách cơ bản, SOA là
tập hợp các dịch vụ kết nối mềm dẻo với nhau (nghĩa là một ứng dụng có thể nói
chuyện với một ứng dụng khác mà không cần biết các chi tiết kĩ thuật bên trong), có
giao tiếp (dùng để gọi hàm dịch vụ) đƣợc định nghĩa rõ ràng và độc lập với nền tảng
hệ thống, và có thể tái sử dụng. SOA là cấp độ cao hơn của phát triển ứng dụng, chú
trọng đến quy trình nghiệp vụ và dùng giao tiếp chuẩn để giúp che đi sự phức tạp của
kĩ thuật bên dƣới.
Thiết kế SOA tách riêng phần thực hiện dịch vụ (phần mềm) với giao tiếp gọi dịch
vụ. Điều này tạo nên một giao tiếp nhất quán cho ứng dụng khách sử dụng dịch vụ bất
chấp công nghệ thực hiện dịch vụ. Thay vì xây dựng các ứng dụng đơn lẻ và đồ sộ,
nhà phát triển sẽ xây dựng các dịch vụ có tính linh hoạt có thể triển khai và tái sử dụng
trong toàn bộ quy trình nghiệp vụ. Điều này cho phép tái sử dụng phần mềm tốt hơn,
cũng nhƣ tăng sự linh hoạt vì nhà phát triển có thể cải tiến dịch vụ mà không làm ảnh

hƣởng đến khách hàng sử dụng dịch vụ.
Thực ra khái niệm SOA không hoàn toàn mới. DCOM và CORBA cũng có kiến
trúc tƣơng tự. Tuy nhiên các kiến trúc cũ ràng buộc các thành phần với nhau quá chặt,
ví dụ các ứng dụng phân tán muốn làm việc với nhau phải đạt đuợc thoả thuận về chi
tiết tập hàm API, một thay đổi mã lệnh trong thành phần COM sẽ yêu cầu những thay
đổi tƣơng ứng đối với mã lệnh truy cập thành phần COM này.
Ƣu điểm quan trọng nhất của SOA là khả năng kết nối mềm dẻo (nhờ sự chuẩn hoá
giao tiếp) và tái sử dụng. Các dịch vụ có thể đƣợc sử dụng với trình khách chạy trên
nền tảng bất kì và đƣợc viết bởi ngôn ngữ bất kì.
14

1.1.2 Nguyên tắc thiết kế của SOA
SOA dựa trên hai nguyên tắc thiết kế quan trọng [9]:
 Mô-đun: đó là tách các vấn đề lớn thành nhiều vấn đề nhỏ hơn.
 Đóng gói: che đi dữ liệu và lô-gic trong từng mô-đun đối với các truy cập từ
bên ngoài.
Hai tính chất này sẽ dẫn đến đặc điểm thiết kế của kiến trúc SOA đó là các dịch vụ
tƣơng tác với nhau qua các thành phần giao tiếp. Tuy nhiên các dịch vụ đó vẫn hoạt
động độc lập với nhau, chia sẻ các lƣợc đồ dữ liệu cho nhau và tuân thủ các chính sách
của kiến trúc chung nhất.
1.2 Công nghệ Web Service
1.2.1 Khái niệm dịch vụ Web
Web Service là một giao diện truy cập mạng đến các ứng dụng chức năng, đƣợc
xây dựng từ việc sử dụng các công nghệ chuẩn Internet [7]. Đƣợc minh hoạ trong hình
dƣới đây.







1.2.2 Đặc điểm của Web Service
Web Service cho phép các ứng dụng khác nhau từ các nguồn khác nhau có thể
giao tiếp với các ứng dụng khác mà không đòi hỏi nhiều thời gian viết mã. Do tất cả
các quá trình giao tiếp đều tuân theo định dạng XML, cho nên dịch vụ Web không bị
phụ thuộc vào bất kì hệ điều hành hay ngôn ngữ lập trình nào. Web Service cho phép
phía khách và phía chủ có thể tƣơng tác đƣợc với nhau trên các nền tảng khác nhau mà
không cần bất cứ thay đổi hay yêu cầu đặc biệt nào. Ví dụ, chƣơng trình viết bằng
ngôn ngữ Java cũng có thể trao đổi dữ liệu với các chƣơng trình viết bằng Perl; các
ứng dụng chạy trên nền Windows cũng có thể trao đổi dữ liệu với các ứng dụng chạy
trên nền Linux. Công nghệ dịch vụ Web không yêu cầu phải sử dụng trình duyệt và
ngôn ngữ HTML, đôi khi Web Service còn đƣợc gọi là Application Services.
Phần lớn kỹ thuật của Web Service đƣợc xây dựng trên mã nguồn mở và đƣợc
phát triển từ các chuẩn đã đƣợc công nhận. Nó tích hợp các ứng dụng trên nền web lại
với nhau bằng cách sử dụng các công nghệ XML, SOAP, WSDL và UDDI trên nền
tảng các giao thức Internet với mục tiêu tích hợp ứng dụng và truyền thông điệp. XML
đƣợc sử dụng để đánh dấu dữ liệu; SOAP đƣợc dùng để truyền dữ liệu; WSDL đƣợc
sử dụng để mô tả các dịch vụ có sẵn và UDDI đƣợc sử dụng để liệt kê những dịch vụ
nào hiện tại đang có sẵn để có thể sử dụng. Web Service cho phép các tổ chức có thể
Hình 1. 1: Web Service cho phép truy cập tới các code ứng dụng
15

trao đổi dữ liệu với nhau mà không cần phải có kiến thức hiểu biết về hệ thống thông
tin đứng ở phía sau các tƣờng lửa [7].
Web Service có thể gồm nhiều mô đun và đƣợc công bố trên Internet. Nó là sự kết
hợp của việc phát triển hƣớng thành phần với những lĩnh vực cụ thể và cở sở hạ tầng
Web, mang lại lợi ích cho cả doanh nghiệp, khách hàng, những nhà cung cấp dịch vụ
khác cũng nhƣ các cá nhân thông qua mạng Internet.
Web Service khi đƣợc triển khai sẽ hoạt động theo mô hình khách-chủ. Nó có thể
đƣợc triển khai bởi một phần mềm ứng dụng phía máy chủ nhƣ PHP, JSP, ASP.NET,

… Không giống nhƣ mô hình khách-chủ truyền thống, chẳng hạn nhƣ hệ thống máy
chủ Web – trang web, Web Service không cung cấp cho ngƣời dùng một giao diện đồ
hoạ nào. Web Service đơn thuần chỉ là việc chia sẻ các dữ liệu và logic xử lý các dữ
liệu đó thông qua một giao diện chƣơng trình ứng dụng đƣợc cài đặt xuyên suốt trên
mạng máy tính. Tuy nhiên nguời phát triển Web Service hoàn toàn có thể đƣa Web
Service vào một giao diện đồ hoạ ngƣời dùng (chẳng hạn nhƣ là một trang web hoặc
một chƣơng trình thực thi nào đó) để có thể cung cấp thêm các chức năng đặc biệt cho
ngƣời dùng.
Nhƣ Hình 1.1 và Hình 1.2 đã minh họa, Web Service là một giao diện ứng dụng
đƣợc đặt giữa mã lệnh của ứng dụng và ngƣời sử dụng các mã lệnh đó. Nó có thể đƣợc
ví nhƣ một tầng trừu tƣợng, phân tách giữa nền tảng hệ thống và ngôn ngữ lập trình.
Nó mô tả cách thức mà các mã lệnh ứng dụng đƣợc triệu gọi nhƣ thế nào. Điều này có
nghĩa nếu bất kì một ngôn ngữ lập trình nào hỗ trợ Web Service đều có thể truy cập
các chức năng ứng dụng của nhau.






Tính tƣơng thích (Inteoperability) là một lợi thế vô cùng mạnh mẽ của dịch vụ
Web. Thông thƣờng, các công nghệ Java và công nghệ của Microsoft rất khó có thể
tích hợp đƣợc với nhau, nhƣng với dịch vụ Web thì các ứng dụng và trình khách sử
dụng 2 công nghệ trên hoàn toàn có khả năng tƣơng tác với nhau thông qua dịch vụ
Web. Nhiều nhà cung cấp ứng dụng nhƣ IBM và Microsoft đều đã hỗ trợ dịch vụ Web
trong các sản phẩm của họ. IBM hỗ trợ dịch vụ Web thông qua gói WebSphere, Tivoli,
Lotus và DB2 và Microsoft cũng đã hỗ trợ dịch vụ Web với .NET.
1.2.3 Cơ chế hoạt động của Web Service
Cơ chế hoạt động của dịch vụ Web yêu cầu phải có 3 thao tác đó là: Tìm kiếm
(Find), Xuất bản (Public), Kết buộc (Bind) [7].

Hình 1. 2 Web Service cung cấp một tầng trừu tƣợng giữa
ứng dụng client và ứng dụng cần gọi tới
16

Trong kiến trúc dịch vụ Web, bên cung cấp dịch vụ (Service Provider) công bố các
mô tả về các dịch vụ thông qua Đăng ký dịch vụ (Service Registry). Bên tiêu dùng
dịch vụ (Service Consumer) tìm kiếm trong các Đăng ký dịch vụ để tìm ra các dịch vụ
mà họ cần sử dụng. Bên tiêu dùng dịch vụ có thể là một ngƣời hoặc cũng có thể là một
chƣơng trình.

Hình 1. 3 Cơ chế hoạt động của dịch vụ Web

Kĩ thuật mô tả dịch vụ là một trong những thành phần chủ chốt của kiến trúc dịch
vụ Web. Các thông tin mô tả đầy đủ nhất về kiến trúc dịch vụ Web đƣợc thể hiện trong
hai tài liệu riêng biệt, đó là NASSL (Network Accessible Service Specification
Language) và WDS (Web Defined Service) NASSL là một tài liệu XML tiêu chuẩn
cho các dịch vụ chạy trên nền mạng. Nó đƣợc sử dụng để chỉ ra các thông tin hoạt
động của dịch vụ Web, chẳng hạn nhƣ danh sách các dịch vụ, các mô tả dịch vụ, ngày
hết hạn của dịch vụ và các thông tin liên quan đến các bên cung cấp dịch vụ nhƣ tên,
địa chỉ. Tài liệu WDS là một tài liệu bổ sung cho NASSL. Khi kết hợp hai tài liệu này
với nhau, ta sẽ có đƣợc mô tả một cách đầy đủ về các dịch vụ để cho phía yêu cầu dịch
vụ có thể dễ dàng tìm kiếm và gọi các dịch vụ đó.
1.2.4 Kiến trúc phân tầng của Web Service
Mô hình kiến trúc phân tầng của dịch vụ Web tƣơng tự với mô hình TCP/IP đƣợc
sử dụng để mô tả kiến trúc Internet [7] :










Hình 1. 4 Phân tầng công nghệ dịch vụ Web
17

Các tầng truyền thống nhƣ Đóng gói (Packaging), Mô tả (Description), và Phát
hiện (Discovery) trong mô hình tầng công nghệ dịch vụ Web là những tầng cung cấp
khả năng tích hợp và cần thiết cho mô hình ngôn ngữ lập trình trung lập.
Tầng Phát hiện (Discovery): Cung cấp cơ chế để cho ngƣời dùng có khả năng lấy
các thông tin mô tả về các bên cung cấp dịch vụ. Công nghệ đƣợc sử dụng tại tầng này
chính là UDDI – Universal Description, Discovery and Integration.
Tầng Mô tả (Description): Khi dịch vụ Web đƣợc thực thi, nó cần phải đƣa ra
các quyết định về các giao thức trên các tầng Mạng (Network), Vận chuyển
(Transport), Đóng gói (Packaging) mà nó sẽ hỗ trợ trong quá trình thực thi. Các mô tả
dịch vụ sẽ đƣa ra phƣơng pháp, làm thế nào để bên tiêu dùng dịch vụ có thể liên kết và
sử dụng các dịch vụ đó. Tại tầng Mô tả, công nghệ đƣợc sử dụng ở đây chính là
WSDL (Web Service Desciption Language – Ngôn ngữ mô tả dịch vụ Web). Ngoài ra,
ít phổ biến hơn, chúng ta còn có 2 ngôn ngữ khác đƣợc định nghĩa bởi tổ chức W3C.
Đó là ngôn ngữ mô tả tài nguyên RDF (Resource Desciption Framework) và ngôn ngữ
đánh dấu sự kiện DARPA. Cả hai ngôn ngữ này đều có khả năng cung cấp mô tả dịch
vụ Web mạnh hơn ngôn ngữ WSDL. Tuy nhiên do tính phức tạp của chúng nên không
đƣợc phát triển rộng rãi.
Tầng Đóng gói (Packaging): Việc thực hiện vận chuyển các dữ liệu dịch vụ Web
đƣợc thực hiện bởi tầng Vận chuyển. Tuy nhiên trƣớc khi đƣợc vận chuyển, các dữ
liệu cần phải đƣợc đóng gói lại theo các định dạng đã định trƣớc để các thành phần
tham gia vào mô hình dịch vụ Web có thể hiểu đƣợc. Việc đóng gói dữ liệu đƣợc thực
thi bởi tầng Đóng gói. Đóng gói dữ liệu bao gồm việc định dạng dữ liệu, mã hóa các
giá trị đi kèm dữ liệu đó và các công việc khác.

Các dữ liệu có thể đƣợc đóng gói dƣới dạng các tài liệu HTML, tuy nhiên tài liệu
HTML thƣờng không thuận tiện cho yêu cầu này bởi vì HTML chỉ mạnh trong việc
thể hiện dữ liệu hơn là trình bày ý nghĩa dữ liệu đó. XML là một định dạng cơ bản
nhất cho việc trình bày ý nghĩa dữ liệu. Do đó XML có thể đƣợc sử dụng để trình bày
ý nghĩa dữ liệu đƣợc vận chuyển, và hơn thế nữa, hiện tại đa số các ứng dụng chạy
trên nền Web đều hỗ trợ các bộ phân tích cú pháp XML.
SOAP là công nghệ chủ yếu đƣợc sử dụng tại tầng này. Nó là một giao thức đóng
gói dữ liệu phổ biến dựa trên nền tảng XML.
Tầng Vận chuyển (Transport): có vai trò đảm nhiệm việc vận chuyển các thông
điệp dịch vụ Web. Ở đây có vài công nghệ khác nhau cho phép giao tiếp trực tiếp ứng
dụng – tới – ứng dụng dựa trên tầng Mạng. Mỗi công nghệ bao gồm các giao thức nhƣ
tcp, http, smtp và jabber v.v.
Việc lựa chọn giao thức vận chuyển dựa trên từng nhu cầu giao tiếp của các dịch
vụ Web. Ví dụ, giao thức HTTP là một giao thức vận chuyển khá phổ biến đƣợc sử
dụng cho các ứng dụng trên nền Web, nhƣng nó không cung cấp cơ chế giao tiếp bất
18

đối xứng. Jabber, xét trên phƣơng diện khác, nó không phải là một chuẩn nhƣng có
khả năng cung cấp tốt các kênh giao tiếp bất đối xứng.
Tầng Mạng (Network): Trong công nghệ dịch vụ Web tầng Mạng chính xác giống
nhƣ tầng Mạng trong mô hình giao thức TCP/IP. Nó cung cấp khả năng giao tiếp cơ
bản, định địa chỉ và định tuyến.
1.3 Các công nghệ của dịch vụ Web
1.3.1 Ngôn ngữ XML – RPC
 XML : đƣợc viết tắt của cụm từ Extensible Markup Language – Ngôn ngữ
đánh dấu dữ liệu.
 RPC – đƣợc viết tắt của cụm từ Remote Procedure Call – Thủ tục gọi từ xa.
RPC cung cấp cho ngƣời phát triển kĩ thuật để định nghĩa ra một giao diện mà
có thể đƣợc gọi từ xa thông qua môi trƣờng mạng máy tính. Giao diện này có
thể là một hàm đơn giản nhƣng cũng có thể là một thƣ viện API khổng lồ.

 XML – RPC là một hƣớng tiếp cận dễ và rõ ràng nhất cho Web Service, nó
cung cấp phƣơng thức gọi một ứng dụng từ một máy tính local đến một máy
tính từ xa thông qua môi trƣờng mạng.
 XML – RPC cho phép chƣơng trình có khả năng tạo ra các hàm hoặc các thủ
tục gọi hàm thông qua mạng máy tính.
 XML – RPC sử dụng giao thức HTTP để vận chuyển thông tin từ Client đến Server.
 XML – RPC sử dụng ngôn ngữ XML để mô tả các thông điệp yêu cầu và các
thông điệp đáp ứng gần gũi với ngôn ngữ tự nhiên.
 XML – RPC Client chỉ ra cụ thể các thông tin về tên thủ tục, các tham
biến trong thông điệp XML request, và Server trả về lỗi hoặc trả về thông điệp
response trong thông điệp XML response.
 Các tham số của XML-RPC đơn giản chỉ là kiểu dữ liệu và nội dung, tuy nhiên
các cấu trúc dữ liệu phức tạp nhƣ struct, array cũng đƣợc hỗ trợ bởi XML –RPC
1.3.2 Giao thức truyền thông điệp SOAP
SOAP viết tắt cho cụm từ - Simple Object Access Protocol nghĩa là giao thức truy
cập đối tƣợng đơn giản. Trong kiến trúc phân tầng của dịch vụ Web, SOAP nằm ở
tầng đóng gói (Packaging). SOAP là một giao thức đóng gói các dữ liệu chia sẻ chung
giữa các ứng dụng. Xét về cơ bản, SOAP là XML hay nói chính xác hơn SOAP là một
ứng dụng cụ thể của XML, đƣợc xây dựng lên từ các chuẩn XML nhƣ XML Schema
và XML Namespaces. Ứng dụng cụ thể này phục vụ cho việc định nghĩa SOAP và các
chức năng của nó [7]. Các thành phần cơ bản của SOAP gồm có:
1.3.2.1 Thông điệp XML
XML : viết tắt của cụm từ Extensible Markup Language – Ngôn ngữ đánh dấu mở
rộng đƣợc. Thông điệp XML là các tài liệu XML đƣợc dùng để trao đổi thông tin
19

giữa các ứng dụng. Nó cung cấp tính mềm dẻo cho các ứng dụng trong quá trình giao
tiếp với nhau và là một dạng cơ bản của SOAP.
Các thông điệp này có thể là bất cứ thứ gì: Hóa đơn thanh toán, yêu cầu về giá
cổ phiếu, một truy vấn tới một công cụ tìm kiếm hoặc có thể là bất kì thông tin nào có

quan hệ tới từng thành phần của ứng dụng.





Bởi vì XML không phụ thuộc vào một ứng dụng cụ thể, hệ điều hành hay ngôn ngữ
lập trình nào, cho nên các thông điệp XML có thể sử dụng trong tất cả các môi trƣờng.
Một chƣơng trình Windows Perl có thể tạo ra một thông điệp XML, trình bày thông
điệp đó và gửi đến cho một chƣơng trình cài đặt bằng ngôn ngữ Java đƣợc triển khai
trên nền Unix.
1.3.2.2 RPC và EDI
Sử dụng thông điệp XML, đƣơng nhiên SOAP có 2 ứng dụng liên quan: RPC và
EDI. Thủ tục gọi hàm từ xa RPC (Remote Procedure Call) là một dạng tính toán phân
tán cơ bản, mô tả cách thức để một chƣơng trình tạo ra một thủ tục gọi hàm hoặc
phƣơng thức tới một máy tính khác, truyền đối số và lấy giá trị trả về. Trao đổi tài liệu
điện tử EDI (Electronic Document Interchange) là một dạng transaction cơ bản cho
quy trình thƣơng mại nó định nghĩa các chuẩn định dạng và thông dịch của các tài
liệu, thông điệp tài chính và thƣơng mại.
Nếu sử dụng SOAP cho EDI, khi đó thông điệp XML có thể là các hóa đơn thanh
toán, trả tiền thuế, hoặc các tài liệu tƣơng tự. Nếu sử dụng SOAP cho RPC khi đó
thông điệp XML có thể trình bày các đối số hoặc các giá trị trả về.
1.3.2.3 Thông điệp SOAP
Thông điệp SOAP bao gồm phần tử gốc envelope bao trùm toàn bộ nội dung thông
điệp SOAP, và các phần tử header và body. Phần tử header chứa các khối thông tin có
liên quan đến cách thức các thông điệp đƣợc xử lý nhƣ thế nào. Nó bao gồm việc định
tuyến và các thiết lập cho việc phân phối các thông điệp. Ngoài ra phần tử Header còn
có thể chứa các thông tin về việc thẩm định quyền, xác minh và các ngữ cảnh cho các
transaction. Các dữ liệu thực sự đƣợc lƣu trữ tại phần tử body. Bất cứ thứ gì có thể
trình bày cú pháp XML đều nằm trong phần tử body của một thông điệp SOAP[7].

Hình 1. 5 Mô tả cấu trúc của một thông điệp XML
20











Tất cả các phần tử envelope đều chứa chính xác một phần tử body. Phần tử body có
thể chứa các nốt con theo yêu cầu. Nội dung của phần tử body là các thông điệp. Nếu
phần tử envelope mà chứa phần tử header, nó chỉ chứa không nhiều hơn một phần tử
header và phần tử header này bắt buộc phải là phần tử con đầu tiên của phần tử
envelope. Mỗi một phần tử chứa header đều đƣợc gọi là header block. Mục đích của
header block cung cấp giao tiếp các thông tin theo ngữ cảnh có liên quan đến quy trình
xử lý các thông điệp SOAP.
1.3.2.4 SOAP Faults
SOAP faults là một dạng thông điệp SOAP đặc biệt đƣợc dùng để thông báo lỗi
trong quá trình trao đổi thông tin, SOAP faults có thể xuất hiện trong quá trình xử lý
các thông điệp SOAP [7].













Các thông tin về SOAP faults đƣợc diễn tả dƣới đây:
 Fault code: Các thuật toán phát hiện lỗi sẽ tự sinh ra các giá trị dùng để phân
biệt các kiểu lỗi xuất hiện. Các giá trị này phải là các XML Qualified Name,
Hình 1. 6 Mô tả cấu trúc của một thông điệp SOAP
<s:Envelop xmlns:s= “ ”>
<s:Body>
<s:Fault>
<faultcode>Client.Authentication</faultcode>
<faultstring>
Invalid credentials
</faultstring>
<faultactor></faultactor>
<details>
<!- - application specific details >
</details>
</s:Fault>
</s: Body>
</s:Envelope>
21

điều đó có nghĩa là các tên của các mã lỗi chỉ có ý nghĩa duy nhất trong vùng
định nghĩa XML Namespace.
 Fault string: Diễn tả các lỗi mà ngƣời dùng có thể đọc hiểu đƣợc.
 Fault actor: Đây là dấu hiệu nhận dạng duy nhất của các nốt xử lý các thông

điệp nơi mà các lỗi có khả năng xuất hiện.
 Fault details: Đƣợc sử dụng để trình bày các thông tin cụ thể của ứng dụng về
lỗi mà nó xuất hiện. Nó phải đƣợc trình bày nếu có lỗi xuất hiện trực tiếp có
liên quan đến các vấn đề về phần thân của thông điệp. Fault details có thể
không cần sử dụng, tuy nhiên sẽ cần thiết khi ta cần trình bày cụ thể về thông
tin lỗi xuất hiện trong mối quan hệ tới các phần còn lại của quy trình xử lý các
thông điệp SOAP.
1.3.2.5 Vận chuyển SOAP
SOAP nằm ở tầng đóng gói (Packaging) trong kiến trúc phân tầng của dịch vụ
Web. SOAP nằm trên tầng Mạng (Network) và tầng Vận chuyển (Transport). Vì thế
SOAP không quan tâm đến việc giao thức vận chuyển nào đƣợc sử dụng trong quá
trình trao đổi các thông điệp. Điều đó làm cho giao thức thực sự mềm dẻo tại bất kì
môi trƣờng triển khai SOAP nào. Tính mềm dẻo của SOAP đƣợc thể hiện qua việc
SOAP có thể sử dụng các giao thức vận chuyển khác nhau để trao đổi các thông điệp
nhƣ HTTP, FTP, SMTP, POP3, MQUERY và Jabber [7].
Hiện nay, HTTP là giao thức đƣợc sử dụng phổ biến trên Internet. Chính vì thế
nên HTTP hiện tại đang là giao thức vận chuyển phổ biến nhất cho việc vận chuyển
các thông điệp SOAP.
SOAP thông qua HTTP rất thuận tiện cho SOAP RPC trong việc gọi yêu cầu và
nhận các thông điệp đáp ứng bởi vì bản chất HTTP chính là giao thức dựa trên nền
tảng gọi các yêu cầu và nhận các đáp ứng (request-response-base protocol). Các thông
điệp yêu cầu (request) đƣợc gửi tới máy chủ HTTP dùng phƣơng thức POST và máy
chủ HTTP trả lại thông điệp đáp ứng (response) dùng các HTTP response.









Hình 1. 7 Mô tả việc trao đổi thông điệp SOAP thông qua giao thức HTTP
22

1.3.3 Ngôn ngữ mô tả dịch vụ Web - WSDL
1.3.3.1 Khái niệm cơ bản về WSDL
WSDL là viết tắt của cụm từ dịch vụ Web Service Description Language – Ngôn
ngữ mô tả dịch vụ Web. WSDL ra đời dƣới sự phát triển của IBM và Microsoft.
WSDL dựa trên giao thức XML để trao đổi thông tin trong môi trƣờng tập trung
hoặc phân tán.
WSDL mô tả cách thức truy cập tới dịch vụ Web và các hành động thực thi trên
dịch vụ Web đó.
WSDL là ngôn ngữ cho việc mô tả các giao diện dịch vụ Web dựa trên nền tảng
XML.
WSDL là ngôn ngữ mà UDDI sử dụng.
1.3.3.2 Các thành phần của WSDL
Một tài liệu WSDL thƣờng bao gồm các thành phần chính sau đây:








Giải thích ý nghĩa các thành phần:
Type : Thành phần type định nghĩa kiểu dữ liệu đƣợc sử dụng cho dịch vụ Web. Để
đảm bảo tính không phụ thuộc vào hệ thống nền, WSDL sử dụng cấu trúc của lƣợc đồ
XML để định nghĩa kiểu dữ liệu.
Message : Thành phần message dùng để định nghĩa các thành phần dữ liệu và các

thông điệp mà nó đƣợc gọi tới. Mỗi thông điệp có thể bao gồm một hoặc nhiều phần,
các thành phần này có thể so sánh với các câu lệnh của các lời gọi hàm trong các ngôn
ngữ lập trình truyền thống.
Port Type : Đây là thành phần quan trọng nhất trong một tài liệu WSDL. Nó đƣợc
sử dụng để mô tả dịch vụ Web, các thao tác đƣợc thực thi và các lời gọi thông điệp.
Thành phần port type có thể đƣợc so sánh với các thƣ viện hàm (hoặc các mô đun, các
lớp) trong các ngôn ngữ lập trình.
Trong thành phần <port Type>, ta thƣờng gặp 4 kiểu thao tác đƣợc WSDL định
nghĩa dƣới đây:




Thành phần
Mô tả
<type>
Định nghĩa kiểu dữ liệu đƣợc dùng trong dịch vụ Web
<message>
Các thông điệp đƣợc sử dụng trong dịch vụ Web
<port type>
Các thao tác đƣợc thực thi bởi dịch vụ Web
<binding>
Các giao thức giao tiếp dùng cho dịch vụ Web
Bảng 1. 1 Các thành phần chính trong tài liệu WSDL
23

Kiểu thao tác
Mô tả
One-way
Thao tác này thể hiện rằng nó chỉ nhận các lời gọi thông

điệp nhƣng không trả lại thông điệp đáp ứng.
Request-response
Thao tác này bao gồm việc nhận các thông điệp yêu cầu
và trả về các thông điệp đáp ứng.
Solicit-response
Thao tác này sẽ gửi đi các yêu cầu và đợi các đáp ứng.
Notification
Thao tác này sẽ gửi đi các yêu cầu nhƣng không đợi để
nhận các đáp ứng.

Bảng 1. 2 Các kiểu thao tác đƣợc WSDL định nghĩa
Binding: Thành phần này định nghĩa các định dạng thông điệp, các mô tả cụ thể về
các giao thức cho mỗi port.









Một thành phần binding thông thƣờng bao gồm 2 thuộc tính: name và type. Thuộc tính
“name” định nghĩa tên của “binding”, và thuộc tính “type” trỏ đến “port” của binding,
ví dụ port của binding là “glossaryTerms”.
Thành phần soap:binding có 2 thuộc tính là “style” và “transport”.













<binding type="glossaryTerms" name="b1">
<soap:binding style="document"
transport="
<operation>
<soap:operation soapAction="
<input><soap:body use="literal"/></input>
<output><soap:body use="literal"/></output>
</operation>
</binding>
<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>
<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>
24


Trong ví dụ trên, thành phần <portType> định nghĩa “glossaryTerms” nhƣ là tên
của một Port, và “getTerm” nhƣ tên của một thao tác.
Thao tác “getTerm” có thông điệp nhập vào gọi là “getTermRequest” và có thông
điệp xuất ra gọi là “getTermResponse”.
Thành phần <message> định nghĩa các phần của mỗi thông điệp và kiểu dữ liệu kết
hợp với các thông điệp đó. Nếu so sánh với các ngôn ngữ lập trình truyền thống,
glossaryTerm có thể đƣợc coi nhƣ là một thƣ viện hàm, “getTerm” là một hàm với đối
số truyền vào là “getTermRequest” và trả lại lại kết quả là getTermResponse.
1.3.4 Đăng ký dịch vụ UDDI
1.3.4.1 Khái niệm cơ bản về UDDI
UDDI viết tắt của Universal Description, Discovery and Integration, là một chuẩn
dựa trên XML dùng cho việc mô tả, công bố và tìm kiếm dịch vụ Web. Có thể coi nó
là thƣ mục dùng cho việc lƣu trữ các thông tin về giao diện với dịch vụ Web, đƣợc mô
tả bởi WSDL.
UDDI giao tiếp thông qua SOAP, cùng với SOAP và WSDL, đƣợc xem là 3 chuẩn
của dịch vụ Web, là một chuẩn kỹ thuật mở đầu tiên cho phép các quy trình thƣơng
mại điện tử có thể khám phá lẫn nhau và định nghĩa cách thức tƣơng tác với nhau qua
Internet.
UDDI có 2 phần :
- Phần đăng ký của tất cả các siêu dữ liệu của dịch vụ Web, bao gồm cả việc trỏ
đến tài liệu WSDL mô tả dịch vụ.
- Phần thiết lập WSDL Port type định nghĩa cho các thao tác và tìm kiếm thông
tin đăng ký.
UDDI xây dựng dựa trên các giao thức chuẩn Internet đƣợc công bố bởi W3C và
IETF nhƣ XML, HTTP, và DNS. UDDI sử dụng WSDL để mô tả giao diện của Web
Service. Thêm nữa tính năng độc lập với nền tảng ngôn ngữ lập trình đã đƣợc điều hợp
cùng với giao thức SOAP.
1.3.4.2 Mô hình dữ liệu của UDDI
UDDI bao gồm một lƣợc đồ XML, mô tả bốn kiểu cấu trúc dữ liệu:

BusinessEntity, BusinessService, BindingTemplate, tModel, publisherAssertion
a) Cấu trúc dữ liệu businessEntity
Cấu trúc dữ liệu businessEntity trình bày nhà cung cấp dịch vụ Web. Cấu trúc này
chứa các thông tin về công ty, bao gồm danh sách liên lạc, thông tin, phân biệt các tổ
chức thƣơng mại, và danh sách các nhà cung cấp dịch vụ web.
b) Cấu trúc dữ liệu businessService
Cấu trúc dữ liệu business service trình bày một dịch vụ Web độc lập đƣợc cung cấp
bởi business entity. Nó mô tả các thông tin về cách thức gắn kết với dịch vụ Web, định
nghĩa kiểu dịch vụ Web và phân loại danh mục đƣợc liệt kê trong đó.
25

Chú ý rằng sử dụng dấu hiệu nhận dạng duy nhất – Universally Unique Identifiers
trong thuộc tính BusinessKey và serviceKey. Tất cả các business entity và business
service đều là dấu hiệu nhận dạng duy nhất trong UDDI registries thông qua việc chỉ
định UDDI bởi việc đăng ký khi thông tin đƣợc nhập vào lần đầu.
c) Cấu trúc dữ liệu bindingTemplate
BindingTemplate là kĩ thuật mô tả của dịch vụ Web đƣợc trình bày bởi cấu trúc dữ
liệu Business Service. Binding template trình bày sự hoạt động thực tế của dịch vụ
Web, mô tả công nghệ sử dụng để giao tiếp với dịch vụ Web. Một Business Service có
thể có nhiều binding template, cho nên dịch vụ phải chỉ rõ các hành động cụ thể khác
nhau trong cùng một dịch vụ.
d) Cấu trúc dữ liệu tModel
tModel là lõi trong cùng của kiểu dữ liệu, nhƣng rất khó có khả năng để có thể
nắm bắt đƣợc hết. tModel là chuẩn cho mô hình kĩ thuật, là phƣơng pháp để mô tả một
vài quy trình thƣơng mại, dịch vụ và các cấu trúc mẫu lƣu trữ trong đăng ký UDDI.
Bất kì một khái niệm trừu tƣợng nào đều có thể đƣợc đăng ký trong UDDI nhƣ là một
tModel. Ví dụ: chúng ta có thể định nghĩa ra một kiểu cổng (port type) WSDL mới, và
đồng nghĩa với đó ta có thể định nghĩa ra một tModel mới mà trình bày kiểu cổng đó
trong UDDI. Sau đó, ta có thể chỉ định ra dịch vụ thƣơng mại mà thực thi kiểu cổng đó
bằng việc kết hợp với tModel với một khuôn mẫu kết buộc tới dịch vụ thƣơng mại.

e) Cấu trúc dữ liệu publisherAssertion
Đây là một cấu trúc dữ liệu quan hệ, đặt sự kết hợp giữa hai hoặc nhiều cấu trúc
dữ liệu businessEntity theo một kiểu quan hệ cụ thể, chẳng hạn nhƣ một công ty con
hoặc một phòng ban.
Cấu trúc dữ liệu pubisherAssertion bao gồm ba thành phần chính: fromkey
(BusinessKey đầu tiên), toKey (bussinesskey thứ hai) và keyedReference.
KeyReference thiết kế ra kiểu mỗi quan hệ kết hợp trong cặp thuật ngữ keyName,
keyValue trong tModel. Tham chiếu duy nhất bởi tModelkey.