Quản trị SOA bằng cách sử dụng WebSphere DataPower và WebSphere Service Registry and Repository, Phần 2: Tạo và thực thi bảng từ vựng chính sách tùy chỉnh

Phần 1 của loạt bài này đã giới thiệu khả năng trung gian thông báo mới mà WebSphere® DataPower đã triển khai thực hiện trong phiên bản firmware 5.0.0. Phần 2 này sẽ giải thích cách mở rộng những khả năng này bằng cách cho phép sử dụng các bảng từ vựng chính sách tùy chỉnh để triển khai các mẫu xử lý ủy quyền (proxy) cụ thể chưa được đề cập trong các lĩnh vực chính sách dựng sẵn.

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.



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.



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.



Oswaldo Gago, Kỹ sư tư vấn phần mềm, IBM

Ảnh của Oswaldo GagoOswaldo Gago là một Kỹ sư tư vấn phần mềm về phát triển DataPower của WebSphere. Anh hiện là nhà phát triển chính về DataPower Web Service Proxy, WSPolicy và tích hợp WSRR (WebSphere Service Registry and Repository). Oswaldo gia nhập IBM vào năm 2002 là thành viên của nhóm Text to Speech (Chuyển văn bản sang tiếng nói) của IBM sau khi tốt nghiệp xuất sắc với bằng Thạc sĩ về Khoa học máy tính của trường Đại học Miami, Florida.



15 05 2013

Giới thiệu

Phần 1 của loạt bài này đã giới thiệu khả năng trung gian thông báo mới mà WebSphere DataPower đã thực hiện trong phiên bản 5.0.0. Phần 2 này sẽ giải thích cách mở rộng những khả năng này bằng cách cho phép sử dụng các bảng từ vựng chính sách tùy chỉnh để triển khai các mẫu xử lý ủy quyền (proxy) cụ thể chưa được đề cập đến trong các lĩnh vực chính sách dựng sẵn. Bài này sẽ hướng dẫn bạn đi qua các bước cần thiết để định nghĩa một bảng từ vựng chính sách tùy chỉnh và thực thi nó như là một SLD hoặc SLA bằng cách sử dụng WebSphere DataPower và WebSphere Service Registry and Repository (WSRR - Kho lưu trữ và Đăng ký dịch vụ WebSphere).

Bài này được viết với giả định rằng bạn đã quen thuộc với việc cấu hình XSLT, XML, WS-Policy (Các dịch vụ Web-Chính sách) và DataPower. Bạn có thể tìm hiểu thêm về WS-Policy bằng cách đọc phần Tài nguyên về WS-Policy kèm theo ở cuối bài này. Bạn có thể tìm hiểu thêm về cách cấu hình DataPower và chính sách xử lý DataPower trong Cẩm nang về Thiết bị SOA của DataPower (DataPower SOA Appliance Handbook) hoặc Trung tâm Thông tin của DataPower.

Các bản tải về

Bài này cung cấp các tệp sau đây để bạn tải về:

  • yourco.com-example.xsl: Đây là tệp chính sách tùy chỉnh ví dụ mẫu được trình bày trong bài.
  • mediatemessage-example.xml: Đây là tệp chính sách ví dụ mẫu để giới thiệu cách sử dụng xác nhận MediateMessage.
  • datapower-export-configutils.zip: Đây là tệp xuất khẩu cấu hình của DataPower, trong đó chứa các tiện ích để xử lý tệp export.xml để chuẩn bị nó hoặc đưa vào một bản định kiểu (stylesheet) ánh xạ chính sách và một cách xác nhận hợp lệ lược đồ cấu hình của DataPower.
  • YourCoExampleWidget.zip: Đây là tệp ví dụ mẫu của tiện ích (widget) của WSRR để thực hiện soạn ra chính sách tùy chỉnh YourCo.com.
  • YourCoExampleWidgetProjects.zip: Đây là tệp mã nguồn cho ví dụ mẫu của tiện ích WSRR.

Các lợi ích của một bảng từ vựng chính sách tùy chỉnh

WebSphere DataPower Appliance (Thiết bị DataPower của WebSphere) có thể thực thi các bảng từ vựng WS-SecurityPolicy (Các dịch vụ Web-An ninh) và WS-MediationPolicy (Các dịch vụ Web-Chính sách trung gian) dùng ngay được. Các bảng từ vựng chính sách này có ích, nhưng có khả năng là các bảng từ vựng này, được xây dựng để cung cấp các giải pháp dịch vụ web đa năng, sẽ không đáp ứng hoàn toàn được các nhu cầu nghiệp vụ riêng của bạn. Ví dụ, khả năng định nghĩa bảng từ vựng riêng của bạn trở nên đặc biệt quan trọng khi nhu cầu bảo đảm sử dụng lại tối đa với khả năng rủi ro thấp nhất sẽ buộc phải nâng cao ngữ nghĩa của chính sách lên một mức độ cao hơn nhiều, do đó giảm thiểu nhiều rủi ro do tính linh hoạt của các xác nhận ở mức chi tiết hơn trong các bảng từ vựng chính sách đó đưa vào. Nói cách khác, mức chi tiết (LoD) của một bảng từ vựng chính sách tùy chỉnh phụ thuộc vào từng nhu cầu của doanh nghiệp nhằm cân bằng yếu tố về tính nhanh nhẹn của chính sách (nó có thể đáp ứng với những thay đổi về các nhu cầu kinh doanh nhanh như thế nào) với các yếu tố về rủi ro vận hành và yếu tố chi phí vận hành của nó (tính linh hoạt của nó phải trả giá ra sao về mặt thử nghiệm và các rủi ro về ổn định vận hành).

Vì vậy, những lợi ích của việc tạo ra các bảng từ vựng chính sách tùy chỉnh có thể rất lớn (về khả năng tiêu dùng của quá trình quản lý CNTT và giảm thiểu rủi ro và chi phí vận hành) đối với hầu hết các doanh nghiệp muốn phát triển vượt xa các bảng từ vựng chính sách sử dụng chung do DataPower đưa ra.

