Như mô tả ở phần một, BPEL sử dụng các đặc tả XML như XML Schema cung cấp mô hình dữ liệu, và BPEL mô hình quy trình nghiệp vụ sử dụng các định nghĩa thành phần activities khai báo đặc tả XML. <flow> trong BPEL sử dụng <link> được xem như cấu trúc dạng đồ thị, thành phần <link> quy định luồng chạy ẩn giữa các thành phần hoạt động trong bao đóng một <flow>. Đặc điểm, mỗi <link> phải có ít nhất một thành phần nguồn <source> và ít nhất một thành phần đích <target>. Bỏ qua các điều kiện <scope> hay trình điều khiển lỗi, vì thế, với đầu vào là tài liệu mã nguồn .bpel dữ liệu dạng XML, chuyển <flow> về mô hình đồ thị có hướng. Như thế, đối với bài toán 1, bài toán 3, quy về tìm chu trình trong đồ thị có hướng. Đối với
bài toán 2, quy về tìm trạng thái thuộc tính của một nốt đồ thị có nhiều hơn hai cung vào. Ứng dụng được mô tả thành các phần như hình 3.1.1.
Hình 3.1.1: Mô hình ứng dụng phát hiện hiện bế tắc
Đầu tiên, 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. Sử dụng DOM, một tiêu chuẩn được định nghĩa bởi tổ chức W3C, để truy cập tài liệu mã nguồn một tiến trình BPEL dạng XML như một cấu trúc cây. Với mỗi tài liệu XML, mô hình DOM sẽ duyệt và chuyển mã nguồn biểu diễn một tiến trình BPEL thành một mô hình cây của các đối tượng DOM Tree. Từ kết quả đó, chương trình ứng dụng sẽ chuyển DOM Tree thành đồ thị có hướng tương ứng cho phần mã nguồn
<flow> trong mã nguồn BPEL. Mỗi một nút (đỉnh) trong DOM Tree sẽ trở thành một
nút trong đồ thị được sinh ra. Tuy nhiên, mô tả XML của các thành phần hoạt động có những đặc tả không cần thiết để sử dụng trong đồ thị có hướng sinh ra trên. Cụ thể với các thành phần hoạt động cơ sở có tác dụng nhận, gửi thông điệp, chứa thông tin, thao tác dữ liệu, sẽ trở thành một nút của đồ thị có hướng. Như mô tả trong phần 1.5.5, thành phần thao tác dữ liệu <assign> nó chứa một hoặc nhiều thao tác <copy>. Mỗi thao tác <copy> có một đặc tả <from> và đặc tả <to>, đòi hỏi các thành phần nguồn và đích, nơi dữ liệu được bảo sao từ <from> và <to>. Bỏ qua các thuộc tính
như <copy>, <from>, <to>, <query> của <assign> trong bước chuyển DOM
Tree của thành phần <assign> thành một nút (đỉnh) của đồ thị có hướng trong
chương trình ứng dụng, thành phần <assign> được mô tả như sau:
Hình 3.1.2: Mô tả thành phần <assign> thành nút đồ thị
Như vậy, đối với các thành phần hoạt động cơ sở như <receive>, <reply>,
<invoke>, <assign>, <wait>, <empty> thành các nút (đỉnh) trong đồ thị có hướng, bỏ qua các thành phần thuộc tính của chúng. Khi đó tên của các nút trên là giá trị của thuộc tính name của các thành phần hoạt động cơ sở.
Đối với các thành phần hoạt động có cấu trúc như <sequence>, <if>, <while>,
<repeatUntil>, <forEach>, <pick>, <flow> chứa các thành phần khác, định
nghĩa nghiệp vụ của chúng. Trong phạm vi luận văn này, sẽ chỉ xét các trường hợp thành phần <flow> chứa thành phần hoạt động lựa chọn <if> hoặc thành phần hoạt động tuần tự <sequence>, hay các trường hợp lồng nhau của nhiều hơn hai thành phần <flow> phức tạp không đề cập sâu. Như đã giới thiệu trong mục 2.2, sự thực thi của thành phần <if> và <sequence> có thể xem như luồng thực thi ẩn của thành phần <link> trong <flow>. Đối với thành phần <if>, sau khi <if> bắt đầu, xét điều kiện biểu thức condition của <if>, điều kiện true, định hướng thực thi tới một trong các nhánh của thành phần <if>. Sau khi một trong các nhánh hoàn thành, thành phần lựa chọn <if> chuyển sang trạng thái hoàn thành. Đối với thành phần tuần tự <sequence>, sau khi <sequence> bắt đầu, thành phần con trong bao chứa của nó trong <sequence> sẽ thực thi tuần tự, sau khi tất cả các thành phần con hoàn thành, <sequence> sẽ có trạng thái hoàn thành. Từ đặc trưng đó, <if> không thể cùng lúc thực thi nhiều hơn hai nhánh của nó hay <sequence> thực thi các thành phần con của nó tuần tự, điều này có thể tạo ra các vấn đề gây bế tắc trong thành phần
<flow>.
Hình 3.1.3: Chuyển <if> thành đồ thị có hướng
Giả sử thành phần <if> chứa các thành phần cơ sở đã đưa ra ở trên, ở bước chuyển
DOM Tree, thành phần <if> chuyển thành một nút (đỉnh) của đồ thị có hướng với tên nút là giá trị của thuộc tính name của <if>. Và các nhánh tương ứng với các thành phần con trong bao đóng của <if>, cũng trở thành các nút (đỉnh) của đồ thị có
hướng. Bước loại bỏ các thành phần thuộc tính của các thành phần cơ sở đã nêu ra trước đó. Luồng điều khiển thực thi của <if>, tương tự luồng điều khiển ẩn của
<link>, từ đó, xác định được các cung trong đồ thị có hướng, ứng với luồng xử lý
các nhánh của <if>, dù biểu thức điều kiện condition của <if>, biểu thức Boolean phụ thuộc vào giá trị biểu thức để xác định, nhánh nào trong <if> mới được thực thi. Tuy nhiên, đối với các trường hợp <if> lồng nhiều hơn một thành phần <if> khác mà nó chứa các thành phần cơ sở, thì đệ quy tương tự thành phần <if> bao đóng. Các trường hợp, <if> chứa các thành phần cấu trúc khác, sẽ liên quan tới mối quan hệ tương quan giữa <if> và các thành phần thao tác khác hoặc biến trong biểu thức
condition và các trường hợp đó không xét trong luận văn này. Tương tự đối với
thành phần <sequence>, các thành phần nằm trong bao đóng một <sequence> sẽ thực thi tuần tự, <sequence> bắt đầu, Activity A hoàn thành, Activity B mới chuyển sang trạng thái thực thi, khi Activity cuối cùng hoàn thành, <sequence> mới có trạng thái là hoàn thành. Rõ ràng, luồng thực thi của <sequence> miêu tả như đặc trưng hoạt động của <source>, <target> của <link> trong <flow>. Khi đó, chuyển <sequence> và các thành phần nằm trong bao đóng của nó thành các đỉnh và các cung của đô thị có hướng mô tả như hình 3.1.4.
Hình 3.1.4: Chuyển <sequence> thành đồ thị có hướng
Trường hợp, ràng buộc điều kiện đối với nhiều hơn hai thành phần <link> cùng đi vào một thành phần nào đó, BPEL quy định sử dụng điều kiện joinCondition, đó là một biểu thức Boolean, chỉ khi nào kết quả của biểu thức trả về giá trị true, thì thành phần hoạt động đi vào mới chuyển sang trạng thái thực thi, ngược lại, thành phần đó sẽ không bao giờ được thực hiện. Có nhiều lý do làm cho giá trị của biểu thức
joinCondition bằng false, có thể luồng xử lý dữ liệu, luồng thực thi của các
<link> gây ra, tuy nhiên, biểu thức joinCondition của nhiều hơn hai thành phần
phần <if>, thì giá trị joinCondition như vậy luôn bằng false. Như vậy, đối với các <link> đi ra từ các nhánh của cùng một thành phần <if>, biểu thức
joinCondition thể hiện phép toán logic AND như $link1 AND $link2 AND…AND
$linkn, thì luôn gây ra lỗi bế tắc chương trình BPEL mà không có cảnh báo trong lập trình bằng công cụ. Tại bước DOM Tree, chương trình ứng dụng phải xét phép toán biểu thức logic của thành phần <joinCondition> thể hiện trong thành phần
<targets>, và các thành phần <target> trong bao đóng của tập <targets>,
các thành phần <source> có thuộc tính linkName có thuộc trong các nhánh của cùng một thành phần <if>.