Kỹ thuật phát triển ứng dụng web bằng ngôn ngữ Ws Bpel

Ngoài ra, đề tài còn sử dụng một số nhận xét, đánh giá cũng như số liệu của các tác giả, cơ quan tổ chức khác, và cũng được thể hiện trong phần tài liệu tham khảo.. Ngôn ngữ BPEL sẽ định

Số hóa bởi trung tâm học liệu http://www.lrc.tnu.edu.vn/

ĐẠI HỌC THÁI NGUYÊN TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

Số hóa bởi trung tâm học liệu http://www.lrc.tnu.edu.vn/

ĐẠI HỌC THÁI NGUYÊN TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

LỜI CAM ĐOAN

Tôi xin cam đoan rằng đây là công trình nghiên cứu của tôi, có sự hỗ trợ từ Giáo viên hướng dẫn là PGS.TS Đặng Văn Đức Các nội dung nghiên cứu và kết quả trong đề tài này là trung thực và chưa từng được ai công bố trong bất cứ công trình nghiên cứu nào trước đây Những số liệu trong các hình phục vụ cho việc phân tích, nhận xét, đánh giá được chính tác giả thu thập từ các nguồn khác nhau có ghi trong phần tài liệu tham khảo Ngoài ra, đề tài còn sử dụng một số nhận xét, đánh giá cũng như số liệu của các tác giả, cơ quan tổ chức khác, và cũng được thể hiện trong phần tài liệu tham khảo

Nếu phát hiện có bất kỳ sự gian lận nào tôi xin hoàn toàn chịu trách nhiệm trước Hội đồng, cũng như kết quả luận văn của mình

LỜI CẢM ƠN

Để hoàn thành luận văn này, em xin tỏ lòng biết ơn sâu sắc đến thầy PGS.TS.ĐẶNG VĂN ĐỨC, đã tận tình hướng dẫn trong suốt quá trình viết luận văn tốt nghiệp

Em chân thành cảm ơn quý thầy, cô trong trường Đại Học Công nghệ Thông tin và Truyền thông đã tận tình truyền đạt kiến thức trong hai năm học tập Với vốn kiến thức được tiếp thu trong quá trình học là nền tảng cho quá trình nghiên cứu để

em hoàn thành luận văn

Chân thành cảm ơn Ban giám đốc Trung tâm Tin học thuộc Sở Giáo dục và Đào tạo Hải Phòng và các bạn đồng nghiệp đã cho phép và tạo điều kiện thuận lợi

để tôi có thời gian học tập và nghiên cứu trong quá trình đào tạo cao học

Cảm ơn gia đình đã động viên cũng như cảm ơn các bạn lớp CH K10C đã cùng tôi đoàn kết xây dựng tập thể lớp K10C, đạt được những thành tích cao trong học tập

Một lần nữa xin chân thành cảm ơn!

Học viên cao học lớp K10C Phạm Thanh Tùng

MỤC LỤC

LỜI CAM ĐOAN i

LỜI CẢM ƠN ii

MỤC LỤC iii

DANH MỤC HÌNH v

MỞ ĐẦU 1

1 Đặt vấn đề 1

2 Đối tượng và phạm vi nghiên cứu 2

3 Hướng nghiên cứu của đề tài 2

Chương 1 TỔNG QUAN VỀ DỊCH VỤ WEB 3

1.1 Ngôn ngữ XML 3

1.2 Giao thức truy cập dịch vụ Web - SOAP 9

1.2.1 Kiến trúc dịch vụ SOAP 9

1.2.2 Đặc trưng của SOAP 9

1.2.3 Cấu trúc một message theo dạng SOAP 11

1.2.4 Những kiểu truyền thông SOAP 12

1.2.5 Mô hình dữ liệu 12

1.3 Ngôn ngữ mô tả dịch vụ Web - WSDL 12

1.4 Mô tả và tìm kiếm dịch vụ Web – UDDI 14

1.4.1 Lớp dịch vụ Web với UDDI 14

1.4.2 Cấu trúc dữ liệu UDDI 17

1.5 Các dịch vụ web hiện nay đã phát triển 19

1.6 Tình hình nghiên cứu hiện nay trong và ngoài nước 19

Chương 2 NGÔN NGỮ BPEL 21

2.1 Giới thiệu ngôn ngữ BPEL 21

2.1.1 Nguyên tắc hoạt động của một tiến trình BPEL 22

2.1.2 Cấu trúc của một tiến trình BPEL 24

2.2 Các khái niệm cơ bản về BPEL 25

2.2.1 Các thành phần tác vụ trong BPEL 25

2.2.2 BPEL với chương trình dịch Java 37

2.3 Kiến trúc một số trình xử lý tiêu biểu trong BPEL 38

2.3.1 Khái niệm trình xử lý BPEL 38

2.3.2 Kiến trúc một số trình xử lý tiêu biểu 41

2.4 Đánh giá hiệu năng của các trình xử lý 54

2.5 Quy trình thiết kế tái sử dụng 55

Chương 3 XÂY DỰNG HỆ THỐNG THỬ NGHIỆM TÍCH HỢP DỊCH VỤ WEB TRÊN CƠ SỞ BPEL 58

3.1 Mô tả bài toán 58

3.2 Phân tích hệ thống 59

3.2.1 Mục đích của hệ thống 59

3.2.2 Phạm vi bài toàn 59

3.3 Thiết kế hệ thống 59

3.4 Triển khai hệ thống demo kết hợp dịch vụ Web 61

KẾT LUẬN 64

TÀI LIỆU THAM KHẢO 66

DANH MỤC HÌNH

Hình 1.1: Một SOAP Operation đơn giản 10

Hình 1.2: Cấu trúc thông điệp SOAP 10

Hình 1.3: Cấu trúc message SOAP 11

Hình 1.4: Lớp dịch vụ Web với UDDI 14

Hình 1.5: Luồng thông báo UDDI giữa Client và Registry 15

Hình 2.1: Ví dụ về một tiến trình BPEL 22

Hình 2.2: Ví dụ về kiểu liên kết ngoài - PartnerLink Type 23

Hình 2.3: Ví dụ về liên kết ngoài – PartnerLink 23

Hình 2.4: Cấu trúc file BPEL 24

Hình 2.5: Cấu trúc XML của receive 27

Hình 2.6: Ví dụ về trường hợp sử dụng invoke 28

Hình 2.7: Cấu trúc XML của invoke 28

Hình 2.8: Trường hợp sử dụng của Reply 29

Hình 2.9: Cấu trúc XML của Reply 29

Hình 2.10: Trường hợp sử dụng của Validate 30

Hình 2.11: Cấu trúc XML của Assign 31

Hình 2.12: Trường hợp sử dụng của Throw 31

Hình 2.13: Trường hợp sử dụng của ReThrow 32

Hình 2.14: Cấu trúc XML của Flow 33

Hình 2.15: Cấu trúc XML của Repeat Until 33

Hình 2.16: Trường hợp sử dụng của Pick 34

