Luận văn: Nghiên cứu vấn đề bế tắc (Deadlock) trong quy trình BPEL

Luận văn thạc sĩ: Nghiên cứu vấn đề bế tắc (deadlock) trong quy trình BPEL. Giải pháp và hiện thực hóa quy trình tránh bế tắc hiệu quả.

• Tác giả: Phạm Thị Dung
• Người hướng dẫn: Ts. Võ Đình Hiếu
• Trường học: Trường Đại học Công nghệ - Đại học Quốc gia Hà Nội
• Chuyên ngành: Công nghệ thông tin
• Đề tài: Vấn đề bế tắc (Deadlock) trong quy trình được hiện thực bằng BPEL
• Loại tài liệu: Luận văn thạc sỹ
• Năm xuất bản: 2015
• Địa điểm: Hà Nội

Mục lục chi tiết

• Lời cảm ơn
• Tóm tắt
• Abtract thesis
• Lời cam đoan
• Mục lục
• Danh sách hình vẽ
• Danh sách các từ viết tắt
• Mở đầu
• 1. Chương 1: Tổng quan về kết hợp dịch vụ và ngôn ngữ BPEL
• 1.1. Tổng quan về kết hợp dịch vụ Web
• 1.2. Ngôn ngữ thực thi quy trình nghiệp vụ BPEL
• 1.3. Tại sao nên sử dụng BPEL
• 1.4. Tổng quan cấu trúc của một tiến trình BPEL
• 1.5. Bài toán khởi tạomột tiến trình BPEL
• 1.6. Cấu trúc của một tiến trình WS-BPEL
• 1.7. Các thành phần hoạt động của BPEL
• 1.8. Cung cấp và tiêu thụ các dịch vụ Web
• 1.9. Cấu trúc hóa logic tiến trình
• 1.10. Các thành phần hoạt động lặp
• 1.11. Xử lý song song
• 1.12. Thao tác dữ liệu
• 1.13. Điều khiển ngoại lệ
• 1.14. Tổng kết chương một
• 2. Chương 2 : Phát biểu và vấn đề bế tắc
• 2.1. Phát biểu
• 2.2. Giới thiệu chung về
• 2.3. Các thành phần và thuộc tính chuẩn liên quan
• 2.4. Thành phần trong
• 2.5. Ví dụ về
• 2.6. Vấn đề bế tắc trong
• 2.7. Tổng kết chương hai
• 3. Chương 3: Xây dựng công cụ kiểm tra và cảnh báo deadlock
• 3.1. Ý tưởng giải pháp
• 3.2. Xây dựng công cụ phát hiện và cảnh báo bế tắc
• 3.3. Kết quả đánh giá công cụ
• 3.4. Tổng kết chương ba
• Tài liệu tham khảo

Tóm tắt

I. Giới thiệu tổng quan luận văn thạc sĩ về Deadlock và BPEL

Luận văn thạc sĩ này tập trung nghiên cứu sâu về vấn đề bế tắc (Deadlock) trong các quy trình được hiện thực bằng ngôn ngữ BPEL (Business Process Execution Language). BPEL được sử dụng rộng rãi trong kiến trúc hướng dịch vụ (SOA) để điều phối các dịch vụ web. Tuy nhiên, việc sử dụng BPEL để xây dựng các workflow phức tạp có thể dẫn đến các tình huống deadlock, gây ảnh hưởng nghiêm trọng đến hiệu năng và tính ổn định của hệ thống. Luận văn này trình bày một cách tiếp cận toàn diện để phát hiện deadlock, ngăn chặn deadlock và giải quyết deadlock trong các quy trình BPEL. Mục tiêu chính là cung cấp một cơ sở lý thuyết vững chắc và các công cụ thực tế để giúp các nhà phát triển xây dựng các quy trình BPEL mạnh mẽ và tin cậy hơn. Dịch vụ Web ra đời đã mở ra hướng mới cho việc tương tác giữa các ứng dụng thông qua sử dụng các tiêu chuẩn Web, hiện được áp dụng đa dạng trong hệ thống phần mềm thực tế. Các ứng dụng, hệ thống đòi hỏi ngày càng mở rộng quy mô và phức tạp về các quy trình nghiệp vụ. Việc sử dụng các dịch vụ Web riêng lẻ cho từng chức năng nghiệp vụ, ngày càng không đáp ứng được với độ phức tạp của hệ thống. Ngôn ngữ thực thi quy trình nghiệp vụ BPEL đưa ra để định nghĩa một mô hình và ngữ pháp để mô tả hành vi của quy trình nghiệp vụ và đối tác hay các dịch vụ Web. BPEL mô hình quy trình nghiệp vụ định nghĩa từ các thành phần hoạt động cơ bản như , , , … và các thành phần hoạt động có cấu trúc như , , , <repeatUntil>, , …. Trong đó, thành phần hoạt động quan trọng, được dùng khi mô hình một ứng dụng nghiệp vụ , sử dụng để định nghĩa một tập các thành phần hoạt động thực thi đồng thời hoặc song song.

