nghệ thông tin đại học Khoa Học Tư Nhiên
Trong khoa công nghệ thông tin, đại học Khoa Học Tự Nhiên đã có một số đề tài nghiên cứu về SOA nhƣ:
18
Đề tài “nghiên cứu kiến trúc hƣớng dịch vụ (SOA) và ứng dụng” [ 2 ] của hai sinh viên: Hồ Bảo Thanh và Nguyễn Hoàng Long thực hiện năm 2005 là đề tài luận văn đầu tiên nghiên cứu về SOA tại khoa. Mục tiêu của đề tài là nghiên cứu các vấn đề có liên quan đến SOA và ứng dụng SOA để xây dựng một tiến trình nghiệp vụ.
Đề tài “Nghiên cứu kiến trúc hƣớng dịch vụ IBM và phát triển ứng dụng” của hai sinh viên: Nguyễn Hoàng Anh và Hoàng Vũ Tuấn thực hiện năm 2007 là đề tài nghiên cứu về kiến trúc hƣớng dịch vụ của hãng IBM và sử dụng các công cụ của IBM để phát triển ứng dụng.
Đề tài “Xây dựng môi trƣờng thiết kế và vận hành SOA trên Web” của hai sinh viên: Trần Quang Duy và Nguyễn Trần Kha đã xây dựng một công cụ thiết kế SOA thực thi trên môi trƣờng web.
Đề tài :” Nghiên cứu và xây dựng hệ thống thiết kế và vận hành quy trình tổng hợp dịch vụ Web ngữ nghĩa” cùa hai sinh viên Phan Lê Sang và Trần Ngọc Tịnh năm 2009,
Đề tài này đƣợc kế th a và phát triển các kiến thức về SOA và BPEL t các đền tài nêu trên.
19
Chư ng 2 PH T TRIỂN V THỰC THI C C QUY TRÌNH NGHIỆP V VỚI WS-BPEL 2.0 V APACH O
ội dung: Trong chương này chúng tôi xin giới thiệu tới các bạn ngôn ngữ mô
hình hóa tiến trình dịch vụ và đư c d ng đ phát tri n các ng dụng lớn và ph c tạp hiện nay chúng tôi sẽ giới thiệu chi tiết về các thành phần c ng như các khái niệm trong cách xây dựng một tiến trình đơn giản.Qua chương này chúng tôi c ng xin giới thiệu tới các bạn một số khái niệm về Apache ODE bao gồm: cấu trúc cách cài đặt cách tri n khai một quy trình nghiệp vụ lên Apache ODE.
2.1 Tổng quan về ngôn ngữ P L 2.1.1Giới thiệu
BPEL (Business Process Execution Language) là một 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 BPEL 1.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 OASIS chuẩn hóa BPEL và đổi tên thành WS-BPEL 2.0 đƣợc dùng cho đến nay[ 3 ].
BPEL không chỉ cho phép bạn mô tả và xử lý luồng công việc bằng cách sử dụng trình soạn thảo đồ họa thân thiện với ngƣời dù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 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 service bên ngoài. Nó phụ thuộc vào bốn chuẩn XML cơ bản đƣợc xem nhƣ là các đặt tả để thực thi một tiến trình BPEL: WSDL, XML Schema 2.0, XPath 2.0 và WS-Addressing. Hình 2.1 thể hiện một tiến trình BPEL trong thực tế.
20
Hình 2.1- Ví dụ về một tiến trình BPEL
2.1.2 Nguyên tắt hoạt động của một tiến trình P L
Trong số các đặc tả: WSDL, XML Schema 2.0, XPath 2.0 và WS-Addressing trên 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 đặt tả 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 đƣợc định nghĩa hoặc cung cấp t một hoặc nhiều đặc tả WSDL khác nhau, và cung cấp một đặc tả của riêng nó về quá trình tổng hợp các dịch vụ này[ 3 ].
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 service mà nó tổng hợp trên đó để mà tƣơng tác trên những service đó. Cũng nhƣ mỗi service đƣợ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à partnerLinkType và partnerLink[ 28 ].
21
Hình 2.2- Quan hệ giữa partnerLink và partnerLinkType. PartnerLinkType:
Một partnerLinkType mô tả quan hệ “đối thoại” giữa hai service bằng cách định nghĩa các role (đóng vai trò của mỗi service) và chỉ định portType để nhận thông điệp
PartnerLink:
Các service 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. Ví dụ về PartnerLink:
22 1 2 3 4 <partnerLinks>
<partnerLink name="ncname" partnerLinkType="qname"
myRole="ncname"? partnerRole="ncname"?> </partnerLink>
</partnerLinks>
Bảng 2.1-Ví dụ về 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 các BPEL service 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 BPEL Webservice. Ngƣợc lại, thuộc tính partnerRole đƣợc dùng để chỉ vai trò của một service bên ngoài.
2.1.3 Cấu trúc của một tiến trình P L
Cấu trúc của một tiến trình BPEL đƣợc mô tả trong tập tin BPEL nhƣ sau: 1 2 3 4 5 6 7 8 9 10 11 12
<bpel:process name="helllo" >
<bpel:import location="aloArtifacts.wsdl"
namespace="http://eclipse.org/bpel/sample" importType="http://schemas.xmlsoap.org/wsdl/" /> <bpel:partnerLinks> </bpel:partnerLinks> <bpel:variables> </bpel:variables>
<bpel:sequence name="main">
</bpel:sequence>
</bpel:process>
Bảng 2.2-Cấu trúc file 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).
23
Việc tích hợp các dịch vụ cung cấp hỗ trợ cho chuyển đổi (theo các tài liệu XML) mà đi ngoài sự hỗ trợ của Xpath[ 28 ].
Các khái niệm chính:
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 activity (đƣợc trình bày chi tiết bên dƣới). Mỗi activity có một nhiệm vụ cụ thể trong tiến trình BPEL. Bản thân sequence cũng là một activity, có thể chứa các cấu trúc song song cũng nhƣ tuần tự khác.
2.1.4 Các thành phần và ký hiệu trong P L
Một tiến trình BPEL đƣợc thể hiện qua các Activity, các Activity 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 BPEL 2.0 thì các Activity đƣợc chia làm ba nhóm cơ bản nhƣ sau:
Basic Activity: là các Activity đơn thể, nó không thể chứa đƣợc bất kỳ các Activity nào khác bên trong nó nữa.
Structure Activity: là các Activity có cấu trúc, nó có thể chứa đƣợc các Activity khác bên trong nó.
Faul Handle Activity: các Activity 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 Activity khác nhau. Bảng sau mô tả chi tiết về các Activity trong BPEL 2.0:
24
Tên Activity Ký hiệu Các trường hợp sử dụng
Các Activity cơ bản Empty
Là một activity đặc biệt, không làm gì hết khi đƣợc gọi. Activity này đƣợc dùng khi cần có một activity nhƣng không thật sự cần một hành động nào xảy ra. Invoke Gọi một webservice để thực hiện một tác vụ nào đó Receive Nhận một thông điệp t một service partner. Thông
thƣờng đây là activity bắt đầu một tiến trình mới Reply Gửi trả một thông điệp cho một đối tƣợng bên ngoài
tiến trình Opaque
Activity
Là một Activity 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…)
Các Activity điều khiển và có cấu trúc
If/Else Định nghĩa cấu trúc điều kiện
Pick
Đinh 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…)
While Lặp lại một tiến trình con nào đó trong process ở dạng while
25
RepeatUntil Lặp lại một tiến trình con nào đó trong process ở dạng do..while
Foreach Định nghĩa vòng lặp để duyệt qua một tập hợp
Wait D ng tiến trình trong một khoản 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 Activity
Scope
Dùng để chia nhỏ tiến trình thành các activity 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 Activity 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à activity dùng để thụ lý lỗi. Khi có lỗi xảy ra thì activity 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ƣ activity 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
Bảng 2.3-Các Activity trong BPEL 2.0
Sau đây là mô tả chi tiết và các trƣờng hợp sử dụng của t ng Activity: Receive
Khi một tiến trình BPEL cần nhận một thông điệp thì activity receive sẽ đƣợc sử dụng. Receive activity 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ụ đối tác mà nó cần phải gọi thông qua PartnerLink và Operation. Để thực thi đƣợc thì receive activity 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 receive activity đƣợc thể hiện nhƣ sau:
26 1 2 3 4 5 6 7 8 9 10 11 12 13
<receive partnerLink=”NCName” portType=”QName”?
operation=”NCName”
variable=”BPELVariableName”? createInstance=”yes|no”?
messageExchange=”NCName”?
standard-attributes> standard-elements
<correlations>?
<correlation set=”NCName” initiate=”yes|join|no”?>+
</correlations>
<fromParts>?
<fromPart part=”NCName” toVariable=”BPELVariableName”/>+
</fromParts> </receive>
Bảng 2.4-cấu trúc XML của receive Invoke
Để gọi hoặc thực hiện một dịch vụ web nào đó thì ta sử dụng invoke activity. Invoke activity 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 invoke activity 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-hồi đáp”). Hình 2.2 mô tả một trƣờng hợp sử dụng cụ thể của invoke activity,ở đây thì dịch vụ tìm kiếm tên khách hàng đƣợc gọi thực hiện:
27
Cấu trúc XML của invoke đƣợc mô tả nhƣ sau: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
<invoke partnerLink=”NCName” portType=”QName”?
operation=”NCName”
inputVariable=”NCName”? outputVariable=”NCName”?
standard-attributes> standard-elements
<correlations>?
<correlation set=”NCName” initiate=”yes|join|no”?
pattern=”request|response|request-response”/>+
</correlations>
<catch faultName=”QName”? faultVariable=”NCName”?
faultMessageType=”QName”? faultElement=”QName”?>* activity </catch> <catchAll>? Activity </catchAll> <compensationHandler>? Activity </compensationHandler> <toParts>?
<toPart part=”NCName” fromVariable=”BPELVariableName”/>+
</toParts>
<fromParts>?
<fromPart part=”NCName” toVariable=”BPELVariableName”/>+
</fromParts>
</invoke>
Bảng 2.5-Cấu trúc Xml của invoke Reply
Một reply activity đó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 Receive Activity ở dạng onMessage (thông điệp) hoặc onEvent (sự kiện). Một Reply Activity thì sẽ có cùng một partnerLink và operation với Receive Activity tƣơng ứng của dịch vụ web đối tác. Để thực thi đƣợc thì Reply Activity 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ì
28
Reply Activity 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 Throw activity để trả về một ngoại lệ nếu xử lý trong tiến trình bị lỗi nhƣ hình 2.4:
Hình 2.4-Trƣờng hợp sử dụng của Reply Cấu trúc xml của Reply nhƣ sau:
1 2 3 4 5 6 7 8 9 10 11 12 13
<reply partnerLink=”NCName” portType=”QName”?
operation=”NCName”
variable=”BPELVariableName”? faultName=”QName”?
messageExchange=”NCName”?
standard-attributes> standard-elements
<correlations>?
<correlation set=”NCName” initiate=”yes|join|no”?>+
</correlations>
<toParts>?
<toPart part=”NCName” fromVariable=”BPELVariableName”/>+
<toParts>
</reply>
29
Validate
Một validate activity 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 activity 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 ném 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 Assign Activity. Hình 2.5 mô tả một trƣờng hợp sử dụng của Validate:
Hình 2.5-Trƣờng hợp sử dụng của Validate Cấu trúc Xml của validate đƣợc mô tả nhƣ sau:
1 2 3 4
<validate variables=”BPELVariableName-list”
standard-attributes> standard-elements </validate>
Bảng 2.7-Cấu trúc Xml của Validate Assign
Assign activity đƣợ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
30
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: 1 2 3 4 5 6 7 8 9 10 11
<assign validate=”yes|no”? standard-attributes>
standard-elements
(<copy keepSrcElementName=”yes|no”?
ignoreMissingFromData=”yes|no”?>
from-spec (see below) to-spec (see below)
</copy> |
<extensionAssignOperation>
...assign-element-of-other-namespace...
</extensionAssignOperation>) +
</assign>
Bảng 2.8-Cấu trúc Xml của Assign Throw
Throw Activity đƣợc sử dụng để trả ra các lỗi trong quá trình thực thi của một tiến trình BPEL. Bạn có thể thiết lập các các link để dẫn đến Throw Activity t các Activity khác trong trƣờng hợp xảy ra lỗi nhƣ hình 2.6:
31
Cấu trúc Xml của Throw Activity đƣợc thể hiện nhƣ sau: 1
2 3 4
<throw faultName=”QName” faultVariable=BPELVariableName”?
standard-attributes standard-elements
</throw>
Bảng 2.9-Cấu trúc Xml của Throw Rethrow
Rethrow activity đƣợc sử dụng trong trƣờng hợp bạn không muốn ném ra ngoại lệ và d ng tiến trình tại chính điểm gây ra lỗi mà muốn ném nó lên một cấp xử lý cao hơn. Rethrow đƣợc dùng để bắt tất cả các lỗi đƣợc ném ra t tiến trình con bên dƣới bởi Throw activity.Ví dụ trong hình 2.7:
32
Cấu trúc Xml của Rethrow Activity đƣợc thể hiện nhƣ sau: