1. Trang chủ
  2. » Luận Văn - Báo Cáo

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

75 390 1

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 75
Dung lượng 8,17 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

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

Trang 3

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ếtquả trong đề tài này là trung thực và chưa từng được ai công bố trong bất cứ côngtrì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ântí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ó ghitrong 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, đánhgiá 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ệntrong 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ệmtrước Hội đồng, cũng như kết quả luận văn của mình

Thái nguyên, ngày 12 tháng 11 năm 2013

Tác giả

Phạm Thanh Tùng

Trang 4

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ầyPGS.TS.ĐẶNG VĂN ĐỨC, đã tận tình hướng dẫn trong suốt quá trình viết luậnvă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ôngtin 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ốnkiế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 tronghọ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

Trang 5

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

Trang 6

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

Trang 7

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

Trang 8

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

Trang 9

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

Trang 10

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 quacá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 tinkhá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ầnthiế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ácthà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 saocho 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ụ webvớ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ụngnhiều phần mềm dịch vụ khác nhau do nhiều hãng khác nhau thiết kế Sự thay đổithự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ụngWeb 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.

Trang 11

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êncứ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ôngthườ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ácthiế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ụngnghiệ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ácdị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ó đượcviế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ốngnhấ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áctá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ênngôn ngữ WS- BPEL

Trang 12

