Tài liệu So sánh hiệu năng của các trình xử lý BPEL

-5- MỤC LỤC LỜI CAM ĐOAN ............................................................................................................1 LỜI CẢM ƠN ..................................................................................................................4 MỤC LỤC .......................................................................................................................5 DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT .....................................................7 DANH MỤC CÁC BẢNG ..............................................................................................8 DANH MỤC CÁC HÌNH VẼ .........................................................................................9 LỜI GIỚI THIỆU ..........................................................................................................11 Chƣơng 1: TỔNG QUAN VỀ KIẾN TRÚC HƢỚNG DỊCH VỤ VÀ NGÔN NGỮ BPEL .............................................................................................................................13 1.1Tổng quan về kiến trúc hƣớng dịch vụ .................................................................13 1.1.1Kiến trúc hƣớng dịch vụ .................................................................................13 1.1.2Dịch vụ Web ...................................................................................................13 1.2Kết hợp dịch vụ .....................................................................................................15 1.3 Ngôn ngữ BPEL ...................................................................................................16 1.3.1Giới thiê ̣u ........................................................................................................16 1.3.2Nguyên tắ t hoa ̣t đô ̣ng của mô ̣t tiế n trin ̀ h BPEL ..............................................17 1.3.3Cấ u trúc của mô ̣t tiế n trình BPEL...................................................................19 1.3.4Các thành phần và ký hiệu trong BPEL .........................................................19 1.3.5Quản lý các ngoại lệ và các biến ....................................................................30 1.3.6Xử lý lỗi ..........................................................................................................31 Chƣơng 2: KIẾN TRÚC CÁC TRÌNH XỬ LÝ BPEL .................................................32 2.1 Khái niệm trình xử lý BPEL ................................................................................32 2.2 Kiến trúc một số trình xử lý tiêu biểu .................................................................35 2.2.1 Apache ODE ..................................................................................................35 2.3.2 ActiveVOS .....................................................................................................38 2.3.3 Oracle BPEL Process Manager .....................................................................41 Chƣơng 3: ĐÁNH GIÁ HIỆU NĂNG CỦA MỘT SỐ TRÌNH XỬ LÝ BPEL ...........47 3.1 Mô hình đo hiệu năng cho trình xử lý BPEL ......................................................47 3.2 Xây dựng hệ thống đo đạc .................................................................................48 3.2.1 Bài toán đo hiệu năng các trình xử lý BPEL .................................................48 3.2.2 Cài đặt trình xử lý BPEL ...............................................................................48 3.2.3 Xây dựng ứng dụng dịch vụ Web ..................................................................49 -63.2.4 Triển khai công cụ đo ....................................................................................52 3.3 Thực hiện đo ........................................................................................................55 3.4 So sánh và đánh giá hiệu năng từ kết quả đo đạc ...............................................57 3.4.1 Đánh giá hiệu năng các trình xử lý ................................................................57 3.4.2 So sánh thời gian xử lý của các trình BPEL ..................................................60 3.5 So sánh các yếu tố kỹ thuật khác .........................................................................64 KẾT LUẬN ...................................................................................................................66 TÀI LIỆU THAM KHẢO .............................................................................................67 -7- DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT Thuật ngữ CSDL Web Service BPEL WSDL Activity SOA (Service Oriented Architecture) XPath WS-Addressing XML Schema Process OASIS (Organization for the Advancement of Structured Information Standards) Axis2 Chú giải Cơ sở dữ liệu Dịch vụ Web Ngôn ngữ thực thi tiến trình nghiệp vụ Ngôn ngữ định nghĩa dịch vụ Tác vụ Kiến trúc hƣớng dịch vụ Mô tả thuộc tính và phần tử của đối tƣợng XML Đặc tả xác định dịch vụ Web và thông điệp Đặc tả đối tƣợng theo định dạng XML Tiến trình nghiệp vụ Tổ chức vì sự phát triển của các chuẩn thông tin có cấu trúc Là nền tảng dịch vụ Web, dùng để tạo và cài đặt các ứng dụng Web Service Giao thức truyền trạng thái REST (Representational State Transfer) API (Application Programming Giao diện lập trình ứng dụng Interface) Apache ServiceMix Là công cụ mã nguồn mở để kết nối các dịch vụ Web trong kiến trúc hƣớng dịch vụ JBI (Java Business Integration) Là đặc tả hỗ trợ việc giao tiếp các ứng dụng trong kiến trúc hƣớng dịch vụ DAO Đối tƣợng truy cập dữ liệu Jacob Java Concurrent Object Tomcat Máy chủ ứng dụng mã nguồn mở của Apache Jboss Máy chủ ứng dụng mã nguồn mở của Tổ chức JBoss WebSphere Máy chủ ứng dụng của hãng IBM Weblogic Máy chủ ứng dụng của hãng Oracle POJO (Plain Old Java Object) Đối tƣợng Java thông thƣờng JMS (Java Message Service) API giao tiếp cho phép truyền nhận thông điệp theo cơ chế point-to-point JSON (Java Script Object Chuẩn định dạng dữ liệu đi kèm với Javascript Notation) XML (Extensible Markup Ngôn ngữ đánh dấu mở rộng Language) JCA (Java EE Connector Giải pháp để kết nối các ứng dụng đóng gói và các Architecture) hệ thống ứng dụng B2B (Business To Business) Mô hình kinh doanh thƣơng mại điện tử giữa các doanh nghiệp -8- DANH MỤC CÁC BẢNG Bảng 1.1 Các tác vụ trong ngôn ngữ WS-BPEL 2.0 .....................................................20 Bảng 2.1 Danh sách các trình xử lý BPEL hiện nay .....................................................34 Bảng 3.1 Danh sách các công cụ triển khai của các trình xử lý nhƣ sau: .....................49 Bảng 3.2 Danh sách các ứng dụng dịch vụ Web ...........................................................50 Bảng 3.3 Thông điệp gửi yêu cầu đến Dịch vụ Web.....................................................54 Bảng 3.4 Bảng thống kê tỉ lệ lỗi của ActiveVOS ..........................................................58 Bảng 3.5 Bảng thống kê tỉ lệ lỗi của Apache ODE .......................................................59 Bảng 3.6 Bảng so sánh các tính năng kỹ thuật của các trình xử lý BPEL ....................64 -9- DANH MỤC CÁC HÌNH VẼ Hình 1.1 Mô hình cộng tác hƣớng dịch vụ ....................................................................13 Hình 1.2 Kết hợp các ứng dụng theo kiến trúc SOA trong một hệ thống ngân hàng ...15 Hình 1.3 Ví dụ về một tiến trình BPEL .........................................................................17 Hình 1.4 Ví dụ về kiểu liên kết ngoài - PartnerLink Type ............................................18 Hình 1.5 Ví dụ về liên kết ngoài - PartnerLink .............................................................18 Hình 1.6 Cấu trúc file BPEL .........................................................................................19 Hình 1.7 Cấu trúc XML của receive .............................................................................21 Hình 1.8 Ví dụ về trƣờng hợp sử dụng invoke ..............................................................22 Hình 1.9 Cấu trúc XML của invoke ..............................................................................22 Hình 1.10 Trƣờng hợp sử dụng của Reply ....................................................................23 Hình 1.11 Cấu trúc XML của Reply .............................................................................23 Hình 1.12 Trƣờng hợp sử dụng của Validate ................................................................24 Hình 1.13 Cấu trúc XML của Assign ............................................................................25 Hình 1.14 Trƣờng hợp sử dụng của Throw ...................................................................25 Hình 1.15 Trƣờng hợp sử dụng của ReThrow ..............................................................26 Hình 1.16 Cấu trúc XML của Flow ...............................................................................27 Hình 1.17 Cấu trúc XML của Repeat Until ...................................................................27 Hình 1.18 Trƣờng hợp sử dụng của Pick ......................................................................28 Hình 1.19 Cấu trúc XML của If ....................................................................................28 Hình1.20 Cấu trúc XML của Flow ................................................................................28 Hình 1.21 Trƣờng hợp sử dụng của Foreach .................................................................29 Hình 1.22 Cấu trúc XML của Foreach ..........................................................................29 Hình 1.23 Cấu trúc XML của While .............................................................................30 Hình 1.24 Trƣờng hợp sử dụng của Scope ....................................................................30 Hình 2.1 Mô hình kiến trúc BPEL.................................................................................32 Hình 2.2 Mẫu tiến trình logic ........................................................................................33 Hình 2.3 Trình thiết kế của Apache ODE trên nền tảng Eclipse...................................35 Hình 2.4 Kiến trúc của Apache ODE ............................................................................36 Hình 2.5 Bộ sản phẩm ActiveVOS................................................................................38 Hình 2.6 Trình thiết kế ActiveVOS ...............................................................................39 Hình 2.7 Kiến trúc tổng quan của ActiveVOS Server ..................................................39 Hình 2.8 Mối quan hệ của Oracle BPEL Process Manager với các thành phần khác ..42 Hình 2.9 Kiến trúc của Oracle BPEL Process Manager................................................43 Hình 2.10 Trình thiết kế Jdeveloper cho Oracle BPEL Process Manager ....................45 Hình 3.1 Mô hình đo hiệu năng trình xử lý BPEL ........................................................48 Hình 3.2 Giao diện thiết kế mô phỏng tác vụ If-else dùng trình thiết kế Eclipse .........51 Hình 3.3 File WSDL thể hiện giao tiếp với dịch vụ Web .............................................52 Hình 3.4 Kết quả đo bằng Jmeter ..................................................................................53 Hình 3.5 Cấu hình ngƣời dùng sử dụng Thread Group .................................................54 Hình 3.6 Cấu hình phép thử với dịch vụ Web ...............................................................55 - 10 Hình 3.7 Mô hình đo hiệu năng của trình xử lý BPEL..................................................56 Hình 3.8 Cấu hình think time cho phép đo dịch vụ Web ..............................................56 Hình 3.10 Biểu đồ thời gian trả về trung bình của Oracle BPEL Process Manager .....57 Hình 3.11 Biểu đồ thời gian trả về trung bình của ActiveVOS ....................................58 Hình 3.12 Biểu đồ thời gian trả về trung bình của Apache ODE ..................................59 Hình 3.13 So sánh thời gian phản hồi trung bình và lớn nhất của tác vụ While ...........60 Hình 3.14 So sánh thời gian phản hồi trung bình và lớn nhất của tác vụ Flow ............61 Hình 3.15 So sánh thời gian phản hồi trung bình và lớn nhất của tác vụ FlowDep ......61 Hình 3.16 So sánh thời gian phản hồi trung bình và lớn nhất của tác vụ Sequence .....62 Hình 3.17 So sánh thời gian phản hồi trung bình và lớn nhất của tác vụ If-else ..........62 Hình 3.18 So sánh thời gian phản hồi trung bình và lớn nhất của tác vụ Invoke .........63 - 11 - LỜI GIỚI THIỆU Ngày nay, các ứng dụng công nghệ thông tin trong doanh nghiệp có nghiệp vụ ngày càng phức tạp, thƣờng xuyên đòi hỏi những ứng dụng mới đáp ứng những thay đổi nghiệp vụ trong thế giới cạnh tranh. Với số lƣợng các ứng dụng phát triển ngày càng nhiều đòi hỏi phải có công nghệ để có thể kết hợp những hệ thống cũ và mới. Kiến trúc hƣớng dịch vụ (Service-Oriented Architecture - SOA) ra đời nhằm giải quyết bài toán đó thông qua việc phối hợp các dịch vụ đơn lẻ và các hệ thống có sẵn thành một quy trình thống nhất. Dịch vụ Web (Web Service) là một trong những công nghệ đƣợc dùng để hiện thực hóa kiến trúc hƣớng dịch vụ. Trong công nghệ này ngƣời ta sử dụng ngôn ngữ BPEL (hay còn gọi là WS-BPEL) để xây dựng và thực thi các tiến trình nghiệp vụ. Phiên bản mới nhất của BPEL làWS-BPEL 2.0, là ngôn ngữ để mô hình hóa các tiến trình nghiệp vụ cho các ứng dụng theo kiến trúc hƣớng dịch vụ. Các tiến trình xây dựng trên nền ngôn ngữ BPEL ngoài các phép toán cấu trúc thông thƣờng còn có các lời gọi đến các dịch vụ bên ngoài để thực thi các chức năng. Kiến trúc SOA sử dụng chuẩn giao tiếp WSDL để kết nối với các ứng dụng khác, chính vì thế các hệ thống cũ không cần sửa đổi nhiều để kết nối với các ứng dụng mới. Tiến trình BPEL sau khi đƣợc xây dựng xong sẽ thực thi trên các trình xử lý BPEL (BPEL engines). Tốc độ thực hiện của các tiến trình hay các ứng dụng này phụ thuộc vào hiệu năng của các trình xử lý. Vì thế, việc lựa chọn một trình xử lý BPEL phù hợp với yêu cầu hoạt động của ứng dụng là một bài toán khó đối với các doanh nghiệp đòi hỏi phải có những so sánh và đánh giá chính xác hiệu năng của các trình xử lý BPEL. Xuất phát từ yêu cầu thực tế trên, luận văn sẽ tiến hành đo đạc, so sánh và đánh giá hiệu năng của một số trình xử lý BPEL thông dụng hiện nay. Luận văn sẽ sử dụng phƣơng pháp định lƣợng trong đó sử dụng các công cụ để đo đạc thời gian phản hồi của các trình xử lý BPEL khi cùng thực hiện một tác vụ (Activities). Kết quả đo đạc sẽ đƣợc phân tích để đƣa ra những đánh giá chính xác về hiệu năng, cũng nhƣ đƣa ra những lời khuyến cáo cho ngƣời dùng khi lựa chọn một trình xử lý BPEL cụ thể. Cấu trúc của luận văn bao gồm 03 chƣơng: Chương 1 nghiên cứu tổng quan về kiến trúc SOA và ngôn ngữ WS-BPEL 2.0, Chương 2 tìm hiểu kiến trúc các trình xử lý BPEL, Chương 3 đo đạc và đánh giá hiệu năng của một số trình xử lý BPEL. Phần Kết luận đánh giá những kết quả đã đạt đƣợc của luận văn và hƣớng phát triển của luận văn trong tƣơng lai. Trong Chương 1, luận văn nghiên cứu lý thuyết kiến trúc SOA, trong đó tập trung vàocông nghệ dịch vụ Web cho phép xây dựng quy trình nghiệp vụ từ các dịch vụ đơn lẻ và các ứng dụng trên nền tảng và công nghệ khác sử dụng ngôn ngữ WS-BPEL 2.0. Ngôn ngữ WS-BPEL 2.0 có những tác vụ cấu trúc dùng để mô tả hoạt động nghiệp vụ, và những tác vụ có khả năng gọi các dịch vụ bên ngoài thông qua dịch vụ Web. Những - 12 tác vụ này đóng vai trò quan trọng, ảnh hƣởng đến hiệu năng hoạt động của các tiến trình nghiệp vụ. Chương 2 tìm hiểu kiến trúc hoạt động chung của BPEL với 03 thành phần chính: Trình thiết kế BPEL, mẫu tiến trình theo chuẩn ngôn ngữ WS-BPEL 2.0 và trình xử lý BPEL. Có rất nhiều các trình xử lý BPEL hiện nay, tuy nhiên chúng ta sẽ lựa chọn tìm hiểu 03 trình xử lý tiêu biểu: Apache ODE, ActiveVOS và Oracle BPEL Manager. Việc nghiên cứu kiến trúc của các trình xử lý này sẽ giúp chúng ta có đƣợc cái nhìn tổng quan về kiến trúc cũng nhƣ hiểu đƣợc cách thức làm việc của các trình xử lý. Chương 3 sử dụng phƣơng pháp đo đạc định lƣợng trong đó triển khai các trình xử lý và sử dụng các công cụ để đo thời gian thực hiện của chúng. Trong phạm vi luận văn này, tác giả sẽ lựa chọn các tác vụ cơ bản và quan trọng nhất của ngôn ngữ WS-BPEL: If-else, Flow, FlowDep (flow dùng link), While, Sequence, Invoke để đánh giá hiệu năng của các trình xử lý BPEL. Các ứng dụng dịch vụ Web sẽ đƣợc xây dựng để mô phỏng từng tác vụ trên, sau đó đƣợc triển khai trên từng trình xử lý với cấu hình cài đặt mặc định. Tiếp theo, công cụ đo tự động Apache Jmeter sẽ đƣợc sử dụng để thực hiện đo thời gian phản hồi khi gửi các yêu cầu đến trình xử lý. Số lƣợng các yêu cầu sẽ tăng dần, tƣơng ứng với số lƣợng ngƣời dùng tăng lên từ 1,2… 500. Kết quả đo đạc sẽ đƣợc lƣu lại để phân tích, so sánh và đánh giá. Sau khi tiến hành đo đạc và phân tích, luận văn đã đạt đƣợc một số kết quả so sánh hiệu năng nhất định giữa các trình xử lý. Từ đó, luận văn đƣa ra những kết luận về hiệu năng đồng thời đƣa ra những khuyến cáo cho ngƣời dùng khi lựa chọn một trình xử lý BPEL cho ứng dụng của mình. Về hƣớng phát triển của luận văn trong tƣơng lai, tác giả sẽ tiếp tục thực hiện đánh giá trình xử lý BPEL trên các môi trƣờng khác nhau: hệ điều hành, máy chủ ứng dụng, CSDL khác nhau…nhằm đem lại kết quả so sánh tổng hợp, đầy đủ thông tin và chính xác nhất về hiệu năng của các trình xử lý BPEL. - 13 - Chương 1: TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ VÀ NGÔN NGỮ BPEL Trong chƣơng này, chúng ta sẽ đi tìm hiểu những nét tổng quan về kiến trúc hƣớng dịch vụ, công nghệ Web Service và ngôn ngữ thực thi tiến trình nghiệp vụ BPEL. 1.1 Tổng quan về kiến trúc hướng dịch vụ 1.1.1 Kiến trúc hướng dịch vụ Kiến trúc hƣớng dịch vụ, đƣợc định nghĩa là 'Khái niệm về hệ thống trong đó mỗi ứng dụng được xem như một nguồn cung cấp dịch vụ'[20].Nói theo một cách đơn giản thì kiến trúc hƣớng dịch vụ (SOA) là một hƣớng tiếp cận với việc thiết kế và tích hợp các phần mềm, chức năng, hệ thống theo dạng module và có khả năng truy cập thông qua môi trƣờng mạng. Hệ thống theo chuẩn SOA là một tập hợp các dịch vụ đƣợc chuẩn hóa trên mạng trao đổi với nhau trong ngữ cảnh một tiến trình nghiệp vụ. Sự cộng tác trong kiến trúc SOA[20] đƣợc mô tả nhƣ sau: Hình 1.1Mô hình cộng tác hƣớng dịch vụ Trong mô hình trên, nhà cung cấp dịch vụ cần cung cấp thông tin về dịch vụ của mình cho một nơi lƣu trữ thông tin dịch vụ. Nơi này lƣu trữ mọi thông tin về dịch vụ nhƣ: đặc tả, chức năng, nhà cung cấp, giao diện sử dụng. Ngƣời sử dụng sẽ tìm kiếm trên Website lƣu trữ để có đƣợc thông tin mô tả về dịch vụ cần tìm và sau đó là xây dựng kênh giao tiếp với phía nhà cung cấp. Kiến trúc hƣớng dịch vụ cung cấp giải pháp để giải quyết các vấn đề tồn tại của các hệ thống hiện nay nhƣ: phức tạp, không linh hoạt và không ổn định. Một hệ thống triển khai theo mô hình hƣớng dịch vụ có khả năng dễ mở rộng, liên kết tốt. Đây chính là cơ sở và nền tảng cho việc tích hợp, tái sử dụng lại những tài nguyên hiện có. Tuy nhiên, kiến trúc hƣớng dịch vụ chỉ là mô hình lý thuyết. Để hiện thực hóa mô hình này, một trong những công nghệ đƣợc sử dụng phổ biến là dịch vụ Web (Web Service). 1.1.2 Dịch vụ Web Dịch vụWeb là hạt nhân trong kiến trúc hƣớng dịch vụ. Theo IBM [12], “Dịch vụ Web là một hệ thống phần mềm được thiết kế để hỗ trợ giao tiếp giữa các hệ thống qua - 14 mạng. Nó có giao tiếp được mô tả theo định dạng chung mà các máy tính có thể xử lý được gọi là ngôn ngữ định nghĩa dịch vụ (Web Service Definition Language WSDL)”. Dịch vụ Web có thể cung cấp một chức năng hoặc một tập các chức năng nhất định. Dịch vụ Web đƣợc mô tả thông qua một chuẩn theo định dạng XML, gọi là đặc tả dịch vụ, trong đó cung cấp thông tin cần thiết để có thể tƣơng tác với dịch vụ, bao gồm định dạng thông điệp (cả các toán tử), giao thức, và địa chỉ. Đặc tả này cũng ẩn đi các thông tin chi tiết bên trong, vì thế dịch vụ Web hoàn toàn độc lập với nền tảng phần cứng và phần mềm tạo nên nó. Kiến trúc hƣớng dịch vụ là cấp độ cao hơn của phát triển ứng dụng, chú trọng đến qui trình nghiệp vụ và dùng giao tiếp chuẩn để giúp che đi sự phức tạp kỹ thuật bên dƣới. Thiết kế hƣớng dịch vụ tách riêng phần thực hiện dịch vụ (phần mềm) với giao tiếp gọi dịch vụ. Điều này tạo nên một giao tiếp nhất quán cho ứng dụng khách (client) sử dụng dịch vụ bất chấp công nghệ thực hiện dịch vụ. Thay vì xây dựng các ứng dụng đơn lẻ và đồ sộ, nhà phát triển sẽ xây dựng các dịch vụ tinh gọn có thể triển khai và tái sử dụng trong toàn bộ quy trình nghiệp vụ. Điều này cho phép tái sử dụng phần mềm tốt hơn, cũng nhƣ tăng sự linh hoạt vì nhà phát triển có thể cải tiến dịch vụ mà không làm ảnh hƣởng đến ứng dụng khách sử dụng dịch vụ. Ƣu điểm quan trọng nhất của kiến trúc hƣớng dịch vụ là khả năng kết nối 'mềm dẻo' – loose coupling và tái sử dụng. Các dịch vụ có thể đƣợc thiết kế trên nền tảng và ngôn ngữ và ngôn ngữ bất kỳ, hoàn toàn độc lập với hệ thống Client sử dụng nó. Ví dụ, một ứng dụng Java có thể liên kết với một dịch vụ Web viết bằng công nghệ .NET và ngƣợc lại. Có thể thấy dịch vụ Web giúp cho các ứng dụng đƣợc tích hợp nhanh hơn, dễ dàng hơn và tốn ít chi phí hơn so với các công nghệ trƣớc đó. Cụ thể, sử dụng dịch vụ Web đem lại những lợi ích sau:  Giảm chi phí phát triển nghiệp vụ: do đã có dịch vụ cung cấp có sẵn. Các dịch vụ này có thể sử dụng lại nhiều lần.  Cung cấp khả năng triển khai giải pháp nhanh chóng hơn: Doanh nghiệp có thể kết hợp những dịch vụ có sẵn để phát triển thành một quy trình nghiệp vụ hoàn thiện.  Với việc nhanh chóng đƣa ra những ứng dụng hỗ trợ cho nghiệp vụ của doanh nghiệp với chi phí rẻ hơn, công nghệ này mở ra những cơ hội kinh doanh mới. Để đạt đƣợc điều nay, dịch vụ Web sử dụng các giao thứchỗ trợ việc giao tiếp giữa các hệ thống nhƣ HTTP, XML, SOAP và WSDL. SOAP hay còn gọi là giao thức truy cập đối tƣợng đơn giản là giao thức để trao đổi thông tin giữa các ứng dụng phân tán. Nó dựa trên chuẩn XML bao gồm 3 phần sau: một lớp bao đóng định nghĩa khung về thông điệp và cách xử lý nó; một tập các luật đƣợc mã hóa để biểu diễn các kiểu dữ liệu mà ứng dụng định nghĩa; chuyển đổi cho các thủ tục gọi từ xa. SOAP có thể dùng kết hợp với các giao thức khác nhƣ HTTP. Trong hình 1.1 ở trên, nhà cung cấp dịch vụ - 15 sử dụng định dạng WSDL để đăng ký dịch vụ với trung tâm lƣu trữ. Ngƣời sử dụng cũng sử dụng giao diện WSDL này để kết nối tới dịch vụ để thử nghiệm và thực thi. Việc trao đổi giữa ngƣời sử dụng dịch vụ và nhà cung cấp đƣợc thực hiện qua các thông điệp XML dựa trên giao thức SOAP. 1.2 Kết hợp dịch vụ Ngày nay, với sự phát triển của các ứng dụng nghiệp vụ đòi hỏi các ứng dụng công nghệ thông tin phải có một hạ tầng mềm dẻo và linh hoạt để có thể nhanh chóng thay đổi và đáp ứng. Tuy nhiên, các ứng dụng CNTT truyền thống thƣờng đƣợc thiết kế theo hƣớng chức năng và thƣờng phục vụ một nghiệp vụ nhất định, khó có khả năng thay đổi nghiệp vụ khi cần. Kết quả là rất nhiều các doanh nghiệp không thể tiếp tục sử dụng lại các hệ thống cũ do không thể tích hợp với các thiết kế của hệ thống mới. Một bài toán đƣợc đặt ra là làm sao có thể sử dụng lại các chức năng của các hệ thống cũ để tạo ra một hệ thống mới, nhằm tiết kiệm chi phí đầu tƣ CNTT trong môi trƣờng cạnh tranh hiện nay. Kiến trúc hƣớng dịch vụ ra đời nhằm giải quyết bài toán đó, ngƣời ta dùng thuật ngữ “Orchestration” – tạm dịch là kết hợp các dịch vụ. Kiến trúc này cho phép kết hợp các dịch vụ rời rạc thành một ứng dụng nghiệp vụ thống nhất một cách đơn giản và nhanh chóng mà không cần thay đổi các dịch vụ đó. Không giống nhƣ các công nghệ trƣớc đây, khi ngƣời dùng muốn sử dụng một chức năng của ứng dụng có sẵn, họ cần phải tích hợp mã nguồn hoặc các thƣ viện của ứng dụng cũ vào ứng dụng mới; kiến trúc hƣớng dịch vụ hỗ trợ khả năng sử dụng lại các chức năng này trong khi chúng vẫn là các dịch vụ Web chạy trên các hệ thống cũ. Đây là điểm đặc biệt củakiến trúc này giúp cho việc tích hợp đƣợc nhanh hơn, đơn giản hơn. Hình 1.2 Kết hợp các ứng dụng theo kiến trúc SOA trong một hệ thống ngân hàng - 16 Hình 1.2 trên là ví dụ về việc kết hợp các ứng dụng trong một ngân hàng theo kiến trúc hƣớng dịch vụ. Ngân hàng có rất nhiều các hệ thống, đƣợc phát triển trên các ngôn ngữ khác nhau nhƣ C, C++, .NET, Java và chạy trên các nền tảng khác nhau nhƣ: Solaris, Window, Unix, Linux. Lãnh đạo ngân hàng muốn xây dựng một hệ thống giám sát giao dịch tập trung để kiểm soát tất cả giao dịch của các hệ thống: hệ thống lõi (giao dịch ngân hàng), hệ thống thẻ ATM, hệ thống ngân hàng trực tuyến, hệ thống chứng khoán, hệ thống sàn vàng. Phòng phát triển ứng dụng đã đề xuất và xây dựng hệ thống ứng dụng theo kiến trúc hƣớng dịch vụ sử dụng công nghệ dịch vụ Web để tận dụng hạ tầng các ứng dụng sẵn có. Mỗi ứng dụng sẵn có sẽ xây dựng dịch vụ Web để đƣa chức năng của nó ra ngoài, sau đó ứng dụng mới sẽ gọi các dịch vụ Web đó để tạo thành một ứng dụng hoàn chỉnh. Trong chiến lƣợc đa dạng hóa dịch vụ và tăng tiện ích cho khách hàng, ngân hàng muốn triển khai dịch vụ thanh toán tiền cƣớc điện thoại cho các khách hàng có nhu cầu. Công nghệ dịch vụ Web tiếp tục đƣợc lựa chọn để giao tiếp với hệ thống thanh toán cƣớc của công ty viễn thông. Trong mô hình này, công ty viễn thông đã xây dựng sẵn các dịch vụ Web cho phép truy vấn và thanh toán cƣớc, do đó phía ngân hàng chỉ cần xây dựng quy trình nghiệp vụ cho phép giao tiếp (theo công nghệ dịch vụ Web) và thực hiện các giao dịch thanh toán cƣớc điện thoại từ tài khoản của khách hàng đăng ký. Nhƣ vậy, công nghệ dịch vụ Web không chỉ cho phép kết hợp nhiều ứng dụng và dịch vụ trong nội bộ doanh nghiệp mà còn hỗ trợ giao tiếp với hệ thống ngoài theo mô hình B2B (Business To Business). Để kết hợp đƣợc các dịch vụ Web thành một quy trình nghiệp vụ hoàn chỉnh, ngƣời ta sử dụng ngôn ngữ mô phỏng và thực thi tiến trình nghiệp vụ có tên là BPEL. Ngôn ngữ BPEL sẽ định nghĩa tiến trình, các dịch vụ ngoài và sử dụng các tác vụ, các phép toán logic để tạo thành một quy trình. Để hiểu rõ hơn về ngôn ngữ BPEL, chúng ta sẽ đi tìm hiểu về từng thành phần của nó trong phần dƣới đây. 1.3 Ngôn ngữ BPEL 1.3.1 Giới thiêụ BPEL (Business Process Execution Language ) là ngôn ngữ dùng để hỗ trơ ̣ phát triể n các ứng dụng phức tạp, lớn đòi hỏi phải tổ ng hơ ̣p nhiề u dich ̣ vu ̣ Web khác nhau. Phiên bản BPEL đầu tiên (BPEL 1.0) ra đời vào tháng 07/2002. Vào tháng 05/2003 BPEL1.1 ra đời 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 [17] (một tổ chức chuyên đƣa ra các chuẩn thông tin). Tháng 04/2007 tổ chức OASIS chuẩn hóa BPEL và đổi tên thành WS-BPEL 2.0 đƣợc dùng cho đến nay. BPEL cho phép đặc tả và xử lý luồng công việc bằng cách cung cấp sẵn các thẻ mô tả các đối tƣợng và các hoạt động xử lý của một quy trình nghiệp vụ thông thƣờng. Ngoài ra BPEL còn định nghĩa các cách qu ản lý các sự kiện và ngoại lệ, cơ chế bảo toàn dữ liệu khi có ngoại lệ xảy ra. BPEL hoa ̣t đô ̣ng dƣ̣a trên nguyên tắ c g ửi các thông - 17 điệp dạng XML đến một dịch vụ khác, thao tác trên cấu trúc XML, nhận các thông điệp XML (đồng bộ hay không đồng bộ) từ các dịch vụ bên ngoài.Nó phụ thuộc vào bố n chuẩ n XML cơ bản đƣợc xem nhƣ là các đặc tả để thực thi một tiến trình BPEL : WSDL, XML Schema 2.0, XPath 2.0 và WS-Addressing. Hình 1.3 dƣới thể hiện mô hình một tiến trình BPEL trong thực tế. Một tiến trình BPEL bao gồm 2 tác vụ cơ bản nhất là receive và reply trong đó tác vụ receive dùng để nhận yêu cầu đầu vào, còn reply trả lại kết quả cho ngƣời dùng. Giữa 2 tác vụ này còn có nhiều tác vụ khác làm nhiệm vụ gọi các dịch vụ Web từ bên ngoài (callbackClient), thực thi, xử lý các dữ liệu trung gian(Assign) trƣớc khi trả về kết quả cuối cùng cho ngƣời dùng. Hình 1.3 Ví dụ về một tiến trình BPEL 1.3.2 Nguyên tắ t hoa ̣t đô ̣ng của mô ̣t tiế n trin ̀ h BPEL Trong số các đă ̣c tả : WSDL, XML Schema 2.0,XPath 2.0 và WS -Addressing thì WSDL đóng vai trò cố t lõi trong mô ̣t tiế n trin ̀ h của BPEL . Cố t lõi của BPEL là khái niê ̣m peer-to-peer là sƣ̣ tƣơng tác giƣ̃a các dich ̣ vu ̣ Web đƣơ ̣c mô tả trong WSDL . Mô ̣t tiế n trin ̀ h BPEL làm thế nào để phố i hơ ̣p giƣ̃a các di ̣ ch vu ̣ khác nhau và kết hợp các dịch vụ đó lại thành một tiến trình hoàn chỉnh . Điề u này có nghiã mô ̣t tiế n trình BPEL phải có đặc tả của riêng nó đồng thời sử dụng các đặc tả WSDL đƣợc cung cấp bởi các dịch vụ khác trong quá trình tổ ng hơ ̣p các dich ̣ vu ̣ này . Tuy nhiên có một vấn đề đặt ra là: làm thế nào để tiến trình BPEL có thể phân biệt đƣợc từng dịch vụ mà nó tổng hợp trên đó để mà tƣơng tác trên những dịch vụ đó; cũng nhƣ mỗi dịch vụ đƣợc sử dụng trong tiến trình BPEL có vai trò nhƣ thế nào trong toàn bộ tiến trình… Để giải quyết vấn đề này, BPEL đã đƣa ra hai khái niệm mới là kiểu liên kết ngoài - partnerLinkType và liên kết ngoài-partnerLink. - 18  Kiểu liên kết ngoài - PartnerLinkType Các dịch vụ trong tƣơng tác của tiến trình nghiệp vụ đƣợc mô tả là các PartnerLinkType trong BPEL. Mỗi một PartnerLink đƣợc mô tả bằng một PartnerLinkType, đƣợc đặt tên để đại diện cho tất cả các tƣơng tác thông qua PartnerLink đó. Nếu PartnerLinkType tƣơng ứng chỉ có một role thì role này sẽ mặc định đƣợc gán cho thuộc tính myRole của PartnerLink, nhƣng nếu có nhiều role thì phải chỉ ra để cho biết PartnerLink này hoạt động với PortType nào.Hình 1.4 dƣới đây ví dụ về mộtkiểu liên kết ngoài có tên là “BuyerSelllerLink” với 2 role là “Buyer” và “Seller”. Trong trƣờng hợp thông thƣờng, portTypes của hai roles (MyRole và PartnerRole) xác định t ừ các namespaces riêng biê ̣t . Tuy nhiên trong mô ̣t số trƣờng hơ ̣p thì chúng đƣơ ̣c xác đinh ̣ chung mô ̣t namespace, điề u này thƣờng xảy ra ở các dich ̣ vụ thuộc có mối quan hệ “callback”(gọi lại chính nó). Hình 1.4Ví dụ về kiểu liên kết ngoài - PartnerLink Type  Liên kết ngoài - PartnerLink Các dịch vụ trong tƣơng tác của tiến trình nghiệp vụ đƣợc mô tả là các PartnerLinkType trong BPEL. Mỗi một PartnerLink đƣợc mô tả bằng một PartnerLinkType, đƣợc đặt tên để đại diện cho tất cả các tƣơng tác thông qua PartnerLink đó. Nếu PartnerLinkType tƣơng ứng chỉ có một role thì role này sẽ mặc định đƣợc gán cho thuộc tính myRole của PartnerLink, nhƣng nếu có nhiều role thì phải chỉ ra để cho biết PartnerLink này hoạt động với PortType nào. Hình 1.5 ví dụ về PartnerLinkcó tên là “ncname”với partnerLinkType là “qname”: + Hình 1.5Ví dụ về liên kết ngoài - PartnerLink PartnerLinkType đƣợc mô tả trong tập tin WSDL nhƣ là một khái niệm mở rộng cho chuẩn WSDL. Còn các partnerLink nào đƣợc dùng trong tiến trình BPEL thì đƣợc chỉ ra trong tập tin BPEL.Kỹ thuật dùng partnerLink chẳng những giải quyết đƣợc vấn đề trên mà còn giúp tiến trình BPEL có thể dễ dàng tích hợp với các bộ phận khác trong kiến trúc tổng thể của SOA. Cụ thể, khi ta định nghĩa một partnerLink, chúng ta sử - 19 dụng thuộc tính myRole để chỉ vai trò của chính dịch vụWeb của BPEL. Ngƣợc lại, thuộc tính partnerRole đƣợc dùng để chỉ vai trò của một dịch vụ bên ngoài. 1.3.3 Cấ u trúc của mô ̣t tiế n trin ̀ h BPEL Mô ̣t tiế n triǹ h BPEL là mô ̣t mô tả dƣới da ̣ng tài liê ̣u XML. Quy trình đƣợc mô tả trong BPEL giao tiếp với trang Web và các dịch vụ trao đổi tài liệu XML(SOAP). Các khái niệm (phần tử) chính trong một tiến trình BPEL bao gồm: : Mọi file BPE L đề u bắ t đầ u với thẻ . Các mô tả cho tiến trình cũng nhƣ các namespace liên quan đƣợc định nghĩa ở thẻ này . :Chƣ́a thông tin các tâ ̣p tin WSDL đƣơ ̣c import vào . : Chứa tập hợp các partnerLink đƣợc sử dụng trong tiến trình. Mỗi partnerLink sẽ thiết lập một quan hệ giữa bản thân process với một service bên ngoài. : 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. : Đây là phần chính mô tả logic của tiến trình. Trong một sẽ chứa nhiều tác vụ (đƣợc trình bày chi tiết bên dƣới). Mỗi tác vụ có một nhiệm vụ cụ thể trong tiến trình BPEL. Bản thân cũng là một tác vụ, có thể chứa các cấu trúc song song cũng nhƣ cấu trúc tuần tự khác.Cấ u trúc của mô ̣t tiế n trình BPEL đƣơ ̣c mô tả trong tâ ̣p tin BPEL nhƣ sau: ……………… ……………… Hình 1.6Cấu trúc file BPEL 1.3.4 Các thành phần và ký hiệu trong BPEL Một tiến trình BPEL đƣợc thể hiện qua các tác vụ, các tác vụ trong BPEL đƣợc thực hiện tuần tự theo cấu trúc đƣợc khai báo trong tiến trình. Trong ngôn ngữ WS-BPEL 2.0 các tác vụ đƣợc chia làm ba nhóm cơ bản nhƣ sau: Tác vụ cơ bản: Là các tác vụ đơn thể, nó không thể chứa đƣợc bất kỳ các tác vụ nào khác bên trong nó nữa. - 20 Tác vụ cấu trúc: Là các tác vụ có cấu trúc, nó có thể chứa đƣợc các tác vụ khác bên trong nó. Tác vụ xử lý lỗi:Các tác vụ này đƣợc sử dụng để thụ lý lỗi và các ngoại lệ xảy ra trong quá trình hoạt động của một tiến trình. Tùy theo nhu cầu và trong các trƣờng hợp cụ thể mà ta có thể chọn và sử dụng các tác vụ khác nhau.Bảng sau mô tả chi tiết về các tác vụ trong ngôn ngữWS-BPEL 2.0: Bảng 1.1Các tác vụ trong ngôn ngữWS-BPEL 2.0 Tên tác vụ Các trường hơ ̣p sử du ̣ng Các tác vụ cơ bản Empty Là một tác vụ đặc biệt, không làm gì hết khi đƣợc gọi. Tác vụ này đƣợc dùng khi cần có một tác vụ nhƣng không thật sự cần một hành động nào xảy ra. Invoke Gọi một dịch vụ Web để thực hiện một tác vụ nào đó Receive Nhận một thông điệp từ một dịch vụ ngoài. Thông thƣờng đây là tác vụ bắt đầu một tiến trình mới Reply Opaque Activity Assign Validate Gửi trả một thông điệp cho mô ̣t đố i tƣơ ̣ng bên ngoài tiế n trin ̀ h Là một tác vụ dạng dẫn xuất Dùng để khởi tạo ho ặc gán giá tri ̣cho các biế n trong tiế n trin ̀ h BPEL Kiểm tra tính hợp lệ của các biến và các biể u thƣ́c d ựa trên định nghĩa của nó (chẳng hạn định nghĩa dựa trên XML Schema, hay WSDL…) Các tác vụ điề u khiể n và có cấ u trúc If/Else Pick Định nghĩa cấu trúc điều kiện Định nghĩa cách lựa chọn phƣơng án hành động (hành động nào sẽ đƣợc thực hiện khi sự kiện tƣơng ứng mà nó quy định xảy ra, nếu không có sự kiện nào xảy ra trong một thời gian chỉ định trƣớc thì hành động nào sẽ đƣợc thực hiện…) Flow Xử lý song song và điều khiển phụ thuộc. While Lă ̣p la ̣i mô ̣t tiế n trình con nào đó trong process ở da ̣ng while - 21 RepeatUntil Foreach Wait Sequence Scope Lă ̣p la ̣i mô ̣t tiế n trình con nào đó trong … Until tiến trình ở dạng Repeat Đinh ̣ nghiã vòng lă ̣p để duyê ̣t qua mô ̣t tâ ̣p hơ ̣p Dƣ̀ng tiế n trình trong mô ̣t khoản g thời gian đƣơ ̣c thiế t lâ ̣p trƣớc Dùng để thiết lập tuầ n tƣ̣ hoa ̣t đô ̣ng của các tác vụ Dùng để chia nhỏ tiến trình thành các tác vụ có các nhiệm vụ liên quan với nhau (khi tiến trình trở nên phức tạp). Các tác vụ dùng để quản lý lỗi và ngoại lệ Exit Throw Rethrow Dƣ̀ng tiế n trin ̀ h hiê ̣n ta ̣i Ném ra một ngoại lệ Ném ra thông báo lỗi sau khi lỗi này đã đƣợc thụ lý trƣớc đó Compensate Scope Là tác vụ dùng để thụ lý lỗi. Khi có lỗi xảy ra thì tác vụ này sẽ đƣợc dùng để xử lý lỗi trên phạm vi đƣợc chỉ ra Compensate Có chức năng cũng giống nhƣ tác vụ Compensate Scope nhƣng đƣợc dùng để thụ lý lỗi trên phạm vi tất cả các phạm vi liên quan Sau đây là mô tả chi tiết và các trƣờng hợp sử dụng của từng tác vụ:  Tác vụ nhận - Receive Khi một tiến trình BPEL cần nhận một thông điệp thì tác vụreceive sẽ đƣợc sử dụng. Tác vụ Receive sẽ xác định đƣợc dịch vụ đối tác mà nó đƣợc nhận thông điệp và các Operation từ dịch vụ ngoài mà nó cần phải gọi thông qua PartnerLink và Operation. Để thực thi đƣợc thì tác vụreceive phải xác định đƣợc một biến đầu vào (input) hoặc phần dữ liệu mà nó đƣợc nhận. Cấu trúc XML của tác vụreceive đƣợc thể hiện nhƣ sau: standard-elements ? + ? + Hình 1.7Cấu trúc XML của receive - 22 Hình 1.7 mô tả khai báo tác vụ receive bao gồm liên kết ngoài(partnerLink=”NCName”, portType=”QName”, operation=”NCName”, các tham số này đƣợc ứng dụng khách sử dụng và gửi thông điệp đến. Biến BPEL VariableName đƣợc sử dụng để lƣu giá trị đầu vào từ thông điệp.  Tác vụ gọi dịch vụ Web - Invoke Để gọi hoặc thực hiện một dịch vụ Web nào đó thì ta sử dụng tác vụ invoke. Tác vụInvoke mô tả một dịch vụ Web thực hiện ở dạng “một chiều” hoặc “yêu cầu- đáp ứng”. Các dịch vụ Web đối tác đƣợc xác định thông qua PartnerLink và Operation. Để thực thi một tác vụ 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 vụ Web mà nó gọi thực hiện (dạng “một chiều” hoặc “ yêu cầu-đáp ứng”). Hình 1.8 mô tả một trƣờng hợp sử dụng cụ thể của tác vụ invoke trong một chức năng tìm thông tin khách hàng,chức năng này gọi dịch vụ Web: tìm kiếm tên khách hàng (InvokeLookupCustomerName): Hình 1.8 Ví dụ về trƣờng hợp sử dụng invoke Cấu trúc XML của invoke đƣợc mô tả nhƣ sau: standard-elements * activity ? activity --------? + ? + Hình 1.9Cấu trúc XML của invoke - 23 Trong hình1.9, một tác vụ invoke đƣợc khai báo để gọi dịch vụ ngoài có partnerLink là “NCName” và operation là “NCName”. Tác vụ này sử dụng biến đầu vào “NCName” và trả kết quả về cho biến “NCFullName”.  Tác vụ nhận - Reply Một tác vụ nhận (Reply)đóng vai trò nhƣ một giá trị trả về trong một tiến trình BPEL. Nội dung thông điệp đƣợc gửi đi sẽ đƣợc dịch vụ Web đối tác tiếp nhận thông qua tác vụ Receive ở dạng onMessage (thông điệp) hoặc onEvent (sự kiện). Một tác vụ Reply thì sẽ có cùng một partnerLink và operation với tác vụ Receive tƣơng ứng của dịch vụ Web đối tác. Để thực thi đƣợc, tác vụ Reply yêu cầu phải đƣợc đặc tả cho thông điệp mà nó sẽ gửi đi. Khi tiến trình xuất hiện lỗi thì tác vụ Replysẽ trả về một ngoại lệ. Chúng ta có thể kiểm soát các lỗi này bằng cách thêm một tác vụThrow để trả về một ngoại lệ nếu xử lý trong tiến trình bị lỗi nhƣ hình 1.10: Hình 1.10Trƣờng hợp sử dụng của Reply Cấu trúc XML của tác vụ Reply nhƣ sau: standard-elements ? + ? + Hình 1.11Cấu trúc XML của Reply - 24 Tác vụ reply trong hình1.11 có cùng partnerLink và operation với tác vụ receive tƣơng ứng với nó. Tác vụ này dùng biến BPELVariableName để lƣu kết quả trả về từ những tác vụ trƣớc đó của tiến trình.  Tác vụ kiểm tra tính hợp lệ - Validate Một tác vụValidate có nhiệm vụ kiểm tra tính hợp lệ của các biến dựa trên định nghĩa của nó có liên quan đến tài liệu XML và WSDL. Bạn có thể kiểm tra một danh sách các biến với tác vụ này. Trong suốt quá trình hoạt động nếu có một biến nào đó đƣợc tìm thấy có chứa một giá trị không hợp lệ thì tiến trình ngay lập tức kết thúc với một ngoại lệ “invalidVariables” đƣợc đƣa ra. Lƣu ý rằng bạn cũng có thể kiểm tra tính hợp lệ của các biến đƣợc sử dụng trong tác vụAssign. Hình 1.12 mô tả một trƣờng hợp sử dụng của Validateđƣợc đặt giữa tác vụ Assign và Reply để kiểm tra tính hợp lệ của các biến trƣớc khi trả về kết quả cuối cùng: Hình 1.12 Trƣờng hợp sử dụng của Validate  Tác vụ gán - Assign Tác vụ Assign đƣợc dùng để cập nhật giá trị cho các biến chứa bên trong nó. Assign cập nhật các biến bằng một trong những cách sau:  Copy dữ liệu từ một biến khác  Khởi tạo thông qua các phƣơng thức của XPath  Khởi tạo thông qua các phƣơng thức của WS-BPEL và một số phƣơng thức mở rộng khác Cấu trúc XML của Assign đƣợc thể hiện nhƣ sau: