So sánh hiệu năng của các trình xử lý BPEL

1

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

TRẦN QUỐC VIỆT

SO SÁNH HIỆU NĂNG CỦA CÁC
TRÌNH XỬ LÝ BPEL

Chuyên ngành:

Công nghê ̣ phầ n mề m

Mã số:

60 48 10

TÓM TẮT LUẬN VĂN THẠC SĨ

Hà Nội - 2012


1

MỤC LỤC
LỜI MỞ ĐẦU ................................................................................ 3
Chương 1: TỔNG QUAN VỀ SOA VÀ NGÔN NGỮ BPEL .......... 5
1.1

Tổng quan về SOA .......................................................... 5

1.2

Phối hợp dịch vụ trong SOA ............................................ 6

1.3

Ngôn ngữ WS-BPEL 2.0 ................................................. 7
1.3.1

Giới thiê ̣u .................................................................... 7

1.3.2

Nguyên tắ t hoa ̣t đô ̣ng của mô ̣t tiế n trình BPEL ............. 7

1.3.3

Cấ u trúc của mô ̣t tiế n trình BPEL ................................ 7

1.3.4

Các thành phần và ký hiệu trong BPEL ........................ 8

1.3.5 Quản lý các ngoại lệ và các variable.. Error! Bookmark
not defined.
1.3.6 Xử lý lỗi (Fault Handling)........... Error! Bookmark not
defined.
Chương 2: TÌM HIỂU CÁC TRÌNH XỬ LÝ BPEL .......................10
2.1 Khái niệm trình xử lý BPEL .................................................10

2.2 Các trình xử lý BPEL tiêu biểu hiện nay: Apache ODE,
ActiveVOS, Oracle BPEL Process Manager ...............................11
2.3.1 Trình xử lý Apache ODE ................................................11
2.3.2 Trình xử lý ActiveVOS ..................................................12
2.3.3 Trình xử lý Oracle BPEL Process Manager ....................12
Chương 3: ĐO ĐẠC VÀ ĐÁNH GIÁ HIỆU NĂNG CỦA MỘT SỐ
TRÌNH XỬ LÝ BPEL: APACHE ODE, ACTIVEVOS VÀ
ORACLE BPEL PROCESS MANAGER.......................................13
3.1 Mô hình đo hiệu năng cho trình xử lý BPEL .......................13


2
3.2

Xây dựng hệ thống đo đạc .................................................14

3.2.1 Phạm vi của bài toán đo hiệu năng các trình xử lý BPEL 14
3.2.2 Cài đặt trình xử lý BPEL ................................................14
3.2.3 Xây dựng ứng dụng dịch vụ Web ...................................15
3.3 Thực hiện đo .....................................................................15
3.4

So sánh và đánh giá hiệu năng từ kết quả đo đạc ...............17

3.4.1 Đánh giá hiệu năng các trình xử lý..................................17
3.4.2 So sánh thời gian xử lý của các trình BPEL ....................19


3

LỜI MỞ ĐẦU
1. Mục tiêu nghiên cứu của đề tài
Ngày nay, các ứng dụng công nghệ thông tin trong doanh nghiệp có
nghiệp vụ ngày càng phức tạp, thường xuyên đòi hỏi những ứng
dụng mới đáp ứng những thay đổi nghiệp vụ trong thế giới cạnh
tranh. Với số lượng các ứng dụng phát triển ngày càng nhiều đòi hỏi
phải có công nghệ và một nền tảng hệ tầng đồng bộ để có thể kết hợp
những hệ thống cũ và mới. Kiến trúc hướng dịch vụ (SOA) ra đời
nhằm giải quyết bài toán đó thông qua việc phối hợp các dịch vụ đơn
lẻ và các hệ thống có sẵn thành một quy trình thống nhất mà không
phải sửa đổi các ứng dụng cũ.
SOA sử dụng ngôn ngữ BPEL để xây dựng và thực thi các tiến trình
nghiệp vụ. Phiên bản mới nhất của BPEL là WS-BPEL 2.0, là ngôn
ngữ để mô hình hóa các tiến trình nghiệp vụ cho các ứng dụng theo
kiến trúc hướng dịch vụ. Các tiến trình xây dựng trên nền ngôn ngữ
BPEL ngoài các phép toán cấu trúc thông thường còn có các lời gọi
đến các dịch vụ bên ngoài để thực thi các chức năng. Kiến trúc SOA
sử dụng chuẩn giao tiếp WSDL để kết nối với các ứng dụng khác,
chính vì thế các hệ thống các hệ thống cũ không cần sửa đổi nhiều để
kết nối với các ứng dụng mới. Tiến trình BPEL sau khi được xây
dựng xong sẽ thực thi trên các trình xử lý BPEL (BPEL engines).
Tốc độ thực hiện của các tiến trình hay các ứng dụng này phụ thuộc
vào hiệu năng của các trình xử lý. Vì thế, việc lựa chọn một trình xử
lý BPEL phù hợp với yêu cầu hoạt động của ứng dụng là một bài
toán khó đối với các doanh nghiệp đòi hỏi phải có những so sánh và
đánh giá chính xác hiệu năng của các trình xử lý BPEL.


4
2. Một số kết quả đạt được

Với đề tài nghiên cứu này tôi đã đạt được một số kết quả nhất định
sau
 Nghiên cứu tổng quát về kiến trúc hướng dịch vụ (SOA) và phối
hợp các dịch vụ trong SOA
 Tìm hiểu đặc tả của ngôn ngữ thực thi tiến trình nghiệp vụ WSBPEL 2.0
 Tìm hiểu kiến trúc của các trình xử lý BPEL và một số trình xử
