2. Tầng Điều Phối Tài nguyên (Resource Coordination Layer): nhiệm vụ chính của
4.3.3.1 Thiết kế Mục tiêu thiết kế
Mục tiêu thiết kế
Như đã được trình bày ở phần 1.4 của chương 1, để hỗ trợ việc tự động hóa quá trình khai thác tiến trình BPEL trong ODE, luận án đã xây dựng một công cụ phần mềm với các tính năng sau:
- Tự động kiểm tra tính hợp lệ của tệp tiến trình BPEL và các tệp WSDL liên quan. Nếu tất cả các tệp này đều hợp lệ thì tệp deploy.xml cần thiết sẽ được tạo ra. - Tự động thu thập các tệp cần thiết vào trong thư mục khai thác của ODE và khởi
tạo quá trình biên dịch.
- Lọc và trả về chỉ các thông báo liên quan, hữu ích về các lỗi tiềm năng gắn với quá trình chuẩn bị và biên dịch.
- Đề xuất các giải pháp và các lý do có thể gây ra lỗi. - Hỗ trợ việc tích hợp với trình soạn thảo BPEL.
Nhiệm vụ chính công cụ là tiếp nhận ở đầu vào tệp tiến trình BPEL và các tệp WSDL liên quan (dùng để mô tả cho các dịch vụ Web được gọi), sau đó kiểm tra tính hợp lệ của các tệp này, và cuối cùng tạo ra ở đầu ra là tệp deploy.xml (nếu tất cả các tệp đều hợp lệ), hoặc thông báo lỗi (nếu có tồn tại ít nhất một tệp không hợp lệ) (xem Hình 4-9 mô tả khái quát các chức năng này). Các tệp được coi là hợp lệ nếu chúng thỏa mãn các điều kiện sau:
BPEL
WSDL
deploy.xml Kiểm tra và tạo tệp deploy.xml
- Tệp tiến trình BPEL chính tồn tại và nội dung của nó là hợp lệ. Để kiểm tra tính hợp lệ của nội dung này, công cụ được xây dựng trong luận án chỉ quan tâm đến phần khai báo và sử dụng các Partner Link. Còn việc kiểm tra và biên dịch nội dung của tệp BPEL là trách nhiệm của BPEL engine.
- Với mỗi activity <receive>, <invoke> hay <reply> sử dụng một Partner Link trong tệp BPEL, đòi hỏi một tệp WSDL tương ứng biểu diễn cho Partner Link đó. Do đó, tệp WSDL này cần phải tồn tại và có chứa Partner Link đó. Hơn nữa, nó phải chứa thông tin hợp lệ về tên của service và port (service name and port name).
Hình 4-58: Chức năng chính của công cụ
Các chức năng của công cụ
Các bước thực hiện chính của công cụ được mô tả trong Hình 4-10.
- Bước 1: Kiểm tra các tệp. Bước này kiểm tra sự đầy đủ của các tệp cần thiết. Điều
này có nghĩa là cần có tồn tại ít nhất một tệp BPEL và mỗi Partner Link trong tệp đó yêu cầu phải có ít nhất một tệp WSDL. Công cụ được xây dựng trong luận án chỉ cần có thư mục chứa tất cả các tệp. Nó sẽ tự động phát hiện tệp BPEL và từ tệp này sẽ kiểm tra các tệp WSDL liên quan. Nếu tất cả các tệp cần thiết đều tồn tại thì nó tiếp tục thực hiện bước tiếp theo. Trái lại nó sẽ thông báo lỗi và dừng lại.
- Bước 2: Thu thập tất cả các thông tin cần thiết cho tệp deploy.xml. Cấu trúc của tệp deploy.xml được giới thiệu trong Hình 4-11. Như đã chỉ ra trong Hình 4-10, bước
này cần phải tìm kiếm và lấy ra tên tiến trình (process name) từ tệp BPEL và tất cả các thông tin liên quan đến từng Partner Link trong tiến trình như tên dịch vụ và tên cổng (service name and port name) trong các tệp WSDL. Bước này cũng giúp kiểm tra và tìm ra các lỗi thường gặp như thiếu Partner Link trong tệp BPEL, thiếu tên dịch vụ hay tên cổng trong tệp WSDL,v..v.. Nếu tất cả các thông tin cần thiết là hợp lệ thì nó sẽ chuyển sang bước tiếp theo. Trái lại, nó sẽ thông báo lỗi và dừng lại.
- Bước 3: Tạo tệp deploy.xml. Ghi tất cả các thông tin cần thiết từ bước 2 vào tệp deploy.xml.
1. Kiểm tra các tệp?
2. Thu thập thông tin cần thiết
3. Tạo tệp deploy.xml
4. Hoàn thành việc khai thác
Hợp lệ
Hình 4-60: Cấu trúc của tệp deploy.xml
- Bước 4: Hoàn thành việc khai thác bằng cách copy toàn bộ các tệp cần thiết vào thư
mục khai thác. Thông thường, khi tất cả các tệp đã được tìm thấy trong thư mục này, ODE engine sẽ tự động phát hiện và biên dịch chúng.
4.3.3.2 Cài đặt
Công cụ được xây dựng trong luận án được phát triển dưới dạng một chương trình JAVA. Để chạy chương trình này, yêu cầu có hai tham số, một tham số vào (input) là thư mục chứa tất cả các tệp cần thiết; một tham số ra là tệp deploy.xml nếu tất cả các tệp trong thư mục đầu vào là hợp lệ. Trái lại, nó sẽ hiện thông báo lỗi và giúp tìm nguyên nhân tại sao không thể tạo ra tệp deploy.xml. Để đọc và ghi các tệp BPEL và WSDL mà đều là các tệp có dạng XML, luận án đã sử dụng DOM API (Document Object Model) của JAVA. Thực ra, một loại API khác có thể được sử dụng cho mục đích này là SAX (Simply API for XML). Tuy nhiên, so với SAX, sử dụng DOM không những cho phép thay đổi nội dung của tệp, mà còn thực hiện nhanh và dễ dàng hơn. Đó là do với DOM, nội dung của tệp chỉ cần đọc một lần rồi được lưu vào bộ nhớ trong. Điều này cũng phù hợp với yêu cầu đối với công cụ được xây dựng trong luận án, đó là không cần phải đọc nội dung các tệp nhiều lần.
Công cụ được xây dựng trong luận án đã được kiểm tra với một số chương trình BPEL khác nhau. Với chương trình mà tất cả các tệp là hợp lệ, công cụ đã tạo ra tệp deploy.xml hợp lệ thích hợp và giúp cho chương trình BPEL trở nên sẵn sàng cho việc khai thác và chạy. Công cụ hỗ trợ hai loại tệp WSDL:
- Loại tệp WSDL thông thường: loại tệp này chứa đầy đủ các thông tin về các Partner Link, service và port. Do đó, việc có được các thông tin là hoàn toàn dễ dàng thông qua việc chỉ cần đọc nội dung của một tệp.
- Loại tệp WSDL Wrap: đây là loại tệp mở rộng của kiểu WSDL thông thường. Loại tệp này trích ra phần Partner Link từ tệp WSDL thông thường và bao chúng trong một tệp WSDL mới. Tệp wrap này phải nhập (import) tệp WSDL thông thường. Trong trường hợp có lỗi trong quá trình chạy do có tệp chứa lỗi, công cụ được xây dựng trong luận án sẽ thông báo lỗi và tệp chứa lỗi.
Trong phần tiếp theo, luận án sẽ giới thiệu một ví dụ cụ thể để minh họa việc sử dụng công cụ này. Trong ví dụ này, luận án đã phát triển một tiến trình BPEL (process) mà gọi một Web service từ bên ngoài của WeatherBug để lấy thông tin dự báo thời tiết trên thế giới. Nó được cài đặt bằng công cụ Netbeans 6.1. Hình 4-12 mô tả cấu trúc các tệp của ví dụ.
Hình 4-61: Cấu trúc của các tệp ví dụ.
Tiến trình chính được chứa trong tệp main.bpel, có hai partner link: client và WeatherProvider. Workflow của tiến trình được minh họa trong Hình 4-13.
Hình 4-62: Workflow của tiến trình trong ví dụ.
Trong hai partner link này, client đại diện cho đối tượng sẽ sử dụng tiến trình (là các tiến trình khác hay các dịch vụ Web, v.v..), còn WeatherProvider đại diện cho dịch vụ Web bên ngoài từ WeatherBug. Có thể thấy rằng, có nhiều thao tác trong dịch vụ Web, nhưng trong ví dụ này chỉ sử dụng một thao tác GetLiveCompactWeatherByCityCode(), trả về thông tin thời tiết trực tuyến của một thành phố từ đầu vào là code của thành phố đó.
Sau khi phát triển ví dụ trên, luận án đã dùng công cụ được xây dựng để khai thác nó trong Tomcat Apache phiên bản 5.5. Công cụ được xây dựng trong luận án cần có hai tham số: sourceDir là thư mục chứa toàn bộ tệp nguồn và destDir là thư mục chứa tiến trình được khai thác (nó thường là CATALINA_HOME\webapps\ode\WEB-INF\ processes).
Sau khi chạy công cụ với ví dụ trên, khi không có lỗi nào được phát hiện, một tệp deploy.xml sẽ được tạo ra trong thư mục sourceDir, sau đó toàn bộ các tệp trong thư mục này sẽ được copy sang thư mục destDir, khi đó tiến trình đã sẵn sàng được sử dụng. Hình 4-14 mô tả danh mục các tệp sau khi công cụ của luận án được chạy. Như thấy trong hình, tệp deploy.xml đã được tạo ra.
Hình 4-63: Tệp deploy.xml đã được tạo ra sau khi công cụ được chạy
Cuối cùng, luận án sử dụng công cụ soapUI để kiểm tra tiến trình trong ví dụ. Kết quả chạy được thể hiện ở Hình 4-15. Bên cửa sổ bên trái là city code của thành phố Melbourne, Australia, đầu vào của tiến trình. Còn cửa sổ bên phải là thông tin thời tiết hiện tại của thành phố đó.