Luận văn: Nghiên cứu Mô hình hóa và Kiểm tra Tiến trình Nghiệp vụ (ĐH Công nghệ - ĐHQGHN)

Luận văn thạc sĩ: Nghiên cứu mô hình hóa và kiểm tra tiến trình nghiệp vụ. Tìm hiểu sâu về quy trình, phương pháp và ứng dụng thực tiễn. Tải ngay!

Chuyên ngành

Công nghệ thông tin

Người đăng

Ẩn danh

Thể loại

Luận văn thạc sĩ

2015

55
0
0

Phí lưu trữ

30 Point

Mục lục chi tiết

LỜI CẢM ƠN

TÓM TẮT

LỜI CAM ĐOAN

MỤC LỤC

DANH MỤC KÝ HIỆU VÀ CÁC TỪ VIẾT TẮT

DANH MỤC CÁC BẢNG BIỂU

DANH MỤC HÌNH VẼ

1. CHƯƠNG 1. PHẦN MỞ ĐẦU

1.1. Lý do chọn đề tài

1.2. Nội dung nghiên cứu

2. CÁC KIẾN THỨC CƠ BẢN

2.1. Tổng quan về ngôn ngữ thực thi tiến trình nghiệp vụ BPEL (Business Process Execution Language)

2.2. Các hoạt động cơ bản trong tiến trình BPEL

2.3. Hoạt động quản lý lỗi và ngoại lệ

2.4. Hệ thống chuyển trạng thái được gán nhãn - LTS và ký pháp tiến trình hữu hạn trạng thái - FSP

2.4.1. Hệ thống chuyển trạng thái được gán nhãn - LTS

2.4.2. Ký pháp tiến trình hữu hạn trạng thái - Finite State Process(FSP)

3. PHƯƠNG PHÁP CHUYỂN TỪ ĐẶC TẢ BPEL

3.1. SANG KÝ PHÁP FSP

3.1.1. Hành động empty

3.1.2. Hành động invoke

3.1.3. Hành động receive

3.1.4. Hành động reply

3.1.5. Hành động assign

3.1.6. Hành động sequence

3.1.7. Hành động if

3.1.8. Hành động while

3.1.9. Hành động pick

3.1.10. Hành động flow

3.1.11. Hành động wait

3.1.12. Hành động exit

3.1.13. Hành động throw

4. KIỂM CHỨNG DỊCH VỤ WEB

4.1. Cài đặt chương trình

4.2. Các ví dụ minh họa cho việc kiểm chứng tiến trình BPEL

TÀI LIỆU THAM KHẢO

Tóm tắt

I. Tổng Quan Mô Hình Hóa Kiểm Tra Tiến Trình Nghiệp Vụ

Dịch vụ Web đã mang lại những lợi ích to lớn, cho phép các phần mềm tích hợp với nhau bất kể nền tảng hay ngôn ngữ. Ngôn ngữ thực thi tiến trình nghiệp vụ BPEL ra đời, cung cấp phương thức tích hợp các dịch vụ Web thành một dịch vụ Web mới, hoạt động theo đúng kịch bản nghiệp vụ. Yêu cầu kiểm tra tính đúng đắn của tiến trình BPEL trở nên quan trọng. Tuy nhiên, việc kiểm chứng trực tiếp trên BPEL là không khả thi, đòi hỏi việc chuyển đổi đặc tả BPEL sang dạng đặc tả có thể kiểm chứng trực tiếp. Luận văn này trình bày về ngôn ngữ thực thi tiến trình nghiệp vụ BPEL và kiểm chứng dịch vụ Web được định nghĩa bằng ngôn ngữ BPEL, cách chuyển đổi đặc tả BPEL sang ký pháp FSP mô tả LTS tương ứng, để kiểm chứng LTS tương ứng. Một thuộc tính đại diện cho luồng thực thi công việc của tiến trình BPEL được sử dụng để kiểm tra tính thỏa mãn của LTS tương ứng. Nếu LTS thỏa mãn thuộc tính, tiến trình thỏa mãn yêu cầu; ngược lại, tiến trình BPEL không thỏa mãn. Các ví dụ minh họa cho việc kiểm chứng tiến trình BPEL với công cụ tự động LTSA cũng được trình bày chi tiết. Luận văn nghiên cứu về mô hình hóa và kiểm tra tiến trình nghiệp vụ, khẳng định tính cấp thiết và tầm quan trọng của việc kiểm chứng trong quá trình phát triển và triển khai các dịch vụ Web phức tạp, tích hợp.

