Kỹ thuật phát triển ứng dụng web bằng ngôn ngữ Ws Bpel

Số hóa bởi trung tâm học liệu
ĐẠI HỌC THÁI NGUYÊN
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG




PHẠM THANH TÙNG





KỸ THUẬT PHÁT TRIỂN ỨNG DỤNG WEB
BẰNG NGÔN NGỮ WS - BPEL





LUẬN VĂN THẠC SĨ KHOA HỌC MÁY TÍNH






THÁI NGUYÊN - 2013

Số hóa bởi trung tâm học liệu
ĐẠI HỌC THÁI NGUYÊN
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG




PHẠM THANH TÙNG




KỸ THUẬT PHÁT TRIỂN ỨNG DỤNG WEB
BẰNG NGÔN NGỮ WS - BPEL

Chuyên ngành: Khoa học máy tính
Mã số: 60 48 01


LUẬN VĂN THẠC SĨ KHOA HỌC MÁY TÍNH



Ngƣời hƣớng dẫn khoa học: PGS.TS. ĐẶNG VĂN ĐỨC

THÁI NGUYÊN - 2013





Số hóa bởi trung tâm học liệu
i
LỜI CAM ĐOAN


Tôi xin cam đoan rằng đây là công trình nghiên cứu của tôi, có sự hỗ trợ từ
Giáo viên hướng dẫn là PGS.TS. Đặng Văn Đức. Các nội dung nghiên cứu và kết
quả trong đề tài này là trung thực và chưa từng được ai công bố trong bất cứ công
trình nghiên cứu nào trước đây. Những số liệu trong các hình phục vụ cho việc phân
tích, nhận xét, đánh giá được chính tác giả thu thập từ các nguồn khác nhau có ghi
trong phần tài liệu tham khảo. Ngoài ra, đề tài còn sử dụng một số nhận xét, đánh
giá cũng như số liệu của các tác giả, cơ quan tổ chức khác, và cũng được thể hiện
trong phần tài liệu tham khảo.
Nếu phát hiện có bất kỳ sự gian lận nào tôi xin hoàn toàn chịu trách nhiệm
trước Hội đồng, cũng như kết quả luận văn của mình.



Thái nguyên, ngày 12 tháng 11 năm 2013

Tác giả

Phạm Thanh Tùng

Số hóa bởi trung tâm học liệu
ii

LỜI CẢM ƠN

Để hoàn thành luận văn này, em xin tỏ lòng biết ơn sâu sắc đến thầy
PGS.TS.ĐẶNG VĂN ĐỨC, đã tận tình hướng dẫn trong suốt quá trình viết luận
văn tốt nghiệp.
Em chân thành cảm ơn quý thầy, cô trong trường Đại Học Công nghệ Thông
tin và Truyền thông đã tận tình truyền đạt kiến thức trong hai năm học tập. Với vốn
kiến thức được tiếp thu trong quá trình học là nền tảng cho quá trình nghiên cứu để
em hoàn thành luận văn.
Chân thành cảm ơn Ban giám đốc Trung tâm Tin học thuộc Sở Giáo dục và
Đào tạo Hải Phòng và các bạn đồng nghiệp đã cho phép và tạo điều kiện thuận lợi
để tôi có thời gian học tập và nghiên cứu trong quá trình đào tạo cao học.
Cảm ơn gia đình đã động viên cũng như cảm ơn các bạn lớp CH K10C đã
cùng tôi đoàn kết xây dựng tập thể lớp K10C, đạt được những thành tích cao trong
học tập.
Một lần nữa xin chân thành cảm ơn!

Học viên cao học lớp K10C
Phạm Thanh Tùng


Số hóa bởi trung tâm học liệu
iii
MỤC LỤC

LỜI CAM ĐOAN i
LỜI CẢM ƠN ii
MỤC LỤC iii
DANH MỤC HÌNH v
MỞ ĐẦU 1
1. Đặt vấn đề 1
2. Đối tượng và phạm vi nghiên cứu 2
3. Hướng nghiên cứu của đề tài 2
Chƣơng 1. TỔNG QUAN VỀ DỊCH VỤ WEB 3
1.1. Ngôn ngữ XML 3
1.2. Giao thức truy cập dịch vụ Web - SOAP 9
1.2.1. Kiến trúc dịch vụ SOAP 9
1.2.2. Đặc trưng của SOAP 9
1.2.3. Cấu trúc một message theo dạng SOAP 11
1.2.4. Những kiểu truyền thông SOAP 12
1.2.5. Mô hình dữ liệu 12
1.3. Ngôn ngữ mô tả dịch vụ Web - WSDL 12
1.4. Mô tả và tìm kiếm dịch vụ Web – UDDI 14
1.4.1. Lớp dịch vụ Web với UDDI 14
1.4.2. Cấu trúc dữ liệu UDDI 17
1.5. Các dịch vụ web hiện nay đã phát triển 19
1.6. Tình hình nghiên cứu hiện nay trong và ngoài nước 19
Chƣơng 2. NGÔN NGỮ BPEL 21
2.1. Giới thiệu ngôn ngữ BPEL 21
2.1.1. Nguyên tắc hoạt động của một tiến trình BPEL 22
2.1.2. Cấu trúc của một tiến trình BPEL 24

Số hóa bởi trung tâm học liệu
iv

