Các tổ chức sử dụng chính sách để hướng dẫn các quyết định quan trọng cho cả hoạt động kinh doanh lẫn Công nghệ thông tin (CNTT). Nhiều khi, chính sách tác động trở lại và tạo ra hậu quả tiêu cực. Kiến trúc tham khảo chính sách SOA (SOA Policy Reference Architecture) cho thấy người thi hành có thể chủ động trong việc tạo ra và duy trì chính sách như thế nào, bao gồm khả năng để quản lý và tự động hóa chính sách đó. Bài này và phần đính kèm chi tiết hơn của nó cung cấp một framework để định nghĩa chính sách bắt đầu với các mục tiêu và hoạt động kinh doanh cụ thể và sau đó phân tích chúng thành các chính sách kinh doanh, các chính sách kiến trúc và các chính sách vận hành cần thiết để kiểm soát tốt tổ chức. Bài này sẽ đưa ra một ví dụ về sử dụng Kiến trúc tham khảo chính sách SOA để tạo ra sự phân tích chính sách nhằm hỗ trợ người đọc trong việc tìm hiểu các chi tiết.

Robert Laird, Kiến trúc sư điều hành, IBM

Ảnh của Robert LairdBob là một kiến trúc sư điều hành của IBM trong nhóm SOA Advanced Technology (Công nghệ tiên tiến SOA), thực hiện tư vấn toàn cầu cho các khách hàng của IBM trong lĩnh vực quản trị SOA và kiến trúc SOA từ 05.2006. Ông là đồng tác giả của SGMM (Phương pháp quản trị & quản lý SOA) của IBM. Ông là thành viên của nhóm làm việc về quản trị SOA của TOGAF (Khung công tác Kiến trúc của Open Group) của ngành CNTT và ông đã viết hai cuốn sách về SOA: 'SOA Governance, Achieving and Sustaining Business and IT Agility' và 'Executing SOA, A Practical Guide for the Service Oriented Architec'. Ông có hai bằng sáng chế đang chờ phê duyệt trong lĩnh vực quản trị SOA. Bob có hơn 20 năm kinh nghiệm trong ngành công nghiệp viễn thông ở MCI và Verizon Business. Ông đã là kiến trúc sư trưởng của MCI, lãnh đạo nhóm kiến trúc doanh nghiệp và làm việc qua toàn bộ trình tự trả tiền thanh toán bộ các ứng dụng. Ông dẫn dắt việc phát triển chiến lược chồng công nghệ duy nhất dựa trên SOA để đơn giản hóa nhiều thùng chứa các ứng dụng và mạng. Bob đã định hướng chiến lược, lập kế hoạch và thi hành việc phát triển sản phẩm của MCI trong lĩnh vực về các trung tâm liên lạc, các dịch vụ IP/VPN, VOIP, IMS và dịch vụ có quản lý. Về "OSS", ông đã lãnh đạo triển khai thực hiện thành công để tự động hóa việc cung cấp mạng, phục hồi mạng và quản trị mạng. Trước khi gia nhập MCI, Bob đã là một nhà tư vấn cho American Management Systems (AMS) and Ideation, Inc. Ông có bằng Thạc sĩ khoa học (MS) và Cử nhân khoa học (BS) về Khoa học máy tính của trường Đại học Purdue và đã được cấp hai bằng sáng chế trong lĩnh vực điện thoại. Ông đã phát biểu tại nhiều diễn đàn ngành nghề khác nhau, đã viết cho Tạp chí SOA và được trích dẫn trong CIO Insight, Telecommunications, Infoworld and Computerworld.



John Falkl, Kỹ sư Xuất xắc và Kiến trúc sư trưởng, Quản trị SOA, IBM

