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á
Trang 11
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
Trang 22
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
Trang 33
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 đòi hỏi phải tổng hợp nhiều di ̣ch vu ̣ web khác nhau BPEL cho phép
Trang 44
bạn mô tả và xử lý 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 đi ̣nh nghĩa 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 hoạ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 trình BPEL
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 trình 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 di ̣ch vu ̣ 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 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 chỉnh Điều này có nghĩa mô ̣t tiến trình BPEL được đi ̣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 dịch vụ này
1.3.3 Cấu trúc của mô ̣t tiến trình BPEL
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ẻ <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 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
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ó
Trang 55
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 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 ngoài tiến trình
Assign Dùng để khởi tạo hoặc gán giá 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 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 va ̀ có cấu trúc
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 chỉ định trước thì hành động nào sẽ được thực hiện…)
While Lă ̣p la ̣i mô ̣t tiến trình con nào đó trong process ở da ̣ng while
Repeat
…Until
Lă ̣p la ̣i mô ̣t tiến trình con nào đó trong process ở da ̣ng do while
Foreach Đi ̣nh nghĩa vòng lă ̣p để duyê ̣t qua mô ̣t tâ ̣p hợp
Wait Dừng tiến trình trong mô ̣t khoản 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)
Trang 66
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 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 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
Trang 77
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
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
Trang 88
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ử 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
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
Trang 99
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ử 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 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ì
Trang 1010
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ử, 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 đế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