Quản trị SOA bằng cách sử dụng WebSphere DataPower và WebSphere Service Registry and Repository, Phần 1: Tận dụng các khả năng của WS-MediationPolicy

Sau khi phát hành phiên bản IBM® WebSphere® DataPower® firmware V5.0 và WebSphere Service Registry and Repository V8.0, các nhà phát triển dịch vụ CNTT và các nhà quản trị chính sách bây giờ có thể đính kèm và tác động đến hành vi của ESB (Enterprise Service Bus - Bus dịch vụ doanh nghiệp) có liên quan đến Quản lý mức dịch vụ (Service Level Management), định tuyến và các khả năng trung gian phiên bản khi sử dụng các chính sách dịch vụ (tương tự như cách WS-SecurityPolicy - Các dịch vụ web-Chính sách an ninh, đang làm hiện nay). Bài này giải thích các khả năng và cú pháp của chính sách trung gian mới của DataPower (WS-MediationPolicy v1.6). Bài này cũng trình bày cách tạo, đính kèm và triển khai chúng bằng cách sử dụng các môi trường WSRR và Integration Developer (Nhà phát triển tích hợp) của IBM.

Mario E. De Armas, Kiến trúc sư phần mềm, IBM

Ảnh của Mario De ArmasMario De Armas là một kiến trúc sư phần mềm trong nhóm phát triển WebSphere DataPower Appliance. Anh có nhiều kinh nghiệm về các lĩnh vực và tính năng khác nhau của các thiết bị DataPower. Anh hiện đang hỗ trợ hướng dẫn của DataPower cho việc tích hợp WSRR (Kho lưu trữ và Đăng ký dịch vụ WebSphere), các dịch vụ Web, WS-Policy (Các dịch vụ Web-Chính sách) và chức năng Quản trị SOA. Trước đây anh đã thực hiện các dự án DataPower bao gồm Trưởng nhóm kỹ thuật cho XB60, trình xử lý giao thức AS1, cổng kết nối giữa các doanh nghiệp (B2B), chức năng quản lý thiết bị, tích hợp cơ sở dữ liệu và các tính năng tùy chỉnh giao diện người dùng.



Thomas Burke, Kỹ sư tư vấn phần mềm, IBM

Ảnh của Thomas BurkeThomas Burke là một Kỹ sư nhóm phần mềm tư vấn thuộc nhóm phát triển WebSphere DataPower Appliance. Thomas làm việc trong đội DataPower trong 2.5 năm, công việc quản lý thiết bị, kết nối và quản trị dự án. Trước khi giữ vai trò là một Lãnh đạo nhóm Quản trị SOA trong DataPower, Thomas là leader trong nhóm WebSphere Business Monitor và là kiến trúc sư cho phiên bản đầu tiên của IBM Mobile Portal Accelerator.



Evan Jardine-Skinner, Kỹ sư phần mềm, IBM

Ảnh của Evan Jardine-SkinnerEvan Jardine-Skinner là một Nhà phát triển phần mềm giao diện người dùng thuộc nhóm Service Registry tại Phòng thí nghiệm phần mềm của IBM ở Hursley, Vương Quốc Anh. Anh đã gia nhập IBM và trở thành thành viên của nhóm Voice Systems Services (Các dịch vụ hệ thống giọng nói) vào năm 1998 và sau đó anh đã sử dụng kinh nghiệm về các dịch vụ của mình để tạo nên hiệu quả to lớn trong quá trình phát triển của Voice Response, chủ yếu làm về các tầng tín hiệu báo gọi ISDN. Anh đã thu được kinh nghiệm trong việc chuyển các ứng dụng của IBM sang các nền tảng mới khi làm việc trong trung tâm chuyển đổi, trước khi niềm đam mê về tính khả dụng đã hướng anh tham gia vào nhóm giao diện người dùng Service Registry vào năm 2007. Evan đã tốt nghiệp với một bằng Danh dự về Khoa học máy tính của trường Đại học Bradford, Vương Quốc Anh.



Dave Spriet, Kỹ sư phần mềm cao cấp, IBM

Ảnh của Dave SprietDave Spriet là Kiến trúc sư về Các công cụ ánh xạ và chuyển đổi (Mapping and Transformation Tools Architect) tại Phòng thí nghiệm phần mềm Toronto của IBM, Ca-na-đa. Anh soạn ra các công cụ cho Business Process Management and Connectivity (Quản lý qui trình nghiệp vụ và kết nối) và chuyên về các công nghệ XML và chuyển đổi, bao gồm XML, XSLT, XQuery, XPath và Java. Anh có bằng cử nhân (bằng Danh dự) về Khoa học Máy tính và Khoa học thống kê của trường Đại học McMaster, Canada.



14 05 2013

Tổng quan

Đây là bài đầu tiên trong một loạt ba phần mô tả các khả năng của WS-MediationPolicy (Các dịch vụ Web-Chính sách trung gian), các ví dụ cơ bản, các lời khuyên về việc tạo chính sách riêng của bạn và làm thế nào để gắn nó vào một dịch vụ Web được thiết bị SOA DataPower của WebSphere (sau đây gọi là "thiết bị") dùng như một máy chủ được ủy quyền.

Trong việc triển khai SOA, mục tiêu dài hạn mong muốn là biểu diễn mục định của chính sách theo một khuôn dạng vượt lên trên các chi tiết cấu hình của nền tảng thực thi cụ thể. Vì vậy, nhiều sản phẩm hiện nay (bao gồm cả DataPower và WSRR) hỗ trợ nhiều loại ngôn ngữ chính sách đã chuẩn hóa tập trung vào việc giải quyết các lĩnh vực vấn đề cụ thể (chẳng hạn như WS-SecurityPolicy - Các dịch vụ Web-Chính sách an ninh). Một số lĩnh vực chính sách đã trải qua quá trình chuẩn hóa (ví dụ như W3C, IETF, OASIS và v.v), trong khi các lĩnh vực khác lại tùy thuộc nhà cung cấp hoặc sản phẩm). Tính mở rộng để tạo ra các khả năng, các yêu cầu chính sách đặc trưng cho từng lĩnh vực và các đặc điểm chung có thể được áp dụng cho các dịch vụ Web là mục tiêu cụ thể của đặc tả khung công tác của WS-Policy 1.5. Bài này tập trung vào một lĩnh vực chính sách mới do IBM tạo ra để dùng với thiết bị DataPower nhằm cho phép các khách hàng thể hiện và tác động đến các ủy quyền (proxy) của dịch vụ Web được triển khai trong DataPower.

Lĩnh vực chính sách mới này, có tên là WS-MediationPolicy, có thể thể hiện các điều kiện dựa trên các yêu cầu quản lý lưu lượng (ví dụ, các chính sách QoS hay SLM), để định tuyến các chỉ dẫn và xác nhận hợp lệ lược đồ và để gọi ra các ánh xạ bản định kiểu dịch dữ liệu. Các khả năng này được biểu diễn bởi một ngôn ngữ tạo các xác nhận chính sách và các tham số xác nhận chính sách. Lĩnh vực chính sách mới này trình bày các khả năng trung gian hòa giải nhằm mục đích cung cấp cho các nhà quản trị chính sách và những người triển khai dịch vụ một cách đơn giản để đính kèm các yêu cầu vận hành CNTT vẫn thường được biểu thị lên DataPower từ một nền tảng WSRR - mà không cần phải tìm hiểu các chi tiết cấu hình nền tảng của DataPower!

Bạn có thể sử dụng WS-MediationPolicy để kiểm soát các tương tác giữa các dịch vụ Web và những bên tiêu dùng để đáp ứng các yêu cầu nghiệp vụ cụ thể, chẳng hạn như hạn chế tốc độ lưu lượng truy cập vào một dịch vụ, xác nhận hợp lệ và dịch các định dạng dữ liệu thông báo hoặc định tuyến đến một điểm dịch vụ thay thế khác. Hình 1 cho thấy một cấu trúc liên kết đơn giản với thiết bị DataPower đang dùng làm Điểm thực thi chính sách (PEP) và thực thi WS-MediationPolicy.

Hình 1. DataPower đang thực thi WS-MediationPolicy
Thiết bị DataPower appliance là một PEP thực thi WS-MediationPolicy

Việc sử dụng WS-MediationPolicy giúp mang đến khả năng thực hiện các chỉ dẫn xử lý "if-then-else" để kiểm soát lưu lượng truy cập và dịch các thông báo bằng cách sử dụng các xác nhận chính sách, thay vì trực tiếp sửa đổi cấu hình thiết bị. Ngoài ra, việc định nghĩa các yêu cầu vận hành khi sử dụng các tài liệu chính sách cũng cho phép việc sử dụng lại trong các doanh nghiệp CNTT. Hơn nữa, giá trị của WS-MediationPolicy được tăng lên nhiều lần nhờ sử dụng nó trong WSRR để định nghĩa Các thỏa thuận mức dịch vụ (SLA).

Ví dụ về trường hợp sử dụng Service Gateway (Cổng kết nối dịch vụ)

Trước tiên, chúng ta hãy xem xét một trường hợp sử dụng quản trị SOA điển hình có thể được hưởng lợi từ việc sử dụng một chính sách trung gian.

Giả sử có một dịch vụ có tên là "GlobalWeather" (Bản tin thời tiết toàn cầu), cung cấp thông tin thời tiết trên toàn thế giới dựa vào mã quốc gia và mã bưu điện. Nhà cung cấp dịch vụ muốn bảo vệ dịch vụ đã triển khai này bằng cách hạn chế số lượng lưu lượng được phép truy cập vào điểm dịch vụ.

Nhà cung cấp dịch vụ có thể không có quyền truy cập vào thiết bị DataPower (hoặc có lẽ không có kỹ năng cần thiết) để thực hiện cấu hình cổng kết nối dịch vụ cần thiết để thực thi chính sách nghiệp vụ mong muốn nhằm hạn chế lưu lượng thông báo. Tuy nhiên, do công ty của nhà cung cấp cũng đã chọn dùng quản trị SOA bằng cách sử dụng sản phẩm WSRR, nên chủ sở hữu dịch vụ quyết định sử dụng WSRR và soạn ra và đính kèm một chính sách vào dịch vụ của mình nhờ sử dụng các tính năng giao diện người dùng về quản lý chính sách của WSRR.

Nhà cung cấp dịch vụ tạo ra một WS-MediationPolicy trong WSRR để mô tả các hạn chế dịch vụ mong muốn và đính kèm chính sách này vào dịch vụ GlobalWeather của mình. Lúc đó, WS-Proxy Service (Các dịch vụ Web-Ủy quyền) của thiết bị DataPower phát hiện ra chính sách mới được đính kèm và tiến hành đồng bộ lại sự ủy quyền (proxy) để thực thi cách hoạt động mới.

