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

ĐẠ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


ĐẠ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


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


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


iii

MỤC LỤC
1. Đặt vấn đề.................................................................................................1


iv

DANH MỤC HÌNH
1. Đặt vấn đề.................................................................................................1


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.


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.


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).


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.


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"?>

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>

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ả


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! -->

Normal

<em>emphasized

<strong>strong

emphasized</em>

strong</strong>

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:


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:
•

& (&)

•

< (<)

•

> (>)

•

' (')

•

" (")

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&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


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"?>
<!ENTITY copy "©">
Enterprises">
]>
<root>
©right-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&T</tên-công-ty>
<tên-công-ty>AT&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.


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.


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.


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:
+ Request messages: Với các tham số gọi thực thi một service


12

+ 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.
- Giao thức và kiểu mã hóa sẽ được sử dụng khi gọi các hàm của web
service.
- Loại thông tin: những thao tác, những tham số, và những kiểu dữ liệu gồm
có giao diện của web service, cộng với tên cho giao diện này.
Một WSDL hợp lệ gồm có hai phần:
1. Phần giao diện mô tả giao diện và giao thức kết nối.
2. Phần thi hành mô tả thông tin để truy xuất service


13

Cả 2 phần trên sẽ được lưu trong 2 tập tin XML, bao gồm:
- Tập tin giao diện service (cho phần 1).
- Tập tin thi hành service (cho phần 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>
<binding>
[...]


14

</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.
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


15

đồ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.
Inquiry Operations:
Find
find_business

Publishing Operations:

Save
save_business


16

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.
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


17

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.

•

tModels hoặc các mô hình siêu dữ liệu. Khi nghiên cứu UDDI, Francis đi
đến kết luận rằng tModel có lẽ là lý do lớn nhất tại sao UDDI đã không cất
cánh như mong đợi. Như một đăng ký của các dịch vụ, sẽ mong đợi tìm thấy


18

một cách để trực tiếp xác định giao diện cho một dịch vụ, như WSDL thực
hiện. Nhưng, như đã nói, UDDI đã chưa bao giờ được dự định là độc quyền
về các dịch vụ Web và được thiết kế với linh hoạt hơn nữa. tModels thực
hiện trợ giúp trỏ đến các tài liệu XML, như chúng ta sẽ thấy sau này, nhưng
trong thực tế chúng có nghĩa là một cách tổng quát để xác định thông tin về
thứ gì đó, thông qua dịch vụ, một doanh nghiệp hay bất cứ điều gì khác.
UDDI nổi danh là quá phức tạp, nhưng với cốt lõi của mình UDDI thuộc về
năm kiểu dữ liệu được mô tả ở trên, được kết hợp với bốn hoạt động: tìm
kiếm, nhận, lưu và xóa. Nói cách khác, đặc tả UDDI lưu ý những điều sau đây để
có thể thực hiện với dữ liệu:
•

find_xx: Những phương thức này, chẳng hạn như find_businessEntity,
find_businessService và v.v, cung cấp một cách để tìm kiếm một bản ghi
trong đăng ký UDDI. Những phương thức này trả về khóa để nhận dạng đối
tượng.

•

get_xx: Một khi có khóa duy nhất nhận dạng một đối tượng, có thể sử
dụng get_xx methods, nhưget_businessService và v.v, để lấy ra chính đối
tượng thực tế đó. Ví dụ, get_businessService trả về toàn bộ đối tượng
businessService, từ đó thu được bất kỳ thông tin nào mà cần.

•

save_xx: Như có thể đã đoán được, các phương thức này thêm thông tin vào
cơ sở dữ liệu hoặc chúng thay đổi thông tin đã có trong cơ sở dữ liệu.

•

delete_xx: Những phương thức này, chẳng hạn delete_binding Template,
delete_tModel, và v.v, lấy khóa duy nhất của đối tượng làm tham số và loại
bỏ nó khỏi cơ sở dữ liệu. Hành vi thực tế của các phương thức này phụ thuộc
vào những gì đang xóa. Ví dụ, vì tModels thường xuyên được các đối tượng
khác trong cơ sở dữ liệu tham chiếu, nên chúng có thể không thực sự bị xóa.
Hầu như tất cả mọi thứ của UDDI dựa trên 20 phân cắt giữa năm đối tượng

(businessService, bindingTemplate, publisherAssertion, businessEntity và tModel) và
bốn hành động (find, get, save và delete).


19

1.5. Các dịch vụ web hiện nay đã phát triển
Hiện nay trên phương diện về dịch vụ web đang phát triển càng ngày càng đa
dạng với nhiều lĩnh vực khác nhau. Vào những năm 2000 khi công nghệ thông tin
Việt Nam còn đang chập chững trước ngưỡng cửa thông tin toàn cầu thì việc triển

khai dịch vụ web vẫn còn rất nghèo nàn về công nghệ dịch vụ web lẫn kỹ thuật.
Việc triển khai công nghệ thông tin sau nhiều năm đã giúp Việt Nam có
được những thành tựu to lớn với các công nghệ tiên tiến và bám sát với cộng đồng
công nghệ mạng thế giới. Cụ thể thông qua các nhà cung cấp dịch vụ mạng Việt
Nam ngày càng nhiều và ngày càng chất lượng.
Ứng dụng web trở nên phổ biến nên dịch vụ mạng trở thành một tiềm năng
khai thác cho rất nhiều doanh nghiệp. Từ việc quản lý nhân viên, quản lý hồ sơ,
quản lý điểm học tập... cho đến giáo dục đào tạo từ xa. Tất cả đều có thể thông qua
ứng dụng dịch vụ mạng để thực hiện công việc trực tuyến.
Một số ứng dụng mạng hiện nay đang phát triển có thể kể đến như:
-

Mạng thanh toán PayNet

-

Mạng xã hội Facebook

-

Mạng chia sẻ ngang hàng Torrent

…
1.6. Tình hình nghiên cứu hiện nay trong và ngoài nước
Với sự phát triển và ứng dụng mạnh mẽ của công nghệ SOA vào các quy
trình nghiệp vụ và đang mang lại một lợi ích lớn cho các tổ chức và doanh nghiệp.
Đi đôi với kiến trúc SOA là sự phát triển của các ngôn ngữ mô hình hóa các quy
trình nghiệp vụ như: XPDL, BPML,BPEL…. Nó giúp cho các lập trình viên và các
nhà sử dụng dịch vụ đơn giãn hóa việc tổng hợp cũng như xây dựng các dịch vụ
riêng cho mình. Chúng không phải là một ngôn ngữ được sử dụng cho việc phân

tích thiết kế và được thể hiện bằng một bộ cú pháp xml và có các giao thức riêng
của mình, chúng không có một ngôn ngữ riêng cụ thể nào cả mà chỉ được thể hiện
qua các giao diện đồ họa, cũng không có một chuẩn ký hiệu chung cho các ngôn
ngữ này. Trong các ngôn ngữ trên thì BPEL là ngôn ngữ được sử dụng rộng rãi