1.1. Tầm quan trọng của việc nghiên cứu về vấn đề Deadlock trong BPEL

Việc nghiên cứu về vấn đề Deadlock trong BPEL có ý nghĩa quan trọng trong bối cảnh các ứng dụng SOA ngày càng trở nên phổ biến và phức tạp. Các quy trình BPEL thường xuyên tương tác với nhiều dịch vụ web khác nhau, và việc đảm bảo tính nhất quán và tin cậy của các tương tác này là rất quan trọng. Deadlock có thể dẫn đến việc hệ thống bị treo, mất dữ liệu và ảnh hưởng đến trải nghiệm người dùng. Do đó, việc phát hiện deadlock, ngăn chặn deadlock và giải quyết deadlock là những vấn đề then chốt cần được giải quyết để đảm bảo chất lượng và hiệu năng của các ứng dụng SOA. Nghiên cứu về Deadlock trong BPEL còn liên quan đến việc hiện thực quy trình hiệu quả. Quy trình cần được thiết kế sao cho không gây ra bế tắc, đảm bảo tính chạy song song khi có thể, và có cơ chế đồng bộ hóa phù hợp. Service-oriented architecture (SOA) cần được xem xét một cách tổng thể, từ khâu thiết kế đến triển khai và vận hành.

1.2. Các phương pháp tiếp cận chính để giải quyết Deadlock trong BPEL

Có nhiều phương pháp tiếp cận khác nhau để giải quyết Deadlock trong BPEL. Các phương pháp này có thể được chia thành ba nhóm chính: phát hiện deadlock, ngăn chặn deadlock và giải quyết deadlock. Phương pháp phát hiện deadlock tập trung vào việc phát hiện deadlock khi nó xảy ra. Phương pháp ngăn chặn deadlock tập trung vào việc thiết kế các quy trình BPEL sao cho deadlock không thể xảy ra. Phương pháp giải quyết deadlock tập trung vào việc khôi phục hệ thống khi deadlock xảy ra. Mỗi phương pháp có những ưu điểm và nhược điểm riêng, và việc lựa chọn phương pháp phù hợp phụ thuộc vào đặc điểm cụ thể của ứng dụng.

II. Phân tích chi tiết các nguyên nhân gây ra Deadlock trong BPEL

Để phát hiện deadlock, ngăn chặn deadlock và giải quyết deadlock hiệu quả, cần phải hiểu rõ các nguyên nhân gây ra deadlock trong các quy trình BPEL. Luận văn này phân tích chi tiết các nguyên nhân phổ biến nhất, bao gồm: điều phối tài nguyên không hợp lý, sử dụng khóa (lock) không đúng cách, và chạy song song không kiểm soát. Ngoài ra, luận văn cũng xem xét các nguyên nhân ít phổ biến hơn, chẳng hạn như các lỗi trong trình hiện thực quy trình BPEL. Luận văn thạc sĩ sẽ đi sâu tìm hiểu về, các vấn đề sẽ gây ra bế tắc, xung đột trong một , từ đó, xây dựng chương trình phát hiện và cảnh báo về vấn đề này. BPEL mô hình quy trình nghiệp vụ định nghĩa từ các thành phần hoạt động cơ bản như , , , … và các thành phần hoạt động có cấu trúc như , , , <repeatUntil>, , …. Trong đó, thành phần hoạt động quan trọng, được dùng khi mô hình một ứng dụng nghiệp vụ , sử dụng để định nghĩa một tập các thành phần hoạt động thực thi đồng thời hoặc song song.

2.1. Điều phối tài nguyên không hợp lý và Deadlock