lý BPEL tiêu biểu: Apache ODE, ActiveVOS và Oracle BPEL
Process Manager.
 Đo đạc và đánh giá, so sánh hiệu năng của các trình xử lý BPEL
khi phản hồi các yêu cầu người dùng.
3. Bố cục luận văn
Bố cục luận văn được chia làm 3 chương chính theo trình tự nghiên
cứu từ lý thuyết tổng quan kiến trúc hướng dịch vụ, đặc tả BPEL đến
thực tiễn đo đạc trên các trình xử lý BPEL, cụ thể như sau:
Chương 1.Nghiên cứu lý thuyết kiến trúc SOA, trong đó nhấn mạnh
mô hình xây dựng ứng dụng nghiệp vụ từ các dịch vụ đơn lẻ và các
ứng dụng trên nền tảng và công nghệ khác sử dụng ngôn ngữ WSBPEL 2.0. Ngôn ngữ BPEL WS-BPEL 2.0 ngoài những tác vụ cấu
trúc thông thường còn có khẳ năng gọi các dịch vụ bên ngoài thông
qua dịch vụ Web(Web Service). Những tác vụ này đóng vai trò quan
trọng, ảnh hưởng đến hiệu năng hoạt động của các tiến trình nghiệp
vụ.
Chương 2. Tìm hiểu kiến trúc hoạt động chung của BPEL với 03
thành phần chính: Trình thiết kế BPEL, mẫu tiến trình theo chuẩn


5
ngôn ngữ WS-BPEL 2.0 và trình xử lý BPEL. Có rất nhiều các trình
xử lý BPEL hiện nay, tuy nhiên chúng ta sẽ lựa chọn tìm hiểu 03
trình xử lý tiêu biểu: Apache, và Oracle BPEL Manager. Việc nghiên
cứu kiến trúc của các trình xử lý này sẽ giúp chúng ta có được cái

nhìn tổng quan về kiến trúc cũng như hiểu được cách thức làm việc
của các trình xử lý.
Chương 3. Sử dụng phương pháp đo đạc định lượng trong đó triển
khai các trình xử lý và sử dụng các công cụ để đo thời gian thực hiện
của chúng. Trong phạm vi luận văn này, tác giả sẽ lựa chọn các tác
vụ cơ bản và quan trọng nhất của ngôn ngữ WS-BPEL: If-else, Flow,
FlowDep (flow dùng link), While, Sequence, Invoke để đánh giá hiệu
năng của các trình xử lý BPEL.Công cụ đo Apache Jmeter sẽ được
sử dụng để thực hiện đo thời gian phản hồi khi gửi các yêu cầu đến
trình xử lý. Số lượng các yêu cầu sẽ tăng dần, tương ứng với số
lượng người dùng tăng lên từ 1,2… 500. Kết quả đo đạc sẽ được lưu
lại để phân tích, so sánh và đánh giá
Kết luận. Kết luận và đánh giá những điểm làm được và chưa làm
được của luận văn và nêu ra hướng phát triển của đề tài trong những
lần nghiên cứu tiếp theo
Chương 1: TỔNG QUAN VỀ SOA VÀ NGÔN NGỮ BPEL
1.1 Tổng quan về SOA
SOA - Service Oriented Architecture (Kiến trúc Định hướng Dịch
vụ), theo định nghĩa của DotNetGuru, là 'Khái niệm về hệ thống
trong đó mỗi ứng dụng được xem như một nguồn cung cấp dịch
vụ'.Nói một cách đơn giản thì kiến trúc hướng dịch vụ (SOA) là một
hướng tiếp cận với việc thiết kế và tích hợp các phần mềm, chức
năng, hệ thống theo dạng module và có khả năng truy cập thông qua


6
môi trường mạng. Hệ thống SOA là một tập hợp các dịch vụ được
chuẩn hóa trên mạng trao đổi với nhau trong ngữ cảnh một tiến trình
nghiệp vụ.
Phối hợp dịch vụ trong SOA

Ngày nay, với sự phát triển của các ứng dụng nghiệp vụ đòi hỏi các
ứng dụng Công nghệ thông tin phải có một hạ tầng mềm dẻo và linh
hoạt để có thể nhanh chóng thay đổi và đáp ứng. Tuy nhiên, các ứng
dụng CNTT truyền thống thường được thiết kế theo hướng chức
năng và thường phục vụ một nghiệp vụ nhất định, khó có khả năng
thay đổi nghiệp vụ khi cần. Kết quả là rất nhiều các tổ chức không
thể tiếp tục sử dụng lại các hệ thống cũ do không thể tích hợp với các
thiết kế của hệ thống mới. Một bài toán được đặt ra là làm sao có thể
sử dụng lại các chức năng của các hệ thống cũ để tạo ra một hệ thống
mới, nhằm tiết kiệm chi phí đầu tư CNTT trong môi trường cạnh
tranh hiện nay.
Kiến trúc SOA ra đời nhằm giải quyết bài toán đó, người ta dùng
thuật ngữ “Orchestration” – tạm dịch là phối hợp các dịch vụ. Kiến
trúc SOA cho phép phối 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à không làm thay đổi kiến trúc của các ứng
dụng đó. Để làm được điều này, kiến trúc SOA 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ũng như các tác vụ thực hiện trên tiến
trình đó. Với các dịch vụ bên ngoài, kiến trúc SOA hỗ trợ giao tiếp
qua chuẩn WSDL. Chuẩn giao tiếp này không những phù hợp với
các ứng dụng SOA hiện tại mà còn có khả năng tương thích với các
hệ thống cũ mà không cần sửa đổi hệ thống đó. Để hiểu rõ hơn về


7
ngôn ngữ BPEL, chúng ta sẽ đi tìm hiểu về từng thành phần của nó
trong phần dưới đây.
1.2 Ngôn ngữ WS-BPEL 2.0
1.3.1 Giới thiêụ
BPEL (Business Process Execution Language ) là một ngôn ngữ dùng

để hổ trợ phát triể n các ứng du ̣ng phức ta ̣p , lớn đòi hỏi phải tổ ng hơ ̣p
nhiề u dich
̣ vu ̣ web khác nhau . BPEL cho phép ba ̣n mô tả và xử lý
luồ ng công viê ̣c bằ ng cách sử du ̣ng trình soa ̣n thảo đồ ho ̣a thân thiê ̣n
với con người . Ngoài ra BPEL còn đinh
̣ nghiã các cách qu ản lý các
sự kiện và ngoại lệ, cơ chế bảo toàn dữ liệu khi có ngoại lệ xảy ra.
BPEL hoa ̣t đô ̣ng dựa trên nguyên tắ c g ửi các thông điệp dạng XML
đến một dịch vụ khác, thao tác trên cấu trúc XML, nhận các thông
điệp XML (đồng bộ hay không đồng bộ) từ các service bên ngoài .Nó
phụ thuộc vào bốn chuẩn XML cơ bản được xem như là các đặt tả để
thực thi mô ̣t tiế n trình BPEL : WSDL, XML Schema 2.0, XPath 2.0
và WS-Addressing.
1.3.2 Nguyên tắ t hoa ̣t đô ̣ng của mô ̣t tiế n trin
̀ h B PEL
Trong số các đă ̣c tả : WSDL, XML Schema 2.0,XPath 2.0 và WS Addressing trên thì WSDL đóng vai trò cố t lõi trong mô ̣t tiế n triǹ h
của BPEL. Cố t lõi của BPEL là khái niê ̣m peer -to-peer là sự tương
tác giữa các dịch vụ web được mô t ả trong WSDL . Mô ̣t tiế n trình
BPEL đă ̣t tả làm thế nào để phố i hơ ̣p giữa các dich
̣ vu ̣ khác nhau và
kế t hơ ̣p các dich
̣ vu ̣ đó la ̣i thành mô ̣t tiế n trin
̀ h hoàn chin̉ h . Điề u này
có nghĩa một tiến trình BPEL được định nghĩa hoặ c cung cấ p từ mô ̣t
hoă ̣c nhiề u đă ̣t tả WSDL khác nhau , và cung cấp một đặt tả của riêng
nó về quá trình tổ ng hơ ̣p các dich
̣ vu ̣ này .
1.3.3 Cấ u trúc của mô ̣t tiế n trin
̀ h BPEL

8
Mô ̣t tiế n trình BPEL là mô ̣t mô tả dưới da ̣ng tài liê ̣u XML

. Quy

trình được mô tả trong BPEL giao tiếp với trang web và các dịch vụ
trao đổi tài liệu XML(SOAP). Các khái niệm chính trong một tiến
trình BPEL bao gồm:
Process: Mọi file BPEL đều bắt đầu với thẻ . Các mô tả
cho tiế n trình cũng như c ác namespace liên quan được định nghĩa ở
thẻ này.
Imports: Chứa thông tin các tâ ̣p tin WSDL đươ ̣c import vào .
PartnerLinks: Chứa tập hợp các partnerLink được sử dụng trong
tiến trình. Mỗi partnerLink sẽ thiết lập một quan hệ giữa bản thân
process với một service bên ngoài.
Variables: Phần này định nghĩa các biến được dùng trong tiến trình.
Mỗi biến đều phải được tham chiếu đến một kiểu thông điệp
(messageType) được mô tả trong tập tin WSDL.
Sequence: Đây là phần chính mô tả logic của tiến trình. Trong một
sequence sẽ chứa nhiều tác vụ (được trình bày chi tiết bên dưới).
Mỗi tác vụ có một nhiệm vụ cụ thể trong tiến trình BPEL. Bản thân
sequence cũng là một tác vụ, có thể chứa các cấu trúc song song
cũng như tuần tự khác
1.3.4 Các thành phần và ký hiệ u trong BPEL
Một tiến trình BPEL được thể hiện qua các Tác vụ, các Tác vụ trong
BPEL được thực hiện tuần tự theo cấu trúc được khai báo trong tiến
trình. Trong BPEL 2.0 thì các Tác vụ được chia làm ba nhóm cơ
bản như sau:
Tác vụ cơ bản: là các tác vụ đơn thể, nó không thể chứa được bất

kỳ các tác vụ nào khác bên trong nó nữa.


9
Tác vụ cấu trúc: là các Tác vụ có cấu trúc, nó có thể chứa được các
Tác vụ khác bên trong nó.
Tác vụ xử lý lỗi: các Tác vụ này được sử dụng để thụ lý lỗi và các
ngoại lệ xảy ra trong quá trình hoạt động của một tiến trình
Tùy theo nhu cầu và trong các trường hợp cụ thể mà ta có thể chọn
và sử dụng các Tác vụ khác nhau. Bảng sau mô tả chi tiết về một số
tác vụ chính trong BPEL 2.0:
Bảng 1.1 Một số tác vụ chính trong BPEL 2.0
Tên

Các trường hợp sử dụng

Các tác vụ cơ bản

Empty

Là một tác vụ đặc biệt, không làm gì hết khi được gọi. Tác
vụ này được dùng khi cần có một tác vụ nhưng không thật
sự cần một hành động nào xảy ra.

Invoke

Gọi một webservice để thự c hiê ̣n mô ̣t tác vu ̣ nào đó

Receive
Reply

Assign
Validate

