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

Ứng dụng BPEL trong việc kết hợp và thay thế dịch vụ web

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



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



HOÀNG HUY TÙNG

ỨNG DỤNG BPEL TRONG VIỆC KẾT
HỢP VÀ THAY THẾ DỊCH VỤ WEB

Ngành: CÔNG NGHỆ THÔNG TIN
Chuyên ngành: CÔNG NGHỆ PHẦN MỀM
Mã số: 60 48 10

Hà nội, 2012



LUẬN VĂN THẠC SĨ ……………………
3

Mục lục

Danh sách các hình vẽ 5
Danh sách các bảng biểu 6
Bảng ký hiệu các chữ viết tắt 7
Mở đầu 8
Chương 1: Tổng quan về dịch vụ Web 10
1.1. XML 10


1.1.1. Cấu trúc Logic 11
1.1.2. Cấu trúc vật lý 12
1.2. Dịch vụ Web 12
1.2.1. SOAP 13
1.2.2. WSDL 13
1.2.3. UDDI 15
Chương 2: Ngôn ngữ BPEL 17
2.1. Giới thiệu 17
2.2. Các khái niệm cơ bản 19
2.2.1. Cấu trúc của tiến trình WS-BPEL 19
2.2.2. Partner Link Types 19
2.2.3. Partner Links 20
2.2.4. Endpoint References 20
2.2.5. Correlation 20
2.2.6. Các hành động cơ bản 22
2.2.7. Các hành động cấu trúc 26
Chương 3 : Hệ thống Đại lý phân phối 31
3.1. Giới thiệu 31
3.2. Mô tả bài toán 32
3.2.1. Mục đích của phần mềm 32
3.2.2. Phạm vi bài toàn 32
3.2.3. Quy trình của hệ thống 33
4

3.2.4. Các chức năng chính 34
3.2.5. Chi tiết các chức năng 34
3.3. Thiết kế 38
3.3.1. Các biểu đồ trình tự 38
3.3.2. Thiết kế chi tiết 43
3.4. Chi tiết việc kết hợp và thay thế service trên hệ thống đại lý phân phối 43

3.4.1. Ví dụ về thanh toán tiền điện thoại sử dụng việc kết hợp các dịch vụ 43
3.4.2. Ví dụ việc đặt chỗ khách sạn sử dụng việc thay thế các dịch vụ 45
Kết luận 48
Tài liệu tham khảo 49
Phụ lục 50



5

Danh sách các hình vẽ

Hình 1.1 Cấu trúc của tài liệu WSDL 14
Hình 2.1 Ví dụ tiến trình WS-BPEL 18
Hình 3.1 Biểu đồ Use Case quy trình nghiệp vụ của hệ thống 33
Hình 3.2 Biểu đồ Use Case tổng quan của hệ thống đại lý phân phối 34
Hình 3.3: Biểu đồ Use case quản lý các đại lý phân phối 35
Hình 3.4 Biểu đồ Use Case tạo dịch vụ kết nối với đại lý phân phối 36
Hình 3.5 Biểu đồ Use Case quản lý Service 36
Hình 3.6 Biểu đồ Use Case quản lý KW và SC 37
Hình 3.7 Biểu đồ trình tự việc tạo dịch vụ 39
Hình 3.8 Biểu đồ trình tự việc cập nhật thông tin dịch vụ 39
Hình 3.9 Biểu đồ trình tự việc xóa dịch vụ 40
Hình 3.10 Biểu đồ trình tự việc tạo kịch bản dịch vụ 41
Hình 3.11 Biểu đồ trình tự việc kết hợp dịch vụ 42
Hình 3.12 Biểu đồ trình tự việc loại bỏ dịch vụ 42
Hình 3.13 Biểu đồ thiết kế chi tiết việc quản lý Service 43
Hình 3.14 Biểu đồ thiết kế chi tiết việc quản lý KW và SC 43
Hình 3.15 Biểu đồ tiến trình nghiệp vụ WS-BPEL việc thanh toán tiền điện thoại 45
Hình 3.16 Biểu đồ tiến trình nghiệp vụ WS-BPEL việc đặt chỗ khách sạn 47


6

Danh sách các bảng biểu

Bảng 3.1 Bảng dữ liệu Agent 35
Bảng 3.2 Bảng dữ liệu Service 37
Bảng 3.3 Bảng dữ liệu KW và SC 38
7

Bảng ký hiệu các chữ viết tắt

KW
: Keyword, từ khóa của dịch vụ
SC
: Shortcode, đầu số của dịch vụ
Agent
: Đại lý phân phối
WS
:Web Service
WSDL
:Web service Definition Language
WS-BPEL
:Web Service Business Process Execution Language
XML
:Extensible Markup Language
XSD
:XML Schema Definition
SOAP
:Simple Object Access Protocol

HTTP
:Hypertext Transfer Protocol













8

Mở đầu

Lý do chọn đề tài
Ngày nay, cùng với sự phát triển không ngừng của khoa học kỹ thuật, hàng loạt
công nghệ mới ra đời phục vụ cho nhu cầu về cuộc sống của con người. Sự tiện lợi của
Internet đã làm cho các dịch vụ Web phát triển mạnh, với rất nhiều nhà cung cấp cung
cấp dịch vụ khác nhau, cung cấp các dịch vụ khách hàng. Tuy nhiên việc tạo ra các
dịch vụ kết hợp là tương đối khó khăn. Đặc biệt, việc kết hợp các dịch vụ từ nhiều nhà
cung cấp khác nhau đòi hỏi rất nhiều yếu tố. Thứ nhất là phải có sự thống nhất giữa
các bên trong việc kết hợp. Thứ hai là phải thay đổi mã nguồn của các dịch vụ cần kết
hợp. Việc thay đổi mã nguồn mã nguồn đôi khi xảy ra thường xuyên khi một dịch vụ
thay đổi các thông tin về địa chỉ cung cấp dịch vụ.
Thông thường các dịch vụ Web tồn tại trong những khoảng thời gian nhất định,