Một trong những nguyên nhân chính gây ra deadlock trong BPEL là điều phối tài nguyên không hợp lý. Khi nhiều quy trình BPEL cùng tranh chấp các tài nguyên hạn chế, chẳng hạn như các kết nối cơ sở dữ liệu hoặc các dịch vụ Web, có thể xảy ra tình huống deadlock nếu mỗi quy trình giữ một số tài nguyên và chờ đợi để có được các tài nguyên mà các quy trình khác đang giữ. Để ngăn chặn deadlock do điều phối tài nguyên không hợp lý, cần phải thiết kế các quy trình BPEL sao cho chúng sử dụng tài nguyên một cách hiệu quả và không giữ tài nguyên quá lâu. Các thuật toán điều phối tài nguyên có thể được sử dụng để đảm bảo rằng các tài nguyên được phân phối một cách công bằng và tránh tình trạng deadlock. Việc mô hình hóa quy trình và phân tích quy trình kỹ lưỡng cũng giúp xác định các điểm nóng tài nguyên và giảm thiểu nguy cơ deadlock.

2.2. Sử dụng khóa Lock không đúng cách và Deadlock trong BPEL

Việc sử dụng khóa (lock) là một cơ chế phổ biến để bảo vệ các tài nguyên được truy cập đồng thời bởi nhiều quy trình BPEL. Tuy nhiên, nếu khóa được sử dụng không đúng cách, nó có thể dẫn đến deadlock. Chẳng hạn, nếu một quy trình BPEL giữ một khóa và sau đó chờ đợi để có được một khóa khác mà một quy trình khác đang giữ, có thể xảy ra tình huống deadlock. Để tránh deadlock do sử dụng khóa không đúng cách, cần phải tuân thủ các nguyên tắc cơ bản về quản lý khóa, chẳng hạn như luôn giải phóng khóa khi không còn cần thiết và tránh giữ khóa quá lâu. Transaction cũng là một khái niệm quan trọng, đảm bảo tính toàn vẹn dữ liệu và có thể giúp ngăn chặn deadlock.

2.3. Các vấn đề về Chạy song song không kiểm soát dẫn đến bế tắc

Một trong những vấn đề của chạy song song là làm sao đồng bộ hóa dữ liệu chính xác để không bị xung đột. Tuy nhiên, việc đồng bộ hóa quá mức có thể dẫn đến bế tắc hay deadlock. BPEL sử dụng cấu trúc Flow để định nghĩa việc chạy song song, đòi hỏi lập trình viên phải hiểu rõ luồng dữ liệu, các khóa và tài nguyên được sử dụng để thiết kế một quy trình ổn định. Cần phân tích kỹ các workflow và quy trình nghiệp vụ trước khi hiện thực quy trình bằng BPEL để tránh các vấn đề bế tắc.

III. Các Thuật toán phát hiện deadlock hiệu quả cho quy trình BPEL

Luận văn này trình bày một số thuật toán phát hiện deadlock hiệu quả có thể được sử dụng để phát hiện deadlock trong các quy trình BPEL. Các thuật toán này dựa trên việc xây dựng một đồ thị chờ đợi, trong đó các nút đại diện cho các quy trình BPEL và các cạnh đại diện cho các mối quan hệ chờ đợi giữa các quy trình. Thuật toán phát hiện deadlock tìm kiếm các chu trình trong đồ thị chờ đợi, và nếu một chu trình được tìm thấy, nó chỉ ra rằng một deadlock đã xảy ra. Thuật toán phát hiện deadlock trong quy trình nghiệp vụ sử dụng thành phần hoạt động , đối với dạng mã nguồn kiểu 1, kết quả trả lại phải không thông báo các lỗi chu trình hoặc bế tắc. Dạng mã nguồn kiểu 2, tìm chu trình, nếu tồn tại chu trình sẽ cảnh báo, có khả năng sẽ xuất hiện chu trình logic trong quá trình runtime. Dạng mã nguồn kiểu 3, phân tích điều kiện joinCondition từ của các link, nếu các link điều hướng phụ thuộc cho các nhánh của thành phần lựa chọn (phiên bản BPEL 2.0) hoặc [5] (phiên bản BPEL 1.0 hoặc 1.1), thì cảnh báo lỗi sai về cách sử dụng thành phần gây ra bế tắc.

3.1. Xây dựng đồ thị chờ đợi để phát hiện deadlock

Việc xây dựng đồ thị chờ đợi là bước quan trọng nhất trong các thuật toán phát hiện deadlock. Đồ thị chờ đợi phải phản ánh chính xác các mối quan hệ chờ đợi giữa các quy trình BPEL, và phải được cập nhật thường xuyên để đảm bảo rằng nó luôn chính xác. Việc xây dựng đồ thị chờ đợi có thể được thực hiện bằng cách theo dõi các sự kiện liên quan đến việc điều phối tài nguyên và việc sử dụng khóa (lock) trong các quy trình BPEL. Cần có một hệ thống giám sát và ghi lại các sự kiện này để phục vụ cho việc xây dựng đồ thị chờ đợi. Mô hình hóa quy trình chi tiết giúp xác định các điểm cần theo dõi.