Hình 2.17: Cấu trúc XML của If 34

Hình 2.18: Cấu trúc XML của Flow 35

Hình 2.19: Trường hợp sử dụng của Foreach 35

Hình 2.20: Cấu trúc XML của Foreach 36

Hình 2.21: Cấu trúc XML của While 36

Hình 2.22: Trường hợp sử dụng của Scope 37

Hình 2.23: Mô hình kiến trúc BPEL 39

Hình 2.24: Mẫu tiến trình logic 40

Hình 2.25: Bảng Danh sách các trình xử lý BPEL hiện nay 41

Hình 2.26: Trình thiết kế của Apache ODE trên nền tảng Eclipse 42

Hình 2.27: Kiến trúc của Apache ODE 43

Hình 2.28: Bộ sản phẩm ActiveVOS 45

Hình 2.29: Trình thiết kế ActiveVOS 46

Hình 2.30: Kiến trúc tổng quan của ActiveVOS Server 47

Hình 2.31: Mối quan hệ của Oracle BPEL Process Manager với các thành phần khác 50

Hình 2.32: Kiến trúc của Oracle BPEL Process Manager 51

Hình 2.33: Trình thiết kế Jdeveloper cho Oracle BPELProcess Manager 53

Hình 2.34: Mô hình đo hiệu năng trình xử lý BPEL 55

Hình 2.35: Thiết lập khách hàng dịch vụ Web 56

Hình 3.1: Mô hình xây dựng quá trình BPEL 59

Hình 3.2: Sơ đồ luồng dữ liệu quy trình BPEL 60

Hình 3.3: Sơ đồ quá trình gán (Assign) theo định nghĩa BPEL 60

Hình 3.4: Cửa sổ Preferences 61

Hình 3.5: Cửa sổ New Server Runtime Environment 61

Hình 3.6: Địa chỉ dịch vụ cùng các cổng kết nối dịch vụ máy chủ Vietnamses 62

Hình 3.7: Địa chỉ dịch vụ cùng các cổng kết nối dịch vụ máy chủ English 62

Hình 3.8: Quy trình kết nối dịch vụ bằng kỹ thuật BPEL trên chương trình dịch Java (Eclipse) 63

MỞ ĐẦU

1 Đặt vấn đề

Trong vài năm qua, Công nghệ thông tin IT ( Information Technology) đã bắt

đầu phát triển các dịch vụ web (web service) Mặc dù các dịch vụ web là một cách

để chia sẻ các tài nguyên máy tính, chứ không phải là một công nghệ mới, nhưng nó

đã châm ngòi một cuộc cách mạng trong cách cung cấp dịch vụ của các tổ chức

Lúc đầu dịch vụ web trên máy tính cung cấp các tính năng ưu việt thông qua các trang web nhưng hiện nay nó đã mở rộng ra với các thiết bị công nghệ thông tin khác như điện thoại, máy kỹ thuật số Công nghệ thông tin hiện đại ngày càng phổ biến chức năng của công nghệ di động, việc ghép nối các dịch vụ ngày càng cần thiết Tuy nhiên, cuộc cách mạng này giống như mọi cuộc cách mạng khác, có các thành phần của quá khứ mà từ đó nó phát triển lên

Vì vậy, để đưa dịch vụ web phát triển mạnh mẽ hơn cần tích hợp chúng sao cho dễ dàng với người sử dụng Về nhiều mặt, sự thay đổi quan trọng này là vấn đề làm sao kết hợp chúng một cách toàn diện chứ không phải là sự ghép nối chắp vá đơn giản Trong thế giới mới việc một người sử dụng một phần mềm dịch vụ web với tất cả tiện ích cơ bản có sẵn là việc thiết yếu, giảm tải sự phức tạp khi sử dụng nhiều phần mềm dịch vụ khác nhau do nhiều hãng khác nhau thiết kế Sự thay đổi thực sự ấy trong cách chúng ta tính toán mang lại các cơ hội to lớn cho người sử dụng dịch vụ công nghệ thông tin để kiểm soát sự thay đổi và sử dụng chúng cho lợi ích cá nhân và tổ chức của họ

Xuất phát từ những vấn đề nêu trên, đề tài ―Kỹ thuật phát triển ứng dụng Web bằng ngôn ngữ WS-BPEL‖ nhằm mục tiêu tiếp cận, nghiên cứu các đặc điểm, ứng dụng, cơ sở hạ tầng, các mô hình triển khai dịch vụ dựa trên các dịch vụ có sẵn

để đề xuất lựa chọn mô hình dịch vụ kết hợp và thay thế chúng Trên cơ sở các mô hình dịch vụ web đã có tìm ra mô hình dịch vụ thay thế và sử dụng ngôn ngữ thực

thi tiến trình nghiệp vụ dịch vụ Web WS-BPEL (Web Service Business Process Execution Language) để thể hiện chúng

2 Đối tượng và phạm vi nghiên cứu

Kiến trúc tổng thể và các thành phần cơ bản như XML, kiến trúc dịch vụ Web như SOAP, WSDL và UDDI, ngôn ngữ BPEL

Lựa chọn một dịch vụ web để xây dựng demo trên cơ sở kiến trúc đã nghiên cứu trên đây

3 Hướng nghiên cứu của đề tài

- Hướng của đề tài đặt ra phương án kết hợp một số dịch vụ web thông thường lại với nhau trong cùng một chương trình xử lý

- Thực hiện bản thử nghiệm với các tính năng đơn giản, gọn nhẹ vào các thiết bị công nghệ thông tin phổ thông

- Nghiên cứu thuật toán kết 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ột cách đơn giản và nhanh chóng mà không cần thay đổi các dịch vụ đó

- Xây dựng hệ thống quy trình thiết kế tái sử dụng các ứng dụng sẵn có được viết trên các ngôn ngữ khác nhau, kết hợp chúng thành ứng dụng nghiệp vụ thống nhất có tính khả thi

- 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ác dịch vụ ngoài và sử dụng các tác vụ, các phép toán logic để tạo thành quy trình

- Thiết lập demo module sử dụng kỹ thuật xây dựng ứng dụng web dựa trên ngôn ngữ WS- BPEL

Chương 1 TỔNG QUAN VỀ DỊCH VỤ WEB 1.1 Ngôn ngữ XML

XML (eXtensible Markup Language) là ngôn ngữ đánh dấu với mục đích

chung do W3C (World Wide Web Consortium là một hiệp hội lập ra các chuẩn cho

Internet) đề nghị, để tạo ra các ngôn ngữ đánh dấu khác Đây là một tập đoàn con

đơn giản của SGML (Standard Generalized Markup Language, một hệ thống tổ chức và gắn thẻ yếu tố của một tài liệu), có khả năng mô tả nhiều loại dữ liệu khác nhau Mục đích chính của XML là đơn giản hóa việc chia sẻ dữ liệu giữa các hệ thống khác nhau, đặc biệt là các hệ thống được kết nối với Internet