1.1. Giới Thiệu Ngôn Ngữ Thực Thi Tiến Trình Nghiệp Vụ BPEL

Ngôn ngữ thực thi tiến trình nghiệp vụ BPEL (Business Process Execution Language) được sử dụng rộng rãi để định nghĩa tiến trình nghiệp vụ của một dịch vụ Web, hỗ trợ phát triển các ứng dụng phức tạp, quy mô lớn, đòi hỏi sự tổng hợp của nhiều dịch vụ Web khác nhau. BPEL hoạt động dựa trên chuẩn XML và là sự kết hợp của hai ngôn ngữ Xlang và WSFL (Web Service Flow Language) của IBM và Microsoft. WSFL được thiết kế bởi IBM dựa trên khái niệm về hướng đồ thị, trong khi Xlang được thiết kế bởi Microsoft là một khối cơ cấu ngôn ngữ. BPEL ra đời kết hợp cả hai phương pháp tiếp cận trên. Một tiến trình BPEL bao gồm các mối quan hệ với các đối tác bên ngoài, khai báo các xử lý dữ liệu, xử lý các mục đích khác nhau và quan trọng nhất là các hành động được thực hiện. Cấu trúc của một tiến trình BPEL bao gồm các phần tử chính như <Partners>, <Variables>, <Correclation-sets>, <Fault-handlers>, <Compensation-handlers> và <Activity>, mỗi phần tử đảm nhận một vai trò cụ thể trong việc mô tả và điều khiển luồng thực thi của tiến trình.

1.2. Tầm Quan Trọng của Kiểm Tra Tính Đúng Đắn Tiến Trình BPEL

Việc tích hợp các dịch vụ Web thành một dịch vụ Web mới, đảm bảo hoạt động theo đúng kịch bản nghiệp vụ, luôn là một yêu cầu quan trọng. Do đó, việc kiểm tra tính đúng đắn của tiến trình BPEL trở nên vô cùng cần thiết. Tuy nhiên, việc kiểm chứng trực tiếp trên tiến trình BPEL là không thể thực hiện được. Vì vậy, tiến trình BPEL cần được chuyển đổi sang dạng ngôn ngữ hoặc ký pháp có thể kiểm chứng trực tiếp được. Ký pháp tiến trình hữu hạn trạng thái FSP được sử dụng để chuyển đổi từ tiến trình BPEL. Việc kiểm chứng BPEL lúc này tương đương với việc kiểm chứng tính thỏa mãn của LTS với một thuộc tính p, và việc kiểm chứng này được thực hiện thông qua công cụ kiểm chứng tự động LTSA. Điều này nhấn mạnh vai trò quan trọng của việc mô hình hóa và kiểm tra tiến trình nghiệp vụ trong việc đảm bảo chất lượng và độ tin cậy của các dịch vụ Web phức tạp.

II. Thách Thức Trong Kiểm Chứng Tiến Trình BPEL Thực Tế

Trong thực tế, việc kiểm chứng tiến trình BPEL gặp nhiều thách thức. Đầu tiên, sự phức tạp của các tiến trình BPEL, với nhiều nhánh rẽ và các hoạt động lặp đi lặp lại, khiến cho việc kiểm tra thủ công trở nên khó khăn và dễ sai sót. Thứ hai, các tiến trình BPEL thường tương tác với nhiều dịch vụ Web bên ngoài, làm tăng thêm độ phức tạp và khó khăn trong việc kiểm soát và dự đoán hành vi của hệ thống. Cuối cùng, việc thiếu các công cụ và phương pháp kiểm chứng hiệu quả khiến cho việc đảm bảo tính đúng đắn và tin cậy của các tiến trình BPEL trở thành một nhiệm vụ đầy thách thức. Do đó, việc nghiên cứu và phát triển các phương pháp và công cụ mô hình hóa và kiểm tra tiến trình nghiệp vụ hiệu quả là vô cùng cần thiết.

2.1. Độ Phức Tạp Của Tiến Trình Nghiệp Vụ BPEL

Tiến trình nghiệp vụ BPEL thường bao gồm nhiều thành phần và hoạt động phức tạp, như các hoạt động điều khiển luồng (sequence, if, while, pick), các hoạt động tương tác với dịch vụ Web (invoke, receive, reply), và các hoạt động xử lý lỗi (throw, compensate). Sự kết hợp của các thành phần này tạo ra một hệ thống có nhiều trạng thái và đường dẫn thực thi khác nhau, khiến cho việc kiểm tra và xác minh tính đúng đắn của tiến trình trở nên vô cùng khó khăn. Một tiến trình BPEL có thể có hàng trăm hoặc thậm chí hàng nghìn dòng mã, và việc kiểm tra thủ công tất cả các trường hợp có thể xảy ra là một nhiệm vụ bất khả thi.

2.2. Tương Tác Với Dịch Vụ Web Bên Ngoài

Tiến trình BPEL thường tương tác với nhiều dịch vụ Web bên ngoài để thực hiện các chức năng cụ thể. Các dịch vụ Web này có thể được cung cấp bởi các tổ chức khác nhau, và việc kiểm soát và dự đoán hành vi của chúng là rất khó khăn. Một dịch vụ Web có thể bị lỗi, bị chậm trễ hoặc trả về kết quả không chính xác, gây ảnh hưởng đến hoạt động của tiến trình BPEL. Do đó, việc kiểm tra và xử lý các trường hợp lỗi có thể xảy ra khi tương tác với các dịch vụ Web bên ngoài là một thách thức lớn trong việc kiểm chứng tiến trình BPEL.

2.3. Thiếu Các Công Cụ Và Phương Pháp Kiểm Chứng Hiệu Quả

Mặc dù có một số công cụ và phương pháp kiểm chứng tiến trình BPEL hiện có, nhưng chúng vẫn còn nhiều hạn chế. Một số công cụ chỉ hỗ trợ kiểm tra cú pháp và ngữ nghĩa của mã BPEL, mà không thể kiểm tra được tính đúng đắn của tiến trình trong quá trình thực thi. Một số phương pháp chỉ có thể kiểm tra được các tiến trình BPEL đơn giản, mà không thể áp dụng cho các tiến trình phức tạp. Do đó, việc nghiên cứu và phát triển các công cụ và phương pháp kiểm chứng tiến trình BPEL hiệu quả là vô cùng cần thiết để đảm bảo chất lượng và độ tin cậy của các dịch vụ Web.

III. Phương Pháp Chuyển Đổi BPEL Sang Ký Pháp FSP Để Kiểm Chứng

Để giải quyết những thách thức trong việc kiểm chứng tiến trình BPEL, luận văn này đề xuất phương pháp chuyển đổi từ đặc tả BPEL sang ký pháp tiến trình hữu hạn trạng thái FSP. Phương pháp này cho phép biểu diễn tiến trình BPEL dưới dạng một mô hình toán học, từ đó có thể áp dụng các kỹ thuật kiểm chứng mô hình để xác minh tính đúng đắn của tiến trình. Việc chuyển đổi BPEL sang FSP bao gồm việc ánh xạ các hoạt động BPEL sang các tiến trình FSP tương ứng, và xây dựng một mô hình FSP hoàn chỉnh mô tả luồng thực thi của tiến trình BPEL. Sau khi chuyển đổi sang FSP, có thể sử dụng công cụ LTSA để kiểm tra tính thỏa mãn của mô hình FSP với các thuộc tính an toàn, như tính không deadlock, tính không livelock và tính thỏa mãn các ràng buộc thời gian.

3.1. Ánh Xạ Hoạt Động BPEL Sang Tiến Trình FSP

Mỗi hoạt động BPEL (ví dụ: invoke, receive, reply, assign, if, while, pick) được ánh xạ sang một tiến trình FSP tương ứng. Ví dụ, hoạt động invoke được ánh xạ sang một tiến trình FSP có hai trạng thái: trạng thái bắt đầu và trạng thái kết thúc, và một hành động invoke để chuyển từ trạng thái bắt đầu sang trạng thái kết thúc. Hoạt động if được ánh xạ sang một tiến trình FSP có hai nhánh: một nhánh cho trường hợp điều kiện đúng và một nhánh cho trường hợp điều kiện sai. Việc ánh xạ này đảm bảo rằng luồng thực thi của tiến trình BPEL được bảo toàn trong mô hình FSP.

3.2. Xây Dựng Mô Hình FSP Hoàn Chỉnh Cho Tiến Trình BPEL

Sau khi ánh xạ các hoạt động BPEL sang các tiến trình FSP tương ứng, cần xây dựng một mô hình FSP hoàn chỉnh mô tả luồng thực thi của tiến trình BPEL. Mô hình này bao gồm việc kết nối các tiến trình FSP lại với nhau theo đúng thứ tự và quan hệ điều khiển trong tiến trình BPEL. Ví dụ, nếu hai hoạt động BPEL được thực hiện tuần tự, thì hai tiến trình FSP tương ứng sẽ được kết nối với nhau sao cho tiến trình thứ nhất kết thúc và tiến trình thứ hai bắt đầu. Mô hình FSP hoàn chỉnh này là một biểu diễn chính xác của luồng thực thi của tiến trình BPEL.

3.3. Sử Dụng LTSA Để Kiểm Tra Tính Thỏa Mãn Thuộc Tính An Toàn

Sau khi xây dựng mô hình FSP hoàn chỉnh, có thể sử dụng công cụ LTSA (Labeled Transition System Analyser) để kiểm tra tính thỏa mãn của mô hình với các thuộc tính an toàn. LTSA là một công cụ kiểm chứng mô hình mạnh mẽ, cho phép kiểm tra tính không deadlock, tính không livelock và tính thỏa mãn các ràng buộc thời gian của mô hình FSP. Nếu mô hình FSP thỏa mãn tất cả các thuộc tính an toàn, thì có thể kết luận rằng tiến trình BPEL tương ứng cũng thỏa mãn các thuộc tính này. Ngược lại, nếu mô hình FSP vi phạm một hoặc nhiều thuộc tính an toàn, thì cần phải xem xét lại tiến trình BPEL để tìm và sửa lỗi.

IV. Ứng Dụng Thực Tiễn Kiểm Chứng Dịch Vụ Web Với LTSA

Luận văn trình bày các ví dụ cụ thể về việc ứng dụng phương pháp chuyển đổi BPEL sang FSP và sử dụng LTSA để kiểm chứng dịch vụ Web. Các ví dụ này bao gồm việc kiểm chứng các tiến trình BPEL đơn giản và phức tạp, và việc kiểm tra tính thỏa mãn của các thuộc tính an toàn khác nhau. Kết quả của các ví dụ này cho thấy rằng phương pháp chuyển đổi BPEL sang FSP và sử dụng LTSA là một phương pháp hiệu quả để kiểm chứng dịch vụ Web, và có thể giúp phát hiện và sửa lỗi trong các tiến trình BPEL.

4.1. Ví Dụ 1 Kiểm Chứng Tiến Trình BPEL Đơn Giản

Ví dụ đầu tiên trình bày về việc kiểm chứng một tiến trình BPEL đơn giản, có chức năng lấy ID của tiến trình được thực hiện trước đó. Tiến trình này gọi đến dịch vụ Pingpong để lấy ID, sau đó trả về kết quả. Việc kiểm chứng tiến trình này bao gồm việc chuyển đổi tiến trình BPEL sang FSP, và kiểm tra tính thỏa mãn của mô hình FSP với thuộc tính "tiến trình luôn trả về ID hợp lệ". Kết quả cho thấy rằng tiến trình BPEL này thỏa mãn thuộc tính an toàn, và có thể kết luận rằng tiến trình hoạt động đúng như mong đợi.

4.2. Ví Dụ 2 Kiểm Chứng Tiến Trình BPEL Phức Tạp Với Vòng Lặp While