3.2. Các thuật toán tìm kiếm chu trình trong đồ thị chờ đợi

Sau khi đồ thị chờ đợi được xây dựng, các thuật toán tìm kiếm chu trình có thể được sử dụng để phát hiện deadlock. Có nhiều thuật toán tìm kiếm chu trình khác nhau, chẳng hạn như thuật toán tìm kiếm theo chiều sâu (DFS) và thuật toán tìm kiếm theo chiều rộng (BFS). Việc lựa chọn thuật toán phù hợp phụ thuộc vào kích thước và độ phức tạp của đồ thị chờ đợi. DFS thường hiệu quả hơn cho các đồ thị lớn và thưa thớt, trong khi BFS có thể hiệu quả hơn cho các đồ thị nhỏ và dày đặc. Cần cân nhắc hiệu năng của thuật toán trong quá trình phân tích quy trình.

3.3. Các phương pháp cảnh báo và giải quyết deadlock sau khi phát hiện

Sau khi deadlock được phát hiện, cần có các phương pháp cảnh báo và giải quyết deadlock để khôi phục hệ thống. Việc cảnh báo có thể được thực hiện bằng cách gửi thông báo đến các nhà quản trị hệ thống hoặc bằng cách ghi lại thông tin về deadlock vào nhật ký hệ thống. Việc giải quyết deadlock có thể được thực hiện bằng cách hủy bỏ một hoặc nhiều quy trình BPEL liên quan đến deadlock, hoặc bằng cách giải phóng các tài nguyên mà các quy trình này đang giữ. Việc lựa chọn phương pháp giải quyết deadlock phù hợp phụ thuộc vào mức độ nghiêm trọng của deadlock và các ràng buộc về thời gian và tài nguyên. Cần có các kịch bản ứng phó deadlock được chuẩn bị trước.

IV. Các Thuật toán ngăn chặn deadlock trong quy trình BPEL

Ngoài việc phát hiện deadlock, cũng có thể ngăn chặn deadlock bằng cách thiết kế các quy trình BPEL sao cho deadlock không thể xảy ra. Luận văn này trình bày một số thuật toán ngăn chặn deadlock phổ biến, chẳng hạn như thuật toán yêu cầu tất cả các quy trình BPEL yêu cầu tất cả các tài nguyên mà chúng cần trước khi bắt đầu, và thuật toán áp đặt một thứ tự tuyến tính trên tất cả các tài nguyên và yêu cầu các quy trình yêu cầu tài nguyên theo thứ tự này. Thuật toán ngăn chặn deadlock này làm cho các thành phần hoạt động của BPEL được thiết kế để chương trình không xảy ra bế tắc hoặc chu trình, tuy nhiên, việc sự kết hợp giữa thành phần hoạt động cấu trúc có lựa chọn như hay tuần tự trong có sử dụng , có thể gây ra bế tắc.

4.1. Yêu cầu tất cả tài nguyên trước khi bắt đầu

Một trong những thuật toán ngăn chặn deadlock đơn giản nhất là yêu cầu tất cả các quy trình BPEL yêu cầu tất cả các tài nguyên mà chúng cần trước khi bắt đầu. Nếu một quy trình không thể có được tất cả các tài nguyên mà nó cần, nó sẽ không bắt đầu. Thuật toán này đảm bảo rằng không có quy trình nào có thể giữ một số tài nguyên và chờ đợi để có được các tài nguyên mà các quy trình khác đang giữ. Tuy nhiên, thuật toán này có thể làm giảm hiệu năng của hệ thống, vì nó có thể dẫn đến việc các quy trình phải chờ đợi lâu để có được tất cả các tài nguyên mà chúng cần. Cần cân nhắc hiệu năng và tính khả thi của việc áp dụng thuật toán này.

4.2. Áp đặt thứ tự tuyến tính trên tất cả các tài nguyên

Một thuật toán ngăn chặn deadlock khác là áp đặt một thứ tự tuyến tính trên tất cả các tài nguyên và yêu cầu các quy trình yêu cầu tài nguyên theo thứ tự này. Thuật toán này đảm bảo rằng không có chu trình nào có thể xảy ra trong đồ thị chờ đợi, vì các quy trình luôn yêu cầu tài nguyên theo cùng một thứ tự. Tuy nhiên, thuật toán này có thể khó thực hiện trong thực tế, vì nó có thể khó xác định một thứ tự tuyến tính phù hợp cho tất cả các tài nguyên. Điều phối tài nguyên theo thứ tự giúp tránh các vòng lặp chờ đợi. Cần có một cơ chế quản lý và theo dõi thứ tự này.