khách hàng thường không theo dõi được khoảng thời gian hiệu lực của các dịch vụ đó,
rất nhiều người sử dụng, sử dụng các dịch vụ Web không còn hiệu lực nữa, trong khi
có nhiều dịch vụ tương tự như dịch vụ họ mong muốn đang được cung cấp bởi nhiều
nhà cung cấp dịch vụ khác. Từ đó nẩy sinh việc thay thế các dịch vụ từ các nhà cung
cấp dịch vụ khác nhau khi các nhà cung cấp trước đó ngừng cung cấp các dịch vụ hiện
tại, hoặc là chất lượng của các dịch vụ đang cung cấp không đáp ứng được yêu cầu của
khách hàng mong muốn.
Kết quả đạt được
Đề tài đã tập trung nghiên cứu tổng quan về dịch vụ Web bao gồm các khái
niệm cơ bản các chuẩn và các giao thức, ngôn ngữ XML. Tập trung vào ngôn ngữ định
nghĩa hành vi của một tiến trình nghiệp vụ WS-BPEL để định nghĩa các tiến trình
nghiệp vụ đáp ứng các yêu cầu khách hàng. Qua đó, tác giả đã xây dựng hệ thống đại
lý phân phối, thực hiện trao đổi thông tin thông từ các dịch Web được cung cấp bởi
các nhà cung cấp dịch vụ khác nhau, cụ thể của việc đó là kết hợp và thay thế các dịch
vụ Web đó.
Ý nghĩa khoa học và thực tiễn của đề tài
Mục tiêu của việc phát triển các ứng dụng Web là đạt được khả năng tương tác
giữa các ứng dụng. Các ứng dụng có thể được xây dựng bởi các ngôn ngữ lập trình
khác nhau như: C#, Java , hay chạy trên nhiều hệ điều hành khác nhau như: Window
hay Linux cũng dễ dàng tương tác với nhau. Người ta có thể dùng nhiều cách khác
nhau để thực hiện việc tương tác, trong đó có một phương pháp là sử dụng ngôn ngữ
định nghĩa hành vi tiến trình nghiệp vụ WS-BPEL. Trong trường hợp này, dịch vụ
Web tạo ra được gọi là dịch vụ Web kết hợp (Composite Web service), dịch vụ Web
9

được dùng để tạo ra dịch vụ Web kết hợp gọi là dịch vụ thành phần (Composed
service hay là Element service).
Kết quả nghiên cứu của đề tài luận văn này có thể được áp dụng cho các công
ty cung cấp các dịch vụ khách hàng. Giúp họ dễ dàng trong việc kết hợp và thay thế
các dịch vụ Web được cung cấp bởi các nhà cung cấp dịch vụ khác nhau.

Kết cấu của luận văn
Ngoài phần mở đầu, danh mục ký hiệu viết tắt, mục lục, danh mục tài liệu tham
khảo, phụ lục và phần kết luận, nội dung của luận văn gồm ba chương.
Chương 1: Tổng quan về dịch vụ Web.
Chương này giới thiệu về XML, các khái niệm cơ bản về dịch vụ Web bao gồm
các chuẩn và các giao thức như SOAP, WSDL
Chương 2: Ngôn ngữ BPEL.
Trong chương này tập trung nghiên cứu về ngôn ngữ định nghĩa hành vi các
tiến trình nghiệp vụ WS-BPEL. Giải thích các khái niệm cơ bản, cấu trúc của một tiến
trình WS-BPEL và các thành phần của ngôn ngữ.
Chương 3: Hệ thống đại lý phân phối
Trong chương này tập trung xây dựng hệ thống đại lý phân phối kết hợp và thay
thế các dịch vụ Web bằng cách định nghĩa và xử lý các tiến trình nghiệp vụ thông qua
ngôn ngữ WS-BPEL.






10

Chương 1: Tổng quan về dịch vụ Web

Ngày nay, việc phát triển các ứng dụng có thể dựa trên rất nhiều ngôn ngữ lập trình
khác nhau như C#.net, Java…Các ứng dụng này cũng được chạy trên nhiều hệ điều
hành khác như: Window hay Linux. Tuy nhiên, do sự phát triển độc lập về ngôn ngữ
và nền tảng như vậy dẫn đến những khó khăn nhất định trong việc trao đổi thông tin
giữa các ứng dụng khác nhau. Có một cách giúp cho việc trao đổi thông tin giữa các
ứng dụng hết sức dễ dàng đó là sử dụng dịch vụ Web. Mục đích của dịch vụ Web ra là

nỗ lực để đạt được khả năng tương tác giữa các ứng dụng bằng việc sử dụng các chuẩn
Web. Trong chương này tác giả xin giới thiệu tổng quan về dịch vụ Web bao gồm:
ngôn ngữ XML phục vụ nhu cầu trao đổi dữ liệu giữa các dịch vụ Web, giao thức
SOAP, tài liệu WSDL và UDDI.
1.1. XML
XML (Extensible Markup Language) là một ngôn ngữ đơn giản, linh hoạt trong việc
định dạng văn bản, có nguồn gốc từ SGML (ISO 8879). Ban đầu được thiết kế để đáp
ứng những thách thức của sản xuất điện tử quy mô lớn, XML cũng đóng một vai trò
ngày càng quan trọng trong việc trao đổi đa dạng dữ liệu trên Web [3].
Mục đích của tài liệu XML là để lưu trữ dữ liệu có cấu trúc, đơn giản và gọn nhẹ, giúp
cho việc chia sẻ dữ liệu giữa các hệ thống khác nhau dễ dàng, đặc biệt là các hệ thống
kết nối Internet. Dưới đây là ví dụ về việc lưu trữ dữ liệu học viên cao học sử dụng
XML:
<hocviencaohoc>
<hocvien id = “1”>
<hoten>Nguyen Van A</hoten>
<mahv>000001</mahv>
<namsinh>01/01/1980</namsinh>
<gioitinh>Nam</gioitinh>
<lop>cnpm3</lop>
<khoahoc>2009-2011</khoahoc>
</hocvien>
<hocvien id = “2”>
<hoten>Nguyen Van B</hoten>
<mahv>000002</mahv>
<namsinh>01/01/1981</namsinh>
<gioitinh>Nu</gioitinh>
<lop>cnpm3</lop>
<khoahoc>2009-2011</khoahoc>
</hocvien>