Nhận một thông điệp từ một service partner. Thông thường
đây là tác vụ bắt đầu một tiến trình mới
Gửi trả một thông điệp cho mô ̣t đố i tươ ̣ng bên ngoài tiế n
trình
Dùng để khởi tạo ho ặc gán giá trị cho các biến trong tiến
trình BPEL
Kiểm tra tính hợp lệ của các biến và các biể u thức d ựa trên
định nghĩa của nó (chẳng hạn định nghĩa dựa trên XML
Schema, hay WSDL…)

Các tác vụ điều khiể n và có cấ u trúc
If/Else
Pick

Định nghĩa cấu trúc điều kiện
Đinh nghĩa cách lựa chọn phương án hành động (hành động
nào sẽ được thực hiện khi sự kiện tương ứng mà nó quy định


10

While
Repeat
…Until
Foreach
Wait
Sequence

Scope

xảy ra, nếu không có sự kiện nào xảy ra trong một thời gian
chỉ định trước thì hành động nào sẽ được thực hiện…)
Lă ̣p la ̣i mô ̣t tiế n trin
̀ h con nào đó trong process ở da ̣ng while
Lă ̣p la ̣i mô ̣t tiế n trình con nào đó trong process ở da ̣ng
do..while
Đinh
̣ nghiã vòng lă ̣p để duyê ̣t qua mô ̣t tâ ̣p hơ ̣p
Dừng tiế n trin
̀ h trong mô ̣t khoản thời gian đươ ̣c thiế t lâ ̣p
trước
Dùng để thiết lập tuần tự hoạt động của các Tác vụ
Dùng để chia nhỏ tiến trình thành các tác vụ có các nhiệm
vụ liên quan với nhau (khi tiến trình trở nên phức tạp).

Chương 2: TÌM HIỂU CÁC TRÌNH XỬ LÝ BPEL
2.1 Khái niệm trình xử lý BPEL
Như đã giới thiệu trong chương 1, BPEL là ngôn ngữ để mô hình hóa
quy trình nghiệp vụ và phối hợp các dịch vụ đơn lẻ thành một quy
trình thống nhất. Sau khi quy trình được tạo ra, nó sẽ được triển khai
trên trình xử lý BPEL, là công cụ thực thi và cụ thể hóa quy trình đó.
Trình xử lý BPEL được định nghĩa là:
“Trình xử lý BPEL là một trình xử lý luồng công việc mà thực thi các
tiến trình được thiết kế trên ngôn ngữ BPEL”.
“Trình xử lý BPEL là một thành phần phần mềm có khả năng biên
dịch ngôn ngữ BPEL”.
Theo định nghĩa trên, trình xử lý BPEL không hoạt động độc lập mà
là một thành phần phần mềm trong kiến trúc của BPEL. Kiến trúc

của BPEL bao gồm 03 thành phần chính là: trình thiết kế BPEL, mẫu
tiến trình và trình xử lý BPEL.
Trình thiết kế BPEL: Trình thiết kế BPEL được sử dụng để định
nghĩa các tiến trình nghiệp vụ, thường độc lập với các nền tảng ứng


11
dụng. Đây là công cụ hỗ trợ đắc lực cho những chuyên viên nghiệp
vụ để định nghĩa cá tiến trình mà không cần biết sâu về kỹ thuật. Sau
khi thiết kế xong, nó sẽ tự động sinh ra mẫu tiến trình lô gic dưới
dạng mã nguồn BPEL.
Mẫu tiến trình logic: Mẫu tiến trình logic có định dạng theo đặc tả
BPEL. Mẫu tiến trình này được sinh ra bởi trình thiết kế BPEL và
thực thi bởi trình xử lý BPEL.
Trình xử lý BPEL: Nhiệm vụ của trình xử lý BPEL là thực thi bất
cứ mẫu tiến trình logic nào theo chuẩn BPEL. Trong quá trình thực
hiện, nó sẽ gọi các dịch vụ Web, ánh xạ dữ liệu với các thông điệp,
xử lý lỗi, đảm bảo giao dịch toàn vẹn và tính bảo mật. Trình xử lý
BPEL thường được tích hợp với các máy chủ ứng dụng (Application
Server). Hiện nay có rất nhiều các sản phẩm trình xử lý BPEL mang
tính thương mại hoặc mã nguồn mở, tuy nhiên không có một kiến
trúc chung nào được sử dụng, cũng như không có một chuẩn thiết kế
nào mà một trình xử lý BPEL tuân theo.Trong phần tiếp theo, chúng
ta sẽ đi tìm hiểu kiến trúc của 3 trình xử lý BPEL tiêu biểu hiện nay:
Apache ODE, ActiveVOS và Oracle BPEL Process Manager.
Apache ODE là trình xử lý mã nguồn mở phổ biến nhất hiện nay,
ActiveVOS là một trong những trình xử lý đầu tiên, Oracle BPEL
Process Manager là sản phẩm dành cho các doanh nghiệp.
2.2 Kiến trúc một số trình xử lý BPEL tiêu biểu
2.3.1 Trình xử lý Apache ODE

Các thành phần chính trong kiến trúc của ODE bao gồm bộ biên dịch
ODE BPEL, trình chạy các ứng dụng BPEL, các đối tượng truy cập
dữ liệu, các lớp tích hợp và các công cụ người dùng. Mô hình quan