V. Xây dựng công cụ kiểm tra và cảnh báo Deadlock trong BPEL

Từ các giải pháp trên, Luận văn này trình bày việc xây dựng một công cụ kiểm tra và cảnh báo deadlock cho các quy trình BPEL. Công cụ này sử dụng các thuật toán phát hiện deadlock và thuật toán ngăn chặn deadlock đã được trình bày ở trên để phát hiện deadlock và ngăn chặn deadlock trong các quy trình BPEL. Công cụ này cũng cung cấp các cảnh báo cho các nhà phát triển khi nó phát hiện các tình huống có thể dẫn đến deadlock. Với đầu vào là tài liệu mã nguồn chương trình BPEL .bpel, đặc tả XML, định dạng các thành phần activity dưới dạng các cặp thẻ bao đóng. Mỗi một activity khác nhau sẽ có đặc điểm đặc trưng, biểu diễn cho định nghĩa của activity đó. Chúng có hai kiểu: thành phần hoạt động có cấu trúc và thành phần hoạt động cơ sở. Thành phần hoạt động có cấu trúc chứa các thành phần khác và định nghĩa logic nghiệp vụ giữa chúng. Ngược lại, thành phần hoạt động cơ sở chỉ thực hiện mục đích đưa ra của chính nó như nhận một thông điệp từ một đối tác, hoặc thao tác dữ liệu và không định nghĩa bất kỳ logic nghiệp vụ khác, cũng không chứa được bất kỳ thành phần hoạt động khác.

5.1. Kiến trúc và chức năng của công cụ kiểm tra Deadlock

Công cụ kiểm tra deadlock bao gồm ba thành phần chính: bộ phân tích mã nguồn, bộ phát hiện deadlock và bộ cảnh báo. Bộ phân tích mã nguồn phân tích mã nguồn BPEL để xây dựng đồ thị chờ đợi và xác định các tình huống có thể dẫn đến deadlock. Bộ phát hiện deadlock sử dụng các thuật toán phát hiện deadlock để tìm kiếm các chu trình trong đồ thị chờ đợi. Bộ cảnh báo cung cấp các cảnh báo cho các nhà phát triển khi nó phát hiện các tình huống có thể dẫn đến deadlock. Công cụ cần có giao diện thân thiện với người dùng và dễ dàng tích hợp vào quy trình phát triển BPEL.

5.2. Đánh giá hiệu năng của công cụ trên các quy trình BPEL thực tế

Hiệu năng của công cụ kiểm tra deadlock cần được đánh giá trên các quy trình BPEL thực tế để đảm bảo rằng nó có thể phát hiện deadlock và ngăn chặn deadlock một cách hiệu quả. Việc đánh giá hiệu năng có thể được thực hiện bằng cách sử dụng các bộ kiểm thử được thiết kế đặc biệt để kiểm tra các tính năng khác nhau của công cụ. Kết quả đánh giá sẽ cung cấp thông tin về độ chính xác, tốc độ và khả năng mở rộng của công cụ. Cải thiện hiệu năng quy trình là một mục tiêu quan trọng khi sử dụng công cụ này.

VI. Kết luận và hướng phát triển tiếp theo của luận văn về Deadlock

Luận văn này đã trình bày một cách tiếp cận toàn diện để phát hiện deadlock, ngăn chặn deadlock và giải quyết deadlock trong các quy trình BPEL. Luận văn đã phân tích chi tiết các nguyên nhân gây ra deadlock, trình bày một số thuật toán phát hiện deadlock và thuật toán ngăn chặn deadlock hiệu quả, và trình bày việc xây dựng một công cụ kiểm tra và cảnh báo deadlock cho các quy trình BPEL. Hướng phát triển tương lai của luận văn bao gồm việc nghiên cứu các thuật toán mới để phát hiện deadlock và ngăn chặn deadlock, và việc đánh giá hiệu năng của các công cụ kiểm tra deadlock trên các quy trình BPEL thực tế. Ngoài ra, cần có các nghiên cứu về việc kiểm thử quy trình và đánh giá hiệu năng quy trình. Việc xây dựng một hệ thống tự động cải thiện hiệu năng quy trình cũng là một hướng đi tiềm năng.

6.1. Tóm tắt những đóng góp chính của luận văn