2.2. Các khái niệm cơ bản về BPEL 25
2.2.1. Các thành phần tác vụ trong BPEL 25
2.2.2 . BPEL với chương trình dịch Java 37
2.3. Kiến trúc một số trình xử lý tiêu biểu trong BPEL 38
2.3.1. Khái niệm trình xử lý BPEL 38
2.3.2. Kiến trúc một số trình xử lý tiêu biểu 41
2.4. Đánh giá hiệu năng của các trình xử lý 54
2.5. Quy trình thiết kế tái sử dụng. 55
Chƣơng 3. XÂY DỰNG HỆ THỐNG THỬ NGHIỆM TÍCH HỢP
DỊCH VỤ WEB TRÊN CƠ SỞ BPEL 58
3.1. Mô tả bài toán 58
3.2. Phân tích hệ thống 59
3.2.1. Mục đích của hệ thống 59
3.2.2. Phạm vi bài toàn 59
3.3. Thiết kế hệ thống 59
3.4. Triển khai hệ thống demo kết hợp dịch vụ Web 61
KẾT LUẬN 64
TÀI LIỆU THAM KHẢO 66

Số hóa bởi trung tâm học liệu
v

DANH MỤC HÌNH

Hình 1.1: Một SOAP Operation đơn giản 10
Hình 1.2: Cấu trúc thông điệp SOAP 10
Hình 1.3: Cấu trúc message SOAP 11
Hình 1.4: Lớp dịch vụ Web với UDDI 14
Hình 1.5: Luồng thông báo UDDI giữa Client và Registry 15
Hình 2.1: Ví dụ về một tiến trình BPEL 22

Hình 2.2: Ví dụ về kiểu liên kết ngoài - PartnerLink Type 23
Hình 2.3: Ví dụ về liên kết ngoài – PartnerLink 23
Hình 2.4: Cấu trúc file BPEL 24
Hình 2.5: Cấu trúc XML của receive 27
Hình 2.6: Ví dụ về trường hợp sử dụng invoke 28
Hình 2.7: Cấu trúc XML của invoke 28
Hình 2.8: Trường hợp sử dụng của Reply 29
Hình 2.9: Cấu trúc XML của Reply 29
Hình 2.10: Trường hợp sử dụng của Validate 30
Hình 2.11: Cấu trúc XML của Assign 31
Hình 2.12: Trường hợp sử dụng của Throw 31
Hình 2.13: Trường hợp sử dụng của ReThrow 32
Hình 2.14: Cấu trúc XML của Flow 33
Hình 2.15: Cấu trúc XML của Repeat Until 33
Hình 2.16: Trường hợp sử dụng của Pick 34
Hình 2.17: Cấu trúc XML của If 34
Hình 2.18: Cấu trúc XML của Flow 35
Hình 2.19: Trường hợp sử dụng của Foreach 35
Hình 2.20: Cấu trúc XML của Foreach 36

Số hóa bởi trung tâm học liệu
vi
Hình 2.21: Cấu trúc XML của While 36
Hình 2.22: Trường hợp sử dụng của Scope 37
Hình 2.23: Mô hình kiến trúc BPEL 39
Hình 2.24: Mẫu tiến trình logic 40
Hình 2.25: Bảng Danh sách các trình xử lý BPEL hiện nay 41
Hình 2.26: Trình thiết kế của Apache ODE trên nền tảng Eclipse 42
Hình 2.27: Kiến trúc của Apache ODE 43
Hình 2.28: Bộ sản phẩm ActiveVOS 45

Hình 2.29: Trình thiết kế ActiveVOS 46
Hình 2.30: Kiến trúc tổng quan của ActiveVOS Server 47
Hình 2.31: Mối quan hệ của Oracle BPEL Process Manager với các
thành phần khác 50
Hình 2.32: Kiến trúc của Oracle BPEL Process Manager 51
Hình 2.33: Trình thiết kế Jdeveloper cho Oracle BPELProcess Manager 53
Hình 2.34: Mô hình đo hiệu năng trình xử lý BPEL 55
Hình 2.35: Thiết lập khách hàng dịch vụ Web 56
Hình 3.1: Mô hình xây dựng quá trình BPEL 59
Hình 3.2: Sơ đồ luồng dữ liệu quy trình BPEL 60
Hình 3.3: Sơ đồ quá trình gán (Assign) theo định nghĩa BPEL 60
Hình 3.4: Cửa sổ Preferences 61
Hình 3.5: Cửa sổ New Server Runtime Environment 61
Hình 3.6: Địa chỉ dịch vụ cùng các cổng kết nối dịch vụ máy chủ Vietnamses 62
Hình 3.7: Địa chỉ dịch vụ cùng các cổng kết nối dịch vụ máy chủ English 62
Hình 3.8: Quy trình kết nối dịch vụ bằng kỹ thuật BPEL trên chương
trình dịch Java (Eclipse) 63


Số hóa bởi trung tâm học liệu
1
MỞ ĐẦU
1. Đặt vấn đề
Trong vài năm qua, Công nghệ thông tin IT (Information Technology) đã bắt
đầu phát triển các dịch vụ web (web service). Mặc dù các dịch vụ web là một cách
để chia sẻ các tài nguyên máy tính, chứ không phải là một công nghệ mới, nhưng nó
đã châm ngòi một cuộc cách mạng trong cách cung cấp dịch vụ của các tổ chức.
Lúc đầu dịch vụ web trên máy tính cung cấp các tính năng ưu việt thông qua
các trang web nhưng hiện nay nó đã mở rộng ra với các thiết bị công nghệ thông tin
khác như điện thoại, máy kỹ thuật số. Công nghệ thông tin hiện đại ngày càng phổ