Một cách để minh họa cho điều này là giả định rằng doanh nghiệp của bạn đã định nghĩa các yêu cầu xử lý thông báo sau đây cho các dịch vụ mà họ cung cấp:

  • Tất cả các dịch vụ phải thực thi ít nhất là một trong các mức bảo vệ sau đây:
    • Standard (Tiêu chuẩn): Mức bảo vệ này chỉ yêu cầu xác thực tên người dùng/mật khẩu thông qua một đầu trang xác thực của HTTP hoặc <soap:header>.
    • Secure (An toàn): Mức bảo vệ này yêu cầu rằng tất cả các yêu cầu phải chứa một WS-Security hoặc thẻ xác thực LTPA để xác thực. Tất cả các thông báo phải có chữ ký và được mã hóa. Mức này cần phải ghi nhật ký kiểm toán.
    • Restricted (Có giới hạn): Đây là yêu cầu bảo mật giống như mức "Secure" ở trên, nhưng nó thêm vào là phải cấp phép để truy cập vào một hoạt động dịch vụ cụ thể hoặc tài nguyên cụ thể bằng cách sử dụng điểm thực thi quản lý truy cập của doanh nghiệp.
  • Tất cả các thông báo phải được xác nhận hợp lệ hoặc được chuyển đổi theo các hướng dẫn sau đây:
    • Phải loại bỏ tất cả các yêu cầu tuân theo lược đồ V1.0 vì nó không còn được lưu hành nữa và không còn được phục vụ (được hỗ trợ) nữa.
    • Phải chuyển đổi tất cả các yêu cầu tuân theo các lược đồ V1.1 và V1.2 thành lược đồ V2.0. Các đáp ứng đến theo lược đồ V2.0 và phải được chuyển đổi để tuân theo lược đồ yêu cầu ban đầu. Điều này cung cấp khả năng tương thích ngược với các phiên bản cũ hơn của lược đồ dữ liệu và cho phép một quy trình đánh dấu là lỗi thời và di trú có quản lý.
    • Tất cả các thông báo tuân theo lược đồ V2.0 không yêu cầu xử lý thêm nữa trên các luồng yêu cầu và phản hồi. Đây là phiên bản mới nhất của lược đồ dữ liệu mà dịch vụ tầng sau hiện đang hỗ trợ.
  • Tất cả các thông báo phải được định tuyến đến một trong các kiểu tầng sau dưới đây để xử lý:
    • Tiêu chuẩn: Không có các yêu cầu định tuyến đặc biệt nào. Sử dụng tầng sau mặc định theo quy định của dịch vụ WSDL.
    • Tính sẵn sàng cao: Kiểu tầng sau này định tuyến đến một tầng sau sẵn sàng cao 24x7.
    • Tính sẵn sàng cao với độ trễ thấp: Kiểu tầng sau này định tuyến đến một tầng sau sẵn sàng cao 24x7 đã được tối ưu hóa để phản hồi với độ trễ thấp.

Cách thông thường để thực thi các yêu cầu nghiệp vụ như vậy là cấu hình các hành động xử lý cho mỗi dịch vụ được DataPower uỷ quyền, theo các yêu cầu được định nghĩa cho dịch vụ đó. Điều này đòi hỏi các thay đổi cấu hình cho các quy tắc xử lý với từng dịch vụ, có nghĩa là mỗi dịch vụ đã triển khai đều đòi hỏi các nỗ lực phát triển, thử nghiệm đơn vị và Bảo đảm chất lượng (QA) trước khi sản xuất duy nhất. Tất cả các chi phí bổ sung này được nhân thêm với các yêu cầu không chức năng bổ sung mà các SLA phải hỗ trợ, chẳng hạn như Các thỏa thuận về chất lượng dịch vụ (QoS).

Ngược lại, việc thực thi các yêu cầu nghiệp vụ này như các xác nhận chính sách (việc trưng ra khả năng thay đổi hạn chế) cung cấp các lợi ích về giảm chi phí phát triển (định nghĩa, soạn ra và thử nghiệm các xác nhận chỉ một lần, sau đó áp dụng chúng nhiều lần khi cần). Điều này cũng làm giảm các vấn đề về tính ổn định thời gian chạy vì cấu hình này được thiết bị tạo tự động theo một quá trình lặp lại nhiều lần và xác định, không có khả năng đưa vào lỗi của con người hoặc khả năng thay đổi bất ngờ.

Hơn nữa, khả năng sử dụng lại các xác nhận chính sách với các SLA khác nhau (chẳng hạn như nhiều người tiêu dùng và nhiều nhà cung cấp dịch vụ) làm tăng lên nhiều lần các lợi ích của việc chọn dùng thực thi chính sách. Ví dụ, việc áp dụng bảng từ vựng chính sách như đã mô tả ở trên với khả năng thực thi SLA được cung cấp trong phiên bản 5.0.0 của chương trình cơ sở của DataPower cho phép chính sách đó định tuyến các khách hàng "Vàng" tới tầng sau "Sẵn sàng cao" và tất cả các khách hàng khác (không phải "Vàng") tới một tầng sau "Tiêu chuẩn".


Thực thi chính sách trên một thiết bị DataPower

Bây giờ chúng tôi đã trình bày xong những lợi ích về việc sử dụng một bảng từ vựng của lĩnh vực chính sách tùy chỉnh, bạn có thể sẵn sàng đi sâu vào một ví dụ. Nhưng trước khi chúng ta làm điều đó, hãy tìm hiểu một số thông tin cơ bản để giúp bạn hiểu rõ ví dụ này sẽ đóng vai trò nào trong việc cung cấp chính sách dịch vụ và nó tác động đến hoạt động của thiết bị ra sao.

Tiêu chuẩn W3C có tên là "WS-Policy" cung cấp một khung công tác cho các giải pháp chính sách để mô tả và tiêu dùng các yêu cầu vận hành nghiệp vụ khi sử dụng một mô hình dữ liệu cụ thể để giúp nắm bắt các mục đích nghiệp vụ dưới dạng chính sách. Đặc tả WS-Policy - Framework (Các dịch vụ Web-Chính sách - Khung công tác) bắt buộc là các biểu thức chính sách được biểu diễn dưới dạng XML. Thiết bị DataPower, làm một điểm thực thi chính sách (PEP) sử dụng các biểu thức WS-Policy và biến đổi chúng thành cấu hình nguyên gốc (có thể thực thi được). Hệ thống con Khung công tác chính sách của DataPower (DataPower Policy Framework) xử lý một phần của việc xử lý chính sách-thành-cấu hình.

