BÁO CÁO Môn Kiến trúc hướng dịch vụ (SOA) Đề tài Tìm hiểu về BPEL Enginge

ĐẠI HỌC QUỐC GIA HÀ NỘI
VIỆN CÔNG NGHỆ THÔNG TIN
o0o
BÁO CÁO
Môn: Kiến trúc hướng dịch vụ (SOA)
Đề tài:
Tìm hiểu về BPEL Enginge
Giảng viên: TS. Võ Đình Hiếu
Nhóm thực hiện:
Nguyễn Trần Ngọc Linh
Nguyễn Việt Bảo
Hà Thị Huyền
Nguyễn Trọng Khôi
Vũ Đức Tiệp
Lớp: Quản lý hệ thống thông tin K1
Hà Nội, tháng 04/2011
MỤC LỤC
1 1. Kiến trúc hướng dịch vụ - Service Oriented Architecture 4
1.1 Các nguyên tắc cơ bản của hướng dịch vụ (Service orientation) 4
1.2 Áp dụng các nguyên tắc SOA 6
1.3 SOA tổng hợp (SOA Compositions) 13
1.4 Sự xếp đặt (Orchestration) 13
1.5 Nghệ thuật biên đạo (Choreography) 14
2 Ngôn ngữ thực thi tiến trình nghiệp vụ dịch vụ web (WS-BPEL) 16
2.1 Tóm tắt ngắn gọn về BPEL 16
2.2 Định nghĩa tiến trình 17
2.3 Phần tử import 18
2.4 Các định nghĩa <partnerLinkType> và <role> trong file WSDL 19
2.5 Các định nghĩa partnerLinks và partnerLink 20
2.6 Các định nghĩa variables và variable 21
2.7 Hoạt động có cấu trúc: Phần tử liên tục 22

2.8 Hoạt động dịch vụ web: Phần tử trả về 23
2.9 Hoạt động cơ bản: các phần tử assign, copy, from và to 24
2.10 Hoạt động dịch vụ web: Phần tử invoke 25
2.11 Hoạt động dịch vụ web: Phần tử reply 26
2.12 Hoạt động cơ bản: Phần tử wait 27
2.13 Hoạt động cơ bản: Phần tử throw 28
2.14 Hoạt động cơ bản: Phần tử exit 28
2.15 Hoạt động cơ bản: Phần tử empty 28
2.16 Hoạt động có cấu trúc: Phần tử while 28
2.17 Hoạt động có cấu trúc: Phần tử if 28
2.18 Hoạt động có cấu trúc: Phần tử pick 28
2.19 Hoạt động có cấu trúc: Phần tử flow 28
2.20 Hoạt động có cấu trúc: Phần tử compensationHandler 29
2.21 Hoạt động có cấu trúc: Phần tử correlationSets 29
2.22 Hoạt động có cấu trúc: Phần tử eventHandlers 29
2.23 Hoạt động có cấu trúc: Phần tử scope 29
3 Java Business Integration (JBI) – JSR 208 30
3.1 JBI Meta-Container 31
3.2 Service Engines 32
3.3 Binding Components 32
3.4 Normalized Message Router 33
3.5 JBI Normalize Message 34
3.6 Delivery Channel (kênh phân phối) 34
3.7 JBI Message Exchange Pattern 36
3.8 Service Invocation Patterns 36
3.9 In-Only Message Exchange Pattern 36
3.10 Robust In-Only Message Exchange Pattern 37
3.11 In – Out Message Exchange Pattern 38
3.12 JBI Message Exchange Routing 39
3.13 Information in the Service Units and Service Assemblies Routing 41