Ví dụ thứ hai trình bày về việc kiểm chứng một tiến trình BPEL phức tạp hơn, có sử dụng vòng lặp while. Tiến trình này thực hiện một loạt các phép tính toán lặp đi lặp lại cho đến khi đạt được một điều kiện nhất định. Việc kiểm chứng tiến trình này bao gồm việc chuyển đổi tiến trình BPEL sang FSP, và kiểm tra tính thỏa mãn của mô hình FSP với thuộc tính "vòng lặp luôn kết thúc sau một số hữu hạn lần lặp". Kết quả cho thấy rằng tiến trình BPEL này thỏa mãn thuộc tính an toàn, và có thể kết luận rằng vòng lặp while hoạt động đúng và không gây ra tình trạng treo.

V. Kết Luận Hướng Phát Triển Nghiên Cứu Mô Hình Hóa BPEL

Luận văn đã trình bày một phương pháp hiệu quả để mô hình hóa và kiểm tra tiến trình nghiệp vụ bằng cách chuyển đổi đặc tả BPEL sang ký pháp FSP và sử dụng công cụ LTSA để kiểm chứng. Phương pháp này cho phép phát hiện và sửa lỗi trong các tiến trình BPEL, giúp đảm bảo chất lượng và độ tin cậy của các dịch vụ Web. Hướng phát triển tiếp theo của nghiên cứu bao gồm việc mở rộng phương pháp để hỗ trợ các tính năng nâng cao của BPEL, như xử lý ngoại lệ, giao dịch và tương tác không đồng bộ. Ngoài ra, việc nghiên cứu và phát triển các công cụ hỗ trợ tự động hóa quá trình chuyển đổi BPEL sang FSP và kiểm chứng mô hình FSP cũng là một hướng đi đầy tiềm năng.

5.1. Tổng Kết Những Đóng Góp Chính Của Luận Văn

Luận văn đã đóng góp vào lĩnh vực mô hình hóa và kiểm tra tiến trình nghiệp vụ bằng cách đề xuất một phương pháp hiệu quả để chuyển đổi đặc tả BPEL sang ký pháp FSP và sử dụng công cụ LTSA để kiểm chứng. Phương pháp này đã được chứng minh là hiệu quả thông qua các ví dụ thực tế, và có thể giúp cải thiện chất lượng và độ tin cậy của các dịch vụ Web. Ngoài ra, luận văn cũng đã xác định các hướng phát triển tiếp theo của nghiên cứu, và đề xuất các giải pháp tiềm năng để giải quyết các thách thức còn tồn tại.

5.2. Hướng Phát Triển Nghiên Cứu Trong Tương Lai

Trong tương lai, có nhiều hướng phát triển tiềm năng cho nghiên cứu về mô hình hóa và kiểm tra tiến trình nghiệp vụ sử dụng BPELFSP. Một hướng đi là mở rộng phương pháp để hỗ trợ các tính năng nâng cao của BPEL, như xử lý ngoại lệ, giao dịch và tương tác không đồng bộ. Một hướng khác là nghiên cứu và phát triển các công cụ hỗ trợ tự động hóa quá trình chuyển đổi BPEL sang FSP và kiểm chứng mô hình FSP. Ngoài ra, việc áp dụng các kỹ thuật trí tuệ nhân tạo để cải thiện hiệu quả và độ chính xác của quá trình kiểm chứng cũng là một hướng đi đầy hứa hẹn.

23/09/2025

Trích đoạn nội dung tài liệu

Phần mở đầu Chương này giới thiệu lý bối cảnh và lý do chọn đề tài. Chương 2: Các kiến thức cơ bản Chương này trình bày các kiến cơ bản ngôn ngữ thực thi tiến trình nghiệp vụ BPELnhư cấu trúc của một tiến trình BPEL, các hoạt động cơ bản trong tiến trình BPEL. TIEU LUAN MOI download : skknchat@gmail.com 2 Chương 3: Phương pháp chuyển từ đặc tả BPEL sang ký pháp FSP Chương này tìm hiểu các phương pháp chuyển đổi các hành động trong tiến trình BPEL sang ký pháp hữu hạn trạng thái FSP. Chương 4: Kiểm chứng dịch vụ Web Chương này xây dựng các ví dụ minh họa cho việc kiểm chứng tính đúng đắn của tiến trình BPEL với kịch bản, với công cụ giúp cho việc kiểm chứng tự động là LTSA.