<hocvien id = “3”>
<hoten>Nguyen Van C</hoten>
<mahv>000003</mahv>
<namsinh>01/01/1982</namsinh>
<gioitinh>Nam</gioitinh>
11

<lop>cnpm3</lop>
<khoahoc>2009-2011</khoahoc>
</hocvien>
</hocviencaohoc>
- Thẻ root trong ví dụ trên là <hocviencaohoc>, tất cả các thẻ <hocvien> là các
thành phần bên trong thẻ <hocviencaohoc>.
- Dữ liệu về từng học viên được lưu trong các cặp thẻ <hocvien>, thuộc tính id để
phân biệt các học viên với nhau.
- Trong thẻ <hocvien> có 6 thành phần lưu trữ các thông tin tương ứng về học
viên là <hoten>: họ tên của học viên, <mahv>: mã học viên, <namsinh>: năm
sinh của học viên, <gioitinh>: giới tính của học viên, <lop>: lớp của học viên,
<khoahoc>: khóa học của học viên.
1.1.1. Cấu trúc Logic
Mỗi tài liệu XML chứa đựng một hay nhiều thành phần (element), ranh giới của các
thành phần đó được phân tách bới bắt đầu và kết thúc các thẻ (start and end Tags) hay
là các thành phần trống (empty – element tag). Mỗi thành phần có một kiểu, xác định
bởi tên, một vài cái gọi là “generic identifier” và có lẽ có một bộ các thuộc tính cụ thể.
Mỗi thuộc tính xác định tên và giá trị.
Một thành phần (element) là hợp lệ nếu nó có khai báo elementdecl nơi khai báo Name
theo thành phần kiểu và một trong các điều sau đây:
- Khai báo Empty phù hợp với thành phần không có nội dung (thậm chí là không
tham chiếu thực thể, ghi chú, hướng dẫn xử lý (Processing instructions) hay
khoảng không)

- Khai báo phù hợp với các con và chuỗi của các thành phần con được sinh ra bởi
ngôn ngữ bằng các biểu thức quy tắc trong mô hình nội dung, với các khoảng
không tùy chọn, chú thích và hướng dẫn xử lý giữa các thẻ bắt đầu và thành
phần con đầu tiên, giữa các thành phần con hay giữa thành phần con cuối cùng
và thẻ kết thúc. Lưu ý một đoạn CDATA chứa đựng duy nhất không gian trống
hay tham chiếu đến một thực thể có thay thế văn bản là các ký tự tham chiếu
mở rộng đến không gian trống.
- Khai báo Mixed, và các nội dung (sau khi thay thế bất kỳ thực thể tham chiếu
với một đoạn văn bản thay thế) chứa đựng ký tự dữ liệu (bao gồm các đoạn
CDATA), chú thích, hướng dẫn xử lý và thành phần con có kiểu phù hợp với
tên trong mô hình nội dung.
- Khai báo ANY, và các nội dung (sau khi thay thế bất kỳ thực thể tham chiếu
với một đoạn văn bản thay thế) chứa đựng các ký tự dữ liệu (bao gồm các đoạn
12

CDATA), ghi chú, hướng dẫn xử lý và các thành phần con có kiểu đã được khai
báo.
1.1.2. Cấu trúc vật lý
Một tài liệu XML có thể chứa đựng một hay nhiều các đơn vị lưu trữ gọi là các thực
thể (entities), tất cả đều có nội dung và tất cả (ngoại trừ các thực thể tài liệu và tập con
DTD bên ngoài) được xác định bởi tên thực thể. Mỗi tài liệu XML có duy nhất một
thực thể gọi là thực thể tài liêu (document entity), phục vụ như là điểm khởi đầu cho
bộ xử lý XMl và có thể chứa đựng toàn bộ tài liệu.
Các thực thể có thể được phân tích cú pháp hoặc không.
- Nội dung của một thực thể phân tích cú pháp được gọi là văn bản thay thế của
nó, văn bản này được coi là một phần của tài liệu.
- Một thực thể không được phân tích cú pháp là một nguồn tài nguyên có các nội
dung có thể hay không thể là văn bản, và nếu là văn bản có thể khác hơn so với
XML. Mỗi thực thể không được phân tích cú pháp có một ký hiệu liên quan,
xác định bởi tên.Ngoài yêu cầu là bộ xử lý XML tạo ra các định danh cho các

thực thể và ký hiệu sẵn có cho ứng dụng, XML không có ràng buộc về nội dung
của các thực thể không được phân tích cú pháp
Các thực thể phân tích cú pháp được gọi theo tên bằng cách sử dụng thực thể tham
chiếu, các thực không được phân tích bằng tên, mang đến giá trị của thực thể hay các
thuộc tính của các thực thể
General entities (các thực thể thông thường) là các thực thể để sử dụng bên trong nội
dung tài liệu. Trong đặc điểm kỹ thuật này, các thực thể chung đôi khi được gọi với
thuật ngữ là thực thể không đủ tiêu chuẩn
Parameter Entities (Các tham số thực thể) là các thực thể được phân tích cú pháp sử
dụng bên trong DTD (Document Type Definition). Hai loại của các thực thể sử dụng
các hình thức khác nhau của tài liệu tham khảo và được công nhân trong các ngữ cảnh
khác nhau. Hơn nữa, chúng chiếm không gian tên khác nhau; tham số thực thể và thực
thể chung với cung tên là hai thực thể phân biệt.
1.2. Dịch vụ Web
Dịch vụ Web (Web Service) là một hệ thống phần mềm được thiết kế để hỗ trợ tương
tác giữa máy với máy thông qua mạng. Nó là một giao diện được mô tả trong một định
dạng mà máy có thể hiểu được (cụ thể là WSDL). Các hệ thống khác nhau tương tác
với dịch vụ Web trong một cách thức theo quy định bằng các mô tả sử dụng thông báo
SOAP, thường truyền tải bằng cách sử dụng HTTP với một định dạng XML kết hợp
với các chuẩn Web khác [5].

13