Nhà cung cấp dịch vụ không phải truy cập hay tìm hiểu các chi tiết cấu hình của DataPower để thực hiện và áp dụng các khả năng quản lý lưu lượng chung cho dịch vụ của họ.

Cùng với khả năng bảo vệ điểm dịch vụ, bây giờ chúng ta cũng đã cho phép sản phẩm quản trị chính sách, chẳng hạn như WSRR, quản trị đúng đắn chính sách của nhà cung cấp dịch vụ. Đây là một yêu cầu quan trọng để nắm lấy qui trình và cách thực hành tốt nhất về quản trị SOA.

Ngoài ra và như được mô tả trong phần tiếp theo, các tác giả chính sách có thể tạo ra các chính sách để thực hiện thêm các kiểu hành động và các mẫu trung gian phổ biến cho hầu hết các nhà cung cấp dịch vụ.

Các mẫu sử dụng cho WS-MediationPolicy

Trước khi thảo luận các chi tiết về cú pháp WS-MediationPolicy, điều quan trọng là phải hiểu rõ một số mẫu sử dụng phổ biến thích hợp với bảng từ vựng chính sách mới này:

  • Loại bỏ dựa vào Điều kiện *
  • Xếp hàng dựa vào Điều kiện *
  • Định tuyến dựa vào Điều kiện *
  • Xác nhận hợp lệ thông báo
  • Dịch thông báo
  • Thông báo (ghi nhật ký) dựa vào Điều kiện *

* Điều kiện là tùy chọn theo cú pháp chính sách trung gian.

Với thông tin chú giải, chúng ta nhận biết các khuôn mẫu chính sách có sẵn trên thiết bị DataPower để tái sử dụng nhằm thực hiện mỗi mẫu. Những mẫu này có trong thư mục store://policies/templates. Các chi tiết về chúng được hiển thị trong Hình 2.

Hình 2. Liệt kê khuôn mẫu WS-MediationPolicy
Một liệt kê khuôn mẫu WS-MediationPolicy có sẵn trên một thiết bị

Mẫu Reject based on Condition - Loại bỏ dựa vào Điều kiện loại bỏ các thông báo vượt quá các tiêu chuẩn SLM đã quy định (ví dụ, loại bỏ các thông báo vượt quá ngưỡng 10 thông báo mỗi phút). Có một ví dụ về mẫu này trong khuôn mẫu wsp-mp-1-6-qos-reject-messages.xml. Tài liệu chính sách này định nghĩa một điều kiện "lớn hơn 10 thông báo mỗi phút" và gọi ra một hành động "loại bỏ" nếu điều kiện đánh giá là đúng (true). Nếu có 11 hoặc nhiều thông báo hơn cùng đến trong khoảng thời gian 1 phút, chúng sẽ bị loại bỏ.

Mẫu Queue based on Condition - Xếp hàng dựa vào Điều kiện cũng tương tự như mẫu "Loại bỏ dựa vào Điều kiện", trừ việc nó hạn chế tốc độ các thông báo mà không loại bỏ chúng một cách dứt khoát. Có một ví dụ về mẫu này trong khuôn mẫu wsp-mp-1-6-qos-queue-messages.xml. Chính sách này cũng tương tự như wsp-mp-1-6-qos-reject-messages.xml, trừ việc nó gọi ra một hành động "xếp hàng" nếu điều kiện đánh giá là đúng. Các thông báo vượt quá ngưỡng này được chứa trong một hàng đợi cho đến khi khoảng thời gian này trôi qua, sau đó chúng sẽ được gửi đi xử lý.

Mẫu Route based on Condition - Định tuyến dựa vào Điều kiện quy định một tầng sau khác thay thế để xử lý thông báo nếu đáp ứng một điều kiện cụ thể. Mẫu này có ích khi có những trường hợp (chẳng hạn như một lịch biểu) ra điều kiện là hãy sử dụng một điểm dịch vụ đã định, thay cho tầng sau mặc định đã quy định cho dịch vụ này. Có một ví dụ về mẫu này trong các khuôn mẫu wsp-mp-1-6-route-after-date.xmlwsp-mp-1-6-route-during-maintenance.xml.

Các điều kiện được dùng trong các mẫu nói trên đều đã dựa vào các tham số SLM (Service Level Management - Quản lý mức dịch vụ), nhưng các ví dụ này chứng tỏ sự linh hoạt của WS-MediationPolicy bằng việc sử dụng một điều kiện dựa trên lịch biểu. Khuôn mẫu "after-date" (sau ngày) thể hiện cách tạo ra một tài liệu chính sách để có hiệu lực vào một thời điểm nào đó trong tương lai. Khuôn mẫu "during-maintenance" (trong lúc bảo trì) trình diễn cách tạo ra một chính sách cần được thực thi theo các khoảng thời gian định kỳ.

Mẫu Message Validate - Message Validate xác nhận hợp lệ một thông báo để bảo đảm nó đáp ứng một lược đồ cụ thể (có lẽ một lược đồ chặt chẽ hơn so với một lược đồ đã quy định trong Ngôn ngữ mô tả các dịch vụ web - WSDL). Mẫu này có ích nếu bạn muốn bảo đảm rằng một thông báo đáp ứng các yêu cầu còn chưa được WSDL đưa ra để tạo ra dịch vụ. Có một ví dụ về mẫu này trong khuôn mẫu wsp-mp-1-6-message-validate.xml. Khuôn mẫu này không có điều kiện nào hết và lúc nào cũng thực hiện hành động xác nhận hợp lệ cho mọi thông báo.

Mẫu Message Translate dịch các thông báo từ một phiên bản này sang một phiên bản khác. Mẫu này mang lại cho một dịch vụ khả năng xử lý nhiều phiên bản thông báo đến, nhưng vẫn cung cấp khả năng dịch thông báo sao cho tầng sau chỉ cần xử lý một phiên bản. Có một ví dụ về mẫu này trong khuôn mẫu wsp-mp-1-6-qos-message-version-translation.xml. Mẫu này cũng không có điều kiện nào, nhưng nó có ba hành động (xác nhận hợp lệ-chuyển đổi- xác nhận hợp lệ). Trong khuôn mẫu này, hành động đầu tiên (xác nhận hợp lệ) bảo đảm rằng thông báo đến tuân theo lược đồ (ví dụ, PurchaseOrder-V10.xsd) mà hành động chuyển đổi đòi hỏi. Hành động chuyển đổi biến đổi thông báo đến sang một định dạng mới (ví dụ, PurchaseOrder-V20.xsd) và hành động cuối cùng xác nhận hợp lệ kết quả của hành động chuyển đổi.

Mẫu Notify based on Condition viết một thông báo vào bản ghi nhật ký thông báo của thiết bị khi có thông báo đến nếu một số điều kiện nhất định được đáp ứng. Không có khuôn mẫu nào có sẵn cho "Thông báo dựa vào Điều kiện", nhưng bạn có thể dễ dàng tạo ra một khuôn mẫu như vậy dựa trên bất kỳ trong số các mẫu có điều kiện nào đã mô tả ở trên.

Các khuôn mẫu được hiển thị trong Hình 2 được sử dụng làm cơ sở cho các tài liệu chính sách mà bạn sẽ viết để thực hiện các chức năng xác nhận hợp lệ thông báo, dịch thông báo và chất lượng dịch vụ. Một sự giải thích ngắn về từng khuôn mẫu trên thiết bị được mô tả trong Bảng 1.

Bảng 1. Các mô tả khuôn mẫu của WS-MediationPolicy
Tên khuôn mẫuMô tảCó tính sẵn sàng không?
wsp-mp-1-6-message-validateThực hiện một hành động xác nhận hợp lệ bằng cách sử dụng lược đồ đã quy định.Không, lược đồ đã quy định trong khuôn mẫu này không tồn tại. Hãy thay thế nó bằng lược đồ mà bạn muốn dùng.
wsp-mp-1-6-message-version-translationXác nhận hợp lệ một thông báo để xem liệu nó có tuân theo một sơ đồ cụ thể không (ví dụ, đã lỗi thời), dịch nó, rồi lại xác nhận hợp lệ nó để bảo đảm tuân theo lược đồ mong muốn.Không, các lược đồ và XSLT đã quy định trong khuôn mẫu này không tồn tại. Hãy thay thế chúng bằng các tạo phẩm mà bạn muốn dùng.
wsp-mp-1-6-qos-errorcount-routeNếu số đếm lỗi thông báo đó vượt quá 5 lỗi trong một phút, thì định tuyến các thông báo tới một điểm cuối khác.Không, hãy thay đổi điểm cuối này sang một điểm cuối mà bạn muốn dùng. Bạn có thể cũng cần điều chỉnh các tham số QoS cho phù hợp với nhu cầu của mình.
wsp-mp-1-6-qos-queue-messagesNếu các thông báo vượt quá tốc độ 10 thông báo mỗi phút, thì xếp hàng các thông báo trong khoảng thời gian này và gửi chúng đi trong khoảng thời gian tiếp theo.Có, nhưng bạn có thể cần điều chỉnh các tham số QoS cho phù hợp với nhu cầu của mình.
wsp-mp-1-6-qos-reject-messagesNếu các thông báo vượt quá tốc độ 10 thông báo mỗi phút, thì loại bỏ chúng.Có, nhưng bạn có thể cần điều chỉnh các tham số QoS cho phù hợp với nhu cầu của mình.
wsp-mp-1-6-qos-token-bucket-queueThực hiện nhiệm vụ QoS bằng cách sử dụng thuật toán SLM TokenBucket, để cho phép phục vụ các sự bùng nổ về các thông báo trong khi thực thi một tốc độ của các thông báo ở "trạng thái ổn định" thấp hơn.Có, nhưng bạn có thể cần điều chỉnh các tham số QoS cho phù hợp với nhu cầu của mình. Hãy đọc các ghi chú trong khuôn mẫu này để hiểu rõ hơn về các thuật toán TokenBucket.
wsp-mp-1-6-route-after-dateĐịnh tuyến tất cả thông báo đến vào một ngày cụ thể hoặc sau một ngày cụ thể tới một điểm dịch vụ thay thế khác.Không, hãy điều chỉnh giá trị ngày tháng và thay đổi điểm dịch vụ này sang một điểm khác mà bạn muốn dùng.
wsp-mp-1-6-route-during-maintenanceĐịnh tuyến tất cả thông báo đến trong một cửa sổ thời gian cụ thể (ví dụ, cửa sổ bảo trì máy chủ) tới điểm dịch vụ thay thế khác.Không, hãy điều chỉnh các giá trị cửa sổ thời gian và thay đổi điểm dịch vụ này sang một điểm dịch vụ khác mà bạn muốn dùng.
wsp-mp-1-6-routeĐịnh tuyến tất cả thông báo tới điểm dịch vụ thay thế khác.Không, hãy thay đổi điểm dịch vụ này sang một điểm dịch vụ khác mà bạn muốn dùng.

Lưu ý rằng các khuôn mẫu được đặt tên theo một cách dễ nhận ra nghĩa của chúng (ví dụ, QoS - Chất lượng dịch vụ, định tuyến và các hoạt động xác nhận hợp lệ thông báo hoặc dịch thông báo). Hãy xem xét các khuôn mẫu để làm quen với một số trong những thứ mà bạn có thể làm với WS-MediationPolicy. Lưu ý rằng các khuôn mẫu chỉ có thể bao phủ một phạm vi các khả năng có hạn. Tuy nhiên, sau khi đọc bài này, bạn sẽ được trang bị để viết nhiều chính sách tinh vi hơn nhằm đáp ứng các nhu cầu hoạt động nghiệp vụ cụ thể của mình.


Cú pháp của WS-MediationPolicy

Để đưa các khuôn mẫu được mô tả trong phần trước lên mức tiếp theo và để đáp ứng các yêu cầu nghiệp vụ của bạn, bạn cần làm quen với cú pháp dùng cho WS-MediationPolicy. Như hiển thị trong Hình 1, bạn có thể áp dụng các xác nhận của WS-MediationPolicy như là các chỉ dẫn xử lý có điều kiện. Cũng có thể dùng các bản trích dẫn đơn giản hơn để có thể bỏ qua tham số có điều kiện và luôn thực thi một tập hợp hành động đã quy định. Các xác nhận của WS-MediationPolicy thường theo một cấu trúc như trong Liệt kê 1.

Liệt kê 1. Cấu trúc WS-MediationPolicy cơ bản (mã giả)
<!-- WS-MediationPolicy assertion begins -->
    <Rule>
        <Condition>
           <!--
                    Declare <Expression> AND/OR <Schedule> here.
                    -->
        </Condition>

        <Action IfCondition="true">
           <!--
                    Declare actions to execute if <Condition> evaluates to true here.
                    -->
        </Action>
        
        <Action IfCondition="false">
           <!--
                    Declare actions to execute if <Condition> evaluates to false here.
                    -->
        </Action>
    </Rule>
    <!-- WS-MediationPolicy assertion ends -->

Các xác nhận của WS-MediationPolicy (WS-MediationPolicy assertions) luôn được chứa trong một phần tử <Rule> (Quy tắc). Phần tử <Rule> này có thể chứa một phần tử <Condition> (Điều kiện) để mô tả một điều kiện đánh giá là true (đúng) hay false (sai) và một hoặc nhiều phần tử <Action IfCondition="xs:boolean">, mỗi phần tử chứa các hành động được thực hiện khi giá trị của thuộc tính IfCondition trùng khớp với kết quả đánh giá phần tử <Condition>. Các xác nhận WS-MediationPolicy thường phù hợp với một trong hai mẫu cơ bản sau đây.

  • Nếu phần tử <Condition> đánh giá là đúng thì thực hiện tất cả các hành động trong <Action IfCondition="true">. Nếu không, thực hiện tất cả các hành động trong <Action IfCondition="false">.
  • Nếu không có phần tử <Condition> nào và có một phần tử <Action>. Hãy thực hiện tất cả các hành động <Action>.

Lưu ý: Một phần tử <Action IfCondition="true"> có cùng nghĩa về cú pháp với <Action> (được hiểu ngầm là thuộc tính "true"). Ngoài ra, các khối <Action> là tùy chọn, nên mẫu đầu tiên không cần phải có khối hành động @IfCondition="false".

Các biểu thức có điều kiện của WS-MediationPolicy phải tuân thủ lược đồ của WS-MediationPolicy được cung cấp trong phần Tải về của bài này.