Ảnh của John FalklJohn Falkl là một Kỹ sư Xuất sắc của IBM và Kiến trúc sư trưởng về quản trị SOA trong Tập đoàn phần mềm IBM. Ông có trách nhiệm dẫn dắt chiến lược kỹ thuật tổng thể và các yêu cầu sản phẩm với chức năng quản trị SOA, cũng như phối hợp các hoạt động quản trị SOA giữa các tổ chức của IBM. John đã lãnh đạo Governance Incubation Project (Dự án ươm mầm về quản trị) để tìm CTO cho Tập đoàn phần mềm IBM. Với dự án này, John đã đưa đến việc thiết lập các quy trình quản trị SOA then chốt và đi theo cùng chiến lược sản phẩm phần mềm dựa vào các trường hợp sử dụng chuẩn. Trong 28 năm làm việc với IBM, John đã có 12 năm làm việc tại IBM Global Services, nơi ông lãnh đạo một số dự án có tác động lớn, gần đây nhất là việc định nghĩa và phát triển một sản phẩm dịch vụ Quản lý SOA cho tổ chức Global Business Services của IBM. John có 3 chứng chỉ toàn ngành trong lĩnh vực CNTT và có một nền tảng chắc chắn về kiến trúc và phát triển doanh nghiệp (với 9 năm về quản lý). John cũng đã hướng dẫn nhiều nghiên cứu công nghệ trình độ cao tại IBM.



Stephen Cocks, Kỹ sư phần mềm cao cấp, IBM

Ảnh của Stephen CocksStephen Cocks là một kỹ sư phần mềm cao cấp tại phòng thí nghiệm phát triển của IBM ở Hursley, Vương quốc Anh, nơi ông hiện đang chịu trách nhiệm làm việc với các nhóm sản phẩm để định nghĩa, kiến trúc và phân phối các khả năng dựa trên chính sách SOA. Kể từ khi gia nhập IBM vào năm 1989, Stephen đã làm việc trong nhiều vai trò khác nhau trên nhiều sản phẩm WebSphere chủ yếu của IBM bao gồm IBM Business Process Manager, IBM WebSphere Enterprise Service Bus và IBM WebSphere Application Server.



Arnaud Le Hors, Kiến trúc sư các tiêu chuẩn phần mềm, Lãnh đạo các tiêu chuẩn dữ liệu có liên kết, IBM

Ảnh của Arnaud Le HorsArnaud Le Hors, một thành viên của nhóm các tiêu chuẩn phần mềm của IBM, chịu trách nhiệm hướng dẫn phối hợp một số hoạt động về các tiêu chuẩn của IBM theo một quan điểm chiến lược và kỹ thuật. Arnaud đã làm về các tiêu chuẩn mở suốt 15 năm, vừa là nhân viên của Hiệp hội X và W3C và vừa là một người đại diện cho IBM. Ông đã tham gia vào mọi khía cạnh của quá trình phát triển các tiêu chuẩn, bao gồm cả kỹ thuật, chiến lược, chính trị và pháp lý, cả bên trong lẫn bên ngoài cho một SDO và cho một công ty như IBM. Arnaud đã tham gia vào việc phát triển các tiêu chuẩn như HTML và XML và là một trong những kiến trúc sư hàng đầu về Xerces, trình phân tích cú pháp XML được Apache Software Foundation (Quỹ phần mềm Apache) phát triển. Hiện nay Arnaud là Lãnh đạo các tiêu chuẩn dữ liệu có liên kết của IBM.



Duncan Clark, Kiến trúc sư CNTT, IBM

Ảnh của Duncan ClarkDuncan Clark là một kiến trúc sư hiện đang quản lý các yêu cầu để tích hợp sản phẩm Operational Decision Management (Quản lý Quyết định vận hành) của IBM với các sản phẩm và giải pháp khác của IBM. Ông làm việc tại phòng thí nghiệm Hursley của IBM và trong năm qua ông đảm nhiệm trình bày và tích hợp các sản phẩm ODM, BPM và Tivoli của IBM. Ông đã quản lý việc tích hợp Các quy tắc nhúng ILOG vào BPM 7.5 và việc phát triển gói hỗ trợ LA71 để cung cấp các công cụ tích hợp và các mẫu phát triển để sử dụng ODM với BPM (Business Process Manager - Trình quản lý qui trình nghiệp vụ). Trước đó, Duncan là một kiến trúc sư làm việc trong nhóm WSRR (WebSphere Service Registry and Repository) chịu trách nhiệm về các khía cạnh quản trị SOA và Quản lý chính sách của WSRR.