biến chức năng của công nghệ di động, việc ghép nối các dịch vụ ngày càng cần
thiết. Tuy nhiên, cuộc cách mạng này giống như mọi cuộc cách mạng khác, có các
thành phần của quá khứ mà từ đó nó phát triển lên.
Vì vậy, để đưa dịch vụ web phát triển mạnh mẽ hơn cần tích hợp chúng sao
cho dễ dàng với người sử dụng. Về nhiều mặt, sự thay đổi quan trọng này là vấn đề
làm sao kết hợp chúng một cách toàn diện chứ không phải là sự ghép nối chắp vá
đơn giản. Trong thế giới mới việc một người sử dụng một phần mềm dịch vụ web
với tất cả tiện ích cơ bản có sẵn là việc thiết yếu, giảm tải sự phức tạp khi sử dụng
nhiều phần mềm dịch vụ khác nhau do nhiều hãng khác nhau thiết kế. Sự thay đổi
thực sự ấy trong cách chúng ta tính toán mang lại các cơ hội to lớn cho người sử
dụng dịch vụ công nghệ thông tin để kiểm soát sự thay đổi và sử dụng chúng cho lợi
ích cá nhân và tổ chức của họ.
Xuất phát từ những vấn đề nêu trên, đề tài ―Kỹ thuật phát triển ứng dụng
Web bằng ngôn ngữ WS-BPEL‖ nhằm mục tiêu tiếp cận, nghiên cứu các đặc điểm,
ứng dụng, cơ sở hạ tầng, các mô hình triển khai dịch vụ dựa trên các dịch vụ có sẵn
để đề xuất lựa chọn mô hình dịch vụ kết hợp và thay thế chúng. Trên cơ sở các mô
hình dịch vụ web đã có tìm ra mô hình dịch vụ thay thế và sử dụng ngôn ngữ thực
thi tiến trình nghiệp vụ dịch vụ Web WS-BPEL (Web Service Business Process
Execution Language) để thể hiện chúng.

Số hóa bởi trung tâm học liệu
2
2. Đối tƣợng và phạm vi nghiên cứu
Kiến trúc tổng thể và các thành phần cơ bản như XML, kiến trúc dịch vụ
Web như SOAP, WSDL và UDDI, ngôn ngữ BPEL.
Lựa chọn một dịch vụ web để xây dựng demo trên cơ sở kiến trúc đã nghiên
cứu trên đây.
3. Hƣớng nghiên cứu của đề tài
- Hướng của đề tài đặt ra phương án kết hợp một số dịch vụ web thông
thường lại với nhau trong cùng một chương trình xử lý.

- Thực hiện bản thử nghiệm với các tính năng đơn giản, gọn nhẹ vào các
thiết bị công nghệ thông tin phổ thông.
- Nghiên cứu thuật toán kết hợp các dịch vụ rời rạc thành một ứng dụng
nghiệp vụ thống nhất một cách đơn giản và nhanh chóng mà không cần thay đổi các
dịch vụ đó.
- Xây dựng hệ thống quy trình thiết kế tái sử dụng các ứng dụng sẵn có được
viết trên các ngôn ngữ khác nhau, kết hợp chúng thành ứng dụng nghiệp vụ thống
nhất có tính khả thi.
- Sử dụng ngôn ngữ mô phỏng và thực thi tiến trình nghiệp vụ có tên là
BPEL. Ngôn ngữ BPEL sẽ định nghĩa tiến trình, các dịch vụ ngoài và sử dụng các
tác vụ, các phép toán logic để tạo thành quy trình.
- Thiết lập demo module sử dụng kỹ thuật xây dựng ứng dụng web dựa trên
ngôn ngữ WS- BPEL.

Số hóa bởi trung tâm học liệu
3
Chƣơng 1
TỔNG QUAN VỀ DỊCH VỤ WEB
1.1. Ngôn ngữ XML
XML (eXtensible Markup Language) là ngôn ngữ đánh dấu với mục đích
chung do W3C (World Wide Web Consortium là một hiệp hội lập ra các chuẩn cho
Internet) đề nghị, để tạo ra các ngôn ngữ đánh dấu khác. Đây là một tập đoàn con
đơn giản của SGML (Standard Generalized Markup Language, một hệ thống tổ
chức và gắn thẻ yếu tố của một tài liệu), có khả năng mô tả nhiều loại dữ liệu khác
nhau. Mục đích chính của XML là đơn giản hóa việc chia sẻ dữ liệu giữa các hệ
thống khác nhau, đặc biệt là các hệ thống được kết nối với Internet.
Các ngôn ngữ dựa trên XML như RDF, RSS, MathML, XHTML, SVG, GML
và cXML được định nghĩa theo cách thông thường, cho phép các chương trình sửa
đổi và kiểm tra hợp lệ bằng các ngôn ngữ này mà không cần có hiểu biết trước về
hình thức của chúng.

XML cung cấp một phương tiện dùng văn bản để mô tả thông tin và áp dụng
một cấu trúc kiểu cây cho thông tin đó. Tại mức căn bản, mọi thông tin đều thể hiện
dưới dạng text, chen giữa là các thẻ đánh dấu (markup) với nhiệm vụ ký hiệu sự
phân chia thông tin thành một cấu trúc có thứ bậc của các dữ liệu ký tự, các phần
tử dùng để chứa dữ liệu, và các thuộc tính của các phần tử đó. Về mặt đó, XML
tương tự với các biểu thức S (S-expression) của ngôn ngữ lập trình LISP ở chỗ
chúng đều mô tả các cấu trúc cây mà trong đó mỗi nút có thể có một danh sách tính
chất của riêng mình.
Đơn vị cơ sở của XML là các ký tự theo định nghĩa của Universal Character
Set (Bộ ký tự toàn cầu). Các ký tự được kết hợp theo các tổ hợp chuỗi hợp lệ để tạo
thành một tài liệu XML. Tài liệu này gồm một hoặc nhiều thực thể, mỗi thực thể
thường là một phần nào đó của các ký tự thuộc tài liệu, được mã hóa dưới dạng một
chuỗi các bit và lưu trữ trong một tệp văn bản (text file).

Số hóa bởi trung tâm học liệu
4
Sự phổ biến của các phần mềm soạn thảo văn bản (word processor) đã hỗ trợ
việc soạn thảo và bảo trì tài liệu XML một cách nhanh chóng. Trước XML, có rất ít
ngôn ngữ mô tả dữ liệu với các đặc điểm đa năng, thân thiện với giao thức Internet,
dễ học và dễ tạo. Thực tế, đa số các định dạng trao đổi dữ liệu thời đó đều chuyện
dụng, có tính độc quyền, và có định dạng nhị phân (chuỗi bit thay vì chuỗi ký tự)
khó dùng chung giữa các ứng dụng phần mềm khác nhau hay giữa các hệ nền
(platform) khác nhau. Việc tạo và bảo trì trên các trình soạn thảo thông dụng lại
càng khó khăn.
Bằng cách cho phép các tên dữ liệu, cấu trúc thứ bậc được phép, và ý nghĩa
của các phần tử và thuộc tính có tính chất mở và có thể được định nghĩa bởi
một giản đồ tùy biến được, XML cung cấp một cơ sở cú pháp cho việc tạo lập các
ngôn ngữ đánh dấu dựa XML theo yêu cầu. Cú pháp chung của các ngôn ngữ đó là
cố định, các tài liệu phải tuân theo các quy tắc chung của XML, bảo đảm rằng tất cả
các phần mềm hiểu XML ít ra cũng phải có khả năng đọc (phân tích cú pháp -

parse) và hiểu bố cục tương đối của thông tin trong các tài liệu đó. Giản đồ chỉ bổ
sung một tập các ràng buộc cho các quy tắc cú pháp. Các giản đồ thường hạn chế
tên của phần tử và thuộc tính và các cấu trúc thứ bậc được phép, ví dụ, chỉ cho phép
một phần tử tên 'ngày sinh' chứa một phần tử tên 'ngày' và một phần tử có tên
'tháng', mỗi phần tử phải chứa đúng một ký tự. Đây là điểm khác biệt giữa XML
và HTML. HTML có một bộ các phần tử và thuộc tính không mềm dẻo, chỉ có một
tác dụng và nói chung là không thể dùng cho mục đích khác [5].
XML không hạn chế về việc nó được sử dụng như thế nào. Mặc dù XML
về cơ bản là dạng text, các phần mềm với chức năng trừu tượng hóa nó thành các
định dạng khác giàu thông tin hơn đã nhanh chóng xuất hiện, quá trình trừu
tượng hóa này được thực hiện chủ yếu qua việc sử dụng các giản đồ định hướng
kiểu dữ liệu (datatype-oriented schema) và khuôn mẫu lập trình hướng đối
tượng (mà trong đó, mỗi tài liệu XML được thao tác như là một đối tượng).
Những phần mềm như vậy có thể coi XML như là dạng text đã được tuần tự hóa
chỉ khi nó cần truyền dữ liệu qua mạng.

Số hóa bởi trung tâm học liệu
5
Ngoài những đặc điểm trên, công nghệ này còn cần phải được xem xét kỹ
bởi lẽ trong quá trình thao tác và truyền dữ liệu, nó đã được thống kê và ghi nhận tỷ
lệ sai sót, mất dữ liệu dao động từ 5 - 7%. Tuy con số này không cao, nhưng cũng
đáng để những người sử dụng phải có những cân nhắc kỹ càng hơn.
Cú pháp XML cơ bản cho một phần tử là
<t
ên thuộc_tính="giá trị"
>
nội dung
</t
ên
>

<?xml
version="1.0" encoding="UTF-8"
?>

<c
ông_thức_nấu_ăn tên="bánh mì" thời_gian_chuẩn_bị="5 phút" thời_gian_nấu
= "3 tiếng"
>


<title>
Bánh mì cơ bản
</title>


<nguy
ên_liệu lượng="3" đơn_vị="ca"
>
Bột mì
</nguy
ên_liệu
>


<nguy
ên_liệu lượng="7" đơn_vị="gram"
>
Men
</nguy

ên_liệu
>


<nguy
ên_liệu lượng="1.5" đơn_vị="ca" trạng_thái="ấm"
>
Nước
</nguy
ên_liệu
>


<nguy
ên_liệu lượng="1" đơn_vị="thìa cà phê"
>
Muối
</nguy
ên_liệu
>


<ch
ỉ_dẫn
>


<b
ước
>

Trộn tất cả các nguyên liệu với nhau và nhào kĩ
</b
ước
>


<b
ước
>
Phủ một mảnh vải, ủ một tiếng đồng hồ trong phòng ấm.
</b
ước
>


<b
ước
>
Nhào lại, đổ vào khuôn, cho vào lò nướng.
</b
ước
>


</ch
ỉ_dẫn
>

</c
ông_thức_nấu_ăn

>

Dòng đầu tiên là Khai báo XML (XML declaration): đó là một dòng không bắt
buộc, với nhiệm vụ thông báo phiên bản XML đang được sử dụng (thường là phiên
bản 1.0), và còn có thể chứa thông tin về mã hóa ký tự và các phụ thuộc bên ngoài.
Phần còn lại của tài liệu này chứa các phần tử lồng nhau, một số phần tử
trong đó có các thuộc tính và nội dung. Một phần tử thường bao gồm hai thẻ (tag),
một thẻ bắt đầu và một thẻ kết thúc, có thể bao quanh văn bản và các phần tử
khác. Thẻ bắt đầu bao gồm một cái tên đặt trong một cặp ngoặc nhọn, như
"<bước>"; thẻ kết thúc bao gồm chính cái tên đó đặt trong một cặp ngoặc nhọn, với
một dấu gạch chéo đứng trước, như "</bước>". Nội dung của phần tử là tất cả