1.2.1. SOAP
Ban đầu được định nghĩa là Simple Object Access Protocol, là một giao thức đặc tả
cho phép trao đổi thông tin có cấu trúc trong việc thực thi các dịch vụ Web trong mạng
máy tính. Nó dựa trên Extensible Markup Language (XML) cho các định dạng thông
báo, và thường dựa trên các giao thức tầng ứng dụng, đáng chú ý nhất là Hypertext
Transfer Protocol (HTTP) và Simple Mail Transfer Protocol (SMTP), cho việc thỏa
thuận và trao đổi thông báo. Soap có thể tạo thành một tầng cơ bản của một ngăn sếp

các giao thức dịch vụ Web, cung cấp một khung thông báo cơ bản trên đó các dịch vụ
Web được xây dựng. Giao thức dựa trên XML chứa đựng 3 phần: vỏ định nghĩa các
thông báo bên trong và làm thế nào xử lý nó, một bộ các quy tắc mã hóa cho việc thể
hiện các trường hợp của kiểu dữ liệu ứng dụng được định nghĩa, và một quy ước đại
diện cho các thủ tục gọi và phản hồi. Soap có 3 đặc điểm chính: khả năng mở rộng (an
ninh và định tuyến dịch vụ Web là một trong các phần mở rộng được phát triển), trung
lập (Soap có thể được sử dụng thông qua bất kỳ giao thức vận chuyển nào như HTTP,
SMTP hay thậm chí là TCP), và độc lập (SOAP cho phép bất kỳ mô hình lập trình
nào).
Theo W3C, SOAP (Simple Object Access Protocol) cung cấp một cơ chế đơn giản và
gọn nhẹ để trao đổi thông tin giữa các điểm trong môi trường phân cấp, phân tán sử
dụng XML có cấu trúc và kiểu. SOAP không phải xác định bất kỳ ngữ nghĩa ứng dụng
nào như là mô hình lập trình hay ngữ nghĩa thực hiện cụ thể, nó định nghĩa một cơ
chế đơn giản cho việc thể hiện ngữ nghĩa của ứng dụng bằng cách cung cấp mô hình
gói các module và cơ chế mã hóa cho việc mã hóa dữ liệu trong các module. Điều đó
cho phép Soap sử dụng trong đa dạng các hệ thống khác nhau từ hệ thống nhắn tin tới
RPC (Remote Procedure Call) [4].
1.2.2. WSDL
WSDL (Web Service Definition Language) là định dạng XML để mô tả dịch vụ mạng
như là một tập hợp các thiết bị đầu cuối hoạt động dựa trên các thông báo có chứa
thông tin hướng tài liệu hoặc là hướng thủ tục. Phương thức và thông báo được mô tả
trừu tượng, bị ràng buộc vào một giao thức mạng cụ thể và định dạng thông báo để
định nghĩa một thiết bị đầu cuối. Các điểm cuối liên quan cụ thể được kết hợp thành
một điểm cuối trừu tượng (dịch vụ). WSDL được mở rộng để cho phép mô tả các thiết
bị đầu cuối và các thông báo của nó bất kể thông báo có định dạng gì hay giao thức
mạng nào được sử dụng để giao tiếp [6].
a. Cấu trúc của tài liệu WSDL
Một tài liệu WSDL đơn giản là tập hợp các định nghĩa. Có một thành phần là gốc
(root) và các định nghĩa bên trong nút gốc, bao gồm sáu thành phần chính.
Cấu trúc của tài liệu WSDL được mô tả trong hình bên dưới:

14

WSDL
Types Message PortType Binding Port Service

Hình 1.1 Cấu trúc của tài liệu WSDL
Sáu thành phần chính trong tài liệu WSDL bao gồm:
- Types: cung cấp các định nghĩa kiểu dữ liệu sử dụng để mô tả cho việc trao đổi thông
báo
- Message: thể hiện một định nghĩa trừu tượng của dữ liệu được truyền. Một thông báo
bao gồm các phần logic, mỗi phần được liên kết với một định nghĩa các kiểu của hệ
thống.
- PortType: là tập hợp các phương thức trừu tượng. Mỗi phương thức đề cập đến các
thông báo vào và ra.
- Binding: quy định các giao thức cụ thể và định dạng dữ liệu cho các phương thức và
thông báo được định nghĩa bởi một porttype cụ thể.
- Port: xác định một địa chỉ liên kết, xác định thiết bị đầu cuối giao tiếp duy nhất.
- Service: sử dụng để tổng hợp các port liên quan.
b. Types
Thành phần Types nằm trong định nghĩa kiểu dữ liệu. Đối với khả năng tương thích tối
đa và các nền tảng độc lập, WSDL sử dụng XSD giống như một hệ thống kiểu kinh
điển, và xử lý nó như một hệ thống kiểu nội tại.
<definitions >
<types>
<xsd:schema />*
</types>
</definitions>
c. Messages
Message chứa đựng một hay nhiều phần logic. Mỗi phần tương thích với một kiểu từ
các kiểu của hệ thống sử dụng thuộc tính kiểu thông báo. Các thiết lập thuộc tính của

15

kiểu thông báo được mở rộng. WSDL định nghĩa một số thuộc tính kiểu thông báo sử
dụng XSD gồm:
- Element: đề cập đến một thành phần XSD sử dụng QNAME
- Type: đề cập đến một kiểu XSD đơn giản hoặc phức tạp sử dụng QNAME
Thuộc tính các kiểu dữ liệu khác có thể được định nghĩa miễn là họ sử dụng một
namespace khác của tệp WSDL. Các yếu tố mở rộng ràng buộc cũng có thể sử dụng
các thuộc tính kiểu thông báo.
Cú pháp định nghĩa một thông báo như sau:
<definitions >
<message name="nmtoken"> *
<part name="nmtoken" element="qname"? type="qname"?/> *
</message>
</definitions>
Thuộc tính tên cung cấp một tên duy nhất trong số tất cả các thông báo được định
nghĩa trong tài liệu WSDL.
d. Port Types
Là một tập hợp các phương thức trừu tượng được đặt tên và các thông báo liên quan.
<wsdl:definitions >
<wsdl:portType name="nmtoken">
<wsdl:operation name="nmtoken" /> *
</wsdl:portType>
</wsdl:definitions>
WSDL có 4 cách truyền nguyên thủy bao gồm:
- One- way: chỉ duy nhất người dùng nhận thông báo đến.
- Request – Response: người dùng nhận một thông báo, và gửi lại một thông báo
tương ứng.
- Solicit – Response: người dùng gửi một thông báo, và nhận lại một thông báo
tương ứng.