Andy Ritchie, Kỹ sư và Kiến trúc sư phần mềm cao cấp, IBM

Andy Ritchie là một kỹ sư và kiến trúc sư phần mềm cao cấp của IBM, ông quan tâm đến BPM và lĩnh vực Quản lý ra quyết định. Ông chủ yếu tập trung vào các giải pháp nối chung nhiều sản phẩm của IBM và thường xuyên làm việc với các nhóm bán hàng dịch vụ và kỹ thuật của IBM về các giải pháp và phương pháp luận của khách hàng. Với hơn 27 năm làm việc tại IBM, ông đã có kinh nghiệm rất rộng và phong phú. Các chính sách và các quy tắc nghiệp vụ là một phần vai trò cốt lõi của ông trong Quản lý ra Quyết định khi làm về các giải pháp Ngân hàng, Bán lẻ, Viễn thông cho các quyết định và các quy tắc về Đủ điều kiện, Tuân thủ và Định giá. Ông cũng đã kiến trúc các giải pháp Phần mềm trung gian SOA của IBM trong nhiều ngành nghề nên ông cũng có vai trò then chốt trong SOA Service Governance with Policies (Quản trị dịch vụ SOA với Các chính sách). Trước đây, ông đã dành 18 năm làm việc trong bộ phận Phát triển của IBM chuyên về các sản phẩm xử lý Giọng nói và truyền dẫn ISDN, X.25.



18 04 2013

Cách sử dụng tài liệu này

Tài liệu này là một hướng dẫn ngắn gọn để tìm hiểu và sử dụng Kiến trúc tham khảo chính sách SOA. Để có được sự hiểu biết chi tiết hơn về chủ đề này, bao gồm cả ví dụ hoàn chỉnh, hãy truy cập toàn bộ tài liệu từ phần Tài liệu tham khảo.

Hãy xem xét hình dưới đây để hiểu vai trò chính sách tiêu biểu của những người sẽ tạo ra, soạn thảo, quản trị, quản lý và thi hành các Chính sách SOA:

Hình 1. Các vai trò để sử dụng Kiến trúc tham khảo chính sách SOA
các vai trò cho chính sách soa

Mô tả Kiến trúc tham khảo chính sách SOA

Kiến trúc tham khảo chính sách SOA dựa trên việc quản lý các dịch vụ bằng cách sử dụng chính sách như thể hiện trong hình dưới đây.

Hình 2. Kiến trúc tham khảo chính sách SOA
Chính sách Kinh doanh, Chính sách Kiến trúc, Chính sách Vận hành

Kiến trúc tham khảo chính sách SOA sắp xếp đại diện chính sách của nó thành các tầng để hỗ trợ các vai trò và các nhân vật SOA hiện có.

  • Tầng kinh doanh (Business Layer) nên được dẫn dắt bởi một nhà phân tích kinh doanh hay một đại diện từ doanh nghiệp, người có thể thấy rõ nhu cầu của doanh nghiệp.
  • Tầng Kiến trúc (Architecture Layer) nên được dẫn dắt bởi các kiến trúc sư, những người chịu trách nhiệm về tính toàn vẹn của SOA.
  • Tầng Vận hành (Operational Layer) phản ánh đặc tả của chính sách runtime để thực hiện các mẫu chính sách vận hành.

Tầng Chính sách kinh doanh (Business Policy Layer)

Ở mức trừu tượng cao nhất, một chính sách chỉ đơn giản là một tuyên bố về nhu cầu kinh doanh cụ thể. Ở mức này, chính sách này thường được thể hiện bằng ngôn ngữ tự nhiên (ví dụ, tiếng Anh, tiếng Pháp và v.v) và được sử dụng để truyền thông các yêu cầu kinh doanh giữa các nhà phân tích kinh doanh và các chuyên gia CNTT. Khi hai bên bắt đầu cộng tác, chính sách kinh doanh này sau đó được phân tách ra thành một tập hợp các hành động cụ thể, các chiến lược và các chiến thuật để định nghĩa các chi tiết về cách sẽ thực hiện và thi hành các yêu cầu kinh doanh trong toàn tổ chức như thế nào.