Các ví dụ đưa ra được đặc tả bằng ngôn ngữ thực thi tiến trình nghiệp vụ BPEL. Sử dụng công cụ LTSA để chuyển đổi tự động sang ký pháp FSP và tiến hành kiểm chứng. Kết luận Chương này đưa ra kết luận về kết quả đạt được, cũng như hạn chế của luận văn. TIEU LUAN MOI download : skknchat@gmail.com 3 Chương 2.

CÁC KIẾN THỨC CƠ BẢN 2. Tổng quan về ngôn ngữ thực thi tiến trình nghiệp vụ BPEL (Business Process Execution Language) Ngôn ngữ thực thi tiến trình nghiệp vụ BPEL được sử dụng để định nghĩa tiến trình nghiệp vụ của một dịch vụ Web. Nó được dùng để hỗ trợ phát triển ứng dụng phức tạp lớn, đòi hỏi tổng hợp nhiều dịch vụ Web khác nhau. Vào 7/2002 phiên bản BPEL 1.0 đầu tiên ra đời.

Phiên bản BPEL 1.1 ra đời vào năm 4/2003 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). Năm 2007 tổ chức OASIS chuẩn hóa BPEL và được đổi tên thành WS-BPEL 2.0 và được dùng cho đến nay. BPEL hoạt động dựa trên chuẩn XML và là sự kết hợp của hai ngôn ngữ Xlang và WSFL (Web Service Flow Language) của IBM và Microsoft. WSFL được thiết kế bởi IBM dựa trên khái niệm về hướng đồ thị.

Xlang được thiết kế bởi Microsoft là một khối cơ cấu ngôn ngữ, BPEL ra đời kết hợp cả hai phương pháp tiếp cận trên. Một tiến trình BPEL chứa đựng các mối quan hệ với các đối tác bên ngoài, khai báo các xử lý dữ liệu, xử lý các mục đích khác nhau và quan trọng nhất, các hành động được thực hiện. Một tiến trình BPEL là một mô tả dưới dạng tài tiệu XML. Các thành phần trong tiến trình BPEL được định nghĩa gồm các phần từ gốc, chứa một hoặc nhiều phần tử con như: partners, variables, Correlation-Set, Fault-Handlers, Compensation-Handlers, Activity.1 minh họa cho cấu trúc BPEL cơ bản và các hoạt động [3].

Các phần tử chính trong tiến trình BPEL bao gồm: <Partners>: Phần tử partners định nghĩa các mối quan hệ giữa các dịch vụ tham gia vào tiến trình. <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. <Correclation-sets>: Phần tử correclation-sets sử dụng để định nghĩa các thuộc tính giúp xác định xem tiến trình sử dụng dịch vụ nào.

TIEU LUAN MOI download : skknchat@gmail. Cấu trúc tiến trình BPEL cơ bản <Fault-handlers>: Fault-handlers dùng để xử lý các ngoại lệ phát sinh trong quá trình thực thi tiến trình. <Compensation-handlers>: Khi công việc thực hiện xong, muốn báo cho tiến trình BPEL biết hành động đã thực hiện thì phần tử Compensation-handlers được sử dụng. <Activity>: Chứa các hành động trong tiến trình.

Ví dụ một tiến trình BPEL như sau: <bpel:process name="helloworld" targetNamespace="http://helloworld" suppressJoinFailure="yes" xmlns:tns="http://helloworld" xmlns:bpel="http://docs.0/process/executable" > <!-- PARTNERLINKS --> <!-- List of services participating in this BPEL process --> <!-- ============================================================= --> <bpel:partnerLinks> <!-- The 'client' role represents the requester of this service.--> <bpel:partnerLink name="client" partnerLinkType="tns:helloworld" myRole="helloworldProvider" /> </bpel:partnerLinks> <!-- =============================================================--> <!-- VARIABLES --> TIEU LUAN MOI download : skknchat@gmail.com 5 <!-- List of messages and XML documents used within this BPEL process--> <!-- ============================================================== --> <bpel:variables> <!-- Reference to the message passed as input during initiation --> <bpel:variable name="input" messageType="tns:helloworldRequestMessage"/> <!-- Reference to the message that will be returned to the requester--> <bpel:variable name="output" messageType="tns:helloworldResponseMessage"/> </bpel:variables> <bpel:sequence name= “main”> </bpel:sequence> </bpel:process> 2. Các hoạt động cơ bản trong tiến trình BPEL Các hành vi trong tiến trình BPEL được xác định bởi các hành động có trong tiến trình và thứ tự thực hiện của chúng. Các hoạt động được chia thành 3 nhóm như sau: - Hoạt động cơ bản: Là các hoạt động đơn thể, nó không chứa hoạt động nào bên trong nó. - Hoạt động có cấu trúc: Nó chứa các hoạt động bên trong nó.