- Notification: chỉ duy nhất người dùng gửi một thông báo đi và không nhận lại
bất kỳ thông báo nào.
1.2.3. UDDI
Theo OASIS, UDDI (Universal description, discovery and integration) định nghĩa một
đăng ký dịch vụ cho dịch vụ Web và các dịch vụ điện tử khác và các dịch vụ không
phải điện tử. Một đăng ký dịch vụ UDDI là một dịch vụ Web quản lý các thông tin về
nhà cung cấp dịch vụ, thực thi dịch vụ và dữ liệu dịch vụ. Nhà cung cấp dịch vụ có thể
sử dụng UDDI để quảng cáo các dịch vụ mà họ cung cấp. Người sử dụng dịch vụ có
16

thể sử dụng UDDI để khám phá các dịch vụ phù hợp với yêu cầu của họ và để có được
các dữ liệu thô cần thiết [8].
UDDI (Universal description, discovery and integration) là tên của một tổ Web dựa
trên đăng ký thông tin về doanh nghiệp hoặc các tổ chức và các giao diện kỹ thuật của
nó (API). Những đăng ký này được điều hành bởi nhiều nhà điều hành và có thể được
sử dụng bởi bất kỳ ai muốn các thông tin sẵn có về một hay nhiều doanh nghiệp hoặc
các tổ chức, cũng như bất kỳ ai muốn tìm các thông tin đó. Miễn phí sử dụng các dịch
vụ cơ bản được điều hành bởi các trang Web này [9].
17

Chương 2: Ngôn ngữ BPEL

Dịch vụ Web sử dụng mô hình tích hợp mềm dẻo để cho phép tích hợp linh hoạt các
hệ thống không đồng nhất trong đa dạng các lĩnh vực bao gồm kinh doanh với người
tiêu dùng, kinh doanh với kinh doanh và tích hợp ứng dụng doanh nghiệp. Có nhiều
cách khác nhau để có thể giao tiếp giữa các dịch vụ Web, một trong số đó là sử dụng
ngôn ngữ định nghĩa hành vi của tiến trình nghiệp vụ WS-BPEL (BPEL). Trong
chương này tác giả xin giới thiệu về WS-BPEL bao gồm các khái niệm, cách định
nghĩa một tiến trình nghiệp vụ và các hành động được định nghĩa bởi WS-BPEL.
2.1. Giới thiệu

Web Service Business Process Execution Language (viết tắt là WS-BPEL hay được
gọi là BPEL) là một ngôn ngữ xác định hành vi của tiến trình nghiệp vụ dựa trên dịch
vụ Web. Tiến trình trong WS-BPEL xử lý các chức năng xuất và nhập bằng cách sử
dụng độc quyển dịch vụ Web [2].
Tiến trình nghiệp vụ có thể được mô tả bằng hai cách: các tiến trình nghiệp vụ thực thi
(Executable business processes) trong mô hình hành vi thực tế của một người tham gia
trong một tương tác nghiệp vụ. Một quá trình trừu tượng (Abstract Process) có thể ẩn
một số các yêu cầu chi tiết liên quan đến vận hành. Quá trình trừu tượng phục vụ vai
trò mô tả, với nhiều hơn một trường hợp có thể sử dụng, bao gồm cả hành vi quan sát
và quá trình mẫu. WS-BPEL có nghĩa là sử dụng để mô hình hành vị của cả tiến trình
thực thi và trừu tượng.
WS-BPEL cung cấp một ngôn ngữ cho việc đặc tả tiến trình nghiệp vụ thực thi và trừu
tượng. Bằng cách đó, nó mở rộng mô hình tương tác dịch vụ Web và cho phép hỗ trợ
các giao dịch kinh doanh. WS-BPEL định nghĩa một mô hình tích hợp tương thích cho
phép mở rộng các tiến trình một cách tự động ở cả trong nội bộ công ty và trong không
gian kinh doanh với kinh doanh.
Ví dụ tiến trình nghiệp vụ tra cứu kết quả sổ xố sử dụng ngôn ngữ WS- BPEL sử dụng
công cụ GlashFish ESB v2.2 [7]: khách hàng nhắn tin đến tổng đài dịch vụ theo cú
pháp xác định, hệ thống sẽ nhận tin nhắn của khách hàng gọi đến dịch vụ của đối tác,
đối tác xử lý và trả lại kết quả cho hệ thống, hệ thống nhận kết quả và trả lại cho khách
hàng.
- Các Web service thuộc tiến trình nghiệp vụ:
o WS giao tiếp với khách hàng: tracuuketquasoxo.
o WS đối tác cung cấp xử lý việc lấy ra kết quả sổ xố: ketquasoxo.

18


Hình 2.1 Ví dụ tiến trình WS-BPEL
- Các bước thực hiện:

o Bắt đầu tiến trình nghiệp vụ, khách hàng nhắn tin đến tiến trình nghiệp
vụ để sử dụng dịch vụ (cụ thể là gọi đến Web service giao tiếp với khách
hàng: tracuuketquasoxo).
o Tiến trình nghiệp vụ nhận yêu cầu thông qua hành động Receive (nhận
giá trị đầu vào từ WS khách hàng gọi đến).
o Tiến trình nghiệp vụ xử lý dữ liệu đầu vào của khách hàng, và gán cho
giá trị đầu vào của WS đối tác cung cấp thông qua hành động Assign.
o Thực hiện gọi đến WS đối tác cung cấp (ketquasoxo) (với dữ liệu đầu
vào xử lý ở bước trên) thông qua hành động Invoke và nhận kết quả trả
về từ WS đó.
o Tiến trình nghiệp vụ xử lý dữ liệu trả về từ đối tác và gán cho dữ liệu để
trả về cho khách hàng thông qua hành động Assign.
o Tiến trình nghiệp vụ trả lại kết quả cho khách hàng (dữ liệu đã được xử
lý ở bước trên) thông qua hành động Reply.
o Khách hàng nhận kết quả từ tiến trình nghiệp vụ (kết thúc tiến trình
nghiêp vụ).