Khung công tác DataPower này tạo ra một chính sách có hiệu lực bằng cách chuẩn hóa các biểu thức chính sách thành các lựa chọn và các lựa chọn thành các xác nhận. Việc biến đổi một xác nhận chính sách riêng lẻ thành cấu hình DataPower được giao cho các bản định kiểu trình ánh xạ chính sách của DataPower (DataPower Policy Mapper), các bản định kiểu này dùng XML của WS-Policy và tạo cấu hình XML của DataPower.

Khung công tác DataPower sau đó lắp ráp các đáp ứng của các bản định kiểu trình ánh xạ chính sách của DataPower riêng lẻ thành cấu hình cuối cùng được áp dụng cho các cổng kết nối dịch vụ bị tác động bởi chính sách đó. Bước "lắp ráp cuối cùng" này bảo đảm rằng cấu hình được tạo ra đúng, ngay cả khi sử dụng nhiều hơn một bảng từ vựng chính sách trong các lựa chọn thay thế. Hình 1 cung cấp một hình ảnh về luồng công việc và các thành phần của quá trình này.

Hình 1. Tổng quan về Khung công tác chính sách của DataPower
Tổng quan về Khung công tác chính sách của DataPower

Thành phần Khung công tác chính sách của DataPower (DataPower Policy Framework) là một trình xử lý (processor) chính sách có khả năng mở rộng để có thể tạo cấu hình DataPower từ các xác nhận của WS-Policy. Phiên bản 5.0.0 của chương trình cơ sở của thiết bị bao gồm một số lĩnh vực chính sách dùng ngay được để bạn có thể dùng ngay lập tức để tác động đến hành vi thực thi của cổng kết nối. Nó cũng cung cấp khả năng mở rộng để thêm các lĩnh vực chính sách tùy chỉnh vào Trình ánh xạ chính sách (Policy Mapper).

Để thêm các lĩnh vực chính sách tùy chỉnh mới, cần phải cung cấp một bản định kiểu của Trình ánh xạ chính sách cho mỗi lĩnh vực chính sách mới mà bạn muốn thực thi với PEP (Điểm thực thi chính sách). Việc tạo một cơ chế chuyển đổi như vậy đòi hỏi bạn hiểu cách sử dụng các quy tắc xử lý, các hành động xử lý của DataPower và bất kỳ các đối tượng tiên quyết nào (như Chính sách SLM và AAA) để đạt được các mục tiêu thực thi chính sách của mình. Ví dụ, hãy tự hỏi mình: "Tôi sẽ cấu hình quy tắc xử lý một cách trực tiếp trong Web Service Proxy ra sao để đạt được các kết quả mong muốn?" Thực ra, một ý tưởng tốt là thực sự tạo ra bản triển khai thực hiện ban đầu với quy tắc xử lý trong WebGUI (Giao diện người dùng đồ họa Web), thử nghiệm nó rồi xuất khẩu quy tắc xử lý đó để dùng làm điểm khởi đầu cho bản định kiểu ánh xạ chính sách của bạn. Để biết thêm thông tin về các quy tắc xử lý và các hành động xử lý của DataPower, hãy xem Trung tâm Thông tin DataPowerCẩm nang thiết bị SOA của DataPower.


Định nghĩa một bảng từ vựng chính sách tùy chỉnh

Một kế hoạch nhỏ cũng phải qua một chặng đường dài khi muốn định nghĩa một bảng từ vựng chính sách tùy chỉnh. Một khi bạn hiểu được các yêu cầu nghiệp vụ, có một vài bước lập kế hoạch đơn giản sẽ áp dụng trực tiếp vào việc thực hiện của bạn. Việc lập kế hoạch cẩn thận và với các mục tiêu thực tế là rất quan trọng để tránh những sự phức tạp không cần thiết sau này.

Bước đầu tiên là chọn một vùng tên chính sách XML cho các xác nhận của bạn. Vùng tên quan trọng vì nó giúp loại bỏ khả năng các xác nhận do bạn định nghĩa sẽ xung đột với các xác nhận đã tạo ra trong một lĩnh vực chính sách khác. Chúng tôi sẽ sử dụng http://yourco.com/policy/standard/2012-08 cho bài này. Tiền tố vùng tên cho vùng tên này sẽ là ycps. Lưu ý rằng trong vùng tên này đã đưa vào một ngày tháng. Một cách thực hành tốt nhất là đưa thêm ngày tháng hoặc mã định danh phiên bản vào vùng tên để hỗ trợ ý niệm chung về các phiên bản tương lai của lĩnh vực chính sách này.

Bước tiếp theo là định nghĩa các xác nhận mà bạn muốn thực thi. Trong ví dụ ở đầu bài này, chúng tôi đã định nghĩa ba yêu cầu nghiệp vụ mức cao nhất cần thực thi trong chính sách. Chúng tôi khuyến cáo rằng các bảng từ vựng chính sách nên rất giống với ngữ nghĩa học CNTT của doanh nghiệp đang được áp dụng, vì làm như vậy sẽ làm cho người dùng dễ chọn dùng và cải thiện việc kiểm nghiệm nền tảng quản trị chính sách (như WSRR). Vì vậy, chúng tôi sẽ ánh xạ cả ba yêu cầu nghiệp vụ ban đầu được liệt kê ở trên tới các xác nhận riêng lẻ sao cho bảng từ vựng chính sách tùy chỉnh của chúng tôi có ba xác nhận.

Một cú pháp ví dụ mẫu cho các xác nhận này có trong Liệt kê 1 dưới đây. Các xác nhận được đề cập trong bài này chỉ dành để thảo luận và không cung cấp chức năng nào trong khuôn mẫu đã cho. Mặc dù chúng tôi giới thiệu cách chèn một cấu hình DataPower vào bản định kiểu xác nhận chính sách, việc triển khai các xác nhận như vậy được coi là một bài tập cho người đọc.

Liệt kê 1. Định nghĩa cú pháp của từng xác nhận chính sách
<ycps:ProtectService>
       <ycps:Standard/> | <ycps:Secure/> | <ycps:Restricted/>
</ycps:ProtectService>

<ycps:MediateMessage/>

<ycps:RouteMessage>
       <ycps:Standard/> | <ycps:HighAvailability/> | <ycps:LowLatency/>
</ycps:RouteMessage>