- Hoạt động xử lý lỗi: Hoạt động này sử dụng để xử lý lỗi và các ngoại lệ xảy ra trong quá trình hoạt động của tiến trình. Mô tả các hành động trong ngôn ngữ BPEL và ý nghĩa TT Tên hành động Ý nghĩa Hành động cơ bản Là một hoạt động đặc biệt, không thực hiện một hành 1 Empty động nào khi được gọi trong tiến trình BPEL 2 Invoke Được sử dụng khi cần gọi một dịch vụ Web khác 3 Receive Nhận một thông điệp từ bên ngoài của tiến trình 4 Reply Gửi trả lại thông điệp được nhận bởi receive trước đó 5 Assign Dùng để khởi tạo hoặc gán giá trị cho biến Hoạt động có cấu trúc Thiết lập thứ tự thực hiện của các hành động xuất hiện 6 Sequence trong sequence TIEU LUAN MOI download : skknchat@gmail.com 6 7 If/Else Định nghĩa cấu trúc có điều kiện Lặp đi lặp lại một hành động cho đến khi không còn thỏa 8 While mãn điều kiện 9 Pick Định nghĩa cách lựa chọn hành động. 10 Wait Dừng tiến trình BPEL trong một khoảng thời gian 11 Scope Chia nhỏ các tiến trình Hoạt động quản lý lỗi và xử lý ngoại lệ 12 Exit Được sử dụng để dừng tiến trình BPEL ngay lập tức Được sử dụng để ném ra một ngoại lệ trong quá trình 13 Throw thực thi tiến trình Hành động này dùng để xử lý lỗi, khi có lỗi xảy ra nó sẽ 14 Compensate được dùng để xử lý lỗi trên phạm vi được chỉ ra Fault Handlers xử lý các ngoại lệ phát sinh trong quá 15 Fault Handler trình thực thi tiến trình 2. Hoạt động cơ bản a)Hành động Empty Là một hoạt động đặc biệt, không làm nhiệm vụ gì khi được gọi trong tiến trình BPEL.

Empty được sử dụng trong trường hợp khi có một lỗi cần được bắt và cấm hoạt động. Cấu trúc XML của hoạt động này có dạng như sau: <empty standard-attributes> standard-elements </empty> Trong đó standard-attributes và standard-elements là các thuộc tính và các thành phần chuẩn trong đặc tả của BPEL b)Hành động Invoke Hoạt động này được sử dụng để gọi đến một dịch vụ Web khác. Điển hình sử dụng để gọi 1 hoạt động cơ bản trên dịch vụ. Tác vụ invoke mô tả dịch vụ Web thực hiện ở dạng “một chiều” hoặc “yêu cầu – đáp ứng”.

Để thực thi một hoạt động 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 Web mà nó gọi thực hiện (dạng “một chiều” hoặc “yêu cầu - đáp ứng”). TIEU LUAN MOI download : skknchat@gmail.com 7 Cấu trúc XML của invoke được mô tả như sau: <invoke partnerLink="ncname" portType="qname" operation="ncname" inputVariable="ncname"? outputVariable="ncname"? standard-attributes> standard-elements <catch faultName="qname" faultVariable="ncname"?>* activity </catch> <catchAll>? activity </catchAll> </invoke> Trong ví dụ trên một hoạt động invoke được khai báo để gọi dịch vụ ngoài có partnerLink là “NCName”, thuộc tính portType và operation xác định chức năng được sử dụng trong dịch vụ được gọi. Hoạt động này sử dụng biến đầu vào inputVariable để lưu trữ thông tin và outputVariable để nhận kết quả. Ví dụ: <bpel:invoke name="InvokeRectangle" partnerLink="rectanglePL" operation="add" portType="ns:CalculatorPortType" inputVariable="rectanglePLRequest" outputVariable="rectanglePLResponse"> </bpel:invoke> c)Hành động Receive Hành động này được sử dụng khi tiến trình BPEL cần nhận một thông điệp từ bên ngoài.