Những chính sách kinh doanh đó cần được định nghĩa trong bối cảnh của giải pháp kinh doanh có áp dụng các chính sách đó. Các dịch vụ sẽ thường có khả năng truy tìm nguồn gốc tới các khả năng kinh doanh do chúng cung cấp, sao cho có thể nhanh chóng gắn một chính sách kinh doanh với các dịch vụ mà chính sách đó sẽ cần tác động đến.

Một khi những yêu cầu kinh doanh đã được phân tách thành các chính sách để có thể áp dụng cho các tập hợp dịch vụ, thì tầng Chính sách kiến trúc (Architectural Policy) được sử dụng để định nghĩa các mẫu phổ biến có thể được dùng để thực thi các chính sách đó.

Tầng Chính sách kiến trúc (Architecture Policy Layer)

Tầng chính sách kiến trúc cung cấp các mẫu để tích hợp chính sách vào kiến trúc được doanh nghiệp chọn dùng. Các chính sách có thể áp dụng theo cách hoạt động của một dịch vụ (ví dụ như việc kiểm soát một dịch vụ định giá thông qua các chính sách đã quy định trong các quy tắc kinh doanh) hoặc chúng có thể được áp dụng vào việc sử dụng dịch vụ của người khác.

Tầng Chính sách vận hành (Operational Policy Layer)

Tầng Chính sách vận hành cung cấp các sản phẩm và cơ sở hạ tầng phần mềm đã triển khai để thực hiện các giải pháp kinh doanh và sử dụng chính sách trong những giải pháp đó. Kiến trúc tham khảo Chính sách SOA định nghĩa một số thành phần đặc trưng cho cách thực hiện chính sách trong các giải pháp SOA vận hành.

Ví dụ về Giải pháp chính sách

Hình dưới đây cho thấy một ví dụ rất đơn giản đối với một yêu cầu Quản lý mức dịch vụ.

Hình 3. Ví dụ Cây chính sách phân tích từ trên xuống dưới của Chính sách SLA (Thỏa thuận mức dịch vụ)
Chính sách Kinh doanh, Chính sách Kiến trúc, Chính sách Vận hành

Giải pháp của Tầng Chính sách kinh doanh

Việc phân tích cây chính sách bắt đầu bằng một bản kê đơn giản, ở mức cao, về yêu cầu của chính sách kinh doanh, chẳng hạn như một bản kê có thể nhận được từ người dùng của doanh nghiệp hoặc nhà phân tích kinh doanh. Bản kê này sau đó được tinh chỉnh, vẫn còn ở mức kinh doanh, để chỉ rõ những hàm ý chi tiết hơn về yêu cầu chính sách kinh doanh, cũng như những gì cần phải đo lường để bảo đảm việc tuân thủ chính sách.

Việc định nghĩa một ý định hay một mục tiêu kinh doanh ở mức cao tương đối dễ dàng dựa trên các cuộc nói chuyện với những người dùng doanh nghiệp. Các ví dụ có thể bao gồm "Thời gian đáp ứng phải thỏa mãn các nhu cầu của khách hàng", "Chỉ bán các hợp đồng bảo hiểm khi khách hàng có mức rủi ro tín dụng thích hợp" hoặc "Giám đốc tài chính phải phê chuẩn giao dịch chi phí cao".

Tuy nhiên, sau đó bắt đầu các câu hỏi chi tiết hơn. Các nhà phân tích có hiểu biết có thể bắt đầu đặt các câu hỏi như sau:

  1. Một số khách hàng có các yêu cầu thời gian đáp ứng khác so với những người khác không?
  2. Thời gian đáp ứng thích hợp là gì?
  3. Bối cảnh giải pháp sẽ áp dụng chính sách này là gì?
  4. Làm thế nào để đo lường mức rủi ro tín dụng thích hợp?
  5. Có hay không các kiểu các hợp đồng bảo hiểm khác nhau với các mức rủi ro khác nhau?
  6. Một giao dịch chi phí cao là gì?
  7. Các mức rủi ro có ảnh hưởng đến những gì là chi phí cao hay không?