19


2.2. Các khái niệm cơ bản
2.2.1. Cấu trúc của tiến trình WS-BPEL
Một tiến trình WS-BPEL chứa đựng các mối quan hệ với các đối tác bên ngoài, khai
báo các xử lý dữ liệu, xử lý các mục đích khác nhau và quan trọng nhất, các hành động
được thực hiện, trong đó khai báo tên và namespace là bắt buộc [1].
Cấu trúc của một tiến trình WS-BPEL được khai báo như sau:
<process name="PrimerProcess"
targetNamespace="
xmlns="

Basic Activities +
Structured Activities +
</process>
- Tên của tiến trình WS-BPEL: PrimerProcess.
- TargetNamespace: “ tiến trình
WS-BPEL sử dụng namespace theo địa chỉ URI được khai báo trên.
- Thuộc tính xmlns: "
xác định rằng đây là 1 tiến trình thực thi.
- Basic Acitivies: là các hành động cơ bản được WS-BPEL định nghĩa như:
Invoke, Receive, Assign, Reply để định nghĩa tiến trình nghiệp vụ.
- Structured Activities: là các hành động có cấu trúc được WS-BPEL định nghĩa
như: Sequence, If, While… để định nghĩa một tiến trình nghiệp vụ.
2.2.2. Partner Link Types
Một <partnerLinkType> đặc tả mối liên hệ giữa hai dịch vụ Web bằng cách định nghĩa
vai trò của mỗi dịch vụ trong mối liên hệ và quy định portType cụ thể cung cấp cho
mỗi dịch vụ bằng cách nhận các thông báo bên trong mối liên hệ cụ thể. Mỗi vai trò
đặc tả chính xác một WSDL portType.
Cú pháp khai báo <partnerLinkType>:
<plnk:partnerLinkType name="NCName">
<plnk:role name="NCName" portType="QName" />
<plnk:role name="NCName" portType="QName" />?
</plnk:partnerLinkType>
- Tên của partnerLinkType được khai báo trong thuộc tính name của thẻ
partnerLinkType.
- Hai thẻ bên trong nút gốc khai báo hai vai trò tương ứng với hai portType.

20

2.2.3. Partner Links
Tương tác giữa các dịch vụ với tiến trình nghiệp vụ được mô hình hóa giống như một

partner links trong WS-BPEL. Mỗi <partnerLink> được cụ thể hóa bằng một
partnerLinkType. Nhiều hơn một <partnerLink> có thể được cụ thể hóa bằng cùng một
partnerLinkType.
Cú pháp khai báo <partnerLink>:
<partnerLinks>
<partnerLink name="NCName"
partnerLinkType="QName"
myRole="NCName"?
partnerRole="NCName"?
initializePartnerRole="yes|no"? />+
</partnerLinks>
- Có thể khai báo nhiều partnerLink khác nhau trong thẻ <partnerLinks>.
- Tên của partnerLink được khai báo trong thuộc tính name của thẻ partnerLink.
- Thuộc tính partnerLinkType khai báo tên của partnerLinkType sử dụng.
- Thuộc tính myRole khai báo vai trò của tiến trình WS-BPEL.
- Thuộc tính partnerRole khai báo vai trò của đối tác.
- Thuộc tính initializePartnerRole xác định liệu bộ xử WS-BPEL cần thiết khởi
tạo giá trị partnerRole của một partnerLink hay không. Việc khởi tạo này không
ảnh hưởng đến giá trị của partnerRole sau khi khởi tạo nó. Nó chỉ là một quy
định để chắc chắn rằng đối tác sẽ luôn cung cấp dịch vụ trong quá trình triển
khai.
2.2.4. Endpoint References
Cơ bản việc sử dụng Endpoint Reference là để phục vụ như là cơ chế giao tiếp động
của các cổng dữ liệu cụ thể cho các dịch vụ. Một Endpoint Reference tạo sự sẵn sàng
trong WS–BPEL để có thể tự động lựa chọn nhà cung cấp dịch vụ cho một loại hình
cụ thể của dịch vụ và gọi đến các sự vận hành của chúng. WS–BPEL cung cấp một cơ
chế chung cho sự tương đồn giữa các thông báo với các thể hiện an toàn của một dịch
vụ thế cho nên Endpoint Reference mang đến các cổng thông tin trung lập thông
thường là đủ. Tuy nhiên, nói chung là cần thiết có thêm các thẻ nhận dạng trong chính
các Endpoint Reference.

2.2.5. Correlation
Correlation là một cơ chế theo dõi đa tiến trình, xuyên suốt quá trình trao đổi thông
báo mà thường diễn ra giưa một tiến trình WS-BPEL và các dịch vụ đối tác. Cơ chế
correlation giúp định tuyến các thông báo đến những tiến trình thích hợp.
21

Một thông báo trong một cuộc hội thoại được kết nối với một giá trị tổng hợp của một
hoặc nhiều các thuộc tính được định nghĩa trong tệp WSDL. Một thuộc tính là một
trường bên trong một thông báo được xác định bởi một truy vấn. Các truy vấn được
quy định bởi một cấu trúc đặc biệt gọi là các thuộc tính bí danh (property aliases)
Tập các Correlation được sử dụng hỗ trợ các trạng thái hợp tác giữa các dịch vụ Web
dựa theo chuẩn thực thi độc lập. Tập các Correlation dựa trên các thẻ dữ liệu
Correlation được lưu trữ trong vỏ của các thông báo, tiêu đề hay các tài liệu nghiệp vụ
tương tự. Khai báo Correlation dựa trên sự khai báo các thuộc tính của thông báo.
Các thuật ngữ liên quan áp dụng cho Corretation:
- Property: là một dấu hiệu để đặt tên. Nó phải là một kiểu đơn giản, được định
nghĩa trong một tệp tin WSDL
- Property Alias: là một quy tắc để cho môi trường thực thi WS-BPEL biết làm
thế nào để ánh xạ dữ liệu từ các thông báo đến một giá trị của Property. Bạn có
thể định nghĩa một số Property alias cho một property sẽ sử dụng giống như
một giá trị correlation.
- Correlation set: là một khóa hỗn hợp được tạo trên một hay nhiều giá trị
Property, thực tế là một bộ Property. Môi trường thực thi WS-BPEL sử dụng
khóa đó để chắc chắn rằng các thông báo được định tuyến đúng tiến trình cho
một hội thoại cụ thể. Tập các Correlation được định nghĩa trong tệp WS-BPEL.
- Correlations: đánh dấu các hoạt động, xác định các bộ Correlation bằng tên và
chỉ ra tập Correlation xảy ra trong các thông báo được gửi hoặc nhận.
Cú pháp khai báo <correlation>:
<correlations>
<correlation set="NCName"