12
hệ mức cao giữa các thành phần được mô tả trong hình dưới. Có thể
tổng kết lại là” Bộ biên dịch sẽ chuyển đổi mã nguồn BPEL sang
dạng có thể thực thi được. Quá trình thực thi sẽ giao tiếp với CSDL
thông qua DAO, và giao tiếp với môi trường bên ngoài thông qua lớp
tích hợp”
2.3.2 Trình xử lý ActiveVOS
Kiến trúc của trình xử lý BPEL bao gồm 04 thành phần: Trình xử lý
trung tâm, mô đun triển khai, mô đun các dịch vụ, mô đun quản trị.
Phần quan trọng nhất trong kiến trúc của ActiveVOS là bộ xử lý
trung tâm ActiveVOS. Nhiệm vụ của nó là xác định, đánh giá và
thực thi các mẫu tiến trình viết bằng ngôn ngữ BPEL. Thành phần
thứ 2 là các trình quản lý máy chủ bao gồm: quản lý cảnh báo, cấu
hình cụm, triển khai, các tiến trình, hàng đợi, lưu trữ, nhiệm vụ và xử
lý các sự kiện phức tạp. Thành phần nền tảng thứ 3 đóng vai trò quan
trọng trong việc giao tiếp với các hệ thống khác, thông qua việc hỗ
trợ các giao thức như : WS, JMS, POJO, REST...
2.3.3 Trình xử lý Oracle BPEL Process Manager
Oracle BPEL Process Manager là công cụ để thực thi các tiến trình
nghiệp vụ. Công cụ này cung cấp một giải pháp nâng cao, được
chuẩn hóa và dễ dùng để tạo, triển khai và quản lý các tiến trình
nghiệp vụ tự động theo kiến trúc hướng dịch vụ. Oracle BPEL
Process Manager là công cụ tích hợp thích hợp cho các doanh
nghiệp. Nó có khả năng kết nối với các hệ thống ngoài và các tiến
trình, có nhiều công nghệ giao tiếp khác nhau giúp nó có thể dễ dàng

xác định và thực thi các nghiệp vụ logic.


13
Chương 3: ĐO ĐẠC VÀ SO SÁNH HIỆU NĂNG CỦA MỘT
SỐ TRÌNH XỬ LÝ BPEL

3.1 Mô hình đo hiệu năng cho trình xử lý BPEL
Để đánh giá một hiệu năng của một hệ thống là tốt hay không, người
ta thường sử dụng các phép đo hiệu năng, trong đó mô phỏng quá
trình xử lý yêu cầu của hệ thống, thu thập các dữ liệu đo dựa trên
một số tiêu chí và cuối cùng tiến hành phân tích, đánh giá các dữ liệu
đo. Để mô phỏng quá trình xử lý yêu cầu, người ta sẽ giả lập các yêu
cầu giống với môi trường thật và gửi tới hệ thống. Theo lý thuyết đo
về hiệu năng phần mềm của Henry H.Liu [Note], người ta sử dụng
phương pháp đo dựa trên 2 tiêu chí là throughput và response time để
đánh giá hiệu năng các hệ thống. Throughput được định nghĩa là số
lượng các đối tượng (objects) được xử lý trong một giây
(Throughput=objects/second), còn response time là thời gian phản
hồi từ hệ thống, tính từ sau khi người dùng submit một yêu cầu đến
khi nhận được kết quả trả về. Trong các hệ thống xử lý giao dịch trực
tuyến (OLTP), “thời gian phản hồi” là tiêu chí quan trọng để đánh
giá hiệu năng của hệ thống, còn “thông lượng” thường được sử dụng
với các hệ thống xử lý giao dịch dài và lớn (ví dụ các hệ thống chạy
batch job).
Để đo hiệu năng của một trình xử lý BPEL, chúng ta cũng sử dụng
phương pháp trên để đo các tiêu chí dựa trên các yêu cầu gửi đến hệ
thống. Tuy nhiên, bản thân trình xử lý BPEL không trực tiếp đón
nhận yêu cầu từ phía người dùng cũng như trả về kết quả. Việc đón
nhận yêu cầu và trả kết quả được thực hiện bởi ứng dụng Dịch vụ

Web chạy trên trình xử lý BPEL, mặc dù trình xử lý này trực tiếp


14
thực hiện các tác vụ của ứng dụng dịch vụ Web. Như vậy để đo hiệu
năng của một trình xử lý BPEL, chúng ta sẽ thực hiện các phép đo
tác động đến ứng dụng dịch vụ Web chạy trên trình xử lý đó.
3.2 Xây dựng hệ thống đo đạc
3.2.1 Phạm vi của bài toán đo hiệu năng các trình xử lý BPEL
Dựa trên mô hình do hiệu năng ở trên, chúng ta xác định các thành
phần trong mô hình bao gồm:
 Các trình xử lý BPEL: gồm 03 trình xử lý Apache ODE,
ActiveVOS và Oracle BPEL Process Manager. Về bản chất,
các trình xử lý BPEL này không chạy độc lập mà nó liên kết
với các mô đun SOA khác. Ngoài ra các trình xử lý BPEL
này cũng chạy trên các thành phần khác như Web Server hay
CSDL. Trong phạm vi luận văn này, ta sẽ cài đặt các trình
xử lý theo mặc định của chúng, là một sản phẩm bao gồm
các thành phần: Web Server + CSDL + trình xử lý BPEL. Ta
sẽ đo hiệu năng của sản phẩm này.
 Các dịch vụ Web: Mỗi Dịch vụ Web thể hiện một tác vụ của
BPEL. Việc đo từng tác vụ sẽ cho ta cái nhìn độc lập và
khách quan về hiệu năng của trình xử lý BPEL khi thực hiện
từng tác vụ đó. Từ kết quả đo cho từng tác vụ, ta có thể tính
toán hiệu năng cho ứng dụng tổng hợp nhiều tác vụ khác
nhau.
 Công cụ đo: Ta sẽ sử dụng công cụ đo tự động Apache
Jmeter[1] để tạo các kịch bản đo theo ý muốn.
3.2.2 Cài đặt trình xử lý BPEL

15
Yêu cầu bài toán của chúng ta sẽ thực hiện đo trên 03 trình xử lý
BPEL tiêu biểu hiện nay: Apache ODE được phát triển bởi tổ chức
Apache Foundation, ActiveVOS của công ty Active Endpoints Inc,
và Oracle BPEL Process Manager 10G của công ty Oracle. Mỗi trình
xử lý BPEL là một phần mềm có kiến trúc riêng nhưng đều hỗ trợ
chuẩn chung WS-BPEL 2.0.
3.2.3 Xây dựng ứng dụng dịch vụ Web
Chúng ta sẽ xây dựng các ứng dụng dịch vụ Web, mỗi ứng dụng sẽ
thực hiện một trong các tác vụ tiêu biểu của ngôn ngữ WS-BPEL2.0
mà trình xử lý BPEL thực hiện: If-else, While, Flow, Sequence,
Invoke. Tác vụ Flow sẽ có 2 ví dụ ứng với 2 trường hợp thực hiện
song song - Flow (không có link) và thực hiện tuần tự - FlowDep (có
link liên kết giữ các luồng). Chúng ta lựa chọn các tác vụ tiêu biểu
này vì chúng đã bao gồm toàn bộ các tác vụ khác của ngôn ngữ WSBPEL 2.0: RepeatUntil có thể mô phỏng bằng tác vụ While.
3.2.4 Triển khai công cụ đo
Để thực hiện mô phỏng yêu cầu của người dùng, chúng ta sử dụng
công cụ đo tự động Apache Jmeter. Apache Jmeter cho phép giả lập
số lượng người dùng với số lượng tùy ý, tạo các test case theo ý
muốn và lưu lại các kết quả đo (throughput, response time) với độ
chính xác cao. Apache Jmeter là phần mềm mã nguồn mở, viết bằng
100% ngôn ngữ Java, được thiết kế để thực hiện các phép kiểm thử
chức năng cũng như đo hiệu năng theo mô hình Client/Server.

3.3

Thực hiện đo

Để đo các ứng dụng Dịch vụ Web, cần thực hiện các bước sau đây:

16
 Bật các trình xử lý BPEL trên các “máy chủ”, đã deploy sẵn
các ứng dụng Dịch vụ Web. Để cô lập môi trường, chúng ta sẽ
chỉ bật một trình xử lý ở tại một thời điểm.
 Khởi động Jmeter trên máy trạm (nối cáp chéo).
 Tạo kịch bản trên Jmeter gửi yêu cầu đến máy chủ. Jmeter sẽ
ghi lại thời gian phản hồi theo 3 thông số: thời gian phản hồi
trung bình, nhỏ nhất và lớn nhất.
 Tăng dần số lượng người dùng đồng thời từ 1,2… 500.
Các ứng dụng Dịch vụ Web được triển khai trên các trình xử lý
BPEL Apache ODE, ActiveVOS, Oracle BPEL Process Manager
chạy trên máy tính có hệ điều hành phiên bản Window 7 Professional
32 bit có cấu hình: Intel Dual Core T9400 2.53 GHz, 3 GB RAM.
Phần mềm Apache JMeter chạy trên máy tính khác có hệ điều hành
phiên bản Window 7 Professional 32 bit với cấu hình: Intel Dual
Core E8400 3.00 GHz, 3 GB RAM. 2 máy chủ được kết nối với nhau
trực tiếp để cô lập môi trường, đảm bảo tính khách quan của kết quả
đo
Với mỗi ứng dụng trên một trình xử lý BPEL, chúng ta sẽ thực hiện
đo đạc nhiều lần, ở nhiều mức độ người sử dụng đồng thời.. Với mỗi
đợt đo tương ứng với một số lượng người dùng, chúng ta sẽ thực
hiện đo nhiều lần và lấy trung bình để tăng độ tin cậy của kết quả đo.
Ngoài ra, để tăng tính chính xác của việc mô phỏng, chúng ta sẽ cấu
hình “think time” giống như môi trường thật – “think time” là thời
gian tính từ lúc người dùng nhận kết quả của yêu cầu thứ nhất đến
lúc gửi yêu cầu thứ hai – cho các yêu cầu đo đạc. Do thời gian này
thường không cố định nên ta sẽ dùng xác suất với giá trị trung bình

17
là 1s (1000ms) và biên độ dao động là 0.5s (500ms). Tham số này
được cấu hình dựa trên đối tượng Gaussian Random Timer của
Apache Jmeter.
3.4

So sánh và đánh giá hiệu năng từ kết quả đo đạc

3.4.1 Đánh giá hiệu năng các trình xử lý
Oracle BPEL Process Manager
Các phép thử đều thành công với Oracle BPEL Process Manager, khi
số lượng user tăng dần từ 1 đến 500, mà không phát sinh một lỗi nào.
Khi tăng số lượng người dùng kết nối đồng thời lên dần thì thời gian
trả về có tăng thêm nhưng vẫn đảm bảo không vượt quá thời gian
timeout (30s). Như vậy có thể khẳng định trình xử lý Oracle BPEL
có khả năng đáp ứng được cùng lúc 500 người dùng đồng thời.
So sánh kết quả của 2 tác vụ Flow và FlowDep thì tác vụ FlowDep
có thời gian trả về trung bình khoảng >2000ms, trong khi tác vụ
Flow chỉ có thời gian trả về trung bình <1600ms. Nguyên nhân là do
trong tác vụ Flow, các luồng thực hiện song song, còn tác vụ
FlowDep thì luồng này phải đợi kết quả luồng kia nên chậm hơn.
Tuy nhiên, khi số lượng người dùng lớn (500) thì sự sai khác này
không đáng kể.
ActiveVOS
Khi số lượng user từ 1-25 thì thời gian phản hồi có sự khác nhau
không đáng kể. Khi số lượng người dùng lớn hơn 25 thì thời gian
phản hồi tăng nhanh rõ rệt, và bắt đầu xuất hiện lỗi (được thể hiện
bằng các vòng tròn nhỏ). Với số lượng người dùng nhỏ, tác vụ Flow
thực hiện nhanh hơn FlowDep, tuy nhiên khi đạt đến 200 người dùng

18
thì chúng như nhau và khi 500 thì thời gian phản hồi của Flow lại lâu
hơn FlowDep.
Nhìn chung, các tác vụ mà trình xử lý ActiveVOS thực hiện đều vượt
qua tất cả các phép thử, chỉ có tác vụ Invoke có đến 59.74% trường
hợp lỗi khi có 500 người dùng đồng thời, và tác vụ While có 38.17%
tỉ lệ lỗi khi có 200 người dùng đồng thời kết nối. Lỗi thông báo
“Retrying transaction to save journal entry” có nghĩ là tại thời điểm
đó, giao dịch không thể thực hiện được và bị trả lại (rollback). Kiểm
tra tải của hệ thống tại thời điểm có lỗi đều chiếm 100%CPU của
máy chủ.
Các tác vụ khác như Flow, FlowDep, Sequence, If có thời gian trả về
vượt quá 30s nhưng không có thông báo lỗi, mà chỉ do hệ thống
nghẽn và trả về kết quả chậm. Khi có 500 người dùng kết nối đồng
thời, tài nguyên hệ thống gần như được sử dụng hết
Như vậy, ta đánh giá trình xử lý OS cho phép tối nhất 500 người
dùng kết nối gửi yêu cầu đồng thời, với tác vụ While và Invoke chỉ
cho tối đa 200 người dùng. Tác vụ FlowDep cũng trả về kết quả
chậm hơn so với tác vụ Flow, điều nay tương tự như kết quả với
trình xử lý Oracle BPEL Process Manager. Giữa tác vụ FlowDep và
tác vụ Sequence, kết quả trả về có sự khác nhau nhưng không đáng
kể.
Apache ODE
Các tác vụ trên trình xử lý Apache ODE không vượt qua được tất cả
các phép thử, hầu như các tác vụ đều gặp lỗi ở mức 25 người dùng
đồng thời kết nối. Với 25 người dùng gửi yêu cầu đồng thời thì với
1-2 lượt request đầu tiên, các yêu cầu đều được đáp ứng, tuy nhiên

19
đến lượt yêu cầu tiếp theo thì phát sinh ra các ngoại lệ (exception).
Ví dụ với tác vụ While thì khi có 25 user đồng thời gửi yêu cầu đến
thì có đến 34.57% lỗi, còn ví dụ Invoke thì có tỉ lệ lỗi là 45%. Như
vậy có thể khẳng định trình xử lý Apache ODE chỉ có thể phục vụ tối
đa không quá 25 người dùng đồng thời.
Kiểm tra tải của máy chủ tại thời điểm bị lỗi thì thấy tài nguyên máy
chủ (CPU, Mem) đều dưới 50%, chứng tỏ nguyên nhân lỗi không
phải do thiếu tài nguyên. Phân tích các mã lỗi trả về cho thấy các lỗi
đều liên quan đến Database, khi trình xử lý Apache ODE không thể
ghi vào Database do có deadlock, dẫn đến không trả về kết quả cho
người dùng. Những giao dịch mà trình xử lý không thể ghi vào trong
Database sẽ được rollback và được lập lịch thực thi trong tương lai.
Khi khởi động lại trình xử lý, các yêu cầu này tiếp tục được xử lý lại,
gây nghẽn cho các yêu cầu mới gửi đến. thời gian phản hồi của tác
vụ Flow và FlowDep tương đối giống nhau trong Apache ODE. Chỉ
khi xóa thông tin của các yêu cầu được gửi đến trong Database thì
trình xử lý Apache ODE mới ngừng thực hiện chúng
3.4.2 So sánh thời gian xử lý của các trình BPEL
While
Nhìn chung, tác vụ While trên Oracle cho thời gian phản hồi trung
bình nhanh hơn so với ActiveVOS và ActiveVOS nhanh hơn so với
ODE. Với số lượng người dùng càng lớn thì sự khác biệt này càng rõ
ràng.
Flow


20
So sánh thời gian phản hồi trung bình của tác vụ Flow với số lượng

người dùng đồng thời nhỏ (<=10) trên các trình xử lý BPEL có thể
thấy thời gian trên các trình xử lý có sự khác nhau không đáng kế.
Trình xử lý Oracle BPEL Process Manager có thời gian phản hồi ổn
định nhất cho dù số lượng người dùng tăng khá lớn từ 1 đến 500
người dùng.
FlowDep
Với số lượng user <200, thời gian trả về của các trình xử lý
ActiveVOS và Oracle không có sự khác nhau nhiều. Với 500 thì xu
hướng tăng của ActiveVOS trở nên tuyên tính.
Sequence
Với số lượng người dùng <10, cả 3 trình xử lý có thời gian trả vể
không khác nhau nhiều. Với số lượng người dùng từ 10 đến 500, có
sự thay đổi về mức độ tăng: ActiveVOS gần như có thời gian trả về
tăng tuyến tính, trong khi Oracle BPEL Process Manager chỉ thay đổi
một chút. Điều đó chứng tỏ trình xử lý Oracle BPEL luôn giữ được
sự ổn định ngay cả khi số lượng người dùng đồng thời đạt đến 500.
IF-Else
Với số lượng người dùng <10, thời gian trả về của 3 trình xử lý là
như nhau. Từ 25 người dùng trở lên chỉ còn ActiveVOS và Oracle
tiếp tục xử lý, tuy nhiên ActiveVOS có thời gian trả về lớn hơn nhiều
so với Oracle. Biểu đồ cho thấy xu hướng tăng của ActiveVOS max
và ActiveVOS avg gần như tuyến tính.
Invoke