Như bạn có thể thấy từ ba xác nhận đã định nghĩa (ProtectService, MediateMessage, và RouteMessage), chúng đều không cung cấp thông tin nào về hành vi cụ thể hoặc cung cấp cách sẽ thực thi nó. Nó không có ý định cho thấy PEP cần thực hiện những hành động cụ thể nào để xử lý thông báo có giới hạn hoặc ở đâu có các máy chủ sẵn sàng cao. Sự bỏ qua này là có chủ ý, vì làm như vậy sẽ tách xác nhận (ý định của yêu cầu nghiệp vụ) ra khỏi việc thực hiện trên PEP và cho phép thay đổi cách diễn giải thế nào là "an toàn" khi các yêu cầu bảo đảm an toàn CNTT của doanh nghiệp thay đổi bằng cách sửa đổi việc thực hiện (chẳng hạn như việc ánh xạ) trên PEP. Lưu ý rằng nên cẩn thận khi thực hiện các thay đổi hành vi của xác nhận. Hãy xem xét việc thay đổi vùng tên của lĩnh vực chính sách đối với những thay đổi lớn trong hành vi.

Lưu ý rằng thứ tự các xác nhận trong một chính sách là quan trọng. Ví dụ, các hoạt động mật mã (mà các mức bảo vệ "Secure" và "Restricted" thường đòi hỏi) sẽ cần xảy ra trước khi áp dụng trung gian hòa giải tải tin thông báo trong lúc xử lý yêu cầu giao dịch.

Các tham số chính sách: Chi tiết nhỏ cuối cùng

Một phần làm nên thiết kế tốt cho một xác nhận chính sách là phải biết những gì cần được thể hiện dưới dạng một tham số xác nhận và những gì cần được thể hiện như là một phần của việc thực hiện PEP. Thỉnh thoảng, bạn rơi vào một tình huống chẳng có trường hợp nào trong đó phù hợp cả. Xác nhận RouteMessage trong WS-MediationPolicy là một ví dụ tốt. WS-MediationPolicy sử dụng xác nhận RouteMessage để định tuyến các thông báo đến một điểm đầu cuối khác. Nhưng, điều gì sẽ xảy ra nếu đích đến đòi hỏi SSL (Tầng ổ cắm bảo mật)? Trên một thiết bị DataPower, giao thức bắt tay SSL yêu cầu một Lược tả SSL (SSL Profile). Nếu bạn sử dụng một hành động xử lý "định tuyến" theo khả năng này, bạn phải chỉ rõ một tên đối tượng của Lược tả SSL như là một phần của cấu hình cho hành động định tuyến đó. Điều đó có thể chấp nhận được với một hành động xử lý duy nhất, nhưng thực hiện điều này như thế nào trong một xác nhận của WS-Policy?

Vấn đề là ở chỗ không thể chỉ rõ tên đối tượng của lược tả SSL này làm một tham số cho xác nhận chính sách (chẳng hạn như trong xác nhận chính sách) vì tên này buộc xác nhận đó với một việc thực hiện PEP cụ thể (các xác nhận của WS-Policy cần phải không biết đến PEP). Tương tự như vậy, cũng không thể viết mã vào việc thực hiện xác nhận đó. Làm như vậy sẽ hạn chế rất nhiều khả năng áp dụng của xác nhận. Xác nhận đó chỉ làm việc với một tầng sau hoặc tệ hơn, xác nhận đó đòi hỏi một Lược tả SSL có một tên riêng. Giải pháp tốt nhất cho vấn đề hóc búa này là kết nối các điểm lại bằng cách sử dụng một tham số chính sách để buộc hành vi đã quy định trong xác nhận đó với việc thực hiện thực tế. Bằng cách đó, chính sách này vẫn không cần biết rõ về PEP và xác nhận đó vẫn linh hoạt.


Giới thiệu ví dụ về lĩnh vực chính sách tùy chỉnh

Bây giờ bạn biết rằng XML Chính sách (Policy XML) được chuyển đổi thành một XML cấu hình với một bản định kiểu ánh xạ chính sách, hãy xem một ví dụ được cung cấp kèm theo bài này.

Điều đầu tiên cần lưu ý là việc khai báo vùng tên của lĩnh vực chính sách cho thiết bị, như hiển thị trong Liệt kê 2. Phần này cho thiết bị biết sẽ sử dụng phép chuyển đổi XSL nào với các xác nhận chính sách được định nghĩa trong vùng tên chính sách http://yourco.com/policy/standard/2012-08 để chuyển đổi chúng thành một cấu hình.

Liệt kê 2. Khai báo một lĩnh vực chính sách trong một bản định kiểu ánh xạ chính sách
<dpe:summary xmlns="">
 <!-- Comment the following
                    line to prevent this policy domain from being processed
                    --><dppolicy:domain>http://yourco.com/policy/standard/2012-08</dppolicy:domain>
        <operation>xform</operation>
        <description>YourCo.com Custom Policy Support</description>
 </dpe:summary>

Điều tiếp theo cần lưu ý là mục <xsl:template match="/"> của bản định kiểu. Khuôn mẫu này sẽ lo một vài vấn đề nội trợ (chẳng hạn như nêu rõ tên của các bối cảnh đầu vào và đầu ra - sẽ bàn nhiều hơn về điều này trong phần sau), rồi nó áp dụng các khuôn mẫu đó với mỗi xác nhận có trong chính sách đó, như trong Liệt kê 3.

Liệt kê 3. Áp dụng các khuôn mẫu với mỗi xác nhận
 <!-- process each assertion in the
                    alternative -->
<xsl:template match="wsp:All">
    <xsl:apply-templates mode="assertion"/>
</xsl:template>

Lưu ý rằng một biểu thức WS-Policy duy nhất có thể có nhiều lựa chọn chính sách, nên khung công tác ánh xạ chính sách trên thiết bị sẽ xử lý việc dịch chính sách bằng cách gọi riêng bản định kiểu ánh xạ chính sách cho từng lựa chọn gặp phải trong chính sách. Điều này có nghĩa là bạn không phải quan tâm đến cách cung cấp thông tin cấu hình riêng rẽ cho mỗi lựa chọn hoặc thứ tự xử lý các lựa chọn đó.

