Nghiên cứu kiến trúc hướng dịch vụ (service-Oriented architecture) và ứng dụng

đồng bộ. Xử lý hoàn thành khi tất cả xử lý bên trong đều hoàn thành. Một xử lý bên trong cũng có thể coi là hòan thành khi nó bị bỏ qua, không được kích hoạt do điều kiện kích hoạt của nó không thỏa. Một ví dụ đơn giản trong đó chứa hai activitiy . Hai xử lý này sẽ được kích hoạt khởi động cùng lúc ngay khi bắt đầu. Và kết thúc sau cả hai khi lời gọi trên nhận được phản hồi (giả sử rằng hai lời gọi trên là request/response). <invoke partnerLink="AmericanAirlines" Trang 208 portType="aln:FlightAvailabilityPT" operation="FlightAvailability" inputVariable="FlightDetails" /> <receive partnerLink="AmericanAirlines" portType="aln:FlightCallbackPT" operation="FlightTicketCallback" variable="FlightResponseAA" /> <invoke partnerLink="DeltaAirlines" portType="aln:FlightAvailabilityPT" operation="FlightAvailability" inputVariable="FlightDetails" /> <receive partnerLink="DeltaAirlines" portType="aln:FlightCallbackPT" operation="FlightTicketCallback" variable="FlightResponseDA" /> Tổng quát hơn, một xử lý ngòai khả năng hỗ trợ thực hiện cùng lúc các xử lý bên trong, nó còn có thể điều khiển đồng bộ hóa giữa những xử lý thông qua các ràng buộc đồng bộ (synchronization dependencies). được dùng để biểu diễn các mối ràng buộc này. Tất cả các của một đều phải được khai báo bên trong . Một được xác định bởi một tên (name) và thể hiện ràng buộc giữa hai xử lý. Trong đó • Một xử lý sẽ giữ vai trò là source của link (xử lý đó sẽ chứa với thuộc tính “linkName” là tên của , và còn có thể có thêm một thuộc tính “transitionCondition” với giá trị là một biểu thức bool – mặc định là “true”) • Xử lý còn lại sẽ giữ vai trò là target của link (xử lý đó sẽ chứa với thuộc tính linkName là tên của ). Target activity sẽ không được thực hiện chừng nào tình trạng của link đó chưa được kích họat. Tình trạng của một link gọi là được kích hoạt khi source activity của link đó kết thúc và transitionCondition của có giá trị “true”. Ngoài ra, target activity có thể có thêm thuộc tính “joinCondition” (sẽ được trình bày trong phần sau) Trang 209 Một được khai báo trong phải có đúng một source activity và một target activity. Và giữa hai xử lý được ràng buộc bởi nhiều nhất là một link, nghĩa là, với hai khác nhau thì không được có cùng source activity và cùng target activity. Một được gọi là “cross boundary” khi các source activity hay target activity của link được chứa trong một construct trong khi link được khai báo bên ngòai construct đó (một construct được tạo ra bởi một xử lý có cấu trúc). Ví dụ ở trên có thể minh họa cho trường hợp “cross boundary” (source activity của link ‘CtoD’ ỏ trong construct tạo ra bởi trong link đó được khai báo trong construct của ). Tuy nhiên tình trạng “cross boundary” này không được xảy ra với xử lý , event handler hay compensation hander. Riêng đối với fault handler thì link được phép “cross boudary”, trong đó fault-handler phải chứa source activity và target activity sẽ thuộc scope bao ngoài scope của fault-handler. Cuối cùng, một điểm nữa cần quan tâm đó là không được dùng link để tạo chu trình giữa hai xử lý, nghĩa là: B chỉ thực thi khi A hoàn thành và A chỉ thực thi khi B hoàn thành. Trang 210 Ngữ nghĩa của link (link semantic) Trong các phần còn lại chúng ta sẽ qui ước như sau: ► Những link mà trong đó A là source activity sẽ được gọi là link đầu ra của A. ► Những link mà trong đó A là target activity sẽ được gọi là link đầu vào của A. ► Nếu xử lý X là target và Y là source của link, thì ta nói rằng ‘X phụ thuộc đồng bộ vào Y’. Mỗi target activity đều có một “join condition” kèm theo (được hiểu ngầm hoặc khai báo tường minh). Các join condition được khai báo tường minh bằng các element ở bên trong element. Và giá trị của là một biểu thức bool. Ý nghĩa của joinCondition là được dùng để kiểm tra một xử lý có đủ điều kiện kích hoạt hay không. Trạng thái “sẵn sàng” của một xử lý sẽ được quyết định bởi các xử lý có cấu trúc chứa nó. Ví dụ, xử lý thứ hai trong một sẽ ở trạng thái “sẵn sàng” ngay khi xử lý thứ nhất hoàn thành ; một xử lý bên trong ở trạng thái “sẵn sàng” ngay khi được kích hoạt. Một xử lý đã ở trạng thái “sẵn sàng” và có một hay nhiều imcoming link, thì nó sẽ được kích hoạt khi trạng thái của tất cả các link đầu vào của nó đều đã được kích hoạt và join condition đi kèm theo được có giá trị “true ”. Trạng thái của một link có thể có một trong ba giá trị sau : được kích hoạt, không được kích hoạt và chưa xác định. Mỗi khi bắt đầu thực thi, thì tất cả các link đều có trạng thái là “chưa xác định”. Và ta thấy rằng chu kỳ sống của một link bằng đúng chu kỳ sống của xử lý mà nó được khai báo trong đó. Vai trò của link trong mối quan hệ đồng bộ giữa hai xử lý sẽ được giải thích một cách rõ hơn . Khi xử lý A hoàn thành, các bước sau sẽ được tiến hành : • Đánh giá trạng thái cho các link đầu ra của A. Trạng thái kết quả sẽ là “được kích hoạt” hay “không được kích hoạt”. Để xác định tình trạng của của mỗi link Trang 211 thì transitionCondition của link đó sẽ được đánh giá. Nếu transitionCondition=true thì trạng thái của link là “được kích hoạt”. Ngược lại thì là “không được kích hoạt”. Một điều lưu ý là việc đánh giá transitionCondition được thực hiện sau khi xử lý đã hoàn thành. Vì thế, nếu có bất kỳ lỗi nào xảy ra trong quá trình đánh giá thì cũng sẽ không ảnh hưởng đến kết quả trước đó của xử lý, và lỗi này sẽ được xử lý scope chứa xử lý đó. Nếu target activity ở bên ngòai scope của source activity thì trạng thái của link sẽ là “không được kích hoạt”. Một điều quan trọng cần nhớ là, trường hợp bản thân source activity là một , thì “hoàn thành” không nhất thiết là không được có lỗi trong quá trình xử lý. Trong quá trình xử lý của có thể có lỗi phát sinh. Nhưng vẫn được gọi là “hoàn thành” khi lỗi đó được bắt và xử lý thành công bởi một fault handler của scope. Trường hợp L với source activity là S, lỗi phát sinh nếu có trong quá trình đánh giá transitionCondition sẽ được truyền ra scope bên ngòai S. • Với mỗi xử lý B mà “phụ thuộc đồng bộ” vào A, sẽ kiểm tra: ► B đã ở trạng thái “sẵn sàng” chưa ► Trạng thái của tất cả link đầu vào của B đã “được kích hoạt” chưa • Nếu cả hai điều kiện trên đều thỏa, thì sẽ thực hiện đánh giá joinCondition của B. Nếu joinCondition có giá trị false thì lỗi “bpws :joinFailure ” sẽ được phát sinh, ngược lại, B sẽ được kích hoạt. Nếu trong quá trình thực thi của một xử lý có cấu trúc S, nếu một xử lý X bên trong S một không được thực thi (ví dự như link đầu vào của X “không được kích hoạt”) thì trạng thái của toàn bộ các link đầu ra của X được gán là “không được kích hoạt”. Trường hợp xử lý chứa bên trong nó một xử lý khác, và bên trong khai báo một số trùng tên với các đã được định nghĩa trước đó ở bên ngoài. Khi khai báo các và trong các xử lý mà có tham chiếu đến “linkName” thì tham chiếu sẽ được chuyển đến cùng tên nào mà gần xử lý đó nhất. Trang 212 o Một ví dụ cho trường hợp này <!—This matches F2.L1 and not F1.L1 --> ... ... ... Xử lý Dead-Path_elimination (DPE) Trong một số trường hợp mà luồng điều khiển rất phức tạp với việc sử dụng rất nhiều . Nếu joinCondition của xử lý A có giá trị false thì A sẽ không được thực thi, và một lỗi ‘bpws :joinFailure’ sẽ được phát sinh. Ngoài ra, ta cần phải thực hiện gán giá trị cho các link đầu ra của A là “không được kích hoạt”. BPEL4WS hỗ trợ vấn đề này thông qua việc sử dụng thuộc tính ‘suppressJoinFailure’ trong các xử lý. Nếu giá trị của thuộc tính này là ‘yes’, thì lỗi này sẽ được bắt và xử lý bởi một trình xử lý lỗi đặc biệt (fault handler này sẽ có phần xử lý là một xử lý). Tuy nhiên, bởi vì xử lý (có joinCondition = false) chưa được thực thi, nên các link đầu ra của nó phải được tự động gán trạng thái “không được kích hoạt”. Điều này sẽ giúp cho các xử lý liên quan được bỏ qua, tránh tình trạng ‘ngõ cụt’. Đây là tình trạng mà các xử lý phải chờ để được kích hoạt trong khi các link đầu vào của chúng ỏ tình trạng ‘không xác định.’ Trang 213 Link và các xử lý có cấu trúc Link có thể được dùng để liên kết hai xử lý được chứa trong những xử lý có cấu trúc khác nhau. Khi đó, ta cần thận trọng để đảm bảo luồng xử lý của tiến trình được thực hiện đúng theo ý muốn. Phần này sẽ làm rõ các vấn đề cần quan tâm thông qua phân tích một ví dụ. Mô tả ví dụ: ► Trong một chứa 3 xử lý: một S và hai X và Y. ► Bên trong S: sau khi A hoàn thành, B không được cho đến khi trạng thái của các link đầu vào của nó là X và Y được kích hoạt và joinCondition được đánh giá có giá trị true. ► Khi X và Y hòan thành, joinCondition của B được đánh giá. ► Giả sử rằng biểu thức P(X,B) OR P(Y,B) có giá trị false, khi đó lỗi “bpws:joinFailure” được phát sinh. Và bởi vì, giá trị của thuộc tính suppressionJoinFailure là “no” nên xử lý của bị dừng và cả B và C đều không được thực hiện. ► Trong trường hợp ngược lại, nếu giá trị của suppressionJoinFailure được gán là ”yes”, thì B sẽ bị bỏ qua nhưng C sẽ được thực thi bởi vì lỗi “bpws:joinFailure” sẽ được xử lý trong scope của B. ... ... ... Trang 214 P(X,B) ... P(Y,B) ... ► Sau đó, giả sử ta bổ sung bằng cách liên kết A, B và C với những link (có transitionCondition=”true”) thay vì để chúng trong một . Khi này, cả B và C sẽ luôn luôn được thực thi. Bởi vì transitionCondition của link “AtoB” luôn bằng “true”, nên joinCondition cũng sẽ luôn có giá trị “true”, bất chấp giá trị của biểu thức P(X,B) và P(Y,B). Trang 215 P(X,B) P(Y,B) A.7 Scope Ngữ cảnh xử lý (behavior context) của mỗi xử lý được cung cấp bởi một scope. Một scope có thể cung cấp một fault handler, event handler, compensation handler, data variable, partner link và correlation sets. Cú pháp khai báo của một scope như sau: standard-elements ? ... see above under for syntax ... ? ... see above under for syntax ... ? ... see above under for syntax ... ? ... see above under for syntax ... ? ... activity Mỗi scope có một xử lý chính dùng để phần xử lý của nó. Xử lý này có thể là một xử lý có cấu trúc phức tạp, với nhiều xử lý khác chứa bên trong nó. Scope được chia sẻ bởi tất cả các xử lý bên trong. Trang 216 Một ví dụ về scope với xử lý chính là . Xử lý sẽ chứa 2 xử lý cần xử lý cùng lúc. Một trong hai xử lý này có thể nhận một hay nhiều kiểu lỗi phản hồi. Phần fault handler của scope được chia sẻ bởi cả hai và có thể được dùng để bắt lỗi nhận về. ? ... <invoke partnerLink="Seller" portType="Sell:Purchasing" operation="SyncPurchase" inputVariable="sendPO" outputVariable="getResponse"/> <invoke partnerLink="Shipper" portType="Ship:TransportOrders" operation="OrderShipment" inputVariable="sendShipOrder" outputVariable="shipAck"/> A.7.1 Xử lý dữ liệu data và Partner Link Một scope có thể khai báo các biến và partner link mà chỉ có ý nghĩa sử dụng bên trong scope. A.7.2 Xử lý lỗi trong tiến trình nghiệp vụ Tiến trình nghiệp vụ thường thực hiện các tương tác trong thời gian dài và theo cơ chế bất đồng bộ. Các tiến trình còn thực hiện thao tác trên những dữ liệu nhạy cảm của các cơ sở dữ liệu bên trong hệ thống. Xử lý lỗi trong môi trường này là một yêu cầu khó khăn nhưng cần thiết. Xử lỹ lỗi trong tiến trình nghiệp vụ chủ yếu dựa trên khái niệm “compensation”, nghĩa là xây dựng các xử lý (application-specific) nhằm quay lui lại kết quả của công việc đã được thực hiện trước đó (trong bối cảnh là ta đang thực hiện một công việc lớn – một giao tác- gồm nhiều công việc nhỏ, vì một lý do gì đó mà ta không muốn tiếp tục thực hiện giao tác đó, nên ta sẽ xử lý quay lui lại những phần việc đã được làm). Trang 217 BPEL4WS hỗ trợ thực thi khái niệm “compensation” thông qua cung cấp khả năng xây dựng các thành phần xử lý lỗi (fault handling) và xử lý compensation (compensation handling). A.7.3 Compensation handler Định nghĩa một compensation handler Một compensation handler đơn giản là một lớp bọc cho phần xử lý quay lui (compensation) ở bên trong ? activity Như đã giải thích ở trên, ta có thể thực hiện gọi phương thức compensation từ trong một xử lý , thay vì phải khai báo một . o Gọi compensation trực tiếp từ xử lý <invoke partnerLink="Seller" portType="SP:Purchasing" operation="SyncPurchase" inputVariable="sendPO" outputVariable="getResponse"> <correlation set="PurchaseOrder" initiate="yes" pattern="out"/> <invoke partnerLink="Seller" portType="SP:Purchasing" operation="CancelPurchase" inputVariable="getResponse" outputVariable="getConfirmation"> o Trong ví dụ này, xử lý thực hiện xử lý mua hàng, và trong trường hợp cần quay lui (compensate) xử lý mua hàng vừa thực hiện, thì sẽ gọi phương thức “cancellation” với Trang 218 cùng portType, partnerLink, với kết quả đầu ra của lần mua hàng sẽ làm tham số đầu vào cho phương thức hủy này. o Gọi compensation từ (cú pháp chuẩn) <invoke partnerLink="Seller" portType="SP:Purchasing" operation="CancelPurchase" inputVariable="getResponse" outputVariable="getConfirmation"> <invoke partnerLink="Seller" portType="SP:Purchasing" operation="SyncPurchase" inputVariable="sendPO" outputVariable="getResponse"> <correlation set="PurchaseOrder" initiate="yes" pattern="out"/> Sử dụng một compesation hander Compensation handler có thể được gọi bằng cách dùng xử lý , chỉ ra tên của scope mà chứa compensation handler sẽ được gọi. Một compensation handler của scope chỉ được phép gọi khi scope đã kết thúc một cách bình thường. Lưu ý rằng trong trường hợp xử lý có định nghĩa bên trong nó một compensation handler, thì tên của xử lý này là tên của scope được dùng trong xử lý standard-elements Xử lý chỉ có thể được gọi trong ngữ cảnh sau: Trang 219 o Trong một fault handler của scope mà bao ngoài trực tiếp scope của compensation cần được thực thi. o Trong một compensation handler của scope mà bao ngoài trực tiếp scope của compensation cần được thực thi. A.7.4 Xử lý lỗi Xử lý lỗi trong BPEL4WS nhằm quay lui lại những xử lý xử lý không thành công (đã phát sinh lỗi) trong một scope. Các lỗi sẽ được bắt và xử lý trong các fault handler. Và ngay cả khi quá trình xử lý lỗi không bị vấn đề gì thì scope chứa xử lý phát sinh lỗi cũng không được gọi là kết thúc thành công. Và các compensation handler của những scope này không bao giờ được thực hiện. Việc thiết kế các fault handler trong scope sẽ cho phép ta lựa chọn các các xử lý lỗi khác nhau thông qua các xử lý . Mỗi xử lý sẽ được chỉ định để bắt một lỗi khác nhau, với QName của lỗi và một biến dùng để chứa các thông tin chi tiết. Nếu tên lỗi không được chỉ định, thì đó sẽ bắt tất cả các lỗi. Biến để chứa lỗi được chỉ định bằng cách sử dụng thuộc tính “faultVariable” trong . Biến này là cục bộ của fault handler mà nó được khai báo, và không được sử dụng ở bên ngoài. Ngoài ra, biến này là tùy chọn vì có những lỗi mà không có thông tin kèm theo. Phản hồi lỗi của xử lý là một dạng của lỗi, với tên rõ ràng và phần dữ liệu lỗi sẽ tùy thuộc vào định nghĩa về fault trong WSDL operation. Một dạng lỗi thứ hai là những lỗi được phát sinh do sử dụng xử lý kèm với tên và thông tin về lỗi. sẽ được sử dụng để bắt những lỗi mà không được quan tâm bởi các ở trên. ? * activity ? activity Trang 220 Bởi vì cơ chế linh hoạt trong việc cho phép chỉ định loại fault mà một có thể xử lý, nên sẽ có trường hợp một lỗi chỉ định xử lý bởi nhiều fault handler. Một số nguyên tắc được sử dụng để chọn ra thích hợp xử lý lỗi: • Nếu lỗi không có thông tin dữ liệu đi kèm, thì xử lý mà có faultName trùng với tên của lỗi sẽ được chọn. Nếu không, lỗi sẽ được xử lý bởi • Nếu lỗi có dữ liệu lỗi kèm theo, thì xử lý nào có tên lỗi và kiểu message type của biến lỗi (faultVariable) trùng với những thông tin tương ứng của biến lỗi sẽ được chọn để xử lý. Nếu không có nào thỏa, thì lỗi sẽ được xử lý bởi . Nếu không có hay được chỉ chọn, thì lỗi sẽ không được bắt bởi scope hiện tại mà sẽ được chuyển ra scope bên ngoài trực tiếp của scope hiện tại. Nếu lỗi được chuyển qua cho tiến trình xử lý, và không tìm thấy fault handler phù hợp thì tiến trình sẽ kết thúc một cách “không bình thường”, giống như khi một xử lý được gọi. Trang 221 Scope mà trong đó có xuất hiện lỗi được xem như có kết thúc không bình thường, cho dù lỗi đó có được bắt và xử lý hay không. Và compensation handler của một scope như thế sẽ không bao giờ được gọi. A.7.5 Xử lý sự kiện Toàn bộ tiến trình cùng với mỗi scope đều có thể được kết hợp với các event handler. Các event handle sẽ được gọi cùng lúc nếu sự kiện tương ứng xảy ra. Xử lý bên trong một event handler có thể là bất kỳ dạng xử lý nào ngoại trừ xử lý vì xử lý này chỉ được phép gọi trong fault handler và compensation handler. Có hai loại sự kiện. Loại sự kiện thứ nhất có thể là các thông điệp đến tương ứng với các operation trong WSDL. Loại thứ hai có thể là biến cố về thời gian. Cú pháp khai báo của event handler như sau: ? <!-- there must be at least one onMessage or onAlarm handler --> <onMessage partnerLink="ncname" portType="qname" operation="ncname" variable="ncname"?>* ? + activity * activity Điều cần lưu ý là, không giống như event handler và compensation handler, event handler được xem như một phần trong xử lý của một scope. Các sự kiện dạng thông điệp nhằm lắng nghe loại sự kiện thông điệp, nghĩa là chờ một thông điệp thích hợp được gửi đến. Ý nghĩa và các thuộc tính của và các thuộc tính của nó rất giống với xử lý (partnerLink, portType, operation, variable, correlation sets). Điểm khác biệt đó là không cho phép tạo các thể hiện tiến Trang 222 trình. Vì thế các event handler không có thuộc tính “createInstance”. Khi thông điệp chỉ định đến, xử lý tương ứng sẽ được thực thi. Một ví dụ về cách dùng event handler để hỗ trợ việc kết thúc một tiến trình thông qua một thông điệp từ bên ngoài gửi vào. ... <onMessage partnerLink=“buyer” portType=“car” operation=“cancel” variable=“cancelDetails”> ... ... Các sự kiện dạng biến cố thời gian dùng để biểu diễn một sự kiện dạng timeout. o Thuộc tính “for” chỉ ra khoảng thời gian mà sau đó sự kiện sẽ được chuyển đi. o Thuộc tính “until” chỉ ra thời điểm mà đến lúc đó sự kiện sẽ được chuyển đi. Thời gian bắt đầu tính khi scope của nó bắt đầu. onLarm chỉ có một trong hai thuộc tính được chỉ định. Sự kích hoạt event handler Event handler gắn với scope thì sẽ được kích hoạt ngay khi scope bắt đầu thực thi. Nếu event handler được gắn với tiến trình, thì sẽ được kích hoạt ngay khi thể hiện của tiến trình được tạo ra. Thể hiện của một tiến trình được tạo ra khi xử lý đầu tiên (với createInstance= “yes”) nhận được và xử lý thông điệp tương ứng. Một ví dụ sử dụng event handler để quản lý thời gian sống của thể hiện tiến trình. Đó là ta sẽ nhúng dữ liệu thời gian vào thông điệp dùng để tạo thể hiện tiến trình. Trang 223 <wsdl:definitions targetNamespace="" xmlns:xsd="" ...> <part name=“processDuration” type=“xsd:duration”/> <process name=“orderCar” xmlns:def="" ...> ... <onAlarm for= “bpws:getVariableData(orderDetails,processDuration)” > ... ... ... <variable name=“orderDetails” messageType="def:orderDetails"/> ... <receive name=“getOrder” partnerLink=“buyer” portType=“car” operation=“order” variable=“orderDetails” createInstance=“yes”/> ... Xử lý sự kiện tiến trình • Sự kiện dạng biến cố thời gian Việc tính thời gian cho một sự kiện kiểu biến cố thời gian bắt đầu ngay khi event handler được kích hoạt. Sự kiện sẽ được phát khi đến thời điểm hay sau khi đã qua một khoảng thời gian được chỉ đinh trong các thuộc tính “for” và “until”. Sự kiện loại này chỉ được thực hiện nhiều nhất là một lần và chuyển sang trạng thái “không còn hiệu lực” sau khi thực hiện phần xử lý kèm theo. Trang 224 • Sự kiện dạng thông điệp Sự kiện này xảy ra khi một thông điệp thích hợp được gửi đến. Khi đó, xử lý tương ứng sẽ được thực hiện. Sự kiện loại này có thể được lắng nghe và xử lý nhiều lần trong khi scope tương ứng vẫn còn hoạt động. Vô hiệu hoá các sự kiện Tất cả các event handler gắn với một scope sẽ bị vô hiệu hóa khi quá trình xử lý của scope đó kết thúc một cách bình thường. Một scope sẽ phải đợi cho đến khi tất cả các event handler xử lý xong để thật sự hoàn thành. Trang 225 Phụ lục B SOA VÀ WEB SERVICES B.1 Kiến trúc Web services Web services là một tập các chuẩn đặc tả mở rộng khả năng của các chuẩn có sẵn như XML, URL và HTTP nhằm cung cấp chuẩn truyền thông giữa các hệ thống với nhau. Web services là những thành phần thực thi một số xử lý nghiệp vụ thông qua những dịch vụ và cung cấp những dịch vụ qua mạng, những dịch vụ này có thể được triệu gọi bởi các dịch vụ client bằng cách sử dụng giao thức SOAP trên HTTP. Web services độc lập về ngôn ngữ và độc lập về nền tảng bởi vì nó tách biệt đặc tả ra khỏi cài đặt; nó còn hỗ trợ tích hợp loose coupling giữa các ứng dụng với nhau qua trao đổi các thông điệp đồng bộ và bất đồng bộ thông. Web services dựa trên kiến trúc phân tán trong đó không có bất kì dịch vụ xử lý trung tâm nào và tất cả dạng truyền thông đều sử dụng các giao thức chuẩn. Các giao thức không được có bất kì ý nghĩa ngầm định nào bên trong mà phải được mô tả rõ ràng. Một trong những đặc tính quan trọng của mô hình tính toán dựa trên Web services là ở đó cả các client và Web services đều không cần biết cài đặt của nhau. Kiến trúc Web services cung cấp nhiều thành phần cho phép các ứng dụng client tìm kiếm và sử dụng những Web services mình cần một cách động. Web services hứa hẹn mang đến khả năng tạo ra các môi trường phân tán trong đó bất kì ứng dụng nào, hoặc bất kì component ứng dụng nào cũng đều có thể kết hợp với nhau dễ dàng với tính độc lập nền tảng, và độc lập ngôn ngữ (language-neutral). Web service có thể được sử dụng vào các mục đích đơn giản như đang nhập vào một trang web hay với mục địch phức tạp như xử lý nghiệp vụ giao dịch vay mượn giữa các công ty với nhau. Điểm khác biệt chính của Web services với các công nghệ phân tán trước đây như Win32, J2EE và CGI là ở sự chuẩn hoá. Web services sử dụng XML, một ngôn ngữ độc lập trong việc biểu diễn dữ liệu, làm ngôn ngữ trao đổi thông tin. Bởi vậy khi được kết hợp với nhau, khả năng tích hợp phần mềm và đa kết nối giữa những mô hình web Trang 226 services thật đáng kinh ngạc. Thêm vào đó, các chuẩn Web services mới còn hỗ trợ các tình năng cao cấp như hỗ trợ giao dịch, bảo mật, quy trình nghiệp vụ, vân vân… Mô hình web services dạng đơn giản định nghĩa cách thức tương tác giữa Service Requester, Service Provider, và Service Directory như sau : Bên sử dụng dịch vụ tìm kiếm các dịch vụ trong một UDDI Service Directory. Chúng sẽ lấy thông tin mô tả WSDL của các Web services cung cấp bởi Service Providers từ trước thông qua Service Directory. Sau khi lấy được mô tả WSDL, bên yêu cầu dịch vụ kết nối đến nhà cung cấp dịch vụ bằng cách triệu gọi các dịch vụ thông qua giao thức SOAP. Web services cơ bản bao gồm các khái niệm SOAP, WSDL, và UDDI. Chúng ta sẽ lần lượt phân tích trong các phần sau. Cần lưu ý là các chuẩn trên có thể được kết hợp với nhau hoặc dùng độc lập tùy trường hợp cụ thể. Trang 227 B.2 Các đặt trưng của Web services B.2.1 Loosely coupled Loosely coupled nghĩa là các Web Service và chương trình triệu gọi chúng có thể thay đối độc lập với nhau thay vì phải thiết kế lại những thành phần liên quan ở hai bên mỗi khi có sử thay đối. Cũng có thể thay đổi Web service interface mà không làm ảnh hưởng đến khả năng tương tác của client với dịch vụ đó. Trong khi đó, với một hệ thống có tính tightly coupled, nghiệp vụ ở phía client và ơ server phải ràng buộc chặt chẽ với nhau, mỗi khi cố một interface thay đổi thì phía còn lại cũng phải được cập nhật. Xu hướng hiện nay là phát triển các kiến trúc có tính loosely coupled để các hệ thống phần mềm trở nên dễ quản lý hơn , làm cho khâu tích hợp các hệ thống khác nhau cũng trở nên dễ dàng hơn. B.2.2 Tính đóng gói Tính đóng gói (Encapsulated) nghĩa là phạm vi bên ngoài của mỗi Web service không được biết đến cài đặt của Web Service đó. Các chức năng chỉ được cung cấp thông qua các interface mà Web Service đó cung cấp. Về bản chất, Web Service trừa tượng hoá cài đặt của nó qua interface, tương tự như cách XML tách biệt thông tin ra khỏi xử lý. Web Service kế thừa tính đóng gói từ những kiến trúc hướng đối tượng dựa trên Java, C++ và COM. B.2.3 Contracted Contracted nghĩa là các hành vi của Web Service bao gồm cách thức kết nối, ràng buộc, các tham số đầu vào đầu ra đều được cung cấp đến người sử dụng Web Service đó. B.2.4 Giao thức chuẩn Web Service là một tập các chuẩn mở và phi thương mại. Web Service còn dựa trên nền tảng XML để định dựa dữ liệu và HTTP làm giao thức truyền dữ liệu, ngoài ra còn có SOAP, WSDL và UDDI là các chuẩn nền tảng của Web Service cũng dựa trên XML. Các chuẩn này có thể là đã cũ nhưng nếu không dựa trên đó, Web Service sẽ được triển khai như những hệ thống đóng, độc quyền và đặc trưng cho mỗi nhà cung Trang 228 cấp trao đối với nhau trên một nền tảng cố định. Tính mở của đặc tả Web Service cho phép nhiều nhà cung cấp và tổ chức trình thể hiện những cách nhìn đa dạng góp phần phát triển các công nghệ Web Service.. B.2.5 Tự định nghĩa Web Service tự định nghĩa chính nó. Tính tự định nghĩa (self-defining) là một đặc tính của XML được tận dụng trong những công nghệ nền tảng của Web Service như SOAP và WSDL. B.2.6 Tìm kiếm và triệu gọi động Bằng cách tận dụng công nghệ UDDI , một Web Service consumer có thể định vị và triệu gọi một Web Service trong khi chạy mà không cần biết trước cụ thể Web Service nào cài đặt, cung cấp chức năng mình mong muốn. B.3 Lợi ích của Web services Lợi ích của Web Service có thể tóm gọn trong một đoạn như sau : “Web Service cung cấp một cơ chế đơn giản để kết nối những ứng dụng lại với nhau bất kể công nghệ hoặc thiết bị chúng đang sử dụng hoặc vị trí. Web Service dựa trên các chuẩn giao thức được hỗ trợ rộng rãi trên internet nhằm giảm chi phí liên lạc. Cách tiếp cận có tính loose coupling hỗ trợ đa kết nối và chia sẻ thông tin giữa các dịch vụ, mà các được đó tự định nghĩa và có thể được tìm thấy một cách tự động” . Ta sẽ lần lượt tìm hiểu chi tiết lợi ích thương mại và lợi ích kỹ thuật của Web Service. ¾ Web Service có thể được truy cập ở mọi nơi, mọi lúc, hầu như trên bất kì công nghệ và thiết bị nào hỗ trợ Web Service. Lợi ích thương mại– Tăng hiệu suất quy trình nghiệp vụ Lợi ích kỹ thuật – Giảm chi phí Tăng hiệu suất của quy trình nghiệp vụ bằng cách giảm chi phí và thời gian kết nối các ứng dụng với nhau. Giảm chi phí kết nối Tăng khả năng truy xuất dữ liệu theo gian thực, kết nối từ xa đến các nguồn dữ liệu Giảm mức độ phức tạp của quá trình tích hợp Hỗ trợ thương mại thời gian thực Độc lập nền tảng và độc lập công nghệ Hỗ trợ khác hàng, đối tác và nhân viên Trang 229 ¾ Dựa trên các chuẩn giao thức được hỗ trợ rộng rãi trên internet Lợi ích thương mại và kỹ thuật – Giảm chi phí và lựa chọn Lợi ích từ các « chuẩn mở » Không phụ thuộc vào một công nghệ độc quyền nào Nhiều nhà cung cấp khác nhau Giảm chi phí công nghệ ¾ Loosely coupled Lợi ích thưong mại – Tăng cường quan hệ Lợi ích kỹ thuật – Giảm chi phí bảo trì Tạo thuận tiên cho vệic thêm vào hay thay đổi đối tác. Thay đổi về mặt hệ thống không hưởng đến nghiệp vụ Giảm chi phí bảo trì Giảm ảnh hưởng của thay đổi Sử dụng lại các thành phần có sẵn ¾ Hỗ trợ đa kết nối Lợi ích thưong mại Lợi ích kỹ thuật – Tiết kiệm chi phí Giảm số lượng phần mềm,công cụ, kỹ năng cần thiết trên nhiều lĩnh vực khác nhau. Tiếp cận vững chắc cho mọi bối cảnh bài toán Một kiến trúc chung cho mội bốii cảnh bài toán (ví dụ như bảo mật) ¾ Tự mô tả Lợi ích thương mại – Tiếp cận thị trường Lợi ích kỹ thuật – Rút ngắn chu kì phát triển Tăng thời gian tiếp cận thị trường bởi vì các kết nối đến đối tác và khách hàng bây giờ trở nên nhanh hơn và tự động. Tạo điều kiện thuận tiện cho đối tác hợp tác làm ăn. Giảm công sức phát triển vì dịch vụ được tự động hoá. Giảm ảnh hưởng của những thay đổi, tự động phản ứng với những thay đổi Dịch vụ có thể được triệu gọi tự động mà không cần đến sự can thiệp của nhân viên phát triển phần mềm ¾ Tự động tìm kiếm Lợi ích thương mại Lợi ích kỹ thuật – Rút ngắn chu kì phát triển Tạo điều kiện thuận tiện khách hàng tìm đến dịch vụ của ta. Dễ dàng tìm kiếm các đối tác mới và dịch vụ của họ. Giảm hoặc không cần loại bỏ công sức phát triển hỗ trợ các kết nối mới. Trang 230 B.4 SOAP SOAP là một đặc tả việc sử dụng các tài liệu XML theo dạng các thông điệp. Bản thân SOAP không định ra các ngữ nghĩa ứng dụng hoặc cách cài đặc chi tiết. SOAP cung cấp một cơ chế đơn giản và gọn nhẹ cho việc trao đổi thông tin có cấu trúc và định dạng giữa các thành phần trong một môi trường phân tán sử dụng XML. SOAP được thiết kế dựa trên những chuẩn nhằm giảm chi phí tích hợp các hệ thống phân tán xây dựng trên nhiều nền tảng khác nhau ở mức càng thấp càng tốt. Đặc tả về SOAP định nghĩa một mô hình trao đổi dữ liệu dựa trên 3 khái niệm cơ bản: các thông điệp là các tài liệu XML, chúng được truyền đi từ bên gửi đến bên nhận, bên nhận có thể chuyển tiếp dữ liệu đến nơi khác. Khái niệm cơ bản nhất của mô hình SOAP là việc sử dụng các tài liệu XML như những thông điệp trao đổi. Điều này có nhiều ưu điểm hơn các giao thức truyền dữ liệu khác. Các thông điệp XML có thể được tổng hợp và đọc với một bộ soạn thảo text đơn giản, ta có thể làm việc với XML trên hầu hết mọi nền tảng. Sau đây là một ví dụ về một thông điệp SOAP : <soap:Envelope xmlns:soap="" soap:encodingStyle=" /encoding/"> Hello world! Khi trao đổi các thông điệp SOAP, có hai thành phần liên quan: bên gửi và bên nhận. Thông điệp sẽ được chuyển từ bên gửi sang bên nhận. Đây là ý niệm đơn giản nhất trong trao đổi thông điệp SOAP. Trong nhiều trường hợp, kiểu trao đổi này không cung cấp đủ chức năng. Nhưng đây là mô hình cơ bản, dựa trên đó sẽ phát triển các mô hình trao đổi phức tạp hơn Trang 231 Hình B-1 – Một SOAP Operation đơn giản Một cấu trúc SOAP được định nghĩa gồm các phần: , và . Hình B-2 – Cấu trúc thông điệp SOAP Envelop là thành phần gốc của một thông điệp SOAP, nó chứa các thành phần Header và Body. Thành phần Header là một cơ chế mở cho phép thêm các tính năng vào bên trong một thông điệp SOAP. Mỗi thành phần con của Header gọi là một Header Entry. Các Header Entry dùng để diễn giải , quy định một số ngữ nghĩa của thông điệp SOAP. Các ứng dụng có thể xử lý và định tuyến các thông điệp dựa trên thông tin header và thông tin bên trong thông điệp đó. Đây là ưu điểm mà các mô hình kiến trúc như DCOM, CORBA và RMI không có được, vì các protocol header của chúng phải được chỉ định chi tiết cho mỗi ứng dụng. B.5 WSDL Web Sevice Description Language (WSDL) định nghĩa một lược đồ XML dùng để mô tả cấu trúc các dịch vụ theo dạng XML. Nó cung cấp thông tin cho các hệ thống phần tán và cho phép các ứng dụng trao đổi với nhau một cách tự động. Trong khi SOAP tập trung vào việc trao đổi thông tin giữa bên yêu cầu và bên cung cấp thì WSDL mô tả dịch vụ được cung cấp bởi bên cung cấp và được xem như một công thức để phát sinh các thông điệp SOAP đến các dịch vụ. Trang 232 Một tài liệu WSDL mô tả một Web Service như một tập các đối tượng trừu tượng gọi là các “ports” và “endpoint”. Một tài liệu WSDL cũng định nghĩa bên trong nó những hành vi. Hành vi tương ứng với “operation” và dữ liệu tương ứng với “message”. Một tập các hành vi liên quan được nhóm lại vào trong một “portType”. Một ràng buộc kết nối (binding) chỉ định một giao thức mạng và đặc tả định dạng dữ liệu cho một portType cụ thể. Kế đến một port được định nghĩa bằng cách kết hợp một địa chỉ mạng với một binding. Nếu một client có được một tài liệu WSDL và tìm thấy binding và địa chỉ cho mỗi port, nó có thể gọi các phương thức của dịch vụ theo đúng giao thức và định dạng dữ liệu đã đặc tả. Phần tử gốc của tất cả các tài liệu WSDL luôn là phần tử . Nó chứa bên trong sáu thành phần chia thành hai nhóm : thông tin trừa tượng và thông tin cụ thể. • Thông tin trừu tượng a. types b. messages c. portType • Thông tin cụ thể d. bindings e. services Các thành phần chứa những tham chiếu lẫn nhau như trong hình. Trang 233 Sau đây là một ví dụ mẫu về một đặc tả WSDL. <definitions xmlns:soap="" xmlns:s="" xmlns:s0="" targetNamespace=""> <soap:binding transport="" style="document" /> <soap:operation soapAction="" style="document" /> <soap:address location="" /> Trang 234 B.6 UDDI Về cơ bản Universal Description, Discovery, and Intergration (UDDI) là một nơi mà các tổ chức đăng ký và tìm kiếm các Web Service. Nó đóng vai trò như service broker cho phép người sử dụng dịch vụ tìm đúng nhà cung cấp dịch vụ cần tìm. UDDI hỗ trợ chức năng: • Thực hiện tìm kiếm, định vị những doanh nghiệp cung cấp dịch vụ hay sản phẩm theo phần loại theo vùng địa lý. • Thông tin về một nhà cung cấp dịch vụ bao gồm địa chỉ, thông tin liên lạc và các định danh. • Thông tin kỹ thuật (Technical information) về Web service mà doanh nghiệp cung cấp (ví dụ như cách sử dụng dịch vụ được cung cấp). Để sử dụng đến các dịch vụ của UDDI, bản thân UDDI cung cấp một tập hàm API dưới dạng SOAP Web Service. Tập API được chia làm hai phần: Inquiry API dùng truy vấn và Publisher’s API dùng đăng ký. Phần API dùng để truy vấn bao gồm hai phần con : một phần dùng để tạo ra các chương trình cho phép tìm kiếm và duyệt thông tin trên một UDDI registry, phần còn lại dùng để xử lý lỗi triệu gọi. Thành phần xử lý chính là bộ đăng ký UDDI, đó là một file XML dùng để mô tả một thực thể kinh doanh (business entity) kèm theo các Web service đi cùng. Sử dụng các dịch vụ của UDDI, các doanh nghiệp đăng ký thông tin về những Web service mà họ định cung cấp. Thông tin này đuợc thêm vào UDDI registry thông qua Web site hoặc sử dụng các công cụ lập trình sử dụng các dịch vụ theo đúng đặc tả UDDI programmer’s API. Lược đồ XML UDDI định nghĩa bốn loại thông tin cơ bản để kết nối đến Web service. Trang 235 Như hình trên, cấu trúc thông tin bao gồm : • Business entity Một business entity chức thông tin về công bao gồm tên công ty, một đoạn mô tả ngắn gọn và một vài thông tin liên lạc cơ bản (địa chỉ, số điện thoại, email, v.v….). Mỗi doanh nghiệp được cấp một định danh duy nhất, ví dụ như số D-U-N-S. • Business service Liên kết với mỗi business entity là một danh sách các business service cung cấp bởi business entity đó. Mỗi thành phần chứa thông tin mô tả về dịch vụ, về thông tin phân loại của dịch vụ và danh sách các binding template liên quan đến thông tin kỹ thuật của dịch vụ. Mỗi business service cần có ít nhất một binding template. Trang 236 • Binding template Gắn với mỗi business service là một danh sách các binding template cung cấp thông tin về địa điểm có thể tìm thấy Web Service và làm cách nào để sử dụng nó. Một cấu trúc binding template mô tả thông tin interface của Web Service và các địa chỉ URL. Mỗi bindingTemplate được định danh duy nhất thông qua số phát sinh tự động UUID lưu trong bindingKey. • tModels Mục đích của tModels là dùng để liên kết đến metadata bên ngoài UDDI. Thành phần quan trọng nhất của tModels là một URL trỏ đến một tài liệu mô tả thông tin metadata. Tài liệu này có thể là tài liệu bất kì HTML, Word, .. tùy ý mô tả một đặc tả kỹ thuật nào đó, ví dụ như giao thức mạng, dạng thức trao đổi hoặc luật tuần tự mà thông thường nhất là file mô tả thông tin service WSDL. Có hai thuộc tính cơ bản bên trong một tModel : tModelKey đóng vai trò định danh duy nhất giữa các tModel với nhau và name dùng cung cấp một tên với đầy đủ ngữ nghĩa cho tModel. <businessEntity xmlns="urn:uddi-org:api" businessKey="BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB"> Sample Services a description Symbol service a description ..... TU UT <tModelInstanceInfo tModelKey="123123"> <tModel authorizedName="..." operator="..." tModelKey="123123"> StockQuote Service WSDL description of a Symbol lookup service Trang 237 WSDL source document TU UT <keyedReference tModelKey="UUDI:12313" keyName="uudi- org:types" keyValue="wsdlSpec" /> Tóm lại SOAP, WSDL và UDDI có thể kết hợp với nhau theo sơ đồ sử dụng sau : 1. Nhà cung cấp Web Service mô tả Web Service trong một tài liệu WSDL và đăng ký nó lên một UDDI bằng cách sử dụng Publisher’s API. 2. Một người sử dụng dịch vụ UDDI Inquiry API để tìm thông tin về nhà cung cấp dịch vụ thích hợp. Nếu có, nó sẽ tìm kiếm tiếp tModel rồi từ đó lấy ra tài liệu mô tả WSDL. 3. Một yêu cầu dạng SOAP được tạo ra dựa trên tài liệu mô tả WSDL. 4. Yêu cầu SOAP trên sẽ được gửi đến nhà cung cấp dịch vụ và được xử lý. Trang 238 B.7 Một số chuẩn Web services mới • WS-Security : Mô tả cách thêm vào các header signature và mã hoá vào bên trong thông điệp dạng SOAP, cách thêm vào các token bảo mật như X.509, chứng thực và Keberos. • WS-Policy : Mô tả khả năng và những ràng buộc về bảo mật và chính sách nghiệp vụ giữa thành phần trung gian và địa chỉ endpoint. • WS-Trust : Một framework cho các mô hình trust, cho phép các Web Service cộng tác một cách an toàn và bảo mật. • … B.8 SOA và Web Service SOA là một kiến trúc phần mềm, bao gồm một tập các nguyên tắc thiết kế độc lập với kỹ thuật và công nghệ nhằm liên kết các dịch vụ. SOA bắt đầu với việc định nghĩa thành phần giao tiếp (interface) và sau đó, xây dựng kiến trúc hệ thống như là sự liên kết của các thành phần interface, phần thực thi của các interface và cách thức tương tác giữa các interface. Trong khi đó, Web services lại là một tập hợp các kỹ thuật và công nghệ (SOAP, WSDL, UDDI, HTTP...) được dùng để hiện thực hóa các nguyên tắc thiết kế của SOA. Trong thực tế, khái niệm SOA không phải là một khái niệm hoàn toàn mới, mà đã xuất hiện cách đây khá lâu. Và trong quá khứ đã có rất nhiều kỹ thuật khác được dùng để triển khai một hệ thống SOA như : • Distributed object : như CORBA, J2EE, COM/DCOM • Message-oriented middleware (MOM) : WebSphere MQ, Tibco, Rendezvous • TP monitor: CICS, IMS, Encinia, Tuxedo. • B2B platform: ebXML, RosettaNet Trang 239 Trong phần này, sẽ giải thích rõ một hệ thống SOA dựa trên Web services khác ra sao với một hệ thống SOA dựa trên các kỹ thuật cũ trước đây. • Cách tiếp cận dựa trên API và dựa trên nghiệp vụ ► Sự khác nhau cơ bản giữa việc triển khai một hệ thống SOA dựa trên các kỹ thuật cũ với khi dùng web service đó là ở cách tiếp cận. Các kỹ thuật trước tiếp cận theo cách sử dụng các hàm API trong khi kỹ thuật web services lại sử dụng cơ chế thông điệp. Lợi ích của cách tiếp cận mới đó là tạo ra được nhiều mô hình tương tác đa dạng, linh hoạt hơn như có thể xây dựng nhiều trạm điều khiển trung gian, xử lý vấn đề định tuyến, orchestration và tương quan, ngoài ra còn hỗ trợ độc lập với môi trường truyền dẫn (transport indenpendence). ► Tương tác giữa nhà cung cấp dịch vụ và đối tượng sử dụng dịch vụ không còn đơn giản là những kết nối điểm-điểm nữa. ► Hiệu suất hoạt động của hệ thống được tốt hơn bởi sự hỗ trợ của cơ chế định tuyến giúp định tuyến cho các luồng trao đổi dịch vụ một cách hiệu quả. ► Với những hỗ trợ trong việc sắp xếp, kết hợp, ... và quản lý các dịch vụ sẽ giúp xây dựng toàn bộ các qui trình nghiệp vụ một cách nhanh chóng, dễ dàng và hiệu quả hơn là thiết kế từng thành phần. ► Việc xác định một dịch vụ sẽ hiệu quả hơn thông qua việc sử dụng các thông tin tương quan (correlation information) • Sử dụng các dữ liệu mô tả (metadata) để tăng tính linh hoạt ► Một điểm yếu nữa của các tiếp cận dựa trên API khi triển khai một hệ thống SOA đó là sự hạn chế (thậm chí là hoàn tòan không có) trong thông tin mô tả dịch vụ. ► Web services dựa trên lược đồ XML để hỗ trợ dữ liệu tự mô tả. Ngoài ra Web services hỗ trợ nhiều chuẩn như WSDL để mô tả thông tin web service, UDDI để tạo nền tảng cho việc quản lý các web service cũng như Trang 240 các thông tin mô tả liên quan của web service. Từ đây sẽ hỗ trợ tốt hơn cho quá trình sử dụng và quản lý các tài nguyên mới lẫn cũ, thông qua: - Tích hợp ngữ nghĩa: các nhà quản lý có thể chỉ định thông tin nào cần trao đổi và cách thức trao đổi sẽ như thế nào. - Chuyển đổi thông tin: hỗ trợ việc chuyển đổi các định dạng dữ liệu trong quá trình trao đổi giữa các hệ thống khác nhau. • Tăng khả năng tương thích và tái sử dụng: ► Các hệ thống SOA không phải là các hệ thống kín (monolithic) và cũng không hẳn là phải được xây dựng mới hoàn toàn. Điều này có nghĩa là hệ thống phải có khả năng tương thích cao để có thể tích hợp với các hệ thống khác bên ngoài cũng như là các ứng dụng, tài nguyên sẵn có nhằm thực hiện tái sử dụng một cách có hiệu quả. ► Các kỹ thuật trước gặp rất nhiều khó khăn trong việc giải quyết vấn đề này, thậm chí là không thể, bởi bản thân các kỹ thuật đó không đưa ra được một chuẩn chung để các hệ thống khác nhau (về công nghệ, kỹ thuật, định dạng dữ liệu) có thể tương tác được với nhau. ► Trong khi đó Web service có thể giải quyết các yêu cầu trên một cách dễ dàng, hiệu quả, tiết kiệm được thời gian lẫn chi phí đó là thực hiện bao bọc những chức năng, ứng dụng, dữ liệu, ... thành các services có thể thực hiện quá trình tương tác với các hệ thống mới thông qua các chuẩn của Web service (SOAP, WSDL...) • Vấn đề sử dụng chuẩn ► Các kỹ thuật trước cũng đưa ra một định dạng thông điệp dùng trong quá trình giao tiếp của các dịch vụ. Nhưng thông điệp chung này được xây dựng dựa trên những chuẩn riêng, ràng buộc chặt chẽ với ngôn ngữ và môi trường của hệ thống. Điều này dẫn đến sự rối rắm, trùng lắp và khó tương thích giữa các chuẩn của các hệ thống. Trang 241 ► Trong khi đó, web service được xây dựng dựa trên các chuẩn đạt được sự nhất trí của cộng đồng phát triển (định dạng thông điệp dựa trên các chuẩn của W3C như là XML, và môi trường truyền thông điệp dựa trên SOAP). ► Ngoài ra các chuẩn này có thể tương thích tốt với nhau (ví dụ như WS- Security và WS-Policy). Hơn nữa, các chuẩn của Web service đều được thiết kế để có khả năng mở rộng để có thể phối hợp hoặc tích hợp với các chuẩn mới trong tương lai. Điều này có nghĩa rằng, sẽ không có chuyện lệ thuộc vào một nhà phát triển và khả năng tùy biến sẽ được hỗ trợ tối đa. Tinh thần này phù hợp với nguyên tắc thiết kế của SOA : “Chỉ cần đầu tư một lần vào xây dựng cơ sở hạ tầng, rồi sau này mọi chuyện đều trở nên dễ dàng.” ► Như vậy, tính tương thích và khả năng tích hợp cao đã được thiết kế và xây dựng trong kiến trúc Web service. Ta sẽ thấy rõ hơn những lợi ích của việc triển khai một hệ thống SOA dựa trên Web service qua việc so sánh với hai kỹ thuật khác là CORBA và WebSphere MQ Cơ sở so sánh WebSphere MQ CORBA XML Web services Chuẩn mở Không hỗ trợ Có hỗ trợ (Chuẩn của tổ chức OMG xây dựng) Có hỗ trợ (do tổ chức W3C, OASIS đưa ra) Hỗ trợ nhiều ngôn ngữ lập trình Có Có Có loosely-coupled Có thể Có thể Có Hợp đồng dịch vụ Định nghĩa hợp đồng độc lập với kỹ thuật? Word, Excel, Access CORBA IDL WSDL, Xml Schema, WS-Policy Định nghĩa thông điêp và các tham số COBOL CORBA IDL WSDL, XmlSchema Kiểm tra định dạng thông điệp và tham số Phải tự xây dựng CORBA IDL compiler XmlSchema và Xml parsers. Phân tích thông điệp và tham số Phải tự xây dựng Xử lý tự động dựa theo các ràng buộc về ngôn ngữ Tự động dựa vào các mô hình DOM, SAX, JAAS, JAX-RPC… Quản lý dữ liệu Kiểu dữ liệu Không có CORBA IDL XmlSchema và WSDL Kiểm tra dữ liệu Không có Có hỗ trợ kiểm tra tham số của các phương thức XmlSchema và Xml parser Truy vấn dữ liệu Không có Không có XPath và XQuery Trang 242 Quản lý dịch vụ Lưu trữ interface Không có CORBA interface repository UDDI Định danh dịch vụ Không có CORBA naming service UDDI Cung cấp dịch vụ ra bên ngoài Không CORBA trading service UDDI Vấn đề bảo mật Chứng thực Userid/password IIOP/TLS HTTPs, WS-Security Phân quyền Không có IIOP/TLS SAML, XACML, WS- Security Bảo về dữ liệu Không có IIOP/TLS HTTPs, WS-Security Tích hợp dữ liệu Không có IIOP/TLS HTTPs, WS-Security Các kiểu tương tác Một chiều, đồng bộ Có Có Có Request/Response Có, nhưng không được hỗ trợ mạnh, quản lý thông điệp ở mức ứng dụng Có Có Một chiều, bất đồng bộ Có, và hỗ trợ mạnh Có, nhưng hỗ trợ yếu WS_Reliability, WS- ReliableMessaging Publish/subscribe Có, nhưng yếu Có WS-Eventing, WS- Notìication Giao tiếp ở mức dịch vụ Chuyển đổi định dạng dữ liệu giữa các nền tảng và ngôn ngữ lập trình Mức độ đơn giản: ASCIIÅÆEDCIDIC Có Các thông điệp dạng text nên không cần chuyển đổi Chất lượng của dịch vụ Quản lý phiên làm việc Có Có WS- SecureConversation, WS-Context Cân bằng tải Có Có Không giải quyết bởi chuẩn, việc hỗ trợ tùy thuộc vào các nhà cung cấp sản phẩm Đảm bảo dữ liệu truyền Có Có WS-Reliability, WS- ReliableMessaging Quản lý giao tác Có Có WS-AT, BA, C và WS- CAF. Quản lý dịch vụ Không Không Web services distributed management (WSDM) và WS-Management. Trang 243 Phụ lục C ĐỊNH DẠNG CÁC FILE TRONG PROJECT BPEL DESIGNER File Process Deployment Descriptor (.pdd) Với mỗi tiến trình BPEL cần triển khai ta cần một mô tả triển khai tiến trình (.pdd). File XML này mô tả thông tin cho BPEL engine biết về tiến trình BPEL cần triển khai. Mỗi tiến trình (mỗi file .bpel) có file .pdd riêng của nó. Thành phần sẽ chứa toàn bộ các partner link và tham chiếu WSDL. Lược đồ XML cho file .pdd có thể tìm thấy ở TU [... endpoint reference....]? ? <myRole service="name" allowedRoles="namelist"? binding="MSG|RPC"/>? + + ? relativeDeploymentLocation là đường dẫn tương đối đến file BPEL. Thông thường, giá trị này chỉ là tên file BPEL có trong cùng thư mục với file .pdd. Bởi vì qname là một tên định danh cho nên tả phải sử dụng thuộc tính xmlns để xác định the namespace. Ví dụ <process name="bpelns:loanApprover" location="approver.bpel" xmlns:bpelns=""> Trang 244 The partner link mô tả các role được sử dụng trong mỗi partner của tiến trình. Partner Role Endpoint reference static Được mô tả trong bản mô tả cài đặt (BPEL4WS) dynamic Được định nghĩa trong tiến trình (BPEL4WS) invoker Lấy từ thông tin SOAP header của partner (WS-Addressing) principal Dò từ file Partner Definition (.pdef) dựa trên xác nhận chứng thực Ví dụ ứng dụng BPEL xử lý cho vay thì thông tin về partner link như sau: <wsa:EndpointReference xmlns:approver=""> approver:anyURI <wsa:ServiceName portName="SOAPPort">approver:LoanApprover <wsa:EndpointReference xmlns:assessor='> assessor:anyURI <wsa:ServiceName portName="SOAPPort">assessor:LoanAssessor Thành phần liệt kê mọi file WSDL tham chiếu bởi tiến trình BPEL. Nó được dùng bởi BPEL engine để tạo ra các đại diện WSDL trong bộ nhớ. Sau đây là ví dụ cho tiến trình xác nhận cho vay: <wsdl namespace="" location="wsdl/loandefinitions.wsdl"/> <wsdl namespace="" location="wsdl/loanapproval.wsdl"/> <wsdl namespace="" location="wsdl/loanapprover.wsdl"/> <wsdl namespace="" location="wsdl/loanassessor.wsdl"/> Trang 245 Trong mỗi thành phần , thuộc tính namespace không cần sử dụng tới. Thuộc tính location có thể là tên một file hay một địa chỉ URL bất kì. File wsdlCatalog.xml File wsdlCatalog.xml được chứa trong thư mục META-INF. <wsdlEntry location="string" classpath="slash/separated/classpath/filename.wsdl"/>* Thuộc tính location chỉ đến một file WSDL theo một trong hai cách. Giá trị của nó có thể là: • Thuộc tính location của một thành phần trong phần wsdlReferences của một file .pdd • Thuộc tính location của một element bên trong một file WSDL Khi nạp một file WSDL lúc triển khai, engine xử lý đọc tham chiếu WSDL từ file .pdd và sử dụng thuộc tính location của thành phần như là khoá đến WSDL catalog. Nếu WSDL catalog chứa địa chỉ tương ứng thì engine sẽ nạp file WSDL từ đường dẫn tương ứng. Nếu không có, engine sẽ tự hiểu đây là địa chỉ tuyệt đối URL và sẽ nạp file WSDL từ địa chỉ này. Sau đây là một ví dụ về file wsdlCatalog.xml. <wsdlEntry location="wsdl/loanapproval.wsdl" classpath="wsdl/loanapproval.wsdl"/> <wsdlEntry location="wsdl/loanapprover.wsdl" classpath="wsdl/loanapprover.wsdl"/> <wsdlEntry location="wsdl/loanassessor.wsdl" classpath="wsdl/loanassessor.wsdl"/> <wsdlEntry location="wsdl/loandefinitions.wsdl" classpath="wsdl/loandefinitions.wsdl"/> File Partner Definition (.pdef) ... endpoint reference.... * * Partner link mô tả mối quan hệ giữa các. File định nghĩa partner không nhất thiết phải cần có trong mọi tiến trình BPEL processes, chỉ những tiến trình có endpoint reference dạng principal mới sử dụng chúng. Mỗi khi có yêu cầu chứng thực thì file này được sử dụng để cung cấp thông tin chứng thực.