3. Hướng nghiên cứu của đề tài
1.5. Các dịch vụ web hiện nay đã phát triển
Hiện nay trên phương diện về dịch vụ web đang phát triển càng ngày càng đa dạng với nhiều lĩnh vực khác nhau. Vào những năm 2000 khi công nghệ thông tin Việt Nam còn đang chập chững trước ngưỡng cửa thông tin toàn cầu thì việc triển khai dịch vụ web vẫn còn rất nghèo nàn về công nghệ dịch vụ web lẫn kỹ thuật.
Việc triển khai công nghệ thông tin sau nhiều năm đã giúp Việt Nam có được những thành tựu to lớn với các công nghệ tiên tiến và bám sát với cộng đồng công nghệ mạng thế giới. Cụ thể thông qua các nhà cung cấp dịch vụ mạng Việt Nam ngày càng nhiều và ngày càng chất lượng.
Ứng dụng web trở nên phổ biến nên dịch vụ mạng trở thành một tiềm năng khai thác cho rất nhiều doanh nghiệp. Từ việc quản lý nhân viên, quản lý hồ sơ, quản lý điểm học tập... cho đến giáo dục đào tạo từ xa. Tất cả đều có thể thông qua ứng dụng dịch vụ mạng để thực hiện công việc trực tuyến.
Một số ứng dụng mạng hiện nay đang phát triển có thể kể đến như: - Mạng thanh toán PayNet
- Mạng xã hội Facebook
- Mạng chia sẻ ngang hàng Torrent …
1.6. Tình hình nghiên cứu hiện nay trong và ngoài nƣớc
Với sự phát triển và ứng dụng mạnh mẽ của công nghệ SOA vào các quy trình nghiệp vụ và đang mang lại một lợi ích lớn cho các tổ chức và doanh nghiệp. Đi đôi với kiến trúc SOA là sự phát triển của các ngôn ngữ mô hình hóa các quy trình nghiệp vụ như: XPDL, BPML,BPEL…. Nó giúp cho các lập trình viên và các nhà sử dụng dịch vụ đơn giãn hóa việc tổng hợp cũng như xây dựng các dịch vụ riêng cho mình. Chúng không phải là một ngôn ngữ được sử dụng cho việc phân tích thiết kế và được thể hiện bằng một bộ cú pháp xml và có các giao thức riêng
của mình, chúng không có một ngôn ngữ riêng cụ thể nào cả mà chỉ được thể hiện qua các giao diện đồ họa, cũng không có một chuẩn ký hiệu chung cho các ngôn ngữ này. Trong các ngôn ngữ trên thì BPEL là ngôn ngữ được sử dụng rộng rãi nhất. Từ năm 2003 tổ chức OASIS đã mua bản quyền và chịu trách nhiệm cho sự phát triển của ngôn ngữ BPEL. Để hổ trợ cho việc thể hiện các ngôn ngữ này thì các công cụ desingner được phát triển ra như là một tất yếu. Có rất nhiều Design Engine được phát triển bởi nhiều tổ chức khác nhau như Oracle SOA Suite, PPEL Eclipse Plugin… hỗ trợ mạnh mẽ cho việc tổng hợp và xây dựng các dịch vụ.
Tuy nhiên với sự phát triển mạnh mẽ của của internet và các công nghệ web đã là cho nhu cầu sử dụng và chia sẽ các ứng dụng thông qua môi trường web như là một nhu cầu tất yếu. Vì vậy nhu cầu xây dụng các công cụ hổ trợ cho việc tổng hợp và thiết kế các dịch vụ trên môi trường web là một nhu cầu có thật và hiển nhiên. Vấn đề đặt ra là làm sao các nhà sử dụng cũng như cung cấp dịch vụ có thể tạo ra một quy trình dịch vụ cũng như tiếp cận các dự án của mình một cách nhanh nhất vào mọi thời điểm và mọi nơi có kết nối internet mà không cần phải cài đặt sẵn các chương trình desingner.
Chƣơng 2
NGÔN NGỮ BPEL 2.1. Giới thiệu ngôn ngữ BPEL
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 dịch vụ 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 (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 [4].
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.
BPEL đại diện cho một quy tụ của hai ngôn ngữ workflow (quy trình làm việc), WSFL (Web Services Flow Language) và XLANG. WSFL này được thiết kế
bởi IBM dựa trên khái niệm về hướng dẫn đồ thị. XLANG được thiết kế bởi Microsoft là một khối cơ cấu ngôn ngữ. BPEL kết hợp cả hai phương pháp tiếp cận và cung cấp một vốn từ vựng phong phú cho các mô tả về quy trình kinh doanh.
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 hoạt động dựa trên nguyên tắc gửi các thông đ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 6 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à receivevà 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 2.1: Ví dụ về một tiến trình BPEL 2.1.1. Nguyên tắc hoạt động của một tiến trình 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 trình 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 dịch vụ Web được mô tả trong WSDL. Một tiến trình BPEL làm thế nào để phối hợp giữa các dịch vụ 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ó nghĩa 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 dịch vụ 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.
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 myRolecủ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 2.2 dưới đây ví dụ về một kiể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 (MyRolevà 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 định chung một namespace, điều này thường xảy ra ở các dịch vụ thuộc có mối quan hệ ―callback‖(gọi lại chính nó).
Hình 2.2: Ví dụ về kiểu liên kết ngoài - PartnerLink Type
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ử 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.
Hình 2.3 ví dụ về PartnerLink có tên là ―ncname‖ với partnerLinkType là ―qname‖:
2.1.2. Cấu trúc của một tiến trình BPEL
Một tiến trình BPEL là một mô tả dưới dạ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) [6]. Các khái niệm (phần tử) chính trong một tiến trình BPEL bao gồm:
<Process>: Mọi file BPEL đều bắt đầu với thẻ <process>. 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.
<Imports>: Chứa thông tin các tập tin WSDL được import vào.
<PartnerLinks>: 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.
<Variables>: 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.
<Sequence>: Đây là phần chính mô tả logic của tiến trình. Trong một <sequence> 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 <sequence> 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:
2.2. Các khái niệm cơ bản về BPEL
2.2.1. Các thành phần tác vụ 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.
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:
Tên tác vụ Các trƣờng hợp sử dụ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 Là một tác vụ dạng dẫn xuất
Opaque Activity Là một tác vụ dạng dẫn xuất
Assign Dùng để khởi tạo hoặc gán giá trị cho các biến trong tiến trình BPEL
Validate
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…)
Tên tác vụ Các trƣờng hợp sử dụng Các tác vụ điều khiển và có cấu trúc
If/Else Định nghĩa cấu trúc điều kiện
Pick
Đị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 lại một tiến trình con nào đó trong process ở dạng while RepeatUntil Lặp lại một tiến trình con nào đó trong tiến trình ở dạng
Repeat … Until
Wait Dừng tiến trình trong một khoảng thời gian được thiết lập trước Sequence Dùng để thiết lập tuần tự hoạt động của các tác vụ
Scope Dùng để chia nhỏ tiến trình thành các tác vụ có cácnhiệ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 Dừng tiến trình hiện tại
Throw Ném ra một ngoại lệ
Rethrow 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 PartnerLinkvà 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.
Hình 2.5: Cấu trúc XML của receive
Hình 2.5 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 2.6: Ví dụ về trường hợp sử dụng invoke
Hình 2.6 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):
Cấu trúc XML của invoke được mô tả như sau:
Hình 2.7: Cấu trúc XML của invoke
Trong hình 2.7, 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ụ Reply sẽ 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ình13:
Hình 2.8 Trường hợp sử dụng của Reply
Cấu trúc XML của tác vụ Reply như sau:
Tác vụ reply trong hình 2.9 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 BPEL VariableName để 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. 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