Số hóa bởi trung tâm học liệu
6
những gì nằm giữa thẻ bắt đầu và thẻ kết thúc, bao gồm văn bản và các phần tử
(con) khác. Dưới đây là một phần tử XML hoàn chỉnh, với thẻ bắt đầu, nội dung
văn bản, và thẻ kết thúc:

<b
ước
>
Nhào lại, đổ vào khuôn, cho vào lò nướng.
</b
ước
>

Bên cạnh nội dung, một phần tử có thể chứa các thuộc tính - các cặp tên - giá
trị được đặt trong thẻ bắt đầu, ngay sau tên phần tử. Giá trị của thuộc tính phải được
đặt trong cặp nháy đơn hoặc nháy kép, mỗi tên thuộc tính chỉ được xuất hiện một
lần trong mỗi phần tử.

<nguyên_liệu lượng="3" đơn_vị="ca">Bột mì</nguyên_liệu>
Trong ví dụ này, phần tử nguyên_liệu có hai thuộc tính: lượng với giá trị "3",
và đơn vị với giá trị "ca". Trong cả hai trường hợp, cũng như tên và nội dung của
các phần tử, tại cấp độ đánh dấu, tên và giá trị của các thuộc tính cũng chỉ là dữ liệu
text — các giá trị "3" và "ca" không phải một số lượng và một đơn vị đo lường mà
chỉ là các chuỗi ký tự mà tác giả tài liệu có thể dùng đểbiểu diễn những thứ đó.
Ngoài văn bản, các phần tử còn có thể chứa các phần tử khác:
<chỉ_dẫn>
<bước>Trộn tất cả các nguyên liệu với nhau và nhào kĩ</bước>
<bước>Phủ một mảnh vải, ủ một tiếng đồng hồ trong phòng ấm.</bước>
<bước>Nhào lại, đổ vào khuôn, cho vào lò nướng.</bước>
</chỉ_dẫn>
Trong đó, phần tử chỉ_dẫn chứa ba phần tử bước. XML đòi hỏi rằng các
phần tử phải được lồng nhau một cách đúng đắn - các phần tử không được có phần
xen vào nhau. Ví dụ, đoạn dưới đây không phải XML định dạng đúng (well-formed
XML) vì các phần từ em và strong xen vào nhau:
<! SAI! ĐỊNH DẠNG KHÔNG ĐÚNG! >
<p>Normal <em>emphasized <strong>strong emphasized</em>
strong</strong></p>
Mỗi tài liệu XML phải có đúng một phần tử gốc tại bậc trên cùng (còn gọi
là phần tử văn bản), do đó đoạn sau cũng sẽ là một tài liệu XML định dạng sai:

Số hóa bởi trung tâm học liệu
7
<?xml version="1.0" encoding="UTF-8"?>
<! SAI! ĐỊNH DẠNG KHÔNG ĐÚNG! >
<đồ vật>Đồ vật thứ nhất</đồ vật>
<đồ vật>Đồ vật thứ hai</đồ vật>
XML cung cấp cú pháp đặc biệt để biểu diễn một phần tử với nội dung rỗng.
Thay vì viết một thẻ bắt đầu và một thẻ kết thúc ngay sau đó, tài liệu có thể chứa thẻ

phần tử rỗng mà trong đó dấu gạch chéo đứng ngay sau tên phần tử. Hai ví dụ sau là
tương đương về chức năng:
<foo></foo>
</div>
:<source lang="xml" enclose="div" style="font-size:1.2em;" >
<foo />
XML cung cấp hai phương pháp biểu diễn các ký tự đặc biệt: các tham chiếu
thực thể (entity reference) và các tham chiếu ký tự số (numeric character reference).
Trong XML, một thực thể (entity) là một thân dữ liệu được đặt tên với dữ
liệu thường là text, chẳng hạn một ký tự đặc biệt.
Một tham chiếu thực thể là một ký hiệu đại diện cho thực thể đó. Nó bao
gồm tên của thực thể với dấu ("&") đứng trước và một dấu chấm phảy (";") đứng
sau. XML có năm thực thể đã được khai báo trước:
&amp; (&)
&lt; (<)
&gt; (>)
&apos; (')
&quot; (")
Dưới đây là một ví dụ sử dụng một thực thể XML khai báo trước để biểu
diễn dấu & trong tên "AT&T":
<tên-công-ty>AT&amp;T</tên-công-ty>
Nếu cần khai báo thêm các thực thể khác, việc đó được thực hiện tại
DTD của tài liệu. Sau đây là một ví dụ cơ bản về khai báo thực thể tại một DTD

Số hóa bởi trung tâm học liệu
8
nhỏ nội bộ. Các thực thể được khai báo có thể mô tả các ký tự đơn hay các đoạn văn
bản, và có thể tham chiếu lẫn nhau.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE example [

<!ENTITY copy "©">
<!ENTITY copyright-notice "Copyright © 2006, XYZ
Enterprises"
>

]>
<root>
&copyright-notice;
</root>
Khi xem tại một trình duyệt thích hợp, tài liệu XML trên sẽ hiện ra như sau:
<root> Copyright © 2006, XYZ Enterprises </root>
Các tham chiếu ký tự số trông giống như các thực thể. Nhưng thay cho
một cái tên, chúng gồm một ký tự "#" và theo sau là một con số. Con số
(theo hệ thập phân hoặc hệ cơ số 16 với tiền tố "x") đại diện cho một mã hiệu
Unicode (Unicode code point), và thường được dùng để đại diện cho các ký tự
không dễ gõ trên máy tính, chẳng hạn một chữ cái Ả-rập trong một tài liệu
được soạn trên một máy tính châu Âu. Dấu & trong ví dụ "AT&T" có thể được
biểu diễn như sau (số 38 thập phân và 26 trong hệ cơ số 16 đều đại diện cho giá
trị Unicode của dấu &):
<t
ên-công-ty
>
AT&#38;T
</t
ên-công-ty
>

<t
ên-công-ty
>

AT&#x26;T
</t
ên-công-ty
>

Còn có nhiều quy tắc khác cần thiết cho việc viết các tài liệu XML định
dạng đúng, chẳng hạn một tên XML có thể chứa các ký tự nào, nhưng phần giới
thiệu ngắn này chỉ cung cấp các kiến thức căn bản để đọc và hiểu được nhiều tài
liệu XML.

Số hóa bởi trung tâm học liệu
9
1.2. Giao thức truy cập dịch vụ Web - SOAP
1.2.1. Kiến trúc dịch vụ SOAP (Simple Object Access Protocol – Giao thức truy
cập đối tượng đơn giản)
SOAP là một giao thức giao tiếp có cấu trúc như XML và mã hóa thành định
dạng chung cho các ứng dụng trao đổi với nhau. Ý tưởng bắt đầu từ Microsoft và
phần mềm Userland, trải qua nhiều lần thay đổi, hiện tại là phiên bản SOAP 1.2.
SOAP được xem như là cấu trúc xương sống của các ứng dụng phân tán xây dựng
từ nhiều ngôn ngữ, hệ điều hành khác nhau.
SOAP là một đặc tả việc sử dụng các tài liệu XML theo dạng các thông điệp.
Bản thân SOAP không định ra các ngữ nghĩa ứng dụng hoặc cách cài đặt chi tiết.
SOAP cung cấp một cơ chế đơn giản và gọn nhẹ cho việc trao đổi thông tin có cấu
trúc và định dạng giữa các thành phần trong một môi trường phân tán sử dụng
XML. SOAP được thiết kế dựa trên những chuẩn nhằm giảm chi phí tích hợp các hệ
thống phân tán xây dựng trên nhiều nền tảng khác nhau ở mức càng thấp càng tốt.
Đặc tả về SOAP định nghĩa một mô hình trao đổi dữ liệu dựa trên 3 khái niệm cơ
bản: Các thông điệp là các tài liệu XML, chúng được truyền đi từ bên gửi đến bên
nhận, bên nhận có thể chuyển tiếp dữ liệu đến nơi khác.
Khái niệm cơ bản nhất của mô hình SOAP là việc sử dụng các tài liệu XML

như những thông điệp trao đổi. Điều này có nhiều ưu điểm hơn các giao thức truyền
dữ liệu khác. Các thông điệp XML có thể được tổng hợp và đọc với một bộ soạn
thảo text đơn giản, ta có thể làm việc với XML trên hầu hết mọi nền tảng [1].
1.2.2. Đặc trưng của SOAP
- SOAP được thiết kế đơn giản và dễ mở rộng.
- Tất cả các message SOAP đều được mã hóa sử dụng XML.
- SOAP sử dùng giao thức truyền dữ liệu riêng.
- Không có garbage collection phân tán, và cũng không có cơ chế tham
chiếu. Vì thế SOAP client không giữ bất kỳ một tham chiếu đầy đủ nào về các đối
tượng ở xa.
- SOAP không bị ràng buộc bởi bất kỳ ngôn ngữ lập trình nào hoặc công
nghệ nào.

Số hóa bởi trung tâm học liệu
10
Vì những đặc trưng này, nó không quan tâm đến công nghệ gì được sử dụng
để thực hiện miễn là người dùng sử dụng các message theo định dạng XML. Tương
tự, service có thể được thực hiện trong bất kỳ ngôn ngữ nào, miễn là nó có thể xử lý
được những message theo định dạng XML.
Khi trao đổi các thông điệp SOAP, có hai thành phần liên quan: Bên gửi và
bên nhận. Thông điệp sẽ được chuyển từ bên gửi sang bên nhận. Đây là ý niệm đơn
giản nhất trong trao đổi thông điệp SOAP. Trong nhiều trường hợp, kiểu trao đổi
này không cung cấp đủ chức năng. Nhưng đây là mô hình cơ bản, dựa trên đó sẽ
phát triển các mô hình trao đổi phức tạp hơn.

Hình 1.1: Một SOAP Operation đơn giản
Một cấu trúc SOAP được định nghĩa gồm các phần: <Envelope>, <Header>
và <Body>.

Hình 1.2: Cấu trúc thông điệp SOAP

Envelop là thành phần gốc của một thông điệp SOAP, nó chứa các thành
phần Header và Body. Thành phần Header là một cơ chế mở cho phép thêm các tính
năng vào bên trong một thông điệp SOAP. Mỗi thành phần con của Header gọi là
một Header Entry. Các Header Entry dùng để diễn giải, quy định một số ngữ nghĩa
của thông điệp SOAP. Các ứng dụng có thể xử lý và định tuyến các thông điệp dựa
trên thông tin header và thông tin bên trong thông điệp đó. Đây là ưu điểm mà các
mô hình kiến trúc như DCOM, CORBA và RMI không có được, vì các protocol
header của chúng phải được chỉ định chi tiết cho mỗi ứng dụng.

Số hóa bởi trung tâm học liệu
11
1.2.3. Cấu trúc một message theo dạng SOAP
Message theo dạng SOAP là một văn bản XML bình thường bao gồm các
phần tử sau:
- Phần tử gốc - envelop: Phần tử bao trùm nội dung message, khai báo văn
bản XML như là một thông điệp SOAP.
- Phần tử đầu trang - header: Chứa các thông tin tiêu đề cho trang, phần tử
này không bắt buộc khai báo trong văn bản. Những đầu mục còn có thể mang
những dữ liệu chứng thực, những chữ ký số hóa, và thông tin mã hóa, hoặc những
cài đặt cho giao tác.
- Phần tử khai báo nội dung chính trong thông điệp - body, chứa các thông
tin yêu cầu và phản hồi.
- Phần tử phát sinh lỗi (Fault) cung cấp thông tin lỗi xảy ra trong quá trình xử
lý thông điệp.
Cấu trúc một message theo dạng SOAP được mô tả như hình dưới đây:

Hình 1.3: Cấu trúc message SOAP
Trong trƣờng hợp đơn giản nhất, phần thân của SOAP message gồm có:
- Tên của message
- Một tham khảo tới một thể hiện service.

- Một hoặc nhiều tham số mang các giá trị và mang các tham chiếu. Có 3
kiểu thông báo:

Số hóa bởi trung tâm học liệu
12
+ Request messages: Với các tham số gọi thực thi một service
+ Response messages: Với các tham số trả về, được sử dụng khi đáp ứng
yêu cầu.
+ Fault messages báo tình trạng lỗi.
1.2.4. Những kiểu truyền thông SOAP
- Remote procedure call (RPC): Cho phép gọi hàm hoặc thủ tục qua mạng.
Kiểu này được khai thác bởi nhiều web service và có nhiều trợ giúp.
- Document (Được biết như kiểu hướng message): Kiểu này cung cấp một lớp thấp
của sự trừu tượng hóa và yêu cầu lập trình nhiều hơn khi làm việc.
Các định dạng message, tham số và lời gọi đến các API thì tương ứng trong
RPC và document là khác nhau. Nên việc quyết định chọn cái nào tùy thuộc vào
thời gian xây dựng và sự phù hợp của service cần xây dựng.
1.2.5. Mô hình dữ liệu
Mục đích của mô hình dữ liệu SOAP là cung cấp sự trừu tượng hóa độc lập
ngôn ngữ cho kiểu ngôn ngữ lập trình chung. Nó gồm có:
Những kiểu XSD đơn giản như những kiểu dữ liệu cơ bản trong đa số các
ngôn ngữ lập trình như int, string, date…
Những kiểu phức tạp, có hai loại là struct và array.
Tất cả các phần tử và những định danh có trong mô hình dữ liệu SOAP thì
được định nghĩa bằng namespace SOAP-ENC
1.3. Ngôn ngữ mô tả dịch vụ Web - WSDL
WSDL định nghĩa cách mô tả web service theo cú pháp tổng quát XML, bao
gồm các thông tin [7]:
- Tên service.
- ể gọi các hàm của web

service.
- Loạ
.

Số hóa bởi trung tâm học liệu
13
:
ối.
ể truy xuất service
Cả 2 phần trên sẽ được lưu trong 2 tập tin XML, bao gồm:
- Tậ (cho phần 1).
- Tậ 2).
Một tài liệu WSDL gồm bảy yếu tố:
- Các loại định nghĩa các loại dữ liệu được sử dụng trong dịch vụ này.
- Tin nhắn định nghĩa của các thông báo liên quan đến sự tương tác với dịch
vụ này.
- Hoạt động hoạt động trừu tượng.
- Nhóm kiểu trừu tượng của các hoạt động dịch vụ hỗ trợ.
- Ràng buộc cụ thể giao thức và định dạng dữ liệu cho một loại cổng của
dịch vụ này.
- Các ràng buộc và địa chỉ mạng.
Phục vụ một bộ sưu tập của các cảng.
Loại, tin nhắn, hoạt động và Port Loại thuộc phần trừu tượng mô tả dịch vụ.
Phần trừu tượng rõ ràng là tách ra từ cụ thể một phần, tức là Binding, cổng và dịch
vụ, cho phép tái sử dụng của các trừu tượng mô tả.
Một tài liệu WSDL có cấu trúc sau:
<Definition name = ". . . ">
<types>
[ ]
</ types>

<message name = ". . . ">
[ ]
</ message>
<porttype name = ". . . ">
[ ]

Số hóa bởi trung tâm học liệu
14
</ porttype>
<binding>
[ ]
</binding>
<service>
[ ]
</service>
</ definitions>
1.4. Mô tả và tìm kiếm dịch vụ Web – UDDI
1.4.1. Lớp dịch vụ Web với UDDI
UDDI dựa vào những chuẩn đã có như là ngôn ngữ đánh dấu mở rộng (XML)
và giao thức truy cập đối tượng đơn giản (SOAP). Tất cả các cài đặt của UDDI đều hỗ
trợ các đặc tả UDDI. Mục đích là để tạo và thực thi ba phiên bản liên tiếp của đặc tả kỹ
thuật trước khi chuyển giao quyền sở hữu cho một cá nhân độc lập.

Hình 1.4: Lớp dịch vụ Web với UDDI
Phiên bản 1 của đặc tả UDDI được công bố trong tháng 9 năm 2000, xây dựng
nền tảng cho việc đăng ký. Phiên bản 2 được công bố váo tháng 6 năm 2001, thêm các
đặc tính như quan hệ kinh doanh. Phiên bản 3 tiếp tục giải quyết các lĩnh vực quan
trọng cho việc phát triển dịch vụ web, như là bảo mật, tăng cường quốc tế hóa, khả
năng tương tác nội bộ, và hàng loạt các cải tiến hàm API để cải tiến công cụ tốt hơn.

Số hóa bởi trung tâm học liệu
15
UDDI xây dựng trên tầng vận chuyển của mô hình mạng và tầng thông điệp
XML dựa trên SOAP. Các ngôn ngữ mô tả dịch vụ, như là ngôn ngữ miêu tả dịch
vụ Web (Web Services Description Language - WSDL), cung cấp thuật ngữ XML
đồng nhất (tương tự như ngôn ngữ tương tác dữ liệu - IDL) để dùng trong việc mô
tả các dịch vụ web và giao diện của chúng.
Bản ghi của UDDI chứa các mô tả của các doanh nghiệp có thể truy cập bằng
các chương trình máy tính và các dịch vụ mà chúng hỗ trợ. Nó cũng chứa các tham
chiếu tới các đặc tả cụ thể mà một dịch vụ web có thể hỗ trợ, các định nghĩa phân
loại (được sử dụng cho việc xếp loại kinh doanh và dịch vụ), và các hệ thống định
danh (sử dụng để xác định các doanh nghiệp). UDDI cung cấp một lược đồ và mô
hình lập trình với định nghĩa luật giao tiếp với bản ghi. Tất cả các hàm API trong
đặc tả UDDI được định nghĩa trong XML, gói gọn trong một phong bì SOAP, và
gửi qua HTTP.

Hình 1.5: Luồng thông báo UDDI giữa Client và Registry
Đặc tả UDDI được cấu thành từ vài tài liệu khác nhau. Đặc tả API mô tả các
hàm API SOAP cho phép thực hiện các hoạt động tìm kiếm và quảng bá. Cách xử
lý lỗi, ngữ nghĩa của yêu cầu, kết quả cũng được mô tả. Các thông tin thực tế về các
quy ước và cách sử dụng cũng có sẵn. Các tài liệu bao gồm đặc tả cấu trúc dữ liệu
và lược đồ API định nghĩa thông điệp và ngữ nghĩa của dữ liệu.
Các hàm API của UDDI được chia thành hai nhóm, truy vấn và phát hành.

Số hóa bởi trung tâm học liệu
16
Inquiry Operations: Publishing Operations:
Find Save
find_business save_business
find_service save_service

find_binding save_binding
find_tModel save_tModel
Get details Delete
get_businessDetail delete_business
get_serviceDetail delete_service
get_bindingDetail delete_binding
get_tModelDetail delete_tModel
get_registeredInfo get_registeredInfo
Security
get_authToken
discard_authToken
Các API truy vấn chia thành ba mẫu truy vấn:
Các mẫu tìm kiếm mẫu thừa kế công dụng của toán từ tìm kiếm, cái mà cho
phép duyệt các mục dữ liệu sử dụng các điều kiện khác nhau, như là hạng
mục phân loại, các định danh, hoặc thông tin tên từng phần sử dụng hàm
API_xxxfind_xxx.
Các mẫu tìm kiếm sâu liên quan đến việc thu nhập thông tin chi tiết về một
mục dữ liệu mà đã tìm thấy. Hàm APIget_xxx hỗ trợ khả năng này.
Các mẫu tìm kiếm viện dẫn thông tin là mẫu tìm kiếm cuối cùng. Việc gọi
các dịch vụ ra yêu cầu sử dụng thông tin mẫu kèm theo, thông thường được
lưu trữ tạm thời bởi các máy trạm để sử dụng lặp đi lặp lại mà không cần gửi
lại bản ghi cho cùng một thông tin mà máy trạm cần. Nếu thông tin đính kèm
thay đổi, máy trạm cần phải gửi lại bản ghi để cập nhật lại thông tin. Đây
chính là mẫu tìm kiếm viện dẫn thông tin.

Số hóa bởi trung tâm học liệu
17
Lưu và xóa (với hàm API save_xxx và delete_xxx) có thể được thực hiện
trên mỗi đầu mục ở cấp cao nhất, tên các hàm tự giải thích chức năng của nó, nhưng
lưu ý rằng cách thức lưu trữ của toán tử save trong UDDI thông thường mang tính

phá hủy. Ví dụ, việc tái lưu trữ (resave) cùng một dịch vụ với thông tin khác sẽ là sự
thay thế hoàn toàn thông tin cũ bằng thông tin mới (hay còn gọi là ghi đè).
Toán tử gắn với authTokens yêu cầu phải đăng ký trước với một nốt UDDI
Business Registry cụ thể và cung cấp thông tin xác thực cần thiết để thành lập một
sự thống nhất của nhà phát hành thông tin. Những thông tin xác thực này được sử
dụng để lấy mộtauthToken để thực hiện một toán tử xuất thông tin (với hàm
APIsave_xxx). authToken có thể được tái sử dụng với thời gian ngắn trong khi các
toán tử xuất thông tin chưa bị hết hạn. Chính sách toán tử quyết định cả nội dung và
thời gian tồn tại của một authToken.
1.4.2. Cấu trúc dữ liệu UDDI
Thông tin được chứa trong một đăng ký UDDI bao gồm năm kiểu khác nhau:
businessEntity hoặc tổ chức công ty thực tế. Điều này có thể có nghĩa là toàn
bộ tổ chức hoặc nó có thể là một tổ chức liên kết hoặc chi nhánh.
publisherAssertion hoặc mối quan hệ giữa businessEntities. Để hợp lệ
publisherAssertions phải được cả hai bên yêu cầu, trừ khi cả hai thực thể có
trách nhiệm với chủ báo hoặc trừ khi cả hai thực thể được nhập vào trong
đăng ký bằng một tài khoản người dùng giống nhau.
bindingTemplate, về cơ bản là đặc tả của một giao diện của một dịch vụ.
Nhiều businessServices có thể thực hiện businessServices.
businessService hay một dịch vụ do một doanh nghiệp cung cấp. Bây giờ,
điều đó có vẻ đơn giản, nhưng trong thế giới của UDDI, điều đó không nhất
thiết có nghĩa là nó là một dịch vụ Web. Ví dụ, thực sự có thể xác định dịch
vụ hỗ trợ điện thoại của doanh nghiệp của (có nghĩa là số điện thoại thực tế
mà người dùng quay số và tất cả mọi thứ mà đi kèm với nó) như một dịch vụ
UDDI. Tất nhiên, sẽ không có một tài liệu WSDL giả, nhưng nó sẽ là một
dịch vụ được doanh nghiệp của cung cấp.