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 chophép bạn hiểu các nguyên tắc khóa khác của hướng dịch
Trang 1ĐẠ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
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
Trang 2MỤC LỤC
Kiến trúc hướng dịch vụ - Service Oriented Architecture 5
1.1 Các nguyên tắc cơ bản của hướng dịch vụ (Service orientation) 5
1.2 Áp dụng các nguyên tắc SOA 7
1.3 SOA tổng hợp (SOA Compositions) 14
1.4 Sự xếp đặt (Orchestration) 14
1.5 Nghệ thuật biên đạo (Choreography) 15
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 17
2.2 Định nghĩa tiến trình 18
2.3 Phần tử import 19
2.4 Các định nghĩa <partnerLinkType> và <role> trong file WSDL 20
2.5 Các định nghĩa partnerLinks và partnerLink 21
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 25
2.12 Hoạt động cơ bản: Phần tử wait 26
2.13 Hoạt động cơ bản: Phần tử throw 26
2.14 Hoạt động cơ bản: Phần tử exit 26
2.15 Hoạt động cơ bản: Phần tử empty 27
2.16 Hoạt động có cấu trúc: Phần tử while 27
2.17 Hoạt động có cấu trúc: Phần tử if 27
2.18 Hoạt động có cấu trúc: Phần tử pick 27
2.19 Hoạt động có cấu trúc: Phần tử flow 27
2.20 Hoạt động có cấu trúc: Phần tử compensationHandler 27
2.21 Hoạt động có cấu trúc: Phần tử correlationSets 27
2.22 Hoạt động có cấu trúc: Phần tử eventHandlers 27
2.23 Hoạt động có cấu trúc: Phần tử scope 28
3 Java Business Integration (JBI) – JSR 208 0
3.1 JBI Meta-Container 1
3.2 Service Engines 1
3.3 Binding Components 1
3.4 Normalized Message Router 2
3.5 JBI Normalize Message 2
3.6 Delivery Channel (kênh phân phối) 3
3.7 JBI Message Exchange Pattern 4
Trang 33.8 Service Invocation Patterns 4
3.9 In-Only Message Exchange Pattern 5
3.10 Robust In-Only Message Exchange Pattern 5
3.11 In – Out Message Exchange Pattern 5
3.12 JBI Message Exchange Routing 6
3.13 Information in the Service Units and Service Assemblies Routing 8
3.14 Service Unit Deployment for a Service Engine 8
3.15 JBI Composite Application Service Assembly 9
3.16 Connection Elements 9
3.17 Service Unit Deployments Intended for a Binding Component 9
3.18 Sample Descriptors 10
3.19 JBI Management, Monitoring, and Administration 11
3.20 Development of a JBI Component ( Service Engine or Binding Component) 11
3.21 Service Unit and Service Assembly Creation and Packaging 12
3.22 Service Assembly Deployment to the JBI Environment 13
Trang 41 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áctrê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ácnhau, 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 ứngdụ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 choviệ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ể haythiế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 Servicehiệ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ảituâ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ùngmộ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 chophé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ạngthá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ự
Trang 5động Bên trong phần Binding với WSDL được mô tả trong chương trước, bạnthấ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ácquy đị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 đồngdịch vụ, dấu đi sự thi hành mô tả chi tiết từ các dịch vụ khách hàng (serviceconsumers) Điều này có nghĩa rằng các dịch vụ tương tác với nhau chỉ thông quacá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áchhà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ínhliê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 đượctổng hợp Ví dụ, sử dụng ngôn ngữ xếp đặt (orchestration), ví dụ WS-BPEL, chophé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 đượcthả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ụ
Trang 6khô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 độclậ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ếubạ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ươnglai
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ôngthể í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ểuxem 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ápSOA 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ụ, ápdụ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
Trang 7ứ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ỏisau:
- 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ướcchung 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ảiphá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
Trang 8- 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, đạidiệ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êucầ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ý:
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àogiao 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ạnthê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
Trang 9thao 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ềukhiể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ựcsự.
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óivới service provider trả lại toàn bộ tài liệu đặc tả đề xuất có tiêu đề là “Building serviceswith PHP and Oracle XML DB” Nếu bạn gọi lại từ ví dụ đã thảo luận trong phầnBinding 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ànhphầ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:
Trang 10Khi 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ươngthứ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 đượctrì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 thaotá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
Trang 11giống như tài liệu WSDL đã thảo luận trong phần Binding with WSDL, các tài liệuWSDL 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ầnràng buộc (binding sections).
Ví dụ, tài liệu WSDL mô tả dịch vụ Proposal có thể như sau:
Trang 12[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
Trang 13được hỗ trợ bởi dịch vụ Proposal Thông tin liên kết (binding information) cho mỗi thaotá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ấutrú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ànhmộ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 SOAtổ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áchthứ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:
Trang 14Như 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ụ trongnghiệ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 ÁpDụ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 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ớixuất bản tài liệu
WS-1.5 Nghệ thuật biên đạo (Choreography)
Đặc tả Web Services Choreography cùng với Web Services Choreography DescriptionLanguage (WS-CDL) tương ứng cung cấp một cách khác để xây dựng các SOA tổnghợ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ệnmố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 trongphạ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ểntậ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ẽ đượcthự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
Trang 15hiệ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ớinhau 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àmviệ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ộtchoreography 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ềukhiể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ủahai dịch vụ Cụ thể hơn, tài liệu WS-CDL choreography mô tả các thông điệp trao đổigiữ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ủanó
[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 http://www.w3.org/TR/ws-cdl-10/ ]
Trang 162 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ữngtiế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ếntrình này với nhau được gọi là orchestration (phối hợp) WS-BPEL cho phéporchestration 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ữacá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ớinhữ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ếntrì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ạngthá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ệucá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áccô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 VisualDesigner tham chiếu những kiến trúc này và các những phần tử ngôn ngữ bên trongnhững widget đồ họa của nó
Ví dụ về một khung định nghĩa tiến trình BPEL
Trang 172.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ĩatiế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
Trang 18-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ủangôn ngữ mã hóa Giá trị phải được thiết lập giá trị là http://www.w3.org/2001/XMLSchema
nếu các tài liệu WSDL 1.1 được nhập vào
Trang 192.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 processcủ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ả haiphần tử <role> Ví dụ với một phần tử con <role>
Trang 20Trong 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ếntrì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ùngmộ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 giavà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 đốitá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ĩahoặ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ếntrì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ệcgiao 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ể đóngvai trò LoanRequestor và tiến trình đối tác LoanProcessorEJB có thể đóng vaiLoanProcessor
Trang 21Phần tử <partnerLink/> chứa thuộc tính myRole và partnerRole để thiết lập những vainà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ếntrì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ênquan đế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 luuwtrong 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ộtvariable của tiến trình:
Trang 22-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ỗithô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ủathuộ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ìnhphứ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
Trang 232.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ầudịch vụ)
Trang 24-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ậnyê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ởichạ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ìnhtrao đổ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ộtbiến số tiến trình đến dịch vụ tiến trình khác