Các ngôn ngữ dựa trên XML như RDF, RSS, MathML, XHTML, SVG, GML

và cXML được định nghĩa theo cách thông thường, cho phép các chương trình sửa đổi và kiểm tra hợp lệ bằng các ngôn ngữ này mà không cần có hiểu biết trước về hình thức của chúng

XML cung cấp một phương tiện dùng văn bản để mô tả thông tin và áp dụng một cấu trúc kiểu cây cho thông tin đó Tại mức căn bản, mọi thông tin đều thể hiện

dưới dạng text, chen giữa là các thẻ đánh dấu (markup) với nhiệm vụ ký hiệu sự

phân chia thông tin thành một cấu trúc có thứ bậc của các dữ liệu ký tự, các phần

tử dùng để chứa dữ liệu, và các thuộc tính của các phần tử đó Về mặt đó, XML tương tự với các biểu thức S (S-expression) của ngôn ngữ lập trình LISP ở chỗ chúng đều mô tả các cấu trúc cây mà trong đó mỗi nút có thể có một danh sách tính chất của riêng mình

Đơn vị cơ sở của XML là các ký tự theo định nghĩa của Universal Character Set (Bộ ký tự toàn cầu) Các ký tự được kết hợp theo các tổ hợp chuỗi hợp lệ để tạo thành một tài liệu XML Tài liệu này gồm một hoặc nhiều thực thể, mỗi thực thể thường là một phần nào đó của các ký tự thuộc tài liệu, được mã hóa dưới dạng một chuỗi các bit và lưu trữ trong một tệp văn bản (text file)

Sự phổ biến của các phần mềm soạn thảo văn bản (word processor) đã hỗ trợ việc soạn thảo và bảo trì tài liệu XML một cách nhanh chóng Trước XML, có rất ít ngôn ngữ mô tả dữ liệu với các đặc điểm đa năng, thân thiện với giao thức Internet,

dễ học và dễ tạo Thực tế, đa số các định dạng trao đổi dữ liệu thời đó đều chuyện dụng, có tính độc quyền, và có định dạng nhị phân (chuỗi bit thay vì chuỗi ký tự) khó dùng chung giữa các ứng dụng phần mềm khác nhau hay giữa các hệ nền (platform) khác nhau Việc tạo và bảo trì trên các trình soạn thảo thông dụng lại càng khó khăn

Bằng cách cho phép các tên dữ liệu, cấu trúc thứ bậc được phép, và ý nghĩa của các phần tử và thuộc tính có tính chất mở và có thể được định nghĩa bởi một giản đồ tùy biến được, XML cung cấp một cơ sở cú pháp cho việc tạo lập các ngôn ngữ đánh dấu dựa XML theo yêu cầu Cú pháp chung của các ngôn ngữ đó là

cố định, các tài liệu phải tuân theo các quy tắc chung của XML, bảo đảm rằng tất cả các phần mềm hiểu XML ít ra cũng phải có khả năng đọc (phân tích cú pháp - parse) và hiểu bố cục tương đối của thông tin trong các tài liệu đó Giản đồ chỉ bổ sung một tập các ràng buộc cho các quy tắc cú pháp Các giản đồ thường hạn chế tên của phần tử và thuộc tính và các cấu trúc thứ bậc được phép, ví dụ, chỉ cho phép một phần tử tên 'ngày sinh' chứa một phần tử tên 'ngày' và một phần tử có tên 'tháng', mỗi phần tử phải chứa đúng một ký tự Đây là điểm khác biệt giữa XML

và HTML HTML có một bộ các phần tử và thuộc tính không mềm dẻo, chỉ có một tác dụng và nói chung là không thể dùng cho mục đích khác [5]

XML không hạn chế về việc nó được sử dụng như thế nào Mặc dù XML

về cơ bản là dạng text, các phần mềm với chức năng trừu tượng hóa nó thành các định dạng khác giàu thông tin hơn đã nhanh chóng xuất hiện, quá trình trừu tượng hóa này được thực hiện chủ yếu qua việc sử dụng các giản đồ định hướng kiểu dữ liệu (datatype-oriented schema) và khuôn mẫu lập trình hướng đối tượng (mà trong đó, mỗi tài liệu XML được thao tác như là một đối tượng) Những phần mềm như vậy có thể coi XML như là dạng text đã được tuần tự hóa chỉ khi nó cần truyền dữ liệu qua mạng

Ngoài những đặc điểm trên, công nghệ này còn cần phải được xem xét kỹ bởi lẽ trong quá trình thao tác và truyền dữ liệu, nó đã được thống kê và ghi nhận tỷ

lệ sai sót, mất dữ liệu dao động từ 5 - 7% Tuy con số này không cao, nhưng cũng đáng để những người sử dụng phải có những cân nhắc kỹ càng hơn

<title>Bánh mì cơ bản</title>

<nguyên_liệu lượng="3" đơn_vị="ca">Bột mì</nguyên_liệu>

<nguyên_liệu lượng="7" đơn_vị="gram">Men</nguyên_liệu>

<nguyên_liệu lượng="1.5" đơn_vị="ca" trạng_thái="ấm"> Nước

</nguyên_liệu>

<nguyên_liệu lượng="1" đơn_vị="thìa cà phê">Muối</nguyên_liệu>

<chỉ_dẫn>

<bước>Trộn tất cả các nguyên liệu với nhau và nhào kĩ</bước>

<bước>Phủ một mảnh vải, ủ một tiếng đồng hồ trong phòng ấm.</bước> <bước>Nhào lại, đổ vào khuôn, cho vào lò nướng.</bước>

</chỉ_dẫn>

</công_thức_nấu_ăn>

Dòng đầu tiên là Khai báo XML (XML declaration): đó là một dòng không bắt

buộc, với nhiệm vụ thông báo phiên bản XML đang được sử dụng (thường là phiên bản 1.0), và còn có thể chứa thông tin về mã hóa ký tự và các phụ thuộc bên ngoài

Phần còn lại của tài liệu này chứa các phần tử lồng nhau, một số phần tử trong đó có các thuộc tính và nội dung Một phần tử thường bao gồm hai thẻ (tag), một thẻ bắt đầu và một thẻ kết thúc, có thể bao quanh văn bản và các phần tử khác Thẻ bắt đầu bao gồm một cái tên đặt trong một cặp ngoặc nhọn, như

"<bước>"; thẻ kết thúc bao gồm chính cái tên đó đặt trong một cặp ngoặc nhọn, với một dấu gạch chéo đứng trước, như "</bước>" Nội dung của phần tử là tất cả

những gì nằm giữa thẻ bắt đầu và thẻ kết thúc, bao gồm văn bản và các phần tử (con) khác Dưới đây là một phần tử XML hoàn chỉnh, với thẻ bắt đầu, nội dung văn bản, và thẻ kết thúc:

<bước>Nhào lại, đổ vào khuôn, cho vào lò nướng.</bước>

Bên cạnh nội dung, một phần tử có thể chứa các thuộc tính - các cặp tên - giá trị được đặt trong thẻ bắt đầu, ngay sau tên phần tử Giá trị của thuộc tính phải được đặt trong cặp nháy đơn hoặc nháy kép, mỗi tên thuộc tính chỉ được xuất hiện một lần trong mỗi phần tử

<nguyên_liệu lượng="3" đơn_vị="ca">Bột mì</nguyên_liệu>

Trong ví dụ này, phần tử nguyên_liệu có hai thuộc tính: lượng với giá trị "3",

và đơn vị với giá trị "ca" Trong cả hai trường hợp, cũng như tên và nội dung của các phần tử, tại cấp độ đánh dấu, tên và giá trị của các thuộc tính cũng chỉ là dữ liệu text — các giá trị "3" và "ca" không phải một số lượng và một đơn vị đo lường mà chỉ là các chuỗi ký tự mà tác giả tài liệu có thể dùng đểbiểu diễn những thứ đó

Ngoài văn bản, các phần tử còn có thể chứa các phần tử khác:

<chỉ_dẫn>

<bước>Trộn tất cả các nguyên liệu với nhau và nhào kĩ</bước>

<bước>Phủ một mảnh vải, ủ một tiếng đồng hồ trong phòng ấm.</bước> <bước>Nhào lại, đổ vào khuôn, cho vào lò nướng.</bước>

Mỗi tài liệu XML phải có đúng một phần tử gốc tại bậc trên cùng (còn gọi

là phần tử văn bản), do đó đoạn sau cũng sẽ là một tài liệu XML định dạng sai:

nhỏ nội bộ Các thực thể được khai báo có thể mô tả các ký tự đơn hay các đoạn văn bản, và có thể tham chiếu lẫn nhau

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE example [ <!ENTITY copy "©">

<!ENTITY copyright-notice "Copyright © 2006, XYZ

Khi xem tại một trình duyệt thích hợp, tài liệu XML trên sẽ hiện ra như sau:

<root> Copyright © 2006, XYZ Enterprises </root>

Các tham chiếu ký tự số trông giống như các thực thể Nhưng thay cho một cái tên, chúng gồm một ký tự "#" và theo sau là một con số Con số (theo hệ thập phân hoặc hệ cơ số 16 với tiền tố "x") đại diện cho một mã hiệu

Unicode (Unicode code point), và thường được dùng để đại diện cho các ký tự

không dễ gõ trên máy tính, chẳng hạn một chữ cái Ả-rập trong một tài liệu được soạn trên một máy tính châu Âu Dấu & trong ví dụ "AT&T" có thể được biểu diễn như sau (số 38 thập phân và 26 trong hệ cơ số 16 đều đại diện cho giá trị Unicode của dấu &):

<tên-công-ty>AT&#38;T</tên-công-ty>

<tên-công-ty>AT&#x26;T</tên-công-ty>

Còn có nhiều quy tắc khác cần thiết cho việc viết các tài liệu XML định dạng đúng, chẳng hạn một tên XML có thể chứa các ký tự nào, nhưng phần giới thiệu ngắn này chỉ cung cấp các kiến thức căn bản để đọc và hiểu được nhiều tài liệu XML

1.2 Giao thức truy cập dịch vụ Web - SOAP

1.2.1 Kiến trúc dịch vụ SOAP (Simple Object Access Protocol – Giao thức truy

cập đối tượng đơn giản)

SOAP là một giao thức giao tiếp có cấu trúc như XML và mã hóa thành định dạng chung cho các ứng dụng trao đổi với nhau Ý tưởng bắt đầu từ Microsoft và phần mềm Userland, trải qua nhiều lần thay đổi, hiện tại là phiên bản SOAP 1.2 SOAP được xem như là cấu trúc xương sống của các ứng dụng phân tán xây dựng

từ nhiều ngôn ngữ, hệ điều hành khác nhau

SOAP là một đặc tả việc sử dụng các tài liệu XML theo dạng các thông điệp Bản thân SOAP không định ra các ngữ nghĩa ứng dụng hoặc cách cài đặt chi tiết SOAP cung cấp một cơ chế đơn giản và gọn nhẹ cho việc trao đổi thông tin có cấu trúc và định dạng giữa các thành phần trong một môi trường phân tán sử dụng XML SOAP được thiết kế dựa trên những chuẩn nhằm giảm chi phí tích hợp các hệ thống phân tán xây dựng trên nhiều nền tảng khác nhau ở mức càng thấp càng tốt Đặc tả về SOAP định nghĩa một mô hình trao đổi dữ liệu dựa trên 3 khái niệm cơ bản: Các thông điệp là các tài liệu XML, chúng được truyền đi từ bên gửi đến bên nhận, bên nhận có thể chuyển tiếp dữ liệu đến nơi khác

Khái niệm cơ bản nhất của mô hình SOAP là việc sử dụng các tài liệu XML như những thông điệp trao đổi Điều này có nhiều ưu điểm hơn các giao thức truyền

dữ liệu khác Các thông điệp XML có thể được tổng hợp và đọc với một bộ soạn thảo text đơn giản, ta có thể làm việc với XML trên hầu hết mọi nền tảng [1]

1.2.2 Đặc trưng của SOAP

- SOAP được thiết kế đơn giản và dễ mở rộng

- Tất cả các message SOAP đều được mã hóa sử dụng XML

- SOAP sử dùng giao thức truyền dữ liệu riêng

- Không có garbage collection phân tán, và cũng không có cơ chế tham chiếu Vì thế SOAP client không giữ bất kỳ một tham chiếu đầy đủ nào về các đối tượng ở xa

- SOAP không bị ràng buộc bởi bất kỳ ngôn ngữ lập trình nào hoặc công nghệ nào

Vì những đặc trưng này, nó không quan tâm đến công nghệ gì được sử dụng

để thực hiện miễn là người dùng sử dụng các message theo định dạng XML Tương

tự, service có thể được thực hiện trong bất kỳ ngôn ngữ nào, miễn là nó có thể xử lý được những message theo định dạng XML

Khi trao đổi các thông điệp SOAP, có hai thành phần liên quan: Bên gửi và bên nhận Thông điệp sẽ được chuyển từ bên gửi sang bên nhận Đây là ý niệm đơn giản nhất trong trao đổi thông điệp SOAP Trong nhiều trường hợp, kiểu trao đổi này không cung cấp đủ chức năng Nhưng đây là mô hình cơ bản, dựa trên đó sẽ phát triển các mô hình trao đổi phức tạp hơn

Hình 1.1: Một SOAP Operation đơn giản

Một cấu trúc SOAP được định nghĩa gồm các phần: <Envelope>, <Header>

và <Body>

Hình 1.2: Cấu trúc thông điệp SOAP

Envelop là thành phần gốc của một thông điệp SOAP, nó chứa các thành phần Header và Body Thành phần Header là một cơ chế mở cho phép thêm các tính năng vào bên trong một thông điệp SOAP Mỗi thành phần con của Header gọi là một Header Entry Các Header Entry dùng để diễn giải, quy định một số ngữ nghĩa của thông điệp SOAP Các ứng dụng có thể xử lý và định tuyến các thông điệp dựa trên thông tin header và thông tin bên trong thông điệp đó Đây là ưu điểm mà các

mô hình kiến trúc như DCOM, CORBA và RMI không có được, vì các protocol header của chúng phải được chỉ định chi tiết cho mỗi ứng dụng

1.2.3 Cấu trúc một message theo dạng SOAP

Message theo dạng SOAP là một văn bản XML bình thường bao gồm các phần tử sau:

- Phần tử gốc - envelop: Phần tử bao trùm nội dung message, khai báo văn bản XML như là một thông điệp SOAP

- Phần tử đầu trang - header: Chứa các thông tin tiêu đề cho trang, phần tử này không bắt buộc khai báo trong văn bản Những đầu mục còn có thể mang những dữ liệu chứng thực, những chữ ký số hóa, và thông tin mã hóa, hoặc những cài đặt cho giao tác

- Phần tử khai báo nội dung chính trong thông điệp - body, chứa các thông tin yêu cầu và phản hồi

- Phần tử phát sinh lỗi (Fault) cung cấp thông tin lỗi xảy ra trong quá trình xử

lý thông điệp

Cấu trúc một message theo dạng SOAP được mô tả như hình dưới đây:

Hình 1.3: Cấu trúc message SOAP

Trong trường hợp đơn giản nhất, phần thân của SOAP message gồm có:

- Tên của message

- Một tham khảo tới một thể hiện service

- Một hoặc nhiều tham số mang các giá trị và mang các tham chiếu Có 3 kiểu thông báo:

+ Request messages: Với các tham số gọi thực thi một service

+ Response messages: Với các tham số trả về, được sử dụng khi đáp ứng yêu cầu

+ Fault messages báo tình trạng lỗi

1.2.4 Những kiểu truyền thông SOAP

- Remote procedure call (RPC): Cho phép gọi hàm hoặc thủ tục qua mạng Kiểu này được khai thác bởi nhiều web service và có nhiều trợ giúp

- Document (Được biết như kiểu hướng message): Kiểu này cung cấp một lớp thấp của sự trừu tượng hóa và yêu cầu lập trình nhiều hơn khi làm việc

Các định dạng message, tham số và lời gọi đến các API thì tương ứng trong RPC và document là khác nhau Nên việc quyết định chọn cái nào tùy thuộc vào thời gian xây dựng và sự phù hợp của service cần xây dựng

Những kiểu phức tạp, có hai loại là struct và array

Tất cả các phần tử và những định danh có trong mô hình dữ liệu SOAP thì được định nghĩa bằng namespace SOAP-ENC

1.3 Ngôn ngữ mô tả dịch vụ Web - WSDL

WSDL định nghĩa cách mô tả web service theo cú pháp tổng quát XML, bao gồm các thông tin [7]:

:

ối

ể truy xuất service

Cả 2 phần trên sẽ được lưu trong 2 tập tin XML, bao gồm:

Một tài liệu WSDL gồm bảy yếu tố:

- Các loại định nghĩa các loại dữ liệu được sử dụng trong dịch vụ này

- Tin nhắn định nghĩa của các thông báo liên quan đến sự tương tác với dịch

vụ này

- Hoạt động hoạt động trừu tượng

- Nhóm kiểu trừu tượng của các hoạt động dịch vụ hỗ trợ

- Ràng buộc cụ thể giao thức và định dạng dữ liệu cho một loại cổng của dịch vụ này

- Các ràng buộc và địa chỉ mạng

Phục vụ một bộ sưu tập của các cảng

Loại, tin nhắn, hoạt động và Port Loại thuộc phần trừu tượng mô tả dịch vụ Phần trừu tượng rõ ràng là tách ra từ cụ thể một phần, tức là Binding, cổng và dịch

vụ, cho phép tái sử dụng của các trừu tượng mô tả

Một tài liệu WSDL có cấu trúc sau:

1.4 Mô tả và tìm kiếm dịch vụ Web – UDDI

1.4.1 Lớp dịch vụ Web với UDDI

UDDI dựa vào những chuẩn đã có như là ngôn ngữ đánh dấu mở rộng (XML)

và giao thức truy cập đối tượng đơn giản (SOAP) Tất cả các cài đặt của UDDI đều hỗ trợ các đặc tả UDDI Mục đích là để tạo và thực thi ba phiên bản liên tiếp của đặc tả kỹ thuật trước khi chuyển giao quyền sở hữu cho một cá nhân độc lập

Hình 1.4: Lớp dịch vụ Web với UDDI

Phiên bản 1 của đặc tả UDDI được công bố trong tháng 9 năm 2000, xây dựng nền tảng cho việc đăng ký Phiên bản 2 được công bố váo tháng 6 năm 2001, thêm các đặc tính như quan hệ kinh doanh Phiên bản 3 tiếp tục giải quyết các lĩnh vực quan trọng cho việc phát triển dịch vụ web, như là bảo mật, tăng cường quốc tế hóa, khả năng tương tác nội bộ, và hàng loạt các cải tiến hàm API để cải tiến công cụ tốt hơn

UDDI xây dựng trên tầng vận chuyển của mô hình mạng và tầng thông điệp XML dựa trên SOAP Các ngôn ngữ mô tả dịch vụ, như là ngôn ngữ miêu tả dịch

vụ Web (Web Services Description Language - WSDL), cung cấp thuật ngữ XML

đồng nhất (tương tự như ngôn ngữ tương tác dữ liệu - IDL) để dùng trong việc mô

tả các dịch vụ web và giao diện của chúng

Bản ghi của UDDI chứa các mô tả của các doanh nghiệp có thể truy cập bằng các chương trình máy tính và các dịch vụ mà chúng hỗ trợ Nó cũng chứa các tham chiếu tới các đặc tả cụ thể mà một dịch vụ web có thể hỗ trợ, các định nghĩa phân loại (được sử dụng cho việc xếp loại kinh doanh và dịch vụ), và các hệ thống định danh (sử dụng để xác định các doanh nghiệp) UDDI cung cấp một lược đồ và mô hình lập trình với định nghĩa luật giao tiếp với bản ghi Tất cả các hàm API trong đặc tả UDDI được định nghĩa trong XML, gói gọn trong một phong bì SOAP, và gửi qua HTTP

Hình 1.5: Luồng thông báo UDDI giữa Client và Registry

Đặc tả UDDI được cấu thành từ vài tài liệu khác nhau Đặc tả API mô tả các hàm API SOAP cho phép thực hiện các hoạt động tìm kiếm và quảng bá Cách xử

lý lỗi, ngữ nghĩa của yêu cầu, kết quả cũng được mô tả Các thông tin thực tế về các quy ước và cách sử dụng cũng có sẵn Các tài liệu bao gồm đặc tả cấu trúc dữ liệu

và lược đồ API định nghĩa thông điệp và ngữ nghĩa của dữ liệu

Các hàm API của UDDI được chia thành hai nhóm, truy vấn và phát hành

Inquiry Operations: Publishing Operations:

Các API truy vấn chia thành ba mẫu truy vấn:

Các mẫu tìm kiếm mẫu thừa kế công dụng của toán từ tìm kiếm, cái mà cho phép duyệt các mục dữ liệu sử dụng các điều kiện khác nhau, như là hạng mục phân loại, các định danh, hoặc thông tin tên từng phần sử dụng hàm API_xxxfind_xxx

Các mẫu tìm kiếm sâu liên quan đến việc thu nhập thông tin chi tiết về một mục dữ liệu mà đã tìm thấy Hàm APIget_xxx hỗ trợ khả năng này

Các mẫu tìm kiếm viện dẫn thông tin là mẫu tìm kiếm cuối cùng Việc gọi các dịch vụ ra yêu cầu sử dụng thông tin mẫu kèm theo, thông thường được lưu trữ tạm thời bởi các máy trạm để sử dụng lặp đi lặp lại mà không cần gửi lại bản ghi cho cùng một thông tin mà máy trạm cần Nếu thông tin đính kèm thay đổi, máy trạm cần phải gửi lại bản ghi để cập nhật lại thông tin Đây chính là mẫu tìm kiếm viện dẫn thông tin

Lưu và xóa (với hàm API save_xxx và delete_xxx) có thể được thực hiện trên mỗi đầu mục ở cấp cao nhất, tên các hàm tự giải thích chức năng của nó, nhưng lưu ý rằng cách thức lưu trữ của toán tử save trong UDDI thông thường mang tính phá hủy Ví dụ, việc tái lưu trữ (resave) cùng một dịch vụ với thông tin khác sẽ là sự thay thế hoàn toàn thông tin cũ bằng thông tin mới (hay còn gọi là ghi đè)

Toán tử gắn với authTokens yêu cầu phải đăng ký trước với một nốt UDDI Business Registry cụ thể và cung cấp thông tin xác thực cần thiết để thành lập một

sự thống nhất của nhà phát hành thông tin Những thông tin xác thực này được sử dụng để lấy mộtauthToken để thực hiện một toán tử xuất thông tin (với hàm APIsave_xxx) authToken có thể được tái sử dụng với thời gian ngắn trong khi các toán tử xuất thông tin chưa bị hết hạn Chính sách toán tử quyết định cả nội dung và thời gian tồn tại của một authToken

1.4.2 Cấu trúc dữ liệu UDDI

Thông tin được chứa trong một đăng ký UDDI bao gồm năm kiểu khác nhau:

businessEntity hoặc tổ chức công ty thực tế Điều này có thể có nghĩa là toàn

bộ tổ chức hoặc nó có thể là một tổ chức liên kết hoặc chi nhánh

publisherAssertion hoặc mối quan hệ giữa businessEntities Để hợp lệ publisherAssertions phải được cả hai bên yêu cầu, trừ khi cả hai thực thể có trách nhiệm với chủ báo hoặc trừ khi cả hai thực thể được nhập vào trong đăng ký bằng một tài khoản người dùng giống nhau

bindingTemplate, về cơ bản là đặc tả của một giao diện của một dịch vụ Nhiều businessServices có thể thực hiện businessServices

businessService hay một dịch vụ do một doanh nghiệp cung cấp Bây giờ, điều đó có vẻ đơn giản, nhưng trong thế giới của UDDI, điều đó không nhất thiết có nghĩa là nó là một dịch vụ Web Ví dụ, thực sự có thể xác định dịch

vụ hỗ trợ điện thoại của doanh nghiệp của (có nghĩa là số điện thoại thực tế

mà người dùng quay số và tất cả mọi thứ mà đi kèm với nó) như một dịch vụ UDDI Tất nhiên, sẽ không có một tài liệu WSDL giả, nhưng nó sẽ là một dịch vụ được doanh nghiệp của cung cấp

tModels hoặc các mô hình siêu dữ liệu Khi nghiên cứu UDDI, Francis đi đến kết luận rằng tModel có lẽ là lý do lớn nhất tại sao UDDI đã không cất cánh như mong đợi Như một đăng ký của các dịch vụ, sẽ mong đợi tìm thấy một cách để trực tiếp xác định giao diện cho một dịch vụ, như WSDL thực hiện Nhưng, như đã nói, UDDI đã chưa bao giờ được dự định là độc quyền

về các dịch vụ Web và được thiết kế với linh hoạt hơn nữa tModels thực hiện trợ giúp trỏ đến các tài liệu XML, như chúng ta sẽ thấy sau này, nhưng trong thực tế chúng có nghĩa là một cách tổng quát để xác định thông tin về thứ gì đó, thông qua dịch vụ, một doanh nghiệp hay bất cứ điều gì khác

UDDI nổi danh là quá phức tạp, nhưng với cốt lõi của mình UDDI thuộc về năm kiểu dữ liệu được mô tả ở trên, được kết hợp với bốn hoạt động: tìm kiếm, nhận, lưu và xóa Nói cách khác, đặc tả UDDI lưu ý những điều sau đây để

có thể thực hiện với dữ liệu:

find_xx: Những phương thức này, chẳng hạn như find_businessEntity, find_businessService và v.v, cung cấp một cách để tìm kiếm một bản ghi trong đăng ký UDDI Những phương thức này trả về khóa để nhận dạng đối tượng

get_xx: Một khi có khóa duy nhất nhận dạng một đối tượng, có thể sử dụng get_xx methods, nhưget_businessService và v.v, để lấy ra chính đối tượng thực tế đó Ví dụ, get_businessService trả về toàn bộ đối tượng businessService, từ đó thu được bất kỳ thông tin nào mà cần

save_xx: Như có thể đã đoán được, các phương thức này thêm thông tin vào

cơ sở dữ liệu hoặc chúng thay đổi thông tin đã có trong cơ sở dữ liệu

delete_xx: Những phương thức này, chẳng hạn delete_binding Template, delete_tModel, và v.v, lấy khóa duy nhất của đối tượng làm tham số và loại

bỏ nó khỏi cơ sở dữ liệu Hành vi thực tế của các phương thức này phụ thuộc vào những gì đang xóa Ví dụ, vì tModels thường xuyên được các đối tượng khác trong cơ sở dữ liệu tham chiếu, nên chúng có thể không thực sự bị xóa

Hầu như tất cả mọi thứ của UDDI dựa trên 20 phân cắt giữa năm đối tượng (businessService, bindingTemplate, publisherAssertion, businessEntity và tModel) và bốn hành động (find, get, save và delete)

1.5 Các dịch vụ web hiện nay đã phát triển

Hiện nay trên phương diện về dịch vụ web đang phát triển càng ngày càng đa dạng với nhiều lĩnh vực khác nhau Vào những năm 2000 khi công nghệ thông tin Việt Nam còn đang chập chững trước ngưỡng cửa thông tin toàn cầu thì việc triển khai dịch vụ web vẫn còn rất nghèo nàn về công nghệ dịch vụ web lẫn kỹ thuật

Việc triển khai công nghệ thông tin sau nhiều năm đã giúp Việt Nam có được những thành tựu to lớn với các công nghệ tiên tiến và bám sát với cộng đồng công nghệ mạng thế giới Cụ thể thông qua các nhà cung cấp dịch vụ mạng Việt Nam ngày càng nhiều và ngày càng chất lượng

Ứng dụng web trở nên phổ biến nên dịch vụ mạng trở thành một tiềm năng khai thác cho rất nhiều doanh nghiệp Từ việc quản lý nhân viên, quản lý hồ sơ, quản lý điểm học tập cho đến giáo dục đào tạo từ xa Tất cả đều có thể thông qua ứng dụng dịch vụ mạng để thực hiện công việc trực tuyến

Một số ứng dụng mạng hiện nay đang phát triển có thể kể đến như:

- Mạng thanh toán PayNet

- Mạng xã hội Facebook

- Mạng chia sẻ ngang hàng Torrent

…

1.6 Tình hình nghiên cứu hiện nay trong và ngoài nước

Với sự phát triển và ứng dụng mạnh mẽ của công nghệ SOA vào các quy trình nghiệp vụ và đang mang lại một lợi ích lớn cho các tổ chức và doanh nghiệp

Đi đôi với kiến trúc SOA là sự phát triển của các ngôn ngữ mô hình hóa các quy trình nghiệp vụ như: XPDL, BPML,BPEL… Nó giúp cho các lập trình viên và các nhà sử dụng dịch vụ đơn giãn hóa việc tổng hợp cũng như xây dựng các dịch vụ riêng cho mình Chúng không phải là một ngôn ngữ được sử dụng cho việc phân tích thiết kế và được thể hiện bằng một bộ cú pháp xml và có các giao thức riêng

của mình, chúng không có một ngôn ngữ riêng cụ thể nào cả mà chỉ được thể hiện qua các giao diện đồ họa, cũng không có một chuẩn ký hiệu chung cho các ngôn ngữ này Trong các ngôn ngữ trên thì BPEL là ngôn ngữ được sử dụng rộng rãi nhất Từ năm 2003 tổ chức OASIS đã mua bản quyền và chịu trách nhiệm cho sự phát triển của ngôn ngữ BPEL Để hổ trợ cho việc thể hiện các ngôn ngữ này thì các công cụ desingner được phát triển ra như là một tất yếu Có rất nhiều Design Engine được phát triển bởi nhiều tổ chức khác nhau như Oracle SOA Suite, PPEL Eclipse Plugin… hỗ trợ mạnh mẽ cho việc tổng hợp và xây dựng các dịch vụ

Tuy nhiên với sự phát triển mạnh mẽ của của internet và các công nghệ web

đã là cho nhu cầu sử dụng và chia sẽ các ứng dụng thông qua môi trường web như

là một nhu cầu tất yếu Vì vậy nhu cầu xây dụng các công cụ hổ trợ cho việc tổng hợp và thiết kế các dịch vụ trên môi trường web là một nhu cầu có thật và hiển nhiên Vấn đề đặt ra là làm sao các nhà sử dụng cũng như cung cấp dịch vụ có thể tạo ra một quy trình dịch vụ cũng như tiếp cận các dự án của mình một cách nhanh nhất vào mọi thời điểm và mọi nơi có kết nối internet mà không cần phải cài đặt sẵn các chương trình desingner

Chương 2 NGÔN NGỮ BPEL 2.1 Giới thiệu ngôn ngữ BPEL

BPEL (Business Process Execution Language) là 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 dịch vụ Web khác nhau Phiên bản BPEL đầu tiên (BPEL 1.0) ra đời vào tháng 07/2002 Vào tháng 05/2003 BPEL1.1 ra đời dựa trên việc kết hợp BPEL 1.0 với một số ngôn ngữ khác

và được đệ trình lên tổ chức OASIS (một tổ chức chuyên đưa ra các chuẩn thông tin) Tháng 04/2007 tổ chức OASIS chuẩn hóa BPEL và đổi tên thành WS-BPEL

2.0 được dùng cho đến nay [4]

BPEL cho phép đặc tả và xử lý luồng công việc bằng cách cung cấp sẵn các thẻ

mô tả các đối tượng và các hoạt động xử lý của một quy trình nghiệp vụ thông thường

BPEL đại diện cho một quy tụ của hai ngôn ngữ workflow (quy trình làm việc), WSFL (Web Services Flow Language) và XLANG WSFL này được thiết kế

bởi IBM dựa trên khái niệm về hướng dẫn đồ thị XLANG được thiết kế bởi Microsoft là một khối cơ cấu ngôn ngữ BPEL kết hợp cả hai phương pháp tiếp cận

và cung cấp một vốn từ vựng phong phú cho các mô tả về quy trình kinh doanh

Ngoài ra BPEL còn đị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 dịch vụ bên ngoài

Nó phụ thuộc vào bốn chuẩn XML cơ bản được xem như là các đặc tả để thực thi một tiến trình BPEL: WSDL, XML Schema 2.0, XPath 2.0 và WS-Addressing Hình 6 dưới thể hiện mô hình một tiến trình BPEL trong thực tế Một tiến trình BPEL bao gồm 2 tác vụ cơ bản nhất là receivevà reply trong đó tác vụ receive dùng để nhận yêu cầu đầu vào, còn reply trả lại kết quả cho người dùng Giữa 2 tác

vụ này còn có nhiều tác vụ khác làm nhiệm vụ gọi các dịch vụ Web từ bên ngoài (callbackClient), thực thi, xử lý các dữ liệu trung gian (Assign) trước khi trả về kết quả cuối cùng cho người dùng

Hình 2.1: Ví dụ về một tiến trình BPEL

2.1.1 Nguyên tắc hoạ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 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 dịch vụ Web được mô tả trong WSDL Một tiến trình BPEL 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 phải có đặc tả của riêng nó đồng thời sử dụng các đặc tả WSDL được cung cấp bởi các dịch vụ khác trong quá trình tổng hợp các dịch vụ này

Tuy nhiên có một vấn đề đặt ra là: làm thế nào để tiến trình BPEL có thể phân biệt được từng dịch vụ mà nó tổng hợp trên đó để mà tương tác trên những dịch vụ

đó, cũng như mỗi dịch vụ được sử dụng trong tiến trình BPEL có vai trò như thế nào trong toàn bộ tiến trình… Để giải quyết vấn đề này, BPEL đã đưa ra hai khái niệm mới là kiểu liên kết ngoài – partnerLinkType và liên kết ngoài-partnerLink

Kiểu liên kết ngoài - PartnerLinkType

Các dịch vụ trong tương tác của tiến trình nghiệp vụ được mô tả là các PartnerLinkType trong BPEL Mỗi một PartnerLink được mô tả bằng một PartnerLinkType, được đặt tên để đại diện cho tất cả các tương tác thông qua PartnerLink đó Nếu PartnerLinkType tương ứng chỉ có một role thì role này sẽ mặc

định được gán cho thuộc tính myRolecủa PartnerLink, nhưng nếu có nhiều role thì phải chỉ ra để cho biết PartnerLink này hoạt động với PortType nào Hình 2.2 dưới đây ví dụ về một kiểu liên kết ngoài có tên là ―BuyerSelllerLink‖ với 2 role là

―Buyer‖ và ―Seller‖ Trong trường hợp thông thường, portTypes của hai roles (MyRolevà PartnerRole) xác định từ các namespaces riêng biệt Tuy nhiên trong một số trường hợp thì chúng được xác định chung một namespace, điều này thường xảy ra ở các dịch vụ thuộc có mối quan hệ ―callback‖(gọi lại chính nó)

Hình 2.2: Ví dụ về kiểu liên kết ngoài - PartnerLink Type

Liên kết ngoài - PartnerLink

PartnerLinkType được mô tả trong tập tin WSDL như là một khái niệm mở rộng cho chuẩn WSDL Còn các partnerLink nào được dùng trong tiến trình BPEL thì được chỉ ra trong tập tin BPEL Kỹ thuật dùng partnerLink chẳng những giải quyết được vấn đề trên mà còn giúp tiến trình BPEL có thể dễ dàng tích hợp với các

bộ phận khác trong kiến trúc tổng thể của SOA Cụ thể, khi ta định nghĩa một partnerLink, chúng ta sử dụng thuộc tính myRole để chỉ vai trò của chính dịch vụ Web của BPEL Ngược lại, thuộc tính partnerRole được dùng để chỉ vai trò của một dịch vụ bên ngoài

Hình 2.3 ví dụ về PartnerLink có tên là ―ncname‖ với partnerLinkType là

―qname‖:

Hình 2.3: Ví dụ về liên kết ngoài – PartnerLink

2.1.2 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 dạ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) [6] Các khái niệm (phần tử) 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ư cấu trúc tuần tự khác Cấu trúc của một tiến trình BPEL được mô tả trong tập tin BPEL như sau:

Hình 2.4: Cấu trúc file BPEL

2.2 Các khái niệm cơ bản về BPEL

2.2.1 Các thành phần tác vụ 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 ngôn ngữ WS-BPEL 2.0 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ó

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ề các tác vụ trong ngôn ngữ WS-BPEL 2.0:

Invoke Gọi một dịch vụ Web để thực hiện một tác vụ nào đó

Receive Nhận một thông điệp từ một dịch vụ ngoài Thông thường đây

là tác vụ bắt đầu một tiến trình mới

Opaque Activity Là một tác vụ dạng dẫn xuất

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…)

Tên tác vụ Các trường hợp sử dụng

Các tác vụ điều khiển và có cấu trúc

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

Pick

Định 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…)

Flow Xử lý song song và điều khiển phụ thuộc

While Lặp lại một tiến trình con nào đó trong process ở dạng while

RepeatUntil Lặp lại một tiến trình con nào đó trong tiến trình ở dạng

Repeat … Until Wait Dừng tiến trình trong một khoảng 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ácnhiệm vụ

liên quan với nhau (khi tiến trình trở nên phức tạp)

Các tác vụ dùng để quản lý lỗi và ngoại lệ

Sau đây là mô tả chi tiết và các trường hợp sử dụng của từng tác vụ: Tác vụ nhận - Receive