Hành động receive có cấu trúc XML như sau: <bpel:receive name="receiveInput" partnerLink="client" portType="tns:helloworld" operation="process" variable="input" createInstance="yes"/> TIEU LUAN MOI download : skknchat@gmail.com 8 Trong đó: thuộc tính partnerLink chứa tên của partnerLink chỉ định dịch vụ nhận thông điệp; thuộc tính portType chứa tên của portType (tập các chức năng có thể thực hiện bởi một dịch vụ); thuộc tính operation chứa tên của chức năng được gọi (lưu ý là portType và operation được định nghĩa trong tệp WSDL); thuộc tính variable chứa tên của biến dùng để lưu trữ thông điệp nhận được; thuộc tính createInstance nhận giá trị “yes” nếu hành động receive là hành động đầu tiên trong tiến trình, giá trị này giúp xác định việc tạo thể hiện mới của tiến trình hay không. Ví dụ: <bpel:receive name="receiveInput" partnerLink="client" portType="tns:While" operation="process" variable="input" createInstance="yes"/> d)Hành động Reply Hành động được sử dụng để gửi một thông điệp trả lời cho thông điệp đã nhận được bởi hành động receive trước đó. Cấu trúc XML của Reply như sau: <reply partnerLink="ncname" portType="qname" operation="ncname" variable="ncname"? faultName="qname"? standard-attributes> standard-elements <correlations>? <correlation set="ncname" initiate="yes|no"?>+ </correlations> </reply> Tác vụ reply có cùng partnerLink operation với tác vụ receive tương ứng với nó. Tác vụ này dùng biến Variable để lưu kết quả trả về từ những tác vụ trước đó của tiến trình.

Khi tiến trình xuất hiện lỗi thì Reply sẽ trả về ngoại lệ thay vì trả về một thông điệp bình thường. Ví dụ: TIEU LUAN MOI download : skknchat@gmail.com 9 <bpel:reply name="replyOutput" partnerLink="client" portType="tns:While" operation="process" variable="output"/> e)Hành động Assign Hoạt động Assign dùng để khởi tạo hoặc gán giá trị cho một hoặc nhiều biến trong tiến trình BPEL. Nó được sử dụng để sao chép dữ liệu từ một biến đến một biến khác, cũng như để xây dựng và chèn dữ liệu mới bằng cách sư dụng các biểu thức. Việc sử dụng các biểu thức chủ yếu được thúc đẩy bởi sự cần thiết phải thực hiện các tính toán đơn giản (chẳng hạn như tăng số thự tự).

Biểu thức hoạt động dựa trên các biến, thuộc tính, các hằng số để tạo ra một giá trị mới. <assign standard-attributes> standard-elements <copy>+ from-spec to-spec </copy> </assign> Một hoạt động assign có thể bao gồm một hoặc nhiều thẻ copy để thực hiện các thao tác gán biến. Trong đó from chỉ định giá trị, biểu thức hoặc biến được dùng để gán, to chỉ định biến được gán giá trị. Standard-attributes và standard-elements là các thuộc tính và các thành phần chuẩn trong đặc tả của BPEL.

Thẻ copy không chỉ được dùng với các biến mà còn được dùng để sao chép từ một phần tử của một biến phức hợp hoặc sử dụng biểu thức thông qua ngôn ngữ XPATH. Ví dụ <bpel:assign validate="no" name="Assign"> <bpel:copy> <bpel:from> <bpel:literal xml:space="preserve">0</bpel:literal> </bpel:from> TIEU LUAN MOI download : skknchat@gmail.com 10 <bpel:to variable="iterator"></bpel:to> </bpel:assign> 2.Hoạt động cấu trúc Hành động có cấu trúc quy định thứ tự trong tập hợp các hành động được thực thi.

Nội dung được bảo vệ bản quyền — Tải xuống đầy đủ