Luận văn đã đóng góp vào việc nâng cao hiểu biết về deadlock trong BPEL bằng cách phân tích các nguyên nhân, trình bày các thuật toán và xây dựng một công cụ. Các kết quả nghiên cứu có thể được sử dụng để cải thiện chất lượng và hiệu năng của các ứng dụng SOA.

6.2. Các hướng nghiên cứu tiềm năng trong tương lai

Trong tương lai, cần có các nghiên cứu sâu hơn về các thuật toán mới để phát hiện deadlock và ngăn chặn deadlock. Ngoài ra, cần có các nghiên cứu về việc tích hợp các công cụ kiểm tra deadlock vào các môi trường phát triển BPEL và về việc sử dụng trí tuệ nhân tạo để tự động giải quyết deadlock. Phân tích quy trình, mô hình hóa quy trình và cải thiện hiệu năng quy trình nên được tiếp tục nghiên cứu và phát triển.

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

Chương 1: Tổng quan về kết hợp dịch vụ và ngôn ngữ BPEL Chương này, luận văn giới thiệu tổng quan về kết hợp dịch vụ Web và ngôn ngữ thực thi quy trình nghiệp vụ BPEL cùng các thành phần hoạt động của nó. Ngoài ra, luận văn còn nêu lên được tại sao nên sử dụng BPEL trong các ứng dụng nghiệp vụ sử dụng dịch vụ Web. Tổng quan về kết hợp dịch vụ Web Web service – dịch vụ Web, tạo ra với mục đích để tương tác giữa các ứng dụng bởi việc sử dụng các tiêu chuẩn Web. Các dịch vụ Web sử dụng mô hình kết nối lỏng lẻo cho phép tích hợp linh hoạt giữa các hệ thống độc lập như B2C (business-to- consumer), B2B (business-to-business) hay các hệ thống tích hợp ứng dụng doanh nghiệp.

Các đặc tả liên quan tới dịch vụ Web như SOAP – định nghĩa một giao thức giao tiếp XML cho khả năng tương tác dịch vụ cơ bản, WSDL (ngôn ngữ mô tả dịch vụ Web) giới thiệu cú pháp chung cho mô tả dịch vụ và UDDI cung cấp kết nối hạ tầng cho việc giao tiếp và kết nối. Kết hợp, các đặc tả đó cho phép các ứng dụng tương tác với mỗi cái khác theo mô hình kết nối lỏng lẻo, độc lập về nền tảng [2]. Việc tích hợp các hệ thống thực tế mong đợi nhiều vào khả năng tương tác đơn giản, sử dụng các giao thức tiêu chuẩn. Dịch vụ Web có nền tảng tích hợp mềm dẻo áp dụng trong các ứng dụng và quy trình nghiệp vụ có thể giải quyết các vấn đề tương tác phức tạp thông qua một mô hình tích hợp quy trình chuẩn.

Mô hình tương tác được hỗ trợ trực tiếp bởi WSDL là mô hình phi trạng thái nhận yêu cầu – phản hồi hoặc cách thức tương quan nhiều chiều. Các mô hình tương tác nghiệp vụ hiện nay cơ bản áp dụng một trong các kiểu trao đổi thông điệp như peer-to-peer, yêu cầu - phản hồi, một chiều, có trạng thái, các tương tác dài (long – running) liên quan tới hai hoặc nhiều bên. Để định nghĩa các tương tác nghiệp vụ hệ thống, mô tả hình thức các giao thức trao đổi thông điệp cùng với sử dụng các quy trình nghiệp vụ của chúng là điều cần thiết. Các quy trình nghiệp vụ bao gồm các hành vi phụ thuộc dữ liệu, khả năng xác định các điều kiện ngoại lệ, hậu quả/ kết quả của tương tác, và tính phối hợp giữa các đơn vị, phòng ban.

Một hệ thống được biểu diễn chi tiết, rõ ràng ở nhiều khía cạnh khác nhau càng tốt. Vai trò phân tích hệ thống, các chi tiết thực thi nghiệp vụ hệ thống không nhất thiết đưa ra, khi đó cần một quy trình trừu tượng để mô tả hành vi trao đổi thông điệp thấy được của mỗi bên liên 2 TIEU LUAN MOI download : [e-mail] quan sẽ quan trọng hơn. Các vai trò xây dựng, triển khai, cần một quy trình thể hiện luồng thực thi và tích hợp các dịch vụ giữa các bên liên quan, hoặc quản lý trao đổi dữ liệu. Ngôn ngữ BPEL định nghĩa hai quy trình: trừu tượng và thực thi sẽ mô tả, biểu diễn tiến trình nghiệp vụ hệ thống sử dụng các dịch vụ Web theo hai quy trình đó.

