1

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

NXB H. : ĐHCN, 2012 Số trang 66 tr. +

Trần Quốc Việt

Trường Đại học Công nghệ

Luận văn ThS ngành: Công nghệ phần mềm; Mã số: 60 48 10

Người hướng dẫn: TS Võ Đình Hiếu

Năm bảo vệ: 2012

Abstract: 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ữ WS-BPEL 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ụ. 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 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, tìm hiểu 03 trình xử

lý tiêu biểu: Apache, và Oracle BPEL Manager. 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ý. 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. 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á

Keywords: Công nghệ phần mềm; Công nghệ thông tin; Ngôn ngữ BPEL; Trình xử lý

Content

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

2

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.

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ụ WS-BPEL 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ữ WS-BPEL 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 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

3

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

1.2 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ề 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êu

BPEL (Business Process Execution Language ) là một ngôn ngữ dùng để hổ trợ phát triên

các ứng dụng phức tạp , lơn đoi hoi phai tông hơp nhiêu dich vu web khac nhau . BPEL cho phep

4

bạn mô tả và xử ly luồng công việc bằng cách sử dụng trình soạn thảo đồ họa thân thiện với con

ngươi. Ngoài ra BPEL còn đinh nghia 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 hoat đô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 ta đê thưc thi môt tiên trinh BPEL: WSDL, XML Schema 2.0, XPath 2.0 và WS-Addressing.

1.3.2 Nguyên tăt hoat đông cua môt tiên trinh BPEL

Trong sô cac đăc ta : WSDL, XML Schema 2.0,XPath 2.0 và WS -Addressing trên thi

WSDL đong vai tro côt loi trong môt tiên trinh cua BPEL . Côt loi cua BPEL la khai niêm peer -to-

peer la sư tương tac giưa cac dich vu web đươc mô t ả trong WSDL . Môt tiên trinh BPEL đăt ta

làm thế nào để phối hợp giữa các dịch vụ khác nhau và kết hợp các dịch vụ đó lại thành một tiến

trình hoàn chinh . Điêu nay co nghia môt tiên trinh BPEL đươc đinh nghia hoă c cung câp tư môt

hoăc nhiêu đăt ta WSDL khac nhau, và cung cấp một đặt tả của riêng nó về quá trình tông hơp cac

dịch vụ này.

1.3.3 Câu truc cua môt tiên trinh BPEL

Môt tiên trinh BPEL la môt mô ta dươi dang tai 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ẻ <process>. 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 cac tâp tin WSDL đươc import vao.

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 Cac thanh phân va ky 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.

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

5

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 Cac 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 tac vu nao đo

Receive 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

Reply Gửi trả một thông điệp cho môt đôi tương bên ngoai tiên trinh

Assign Dùng để khởi tạo hoặc gan gia trị cho các biến trong tiến trình BPEL

Validate Kiểm tra tính hợp lệ của các biến va cac 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 va co câu truc

If/Else Định nghĩa cấu trúc điều kiện

Pick

Đ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 xảy ra, nếu không có sự kiện nào xảy ra

trong một thời gian chi định trước thì hành động nào sẽ được thực hiện…)

While Lăp lai môt tiên trinh con nao đo trong process ơ dang while

Repeat

…Until

Lăp lai môt tiên trinh con nao đo trong process ơ dang do..while

Foreach Đinh nghia vong lăp đê duyêt qua môt tâp hơp

Wait Dưng tiên trinh trong môt khoan thơi gian đươc thiêt lâp trươc

Sequence Dùng để thiết lập tuần tự hoạt động của các Tác vụ

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

6

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ử

ly 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 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ử ly 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ử ly 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ử ly đầ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 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

7

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

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ử ly 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

8

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 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ử ly đó.

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ử ly 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 y muốn.

3.2.2 Cài đặt trình xử lý BPEL

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ữ WS-

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

9

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:

Bật các trình xử ly 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ẽ chi 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 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 chi 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ì

10

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 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ử, chi 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% ti 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à chi 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 chi 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ử ly 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 đế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ó ti lệ lỗi là 45%. Như vậy

có thể khẳng định trình xử lý Apache ODE chi 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

11

Apache ODE. Chi 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

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 chi 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ử ly là như nhau. Từ 25 người

dùng trở lên chi 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

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 chi 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), chi 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ì chi có trình xử lý ActiveVOS và Oracle là trả về được kết quả, trong

12

đó 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 chi 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 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ụ WS-BPEL 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ử ly. 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. 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.

References

[1] Active Endpoints, ActiveVOS Documentation,

http://www.activevos.com/developers/documentation

13

[2] Apache Software Foundation, Apache JMeter Documentation,

http://jmeter.apache.org/usermanual/index.html

[3] Apache Software Foundation, Apache ODE Documentation, http://ode.apache.org/user-

guide.html

[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 Process Execution Language Version 2.0, http://docs.oasis-

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

[7] Oracle Corporation, Oracle BPEL Process Manager Documentation,

http://docs.oracle.com/cd/E23943_01/dev.1111/e10224/partpage_bpel.htm