Mỗi lựa chọn có thể chứa nhiều hơn một xác nhận chính sách ( thực tế là "1 .. *"), vì vậy bạn phải bảo đảm rằng mỗi xác nhận mà bạn xử lý sẽ được xử lý đúng đắn bằng cách gói cấu hình cho mỗi xác nhận vào một phần tử <dppolicy:config> như trong Liệt kê 4 và thiết lập các thuộc tính uri, assertionNodirection.

  • Thuộc tính uri được sử dụng để buộc cấu hình mà bạn tạo ra vào lĩnh vực chính sách của bạn. Giá trị được thiết lập là vùng tên của lĩnh vực chính sách của bạn.
  • Thuộc tính assertionNo được dùng để cho biết thứ tự tương đối mà xác nhận này xuất hiện trong lựa chọn. Điều này là cần thiết vì khung công tác ánh xạ chính sách của thiết bị cố gắng để thực thi các xác nhận theo thứ tự mà chúng đã được chuẩn hóa thành các chính sách có hiệu lực cuối cùng. Lưu ý rằng nếu thứ tự thực thi không được bảo đảm thì đặc tả Khung công tác WS-Policy (WS-Policy Framework) sẽ không yêu cầu thực thi các xác nhận theo thứ tự xuất hiện của chúng trong một lựa chọn chính sách. Xem Khung công tác của Chính sách các dịch vụ web 15.1: Lựa chọn chính sách.
  • Thuộc tính direction (hướng) áp đặt hướng xử lý áp dụng cho xác nhận đó (ví dụ, yêu cầu, đáp ứng hoặc cả hai). Các giá trị hợp lệ cho thuộc tính direction là request-rule (quy tắc-yêu cầu) và response-rule (quy tắc-đáp ứng). Nếu bạn bỏ qua thuộc tính direction, thì các hành động được cung cấp sẽ áp dụng cả hai hướng của quy tắc.

Các nội dung của phần tử <dppolicy:config> trông rất quen thuộc nếu bạn đã xem xét kỹ cấu hình của một thiết bị DataPower. Đoạn mã được hiển thị trong Liệt kê 4 cho thấy khuôn mẫu để tạo ra XML cấu hình cho xác nhận MediateMessage sẽ trông như thế nào.

Liệt kê 4. Tạo cấu hình cho một xác nhận duy nhất
 <!-- TEMPLATE
                    -----> <!-- assertion "MediateMessage" --> <!--
                    This basically "does nothing" by performing an identity transform to copy
                    the input to the output.
                    -->
  <xsl:template mode="assertion" match="ycps:MediateMessage">


                    <!-- This assertion contains examples of best practices - Using the
                    correct input context ('input-context') and output context
                    ('output-context'). - Use policy key to correlate processing actions
                    to policy - A method for creating unique names for StylePolicyAction
                    (see: "actionName") It also contains some tips
                    like - Using xsl:message with dpe:priority="error" for debug
                    purposes. - The practice of placing the generated configuration XML
                    into a variable "config" so it can be sent to the log, or written to
                    the temporary directory using the dump-nodes extension function.
                    
                    -->
        
    <xsl:message dpe:priority="error">Enter template MediateMessage: . . .</xsl:message>


                    <!-- The framework passed in a policykey value, this must be added to
                    the processing actions in order to properly instrument source policy
                    origin information into monitoring subsystem and UI presentation
                    -->
    <xsl:variable name="policyKey" select="./@policy-key"/>

    <xsl:variable name="config">


                    <!-- generate processing actions (assertionNo = position of assertion in
                    the normalized policy alternative)
                    -->
      <dppolicy:config uri="{$nsuri}" assertionNo="{position()}"
                                      direction="{'request-rule'}">


                    <!-- Create the name of the action. It must be unique within the
                    DataPower Application Domain. Notes: The PolicyID
                    will help you make the name unique, because it is unique per
                    attachment point. It is a best practice to identify the type of action
                    in the name, to simplify debugging. It is also a best practice to
                    provide a hint of the assertion this action supports in the name
                    -->
          <xsl:variable name="actionName"
           select="concat($header/dppolicy:PolicyID,'-xform-',position(),'-Mediate')"/>

        
                    <!-- Create the action using the name created above
                    -->
          <xsl:element name="StylePolicyAction">
            <xsl:attribute name="name">
              <xsl:value-of select="$actionName"/>
            </xsl:attribute>
            <xsl:element name="Type">
              <xsl:text>xform</xsl:text>
            </xsl:element>
            <xsl:element name="PolicyKey">
              <xsl:value-of select="$policyKey"/>
            </xsl:element>


                    <!-- The input and output contexts usually require special
                    consideration because you may want the result of one assertion to
                    serve as the input of the next assertion, in which case the Input
                    should not be INPUT and the Output should not be OUTPUT. Instead use
                    the contexts specified in the notepad (which have already been placed
                    in the local variables shown.
                    -->
            <xsl:element name="Input">
              <xsl:value-of select="dpe:local-variable('input-context')"/>
            </xsl:element>
            <xsl:element name="Output">
              <xsl:value-of select="dpe:local-variable('output-context')"/>
            </xsl:element>
            <xsl:element name="Transform">
              <xsl:text>store:///identity.xsl</xsl:text>
            </xsl:element>
            <xsl:element name="OutputType"><xsl:text>default</xsl:text></xsl:element>
          </xsl:element>

      </dppolicy:config>
    </xsl:variable>


                    <!-- Send the config to the console, or whatever portion of it will
                    fit (roughly 3k) --> <!-- Remove this message, or
                    change its priority once unit test is complete
                    -->
    <xsl:message dpe:priority="error">Exit template MediateMessage:
      <xsl:copy-of select="$config"/>
    </xsl:message>
    

                    <!-- Send the config to the temporary directory --> <!--
                    Remove this once unit test is complete
                    -->
    <xsl:variable name="filename" select="concat('YCPS-mediation-config', 
     $header/dppolicy:RequestObject, '-', $header/dppolicy:PolicyExecutionID, '-', 
     $header/dppolicy:PolicyID, '.xml')"/>
    <dpe:dump-nodes file="$filename" nodes="$config"/>    


                    <!-- Don't forget to send the config to output -->
    <xsl:copy-of select="$config"/>
  </xsl:template>

Sử dụng trình soạn thảo chính sách để tạo XML cho một xác nhận

Phần này cho thấy cách soạn ra một khuôn mẫu xác nhận chính sách bằng cách sử dụng WebGUI để tạo ra một quy tắc xử lý trong trình soạn thảo chính sách xử lý của Web Service Proxy (WSP - Ủy quyền của Dịch vụ Web) và xuất khẩu nó.