Khi một tiến trình BPEL cần nhận một thông điệp thì tác vụ receive sẽ được

sử dụng Tác vụ Receive sẽ xác định được dịch vụ đối tác mà nó được nhận thông điệp và các Operation từ dịch vụ ngoài mà nó cần phải gọi thông qua PartnerLinkvà Operation Để thực thi được thì tác vụ receive phải xác định được một biến đầu vào (input) hoặc phần dữ liệu mà nó được nhận Cấu trúc XML của tác vụ receive được thể hiện như sau

Hình 2.5: Cấu trúc XML của receive

Hình 2.5 mô tả khai báo tác vụ receive bao gồm liên kết ngoài (partnerLink=

‖NCName‖, portType=‖QName‖, operation=‖NCName‖, các tham số này được ứng dụng khách sử dụng và gửi thông điệp đến Biến BPEL VariableName được sử dụng để lưu giá trị đầu vào từ thông điệp

Tác vụ gọi dịch vụ Web - Invoke

Để gọi hoặc thực hiện một dịch vụ Web nào đó thì ta sử dụng tác vụ invoke Tác vụ Invoke mô tả một dịch vụ Web thực hiện ở dạng ―một chiều‖ hoặc ―yêu cầu

- đáp ứng‖ Các dịch vụ Web đối tác được xác định thông qua PartnerLink và Operation Để thực thi một tác vụ Invoke thì cần xác định ít nhất một biến đầu vào

và có hoặc không có biến đầu ra tùy thuộc vào từng dạng dịch vụ Web mà nó gọi thực hiện (dạng ―một chiều‖ hoặc ― yêu cầu - đáp ứng‖)

Hình 2.6: Ví dụ về trường hợp sử dụng invoke

Hình 2.6 mô tả một trường hợp sử dụng cụ thể của tác vụ invoke trong một chức năng tìm thông tin khách hàng, chức năng này gọi dịch vụ Web: tìm kiếm tên khách hàng (InvokeLookupCustomerName):

Cấu trúc XML của invoke được mô tả như sau:

Hình 2.7: Cấu trúc XML của invoke

Trong hình 2.7, một tác vụ invoke được khai báo để gọi dịch vụ ngoài có partnerLink là ―NCName‖ và operation là ―NCName‖ Tác vụ này sử dụng biến đầu vào ―NCName‖ và trả kết quả về cho biến ―NCFullName‖

Tác vụ nhận - Reply

Một tác vụ nhận (Reply) đóng vai trò như một giá trị trả về trong một tiến trình BPEL Nội dung thông điệp được gửi đi sẽ được dịch vụ Web đối tác tiếp nhận thông qua tác vụ Receive ở dạng onMessage (thông điệp) hoặc onEvent (sự kiện) Một tác vụ Reply thì sẽ có cùng một partnerLink và operation với tác vụ Receive tương ứng của dịch vụ Web đối tác Để thực thi được, tác vụ Reply yêu cầu phải được đặc tả cho thông điệp mà nó sẽ gửi đi Khi tiến trình xuất hiện lỗi thì tác vụ Reply sẽ trả về một ngoại lệ Chúng ta có thể kiểm soát các lỗi này bằng cách thêm một tác vụ Throw để trả về một ngoại lệ nếu xử lý trong tiến trình bị lỗi như hình13:

Hình 2.8 Trường hợp sử dụng của Reply

Cấu trúc XML của tác vụ Reply như sau:

Hình 2.9 Cấu trúc XML của Reply