3. Hướng nghiên cứu của đề tài
2.3.1. Khái niệm trình xử lý BPEL
Như đã giới thiệu trong phần 2.1, BPEL là ngôn ngữ để mô hình hóa quy trình nghiệp vụ và kết hợp các dịch vụ đơn lẻ thành một quy trình thống nhất. Sau khi quy trình được tạo ra, nó sẽ được triển khai trên trình xử lý BPEL là công cụ thực thi và cụ thể hóa quy trình đó.
Trình xử lý BPEL được định nghĩa là: ―Trình xử lý BPEL là một trình xử lý luồng công việc mà thực thi các tiến trình được đặc tả bằng ngôn ngữ BPEL‖ hoặc ―Trình xử lý BPEL là một thành phần phần mềm có khả năng biên dịch ngôn ngữ BPEL‖.
Theo định nghĩa trên, trình xử lý BPEL không hoạt động độc lập mà là một thành phần phần mềm trong kiến trúc của BPEL. Kiến trúc của BPEL bao gồm 03 thành phần chính là: trình thiết kế BPEL, mẫu tiến trình BPEL và trình xử lý BPEL
Hình 2.23 Mô hình kiến trúc BPEL
Trong kiến trúc trên, những chuyên viên hay những người phân tích nghiệp vụ của công ty sẽ sử dụng trình thiết kế (với giao diện đồ họa) để định nghĩa tiến trình nghiệp vụ. Một tiến trình nghiệp vụ được hiểu là một kịch bản nhằm thực hiện một chức năng nào đó ví dụ như ―Đặt hàng‖, ―Thanh toán hóa đơn‖… Trong quá trình thiết kế, tiến trình này có thể gọi các dịch vụ Web khác để kết hợp và đưa vào luồng tiến trình. Sau khi chuyên viên nghiệp vụ hoàn thành luồng tiến trình nghiệp vụ, một mẫu tiến trình logic bao gồm luồng công việc sẽ được trình thiết kế tự động sinh ra. Mẫu tiến trình này sẽ hiển thị dưới dạng mã nguồn BPEL và được thực thi bởi trình xử lý BPEL.
Trình thiết kế BPEL
Trình thiết kế BPEL được sử dụng để định nghĩa các tiến trình nghiệp vụ, thường độc lập với các nền tảng ứng dụng. Đây là công cụ hỗ trợ đắc lực cho những chuyên viên nghiệp vụ để định nghĩa các tiến trình mà không cần biết sâu về kỹ thuật. Sau khi thiết kế xong, nó sẽ tự động sinh ra mẫu tiến trình logic dưới dạng mã nguồn BPEL.
Mẫu tiến trình logic
Mẫu tiến trình logic có định dạng theo đặc tả BPEL. Mẫu tiến trình này được sinh ra bởi trình thiết kế BPEL và thực thi bởi trình xử lý BPEL. Hình dưới đây ví dụ mẫu tiến trình HelloWorld đơn giản. Tiến trình này sẽ nhận tên đầu vào qua tác vụ Receive, sau đó tạo thành một chuỗi ký tự qua tác vụ Assign, và cuối cùng trả về kết quả qua tác vụ Reply.
Hình 2.24 Mẫu tiến trình logic
Trình xử lý BPEL
Nhiệm vụ của trình xử lý BPEL là thực thi bất cứ mẫu tiến trình logic nào theo chuẩn BPEL. Trong quá trình thực hiện, nó sẽ gọi các dịch vụ Web, ánh xạ dữ liệu với các thông điệp, xử lý lỗi, đảm bảo giao dịch toàn vẹn và tính bảo mật. Trình xử lý BPEL thường được tích hợp với các máy chủ ứng dụng (Application Server). Hiện nay có rất nhiều các sản phẩm trình xử lý BPEL mang tính thương mại hoặc mã nguồn mở, tuy nhiên không có một kiến trúc chung nào được sử dụng, cũng như không có một chuẩn thiết kế nào mà một trình xử lý BPEL tuân theo. Bảng sau liệt kê danh sách các trình xử lý BPEL hiện nay:
Hình 2.25 Bảng Danh sách các trình xử lý BPEL hiện nay 2.3.2. Kiến trúc một số trình xử lý tiêu biểu
Apache ODE
Apache ODE thực thi các tiến trình nghiệp vụ được viết theo chuẩn BPEL. Tiến trình sẽ giao tiếp với các dịch vụ Web, gửi và nhận thông điệp, điều khiển thao tác dữ liệu và phục hồi sau lỗi. ODE hỗ trợ thực thi cả những tiến trình có vòng đời khác nhau để kết hợp tất cả các dịch vụ tạo nên ứng dụng người dùng.
Apache ODE hỗ trợ chuẩn WS-BPEL 2.0 mới nhất của OASIS và cả chuẩn cũ BPEL4WS 1.1. ODE hỗ trợ 2 lớp giao tiếp: lớp thứ nhất dựa trên Axis2 (giao thức http), và lớp thứ hai dựa trên chuẩn JBI (sử dụng ServiceMix). Để liên kết với các dịch vụ bên ngoài, ODE hỗ trợ chuẩn kết nối qua giao tiếp WSDL hoặc cho phép gọi các dịch vụ Web kiểu REST. ODE cũng cung cấp các API để trình xử lý BPEL có thể tích hợp với các lớp giao tiếp khác. Các ứng dụng dịch vụ Web có thể triển khai từ trình thiết kế hoặc qua giao diện quản trị dạng Web. Để mô hình hóa các tiến trình bằng ngôn ngữ BPEL, ODE sử dụng trình thiết kế Eclipse. Trình thiết kế BPEL được phát triển như là module tích hợp vào công cụ Eclipse, vì thế sau khi cài đặt xong Eclipse, người dùng cần phải tải về bổ sung module BPEL Visual Designer [5].
Hình 2.26 Trình thiết kế của Apache ODE trên nền tảng Eclipse
Mục đích của Apache Foundation khi thiết kế ODE là để tạo ra một module tin cậy, đóng gói và dễ dàng tích hợp để quản lý việc thực thi của các tiến trình nghiệp vụ sử dụng ngôn ngữ BPEL. Sản phẩm tập trung vào phát triển các module
nhỏ với tính độc lập cao mà có thể được triển khai trên các hệ thống quản trị tiến trình nghiệp vụ (Business Process Management System).
Các thành phần chính trong kiến trúc của ODE trong hình dưới bao gồm bộ biên dịch ODE BPEL, trình chạy các ứng dụng BPEL, các đối tượng truy cập dữ liệu, các lớp tích hợp và các công cụ người dùng. Mô hình quan hệ mức cao giữa các thành phần được mô tả trong hình dưới. Có thể tổng kết lại là ―Bộ biên dịch sẽ chuyển đổi mã nguồn BPEL sang dạng có thể thực thi được. Quá trình thực thi sẽ giao tiếp với CSDL thông qua DAO, và giao tiếp với môi trường bên ngoài thông qua lớp tích hợp‖.
Hình 2.27 Kiến trúc của Apache ODE
Bộ biên dịch có trách nhiệm chuyển đổi từ mã nguồn BPEL sang thành mã nguồn có thể thực thi được. Đầu ra của bộ biên dịch có thể là một mã nguồn tốt hoặc một danh sách các thông báo lỗi. File biên dịch sinh bởi bộ biên dịch là một mô hình đối tượng tương tự với cấu trúc trong file tiến trình BPEL. Tuy nhiên, file biên dịch này thực tế chứa nhiều tên tham chiếu (ví dụ các biến), các liên kết WSDL, các kiểu
biến, và các cấu trúc khác nhau. File biên dịch này thường có đuôi mở rộng là .cbp, là đầu vào không thể thiếu của trình chạy ứng dụng BPEL (BPEL runtime).
Trình chạy ứng dụng được thiết kế trong module BPEL - Tuntime nhằm hỗ trợ việc thực thi của các tiến trình sau khi đã biên dịch. Trình chạy này sẽ thực hiện các thao tác của tiến trình thông qua việc thực thi các cấu trúc của nó. Trong lúc chạy, module này sẽ tạo thêm đối tượng mới nếu cần và gửi thông điệp tới các đối tượng. Cuối cùng, trình chạy này sẽ thực thi các hàm API để tương tác với bộ lõi của BPEL.
Để có thể thực hiện được đầy đủ một tiến trình trong mọi môi trường, trình chạy dựa trên thành phần DAO (các đối tượng truy cập dữ liệu) giúp duy trì hoạt động của nó. Việc thực thi của những DAO này có thể được tùy biến nhưng nhìn chung được cung cấp bởi một CSDL quan hệ. Quá trình thực thi các cấu trúc BPEL ở mức đối tượng được thực hiện dựa trên nền tảng kỹ thuật Java Concurrent Object (Jacob). Jacob cung cấp cơ chế thực hiện đồng thời ở mức ứng dụng và cơ chế trong suốt để ngắt và duy trì trạng thái thực thi. Jacob là phần quan trọng trong mô hình thực thi đồng thời ACTORS. Jacob còn cung cấp một máy ảo cho việc thực thi các cấu trúc BPEL.
DAO thực hiện tương tác giữa các trình chạy BPEL và kho lưu trữ dữ liệu phía dưới. Thông thường, dữ liệu được lưu trữ dưới dạng một CSDL quan hệ. Trong trường hợp này, DAO sẽ thực thi thông qua thư viện truy cập dữliệu OpenJPA. Trình chạy BPEL yêu cầu DAO các ràng buộc sau:
Các đối tượng đang hoạt động – Theo dõi đối tượng nào vừa được tạo. Định hướng thông điệp – Đối tượng nào đang đợi thông điệp nào. Các biến – Giá trị của các biến cho mỗi đối tượng.
Liên kết ngoài – giá trị của các liên kết ngoài cho mỗi đối tượng.
Trạng thái thực thi của tiến trình – Chuỗi các trạng thái liên tiếp của máy ảo Java.
Trình chạy BPEL không tồn tại một mình mà nó có thể thực hiện các tác động với bên ngoài. Các lớp tích hợp được liên kết với trình chạy để thực hiện nhiệm vụ này. Ví dụ, có những lớp tích hợp riêng cho AXIS2 hay JBI. Chức năng cơ bản của lớp tích hợp là nhằm cung cấp các kênh giao tiếp cho trình chạy. Lớp
tích hợp AXIS2 sử dụng các thư viện của AXIS2 để giao tiếp với trình chạy thông qua giao tiếp Dịch vụ Web. Còn lớp tích hợp JBI sử dụng cơ chế gắn trình chạy vào trục tích hợp JBI. Bên cạnh việc giao tiếp, lớp tích hợp còn cung cấp cơ chế lập lịch và quản lý vòng đời của trình chạy.
Hai trong số những thách thức khó nhất trong việc thực thi của trình chạy BPEL là duy trì trạng thái thực thi của tiến trình và quản lý thực thi đồng thời. ODE sử dụng nền tảng Jcob để quản lý hai vấn đề này. Cách tiếp cận của Jcob lấy ý tưởng từ cách tiếp cận của actor modelvà process elgebra. Thông qua Jacob, ODE duy trì trạng thái của tiến trình như là một tập các đối tượng được kết nối bằng một kênh truyền thông điệp. Khi một đối tượng nhận một thông điệp, nó có thể tạo các kênh và đối tượng mới và gửi thông điệp, thực thi đồng thời được quản lý bởi vệcsử dụng các thông điệp trong mô hình đơn luồng.
ActiveVOS
Công ty Active Endpoints được thành lập từ năm 2003, là nhà cung cấp hàng đầu cho các giải pháp BPEL và các sản phẩm SOA khác. ActiveEndpoints có những sản phẩm BPEL nổi tiếng như trình thiết kế và trình xử lý ActiveBPEL, được hàng triệu lập trình viện và các tổ chức sử dụng. Trình thiết kế ActiveBPEL là công cụ để tạo các tiến trình BPEL và xuất ra tiến trình mẫu để chạy trên trình xử lý BPEL. Trình xử lý BPEL của Active Enpoints có thể chạy trên cả những phần mềm mã nguồn mở - Tomcat, hay những phần mềm thương mại như WebLogic, WebSphere. Hình dưới đây mô tả tổng quan bộ sản phẩm của Active BPEL.
Trình thiết kế ActiveBPEL được cấu hình như là module gắn vào công cụ quen thuộc Eclipse. Với giao diện thân thiện và quen thuộc với người lập trình, trình thiết kế này hỗ trợ người lập trình cách thiết kế theo phương pháp từ trên xuống hay từ dưới lên. Active BPEL Designer thiết kế sẵn các biểu tượng cho các đối tượng của BPEL (như các Activities, Handlers) để người phát triển có thể kéo thả vào vùng thiết kế. Sau đó, trình thiết kế Active BPEL sẽ tự động sinh ra các mã nguồn BPEL và các định nghĩa cho các tiến trình BPEL. Mọi thay đổi trên giao diện thiết kế sẽ được ghi nhận thành mẫu tiến trình theo ngôn ngữ BPEL và ngược lại. Các dịch vụ bên ngoài sẽ được liệt kê trong phần Web References (ví dụ như WSDL) giúp người dùng dễ dàng trong việc tạo một sơ đồ tiến trình từ các định nghĩa WSDL. Ngoài ra, người dùng có thể tự thiết kế thêm các đối tượng của riêng mình dưới dạng đối tượng BPELets, và thêm vào bảng đối tượng để có thể sử dụng lại. BPEL Designer không chỉ làm nhiệm vụ thiết kế mà còn cho phép người dùng biên dịch, đóng gói và triển khai ứng dụng lên trên các hệ thống mà không cần phải truy cập trực tiếp vào hệ thống đó. Ngoài ra, người phát triển cũng có thể mô phỏng thao tác của các tiến trình mà không cần phải chạy trực tiếp trên hệ thống thật. Trong quá trình mô phỏng, BPEL Designer cho phép giả định đầu vào để người phát triển có thể thực hiện các kịch bản kiểm thử khác nhau.
Máy chủ Active BPEL có nhiệm vụ thực thi các tiến trình đã được thiết kế từ trước. Các máy chủ này hỗ trợ cơ chế cân bằng tải, máy chủ cụm, và khả năng chịu lỗi, đem lại độ tin cậy và hiệu năng cao. Màn hình quản trị giao diện Web cho phép thực hiện các công việc quản trị tiến trình, giám sát và phân tích từ bất kỳ đâu.
Hình 2.30 Kiến trúc tổng quan của ActiveVOS Server
Kiến trúc của trình xử lý BPEL như trong hình 2.30 trên bao gồm bốn thành phần: Trình xử lý trung tâm, module triển khai, module các dịch vụ, mô module quản trị. Phần quan trọng nhất trong kiến trúc của ActiveVOS là bộ xử lý trung tâm ActiveVOS. Nhiệm vụ của nó là xác định, đánh giá và thực thi các mẫu tiến trình viết bằng ngôn ngữ BPEL. Thành phần thứ 2 là các trình quản lý máy chủ bao gồm: quản lý cảnh báo, cấu hình cụm, triển khai, các tiến trình, hàng đợi, lưu trữ, nhiệm vụ và xử lý các sự kiện phức tạp. Thành phần nền tảng thứ 3 đóng vai trò quan trọng trong việc giao tiếp với các hệ thống khác, thông qua việc hỗ trợ các giao thức như: WS, JMS, POJO, REST...Ngoài ra trên ActiveVOS còn có các tiện ích và dịch vụ khác như: Quản lý thời gian, ánh xạ URN, định danh dịch vụ, nhắn tin qua Email. Module quản trị qua giao diện Web hỗ trợ người dùng có thể giám sát và quản lý hệ thống ở bất cứ đâu.
Trình xử lý trung tâm (Process Engine) có nhiệm vụ biên dịch ngôn ngữ BPEL thành ngôn ngữ máy có thể thực thi được. Nó cũng sẽ tạo ra các tiến trình và quản lý vòng đời hoạt động của nó. Các yêu cầu gửi đến cho tiến trình sẽ được quản lý trong hàng đợi để đảm bảo tất cả đều được xử lý. Trong quá trình thực thi nếu có lỗi thì trình xử lý sẽ đưa ra các cảnh báo nếu có. Trong quá trình thực hiện, mọi thông tin sẽ được lưu lại vào CSDL.
Các tiến trình (Process) được tạo ra sẽ giao tiếp với trình xử lý thông qua định dạng chuẩn hoặc trực tiếp qua API. Các tiến trình này sẽ dựa vào mẫu tiến trình (file BPEL) để tạo ra các lớp thực hiện. Các lớp sẽ thực hiện các tác vụ như invoke, receive, response, assign … có trong file mẫu tiến trình. Trong quá trình thực hiện, các lớp sẽ sinh ra các thông báo sự kiện khi gặp lỗi và tự dẫn xuất trong phạm vi tác vụ nếu cần.
ActiveVOS cho phép cài đặt nhiều ngôn ngữ thể hiện biểu thức (Expression Processing). Trước hết, ngôn ngữ biểu thức cần đăng ký một không gian tên (namespace) trong tiến trình BPEL để người phát triển có thể sử dụng được trong tiến trình đó. Sau khi đăng ký, ngôn ngữ biểu thức sẽ thực hiện trong cả quá trình thiết kế và thực thi. ActiveVOS hỗ trợ sẵn ba kiểu ngôn ngữ biểu thức là Xpath, Xquery và JavaScript. ActiveVOS hỗ trợ nhiều hình thức triển khai ứng dụng (Deployment Plan): có thể sử dụng màn hình Admin Console để triển khai file. BPR, hoặc từ trình thiết kế deploy lên server được cấu hình sẵn. File nén BPR chứa toàn bộ tiến trình và các mô tả triển khai (file PDD – Process Deployment Descriptor) cũng như các tài nguyên khác như file WSDL, Schema và Style Sheets. Khi triển khai, ActiveVOS tự nhận ra các dẫn xuất hoặc nhập từ các nguồn khác (ví dụ như các dịch vụ Web bên ngoài). Các ứng dụng dịch vụ Web được đánh dấu phiên bản để quản lý thay đổi, giúp cho người quản trị có thể kiểm soát được những thay đổi về ứng dụng và các tài nguyên tương ứng. Ứng dụng khi được triển khai sẽ có ba trạng thái: Online, Offline và Offline Pending. Tại một thời điểm, chỉ có một phiên bản của ứng dụng ở trạng thái Online, còn Offline Pending là trạng thái mà tiến trình đó đang chạy hoặc các tiến trình Online khác đang tham chiếu đến nó.
Khi cài đặt, trình thiết kế ActiveVOS đã có sẵn máy chủ ứng dụng Tomcat, được sử dụng để triển khai ứng dụng với mục đích kiểm thử. Người phát triển có thể chạy ngay máy chủ Tomcat từ trình thiết kế hoặc chạy riêng từ thư mục gốc của Tomcat. Để lưu thông tin các tiến trình và quá trình hoạt động, ActiveVOS sử dụng