Hãy làm theo các bước sau để tạo ra khuôn mẫu xác nhận:

  1. Tạo một WSP với WSDL của bạn, sau đó chuyển đến ngăn Policy và tạo ra một quy tắc xử lý để thực thi hành vi đã quy định với xác nhận của bạn (xem Hình 2). Bạn sẽ xuất khẩu quy tắc này sau đó (do đó, hãy ghi lại tên của quy tắc). Một khi bạn đã cấu hình quy tắc này và đã thử nghiệm hành vi của nó, bạn đã chuẩn bị xong để tiến hành bước tiếp theo.
    Hình 2. Cấu hình quy tắc xử lý
    Cấu hình quy tắc xử lý
  2. Chuyển đến tiện ích Export Configuration (Xuất khẩu cấu hình) trên Bảng điều khiển như trong Hình 3.
    Hình 3. Xuất khẩu cấu hình
    Xuất khẩu cấu hình
  3. Tùy chọn "Export configuration and files..." (Xuất khẩu cấu hình và các tệp..." cho phép bạn xuất khẩu cấu hình là một tệp XML. Hãy chọn tùy chọn này và nhấn Next như trong Hình 4.
    Hình 4. Chọn "Xuất khẩu cấu hình và các tệp..." từ Trình hướng dẫn Xuất khẩu
    Chọn “Xuất khẩu cấu hình và các tệp” từ Trình hướng dẫn Xuất khẩu
  4. Chọn quy tắc xử lý để xuất khẩu (Các bước 1 và 2 trong Hình 5). Bảo đảm rằng bạn đang xuất khẩu tất cả các đối tượng cần có cho xác nhận của mình bằng cách chọn tùy chọn Include all objects (Bao gồm tất cả các đối tượng) (Bước 3). Chọn tùy chọn XML Config (Cấu hình XML) để cho xuất khẩu sẽ được tạo ra là một tệp XML (Bước 4). Cuối cùng, nhập tên cho tệp xuất khẩu (Bước 5) và nhấn Next (Bước 6). Ô cửa sổ tiếp theo cung cấp một liên kết để tải về tệp XML xuất khẩu.
    Hình 5. Các tùy chọn cần dùng khi xuất khẩu cấu hình quy tắc xử lý
    Các tùy chọn cần dùng khi xuất khẩu cấu hình quy tắc xử lý
  5. Một khi bạn đã tải về tệp này, bạn có thể sử dụng XML Firewall utility (tiện ích Tường lửa XML) được cung cấp trong phần Tải về của bài này để trích ra các quy tắc và các đối tượng cần thiết. Chúng tôi đã sử dụng lệnh sau cho bước này:
    curl -d @myAssertion.xcfg http://<your-appliance-hostname>:10200 |
     tidy -xml -i > myAssertion.xml
  6. Bạn có thể nhớ lại từ Bước 1 là quy tắc xử lý cho ví dụ này rất đơn giản (một hành động so khớp, một hành động chuyển đổi và một hành động tạo kết quả), nên kết quả của Bước 5 có chứa là hai hành động xử lý. Lưu ý rằng các hành động so khớp không được đưa vào việc xuất khẩu quy tắc vì chúng thực sự "thuộc về" chính sách xử lý. Hành động tạo kết quả ở cuối của quy tắc này phải được loại bỏ vì khung công tác chính sách tự động thêm vào một hành động tạo kết quả sau khi xác nhận cuối cùng được khung công tác cho từng chủ đề chính sách xử lý. Trong trường hợp của ví dụ này, chúng ta chỉ còn lại hành động được hiển thị trong Liệt kê 5.

    Trong trường hợp của ví dụ này, những thay đổi duy nhất mà bạn cần phải thực hiện cho hành động này trước khi sử dụng nó trong bản định kiểu ánh xạ chính sách của bạn là:

    1. Cung cấp một tên duy nhất cho các hành động trong xác nhận của bạn. Lưu ý rằng có thể sử dụng nhiều lần một chuỗi hành động giống nhau, nên các tên hành động không thể là các chuỗi ký tự cố định.
    2. Cập nhật các phần tử <Input><Output> để sử dụng các tên của bối cảnh đầu vào và đầu ra do khung công tác ánh xạ chính sách cung cấp.
    3. Thêm một phần tử <PolicyKey> để mở bộ sưu tập các số đo thực thi trung gian hòa giải. Có một ví dụ về một trong các thay đổi như vậy trong xác nhận MediateMessage được cung cấp trong tệp chính sách tùy chỉnh yourco.com-example.xsl trong phần Tải về của bài này.
    Liệt kê 5. Tạo cấu hình cho xác nhận MediateMessage
     <StylePolicyAction name="myService_rule_0_xform_0" ... >
      <mAdminState>enabled</mAdminState>
     <Type>xform</Type>
         <Input>INPUT</Input>
     <Transform>store:///myRequestTransform.xsl</Transform>
         <Output>PIPE</Output>
     <NamedInOutLocationType>default</NamedInOutLocationType>
     <OutputType>default</OutputType>
     <Transactional>off</Transactional>
     <SOAPValidation>body</SOAPValidation>
     <SQLSourceType>static</SQLSourceType>
     <Asynchronous>off</Asynchronous>
     <ResultsMode>first-available</ResultsMode>
     <RetryCount>0</RetryCount>
     <RetryInterval>1000</RetryInterval>
      <MultipleOutputs>off</MultipleOutputs>
      <IteratorType>XPATH</IteratorType>
      <Timeout>0</Timeout>
      <MethodRewriteType>GET</MethodRewriteType>
      <MethodType>POST</MethodType>
      <MethodType2>POST</MethodType2>
     </StylePolicyAction>
  7. Một khi bạn đã soạn xong các xác nhận cho lĩnh vực chính sách tùy chỉnh của mình, bạn có thể đăng nhập vào thiết bị DataPower vào lĩnh vực mặc định và gửi bản định kiểu ánh xạ chính sách vào store://policies/custom. Để xác minh xem bản định kiểu này đã được phân tích cú pháp đúng chưa, bạn có thể kiểm tra các lĩnh vực được hỗ trợ trong đối tượng trạng thái giao diện người dùng như được hiển thị trong Hình 6.
    Hình 6. Xác nhận hợp lệ rằng thiết bị có thể nạp bản định kiểu ánh xạ chính sách
    Xác nhận hợp lệ rằng thiết bị có thể nạp bản định kiểu ánh xạ chính sách

Bây giờ bạn đã sẵn sàng để đính kèm chính sách vào các chủ đề chính sách trong WSDL của mình và kiểm tra các khả năng dưới dạng một xác nhận chính sách, thay vì một quy tắc xử lý cấu hình thủ công.


Xử lý sự cố

Do những hạn chế vốn có trong việc xác nhận hợp lệ lược đồ XML, có thể khó tạo ra cấu hình DataPower phức tạp mà không vi phạm một chính sách. Các đối tượng cấu hình DataPower có thể trở nên khá phức tạp. Ngoài ra, có lẽ không rõ ràng ngay là cấu hình mà bạn tạo ra đã bị loại bỏ và không được ghi vào thiết bị. Để giúp xử lý sự cố về các vi phạm lược đồ, việc xuất khẩu lĩnh vực được cung cấp trong bài này gồm có một tiện ích để xác nhận hợp lệ cấu hình do các bản định kiểu ánh xạ chính sách tạo ra. Để sử dụng tiện ích này, hãy lấy bản cấu hình đã được viết bằng cách dùng chức năng mở rộng các nút-kết xuất (xem Liệt kê 4) và chạy lệnh sau:

curl --data-binary @YOUR.XML http://<your-appliance-hostname>:10300/service/mgmt/3.0

Nếu XML vượt qua xác nhận hợp lệ lược đồ, thì tiện ích sẽ trả về XML đó. Nếu nó có lỗi, thì tiện ích sẽ trả về một thông báo lỗi. Sự vi phạm lược đồ sẽ được ghi vào bản ghi nhật ký hệ thống của DataPower như trong Hình 7.

Hình 7. Lỗi xác nhận hợp lệ lược đồ được hiển thị trong bản ghi nhật ký hệ thống của DataPower
Lỗi xác nhận hợp lệ lược đồ được hiển thị trong bản ghi nhật ký hệ thống của DataPower

Thêm một tiện ích (widget) tùy chỉnh vào Vùng Nghiệp vụ

WSRR hỗ trợ nạp bất kỳ chính sách nào có hỗ trợ tiêu chuẩn WS-Policy. Sau khi đã nạp vào WSRR, bạn có thể đính kèm chính sách đó vào bất kỳ đối tượng nào trong WSRR bằng cách sử dụng giao diện người dùng Vùng Nghiệp vụ (Business Space) của WSRR V8.

Việc soạn ra và quản lý các chính sách tùy chỉnh có thể được cung cấp trong Vùng Nghiệp vụ của WSRR V8 bằng cách phát triển các tiện ích tùy chỉnh của Vùng Nghiệp vụ. Bạn có thể phát triển các tiện ích để thực hiện một trình soạn thảo chính sách nhằm tạo, lấy ra và cập nhật các chính sách trong WSRR.

Các tiện ích tùy chỉnh như vậy có thể được tích hợp một phần với các tiện ích WSRR hiện có bằng cách nối các tiện ích tùy chỉnh để bắt giữ lại các sự kiện do các tiện ích WSRR tạo ra.

Một ví dụ của tiện ích như vậy được cung cấp trong tệp YourCoExampleWidget.zip, có trong phần Tải về của bài này. Các chức năng đưa đưa vào tiện ích này là:

  • Tạo mới hoặc chỉnh sửa Các tài liệu chính sách (Policy Documents) hiện có trong miền http://yourco.com/policy/standard/2012-08.
  • Hỗ trợ tất cả các xác nhận do miền trong ví dụ này định nghĩa.
  • Nối các sự kiện được chọn với mục đến.
  • Nối các sự kiện được tạo ra và cập nhật với mục đi.

Có thể bạn sẽ muốn luyện tập để giải quyết những hạn chế sau đây:

  • Không có khả năng xóa hoặc chuyển tiếp Các tài liệu chính sách.
  • Bạn không thể chỉnh sửa một Chính sách bằng cách nhấn chuột vào Chính sách đó, chỉ sửa được Tài liệu chính sách (Policy Document).
  • Tên Tài liệu chính sách và tên Chính sách sẽ được tự động tạo ra với các UUID. Không sử dụng bất kỳ phần nào của tên đầu vào của người dùng để tạo các mã định danh duy nhất.
  • Không áp dụng CSS hoặc định dạng HTML nào cho tiện ích.
  • Không có việc xử lý lỗi nào.

Xem các ghi chú "TODO" (Cần làm) trong tệp PolicyEditor.js để biết được tất cả những thứ cần tuỳ chỉnh.

Để cài đặt tiện ích này để sử dụng trong Vùng Nghiệp vụ, hãy thực hiện các hành động sau:

  1. Trong một Eclipse hoặc Rational® Software Architect hay Rational Application Developer, hãy sử dụng tùy chọn Import > existing projects into workspace (Nhập khẩu > các dự án hiên có vào vùng làm việc) và chọn tệp YourCoExampleWidgetProjects.zip.
  2. Nhấn chuột phải vào dự án YourCoPolicyEditorEAR và chọn Export > EAR file (Tệp EAR) và nhập YourCoExamplePolicyEditor.ear làm tên tệp.
  3. Tạo một tệp zip có tên là YourCoExampleWidget.zip có cấu trúc như sau:
    catalog/catalog_YourCoPolicyEditorWidget.xml
    ear/YourCoExamplePolicyEditor.ear
    endpoints/
    help/
    spaces/
    templates/

    Lưu ý:

    • Có tệp "catalog_YourCoPolicyEditorWidget.xml" trong dự án YourCoPolicyEditorWidget trong thư mục WebContent/WEB-INF.
    • Nếu bạn muốn bỏ qua việc tạo tệp ZIP này, thì trong bài này có cung cấp cho bạn một tệp ZIP có tên là YourCoExampleWidget.zip.
  4. Trên máy chủ WSRR V8 của bạn, hãy chạy công cụ dòng lệnh wsadmin và nhập vào các lệnh sau:
    a. $AdminTask installBusinessSpaceWidgets { -serverName 	
        <server name> -nodeName <node name> -widgets 
        <full	path to YourCoExampleWidget.zip> }
    
    b. $AdminConfig save
    
    c. exit
  5. Đăng nhập vào Giao diện người dùng Vùng Nghiệp vụ của WSRR (WSRR Buiness Space UI). Bây giờ bạn thấy một tiện ích mới gọi là "YourCoPolicyEditorWidget" có thể được thêm vào một vùng như trong Hình 8.
    Hình 8. Thêm tiện ích ví dụ vào một trang Vùng Nghiệp vụ
    Thêm tiện ích ví dụ vào một trang Vùng Nghiệp vụ
  6. Sau khi đã thêm vào, tiện ích này trông giống như Hình 9.
    Hình 9. Khung nhìn ban đầu của tiện ích ví dụ
    Khung nhìn ban đầu của tiện ích ví dụ
  7. Nếu bạn nhấn vào New Policy (Chính sách mới), thì một hộp thoại bật lên (Hình 10) sẽ xuất hiện để cho phép bạn đặt tên của chính sách đó và các giá trị của các phần tử lĩnh vực chính sách ví dụ.
    Hình 10. Tạo ra một chính sách mới bằng tiện ích ví dụ
    Tạo ra một chính sách mới bằng tiện ích ví dụ
  8. Nếu sau đó bạn nhấn vào Create (Tạo), bạn sẽ thấy một khung nhìn chính sách chỉ đọc như trong Hình 11.
    Hình 11. Xem một chính sách mới được tạo ra bằng tiện ích ví dụ
    Xem một chính sách mới được tạo ra bằng tiện ích ví dụ
  9. Bạn có thể nối tiện ích này tới bất kỳ các tiện ích Vùng Nghiệp vụ nào do WSRR cung cấp bằng cách chỉnh sửa việc nối tiện ích này. Ví dụ, nếu bạn nối nó tới Service Registry Collection Widget (Tiện ích của bộ sưu tập Đăng ký dịch vụ) như trong Hình 12, thì tiện ích ví dụ hiển thị các chi tiết của Tài liệu chính sách được chọn trong tiện ích của bộ sưu tập và cho phép bạn chỉnh sửa nó bằng cách nhấn vào Edit Policy (Chỉnh sửa chính sách). Điều này có thể đạt được bằng cách chọn Edit Page (Chỉnh sửa trang), nhấn vào trình đơn thả xuống ở góc trên cùng bên phải của tiện ích ví dụ, rồi chọn Edit Wiring (Chỉnh sửa đấu nối).
    Hình 12. Nối tiện ích ví dụ tới các tiện ích Vùng Nghiệp vụ khác
    Nối tiện ích ví dụ tới các tiện ích Vùng Nghiệp vụ khác

Để biết thông tin chi tiết về phát triển các tiện ích Vùng Nghiệp vụ, hãy xem Phát triển các tiện ích.


Kết luận

Việc sử dụng các lĩnh vực chính sách dùng ngay được như WS-SecurityPolicy và WS-MediationPolicy, cho phép chọn dùng nhanh chóng giải pháp dựa trên chính sách để thực thi các yêu cầu không chức năng của dịch vụ nghiệp vụ phổ biến - chẳng hạn như bảo mật thông báo và quản lý lưu lượng - mà không đòi hỏi các kỹ năng DataPower. Tuy nhiên, để tận dụng được hết những lợi ích của khung công tác chính sách SLA của DataPower, bạn có thể mở rộng phạm vi các lĩnh vực chính sách mà thiết bị đã hiểu rõ vượt ra ngoài những khả năng do các lĩnh vực dựng sẵn cung cấp. Việc sử dụng các lĩnh vực chính sách tùy chỉnh mang lại nhiều lợi ích về triển khai dựa vào chính sách so với triển khai vòng đời cấu hình truyền thống (chẳng hạn như tính nhanh nhẹn nghiệp vụ tăng lên cùng với tính ổn định vận hành được cải thiện) cho các mẫu xử lý do khách hàng định nghĩa.

Tính năng mở rộng then chốt này làm cho có thể đạt được một tập các mẫu xử lý phong phú bằng cách sử dụng các xác nhận chính sách tùy chỉnh (và các tham số xác nhận có liên quan của chúng). Thuận tiện hơn, bất cứ thứ gì có thể phát triển thành một quy tắc xử lý đều có thể thực thi được qua khung công tác chính sách bằng cách sử dụng các xác nhận của lĩnh vực chính sách tùy chỉnh.

Tính linh hoạt này đi cùng với quyền lực lớn, nên điều quan trọng là phải hiểu rằng các xác nhận chính sách cung cấp một cơ hội cho DataPower để đáp ứng với các thay đổi nghiệp vụ phổ biến trong khi giảm thiểu những tác động vận hành của sự thay đổi đó tới các dịch vụ khác. Nói cách khác, một ý niệm về chính sách tùy chỉnh then chốt là tìm ra sự cân bằng hợp lý giữa "truy cập để thay đổi" và "tính ổn định và sự kiểm soát". Nhờ thay đổi phạm vi và chiều sâu của khả năng thay đổi của mỗi xác nhận, mỗi kiến trúc sư có thể kiểm soát xem việc áp dụng những xác nhận đó có thể ảnh hưởng như thế nào đến một luồng công việc của ủy quyền (proxy) dịch vụ và ma trận kiểm tra chính sách. Chúng tôi đề xuất rằng như là một quy tắc chung (như đã chỉ ra trong các ví dụ của bài này), hãy luôn làm cho cú pháp các xác nhận càng ở mức cao càng tốt (ví dụ, gần với ý định của các yêu cầu nghiệp vụ ban đầu) mà không ảnh hưởng đến tính linh hoạt với các thay đổi nghiệp vụ thông thường.

Cuối cùng, chúng tôi hy vọng rằng những khả năng mới được trình bày trong loạt bài này đã cung cấp một nền tảng tốt để xem xét nghiêm chỉnh việc chọn dùng phương pháp tiếp cận dựa trên chính sách để quản trị SOA tốt hơn và cung cấp các luồng công việc dịch vụ trong các ủy quyền của DataPower. Đây chỉ là một ví dụ về tương lai của việc quản lý chính sách SOA được dự kiến sẽ phát triển ra sao theo thời gian - và qua đó cải thiện khả năng tiêu dùng và khả năng mở rộng quy mô của các thiết bị SOA trong doanh nghiệp của bạn để cung cấp các thay đổi nghiệp vụ phổ biến nhanh hơn.


Tải về

Mô tảTênKích thước
Code samplecustom_policy_domains_downloads.zip525KB

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=929798
ArticleTitle=Quản trị SOA bằng cách sử dụng WebSphere DataPower và WebSphere Service Registry and Repository, Phần 2: Tạo và thực thi bảng từ vựng chính sách tùy chỉnh
publish-date=05152013