Ngôn ngữ thực thi quy trình nghiệp vụ BPEL WS-BPEL (Web Services Business Process Execution Language) hay ngắn gọn BPEL (Business Process Execution Language) là ngôn ngữ thực thi tiến trình nghiệp vụ các dịch vụ Web. Phiên bản BPEL4WS (Business Process Execution Language for Web Services 1.0) được giới thiệu vào tháng 7/2002, kết hợp chung của IBM, Microsoft và BEA. Nó sử dụng ngôn ngữ luồng dịch vụ Web (Web Services Flow Language - WSFL) của IBM và XLANG của Microsoft.1 và thêm sự tham gia đóng góp của SAP và Siebel Systems, được phát hành vào tháng 5/2003 [3]. Phiên bản gần nhất WS-BPEL 2.0 được giới thiệu năm 2007.

Trong phạm vi tài liệu luận văn này, chỉ đề cập và sử dụng phiên bản WS-BPEL 2.0 và gọi ngắn gọn là BPEL hay WS-BPEL. Đặc tả BPEL 2.0 định nghĩa một ngôn ngữ cho quy trình nghiệp vụ xây dựng dựa trên các dịch vụ Web.0 cung cấp một mô tả quy chuẩn hoàn chỉnh về ngôn ngữ thực thi quy trình nghiệp vụ. Các khái niệm cơ bản của BPEL được hiểu theo một trong hai hướng, trừu tượng hoặc thực thi. Một tiến trình trừu tượng BPEL là một tiến trình đặc tả từng phần không phải để thực thi và phải được khai báo rõ ràng như kiểu trừu tượng.

Trong khi tiến trinh thực thi được đặc tả đầy đủ và có thể được thi hành, một tiến trình trừu tượng có thể ẩn các chi tiết thao tác cụ thể hóa được yêu cầu thể hiện bởi vật thực thi. Tất cả kiến trúc của tiến trình thực thi tạo nên giá trị tới tiến trình trừu tượng, vì thế tiến trình BPEL thực thi và trừu tượng có độ mạnh thể hiện như nhau. - Tiến trình trừu tượng cung cấp hai cơ chế ẩn các chi tiết thao tác; một sử dụng các thẻ không rõ ràng một cách rõ ràng hoặc thiếu sót. Các tiến trình trừu tượng có vai trò mô tả, thường đưa ra nhiều ca sử dụng, một ca sử dụng mô hình hành vi nhìn thấy của vài hoặc tất cả các dịch vụ được đề xuất bởi tiến trình trừu tượng.

Ca sử dụng khác định nghĩa một khuôn mẫu tiến trình, khuôn mẫu này thể hiện những thực hành tốt nhất từng miền cụ thể. Bất kể với từng ca sử dụng và mục đích, tất cả các tiến trình trừu tượng chia sẻ một cơ sở cú pháp chung. Chúng có yêu cầu khác nhau về mức độ của độ mờ và hạn chế trong các phần của một định nghĩa tiến trình, có thể bị bỏ sót hoặc bị ẩn. Cách sử dụng phù hợp của các tiến trình trừu tượng có hiệu quả khác nhau trong các ràng buộc nhất quán và trong cú pháp của tiến trình đó.

3 TIEU LUAN MOI download : [e-mail] - Trong khi tiến trình trừu tượng không yêu cầu để chỉ rõ đầy đủ, tiến trình thực thi có ngôn ngữ định nghĩa một cách hiệu quả dạng thực thi động cho các tiến trình nghiệp vụ dựa trên các tài nguyên dịch vụ Web và dữ liệu XML hoàn toàn. Hơn nữa, các tiến trình thực thi và tương tác cùng với các đối tác của chúng trong một cách thức nhất quán không phân biệt nền tảng hỗ trợ hoặc mô hình lập trình được dùng thực thi của các môi trường phục vụ. BPEL sử dụng vài đặc tả XML: WSDL 1. Ngôn ngữ mô tả dịch vụ Web WSDL và định nghĩa kiểu XML Schema cung cấp mô hình dữ liệu được sử dụng bởi các tiến trình BPEL.

XPath và XSLT cung cấp hỗ trợ cho việc thao tác sử dụng dữ liệu. Tất cả tài nguyên bên ngoài và các đối tác được miêu tả như các dịch vụ WSDL. BPEL cung cấp khả năng mở rộng để cung cấp các phiên bản tương lai của các chuẩn, đặc tả XPath và liên quan chuẩn được sử dụng trong tính toán XML. Tại sao nên sử dụng BPEL Điểm mạnh của BPEL là khả năng tổ chức một tiến trình nghiệp vụ.