initiate="yes|join|no"?
pattern="request|response|request-response"? />+
</correlations>
- Có thể khai báo nhiều <correlation> khác nhau trong thẻ <correlations>.
- Tên của correlation được khai báo trong thuộc tính set.
- Thuộc tính initiate xác định loại khởi tạo ban đầu của correlation có ba loại là:
“yes”, “join” hay “no” và có giá trị mặc định là “no”.
- Thuộc tính pattern sử dụng để chỉ ra sự tương quan áp dụng cho việc gửi các
thông báo theo các kiểu: “request”, “response” hay là “request-response”.
Correlation có thể được sử dụng trên mỗi hành động (<receive>,<reply>,<invoke>).

22

2.2.6. Các hành động cơ bản
Các hành động cơ bản thực hiện tiến trình logic. Các hoạt động được chia thành hai
lớp: cơ bản và cấu trúc. Hoạt động cơ bản là những mô tả các bước thành phần của
một tiến trình hành vi. Hoạt động cấu trúc mã hóa điều khiển luồng logic.
a. Invoke
Invoke sử dụng để gọi các dịch vụ Web được cung cấp bởi các nhà cung cấp dịch vụ.
Cụ thể là sử dụng để gọi một phương thức của một dịch vụ xác định. Hành động
Invoke có thể kèm theo các hành động khác như xử lý lỗi.
Cú pháp của hành động Invoke:
<invoke partnerLink="NCName"
portType="QName"?
operation="NCName"
inputVariable="BPELVariableName"?
outputVariable="BPELVariableName"?
standard-attributes>
standard-elements
<correlations>?

<correlation set="NCName" initiate="yes|join|no"?
pattern="request|response|request-response"? />+
</correlations>
<catch faultName="QName"?
faultVariable="BPELVariableName"?
faultMessageType="QName"?
faultElement="QName"?>*
activity
</catch>
<catchAll>?
activity
</catchAll>
<compensationHandler>?
activity
</compensationHandler>
<toParts>?
<toPart part="NCName" fromVariable="BPELVariableName" />+
</toParts>
<fromParts>?
<fromPart part="NCName" toVariable="BPELVariableName" />+
</fromParts>
</invoke>
- Thuộc tính parnerLink khai báo tên của partnerlink gọi đến.
- Thuộc tính portType khai báo tên của porttype gọi đến.
- Thuộc tính operation khai báo tên của phương thức được gọi đến.
- Thuộc tính inputVariable khai báo giá trị đầu vào gọi đến dịch vụ.
23

- Thuộc tính outputVariable khai báo giá trị trả về từ dịch vụ.
- Thẻ <correlations> liệt kê các correlation được sử dụng trong hành động

invoke.
- Thẻ <catch> định nghĩa việc xử lý trong các trường hợp không gọi được đến
dịch vụ, hay có lỗi xảy ra.
- Thẻ <toParts> cho phép khai báo một hay nhiều giá trị đầu vào có giá trị tương
ứng với giá trị thuộc tính inputVariable (chỉ khai báo ở inputVariable hoặc
<toPart> không khai báo ở cả hai nơi).
- Thẻ <fromParts> cho phép khai báo một hay nhiều giá trị trả về có giá trị tương
ứng với giá trị thuộc tính outputVariable (chỉ khai báo ở outputVariable hoặc
<fromPart> không khai báo ở cả hai nơi).
b. Receive
Hành động Receive xác định partnerLink có chứa myRole sử dụng để nhận thông báo,
portType
Cú pháp của hành động Receive:
<receive partnerLink="NCName"
portType="QName"?
operation="NCName"
variable="BPELVariableName"?
createInstance="yes|no"?
messageExchange="NCName"?
standard-attributes>
standard-elements
<correlations>?
<correlation set="NCName" initiate="yes|join|no"? />+
</correlations>
<fromParts>?
<fromPart part="NCName" toVariable="BPELVariableName" />+
</fromParts>
</receive>
- Thuộc tính parnerLink khai báo tên của partnerLink nhận thông báo.
- Thuộc tính portType khai báo tên của portType nhận thông báo.

- Thuộc tính operation khai báo tên của phương thức nhận thông báo.
- Thuộc tính variable khai báo giá trị đầu vào của dịch.
- Thuộc tính createInstance có giá trị mặc định là “no”. Nếu giá trị của thuộc tính
createInstance là “yes” thì hành động Receive sẽ là một trong các hành động
ban đầu của tiến trình nghiệp vụ WS-BPEL, trong trường hợp này, các hoạt
động đầu tiên được gọi sẽ bắt đầu tiến trình nghiệp vụ WS-BPEL.
24

- Thuộc tính messageExchange là tùy chọn được sử dụng để phân biệt mối quan
hệ giữa các hành động gửi thông báo đến và các hành động <reply>, việc sử
dụng messageExchange cần thiết khi việc thực thi có kết quả trong nhiều cặp
<receive> <reply> trên cùng một partnerLink và các hoạt động được thực hiện
đồng thời.
- Thẻ <correlations> liệt kê các correlation được sử dụng trong hành động
<Receive>.
- Thẻ <fromParts> cho phép khai báo một hay nhiều giá trị nhận từ hành động
<Receive> có giá trị tương ứng với giá trị thuộc tính variable (chỉ khai báo ở
variable hoặc <fromPart> không khai báo ở cả hai nơi).
Một tiến trình không được chứa hai hành động Receive có cùng partnerLink,
portType, operation và correlationSet.
c. Reply
Hành động Reply được sử dụng để gửi phản hồi đến một yêu cầu được chấp nhận
trước đó thông qua hành động gửi tin nhắn đến giống như hành động Receive. Những
phản hồi này chỉ có ý nghĩa cho các tương tác yêu cầu và phản hồi. Một cách khác
“phản hồi” có thể được gửi bằng cách gọi hoạt động tương ứng của partnerLink. Hành
động Reply có thể chỉ ra thuộc tính của biến tham chiếu đến biến chứa dữ liệu thông
báo để gửi đi.
Cú pháp của hành động Reply:
<reply partnerLink="NCName"
portType="QName"? operation="NCName"