Chúng tôi phân tách các kết quả như được thể hiện trong hình sau đây:

Hình 4. Ví dụ về phân tách chính sách ở tầng kinh doanh
Tầng Chính sách Kinh doanh

Hãy mô tả và phân tách chính sách cho tầng kinh doanh:

Bảng 1. Phân tách chính sách từ các mục đích kinh doanh
TênMô tảVí dụ
Nhận biết Mục tiêu kinh doanhMột Mục tiêu kinh doanh là một tuyên bố về ý định và định nghĩa những gì cần phải thực hiện theo một quan điểm kinh doanh.Những mong đợi của khách hàng về thời gian đáp ứng cần được thỏa mãn.
Rút ra Hướng dẫn chính sáchHướng dẫn chính sách định nghĩa ý định của Mục đích kinh doanh và do đó đưa ra các hướng dẫn về mục đích kinh doanh cần được tiếp tục phân tách như thế nào. Nó được tinh chỉnh thêm trong giai đoạn Bối cảnh giải pháp, Các miền chính sách, Các chính sách giải pháp và Các chính sách quản trị. Thời gian đáp ứng từ đầu đến cuối (từ lúc nhấn phím Enter đến khi nhận được trả lời) cho các khách hàng cần thấp hơn 3 giây.
Định lượng Các hoạt động kinh doanh cụ thểCác mục tiêu kinh doanh định nghĩa những gì cần được đo lường chi tiết để theo dõi việc đạt được mục đích đó dưới dạng các KPI.KPI 1: Đo thời gian đáp ứng tối đa của các dịch vụ khách hàng và cung cấp một cảnh báo vận hành nghiêm trọng nếu thời gian này bị vượt quá.
Xác định phạm vi Bối cảnh giải phápBối cảnh giải pháp định nghĩa các hướng dẫn kinh doanh sẽ áp dụng trong doanh nghiệp. Phạm vi của nó có thể được khoanh vùng trong một khả năng kinh doanh nhỏ hoặc được triển khai rộng rãi hơn trên toàn bộ doanh nghiệp.Giai đoạn 1: Chỉ cho Các dịch vụ ATM ngân hàng.
Chọn (các) Miền chính sáchMỗi Miền nhận biết một bảng từ vựng chung cần được sử dụng để định nghĩa chính sách nhất quán. Các miền con của chính sách kinh doanh cần xem xét là:
  1. Các chính sách nhận biết tình huống chẳng hạn như việc phát hiện các mẫu của các sự kiện trong một khoảng thời gian cụ thể.
  2. Các chính sách qui trình nghiệp vụ có ảnh hưởng đến hành vi của qui trình tại các bước hoạt động cụ thể.
  3. Các chính sách đặc trưng cho ngành nghề có thể thực hiện các tiêu chuẩn ngành hay các quy định tuân thủ.
  4. Các chính sách quản lý mức dịch vụ.
Miền Chính sách quản lý mức dịch vụ được sử dụng.
Phân tách Các chính sách giải phápHướng dẫn chính sách cần được tiếp tục cải thiện khi chúng ta nhận được kiến thức chi tiết hơn về bối cảnh mà chúng ta đang đối phó.Tất cả Các dịch vụ ATM ngân hàng phải cung cấp một đáp ứng cho người tiêu dùng dịch vụ của mình dưới 3 giây.
Áp dụng Các chính sách quản trịHướng dẫn chính sách sẽ cần được quản trị sao cho có thể cung cấp sự thay đổi nhanh nhẹn trong tương lai. Điều này liên quan đến Vòng đời chính sách SOA có thể được thực hiện ở đâu. Việc tiếp thị sẽ có thẩm quyền để tạo, cập nhật hoặc hủy bỏ bất kỳ các chính sách kinh doanh nào được phân loại là tiếp thị.