Đối với các yêu cầu cho một tiến trình logic phức tạp, BPEL là một lựa chọn tốt[10]. Nó phù hợp cho các hệ thống nghiệp vụ lớn và các tiến trình tương tác dài (long-running), đặc biệt các hệ thống SOA. Ưu điểm của việc sử dụng BPEL trong mô hình nghiệp vụ các dịch vụ Web bao gồm: - Cung cấp ngôn ngữ chuẩn cho việc diễn giải các quy trình nghiệp vụ: giàu ngữ nghĩa và bao quát, trải qua phát triển nghiêm ngặt hướng tới giải quyết các yêu cầu phức tạp, BPEL đưa ra hướng giải quyết dàn phối toàn diện. - Tận dụng một tập hợp kỹ năng chung và ngôn ngữ: Các tiêu chuẩn cho phép chi phí tổng thấp nhất của quyền sở hữu qua tính di động tri thức, thay vì sử dụng các kỹ thuật độc quyền phức tạp, BPEL có các thực hành tốt, các mẫu, kinh nghiệm và đào tạo được tận dụng từ đa dạng các nhà cung cấp, truy cập tới các nguồn tài nguyên tri thức trong mô hình và công nghệ của BPEL.

- Được thiết kế để phù hợp tự nhiên tới ngăn xếp chứa dịch vụ Web: Trong WS- BPEL một tiến trình nghiệp vụ tương tác cùng các dịch vụ qua các lời gọi dịch vụ Web. Sự tổng hợp đệ quy, một tiến trình BPEL tận dụng tương tác cung cấp bởi các mức thấp nhất của hàng đợi các dịch vụ Web, như WSDL, SOAP, WS-Addressing. - Thể hiện hoàn toàn bằng XML: như các tiến trình nghiệp vụ WS-BPEL thể hiện trong XML, chúng là dễ đọc và được sử dụng bởi bất kỳ các cơ sở tiến trình XML. 4 TIEU LUAN MOI download : [e-mail] - Sử dụng và kế thừa WSDL 1.1 và XML Schema 1.0: BPEL sử dụng và kế thừa WSDL để cả cung cấp và sử dụng dịch vụ Web trong phương thức trừu tượng, sử dụng WSDL để định nghĩa các giao tiếp dịch vụ.

Trong khi đó XML Schema 1.0 để mô hình dữ liệu. - Đa nền tảng và nhà cung cấp động: BPEL cung cấp các nền tảng tiêu chuẩn cơ sở. Các tiến trình BPEL chạy trên bất kỳ engine biên dịch WS-BPEL. - Tương thích giữa các tiến trình tương tác và tái sử dụng: BPEL cung cấp một chuẩn chung cung cấp tương thích giữa các nền tảng khác nhau và các tiến trình thực thi trong chúng.

Tổng quan cấu trúc của một tiến trình BPEL 1. Bài toán khởi tạomột tiến trình BPEL Trước khi đi mô tả chi tiết cấu trúc của các tiến trình nghiệp vụ, phần này sẽ đưa ra một ví dụ đơn giản của một tiến trình WS-BPEL cho việc xử lý một đơn đặt hàng. Các thao tác tiến trình được miêu tả trong hình 1. Bài toán: Trong việc nhận đặt hàng từ một khách hàng, tiến trình phải khởi tạo và tính toán đồng thời ba phần như tính toán chi phí cuối của một đơn hàng, lựa chọn một phương thức chuyển hàng, lên lịch sản phẩm và giao hàng.

Trong vài xử lý có thể tiến hành đồng thời, có sự phụ thuộc điều khiển và dữ liệu giữa ba phần. Như, chi phí giao hàng được yêu cầu để tính chi phí cuối cùng của đơn hàng, ngày giao hàng được yêu cầu để hoàn thành lịch giao hàng. Sau khi ba phần đồng thời được hoàn thành, tiến trình hóa đơn có thể tiến hàng và hóa đơn sẽ được gửi tới khách hàng. 5 TIEU LUAN MOI download : skknchat@gmail.1: Tiến trình xử lý đơn nhận hàng Dịch vụ Web purchaseOrderPT được sử dụng cho tiến trình đặt hàng và nó được mô tả trong WSDL kèm theo.Việc tính toán chi phí cung cấp, lựa chọn phương thức giao hàng và đặt lịch được xây dựng như các dịch vụ Web mô tả trong WSDL.