Chương 1TỔNG QUAN VỀ DỊCH VỤ WEB1.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ácnhau 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ụngmộ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 đó, XMLtươ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ínhchấ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 CharacterSet (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ạothà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ộtchuỗi các bit và lưu trữ trong một tệp văn bản (text file)

Trang 13

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 ítngô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ệndụ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ạicà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ĩacủ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ởimộ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ácngô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ạnchế 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ỉ chophé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ộttá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ừutượ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ướngkiểu dữ liệu (datatype-oriented schema) và khuôn mẫu lập trình hướng đốitượ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óachỉ khi nó cần truyền dữ liệu qua mạng

Trang 14

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ênbả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ớimộ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ả

Trang 15

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 dungvă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ộtlầ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ủacá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ệutext — 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:

Trang 17

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ănbả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 chomộ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ể đượcbiể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 địnhdạ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ớithiệ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àiliệu XML

Trang 18

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 địnhdạ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ấutrú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ụngXML 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ênnhậ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 XMLnhư 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ạnthả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ế thamchiếu Vì thế SOAP client không giữ bất kỳ một tham chiếu đầy đủ nào về các đốitượ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ôngnghệ nào

Trang 19

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 đơngiản nhất trong trao đổi thông điệp SOAP Trong nhiều trường hợp, kiểu trao đổinà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ànhphần Header và Body Thành phần Header là một cơ chế mở cho phép thêm các tínhnă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ĩacủ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ựatrê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 protocolheader của chúng phải được chỉ định chi tiết cho mỗi ứng dụng

Trang 20

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ácphần tử sau:

- Phần tử gốc - envelop: Phần tử bao trùm nội dung message, khai báo vănbả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ể mangnhữ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ữngcà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ôngtin 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ó 3kiểu thông báo:

Trang 21

+ 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 ứngyê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ấpcủ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 trongRPC và document là khác nhau Nên việc quyết định chọn cái nào tùy thuộc vàothờ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, baogồm các thông tin [7]:

- Tên service

- Giao thức và kiểu mã hóa sẽ được sử dụng khi gọi các hàm của webservice

- Loại thông tin: những thao tác, những tham số, và những kiểu dữ liệu gồm

có giao diện của web service, cộng với tên cho giao diện này

Trang 22

Một WSDL hợp lệ gồm có hai phần:

1 Phần giao diện mô tả giao diện và giao thức kết nối

2 Phần thi hành mô tả thông tin để truy xuất service

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

- Tập tin giao diện service (cho phần 1)

- Tập tin thi hành service (cho phần 2)

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ủadị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:

Trang 23

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ựngnề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 quantrọ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

Trang 24

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ệpXML 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ằngcá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 thamchiế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ânloại (được sử dụng cho việc xếp loại kinh doanh và dịch vụ), và các hệ thống địnhdanh (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áchà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ácquy ướ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

Trang 25

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à chophé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ạngmục phân loại, các định danh, hoặc thông tin tên từng phần sử dụng hàmAPI_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ộtmụ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ọicác dịch vụ ra yêu cầu sử dụng thông tin mẫu kèm theo, thông thường đượclư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ửilạ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èmthay đổ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 Đâychính là mẫu tìm kiếm viện dẫn thông tin

Trang 26

Lưu và xóa (với hàm API save_xxx và delete_xxx) có thể được thực hiệntrê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ưnglưu ý rằng cách thức lưu trữ của toán tử save trong UDDI thông thường mang tínhphá 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 UDDIBusiness 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àmAPIsave_xxx) authToken có thể được tái sử dụng với thời gian ngắn trong khi cáctoá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ấtthiế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ộtdịch vụ được doanh nghiệp của cung cấp

Trang 27

 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ấtcánh như mong đợi Như một đăng ký của các dịch vụ, sẽ mong đợi tìm thấymột cách để trực tiếp xác định giao diện cho một dịch vụ, như WSDL thựchiệ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ựchiện trợ giúp trỏ đến các tài liệu XML, như chúng ta sẽ thấy sau này, nhưngtrong 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ìmkiế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 ghitrong đăng ký UDDI Những phương thức này trả về khóa để nhận dạng đốitượ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 đốitượng thực tế đó Ví dụ, get_businessService trả về toàn bộ đối tượngbusinessService, 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ộcvào những gì đang xóa Ví dụ, vì tModels thường xuyên được các đối tượngkhác trong cơ sở dữ liệu tham chiếu, nên chúng có thể không thực sự bị xóa

Trang 28

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 đadạ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 tinViệ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ểnkhai 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 đồngcông nghệ mạng thế giới Cụ thể thông qua các nhà cung cấp dịch vụ mạng ViệtNam 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ăngkhai 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 quytrì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 quytrình nghiệp vụ như: XPDL, BPML,BPEL… Nó giúp cho các lập trình viên và cácnhà 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ântí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

Trang 29

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ệnqua các giao diện đồ họa, cũng không có một chuẩn ký hiệu chung cho các ngônngữ này Trong các ngôn ngữ trên thì BPEL là ngôn ngữ được sử dụng rộng rãinhấ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áccô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 EclipsePlugin… 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ổnghợ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ểnnhiê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 nhanhnhấ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ẵncác chương trình desingner

Trang 30

Chương 2NGÔN NGỮ BPEL2.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ácnhau Phiên bản BPEL đầu tiên (BPEL 1.0) ra đời vào tháng 07/2002 Vào tháng05/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ởiMicrosoft 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ắcgử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 thimộ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ìnhBPEL bao gồm 2 tác vụ cơ bản nhất là receivevà reply trong đó tác vụ receivedù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ếtquả cuối cùng cho người dùng

Trang 31

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-Addressingthì 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ả trongWSDL 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ộttiế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 đượccung 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ânbiệ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àotrong toàn bộ tiến trình… Để giải quyết vấn đề này, BPEL đã đưa ra hai khái niệmmớ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ácPartnerLinkType trong BPEL Mỗi một PartnerLink được mô tả bằng mộtPartnerLinkType, được đặt tên để đại diện cho tất cả các tương tác thông quaPartnerLink đó Nếu PartnerLinkType tương ứng chỉ có một role thì role này sẽ mặc

Trang 32

đị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 trongmột số trường hợp thì chúng được xác định chung một namespace, điều này thườngxả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 BPELthì được chỉ ra trong tập tin BPEL Kỹ thuật dùng partnerLink chẳng những giảiquyế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ộtpartnerLink, 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ộtdị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

Trang 33

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ếntrì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ếntrình Mỗi partnerLink sẽ thiết lập một quan hệ giữa bản thân process với mộtservice 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ỗibiế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ủamộ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

Trang 34

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áctrườ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 Reply Là một tác vụ dạng dẫn xuất

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 XMLSchema, hay WSDL…)

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