Các kết quả đầu ra chính từ việc phân tách tầng kinh doanh sẽ được sử dụng ở tầng Kiến trúc, là:

  • Chính sách Giải pháp: Được phân tách từ Hướng dẫn chính sách và chịu ảnh hưởng của bối cảnh Giải pháp.
  • Các KPI của giải pháp: Được phân tách từ Hướng dẫn chính sách và các hoạt động kinh doanh cụ thể và chịu ảnh hưởng của bối cảnh Giải pháp.
  • Các miền chính sách: Quản lý mức dịch vụ được chọn trong ví dụ của chúng tôi với tiêu điểm là khách hàng.

Giải pháp của Tầng Chính sách kiến trúc

Một khi đã chỉ rõ một mức chính sách kinh doanh hợp lý, thì có thể phân tách nó thành các chính sách của tầng kiến trúc cần thiết để thực hiện các chính sách kinh doanh. Các chính sách kiến trúc làm rõ hơn chính sách kinh doanh đến mức cần thiết để bảo đảm một thiết kế có chất lượng cao cho giải pháp này và nhận biết mẫu chính sách nào, nếu cần thiết, nên được sử dụng để đáp ứng các yêu cầu kinh doanh.

Có ba khái niệm chính về tầng Kiến trúc cần được xem xét. Các khái niệm này được thể hiện trong hình và bảng dưới đây.

Hình 5. Ví dụ về phân tách chính sách ở tầng Kiến trúc
Tầng Chính sách Kiến trú

Tại thời điểm này trong vòng đời Chính sách SOA, chúng tôi đã giới thiệu một phương tiện để soạn và biến đổi các chính sách kinh doanh xuống thành các tập hợp chính sách vận hành có thể được gắn với mỗi lần thực hiện dịch vụ.

Bảng 2. Phân tách Tầng Kiến trúc
TênMô tảVí dụ
Phân tách Chính sách giải phápHoạt động này định nghĩa tầng kiến trúc được sử dụng như thế nào để phân tách các chính sách giải pháp do tầng kinh doanh cung cấp thành các chính sách có thể được áp dụng cho các tài nguyên SOA dùng cho giải pháp theo bối cảnh. Hoạt động này bao gồm việc nhận biết các tài nguyên bị ảnh hưởng (dịch vụ, thông tin hoặc qui trình).Tất cả các dịch vụ ngân hàng phải đáp ứng trong vòng 2 giây. Tất cả các dịch vụ thông tin phải đáp ứng trong vòng 1 giây.
Chọn Mẫu miềnCác mẫu miền, do cơ sở hạ tầng SOA hiện tại cung cấp, có thể được sử dụng để thực thi cách dùng một mẫu thực hiện cụ thể. Việc chọn các mẫu hiện đẩy nhanh thời gian tới giá trị và phát triển, bằng cách cho phép sử dụng lại các thành phần hiện có hơn là phải phát triển một giải pháp mới. Sử dụng một Mẫu SLA để theo dõi các độ trễ dịch vụ và định tuyến đến dịch vụ thích hợp để thực hiện mức dịch vụ cần thiết.
Các tập hợp Chính sách vận hànhCác tập hợp này là kết quả của việc chuyển đổi các chính sách giải pháp thành các tập hợp chính sách có thể được thực hiện bằng cách sử dụng việc triển khai thực hiện vận hành của mẫu miền. Việc này cung cấp vòng đời quản lý chính sách từ đầu đến cuối bằng cách sử dụng các khả năng và các sản phẩm đã triển khai thường dùng để quản lý các chính sách này. Các tập hợp chính sách dịch vụ cụ thể bao gồm việc định tuyến và giám sát các chính sách.

Giải pháp Tầng Chính sách vận hành

Sau cùng, ở tầng chính sách vận hành, các chính sách kinh doanh và chính sách kiến trúc có thể tiếp tục được phân tách thành tập hợp các chính sách vận hành có thể dùng được, cần thiết để thực thi và giám sát chính sách đó và bảo đảm nó sẽ đáp ứng các nhu cầu ban đầu của doanh nghiệp.