Cách tốt nhất để mô tả WS-MediationPolicy là chỉ ra một ví dụ và giải thích hành vi được mô tả bởi chính sách ví dụ mẫu ấy, rồi thảo luận về cách có thể đạt được các biến thể của chính sách bằng cách thay đổi chính sách đó. Ví dụ đầu tiên được hiển thị trong Liệt kê 2. Chính sách này định tuyến các thông báo đến một máy chủ thay thế (http://secondary-server:9080) thay cho máy chủ được quy định trong dịch vụ Web (chẳng hạn như cấu hình dịch vụ WSDL hoặc cấu hình dịch vụ WS-Proxy) khi tốc độ các thông báo vượt quá 100 thông báo mỗi phút (PT60S), nhưng chỉ vào các ngày thứ Hai, thứ Tư và thứ Sáu, từ nửa đêm đến 6:00 sáng.

Liệt kê 2. WS-MediationPolicy ví dụ mẫu
<wsp:Policy wsp:Name="Route-secondary-schedule-template"
            xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
            xmlns:wsmp="http://www.ibm.com/xmlns/stdwip/2011/02/ws-mediation">
    <wsmp:Rule>
        <wsmp:Condition>
        
            <wsmp:Expression>
                <wsmp:Attribute>MessageCount</wsmp:Attribute>
                <wsmp:Operator>GreaterThan</wsmp:Operator>
                <wsmp:Value>100</wsmp:Value>
                <wsmp:Interval>PT60S</wsmp:Interval>
            </wsmp:Expression>
            
            <wsmp:Schedule>
                <wsmp:Daily StartTime="00:00:00" StopTime="06:00:00"/>
                <wsmp:WeekDays Days="Monday+Wednesday+Friday"/>
            </wsmp:Schedule>
            
        </wsmp:Condition>

        <wsmp:Action IfCondition="true">
            <wsmp:RouteMessage>
                <wsmp:EndPoint>
                    http://secondary-server:9080
                </wsmp:EndPoint>
            </wsmp:RouteMessage>
        </wsmp:Action>
    </wsmp:Rule>
</wsp:Policy>

Phần tử Rule (Quy tắc)

Trong ví dụ ở trên, phần tử <Rule> là xác nhận chính sách của WS-MediationPolicy trong biểu thức <wsp:Policy>. Một xác nhận chính sách Rule có thể chứa một phần tử <wsmp:Condition> và luôn có chứa ít nhất một phần tử <wsmp:Action>. Nếu không chỉ rõ một phần tử <wsmp:Condition> thì đánh giá về xác nhận chính sách đó được hiểu ngầm là một điều kiện true để quyết định hành động nào cần thực thi.

Phần tử Condition (Điều kiện)

Phần tử "<wsmp:Condition>" đại diện cho một điều kiện có thể đánh giá là một giá trị true (đúng) hay một giá trị false (sai). Phần tử <wsmp:Condition> có thể chứa một phần tử <wsmp:Expression>, một phần tử <wsmp:Schedule> hoặc nó có thể chứa cả hai như được chỉ ra trong Liệt kê 2. Phần tử <wsmp:Condition> của một xác nhận của WS-MediationPolicy đánh giá là true chỉ khi cả hai phần tử <wsmp:Expression> và phần tử <wsmp:Schedule> đều đánh giá là đúng (true).

Phần tử "<wsmp:Expression>" đại diện cho một tiêu chí hoặc ngưỡng sẽ được đánh giá trong thời gian chạy là một giá trị true hay một giá trị false cho mỗi thông báo được một nền tảng thực thi chính sách xử lý. Việc đánh giá này sẽ dựa trên các hạn chế chính sách được thể hiện trong tiêu chí chính sách đã chọn trong phần tử <wsmp:Expression> và tốc độ/các độ trễ của các thông báo đang được xử lý (ví dụ, thông lượng, độ trễ hoặc số các lỗi cho mỗi khoảng thời gian của thông báo).

Số lượng các phần tử cần thiết cho một phần tử <Expression> thay đổi, tùy thuộc vào giá trị được chọn cho phần tử <Operator> (Toán tử). Các giá trị hợp lệ cho phần tử <Operator> được liệt kê trong Bảng 2, cùng với các ý nghĩa của chúng.

Bảng 2. Các giá trị hợp lệ cho phần tử Operator và ý nghĩa của chúng
Giá trịMô tả
GreaterThanMột thuật toán số đơn giản, để đánh giá là "true" khi thuộc tính lớn hơn giá trị đã định.
LessThanMột thuật toán số đơn giản, để đánh giá là "true" khi thuộc tính nhỏ hơn giá trị đã định.
HighLowMột thuật toán để đánh giá là "true" khi thuộc tính đạt đến giá trị là ngưỡng cao đã định. Sau đó nó tiếp tục đánh giá là "true" cho đến khi thuộc tính đạt đến giới hạn là ngưỡng thấp đã định.
TokenBucketMột thuật toán dựa trên tốc độ để cho phép các sự bùng nổ của các thông báo. Thuật toán này gồm có một thùng chứa có một sức chứa tối đa các thẻ xác thực. Thùng chứa này nạp đầy các thẻ xác thực theo mỗi khoảng thời gian ở một tốc độ không đổi, trong khi cứ mỗi đơn vị giá trị thuộc tính, một thẻ xác thực được lấy ra. Thuật toán này đánh giá là "true" khi không còn thẻ xác thực nào trong thùng chứa đó. Nếu không, nó sẽ đánh giá là "false".

Nếu "GreaterThan" hoặc "LessThan" được lựa chọn cho phần tử <Operator>, thì các phần tử còn lại cần phải có là:

  • <Attribute>: Phần tử này đại diện cho khía cạnh của thông báo áp dụng cho phần tử <Expression> (xem Bảng 2).
  • <Interval>: Phần tử này đại diện cho độ dài của khoảng thời gian giám sát.
  • <Value>: Phần tử này đại diện cho giá trị được quan sát sẽ làm cho giá trị của phần tử <Expression> thay đổi trong phần thời gian còn lại của phần tử <Interval> đã quy định. Một ví dụ về giá trị GreaterThan được hiển thị trong Liệt kê 2. Một ví dụ về giá trị LessThan được hiển thị trong Liệt kê 3.
Liệt kê 3. Ví dụ về giá trị LessThan
<wsp:Policy wsp:Name="LessThan example"
            xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
            xmlns:wsmp="http://www.ibm.com/xmlns/stdwip/2011/02/ws-mediation">
    <wsmp:Rule>
        <wsmp:Condition>
            <wsmp:Expression>
                <wsmp:Attribute>MessageCount</wsmp:Attribute>
                <wsmp:Operator>LessThan</wsmp:Operator>
                <wsmp:Value>100</wsmp:Value>
                <wsmp:Interval>PT60S</wsmp:Interval>
            </wsmp:Expression>
        </wsmp:Condition>

        <wsmp:Action IfCondition="true">
            <wsmp:RouteMessage>
                <wsmp:EndPoint>http://secondary-server:9080</wsmp:EndPoint>
            </wsmp:RouteMessage>
        </wsmp:Action>
    </wsmp:Rule>
</wsp:Policy>

Giá trị "HighLow" cho phần tử <Operator> làm việc giống như giá trị GreaterThan, trừ việc nó đòi hỏi một phần tử bổ sung là <Limit>, đại diện cho số đếm thông báo là nguyên nhân làm cho phần tử <Expression> đánh giá lại thành sai (ví dụ, hoạt động như một "dấu hiệu mờ"). Một ví dụ về giá trị HighLow được hiển thị trong Liệt kê 4.

Liệt kê 4. Ví dụ về giá trị HighLow
<wsp:Policy wsp:Name="HighLow example"
            xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
            xmlns:wsmp="http://www.ibm.com/xmlns/stdwip/2011/02/ws-mediation">
    <wsmp:Rule>
        <wsmp:Condition>
            <wsmp:Expression>
                <wsmp:Attribute>MessageCount</wsmp:Attribute>
                <wsmp:Operator>HighLow</wsmp:Operator>
                <wsmp:Value>100</wsmp:Value>
                <wsmp:Limit>50</wsmp:Limit>
                <wsmp:Interval>PT60S</wsmp:Interval>
            </wsmp:Expression>
        </wsmp:Condition>

        <wsmp:Action IfCondition="true">
            <wsmp:RouteMessage>
                <wsmp:EndPoint>http://secondary-server:9080</wsmp:EndPoint>
            </wsmp:RouteMessage>
        </wsmp:Action>
    </wsmp:Rule>
</wsp:Policy>

"TokenBucket <Operator>" cũng đòi hỏi phải chỉ rõ một phần tử <Limit>. Toán tử TokenBucket cho phép các sự bùng nổ lưu lượng truy cập vào một dịch vụ, trong khi vẫn duy trì một tốc độ lưu lượng truy cập trung bình thấp hơn. Điều này được thực hiện bằng cách thêm "các thẻ xác thực" vào một "thùng chứa" ở tốc độ của các thẻ xác thực của phần tử <Value> cho mỗi phần tử <Interval>. Tuy nhiên, số lượng các thẻ xác thực trong thùng chứa không bao giờ có thể vượt quá phần tử <Limit>. Mỗi thông báo lấy ra một thẻ xác thực khỏi thùng chứa. Nếu thùng chứa trở nên rỗng, thì phần tử Expression sẽ đánh giá là true. Nếu không, nó đánh giá là false. MessageCount (Số đếm thông báo) và ErrorCount (Số đếm lỗi) là hai giá trị duy nhất của phần tử <Attribute> cho TokenBucket. Một ví dụ về TokenBucket được hiển thị trong Liệt kê 5.

Liệt kê 5. Ví dụ về TokenBucket
<wsp:Policy wsp:Name="TokenBucket example"
            xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
            xmlns:wsmp="http://www.ibm.com/xmlns/stdwip/2011/02/ws-mediation">
    <wsmp:Rule>
        <wsmp:Condition>
            <wsmp:Expression>
                <wsmp:Attribute>MessageCount</wsmp:Attribute>
                <wsmp:Operator>TokenBucket</wsmp:Operator>
                <wsmp:Value>100</wsmp:Value>
                <wsmp:Limit>10</wsmp:Limit>
                <wsmp:Interval>PT60S</wsmp:Interval>
            </wsmp:Expression>
        </wsmp:Condition>

        <wsmp:Action IfCondition="true">
            <wsmp:RouteMessage>
                <wsmp:EndPoint>http://secondary-server:9080</wsmp:EndPoint>
            </wsmp:RouteMessage>
        </wsmp:Action>
    </wsmp:Rule>
</wsp:Policy>
Bảng 3. Các giá trị hợp lệ cho các thuộc tính và ý nghĩa của chúng
Giá trịMô tả
ErrorCountSố lỗi được quan sát trong khoảng thời gian giám sát này.
MessageCountSố thông báo được xử lý trong khoảng thời gian giám sát này.
InternalLatencyĐộ trễ trong (thời gian xử lý) tính theo mili giây.
BackendLatencyĐộ trễ thiết bị-đến-máy chủ tính theo mili giây.
TotalLatencyTổng độ trễ tầng sau và độ trễ bên trong tính theo mili giây.

Bạn có thể sử dụng phần tử "<wsmp:Schedule>" để bật hoặc tắt một bộ sưu tập các hành động dựa vào thời gian để xử lý một thông báo. Ví dụ, có thể viết một xác nhận chính sách để loại bỏ các thông báo được gửi đi giữa các giờ nhất định trong ngày (xem Liệt kê 6), vào một số ngày nhất định trong tuần (xem Liệt kê 7) hoặc giữa các ngày tháng nhất định (xem Liệt kê 8).

Một lịch biểu hàng ngày được cấu hình trong một biểu thức chính sách bằng cách sử dụng phần tử "<wsmp:Daily>". Thuộc tính StartTime (Thời gian bắt đầu) và StopTime (Thời gian kết thúc) bắt buộc phải có với phần tử <wsmp:Daily> và các thời gian đó phải được quy định cụ thể theo định dạng xs:time, không tính đến độ lệch múi giờ hay số giây. Thuộc tính StopTime có thể có cùng một giá trị như thuộc tính StartTime để mô tả một khoảng thời gian 24 giờ, bắt đầu từ StartTime. Nếu StopTime nhỏ hơn StartTime (như trong Liệt kê 6), thì thời gian sẽ được coi là đã qua nửa đêm. Trong trường hợp này, độ dài thời gian dài 8 giờ, bắt đầu từ 22:00 giờ (10 giờ tối) đến 06:00 giờ (6 giờ sáng). Lưu ý rằng StartTime và StopTime được xử lý chi tiết đến mức giờ và phút, bỏ qua bất kỳ các số giây nào đã xác định trong giá trị thời gian. Ngoài ra, hãy lưu ý rằng các giá trị thời gian có liên quan đến các thiết lập thời gian địa phương, múi giờ và thời gian mùa hè (DST) của nền tảng thực thi chính sách.

Liệt kê 6. Loại bỏ thông báo dựa trên một lịch biểu hàng ngày
<wsp:Policy wsp:Name="Reject messages based on a daily schedule"
            xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
            xmlns:wsmp="http://www.ibm.com/xmlns/stdwip/2011/02/ws-mediation">
    <wsmp:Rule>
        <wsmp:Condition>
            <wsmp:Schedule>
                <wsmp:Daily StartTime="22:00:00" StopTime="06:00:00"/>
            </wsmp:Schedule>
        </wsmp:Condition>

        <wsmp:Action IfCondition="true">
            <wsmp:RejectMessage/>
        </wsmp:Action>
    </wsmp:Rule>
</wsp:Policy>

Phần tử "<wsmp:WeekDays>" mô tả các ngày trong tuần mà lịch biểu có hiệu lực. Các ngày trong tuần được chỉ rõ bởi thuộc tính Days (Các ngày) dưới dạng các tên ngày trong tuần, phân cách bằng một ký tự "+". Tất cả các tên ngày trong tuần phải bắt đầu bằng một ký tự chữ hoa và tiếp theo là tất cả các ký tự chữ thường. Lịch biểu được hiển thị trong Liệt kê 7 loại bỏ tất cả các thông báo đã nhận được vào các ngày thứ Bảy và Chủ Nhật.

Liệt kê 7. Loại bỏ thông báo dựa vào ngày trong tuần
<wsp:Policy wsp:Name="Reject messages based on a day of the week"
            xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
            xmlns:wsmp="http://www.ibm.com/xmlns/stdwip/2011/02/ws-mediation">
    <wsmp:Rule>
        <wsmp:Condition>
            <wsmp:Schedule>
                <wsmp:WeekDays Days="Saturday+Sunday"/>
            </wsmp:Schedule>
        </wsmp:Condition>

        <wsmp:Action IfCondition="true">
            <wsmp:RejectMessage/>
        </wsmp:Action>
    </wsmp:Rule>
</wsp:Policy>

Các thuộc tính StartDate và StopDate của phần tử <wsmp:Schedule> quy định ngày có hiệu lực của một lịch biểu. StartDate đại diện cho ngày đầu tiên lịch biểu bắt đầu có hiệu lực và StopDate đại diện cho ngày đầu tiên lịch biểu không có hiệu lực. Lưu ý rằng StopDate này khác ngày cuối cùng lịch biểu có hiệu lực. Lịch biểu được hiển thị trong Liệt kê 8 sẽ loại bỏ các thông báo nhận được vào ngày 1, 2, 3 và 4 của tháng 7. Nó sẽ cho phép các thông báo nhận được vào ngày 5 tháng 7. Một lịch biểu chỉ có một StartDate không có hiệu lực trước ngày được quy định. Một lịch biểu chỉ có một StopDate trở thành không có hiệu lực trong ngày được quy định.

Liệt kê 8. Loại bỏ các thông báo dựa trên các ngày tháng
<wsp:Policy wsp:Name="Reject messages based on dates"
            xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
            xmlns:wsmp="http://www.ibm.com/xmlns/stdwip/2011/02/ws-mediation">
    <wsmp:Rule>
        <wsmp:Condition>
            <wsmp:Schedule StartDate="2012-07-01" StopDate="2012-07-05" />
        </wsmp:Condition>

        <wsmp:Action IfCondition="true">
            <wsmp:RejectMessage/>
        </wsmp:Action>
    </wsmp:Rule>
</wsp:Policy>

Bạn có thể kết hợp các khía cạnh khác nhau của một lịch biểu (các ngày trong tuần - WeekDays, thời gian Start/Stop hàng ngày - Daily Start/Stop, StartDate và StopDate) để tạo thành một lịch biểu phức tạp hơn. Tuy nhiên, hãy cẩn thận khi bạn xây dựng các lịch biểu phức tạp hơn để chắc chắn rằng các khía cạnh đó không loại trừ lẫn nhau và không dẫn đến những hậu quả không mong muốn như trong các ví dụ dưới đây.

  • Các phạm vi từ StartDate đến StopDate không bao gồm bất kỳ các ngày trong tuần (WeekDays) đã quy định nào.
  • Một lịch biểu quy định WeekDays hoặc StopDate sẽ không cắt xén một lịch biểu hàng ngày (Daily) "lấn qua nửa đêm". Ví dụ, Liệt kê 9 loại bỏ thông báo bắt đầu lúc 22:00 tối thứ Bảy đến 6:00 sáng Chủ nhật và 22:00 đêm Chủ nhật đến 6:00 sáng thứ Hai. Thực tế là "Thứ hai" không được liệt kê với WeekDays có nghĩa là các khoảng thời gian cho lịch biểu hàng ngày sẽ không được bắt đầu từ thứ Hai đến thứ Sáu. Tuy nhiên, điều đó không có nghĩa là sẽ cắt mất phần của lịch biểu kéo dài đến thứ Hai.
  • Các thời gian đều dựa trên thời gian địa phương của nền tảng thực thi chính sách.
Liệt kê 9. Lịch biểu chứa các phần tử Daily và WeekDays
<wsp:Policy wsp:Name="Schedule containing Daily and Weekdays elements"
            xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
            xmlns:wsmp="http://www.ibm.com/xmlns/stdwip/2011/02/ws-mediation">
    <wsmp:Rule>
        <wsmp:Condition>
            <wsmp:Schedule>
                <wsmp:Daily StartTime="22:00:00" StopTime="06:00:00"/>
                <wsmp:WeekDays Days="Saturday+Sunday"/>
            </wsmp:Schedule>
        </wsmp:Condition>

        <wsmp:Action IfCondition="true">
            <wsmp:RejectMessage/>
        </wsmp:Action>
    </wsmp:Rule>
</wsp:Policy>

Phần tử Action

Các phần tử Action (hành động) được định nghĩa trong WS-MediationPolicy cung cấp thông tin chung cho một loạt các nhu cầu của yêu cầu vận hành CNTT.

Phần tử Action chứa một hoặc nhiều hành động cần thực hiện nếu kết quả đánh giá điều kiện logic đã mô tả trong phần tử <wsmp:Condition> khớp với thuộc tính IfCondition của phần tử Action. Nếu không quy định phần tử IfCondition nào cho phần tử Action, thì hiểu ngầm là phần tử IfCondition = "true". Trong ví dụ được hiển thị trong Liệt kê 2, hành động RouteMessage được gọi với các thông báo được gửi đi từ giữa nửa đêm và 6:00 giờ sáng ngày thứ Hai, thứ Tư và thứ Sáu. Một chính sách như vậy có ích cho việc lái các thông báo ra khỏi một dịch vụ Web theo định kỳ để bảo trì thường xuyên.

Các hành động được hỗ trợ trong phần tử Action là:

  • ValidateMessage
  • RouteMessage
  • QueueMessage
  • RejectMessage
  • ExecuteXSL
  • Notify

Hành động "ValidateMessage" xác nhận hợp lệ một thông báo bằng cách sử dụng một XML Schema (XSD) hoặc một WSDL. Nếu chọn dùng tùy chọn XSD, phần tử Action cho ValidateMessage được khai báo như trong Liệt kê 10. Nếu chọn dùng tùy chọn WSDL, thì phần tử Action cho ValidateMessage được khai báo như trong Liệt kê 11.

Liệt kê 10. Hành động ValidateMessage với XSD
<wsmp:Action>
     <wsmp:ValidateMessage>
     <wsmp:XSD>
          local:///MySchema.xsd
     </wsmp:XSD>
     </wsmp:ValidateMessage>
     <wsme:Scope>SOAPBody</wsme:Scope>
</wsmp:Action>
Liệt kê 11. Hành động ValidateMessage với WSDL
<wsmp:Action>
     <wsmp:ValidateMessage>
         <wsmp:WSDL>
            local:///MyWebService.wsdl
         </wsmp:WSDL>
     </wsmp:ValidateMessage>
</wsmp:Action>

Như trong Liệt kê 10, tùy chọn XSD cho hành động ValidateMessage cũng cho phép định nghĩa một Scope (Phạm vi) để xác nhận hợp lệ thông báo. Các giá trị hợp lệ cho Scope là SOAPBody, SOAPBodyOrDetails, SOAPEnvelope và SOAPIgnoreFaults. Ý nghĩa của các giá trị này được liệt kê trong Bảng 4.

Bảng 4. Các giá trị hợp lệ cho Scope và các ý nghĩa của chúng
Giá trịMô tả
SOAPBodyCác nội dung của phần tử SOAP Body, không xử lý đặc biệt đối với các lỗi SOAP. Đây là hành vi mặc định nếu không chỉ rõ Scope.
SOAPBodyOrDetailsCác nội dung của phần tử detail (chi tiết) cho trường hợp các lỗi SOAP và các nội dung của Body nếu trái lại.
SOAPEnvelopeToàn bộ thông báo SOAP, bao gồm cả phong bì.
SOAPIgnoreFaultsKhông có xác nhận hợp lệ nào nếu thông báo là một lỗi SOAP, các nội dung của SOAP Body nếu trái lại.

Hành động "RouteMessage" thay đổi đích đến ở xa (tầng sau) để thực thi chính sách nhằm chuyển tiếp yêu cầu sau khi được xử lý bởi sự ủy quyền (proxy). Hành động này được thực hiện bằng cách thay thế URL tầng sau đã định nghĩa trong cổng kết nối thực thi (ví dụ, được cung cấp trong WSDL hoặc Điểm cuối từ xa - Remote Endpoint được cấu hình trong một Web Service Proxy –Ủy quyền các dịch vụ Web) bằng các thông tin được phần tử Action của RouteMessage cung cấp. Ví dụ, hãy giả sử rằng tất cả các dịch vụ dùng cho một Web Service Proxy được cấu hình để sử dụng một Remote Endpoint là "http://myPrimaryServer.myco.com:80". Bạn có thể sử dụng ví dụ được hiển thị trong Liệt kê 12 để định tuyến các thông báo tới "https://myAlternateServer.myco.com:9443" để thay thế.

Liệt kê 12. Ví dụ về RouteMessage
<wsmp:Action>
    <wsmp:RouteMessage>
        <wsmp:EndPoint>
            https://myAlternateServer.myco.com:9443
        </wsmp:EndPoint>
    </wsmp:RouteMessage>
</wsmp:Action>

Hành động "QueueMessage", như trong Liệt kê 13, làm cho các thông báo sẽ được giữ lại để xử lý vào một thời gian muộn hơn theo điều kiện của phần tử Expression, mà chúng tôi sẽ trình bày sau. Hành động QueueMessage đáng chú ý ở chỗ nó chỉ áp dụng khi một phần tử <Expression> được khai báo và đánh giá là true. Hơn nữa, nếu nhiều phần tử <Action> hoặc <Action IfCondition="true"> được khai báo, thì QueueMessage phải nằm ở phần tử đầu tiên.

Liệt kê 13. Ví dụ về hành động QueueMessage
<wsmp:Action IfCondition="true">
     <wsmp:QueueMessage/>
</wsmp:Action>

Hành động RejectMessage, như trong Liệt kê 14, làm cho một thông báo bị loại bỏ. Không có hạn chế nào về cách sử dụng RejectMessage. Có thể sử dụng hành động này trong bất kỳ điều kiện logic nào. Việc xử lý thông báo dừng lại khi gặp một hành động RejectMessage và một phản hồi lỗi được gửi lại cho bên sử dụng dịch vụ.

Liệt kê 14. Ví dụ về hành động RejectMessage
<wsmp:Action>
    <wsmp:RejectMessage/>
</wsmp:Action>

Hành động "ExecuteXSL" (Thực hiện XSL), như trong Liệt kê 15, cung cấp một cơ chế để dịch định dạng thông báo (trung gian hòa giải dữ liệu không theo ngữ nghĩa). Hành động này được đưa ra để cho phép chuyển đổi một thông báo từ một phiên bản sang một phiên bản khác trước khi chuyển tiếp nó đến dịch vụ Web tầng sau để xử lý.

Liệt kê 15. Ví dụ về hành động ExecuteXSL
<wsmp:Action>
    <wsmp:ExecuteXSL>
        <wsmp:Parameter Name="SoureceVersion" Value="V1" />
        <wsmp:Stylesheet/>
            local:///convertMessageVersion.xsl
        </wsmp:Stylesheet>
    </wsmp:ExecuteXSL>
</wsmp:Action>

Hành động "Notify" (Thông báo) cung cấp một cơ chế để tạo ra một mục bản ghi nhật ký ở mức "thông báo" của chính sách. Thiết bị DataPower sẽ tạo ra một sự kiện thông báo trong bản ghi nhật ký hệ thống khi nó gặp một hành động Notify như thể hiện trong Liệt kê 16.

Liệt kê 16. Ví dụ về hành động Notify
<wsmp:Action>
    <wsmp:Notify/>
</wsmp:Action>

Hành động Notify tạo ra mục trong bản ghi nhật ký được hiển thị trong Hình 3. Lưu ý là tên hành động được thiết bị tạo ra tự động và có thể thay đổi được, nhưng mã định danh (ID) của thông báo (0x80800101) sẽ là giống nhau với tất cả các thông báo Notify.

Hình 3. Mục trong bản ghi nhật ký do hành động Notify tạo ra
Thông báo ghi nhật ký do hành động Notify tạo ra khi nó xuất hiện trong WebGUI

Soạn WS-MediationPolicy

Phần này trình bày các lựa chọn khác nhau có sẵn khi tạo các biểu thức WS-MediationPolicy và sử dụng chúng như một thiết bị DataPower. Chúng tôi sẽ trình bày ba phương thức, lần lượt sử dụng WSRR, Integration Designer (Trình thiết kế tích hợp) và một trình soạn thảo văn bản đơn giản.


Soạn chính sách bằng WSSR

WSRR V8.0 (Phiên bản 8.0 của WSRR) đã thêm vào sự hỗ trợ dựng sẵn để tạo các tài liệu WS-MediationPolicy với một trình soạn thảo giao diện người dùng chuyên dụng trong WSRR Business Space UI (Giao diện người dùng Vùng nghiệp vụ của WSRR).

WSRR V7.5 có hỗ trợ cho WS-MediationPolicy bằng cách sử dụng trình soạn thảo chính sách truyền thống trong giao diện bàn điều khiển của WSRR Web UI (Giao diện người dùng Web của WSRR). Bài này tập trung vào sự hỗ trợ cho WSRR V8.0 mới. Để có thông tin về cách sử dụng WSRR V7.5, hãy xem Các nhiệm vụ soạn chính sách.

Để soạn ra một xác nhận của WS-MediationPolicy bằng cách sử dụng WSRR Business Space UI, trước tiên bảo đảm rằng người quản trị hệ thống đã cấu hình vùng này một cách thích hợp cho vai trò này. Cần phải tạo ra vùng nghiệp vụ sử dụng này dựa trên một trong các khuôn mẫu sau đây:

  • Service Registry (Đăng ký dịch vụ) cho Phát triển
  • Service Registry cho các Hoạt động
  • Service Registry cho Quản trị SOA

Ngoài ra, bạn có thể sử dụng một vùng tùy chỉnh. Trong trường hợp này, bạn phải cấu hình một tiện ích (widget ) "Service Registry Actions" (Các hành động Đăng ký dịch vụ) để hiển thị một hành động "Create a Policy" (Tạo một chính sách), với một kiểu chính sách là "Mediation" (Trung gian hòa giải).

Để bắt đầu quá trình soạn một xác nhận WS-MediationPolicy mới trong WSRR Business Space UI, trước tiên hãy tìm đến tiện ích "Service Registry Actions". Trên một vùng được tạo ra từ một trong các khuôn mẫu ở trên, hãy tìm tiện ích (widget) này trên tab "Overview" (Tổng quan). Tiện ích này chứa liên kết hành động như trong Hình 4, để khi nhấn chuột vào, sẽ khởi động quá trình soạn thảo. Lưu ý rằng các văn bản trong liên kết hành động này có thể khác nếu vùng sử dụng không phải là một vùng được tạo ra từ một trong những khuôn mẫu nói trên.

Hình 4. Tạo một hành động Mediation Policy (Chính sách trung gian)
Tạo một hành động Mediation Policy

Sau khi đã nhấn chuột vào Create a Mediation Policy (Tạo một chính sách trung gian), liên kết này sẽ đưa ra một hộp thoại tương tự như được hiển thị trong Hình 5, như hộp thoại được sử dụng để tạo ra một cá thể mới của một đối tượng Business Modeled (Mô hình hóa nghiệp vụ) với một phần bổ sung có tựa đề "Policy".

Hình 5. Hộp thoại Create a Mediation Policy
Hộp thoại Create A Mediation Policy

Phần Policy (Chính sách) đại diện cho một phần tử Rule duy nhất trong XML. Để soạn ra nhiều quy tắc, bạn phải tạo ra nhiều xác nhận WS-MediationPolicy bằng WSRR. Đây là một hạn chế hiện tại của trình soạn thảo chính sách WSRR Business Space. Khi lần đầu tiên nhập vào, hộp thoại sẽ có tùy chọn để thêm vào một "Attribute Condition" (Điều kiện Thuộc tính), một "Schedule Condition" (Điều kiện Lịch biểu) và nhiều "Actions". Những hành động được thêm vào trong phần "Actions" sẽ được thực hiện khi không có mặt điều kiện nào hoặc một khi đã thêm vào một số điều kiện, như trong Hình 6, thì sẽ thực hiện các hành động này khi các điều kiện đánh giá là đúng. Khi đã thêm vào một trong hai kiểu điều kiện, phần hành động (Action) sẽ mở rộng thêm để chứa một tùy chọn cho phép thêm vào các hành động, sẽ được thực hiện khi các điều kiện đánh giá là sai.

Hình 6. Thêm vào một chính sách trung gian một điều kiện
Phần chính sách ngay khi có một điều kiện đã được thêm vào

Biểu tượng trong Hình 7, khi được di chuột lên, sẽ cung cấp thêm thông tin về phần đó của giao diện người dùng.

Hình 7. Một biểu tượng thông tin
Một biểu tượng thông tin

Các điều kiện thuộc tính

Sau khi nhấn chuột vào Add Attribute Condition (Thêm Điều kiện Thuộc tính), một vùng nội dòng xuất hiện như trong Hình 8, để cho phép bạn chọn thuộc tính để áp dụng điều kiện cho nó, đồng thời cũng cung cấp một mô tả về thuộc tính. Sau khi đã thêm điều kiện thuộc tính bằng cách nhấn Add, có thể thiết lập các tham số của điều kiện này.

Hình 8. Thêm một điều kiện thuộc tính
Thêm vùng điều kiện thuộc tính

Điều kiện thuộc tính là một trong các giá trị sau có tương quan trực tiếp với các giá trị được định nghĩa trong Bảng 3:

  • Message count
  • Error count
  • Backend latency
  • Internal latency
  • Total latency

Toán tử là một trong những giá trị sau có tương quan trực tiếp với các giá trị được định nghĩa trong Bảng 2, với "Greater Than, Allowing Bursts" ánh xạ tới "TokenBucket" và "Greater Than, Until Less Than" ánh xạ tới "HighLow":

  • Greater Than (Lớn hơn)
  • Greater Than, Allowing Bursts (Lớn hơn, Cho phép các sự bùng nổ)
  • Greater Than, Until Less Than (Lớn hơn, Cho đến khi nhỏ hơn)
  • Less Than (Nhỏ hơn)

Lưu ý rằng toán tử "Greater Than, Allowing Bursts" không có sẵn nếu đã chọn một điều kiện thuộc tính độ trễ, do toán tử này chỉ áp dụng cho các số đếm.

Các toán tử hoạt động theo như tên của chúng gợi ý. Như trong Hình 6, đã định nghĩa một điều kiện có một thuộc tính là "Message Count", một toán tử là "Greater Than", một "Value" là 100 và một "Per interval of" (Cho mỗi khoảng thời gian) là 30 giây. Điều này có nghĩa là điều kiện này sẽ đánh giá là “true” nếu số lượng các thông báo, được đo trong khoảng thời gian 30 giây, lớn hơn 100. Khi số lượng thông báo được đo trong khoảng thời gian tương tự giảm xuống dưới 100, thì điều kiện này sẽ đánh giá là "false".

Một dấu hoa thị bên trái của tên trường cho biết trường này là bắt buộc. Lưu ý rằng giao diện WSRR coi một số trường bắt buộc là các trường tùy chọn theo định nghĩa XML. Điều này bảo đảm rằng các giá trị cụ thể được đưa ra trong lúc soạn thảo, thay vì chấp nhận các giá trị mặc định do điểm thực thi định nghĩa, có nghĩa là ngữ nghĩa của chính sách là hoàn toàn xác định.

Các trường có sẵn cho đầu vào sẽ khác nhau về số lượng và tên tùy theo thuộc tính và toán tử được chọn. Trong Hình 9, chúng tôi đã chọn toán tử "Greater Than, Allowing Bursts" nên trường đầu tiên đã thay đổi thành "Normal maximum". Chúng tôi có thêm một trường bổ sung có tên là "Allowing bursts of up to". Trong ví dụ này, toán tử "Greater Than, Allowing Bursts" hoạt động giống như toán tử "Greater Than", trừ một sự bùng nổ là 200 thông báo trong khoảng thời gian 30 giây, hoặc hai sự bùng nổ liên tiếp là 150 thông báo trong hai khoảng thời gian 30 giây và v.v, sẽ không làm cho điều kiện này đánh giá là đúng.

Hình 9. Một điều kiện có sử dụng toán tử "Greater Than, Allowing Bursts"
Một điều kiện có một toán tử Greater Than, Allowing Bursts

Trong Hình 10, đã chọn toán tử "Greater Than, Until Less Than" trong hộp thoại thả xuống của toán tử. Toán tử này hoạt động giống hệt như toán tử "Greater Than". Một ngoại lệ là một khi nó đã bắt đầu đánh giá là đúng, nó sẽ tiếp tục đánh giá là đúng cho đến khi số lượng các thông báo đã giảm xuống dưới 50, như được chỉ thị trong trường "Until less than" (Cho đến khi nhỏ hơn).

Hình 10. Một điều kiện có sử dụng toán tử "Greater Than, Until Less Than"
Một điều kiện có một toán tử Greater Than, Until Less Than

Toán tử "Less Than" đưa ra các trường tương tự như toán tử "Greater Than", nhưng đánh giá là sai trong khi giá trị đo được lớn hơn hoặc bằng giá trị đã định nghĩa và đánh giá là đúng khi giá trị đo được thấp hơn giá trị đã định nghĩa trong trường có tên là "Value".

Các điều kiện lịch biểu

Bằng cách nhấn chuột vào Add Schedule Condition (Thêm Điều kiện lịch biểu), thì có thể thêm vào một điều kiện chỉ đánh giá là "đúng" trong một khoảng thời gian cụ thể. Có thể chỉ rõ các ngày tháng cho khoảng thời gian để bắt đầu và kết thúc, các ngày trong tuần để tính vào và hơn nữa cả các hạn chế về thời gian trong ngày được tính đến trong lịch biểu cho từng ngày. Một lịch biểu đơn giản được hiển thị trong Hình 11. Lịch biểu này sẽ đánh giá là đúng đối với khoảng thời gian một năm và một ngày bắt đầu từ ngày 02.04.2012. Lưu ý rằng các trường "Start date" (Ngày bắt đầu) và "End date" (Ngày kết thúc) cũng được tính đến trong lịch biểu này. Vì lợi ích của những người dùng đã quen làm việc với "Stop date" của XML, ngày dừng lại (Stop date) không được tính đến trong lịch biểu này, nên Stop date được chỉ thị bằng văn bản hiển thị ngay bên dưới ngày kết thúc.

Hình 11. Một điều kiện lịch biểu đơn giản
Một điều kiện lịch biểu đơn giản

Khi các ngày trong tuần và thời gian trong ngày cũng được chỉ rõ, điều kiện lịch biểu trông giống như ví dụ được hiển thị trong Hình 12. Ví dụ này sẽ đánh giá là đúng đối với khoảng thời gian một năm và một ngày bắt đầu từ ngày 02.04.2012, nhưng chỉ vào các ngày từ thứ Hai đến thứ Sáu, từ 8:00 tối cho tới 8 giờ sáng. Do các thời gian trong ngày được quy định trong ví dụ này chạy cắt qua ranh giới ngày, nên lịch biểu này vẫn sẽ đánh giá là đúng vào thứ Bảy, mặc dù thứ Bảy không có trong lịch biểu này, cho đến 8 giờ sáng, như được chỉ thị bằng đoạn văn bản "The next day" (Ngày hôm sau) trong ví dụ này. Lịch biểu này sẽ vẫn đánh giá là đúng vào ngày thứ Tư, 03.04 cho đến 8 sáng, do khoảng thời gian bắt đầu từ 08:00 tối và chạy cho đến 8:00 sáng sẽ được bắt đầu vào thứ Ba ngày 02.04.

Hình 12. Một điều kiện lịch biểu phức tạp
Một điều kiện lịch biểu phức tạp

Các hành động

Việc nhấn chuột vào Add Action (Thêm hành động) cho phép thêm một hành động cần được thực hiện. Nếu không có điều kiện nào được quy định cho chính sách đó, thì các hành động sẽ luôn được thực hiện. Nếu có điều kiện được quy định cho chính sách đó, thì các hành động trong phần có liên quan, "Actions If All Conditions are True" hoặc "Actions If Any Condition is False", sẽ được thực hiện dựa trên kết quả của việc đánh giá các điều kiện. Các hành động có sẵn để sử dụng trong chính sách này là:

  • ValidateMessage
  • RouteMessage
  • QueueMessage - chỉ có sẵn trong phần "Actions If All Conditions are True"
  • RejectMessage
  • ExecuteXSL
  • Notify

Sau khi nhấn chuột vào Add Action, một vùng nội dòng (xem Hình 13) xuất hiện để cho phép bạn chọn một hành động để thực hiện, đồng thời nó cũng đưa ra một mô tả về hành động. Sau khi nhấn Add để thêm vào hành động này, có thể thiết lập các tham số của hành động và cũng có thể thêm vào nhiều hành động hơn nữa bằng cách nhấn lại vào liên kết Add Action.

Hình 13. Thêm một vùng hành động
Thêm một vùng hành động

Các hành động "Notify", "Queue Message" và "Reject Message" không có tham số nào, như đã thấy trong Hình 14.

Hình 14. Các hành động không có tham số nào
Các hành động không có tham số nào

Hành động "Route Message", như trong Hình 15, có thể lấy một điểm đầu cuối làm tham số để định tuyến thông báo. Điểm đầu cuối này có thể là bất kỳ đầu vào văn bản nào và được điểm thi hành chính sách diễn giải trong thời gian chạy.

Hình 15. Hành động Route Message
Hành động Route message

Hành động "Validate Message" cần có một tệp XSD hoặc tệp WSDL để chạy xác nhận hợp lệ thông báo dựa vào đó. Hộp thoại thả xuống trong thanh tiêu đề của hành động này cho phép chọn kiểu tệp nào để hành động này sử dụng. Bạn có thể sử dụng các nút tròn ở phía trên đầu dòng của hành động để quyết định xem có nhập địa chỉ URL để nhận biết tệp đó bằng cách sử dụng "Enter the XSD document URL" không. Hoặc, nếu tệp đó được lưu trữ trong WSRR, thì sử dụng "The XSD document is in the registry" (Tài liệu XSD trong số đăng ký) để tìm kiếm tệp đó theo tên. Nếu chọn xác nhận hợp lệ bằng XSD, thì chỉ rõ "Validation Scope" (Phạm vi xác nhận hợp lệ) bằng cách sử dụng các nút tròn ở dưới đáy của hành động. Hình 16 cho thấy một việc xác nhận hợp lệ bằng một XSD được xác định theo một URL.

Hình 16. Xác nhận hợp lệ thông báo bằng XSD và hành động
Hành động Validate message sử dụng xác nhận hợp lệ XSD

Hình 17 cho thấy một việc xác nhận hợp lệ bằng một tài liệu WSDL. Người dùng sẽ nhận biết tệp WSDL từ WSRR đang sử dụng một đề xuất do trường tìm kiếm cung cấp, sau khi gõ basicE vào trường này. Lưu ý rằng trường "Validation Scope" không có mặt cho việc xác nhận hợp lệ bằng WSDL.

Hình 17. Xác nhận hợp lệ thông báo bằng WSDL, hành động
Hành động Validate message, sử dụng xác nhận hợp lệ WSDL validation

Hành động "Execute XSLT Transform" (Thực hiện chuyển đổi XSLT) đòi hỏi URL của bản định kiểu (stylesheet) để sử dụng cho việc chuyển đổi này, theo tùy chọn, một số tham số chuyển đến bản định kiểu. Hình 18 cho thấy một ví dụ đơn giản của hành động này, ở đây không cần có tham số nào cả. Lưu ý là "XSLT stylesheet URL" (URL của bản định kiểu XSLT) phải bắt đầu bằng hoặc là "store://" hoặc là "local://".

Hình 18. Thực hiện Chuyển đổi XSLT không có tham số nào
Thực hiện Chuyển đổi XSLT không có tham số nào

Trong Hình 19, người dùng đã đánh dấu chọn của hộp chọn để chỉ rõ một vài tham số. Bạn có thể thêm các cặp tên và giá trị được chuyển đến bản định kiểu khi chúng được điểm thực thi thực hiện. Bạn có thể thêm một tham số mới bằng cách nhấn vào Add Parameter (Thêm tham số). Bạn có thể sắp xếp lại các tham số này bằng cách sử dụng các biểu tượng mũi tên ở bên trái của mỗi hàng hoặc bằng cách kéo và thả. Một tham số có thể không có giá trị nào do đó bạn có thể sử dụng tham số này để ghi đè lên một giá trị mặc định được quy định trong bản định kiểu với một giá trị rỗng. Bạn có thể để trống các hàng tham số trong phần này và chúng sẽ đơn giản được bỏ qua khi chính sách này được lưu. Tuy nhiên, một giá trị tham số không có một tên tham số là không hợp lệ, như được biểu thị bằng cách tô đỏ trường tên cho tham số chỉ có giá trị là "valueC".

Hình 19. Thực hiện Chuyển đổi XSLT với một vài tham số
Thực hiện Chuyển đổi XSLT với một vài tham số

Lưu và chỉnh sửa

Sau khi chính sách đã hoàn thành, hãy nhấn vào nút Finish trong hộp thoại để lưu chính sách này vào WSRR. Nếu nút Finish không chạy, thì nghĩa là có một trường bắt buộc. Trường này được chỉ thị bằng một dấu hoa thị bên trái của tên trường và chưa được điền giá trị vào hoặc có một giá trị không hợp lệ trong một trong các trường. Giá trị này được chỉ thị bằng một đường viền màu đỏ xung quanh trường này, như trong Hình 19 hay một biểu tượng cảnh báo ở bên phải của trường, như trong Hình 20.

Hình 20. Một trường có một giá trị không hợp lệ
Một trường có một giá trị không hợp lệ

Sau khi chính sách đã được lưu vào WSRR, tiện ích xem chi tiết sẽ nạp một khung nhìn chính sách như trong Hình 21. Khi xem chính sách này trong tiện ích xem chi tiết, chỉ các phần có một số nội dung mới được hiển thị. Trong trường hợp này, phần có tiêu đề "Actions If Any Condition is False" (Các hành động nếu có bất kỳ điều kiện nào là sai) không được hiển thị do không có hành động nào chứa bên trong nó. Trong ví dụ này, cũng nhìn thấy một phần "Source Document" (Tài liệu nguồn). Đây là một liên kết đến các chi tiết của tài liệu do WSRR tạo ra khi đã lưu chính sách. Tài liệu này là tạo phẩm vật lý có chứa XML do WSRR tạo ra để biểu diễn chính sách này. Lưu ý rằng số lượng chi tiết có sẵn khi xem các chi tiết của một chính sách có thể khác đi nếu người quản trị hệ thống đã cấu hình khung nhìn chi tiết theo cách khác.

Để chỉnh sửa chính sách sau khi đã lưu, hãy nhấn vào biểu tượng bút chì ở góc trên bên phải của tiện ích chi tiết. Sau đó, bạn có thể chỉnh sửa chính sách giống như khi mới tạo nó.

Hình 21. Một chính sách WS-Mediation hoàn chỉnh
Một chính sách WS-Mediation đã hoàn thành

Sử dụng giao diện người dùng Web

Cũng có thể tạo ra các xác nhận WS-MediationPolicy bằng cách sử dụng giao diện người dùng Web. Lưu ý rằng đây không còn là cách làm được khuyên dùng để tạo các xác nhận WS-MediationPolicy trong WSRR nữa. Để tìm hiểu thêm về phương pháp này, hãy xem hướng dẫn Làm việc với công cụ soạn chính sách trong Trung tâm Thông tin WSRR.


Soạn chính sách bằng IBM Integration Designer

IBM Integration Designer V7.5 (Phiên bản 7.5 của Trình thiết kế tích hợp của IBM) hỗ trợ soạn ra, tải lên và thử nghiệm các tạo phẩm của DataPower bao gồm XML Schema (Lược đồ XML), WebServices, XML và các phép chuyển đổi XSL.

Bạn cũng có thể sử dụng Integration Designer để tạo và sửa đổi một WS-MediationPolicy bằng cách tạo một thư viện DataPower và tạo ra một WS-MediationPolicy bên trong nó.

Có hai trình soạn thảo có sẵn trong Integration Designer để sửa đổi một WS-MediationPolicy:

  • Ví dụ mẫu của plugin của trình soạn thảo WS-MediationPolicy cung cấp một phương pháp nhập theo hướng dẫn để tạo ra chính sách.
  • Trình soạn thảo XML có sẵn mà không yêu cầu sử dụng ví dụ mẫu trình cắm thêm được cung cấp trong bài này, nhưng nó không cung cấp nhập theo hướng dẫn hoặc việc xác nhận hợp lệ lược đồ.

Sử dụng trình cắm thêm của trình soạn thảo ví dụ mẫu WS-MediationPolicy trong Integration Designer

Trong bài này, chúng tôi đã cung cấp một trình soạn thảo WS-MediationPolicy ví dụ mẫu, để bạn có thể cài đặt trong Integration Designer bằng cách giải nén tệp zip được cung cấp trong thư mục <IID Install Directory>/drops.

Plugin này trưng ra một trình hướng dẫn WS-MediationPolicy và trình soạn thảo WS-MediationPolicy để tạo và sửa đổi các chính sách trung gian của Các dịch vụ Web (WS Mediation Policy).

Tạo một WS-MediationPolicy mới

Để tạo một WS-MediationPolicy mới, trước tiên bạn phải khởi chạy Integration Designer rồi khởi chạy trình hướng dẫn WS-MediationPolicy bằng cách chọn Business Integration > WS-MediationPolicy wizard.

WS-MediationPolicy có chứa một trang trình hướng dẫn (wizard) đơn giản (Hình 22), trong đó yêu cầu một thư viện DataPower và tên của tệp WS-MediationPolicy (Figure 23).

Hình 22. Ô cửa sổ đầu tiên của trình hướng dẫn tạo WS-MediationPolicy
Ô cửa sổ đầu tiên của trình hướng dẫn tạo WS-MediationPolicy
Hình 23. Ô cửa sổ cuối cùng của trình hướng dẫn tạo WS-MediationPolicy
Ô cửa sổ cuối cùng của trình hướng dẫn tạo WS-MediationPolicy

Chỉnh sửa và thay đổi một WS-MediationPolicy

Để chỉnh sửa hay thay đổi một WS-MediationPolicy, bạn có thể mở khung nhìn Physical Resources trong Integration Designer và mở tệp WS-MediationPolicy đã tạo ra. Việc này sẽ khởi chạy trình soạn thảo WS-MediationPolicy (Hình 24) để chỉnh sửa và thay đổi một WS-MediationPolicy.

Trình soạn thảo có hai ngăn, trình soạn thảo Design (Thiết kế) và trình soạn thảo Source (Nguồn). Cả hai khung nhìn được giữ đồng bộ với nhau nên nếu bạn thay đổi khung nhìn Design, thì khung nhìn Source được cập nhật và ngược lại.

Hình 24. Trình soạn thảo WS-MediationPolicy
Trình soạn thảo WS-MediationPolicy

Sử dụng Trình soạn thảo XML (XML Editor) để chỉnh sửa một WS-MediationPolicy trong Integration Designer

Integration Designer có một Trình soạn thảo XML để bạn có thể sử dụng để chỉnh sửa một tệp XML. Cách dễ nhất để tạo ra một WS-MediationPolicy là tạo ra một tệp XML trong một dự án DataPower và đặt đoạn mã XML khung sườn này bên trong tệp XML mới được tạo ra, như trong Liệt kê 17.

Liệt kê 17. Chính sách rỗng với khai báo vùng tên WS-MediationPolicy
<?xml version="1.0" encoding="UTF-8"?>
<wsp:Policy xmlns:wsp="http://www.w3.org/ns/ws-policy" 
     xmlns:wsme="http://www.ibm.com/xmlns/stdwip/2011/02/ws-mediation">
</wsp:Policy>

Sau khi WS-MediationPolicy được tạo ra, bạn có thể tải nó lên một thiết bị DataPower trực tiếp từ bên trong Integration Designer bằng cách sử dụng Khung nhìn DataPower Appliance (Thiết bị DataPower).

Để biết thêm thông tin, xem Sử dụng Integration Designer với WebSphere DataPower.


Soạn chính sách bằng một trình soạn thảo

Nếu không có sẵn WSSR hoặc Integration Designer, bạn vẫn có thể tạo ra một WS-MediationPolicy bằng cách sử dụng bất kỳ trình soạn thảo XML hoặc trình soạn thảo văn bản ưa thích nào. Hình 25 cho thấy một trình soạn thảo văn bản đơn giản để tạo ra một chính sách trung gian mới dựa trên một khuôn mẫu được nhân bản từ một khuôn mẫu trong thư mục store://policies/templates của thiết bị.

Hình 25. Tạo WS-MediationPolicy trong một trình soạn thảo văn bản
Tạo WS-MediationPolicy trong một trình soạn thảo văn bản

Chính sách này định tuyến các thông báo đến một máy chủ mới. Đó là một cách thực hành tốt nhất để định nghĩa các thuộc tính Name (wsp: Name) và Id (WSU: Id) cho chính sách của bạn. Bây giờ khi đã định nghĩa chính sách rồi, bạn có thể đính kèm nó vào một dịch vụ WSDL bằng cách sử dụng DataPower WebGUI (Giao diện người dùng đồ họa Web của DataPower).

Các bước để đính kèm một chính sách rất đơn giản (xem Hình 26). Trước tiên, bạn phải biết bạn muốn đính kèm các chính sách vào đâu. Trong trường hợp này, chúng tôi đã chọn chủ đề chính sách dịch vụ và chúng tôi chọn nút WS-Policy cho dịch vụ này (1). Chính sách này được tải lên thư mục "local://" với tên lĩnh vực (2) và đính kèm nó (3). Cuối cùng, khi chúng tôi nhấn Done (4), các thay đổi sẽ được áp dụng cho ủy quyền dịch vụ Web (Web service proxy). Sau khi đính kèm chính sách, tất cả các thông báo đưa vào dịch vụ có chính sách định tuyến kèm theo đều được định tuyến tới máy chủ mới theo quy định của chính sách đó.

Hình 26. Đính kèm chính sách trong giao diện người dùng đồ họa Web
Đính kèm chính sách trong giao diện người dùng đồ họa Web

Một điều bạn có thể hỏi ngay bây giờ là: "Chính sách định tuyến làm việc như thế nào nếu tầng sau là "https://", thay vì là "http://"?" DataPower hỗ trợ các tham số chính sách ảnh hưởng đến cách chính sách được thực thi như thế nào trên thiết bị. Trong trường hợp là https, cần có một tham số chính sách SSL Profile sao cho ủy quyền (proxy) có thể tìm đến khóa hay chứng chỉ cần thiết để dàn xếp đúng đắn kết nối SSL đến máy chủ tầng sau mới. Một danh sách đầy đủ của các tham số chính sách được hỗ trợ cho WS-MediationPolicy được hiển thị trong Bảng 5.

Bảng 5. Danh sách các tham số chính sách cho WS-MediationPolicy và các ý nghĩa của chúng
TênMô tả
Log Priority (Ưu tiên ghi nhật ký)Thiết lập ưu tiên ghi nhật ký cho các thông báo ghi nhật ký là kết quả của xác nhận chính sách Điều kiện (Condition).
SSL Profile (Lược tả SSL)Thiết lập SSL Proxy Profile (Lược tả ủy quyền SSL) để xác nhận chính sách RouteMessage sử dụng nó. Điều này là cần thiết để xử lý phần phía máy khách của cái bắt tay SSL với một tầng sau đòi hỏi SSL.
Output Type (Kiểu đầu ra)Thiết lập kiểu đầu ra cho xác nhận chính sách ExecuteXSL. Các giá trị hợp lệ là xml, binary (nhị phân) và default (mặc định).
SLM Peer Group (Nhóm ngang hàng SLM)Thiết lập SLM Peer Group để cho xác nhận chính sách Điều kiện sẽ sử dụng. Các nhóm ngang hàng cho phép trao đổi dữ liệu SLM giữa một nhóm các thiết bị.
SLM Credential Class (Lớp thông tin đăng nhập SLM)Thiết lập SLM Credential Class để cho xác nhận chính sách Điều kiện sẽ sử dụng. Một lớp các thông tin đăng nhập SLM xác định một tập hợp những người dùng (các thông tin đăng nhập) phụ thuộc vào một chính sách SLM. Một Credential Class được tự động tạo ra cho chính sách SLA, nhưng Policy Parameter (Tham số chính sách) sẽ ghi đè lên giá trị mặc định.
SLM Resource Class (Lớp tài nguyên SLM)Thiết lập SLM Resource Class để cho xác nhận chính sách Điều kiện sẽ sử dụng. Một lớp tài nguyên SLM xác định một tập hợp các tài nguyên phụ thuộc vào một chính sách SLM.
Configuration Optimization (Tối ưu hóa cấu hình)Cấu hình được tạo ra từ mỗi xác nhận đã gặp trong chính sách, ngay cả khi nó không thể đạt tới được. Điều này rất có ích để gỡ lỗi chính sách, nhưng đòi hỏi phải có thêm khả năng trong thời gian chạy để thực hiện các hành động xử lý bổ sung. Tham số Configuration Optimization, khi được đặt là "on" (bật lên), báo cho thiết bị biết để loại bỏ các xác nhận chính sách không thể đạt được.
WSRR Server (Máy chủ WSRR)Xác nhận chính sách ValidateMessage có thể sử dụng một URL có liên quan đến một máy chủ WSRR. Tham số này được dùng để quyết định cấu hình máy chủ WSRR cần dùng nếu không thể xác định nó một cách tự động.

Việc sử dụng WS-MediationPolicy để phân tách mục đích chính sách ("cần làm gì") khỏi cấu hình nền tảng thực thi ("thực hiện nó như thế nào") mang lại nhiều lợi ích, ví dụ:

  • Tách các mối quan tâm giữa các nhà phát triển chính sách vận hành và các nhà quản trị DataPower bằng cách hỗ trợ các tài liệu chính sách để chứa đựng mục đích chính sách không có các chi tiết cấu hình.
  • Tạo điều kiện thuận lợi để chọn dùng quá trình quản trị và quản lý chính sách bằng việc nắm chắc các sản phẩm, chẳng hạn như WSRR.
  • Cho phép khả năng mở rộng quy mô chọn dùng thiết bị DataPower bằng cách tăng thêm số lượng các cá nhân có thể tạo ra chính sách tác động đến các cổng kết nối dịch vụ.
  • Sử dụng các đặc tả các tiêu chuẩn ngành nghề để làm giảm thời gian học tập và tăng thêm các công cụ có sẵn.

Kết luận

Bài này trình bày các phương pháp khác nhau để soạn các tài liệu WS-MediationPolicy, chẳng hạn như trình soạn thảo trung gian hòa giải WSRR V8.0, các plugins (tải về plugin) của trình soạn thảo Integration Designer và các trình soạn thảo XML phổ biến nhất. Phương pháp tổng thể tốt nhất phụ thuộc vào các yêu cầu của quá trình phát triển của bạn, cũng như các quá trình quản trị chính sách được chọn dùng. Bất kể bạn chọn phương pháp nào để tạo các chính sách, WS-MediationPolicy vẫn cho phép bạn tập trung vào việc giải quyết yêu cầu CNTT về nghiệp vụ thay cho các thay đổi cấu hình vận hành.

Cuối cùng, điều quan trọng cần nhớ các mẫu thực thi của cổng kết nối dịch vụ phổ biến mà bảng từ vựng chính sách mới này cho phép bạn thể hiện:

  • Quản lý lưu lượng (QoS)
  • Định tuyến
  • Xác nhận hợp lệ thông báo
  • Dịch thông báo (chuyển đổi phiên bản)

Bạn có thể nhanh chóng triển khai các mẫu này bằng cách sử dụng trình soạn thảo chính sách của WSRR V8.0 hoặc sao chép các khuôn mẫu ví dụ được cung cấp trong thiết bị và sau đó đính kèm chúng vào dịch vụ Web mong muốn. WS-MediationPolicy cũng hỗ trợ một loạt các tham số cấu hình chính sách để có thể kiểm soát cách tạo các lựa chọn cấu hình.

Bài này đã giới thiệu cách bạn có thể tận dụng lợi thế của tính năng đa năng này để có thể dễ dàng và tiến nhanh hơn trên con đường của mình khi theo đuổi các mục tiêu cụ thể về quản trị SOA và quản lý chính sách. Các bài sau trong loạt bài này sẽ trình bày cách khai báo Các thỏa thuận mức dịch vụ (SLA - Service Level Agreements) bằng cách sử dụng các bộ lọc nội dung thông báo kết hợp với các tệp đính kèm của WS-Policy và cách tạo các lĩnh vực chính sách tùy chỉnh riêng của bạn cho DataPower.


Các tải về

Mô tảTênKích thước
WS-MediationPolicy schemaws-mediationpolicy-1.6-2011-02.xsd5KB
Plug-in for IBM Integration Designercom.ibm.wbit.wdp.policy_8.0.0.zip41KB

Tài nguyên

Học tập

Thảo luận

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=SOA và dịch vụ Web
ArticleID=929676
ArticleTitle=Quản trị SOA bằng cách sử dụng WebSphere DataPower và WebSphere Service Registry and Repository, Phần 1: Tận dụng các khả năng của WS-MediationPolicy
publish-date=05142013