Trang 35

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

xảy ra, nếu không có sự kiện nào xảy ra trong một thời gianchỉ đị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 whileRepeatUntil 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ệ

Exit Dừng tiến trình hiện tại

Trang 36

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 đượcthể 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ọithực hiện (dạng “một chiều” hoặc “ yêu cầu - đáp ứng”)

Trang 37

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ộtchứ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ênkhá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 đầuvào “NCName” và trả kết quả về cho biến “NCFullName”

Ngày đăng: 12/12/2016, 16:44

HÌNH ẢNH LIÊN QUAN

Hình 1.4: Lớp dịch vụ Web với UDDI - Kỹ thuật phát triển ứng dụng web bằng ngôn ngữ WS   BPEL
Hình 1.4 Lớp dịch vụ Web với UDDI (Trang 20)
Bảng sau mô tả chi tiết về các tác vụ trong ngôn ngữ WS-BPEL 2.0: - Kỹ thuật phát triển ứng dụng web bằng ngôn ngữ WS   BPEL
Bảng sau mô tả chi tiết về các tác vụ trong ngôn ngữ WS-BPEL 2.0: (Trang 31)
Hình 2.8 Trường hợp sử dụng của Reply - Kỹ thuật phát triển ứng dụng web bằng ngôn ngữ WS   BPEL
Hình 2.8 Trường hợp sử dụng của Reply (Trang 35)
Hình 2.11 Cấu trúc XML của Assign - Kỹ thuật phát triển ứng dụng web bằng ngôn ngữ WS   BPEL
Hình 2.11 Cấu trúc XML của Assign (Trang 37)
Hình 2.14: Cấu trúc XML của Flow - Kỹ thuật phát triển ứng dụng web bằng ngôn ngữ WS   BPEL
Hình 2.14 Cấu trúc XML của Flow (Trang 39)
Hình 2.15: Cấu trúc XML của Repeat Until - Kỹ thuật phát triển ứng dụng web bằng ngôn ngữ WS   BPEL
Hình 2.15 Cấu trúc XML của Repeat Until (Trang 40)
Hình 2.18: Cấu trúc XML của Flow - Kỹ thuật phát triển ứng dụng web bằng ngôn ngữ WS   BPEL
Hình 2.18 Cấu trúc XML của Flow (Trang 41)
Hình 2.23 Mô hình kiến trúc BPEL - Kỹ thuật phát triển ứng dụng web bằng ngôn ngữ WS   BPEL
Hình 2.23 Mô hình kiến trúc BPEL (Trang 45)
Hình 2.25 Bảng Danh sách các trình xử lý BPEL hiện nay - Kỹ thuật phát triển ứng dụng web bằng ngôn ngữ WS   BPEL
Hình 2.25 Bảng Danh sách các trình xử lý BPEL hiện nay (Trang 48)
Hình 2.26 Trình thiết kế của Apache ODE trên nền tảng Eclipse - Kỹ thuật phát triển ứng dụng web bằng ngôn ngữ WS   BPEL
Hình 2.26 Trình thiết kế của Apache ODE trên nền tảng Eclipse (Trang 49)
Hình 2.29: Trình thiết kế ActiveVOS - Kỹ thuật phát triển ứng dụng web bằng ngôn ngữ WS   BPEL
Hình 2.29 Trình thiết kế ActiveVOS (Trang 54)
Hình 2.35: Thiết lập khách hàng dịch vụ Web - Kỹ thuật phát triển ứng dụng web bằng ngôn ngữ WS   BPEL
Hình 2.35 Thiết lập khách hàng dịch vụ Web (Trang 63)
Hình 3.4: Cửa sổ Preferences - Kỹ thuật phát triển ứng dụng web bằng ngôn ngữ WS   BPEL
Hình 3.4 Cửa sổ Preferences (Trang 68)
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 - Kỹ thuật phát triển ứng dụng web bằng ngôn ngữ WS   BPEL
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 (Trang 69)
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 - Kỹ thuật phát triển ứng dụng web bằng ngôn ngữ WS   BPEL
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 (Trang 69)

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm

w