21
So sánh tác vụ If và tác vụ Invoke: Với số lượng người dùng nhỏ và
vừa (1-100) thì thời gian trả về giữa các trình xử lý không có sự
khác biệt. Như vậy so với các tác vụ khác thì thời gian mà
ActiveVOS xử lý tiệm cận với Oracle cao hơn (đến mức 100 users,

trong khi các tác vụ khác mới chỉ 25 user đã có sự thay đổi). Tuy
nhiên với phép thử từ 200 người dùng trở lên thì có sự khác biệt:
ODE không thực hiện được, ActiveVOS thực hiện được nhưng thời
gian trả về khá lớn (>21s), chỉ có Oracle BPEL Process Manager là
có thời gian trả về nhỏ (<5s).
Kết luận: Qua các số liệu đo đạc và phân tích ở trên, chúng ta có thể
thấy được sự khác biệt giữa hiệu năng của các trình xử lý BPEL.
Đánh giá thời gian trả về, khi số lượng người dùng nhỏ (<25) thì thời
gian không có sự khác biệt đáng kể, tuy nhiên, khi số lượng người
dùng đồng thời ở tăng cao (>=200), thì chỉ có trình xử lý ActiveVOS
và Oracle là trả về được kết quả, trong đó Oracle vẫn giữ được sự ổn
định, còn ActiveVOS thì có xu hướng tăng cao tuyến tính (Với tác
vụ Sequence và If-else thì từ 50 người dùng đã có sự khác biệt). Một
yếu tố nữa thể hiện sự khác biệt về hiệu năng là khả năng hỗ trợ
người dùng đồng thời, với Apache ODE chỉ hỗ trợ tối đa 25 người
dùng, ActiveVOS hỗ trợ tối đa 500 người dùng, còn Oracle Active
OS thì vẫn có thể phục vụ hơn 500 người dùng đồng thời.

KẾT LUẬN
Sau một thời gian tìm tòi, nghiên cứu, luận văn đã thu được một số
kết quả quan trọng. Về lý thuyết, luận văn đã nêu ra những điểm
quan trọng của kiến trúc hướng dịch vụ, trong đó đi sâu vào việc
phối hợp (orchestration) các dịch vụ đơn lẻ và các hệ thống ứng dụng


22
thành một quy trình nghiệp vụ đầy đủ. Luận văn cũng đã mô tả tổng
quan về các tác vụ của ngôn ngữ thực thi tiến trình nghiệp vụ WSBPEL 2.0.
Luận văn đã tìm hiểu kiến trúc chung của BPEL và đi sâu vào tìm
hiểu kiến trúc của từng trình xử lý BPEL cụ thể Apache ODE,

ActiveVOS, Oracle BPEL Process Manager. Việc tìm hiểu những
kiến trúc này giúp người đọc có thể hiểu rõ hơn về các thành phần
cũng như mô hình hoạt động của các tiến trình BPEL.
Trong phần thực nghiệm, luận văn đã đưa ra mô hình đo hiệu năng
cũng như triển khai các trình xử lý. Các ứng dụng dịch vụ Web được
tạo ra cho từng tác vụ, sau đó được triển khai trên từng trình xử lý.
Quá trình đo đạc được thực hiện hàng trăn lần với hàng chục nghìn
mẫu dữ liệu đảm bảo tính chính xác, khách quan và độ tin cậy của dữ
liệu đo. Việc phân tích, đánh giá dữ liệu đo đem lại những kết quả
quan trọng như: Kết quả so sánh hiệu năng giữa các trình xử lý,
Apache ODE có hiệu năng thấp nhất và phục vụ được ít người dùng
nhất, ActiveVOS có hiệu năng trung bình, còn Oracle BPEL Process
Manager có hiệu năng tốt và ổn định nhất cho dù số lượng người
dùng có tăng lên 500. Quá trình thực nghiệm cũng đưa ra những kinh
nghiệm khi tạo ra tiến trình BPEL như dùng tác vụ Flow nhanh hơn
so với FlowDep để tận dụng khả năng thực hiện song song. Luận văn
cũng đưa cho người dùng những khuyến cáo cần thiết về những yếu
tố kỹ thuật khác khi lựa chọn một trình xử lý BPEL.
Trong thời gian ngắn thực hiện, mặc dù đã cố gắng nghiên cứu và
tìm hiểu, tuy nhiên luận văn vẫn còn nhiều thiếu sót. Trong thời gian
tới, luận văn sẽ tiếp tục mở rộng việc đo đạc trên các nền tảng khác
như: hệ điều hành khác, máy chủ ứng dụng và Cơ sở dữ liệu khác.


23
Luận văn cũng sẽ mở rộng việc đo trên các ứng dụng phức hợp bao
gồm nhiều tác vụ khác nhau để tăng độ chính xác của kết quả đo.


24

TÀI LIỆU THAM KHẢO
[1]

Active

Endpoints,

ActiveVOS

Documentation,

/>[2]

Apache

Software

Foundation,

Apache

JMeter

Documentation,
/>[3]

Apache Software Foundation, Apache ODE Documentation,
/>
[4]

Emmanuel Cecchet, Julie Marguerite, Willy Zwaenepoel,
Performance and Scalability of EJB Applications, 2002.

[5]

Henry H. Liu, Software performance and scalability – A
Quantitative Approach, A John Wiley & SONS, INC,
Publication, 2009.

[6]

OASIS,

Web

Services

Business

Language Version 2.0,

Process

Execution

is-

open.org/wsbpel/2.0/wsbpel-v2.0.html, 2007.
[7]

Oracle

Corporation,

Oracle

BPEL

Process

Manager

Documentation,
/>age_bpel.htm