variable="BPELVariableName"?
faultName="QName"?
messageExchange="NCName"?
standard-attributes>
standard-elements
<correlations>?
<correlation set="NCName" initiate="yes|join|no"? />+
</correlations>
<toParts>?
<toPart part="NCName" fromVariable="BPELVariableName" />+
</toParts>
</reply>
- Thuộc tính parnerLink khai báo tên của partnerLink chứa dịch vụ nhận kết quả
trả về.
- Thuộc tính portType khai báo tên của portType nhận kết quả trả về.
- Thuộc tính operation khai báo tên của phương thức nhận kết quả trả về.
- Thuộc tính variable khai báo giá trị nhận giá trị kết quả trả về.
25

- Thuộc tính faultName là tùy chọn tên của biến lỗi khi có lỗi xảy ra.
- Thuộc tính messageExchange là tùy chọn được sử dụng để phân biệt mối quan
hệ giữa các hành động gửi thông báo đến và các hành động <reply>, việc sử
dụng messageExchange cần thiết khi việc thực thi có kết quả trong nhiều cặp
<receive> <reply> trên cùng một partnerLink và các hoạt động được thực hiện
đồng thời.
- Thẻ <correlations> liệt kê các correlation được sử dụng trong hành động
<Receive>.
- Thẻ <toParts> cho phép khai báo một hay nhiều giá trị đầu vào có giá trị tương
ứng với giá trị thuộc tính variable (chỉ khai báo ở variable hoặc <toPart> không
khai báo ở cả hai nơi).

d. Assign
Hành động Assign được sử dụng để sao chép dữ liệu từ một biến đến một biến khác,
cũng như để xây dựng và chèn dữ liệu mới bằng cách sử dụng các biểu thức. Việc sử
dụng các biểu thức chủ yếu được thúc đẩy bởi sự cần thiết phải thực hiện các tính toán
đơn giản (chẳng hạn như tăng số thự tự). Biểu thức hoạt động dựa trên các biến, thuộc
tính, các hằng số để tạo ra một giá trị mới. Hành động Assign cũng có thể sử dụng để
sao chép endpoint references từ partnerLinks. Nó cũng có thể bao gồm các thao tác dữ
liệu vận hành mở rộng định nghĩa giống như các thành phần mở rộng dưới các không
gian tên (namespace) khác từ không gian tên của WS-BPEL (WS-BPEL namespace)
Hành động Assign chứa đựng một hoặc nhiều thành phần vận hành.
<assign validate="yes|no"? standard-attributes>
standard-elements
(
<copy keepSrcElementName="yes|no"? ignoreMissingFromData="yes|no"?>
from-spec to-spec
</copy>
|
<extensionAssignOperation>
assign-element-of-other-namespace
</extensionAssignOperation>
)+
</assign>
- Thuộc tính validate có giá trị mặc định là “no”, khi giá trị của nó là “yes”, các
hành động <assign> xác nhận tất cả các biến được sửa đổi bởi các hành động
đó.
- Thuộc tính keepSrcElementName trong thẻ <copy> được sử dụng để xác định
tên thành phần của đích đến sẽ được thay thế bởi tên thành phần nào của điểm
nguồn.
26


- Thuộc tính ignoreMissingFromData trong thẻ <copy> có giá trị mặc định là
“no”, sử dụng để ném ra các lỗi chuẩn.
- Giá trị from-spec là biến giá trị từ điểm nguồn, và giá trị to-spec là giá trị của
điểm đích.
- Thẻ <extensionAssignOperation> chứa các hoạt động thao tác dữ liệu mở rộng,
như là thay đổi giá trị khi gán giá trị từ giá trị nguồn đến giá trị đích.
2.2.7. Các hành động cấu trúc
Hành động có cấu trúc quy định thứ tự trong tập hợp các hành động được thực thi.
Chúng mô tả làm thế nào một tiến trình nghiệp vụ được tạo ra; bằng cách soạn các
hành động cơ bản thực hiện thành cấu trúc thể hiện các mô hình điều khiển, xử lý lỗi
và các sự kiện bên ngoài, phối hợp trao đổi thông báo giữa các tiến trình tham gia
trong một giao thức kinh doanh.
a. Sequence
Hành động Sequence chứa đựng một hoặc nhiều hành động thực hiện tuần tự, theo thứ
tự xuất hiện bên trong thành phần <Sequence>. Hành động Sequence hoàn thành khi
hành động cuối cùng trong Sequence hoàn thành.
<sequence standard-attributes>
standard-elements
activity+
</sequence>
- Bên trong hành động sequence là tập hợp các hành động (activity). Các hành
động này có thể là hành động cơ bản hay hành động có cấu trúc.
b. If
Hành động If cung cấp điều kiện cho hành vi của tiến trình nghiệp vụ. Hành động này
bao gồm một danh sách có thứ tự của một hoặc nhiều các điều kiện nhánh được định
bởi thành phần if và tùy chọn elseIf, theo sau là một tùy chọn else. Các nhánh if và
elseif được xem xét theo thứ tự mà chúng xuất hiện. Nhánh đầu tiên có điều kiện đúng
được thực hiện, các hành động bên trong được thực hiện. Nếu không có nhánh với
điều kiện đúng được thực hiện thì nhánh else sẽ được thực hiện.
<if standard-attributes>

standard-elements
<condition expressionLanguage="anyURI"?>bool-expr</condition>
activity
<elseif>*
<condition expressionLanguage="anyURI"?>bool-expr</condition>
activity
</elseif>
<else>?
activity

×