Tầng kiến trúc đã cung cấp phương tiện để ánh xạ các chính sách kinh doanh lên các chính sách chức năng được diễn giải bằng các qui trình và các dịch vụ, và lên các tập hợp chính sách không chức năng để điều khiển cách cấu hình các mẫu kiến trúc trong giải pháp vận hành. Kiến trúc tham khảo chính sách SOA nhận biết bốn lĩnh vực chính sách không chức năng quan trọng được thực hiện trong tầng vận hành. Các lĩnh vực chính sách vận hành này cung cấp các khối xây dựng không chức năng được sử dụng cho các mẫu kiến trúc được mô tả trong phần cuối.

Lấy ví dụ Cây Chính sách, có ba khái niệm chính trong tầng vận hành cần được xem xét. Các khái niệm này được hiển thị trong sơ đồ và bảng dưới đây và được mô tả chi tiết hơn trong phần tiếp theo.

Hình 6. Ví dụ về xây dựng chính sách của tầng vận hành
Tầng Chính sách Vận hành
Bảng 3. Phân tách Tầng vận hành
TênMô tảVí dụ
Đối chiếu các tập hợp chính sách qua các chính sách cho bất kỳ sự tương tác đã cho nàoCác tập hợp chính sách là kết quả của một Hướng dẫn chính sách cụ thể cần được sáp nhập với các chính sách khác đã được triển khai với bất kỳ các tương tác dịch vụ nào.Các chính sách SLA cho các tương tác dịch vụ ngân hàng sẽ cần được sáp nhập với các chính sách bảo mật hiện có để bảo vệ dữ liệu tài khoản của khách hàng.
Ánh xạ các tập hợp chính sách tới cấu hình PDP/PEP Các PDP và các PEP được sử dụng để diễn giải và thi hành các chính sách sẽ thường sử dụng tập hợp chính sách gắn với các thông tin động khác để bắt buộc thực hiện. Việc đưa vào các điều khoản mới trong các chính sách có thể yêu cầu rằng cấu hình của các PEP, các trung gian hoặc các đăng ký liên quan của chúng phải thay đổi để hỗ trợ các chính sách đã cập nhật.Trung gian SLA sử dụng số liệu thống kê độ trễ chính sách của nhà cung cấp để xác định các điểm đầu cuối có sẵn có thể cung cấp SLA cần thiết.
Ánh xạ các tập hợp chính sách giám sát tới các bảng điều khiển và các cảnh báo của KPICác tập hợp chính sách của tầng kiến trúc sẽ định nghĩa những gì cần được ghi lại từ mỗi tương tác. Tuy nhiên, sẽ vẫn cần cấu hình các phương tiện hiển thị các KPI chính sách trong bảng điều khiển và các phương tiện đáp ứng lại với tiêu chí và các cảnh báo ngoại lệ quan trọng.Cảnh báo nếu độ trễ là GT SLM Policy hoặc một việc sử dụng dịch vụ là GT 90%.

Kết luận

Chính sách SOA đưa ra các phương tiện để cung cấp khả năng nhanh nhẹn và khả năng đáp ứng kinh doanh trong các giải pháp SOA, nhưng đòi hỏi một cách tiếp cận có hệ thống để quản trị và quản lý các chính sách đó. Tài liệu này đã tóm tắt các hướng dẫn thực hành và vòng đời gợi ý nên chọn dùng để thực hiện các giải pháp có thể sử dụng các khối xây dựng và các mẫu chính sách SOA do các công nghệ chính sách khác nhau cung cấp.

Kiến trúc tham khảo chính sách SOA của IBM mô tả cách làm thế nào để soạn, triển khai, thực thi và giám sát các chính sách một cách có hệ thống như là một phần của giải pháp. Nó mô tả vòng đời của chính sách này tương tác như thế nào với các vòng đời Phát triển SOA đang được dùng để phát triển các dịch vụ, các qui trình và các ứng dụng của giải pháp. Cuối cùng nó mô tả cách chính sách SOA đi cùng và hỗ trợ toàn bộ các qui trình quản trị được tổ chức chọn dùng.

Tài liệu tham khảo

TênMô tả
SOA_Policy_Reference_Architecture_Full_Article.pdfTải về Kiến trúc tham khảo chính sách SOA đầy đủ

Tài nguyê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=871760
ArticleTitle=Chính sách SOA
publish-date=04182013