Vấn đề bế tắc (deadlock) trong quy trình được hiện thực bằng BPEL
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.03 MB, 51 trang )
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Phạm Thị Dung
VẤN ĐỀ BẾ TẮC (DEADLOCK)
TRONG QUY TRÌNH ĐƯỢC HIỆN THỰC BẰNG BPEL
LUẬN VĂN THẠC SỸ
HÀ NỘI - 2015
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Phạm Thị Dung
VẤN ĐỀ BẾ TẮC (DEADLOCK)
TRONG QUY TRÌNH ĐƯỢC HIỆN THỰC BẰNG BPEL
Ngành: Công nghệ thông tin
Chuyên ngành: Kỹ thuật phần mềm
Mã số: 60.48.01.03
LUẬN VĂN THẠC SỸ
Cán bộ hướng dẫn:
TS. Võ Đình Hiếu
HÀ NỘI - 2015
VIETNAM NATIONAL UNIVERSITY, HANOI
UNIVERSITY OF ENGINEERING AND TECHNOLOGY
Dung Pham Thi
DEADLOCK PROBLEMS IN THE PROCESS
IS IMPLEMENTED IN BPEL
Major: Information of Technology
Supervisor: Ph.D Hieu Vo Dinh
HA NOI, 2015
Lời cảm ơn
Trước tiên, em xin bày tỏ lòng biết ơn chân thành và sâu sắc tới Thầy giáo, TS Võ
Đình Hiếu đã tận tình chỉ bảo, hướng dẫn, động viên và giúp đỡ em trong suốt quá
trình thực hiện đề tài luận văn.
Em xin gửi lời cảm ơn sâu sắc tới các Thầy Cô trong Khoa Công nghệ thông tin đã
truyền đạt kiến thức quý báu cho em trong sáu năm học vừa qua.
Con xin nói lên lòng biết ơn vô hạn đối với Cha Mẹ luôn là nguồn động viên, chăm
sóc và khích lệ con trên mỗi bước đường học vấn.
Cuối cùng, xin chân thành cảm ơn các Anh Chị và Bạn Bè, các thành viên lớp K53CB
và K19CNPM đã ủng hộ, giúp đỡ tôi trong suốt thời gian tôi học tập trên giảng đường
và thực hiện đề tài luận văn này.
Tôi xin chân thành cảm ơn!
Hà Nội, ngày 09 tháng 08 năm 2015
Học viên
Phạm Thị Dung
VẤN ĐỀ BẾ TẮC (DEADLOCK)
TRONG QUY TRÌNH ĐƯỢC HIỆN THỰC BẰNG BPEL
Phạm Thị Dung
Khóa K19KTPM, ngành công nghệ thông tin.
Tóm tắt Luận văn tốt nghiệp:
Dịch vụ Web ra đời đã mở ra hướng mới cho việc tương tác giữa các ứng dụng thông qua sử
dụng các tiêu chuẩn Web, hiện được áp dụng đa dạng trong hệ thống phần mềm thực tế. Dịch
vụ Web sử dụng mô hình tích hợp kết nối lỏng lẻo và độc lập nền tảng đã cho phép tính linh
hoạt trong việc tích hợp các hệ thống B2C, B2B và các ứng dụng doanh nghiệp. Tuy nhiên,
độ lớn và phức tạp của các hệ thống ngày nay thì tích hợp giữa các ứng dụng và các quy trình
nghiệp vụ hệ thống yêu cầu đòi hỏi nhiều hơn ngoài sử dụng các giao thức tiêu chuẩn Web.
Khi đó, tích hợp giữa các dịch vụ Web theo quy trình nghiệp vụ cần sử dụng một mô hình tích
hợp quy trình chuẩn. Ngôn ngữ thực thi quy trình nghiệp vụ BPEL (Bussiness Execute
Process Language) ( hay WS-BPEL, BPEL4WS) đưa ra để định nghĩa một mô hình và ngữ
pháp mô tả hành vi của quy trình nghiệp vụ dựa trên tương tác giữa các quy trình và các đối
tác của nó, đơn giản hóa bài toán kết hợp các dịch vụ theo quy trình nghiệp vụ.
BPEL sử dụng các đặc tả XML như WSDL, XML Schema, XPath và XSLT. WSDL và XML
Schema cung cấp mô hình dữ liệu, còn XPath và XSLT cung cấp hỗ trợ cho việc thao tác sử
dụng dữ liệu trong BPEL. BPEL mô hình quy trình nghiệp vụ định nghĩa các thành phần hoạt
động cơ sở và có cấu trúc. Trong đó, thành phần hoạt động quan trọng, được dùng khi mô
hình một ứng dụng nghiệp vụ <flow>, sử dụng để định nghĩa một tập các thành phần hoạt
động thực thi đồng thời hoặc song song.
<flow> được xem như cấu trúc dạng đồ thị, như một chuỗi các liên kết <link>, <link>
quy định luồng chạy ẩn của điều khiển giữa các thành phần hoạt động trong một <flow>.
Mỗi <link> phải có ít nhất một thành phần nguồn <source> và ít nhất một thành phần
đích <target>. Thành phần <target> của một <link> không được bắt đầu cho tới khi
thành phần <source> của <link> hoàn thành. Vấn đề về bế tắc, xung đột giữa các thành
phần hoạt động trong thành phần hoạt động <flow> có thể xảy ra trong một quy trình nghiệp
vụ. Khi sử dụng <link> đặc biệt trong trường hợp nhiều <link> trong một <flow>, dễ
gây ra bế tắc như xuất hiện chu trình của các thành phần hoạt động, thành phần đích là thành
phần nguồn của một thành phần hoạt động đã thực thi xong hoặc các thành phần hoạt động
song song cùng thao tác tới một biến toàn cục. Luận văn sẽ đi sâu tìm hiểu về, các vấn đề sẽ
gây ra bế tắc, xung đột trong một <flow>, từ đó, xây dựng chương trình phát hiện và cảnh
báo về vấn đề này.
DEADLOCK PROBLEMS IN THE PROCESS
IS IMPLEMENTED IN BPEL
Dung Pham Thi
K19KTPM course, information technology faculty
Abtract thesis:
Web services have been launched to open the way to the interaction between applications
through the use of Web standards currently applied varied in actual software system. Web
Services used loose connected integration models and platform independence which has
allowed flexibility in integrating systems B2C, B2B and enterprise applications. However, the
magnitude and complexity of today's systems integrate between applications and business
process systems requiring more demanding exterior use standard Web protocols. Meanwhile,
the integration between Web services according to business processes using an integrated
model. Language executable BPEL business processes (Business Process Execute Language)
(- or WS-BPEL, BPEL4WS) launched to define a model and grammar for describing the
behavior of the business process based on interactions between the process and its partners, to
simplify the problem combined with services as business processes.
BPEL uses the XML specification as WSDL, XML Schema, XPath, and XSLT. WSDL and
XML Schema provides data models, and XPath and XSLT provide support for the use of data
manipulation in BPEL. BPEL business process model defines the basic activities and the
structured activities. In particular, important activities, or used to model a business application
is <flow>, used to define a set of components executed simultaneously or in parallel.
<Flow> is seen as structures graphically, as a sequence of the <link>, <link> specified
stream in the background of control between the activities in a <flow>. Each <link>
should have at least one <source> activity and at least one destination component <target>.
The <target> of a <link> is not started until the <source> of <link> finish. The
issue of impasse, the conflict between the activities in <flow> can happen in a business
process. When using the <link> especially in the case of multiple <link> in a <flow>,
prone to deadlock cycle occurs as the activity, the destination component is part of an active
ingredient source runaway or moving components operating in parallel with actions to a
global variable. Dissertations will go deep to find out about, the problem would cause
deadlock, conflict in a <flow>, from there, building programs to detect and alert on this
issue.
Lời cam đoan
Tôi xin cam đoan vấn đề phát hiện và xây dựng công cụ cảnh báo bế tắc (deadlock) trong quy
trình được hiện thực bằng BPEL được trình bày trong luận văn này là do tôi thực hiện dưới sự
hướng dẫn của TS Võ Đình Hiếu.
Tất cả những tham khảo từ các nghiên cứu liên quan đề được nêu nguồn gốc một các rõ ràng
từ danh mục tài liệu tham khảo trong luận văn. Trong luận văn, không có việc sao chép tài
liệu, công trình nghiên cứu của người khác mà không chỉ rõ về tài liệu tham khảo.
Hà Nội, ngày 09 tháng 08 năm 2015
Tác giả
Phạm Thị Dung
Mục lục
Mở đầu ............................................................................................................................1
Chương 1: Tổng quan về kết hợp dịch vụ và ngôn ngữ BPEL .................................2
1.1.
Tổng quan về kết hợp dịch vụ Web................................................................2
1.2.
Ngôn ngữ thực thi quy trình nghiệp vụ BPEL ..............................................3
1.3.
Tại sao nên sử dụng BPEL ..............................................................................4
1.4.
Tổng quan cấu trúc của một tiến trình BPEL...............................................5
1.4.1.
Bài toán khởi tạomột tiến trình BPEL.........................................................5
1.4.2.
Cấu trúc của một tiến trình WS-BPEL ........................................................8
1.5.
Các thành phần hoạt động của BPEL ..........................................................10
1.5.1.
Cung cấp và tiêu thụ các dịch vụ Web ......................................................10
1.5.2.
Cấu trúc hóa logic tiến trình .....................................................................11
1.5.3.
Các thành phần hoạt động lặp ..................................................................12
1.5.4.
Xử lý song song .........................................................................................13
1.5.5.
Thao tác dữ liệu.........................................................................................14
1.5.6.
Điều khiển ngoại lệ ...................................................................................15
Tổng kết chương một ...............................................................................................16
Chương 2 : Phát biểu <flow> và vấn đề bế tắc .......................................................17
2.1.
Phát biểu <flow> ..........................................................................................17
2.1.1
Giới thiệu chung về <flow> ....................................................................17
2.1.2
Các thành phần và thuộc tính chuẩn liên quan <flow> .........................18
2.1.3
Thành phần <link> trong <flow> .......................................................20
2.1.4
Ví dụ về <flow> ......................................................................................21
2.2.
Vấn đề bế tắc trong <flow>.........................................................................22
Tổng kết chương hai ................................................................................................ 27
Chương 3: Xây dựng công cụ kiểm tra và cảnh báo deadlock................................ 29
3.1.
Ý tưởng giải pháp ...........................................................................................29
3.2.
Xây dựng công cụ phát hiện và cảnh báo bế tắc .........................................33
3.3.
Kết quả đánh giá công cụ ..............................................................................38
Tổng kết chương ba .................................................................................................39
Kết luận ........................................................................................................................40
Tài liệu tham khảo .......................................................................................................41
Danh sách hình vẽ
Hình 1.1: Tiến trình xử lý đơn nhận hàng hàng ..............................................................6
Hình 1.2: Biểu diễn WSDL xử lý một đơn nhận hàng ....................................................7
Hình 2.1: Ví dụ về luồng Flow ......................................................................................21
Hình 2.2.1: Mô tả activity <if>......................................................................................23
Hình 2.2.2: Kết hợp <flow> và <if>.............................................................................24
Hình 2.2.3: Kết hợp <flow> và <if> có điều kiện JoinCondition .................................25
Hình 2.2.4: Biểu diễn luồng thực thi <sequence> .........................................................26
Hình 2.2.5: Kết hợp <flow> và <sequence> có chu trình. ............................................27
Hình 3.1.1: Mô hình ứng dụng phát hiện hiện bế tắc ....................................................29
Hình 3.1.2: Mô tả thành phần <assign> thành nút đồ thị ..............................................30
Hình 3.1.3: Chuyển <if> thành đồ thị có hướng ...........................................................31
Hình 3.1.4: Chuyển <sequence> thành đồ thị có hướng ...............................................32
Hình 3.2.1: Đồ thị có hướng cho bài toán 1. .................................................................36
Hình 3.2.2: Đồ thị có hướng cho bài toán 2. .................................................................37
Danh sách các từ viết tắt
WS-BPEL
Web Services Business Process Execution Language
BPEL
Business Process Execution Language
WSDL
Web Services Description Language
UDDI
Universal Description, Discovery, and Integration
XML
eXtensible Markup Language
SOAP
Simple Object Access Protocol
WSFL
Web Services Flow Language
B2C
Business To Consumer
B2B
Business To Business
Mở đầu
Dịch vụ Web ra đời đã mở ra hướng mới cho việc tương tác giữa các ứng dụng thông
qua sử dụng các tiêu chuẩn Web, hiện được áp dụng đa dạng trong hệ thống phần mềm
thực tế. Các ứng dụng, hệ thống đòi hỏi ngày càng mở rộng quy mô và phức tạp về các
quy trình nghiệp vụ. Việc sử dụng các dịch vụ Web riêng lẻ cho từng chức năng
nghiệp vụ, ngày càng không đáp ứng được với độ phức tạp của hệ thống. Ngôn ngữ
thực thi quy trình nghiệp vụ BPEL đưa ra để định nghĩa một mô hình và ngữ pháp để
mô tả hành vi của quy trình nghiệp vụ và đối tác hay các dịch vụ Web.
BPEL mô hình quy trình nghiệp vụ định nghĩa từ các thành phần hoạt động cơ bản như
<invoke>, <receive>, <reply>, <assign>… và các thành phần hoạt động có
cấu trúc như <sequence>, <if>, <while>, <repeatUntil>,
<flow>…. Trong đó, thành phần hoạt động quan trọng, được dùng khi mô hình một
ứng dụng nghiệp vụ <flow>, sử dụng để định nghĩa một tập các thành phần hoạt
động thực thi đồng thời hoặc song song. Bởi liên kết <link> quy định phụ thuộc thực
thi trong một <flow>, trong khi các thành phần hoạt động của BPEL được thiết kế để
chương trình không xảy ra bế tắc hoặc chu trình, tuy nhiên, việc sự kết hợp giữa thành
phần hoạt động cấu trúc có lựa chọn như <if> hay tuần tự <sequence> trong
<flow> có sử dụng <link>, có thể gây ra bế tắc.
Nội dung của luận văn được chia thành các chương như sau:
Chương 1: Luận văn giới thiệu tổng quan về kết hợp dịch vụ Web và ngôn ngữ BPEL.
Chương 2: Luận văn phát biểu về thành phần hoạt động <flow> và vấn đề deadlock.
Chương 3: Luận văn đề xuất và xây dựng công cụ kiểm tra và cảnh báo deadlock.
Phần kết luận : Tóm lược kết quả đạt được của luận văn và định hướng phát triển
tương lai.
1
Chương 1: Tổng quan về kết hợp dịch vụ và ngôn ngữ BPEL
Chương này, luận văn giới thiệu tổng quan về kết hợp dịch vụ Web và ngôn ngữ thực
thi quy trình nghiệp vụ BPEL cùng các thành phần hoạt động của nó. Ngoài ra, luận
văn còn nêu lên được tại sao nên sử dụng BPEL trong các ứng dụng nghiệp vụ sử dụng
dịch vụ Web.
1.1.
Tổng quan về kết hợp dịch vụ Web
Web service – dịch vụ Web, tạo ra với mục đích để tương tác giữa các ứng dụng bởi
việc sử dụng các tiêu chuẩn Web. Các dịch vụ Web sử dụng mô hình kết nối lỏng lẻo
cho phép tích hợp linh hoạt giữa các hệ thống độc lập như B2C (business-toconsumer), B2B (business-to-business) hay các hệ thống tích hợp ứng dụng doanh
nghiệp. Các đặc tả liên quan tới dịch vụ Web như SOAP – định nghĩa một giao thức
giao tiếp XML cho khả năng tương tác dịch vụ cơ bản, WSDL (ngôn ngữ mô tả dịch
vụ Web) giới thiệu cú pháp chung cho mô tả dịch vụ và UDDI cung cấp kết nối hạ
tầng cho việc giao tiếp và kết nối. Kết hợp, các đặc tả đó cho phép các ứng dụng tương
tác với mỗi cái khác theo mô hình kết nối lỏng lẻo, độc lập về nền tảng [2].
Việc tích hợp các hệ thống thực tế mong đợi nhiều vào khả năng tương tác đơn giản,
sử dụng các giao thức tiêu chuẩn. Dịch vụ Web có nền tảng tích hợp mềm dẻo áp dụng
trong các ứng dụng và quy trình nghiệp vụ có thể giải quyết các vấn đề tương tác phức
tạp thông qua một mô hình tích hợp quy trình chuẩn. Mô hình tương tác được hỗ trợ
trực tiếp bởi WSDL là mô hình phi trạng thái nhận yêu cầu – phản hồi hoặc cách thức
tương quan nhiều chiều.
Các mô hình tương tác nghiệp vụ hiện nay cơ bản áp dụng một trong các kiểu trao đổi
thông điệp như peer-to-peer, yêu cầu - phản hồi, một chiều, có trạng thái, các tương tác
dài (long – running) liên quan tới hai hoặc nhiều bên. Để định nghĩa các tương tác
nghiệp vụ hệ thống, mô tả hình thức các giao thức trao đổi thông điệp cùng với sử
dụng các quy trình nghiệp vụ của chúng là điều cần thiết. Các quy trình nghiệp vụ bao
gồm các hành vi phụ thuộc dữ liệu, khả năng xác định các điều kiện ngoại lệ, hậu quả/
kết quả của tương tác, và tính phối hợp giữa các đơn vị, phòng ban. Một hệ thống được
biểu diễn chi tiết, rõ ràng ở nhiều khía cạnh khác nhau càng tốt. Vai trò phân tích hệ
thống, các chi tiết thực thi nghiệp vụ hệ thống không nhất thiết đưa ra, khi đó cần một
quy trình trừu tượng để mô tả hành vi trao đổi thông điệp thấy được của mỗi bên liên
2
quan sẽ quan trọng hơn. Các vai trò xây dựng, triển khai, cần một quy trình thể hiện
luồng thực thi và tích hợp các dịch vụ giữa các bên liên quan, hoặc quản lý trao đổi dữ
liệu. Ngôn ngữ BPEL định nghĩa hai quy trình: trừu tượng và thực thi sẽ mô tả, biểu
diễn tiến trình nghiệp vụ hệ thống sử dụng các dịch vụ Web theo hai quy trình đó.
1.2.
Ngôn ngữ thực thi quy trình nghiệp vụ BPEL
WS-BPEL (Web Services Business Process Execution Language) hay ngắn gọn BPEL
(Business Process Execution Language) là ngôn ngữ thực thi tiến trình nghiệp vụ các
dịch vụ Web. Phiên bản BPEL4WS (Business Process Execution Language for Web
Services 1.0) được giới thiệu vào tháng 7/2002, kết hợp chung của IBM, Microsoft và
BEA. Nó sử dụng ngôn ngữ luồng dịch vụ Web (Web Services Flow Language WSFL) của IBM và XLANG của Microsoft. Phiên bản 1.1 và thêm sự tham gia đóng
góp của SAP và Siebel Systems, được phát hành vào tháng 5/2003 [3]. Phiên bản gần
nhất WS-BPEL 2.0 được giới thiệu năm 2007. Trong phạm vi tài liệu luận văn này, chỉ
đề cập và sử dụng phiên bản WS-BPEL 2.0 và gọi ngắn gọn là BPEL hay WS-BPEL.
Đặc tả BPEL 2.0 định nghĩa một ngôn ngữ cho quy trình nghiệp vụ xây dựng dựa trên
các dịch vụ Web. BPEL 2.0 cung cấp một mô tả quy chuẩn hoàn chỉnh về ngôn ngữ
thực thi quy trình nghiệp vụ. Các khái niệm cơ bản của BPEL được hiểu theo một trong
hai hướng, trừu tượng hoặc thực thi. Một tiến trình trừu tượng BPEL là một tiến trình
đặc tả từng phần không phải để thực thi và phải được khai báo rõ ràng như kiểu trừu
tượng. Trong khi tiến trinh thực thi được đặc tả đầy đủ và có thể được thi hành, một tiến
trình trừu tượng có thể ẩn các chi tiết thao tác cụ thể hóa được yêu cầu thể hiện bởi vật
thực thi. Tất cả kiến trúc của tiến trình thực thi tạo nên giá trị tới tiến trình trừu tượng, vì
thế tiến trình BPEL thực thi và trừu tượng có độ mạnh thể hiện như nhau.
Tiến trình trừu tượng cung cấp hai cơ chế ẩn các chi tiết thao tác; một sử dụng
các thẻ không rõ ràng một cách rõ ràng hoặc thiếu sót. Các tiến trình trừu tượng có vai
trò mô tả, thường đưa ra nhiều ca sử dụng, một ca sử dụng mô hình hành vi nhìn thấy
của vài hoặc tất cả các dịch vụ được đề xuất bởi tiến trình trừu tượng. Ca sử dụng khác
định nghĩa một khuôn mẫu tiến trình, khuôn mẫu này thể hiện những thực hành tốt
nhất từng miền cụ thể. Bất kể với từng ca sử dụng và mục đích, tất cả các tiến trình
trừu tượng chia sẻ một cơ sở cú pháp chung. Chúng có yêu cầu khác nhau về mức độ
của độ mờ và hạn chế trong các phần của một định nghĩa tiến trình, có thể bị bỏ sót
hoặc bị ẩn. Cách sử dụng phù hợp của các tiến trình trừu tượng có hiệu quả khác nhau
trong các ràng buộc nhất quán và trong cú pháp của tiến trình đó.
3
-
Trong khi tiến trình trừu tượng không yêu cầu để chỉ rõ đầy đủ, tiến trình thực
thi có ngôn ngữ định nghĩa một cách hiệu quả dạng thực thi động cho các tiến trình
nghiệp vụ dựa trên các tài nguyên dịch vụ Web và dữ liệu XML hoàn toàn. Hơn nữa,
các tiến trình thực thi và tương tác cùng với các đối tác của chúng trong một cách thức
nhất quán không phân biệt nền tảng hỗ trợ hoặc mô hình lập trình được dùng thực thi
của các môi trường phục vụ.
BPEL sử dụng vài đặc tả XML: WSDL 1.1, XML Schema 1.0, XPath 1.0 và XSLT
1.0. Ngôn ngữ mô tả dịch vụ Web WSDL và định nghĩa kiểu XML Schema cung cấp
mô hình dữ liệu được sử dụng bởi các tiến trình BPEL. XPath và XSLT cung cấp hỗ
trợ cho việc thao tác sử dụng dữ liệu. Tất cả tài nguyên bên ngoài và các đối tác được
miêu tả như các dịch vụ WSDL. BPEL cung cấp khả năng mở rộng để cung cấp các
phiên bản tương lai của các chuẩn, đặc tả XPath và liên quan chuẩn được sử dụng
trong tính toán XML.
1.3.
Tại sao nên sử dụng BPEL
Điểm mạnh của BPEL là khả năng tổ chức một tiến trình nghiệp vụ. Đối với các yêu
cầu cho một tiến trình logic phức tạp, BPEL là một lựa chọn tốt[10]. Nó phù hợp cho
các hệ thống nghiệp vụ lớn và các tiến trình tương tác dài (long-running), đặc biệt các
hệ thống SOA. Ưu điểm của việc sử dụng BPEL trong mô hình nghiệp vụ các dịch vụ
Web bao gồm:
Cung cấp ngôn ngữ chuẩn cho việc diễn giải các quy trình nghiệp vụ: giàu ngữ
nghĩa và bao quát, trải qua phát triển nghiêm ngặt hướng tới giải quyết các yêu cầu
phức tạp, BPEL đưa ra hướng giải quyết dàn phối toàn diện.
Tận dụng một tập hợp kỹ năng chung và ngôn ngữ: Các tiêu chuẩn cho phép chi
phí tổng thấp nhất của quyền sở hữu qua tính di động tri thức, thay vì sử dụng các kỹ
thuật độc quyền phức tạp, BPEL có các thực hành tốt, các mẫu, kinh nghiệm và đào
tạo được tận dụng từ đa dạng các nhà cung cấp, truy cập tới các nguồn tài nguyên tri
thức trong mô hình và công nghệ của BPEL.
Được thiết kế để phù hợp tự nhiên tới ngăn xếp chứa dịch vụ Web: Trong WSBPEL một tiến trình nghiệp vụ tương tác cùng các dịch vụ qua các lời gọi dịch vụ
Web. Sự tổng hợp đệ quy, một tiến trình BPEL tận dụng tương tác cung cấp bởi các
mức thấp nhất của hàng đợi các dịch vụ Web, như WSDL, SOAP, WS-Addressing.
Thể hiện hoàn toàn bằng XML: như các tiến trình nghiệp vụ WS-BPEL thể hiện
trong XML, chúng là dễ đọc và được sử dụng bởi bất kỳ các cơ sở tiến trình XML.
4
-
Sử dụng và kế thừa WSDL 1.1 và XML Schema 1.0: BPEL sử dụng và kế thừa
WSDL để cả cung cấp và sử dụng dịch vụ Web trong phương thức trừu tượng, sử dụng
WSDL để định nghĩa các giao tiếp dịch vụ. Trong khi đó XML Schema 1.0 để mô
hình dữ liệu.
Đa nền tảng và nhà cung cấp động: BPEL cung cấp các nền tảng tiêu chuẩn cơ
sở. Các tiến trình BPEL chạy trên bất kỳ engine biên dịch WS-BPEL.
Tương thích giữa các tiến trình tương tác và tái sử dụng: BPEL cung cấp một
chuẩn chung cung cấp tương thích giữa các nền tảng khác nhau và các tiến trình thực
thi trong chúng.
1.4.
Tổng quan cấu trúc của một tiến trình BPEL
1.4.1. Bài toán khởi tạomột tiến trình BPEL
Trước khi đi mô tả chi tiết cấu trúc của các tiến trình nghiệp vụ, phần này sẽ đưa ra
một ví dụ đơn giản của một tiến trình WS-BPEL cho việc xử lý một đơn đặt hàng. Các
thao tác tiến trình được miêu tả trong hình 1.1.
Bài toán: Trong việc nhận đặt hàng từ một khách hàng, tiến trình phải khởi tạo và tính
toán đồng thời ba phần như tính toán chi phí cuối của một đơn hàng, lựa chọn một
phương thức chuyển hàng, lên lịch sản phẩm và giao hàng. Trong vài xử lý có thể tiến
hành đồng thời, có sự phụ thuộc điều khiển và dữ liệu giữa ba phần. Như, chi phí giao
hàng được yêu cầu để tính chi phí cuối cùng của đơn hàng, ngày giao hàng được yêu
cầu để hoàn thành lịch giao hàng. Sau khi ba phần đồng thời được hoàn thành, tiến
trình hóa đơn có thể tiến hàng và hóa đơn sẽ được gửi tới khách hàng.
5
Hình 1.1: Tiến trình xử lý đơn nhận hàng
Dịch vụ Web purchaseOrderPT được sử dụng cho tiến trình đặt hàng và nó được
mô tả trong WSDL kèm theo.Việc tính toán chi phí cung cấp, lựa chọn phương thức
giao hàng và đặt lịch được xây dựng như các dịch vụ Web mô tả trong WSDL. Trong
tài liệu WSDL không mô tả và hiển thị các kết nối. Một tiến trình BPEL định nghĩa
các tham chiếu chỉ ra các loại cổng của dịch vụ Web được gọi tới dùng trong tiến
trình, và trong BPEL không triển khai xây dựng các dịch vụ Web. Bởi cách thức này,
cho phép tái sử dụng các tiến trình nghiệp vụ qua các cách triển khai khác nhau. Để
tương tác với mỗi đối tác dịch vụ Web, BPEL sử dụng các partnerLink. Kiểu của
các partnerLink là
WSDL, miêu tả sự tương tác giữa dịch vụ Web đặt hàng với mỗi dịch vụ Web nghiệp
vụ với cùng cách tương tác. Các
các dịch vụ Web, và mỗi
sách các porttypes, hỗ trợ cho tương tác tiến hành thành công. Trong ví dụ đặt
hàng trên, hai
cầu của khách hàng, chỉ khi dịch vụ đặt hàng cần đưa ra một thao tác dịch vụ
sendPurchaseOrder;
tác giữa dịch vụ đặt hàng và dịch vụ đặt lịch. Hai
6
invoicingLT và shippingLT định nghĩa hai vai trò tính toán hóa đơn và sử dụng
dịch vụ giao hàng phải cung cấp các thao tác gọi lại invoiceCallbackPT và
shippingCallbackPT để thông báo đã gửi. Hình 1.2 biểu diễn cho các mô tả trên.
Hình 1.2: Biểu diễn WSDL xử lý một đơn nhận hàng[1]
Một tiến trình nghiệp vụ WS-BPEL thể hiện bởi XML, như một ngôn ngữ thực thi, nó
định nghĩa sự hoạt động tương ứng với các thành phần hoạt động bao đóng, biểu diễn
luồng điều khiển logic, dữ liệu, tương tác thông điệp, điều khiển ngoại lệ và các phần
khác. Trong tiến trình nghiệp vụ BPEL bao gồm các thành phần liên quan như:
-
nghiệp vụ
tượng và các dịch vụ Web. Nó được đặc tả bởi một partnerLinkType và hai thuộc
tính vai trò như myRole và partnerRole. Thông tin này định danh chức năng
được cung cấp bởi tiến trình nghiệp vụ và dịch vụ đối tác khi cần thực thi.
-
<variables> định nghĩa các biến dữ liệu được sử dụng trong tiến trình, nó
được định nghĩa chung cùng các kiểu thông điệp của WSDL, các kiểu XML Schema
hoặc các thành phần XML Schema.
-
<faultHandlers> chứa các trình điều khiển lỗi định nghĩa các thành phần
hoạt động (activities) khi thực thi phản hồi trả về các kết quả lỗi từ quá trình gọi các
dịch vụ Web.
7
-
nghiệp vụ. Thành phần này là thành phần bao đóng ngoài cùng, chứa tất cả các thành
phần hoạt động tạo nên một tiến trình nghiệp vụ BPEL.
1.4.2.
Cấu trúc của một tiến trình WS-BPEL
BPEL thể hiện hoàn toàn định dạng bằng XML, chúng dễ đọc và dễ hiểu, mỗi thành
phần, đặc tả đặc tả bởi một cặp bao đóng XML. Cấu trúc cơ bản của một tiến trình
nghiệp vụ WS-BPEL như:
expressionLanguage="anyURI"?
suppressJoinFailure="yes|no"?
exitOnStandardFault="yes|no"?
xmlns=" />
<messageExchanges>…
</messageExchanges>
<variables>…</variables>
<correlationSets>…</correlationSets>
<faultHandlers>…</faultHandlers>
<eventHandlers>…
</eventHandlers>
activities
</process>
Thành phần
hoặc các trình điều khiển phải được khai báo trong
•
queryLanguage đặc tả ngôn ngữ truy vấn được sử dụng trong tiến trình. Giá
trị mặc định của
thuộc tính này trong phiên bản
WS-BPEL 2.0 là
urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0, miêu tả sử dụng
XPath 1.0 trong WS-BPEL 2.0.
•
expressionLanguage đặc tả ngôn ngữ biểu thức được sử dụng trong
định của thuộc tính này là:
8
urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0.
•
suppressJoinFailure xác định khi các lỗi joinFailure được ném ra
từ tất cả các thành phần hoạt động trong tiến trình. Thuộc tính này có thể bị ghi đè bởi
một thành phần hoạt động bên trong tiến trình sử dụng các giá trị khác nhau của thuộc
tính này. Giá trị mặc định của thuộc tính này là no tại mức
tính này không được chỉ ra trong tiến trình, nó sẽ thừa kế giá trị từ các thành phần hoạt
động bao đóng bên ngoài hoặc từ
thuộc tính này.
•
exitOnStandardFault, nếu giá trị của thuộc tính này là yes, thì tiến trình
đưa ra, hoặc khi có một lỗi BPEL chuẩn như bpel:joinFailure được thông báo.
Nếu giá trị của thuộc tính này được là no, thì tiến trình có thể điều khiển một lỗi
chuẩn sử dụng trình điều khiển lỗi. Giá trị mặc định là no. Khi thuộc tính này không
được dùng trong một <scope> thì nó thừa kế thành phần bao đóng <scope> hoặc
•
Cú pháp của tiến trình trừu tượng hoặc tiến trình thực thi có không gian tên đích
phân biệt của chính nó, như: />chỉ rằng đây là một tiến trình thực thi, một tiến trình trừu tượng sẽ được định nghĩa trong WS-BPEL 2.0.
Mỗi tiến trình nghiệp vụ, biểu diễn bởi ngôn ngữ BPEL, phân chia thành các thành
phần hoạt động tương ứng với chức năng riêng của mỗi chúng như:
•
WS-BPEL cũng hỗ trợ khái niệm khai báo theo từng địa phương cục bộ. Thành
phần cú pháp hỗ trợ khai báo là <scope>.
•
Tiến trình nghiệp vụ BPEL khả năng tích hợp các dịch vụ Web và định nghĩa
logic nghiệp vụ giữa mỗi các tương tác dịch vụ đó. Mỗi tương tác dịch vụ được coi là
một giao tiếp cùng một đối tác nghiệp vụ. Tương tác mô tả một hoặc nhiều giao tiếp
các
•
Dữ liệu tiến trình là các biến, được khai báo trong một
<scope> bên trong tiến trình đó. Biến nắm giữ dữ liệu cấu thành nên trạng thái của
một tiến trình nghiệp vụ BPEL trong suốt thời gian chạy. Dữ liệu trong BPEL được
viết và đọc từ các biến định kiểu. Mỗi một biến được mô tả bởi <variable> khai
báo trong <variables>.
•
Trong một thành phần hoạt động BPEL có thể là một trong bất kỳ các thành
phần hoạt động như: <receive>, <reply>, <invoke>, <assign>, <throw>,
9
<exit>,
<wait>,
<empty>,
<sequence>,
<if>,
<while>,
<repeatUntil>, <forEach>,
<compensateScope>, <rethrow>, <validate>, <extensionActivity>.
Các thành phần hoạt động của BPEL
1.5.
Các thành phần chính của các tiến trình WS-BPEL là các thành phần hoạt động
(activity). Chúng có hai kiểu: thành phần hoạt động có cấu trúc và thành phần hoạt
động cơ sở. Thành phần hoạt động có cấu trúc chứa các thành phần khác và định nghĩa
logic nghiệp vụ giữa chúng. Ngược lại, thành phần hoạt động cơ sở chỉ thực hiện mục
đích đưa ra của chúng như nhận một thông điệp từ một đối tác, hoặc thao tác dữ liệu
và không định nghĩa bất kỳ logic nghiệp vụ khác cũng không chứa được bất kỳ thành
phần hoạt động khác. Có thể chia các thành phần hoạt động của WS-BPEL thành các
nhóm hay được sử dụng sau:
1.5.1.
Cung cấp và tiêu thụ các dịch vụ Web
Trong BPEL, tồn tại một cặp thành phần hoạt động đơn giản với mục đích tiêu dùng
các thông điệp đến hoặc cung cấp thông điệp tới các đối tác dịch vụ Web. Đó là thành
phần hoạt động <receive> và <reply>. Tất cả các thành phần hoạt động đó cho
phép trao đổi thông điệp cùng với các đối tác (các dịch vụ Web) bên ngoài.
Thành phần hoạt động <receive> cho phép tiến trình nghiệp vụ nhận một thông
điệp từ đối tác bên ngoài, nó hoàn thành khi thông điệp đến. Vì thế, một <receive>
luôn đặc tả thuộc tính partnerLink và thao tác operation của các đối tác dịch
vụ Web như thuộc tính của nó. Hơn nữa, <receive> đặc tả một biến, sử dụng thuộc
tính variable, để nhận dữ liệu thông điệp.
partnerLink="ClientStartUpPLT"
operation="StartProcess" ... />
Một thành phần <receive> có thể kết hợp cùng thành phần <reply>. Thành phần
hoạt động <reply> cho phép tiến trình nghiệp vụ trả lời một thông điệp đã nhận bởi
thành phần gửi đến như là <receive>, <onMessage>, hoặc <onEvent>. Một
<reply> đặc tả một thuộc tính variable để tham chiếu biến chứa dữ liệu thông
điệp đã được gửi trước đó.
10
operation="StartProcess" ... />
Thành phần liên quan tới dịch vụ Web nữa là thành phần hoạt động <invoke>.
<invoke> được sử dụng để gọi tới một dịch vụ Web đã được cung cấp bởi một đối
tác khai báo trước. Vì thế, thuộc tính partnerLink và thao tác operation sẽ
được đặc tả. Các operation là các thao tác yêu cầu – phản hồi, hoặc một chiều,
tương ứng trong mô tả WSDL đi kèm. <invoke> được xem là một thành phần cơ
bản, tuy nhiên, thành phần này có thể bao đóng các thành phần khác, điều khiển bù và
xử lý lỗi như <correlation>, <catch>, <compensationHandler>.
operation="partnerOperation" ... />
1.5.2.
Cấu trúc hóa logic tiến trình
BPEL cung cấp nghĩa để cấu trúc logic nghiệp vụ theo sự cần thiết của ứng dụng. Nếu
cần một sự tuần tự của các thành phần hoạt động, sử dụng thành phần hoạt động
<sequence> của BPEL. <sequence> được sử dụng để định nghĩa một tập của các
hoạt động được thực thi một cách tuần tự. Thành phần <sequence> hoàn thành khi
thành phần cuối cùng trong bao đóng <sequence> đã hoàn thành.
<sequence name="InvertMessageOrder">
<receive name="receiveOrder" ... />
<invoke name="checkPayment" ... />
<invoke name="shippingService" ... />
<reply name="sendConfirmation" ... />
</sequence>
Thành phần khác được sử dụng cấu trúc hóa logic nghiệp vụ là thành phần hoạt động
<if>. <if> cho phép lựa chọn chính xác một nhánh của hoạt động từ một tập lựa
chọn. Với mỗi lựa chọn, hành vi được kiểm tra điều kiện và nếu điều kiện <if> trả về
true, nhánh kết hợp được thực thi. Thuộc tính <condition> chứa biểu thức điều
kiện có thể sử dụng các biểu thức XPath để biểu diễn, điều khiển logic thực thi nhánh
nào của <if> phụ thuộc vào điều kiện <condition> trả về giá trị true.
11
<if name="isOrderBiggerThan5000Dollars">
<condition>
$order > 5000
</condition>
<invoke name="calculateTenPercentDiscount" ... />
<elseif>
<condition>
$order > 2500
</condition>
name="calculateFivePercentDiscount"
...
/>
</elseif>
<else>
<reply name="sendNoDiscountInformation" ... />
</else>
</if>
1.5.3.
Các thành phần hoạt động lặp
BPEL đưa ra ba thành phần cho phép thực thi lặp một phần logic nghiệp vụ. Một trong
đó là thành phần hoạt động <while>. <while> cũng là thành phần có cấu trúc.
<while> cho phép thực thi lặp thành phần con khi điều kiện trả lại true.
<while>
<condition>
$iterations > 3
</condition>
<invoke name="increaseIterationCounter" ... />
</while>
Thành phần hoạt động <repeatUntil> được sử dụng để định nghĩa các thành phần
con được lặp lại cho đến khi đặc tả <condition> trở thành true. <condition>
được kiểm tra sau activity con hoàn thành. Activity <repeatUntil> được sử dụng
để thực thi thành phần con ít nhất một lần, (thực thi khối lệnh trước mới kiểm tra điều
kiện).
12
<repeatUntil>
<invoke name="increaseIterationCounter" ... />
<condition>
$iterations > 3
</condition>
</repeatUntil>
Thành phần hoạt động thứ ba thực thi lặp các thành phần khác là <forEach>.
<forEach> lặp lại thành phần con của nó chính xác N+1 lần khi N bằng
<finalCounterValue> trừ <startCounterValue>. Nếu thuộc tính parallel
bằng yes thì đó là một <forEach> song song khi các thể hiện N+1 của thành phần
<scope> kèm theo nên xuất hiện song song. Thực chất, một luồng ẩn tạo động cùng
N+1 bản sao của <scope> của <forEach>. Một điều kiện đặc tả sự hoàn thành
<completionCondition> được sử dụng trong <forEach> thông báo hoàn
thành khi không thực thi hoặc kết thúc tất cả nhánh đặc tả.
<forEach parallel="no" counterName="N" ...>
<startCounterValue>1</startCounterValue>
<finalCounterValue>5</finalCounterValue>
<scope>
<documentation>check availability of each item
ordered</documentation>
<invoke name="checkAvailability" ... />
</scope>
</forEach>
1.5.4.
Xử lý song song
WS-BPEL đưa ra thành phần hoạt động <flow> cho phép điều khiển các thành phần
chạy song song. Nó cho phép tập các thành phần bắt đầu một cách đồng thời khi
<flow> bắt đầu. Tuy nhiên, trong bao đóng <flow>, ngoài xử lý song song, còn có
thể dùng thành phần <link> để điều khiển sự phụ thuộc giữa các thành phần mà
thành phần hoạt động đích của <link> sẽ được thực hiện nếu thành phần là nguồn
<source> của <link> đó đã hoàn thành. Các <link> có thể sử dụng hai điều kiện
<transitionCondition> cho thành phần nguồn <source> và điều kiện nối
<joinCondition> cho thành phần đích <target>.
13
<flow ...>
<links>
<link name="checkFlight-To-BookFlight" />
</links>
<documentation>
check availability of a flight, hotel and rental
car concurrently
</documentation>
<invoke name="checkFlight" ...>
<sources>
<source linkName="checkFlight-To-BookFlight" />
</sources>
</invoke>
<invoke name="checkHotel" ... />
<invoke name="checkRentalCar" ... />
<invoke name="bookFlight" ...>
<targets>
linkName="checkFlight-To-BookFlight"
/>
</targets>
</invoke>
</flow>
1.5.5.
Thao tác dữ liệu
BPEL đưa ra thành phần hoạt động <assign> được sử dụng để tạo bản sao dữ liệu
từ một biến tới biến khác, như cập nhật các giá trị của các biến cùng với dữ liệu mới sử
dụng biểu thức. Biểu thức thao tác trên các biến, các thuộc tính, và các hằng để thao
tác một giá trị mới. <assign> chứa một hoặc nhiều thao tác <copy>. Mỗi thao tác
<copy> có một đặc tả <from> và đặc tả <to>, đòi hỏi các thành phần nguồn và
đích, nơi dữ liệu được bảo sao từ <from> và <to>.
<assign>
<copy>
variable="Input"
14
<query>
creditCardInformation
</query>
</from>
<to variable="CreditCardServiceInput" />
</copy>
</assign>
1.5.6.
Điều khiển ngoại lệ
BPEL cung cấp cơ chế để phát hiện trường hợp ngoại lệ xuất hiện và cũng có thể điều
khiển để xử lý ngoại lệ. Trước đó, BPEL đưa ra khái niệm trình điều khiển lỗi. Một
trình xử lý lỗi có thể gắn kèm tới một <scope>, một
trong các thành phần hoạt động như <invoke>.
Thành phần <faultHandlers> chứa các xử lý lỗi định nghĩa các activity thực thi phản
hồi trả về một kết quả lỗi từ lời gọi thông qua sự đánh giá xử lý và các dịch vụ chấp
nhận.
<faultHandlers>
</catch>
<catchAll>...</catchAll>
</faultHandlers>
Ngoài ra, thành phần để kiểm chứng giá trị của các biến <validate>, nó có thuộc
tính variables để nói đang gọi tới biến nào trong một tiến trình BPEL. Còn thành
phần <throw> để ném ra một lỗi từ bên trong tiến trình.
standard-attributes>
standard-elements
</throw>
15