3.14 Service Unit Deployment for a Service Engine 41
3.15 JBI Composite Application Service Assembly 42
3.16 Connection Elements 43
3.17 Service Unit Deployments Intended for a Binding Component 43
3.18 Sample Descriptors 44
3.19 JBI Management, Monitoring, and Administration 45
3.20 Development of a JBI Component ( Service Engine or Binding Component) 46
3.21 Service Unit and Service Assembly Creation and Packaging 46
3.22 Service Assembly Deployment to the JBI Environment 48
1 1. Kiến trúc hướng dịch vụ - Service Oriented Architecture
Trong khi việc sử dụng Web service cho phép bạn đạt được khả năng tương tác
trên các ứng dụng được xây dựng trên nhiều nền tảng khác nhau với các ngôn ngữ khác
nhau, việc áp dụng các khái niệm và nguyên tắc hướng dịch vụ khi xây dựng các ứng
dụng dựa trên việc sử dụng Web service có thể giúp bạn tạo các giải pháp SOA mạnh mẽ,
dựa trên chuẩn và có khả năng tương thích.
[Có điều thú vị rằng Kiến trúc hướng dịch vụ trong khi cung cấp nền tảng kiến trúc cho
việc xây dựng các giải pháp hướng dịch dụ, nó không trói buộc một công nghệ cụ thể hay
thiết đặt công nghệ nào cả. Ngược lại, nó có thể được thực thi với nhiều loại công nghệ,
ví dụ: DCOM, CORBA, hoặc Web Service. Tuy nhiên, chỉ có công nghệ Web Service
hiện tại đang là hướng chính để đưa SOA vào thực tế.
1.1 Các nguyên tắc cơ bản của hướng dịch vụ (Service orientation)
Như đã được đề cập, để xây dựng một giải pháp SOA dựa trên Web service, bạn cần phải
tuân theo các nguyên tắc hướng dịch vụ khi sử dụng các dịch vụ cùng nhau trong cùng
một ứng dụng. Dưới đây là một vài nguyên tắc quan trọng (khóa) của hướng dịch vụ mà
bạn cần phải nhớ khi thiết kế các giải pháp SOA:
- Kết nối lỏng lẻo (Loose coupling): biểu diễn một mối liên hệ thiếu logic của một
dịch vụ để thay đổi một cách tối thiểu hoặc tác động đến các dịch vụ khác được sử
dụng trong cùng SOA. Kết nối lỏng lẻo là nguyên tắc khóa của hướng dịch vụ.
Các dịch vụ thực thi như các thành phần được liên kết lỏng lẻo của phần mềm cho
phép bạn hiểu các nguyên tắc khóa khác của hướng dịch vụ, ví dụ như: khả năng

sử dụng lại dịch vụ, dịch vụ tự chủ (service autonomy), và dịch vụ không trạng
thái (service statelessness).
- Hợp đồng dịch vụ (Service contract): biểu diễn các mô tả dịch vụ và các tài liệu
khác. Nó mô tả cách một dịch vụ có thể được truy cập chương trình một cách tự
động. Bên trong phần Binding với WSDL được mô tả trong chương trước, bạn
thấy một ví dụ về tài liệu mô tả dịch vụ WSDL mô tả một dịch vụ, định nghĩa các
quy định cho dịch vụ đó.
- Trừu tượng hóa của thiếu logic (Abstraction of underlying logic): có nghĩa
rằng một dịch vụ được đưa ra công khai chỉ khi logic được mô tả trong hợp đồng
dịch vụ, dấu đi sự thi hành mô tả chi tiết từ các dịch vụ khách hàng (service
consumers). Điều này có nghĩa rằng các dịch vụ tương tác với nhau chỉ thông qua
các giao diện công khai của chúng. Như bạn đã học trong ví dụ trước, bộ mô tả
WSDL mô tả một dịch vụ cung cấp các giao diện thực sự cho các dịch vụ khách
hàng.
- Tự chủ (Autonomy): có nghĩa là các dịch vụ chỉ kiểm soát về logic tính đóng gói
của chúng. Việc phân chia ứng dụng về mặt logic thành tập các dịch vụ có tính tự
chủ cho phép bạn xây dựng các giải pháp SOA một cách linh hoạt, đạt được tính
liên kết lỏng lẻo, khả năng sử dụng lại và khả năng tổng hợp (composability).
- Khả năng tái sử dụng (Reusability) trong hướng dịch vụ được thực hiện bằng
cách phân tán ứng dụng về mặt logic giữa các dịch vụ để mỗi dịch vụ có thể được
sử dụng bởi nhiều một service requestor. Việc xây dựng các dịch vụ có thể tái sử
dụng hỗ trợ các nguyên tắc tổng thể (composability).
- Có khả năng tổng hợp (composability) mô tả khả năng các dịch vụ được kết hợp
thành dịch vụ hoàn chỉnh, phối hợp trao đổi dữ liệu giữa các dịch vụ đang được
tổng hợp. Ví dụ, sử dụng ngôn ngữ xếp đặt (orchestration), ví dụ WS-BPEL, cho
phép bạn tổng hợp các dịch vụ tinh thành các dịch vụ thô hơn. WS-BPEL được
thảo luận tại phần BPEL sau của chương này.
- Không trạng thái (Statelessness) có nghĩa rằng các dịch vụ không duy trì trạng
thái cụ thể nào của chúng cho một hành động nào. Việc xây dựng các dịch vụ
không trạng thái khuyến khích tính liên kết lỏng lẻo, khả năng tái sử dụng và khả

năng tổng hợp (composability).
- Khả năng tương tác (Interoperation) giữa các dịch vụ dễ dàng đạt được miễn là
các dịch vụ tương tác với mỗi dịch vụ khác thông qua các giao diện, đảm bảo độc
lập thực thi và độc lập nền tảng.
- Có khả năng nhận biết (Discoverability) đề cập đến các cơ chế chuẩn làm cho
nó có khả năng trong việc mô tả dịch vụ được nhận biết bởi các service requestor.
Đặc tả Universal Description, Discovery và Integration (UDDI) cung cấp một cơ
chế cho phép xuất bản các tài liệu mô tả dịch vụ trong một registry dựa trên XML,
do đó làm cho chúng sẵn sàng sử dụng một cách công khai.
Như bạn thấy, hầu hết các khái niệm đều có liên quan chặt chẽ với nhau. Ví dụ, nếu
bạn theo nguyên tắc tự chủ khi phân chia ứng dụng logic thành các dịch vụ được sử
dụng trong SOA, bạn sẽ có các được các nguyên tắc: tái sử dụng, có thể tổng hợp, và
liên kết lỏng lẻo các thành phần của phần mềm để tái sử dụng trong các dự án tương
lai.
Mặt khác, việc bỏ qua ít nhất một nguyên tắc của hướng dịch vụ làm cho nó khó có
thể giữ được các nguyên tắc khác. Ví dụ, nếu bạn bỏ qua nguyên tắc không trạng thái
(statelessness) khi thiết kế các dịch vụ, bạn sẽ kết thúc với khối xây dựng mà không
thể ít sử dụng và ít có thể tổng hợp cho các giải pháp SOA của bạn.
1.2 Áp dụng các nguyên tắc SOA
Bây giờ các bạn đã biết các nguyên tắc khóa của hướng dịch vụ, đã đến lúc tìm hiểu
xem làm thế nào để các nguyên tắc này có thể được áp dụng khi thiết kế các giải pháp
SOA. Phần này thảo luận ngắn về tiến trình thiết kế một ứng dụng hướng dịch vụ, áp
dụng các nguyên tắc hướng dịch vụ nêu trong phần trước.
Giai đoạn phân tích hướng dịch vụ là giai đoạn đầu tiên trong tiến trình thiết kế một
ứng dụng hướng dịch vụ. Bất kể việc liệu bạn sẽ xây dựng một giải pháp SOA khi
ứng dụng logic có sẵn hay xây dựng nó từ đầu, bạn phải cân nhắc theo các câu hỏi
sau:
- Dịch vụ nào được yêu cầu để thỏa mãn các yêu cầu nghiệp vụ?
- Ứng dụng logic nên được phân chia như thế nào giữa các dịch vụ?
- Các dịch vụ nên được tổng hợp như thế nào để thực thi giải pháp SOA đã yêu cầu?

Cách dễ nhất để hiểu được những gì phải được hoàn thành ở giai đoạn này là lên một ví
dụ.
Hãy tưởng tượng bạn chạy một trang tạp chí trực tuyến chuyên về xuất bản các bài báo
kỹ thuật được gửi bởi những kỹ thuật viên làm việc trên cơ sở hợp đồng. Khi một tác giả
tiềm năng gửi một đề xuất (proposal), bạn nhìn qua và sau đó chấp nhận hoặc từ chối nó,
tùy thuộc vào nhu cầu biên tập hiện tại của bạn và một vài thứ khác. Sau đây là các bước
chung bạn phải thực hiện khi chấp nhận một đề xuất:
1. Lưu đề xuất vào cơ sở dữ liệu
2. Lưu thông tin về tác giả (chỉ khi tác giả mới)
3. Thông báo cho tác giả về việc chấp nhận đề xuất.
4. Ban hành (issue) một PO
5. Gửi PO về cho tác giả.
Bây giờ, giả sử bạn muốn thiết kế một giải pháp SOA tự động hóa tiến trình này.
Như đã đề cập trước đó, điều đầu tiên bản phải xác định được những dịch vụ nào phải
được xây dựng. Suy nghĩ những nguyên tắc hướng dịch vụ đã nêu trong phần trước, bạn
có thể tạo ra các dịch vụ sau đây để sau đó được sử dụng khi xây dựng các khối trong giải
pháp SOA đang được thiết kế:
- Dịch vụ đề xuất
- Dịch vụ tác giả
- Dịch vụ thanh toán hóa đơn
- Dịch vụ thông báo
Như bạn đã thấy, 3 dịch vụ đầu tiên trong danh sách trên là các dịch vụ trọng tâm, đại
diện các thực thể nghiệp vụ tương ứng.
[Có 2 hướng tiếp cận chính để thiết kế các dịch vụ đại diện nghiệp vụ logic: thực thể
trọng tâm và nhiệm vụ trọng tâm. Trong khi một dịch vụ nhiệm vụ trọng tâm bị ràng
buộc chặt chẽ với một nhiệm vụ cụ thể và vì vậy khó có thể thay đổi và tái sử dụng, một
dịch vụ thực thể trọng tâm đại diện cho một thực thể nghiệp vụ cụ thể, đại diện cho sự
thay đổi tốt đang được sử dung lại trong các giải pháp đối với thực thể nghiệp vụ tương
tự. cả hai hướng tiếp cận được thảo luận chi tiết trong chương 7, trong đó tập trung vào
các vẫn đề liên quan đến mô hình nghiệp vụ hướng đối tượng.]

Một dịch vụ thực thể trọng tâm thường cung cấp một tập đầy đủ các thao tác được yêu
cầu để thao tác trong một cá thể của thực thể nghiệp vụ cụ thể. Ví dụ, dịch vụ Proposal
(đề xuất) có thể hỗ trợ tập các thao tác sau đây để đáp ứng các yêu cầu xử lý:
- saveProposal
- getProposalById
- getProposalByTitle
- getProposalsByAuthor
- getProposalsByTopic
Giả sử rằng các tài liệu đề xuất được gửi lên có một cấu trúc nhất định (nói, từng đề nghị
bao gồm chủ đề - Topic và phần dàn ý – Outline), danh sách các thao tác ở trên hỗ trợ bởi
dịch vụ Proposal có thể cần được mở rộng thêm một vài thao tác có trách nhiệm duyệt
các phần cụ thể của một đề xuất.
Tuy nhiên, điều quan trọng để nhận ra rằng việc bao gồm các thao tác mới tác động vào
giao diện dịch vụ, làm cho bạn phải chỉnh sửa tài liệu WSDL mô tả dịch vụ mỗi lần bạn
thêm một thao tác mới. Có một cách để làm việc xung quanh vấn đề này là sử dụng các
thao tác điều khiển tham số, chúng gọi phần yêu cầu thiếu logic phụ thuộc vào đối số
được truyền vào. Trong trường hợp này, việc đóng gói hàm thiếu logic của thao tác điều
khiển tham số ủy thác công việc cho một vài hàm khác nơi mà công việc hoàn thành thực
sự.
Ví dụ, bạn phải đưa ra một thao tác đơn để nhận về nội dung của một đề xuất, các tham
số truyền vào các định xem liệu có tìm thấy tài liệu đề xuất thông qua ID hay tiêu đề và
phần nào của đề xuất sẽ được trả lại. Trong trường hợp này, một thông điệp yêu cầu được
đưa ra bởi một requestor để gọi đến thao tác getProposal như sau:
Khi ban không đoán ra được bất kỳ nghi ngờ nào, tham số sử dụng trong ví dụ này nói
với service provider trả lại toàn bộ tài liệu đặc tả đề xuất có tiêu đề là “Building services
with PHP and Oracle XML DB”. Nếu bạn gọi lại từ ví dụ đã thảo luận trong phần
Binding with WSDL, cấu trúc thông điệp mô tả nội dung trừu tượng logic của thông điệp
đầu vào hoặc thông điệp đầu ra sẽ sử dụng với một thao tác RPC chứa đựng các thành
phần bộ phận để xác định các tham số phụ thuộc vào thao tác. Vì vậy, cấu trúc thông điệp
mô tả thông điệp đầu vào ở trên trong tài liệu WSDL có thể như sau:

Khi thao tác getProposal được thực thi, các tham số đầu vào đến với thông điệp yêu cầu
được truyền vào phương thức điều khiển cơ bản bên trong lời gọi trả về một phương thức
cơ bản getProposal* thích hợp, phụ thuộc vào các giá trị của các tham số truyền vào.
Hướng tiếp cận này cho phép bạn giảm bớt số lượng thao tác trình bày bởi một dịch vụ
trong khi vẫn cung cấp các tính năng được yêu cầu. Bây giờ bạn có thể thêm một phương
thức mới vào lớp cơ bản (underlying layer) của dịch vụ (thông thường, tầng này được
trình bày bởi một class) và tạo cho phương thức đó sẵn có cho các service requestor mà
không phải chỉnh sửa tài liệu WSDL xác định giao diện dịch vụ.
Bây giờ, giả định rằng bạn áp dụng hướng tiếp cận ở trên cho tất cả các dịch vụ nghiệp vụ
được đề cập trước đó trong phần này, bạn có thể cắt giảm đáng kể một số lượng các thao
tác được trình bày bởi các dịch vụ này, trình bày công khai chỉ các thao tác chung như
hình sau đây:
Như bạn thấy, mỗi dịch vụ được mô tả trong hình, ngoại trừ dịch vụ thông báo
(Notification service), đều hỗ trợ nhiều hơn một thao tác. Điều này có nghĩa rằng không
giống như tài liệu WSDL đã thảo luận trong phần Binding with WSDL, các tài liệu
WSDL mô tả các dịch vụ được thảo luận ở đây sẽ chứa đa thao tác portType và các phần
ràng buộc (binding sections).
Ví dụ, tài liệu WSDL mô tả dịch vụ Proposal có thể như sau:
[Lưu ý rằng tài liệu WSDL này giả định rằng các định nghĩa loại dữ liệu được sử dụng
khi định nghĩa các thông điệp có liên quan được mô tả trong một tài liệu XSD riêng biệt
đặt tại http://localhost/WebServices/schema/proposal.xsd.]
Như bạn thấy, trong tài liệu WSDL này, cấu trúc portType chứa đựng 3 yếu tố thao tác,
mỗi thành phần trong chúng đại diện cho một định nghĩa trừu tượng của một thao tác
được hỗ trợ bởi dịch vụ Proposal. Thông tin liên kết (binding information) cho mỗi thao
tác này được xác định với một yếu tố thao tác tương ứng được định nghĩa bên trong cấu
trúc liên kết (binding construct).
1.3 SOA tổng hợp (SOA Compositions)
Sau khi đã tạo tất cả các dịch vụ cần thiết cho việc tự động hóa quá trình gửi các đề xuất
(submitting proposals), giờ là lúc xem xét tới việc làm thế nào đưa các dịch vụ đó hoạt
động.

Trên thực tế, có một số phương pháp điều phối các dịch vụ để chúng có thể hợp thành
một giải pháp SOA. Ví dụ như bạn có thể tạo ra một dịch vụ tổng hợp như một đoạn mã
PHP hoạt động như một dịch vụ Web mà, đứng trên khía cạnh lập trình, dịch vụ này sẽ
gọi các dịch vụ khác khi cần. Tuy vậy, phương pháp thông dụng nhất để tạo một SOA
tổng hợp là sử dụng WS-BPEL, một ngôn ngữ xếp đặt (orchestration language) cho phép
ta tạo ra các dịch vụ điều khiển được xếp đặt tổng hợp, dùng trong việc định nghĩa cách
thức các dịch vụ được sử dụng phối hợp nhau để hoàn thành công việc.
1.4 Sự xếp đặt (Orchestration)
Một sự xếp đặt gắn kết các dịch vụ tạo thành một quy trình nghiệp vụ thực thi được sẽ
được chạy bởi một máy xếp đặt. Nhìn chung, một sự xếp đặt có cấu trúc như sau:
Như ta thấy, hình vẽ trên thể hiện một sự kết hợp các dịch vụ được điều phối bởi hệ
thống logic thể hiện trong dịch vụ điều khiển (controller service). Dịch vụ điều khiển này
có thể là một quy trình nghiệp vụ WS-BPEL mà có thể hoàn thành một tác vụ trong
nghiệp vụ khi được thực thi ngược với máy xếp đặt. Trong ví dụ này, bộ phận điều khiển
có thể được bố trí sao cho nó hoàn tất các bước liệt kê ở đoạn đầu của phần trước Áp
Dụng Các Nguyên Lý SOA.
[ Một dịch vụ điều khiển xây dựng với ngôn ngữ xếp đặt WS_BPEL, giống như bất kỳ
dịch vụ khác, nên có một tài liệu WSDL tương ứng mô tả dịch vụ đến khách hàng của nó.
Xây dựng các định nghĩa WSDL cho các dịch vụ tổng hợp là xây dựng với WS_BPEL
được thảo luận trong phần “WSDL definitions for Composite Services” được mô tả sau
trong chương này]
Bạn có thể tạo một sự xếp đặt được dùng như một dịch vụ trong một sự xếp đặt lớn hơn.
Ví dụ, sự xếp đặt thể hiện trong hình vẽ trên có thể là một phần của một sự xếp đặt WS-
BPEL mà có thể làm tự động hóa toàn bộ quá trình biên tập từ chấp nhận đề xuất cho tới
xuất bản tài liệu.
1.5 Nghệ thuật biên đạo (Choreography)
Đặc tả Web Services Choreography cùng với Web Services Choreography Description
Language (WS-CDL) tương ứng cung cấp một cách khác để xây dựng các SOA tổng
hợp. Trong khi WS-BPEL dùng để bố trí các dịch vụ thành các giải pháp tổng hợp và
thường thể hiện các luồng quy trình nghiệp vụ riêng biệt, WS-CDL cho phép thể hiện

mối quan hệ ngang hàng giữa các dịch vụ WEB và các thành phần tham gia khác trong
phạm vi được tin tưởng.
Không giống với sự xếp đặt, choreography không đồng nghĩa với một cơ chế điều khiển
tập trung mà quyền điều khiển được chia sẻ giữa các thành viên tham gia. Điều đó có
nghĩa là một sự xếp đặt biểu hiện một tiến trình thực thi được và tiến trình này sẽ được
thực thi tại thời điểm nào đó bởi một máy xếp đặt, trong khi về cơ bản choreography biểu
hiện một đặc tả về việc quyền điều khiển được phân tán giữa các thành viên cộng tác với
nhau mà không dùng một bộ máy đơn lẻ nào để làm việc đó.
Để định nghĩa một choreography, bạn tạo một tài liệu đặc tả WS-CDL choreography,
được dùng như một bản hợp đồng giữa các thành phần tham gia. Một tài liệu WS-CDL
mô tả thông điệp trao đổi giữa các thành phần cộng tác và các thức các thành phần đó làm
việc với nhau để cùng đạt tới một mục tiêu nghiệp vụ chung. Ví dụ, có thể có một
choreography cho phép một sự hợp tác diễn ra giữa một sự xếp đặt, một dịch vụ điều
khiển đại diện cho một tiến trình WS-BPEL, và một dịch vụ khách tương tác với dịch vụ
điều khiển này.
Trong hình trên, tầng choreography được dùng để đặc tả các mối quan hệ ngang hàng của
hai dịch vụ. Cụ thể hơn, tài liệu WS-CDL choreography mô tả các thông điệp trao đổi
giữa các dịch vụ tổng hợp (đã được trình bày trong phần trước) và một khách hàng của
nó.
[Việc thảo luận đầy đủ về đặc tả Choreography và ngôn ngữ WS-CDL tương ứng của nó
nằm ngoài phạm vi của cuốn sách này. Để biết thêm thông tin về chủ đề này, bạn có thể
xem thêm tài liệu W3C trên WS-CDL tại ]
2 Ngôn ngữ thực thi tiến trình nghiệp vụ dịch vụ web (WS-BPEL)
BPEL được sử dụng để tạo ra các tiến trình có thể gọi được những tiến trình khác, những
tiến trình này đáp ứng một nghiệp vụ nào đó trong luồng công việc. Việc kết hợp các tiến
trình này với nhau được gọi là orchestration (phối hợp). WS-BPEL cho phép
orchestration bằng cách cung cấp các chuẩn tích hợp logic và các tiến trình tự động giữa
các dịch vụ web.
Sử dụng các cấu trúc kế thừa từ Ngôn ngữ định nghĩa dịch vụ web (WSDL) , WS-BPEL
mô tả các giao diện tiến trình vào và ra sao cho một tiến trình có thể dễ dàng tích hợp với

những tiến trình hoặc ứng dụng khác. Những mô tả giao diện cho phép những người sử
dụng tiến trình có thể điều tra hoặc gọi một tiến trình WS-BPEL từ bất kỳ một dịch vụ
web nào.
2.1 Tóm tắt ngắn gọn về BPEL
BPEL là một ngôn ngữ chặt chẽ để mở rộng các dịch vụ web cho việc tương tác các tiến
trình. Tiến trình nghiệp vụ BPEL xây dựng stateful (có khả năng lưu khôi phục trạng
thái), kết hợp giao tiếp từ dịch vụ web. Tiến trình BPEL được mô tả bằng XML.
Để thiết kế một ứng dụng thành phần sử dụng WS-BPEL, bạn phải biết ngôn ngữ BPEL.
Bài viết không thể mô tả tất cả khía cạnh của BPEL và khả năng của nó, chỉ giới thiệu
các tính năng để làm nền tảng giúp bạn hiểu các ví dụ ở phần sau.
Người dùng NetBean Enterprice Pack 5.5 có thể sử dụng BPEL Visual Designer và các
công cụ đi kèm để tạo ra các orchestations của chúng và vì thế sẽ không cần phải tạo các
mã BPEL bằng tay. Tuy nhiên hiểu biết về các phần tử vẫn hữu ích vì BPEL Visual
Designer tham chiếu những kiến trúc này và các những phần tử ngôn ngữ bên trong
những widget đồ họa của nó.
Ví dụ về một khung định nghĩa tiến trình BPEL
2.2 Định nghĩa tiến trình
Phần tử gốc của một tiến trình BPEL bất kỳ là định nghĩa <process> . Mỗi định nghĩa
tiến trình có một thuộc tính name và định nghĩa liên quan đến không gian tên
(namespace), xem ví dụ minh họa ở hình dưới
2.3 Phần tử import
Phần tử import, như ví dụ dưới đây, chỉ ra sự độc lập trên ngôn ngữ XML mở rộng (hay
định nghĩa WSDL). Mỗi phần tử import gồm 3 thuộc tính bắt buộc:
-Thuộc tính namespace chỉ ra không gian tên URI của những định nghĩa được nhập vào
-Thuộc tính location chứa một URI chỉ ra địa chỉ của một tài liệu chứa các định nghĩa
liên quan trong không gian tên đã được chỉ ra.
-Thuộc tính imortType chỉ ra kiểu của tài liệu được nhập vào bằng cách đưa ra URI của
ngôn ngữ mã hóa. Giá trị phải được thiết lập giá trị là />nếu các tài liệu WSDL 1.1 được nhập vào.
2.4 Các định nghĩa <partnerLinkType> và <role> trong file WSDL
Phần tử <parterLinkType/> được nhúng trực tiếp bên trong file WSDL của mọi tiến trình

đối tác và dịch vụ tiến trình liên quan trong một BPEL orchestration.
Các phần tử <parterLinkType/> định nghĩa trong file WSDL của đối tác nhận ra phần tử
portType tham chiếu bởi phần tử partnerLink trong định nghĩa thuộc tính BPEL process
của dịch vụ tiến trình.
Phần tử <parterLinkType/> chưa một phần tử <role> cho mỗi vai (bên cung cấp hoặc bên
sử dụng dịch vụ) mà dịch vụ tiến trình có thể chạy, như được định nghĩa bở phần tử
partnerLink gồm 2 thuộc tính myRole (dành cho bên cung cấp dịch vụ) và partnerRole
(dùng cho bên sử dụng dịch vụ). Vì vậy partnerLinkType có thể có hoặc một hoặc cả hai
phần tử <role>. Ví dụ với một phần tử con <role>
Trong trường hợp khi một dịch vụ tiến trình có mối quan hệ như nhau với nhiều tiến
trình đối tác, các thuộc tính partnerLink của dịch vụ tiến trình có thể tham chiếu đề cùng
một partnerLinkType.
2.5 Các định nghĩa partnerLinks và partnerLink
<partnerLink> định nghĩa portType của tiến trình đối tác mà tiến trình đó sẽ tham gia
vào sự kết hợp BPEL của tiến trình nghiệp vụ đang được định nghĩa.Những tiến trình đối
tác có thể đóng vai trò như các máy khách đến dịch vụ tiến trình đang được định nghĩa
hoặc có thể được gọi bởi tiến trình này.
Phần tử <partnerLink> mã hóa thông tin trao đổi giữa tiến trình nghiệp vụ và các tiến
trình đối tác của nó. Vai trò của tiến trình nghiệp vụ sẽ biến đổi theo sự tự nhiên của việc
giao tiếp với tiến trình đối tác của nó. Như trong hình minh họa bên dưới đây, khi dịch vụ
tiến trình LoanRequestor gọi một tiến trình đối tác là LoanProcessorEJB, nó có thể đóng
vai trò LoanRequestor và tiến trình đối tác LoanProcessorEJB có thể đóng vai
LoanProcessor
Phần tử <partnerLink/> chứa thuộc tính myRole và partnerRole để thiết lập những vai
này cho dịch vụ tiến trình và tiến trình đối tác của nó, giống như đoạn code ví dụ dưới
đây.
Thuộc tính myRole được sử dụng khi dịch vụ tiến trình đóng vai bên cung cấp dịch vụ và
đang được gọi bởi tiến trình đối tác khách. Tương tự, thuộc tính partnerRole chỉ ra tiến
trình đối tác phía cung cấp dịch vụ đang được gọi khi đóng vai trò là một khách hàng sử
dụng dịch vụ.

2.6 Các định nghĩa variables và variable
Phần tử <variable/> được sử dụng bởi dịch vụ tiến trình để lưu trạng thái thông tin liên
quan đến logic luồng công việc trực tiếp. Toàn bộ các thông điệp XML có thể được luuw
trong một variable và được lấy về sau đó bởi một tiến trình. Chỉ kiểu dữ liệu giản đồ
XSD được định nghĩa trước mới có thể lưu giữ trong những variable này.
Như định nghĩa của các thuộc tính dưới đây, vài kiểu dữ liệu có thể lưu giữ trong một
variable của tiến trình:
-Thuộc tính messageType cho phép variable chứa toàn bộ thông điệp WSDL đã được
định nghĩa như minh họa ở đoạn code ví dụ bên dưới.
-Thuộc tính element cho phép một variable chưa một phần tử XSD
-Thuộc tính type cho phép một variable chưa bất kỳ một XSD simpleType
Trong ví dụ bên dưới, variables với thuộc tính messageType được định nghĩa cho mỗi
thông đầu vào và đầu ra của thong điệp được xử lý bởi sự định nghĩa tiến trình.Giá trị của
thuộc tính này là tên thông điệp từ sự định nghĩa tiến trình đối tác.
2.7 Hoạt động có cấu trúc: Phần tử liên tục
Những hoạt động có cấu trúc kết hợp với những hoạt động gốc bên trong những tiến trình
phức tạp hơn. Phần tử <sequence/> định nghĩa một số thứ tự của những hoạt động để
chúng được thực thi theo thứ tự mà chúng được liệt kê ra, như ví dụ bên dưới. Các phần
tử <sequence> có thể được định nghĩa bên trong những phần tử <sequence> khác.
2.8 Hoạt động dịch vụ web: Phần tử trả về
Các hoạt động dịch vụ web được định nghĩa bởi BPEL để tao ra các thành phần dịch vụ
web. Phần tử <receive/> định nghĩa thông tin được mong đợi bởi dịch vụ tiến trình (có
vai trò như một bên cung cấp dịch vụ ) chờ để nhận một yêu cầu từ tiến trình đối tác mở
rộng (có vai trò như bên sử yêu cầu dịch vụ).
Các thuộc tính cần có để định nghĩa một nhiệm vụ nhận về gồm:
-Thuộc tính partnerLink: giá trị của thuộc tính này trỏ vào tiến trình đối tác (bên yêu cầu
dịch vụ).
-Thuộc tính portType: giá trị của thuộc tính này chứa kiểu cổng (hay giao diện) của dịch
vụ tiến trình (bên cung cấp dịch vụ). Kiểu cổng này sẽ chờ để nhận yêu cầu dịch vụ từ
bên yêu cầu dịch vụ.

-Thuộc tính opertation: giá trị của thuộc tính này chứa thao tác của dịch vụ tiến trình mà
bên yêu cầu sẽ nhận về.
-Thuộc tính variable: giá trị của thuộc tính này chứa biến số định nghĩa tiến trình mà nó
sẽ được lưu trong thông điệp yêu cầu đến.
-Thuộc tính createInstance: giá trị của thuộc tính này được thiết lập là “yes” nếu khi nhận
yêu cầu từ máy khách, một thể hiện dịch vụ tiến trình mới phải được tạo ra và được khởi
chạy. Nếu giá trị của thuộc tính được thiết lập là “no”, một thể hiện dịch vụ mới không
được tạo ra khi nhận được một yêu cầu.
Phần tử <receive/> cũng được sử dụng để nhận các thông điệp gọi lại trong suốt quá trình
trao đổi thông điệp không đồng bộ.
2.9 Hoạt động cơ bản: các phần tử assign, copy, from và to
Các hoạt động cơ bản được định nghĩa bởi BPEL để tạo ra các thành thần dịch vụ web.
Các phần tử <assign/>, <copy/>, <from/> và <to/> cho phép bạn sao chép dữ liệu từ một
biến số tiến trình đến dịch vụ tiến trình khác.
2.10 Hoạt động dịch vụ web: Phần tử invoke
Phần tử <invoke/> cho phép dịch vụ tiến trình gọi một thao tác một chiều hoặc thao tác
dạng yêu cầu-đáp ứng trên kiểu cổng (hay giao diện) cung cấp bởi tiến trình đối tác.
Dưới đây là 5 thuộc tính phổ biến của phần tử <invoke/>:
-partnerLink: giá trị của thuộc tính này chỉ ra tiến trình đối tác thông qua liên kết này.