TIÊU CHUẨN QUỐC GIA TCVN 12482-1:2019 (ISO/IEC 18384-1:2016) VỀ CÔNG NGHỆ THÔNG TIN – KIẾN TRÚC THAM CHIẾU CHO KIẾN TRÚC HƯỚNG DỊCH VỤ – PHẦN 1: THUẬT NGỮ VÀ KHÁI NIỆM CHO KIẾN TRÚC HƯỚNG DỊCH VỤ

Hiệu lực: Còn hiệu lực

TIÊU CHUẨN QUỐC GIA

TCVN 12482-1:2019

ISO/IEC 18384-1:2016

CÔNG NGHỆ THÔNG TIN – KIẾN TRÚC THAM CHIẾU CHO KIẾN TRÚC HƯỚNG DỊCH VỤ – PHẦN 1: THUẬT NGỮ VÀ KHÁI NIỆM CHO KIẾN TRÚC HƯỚNG DỊCH VỤ

Information technology – Reference Architecture for Service Oriented Architecture (SOA RA) – Part 1: Terminology and concepts for SOA

Lời nói đầu

TCVN 12482-1:2019 hoàn toàn tương đương ISO/IEC 18384-1:2016.

TCVN 12482-1:2019 do Ban kỹ thuật tiêu chuẩn quốc gia TCVN/JTC 1 “Công nghệ thông tin” biên soạn, Tổng cục Tiêu chuẩn Đo lường Chất lượng đề nghị, Bộ Khoa học và Công nghệ công bố.

Hiện nay, Bộ TCVN 12482 (ISO/IEC 18384) về Công nghệ thông tin – Kiến trúc tham chiếu cho kiến trúc hướng dịch vụ gồm các tiêu chuẩn:

– TCVN 12482-1:2019 (ISO/IEC 18384-1:2016), Phần 1: Thuật ngữ và khái niệm cho kiến trúc hướng dịch vụ;

– TCVN 12482-2:2019 (ISO/IEC 18384-2:2016), Phần 2: Kiến trúc tham chiếu cho giải pháp kiến trúc hướng dịch vụ;

– TCVN 12482-3:2019 (ISO/IEC 18384-3:2016), Phần 3: Bản thể học kiến trúc hướng dịch vụ.

CÔNG NGHỆ THÔNG TIN – KIẾN TRÚC THAM CHIẾU CHO KIẾN TRÚC HƯỚNG DỊCH VỤ – PHẦN 1: THUẬT NGỮ VÀ KHÁI NIỆM CHO KIẾN TRÚC HƯỚNG DỊCH VỤ

Information technology – Reference Architecture for Service Oriented Architecture (SOA RA) – Part 1: Terminology and concepts for SOA

1 Phạm vi áp dụng

Tiêu chuẩn này thiết lập bộ từ vựng, hướng dẫn và nguyên tắc kỹ thuật chung là cơ sở cho kiến trúc hướng dịch vụ (SOA), bao gồm các nguyên tắc liên quan đến thiết kế, hiệu năng, phát triển, triển khai và quản lý chức năng.

2 Thuật ngữ và định nghĩa

Tiêu chuẩn này áp dụng các thuật ngữ và định nghĩa sau.

2.1

Tác nhân (actor).

Người hoặc thành phần hệ thống tương tác với hệ thống như một tổng thể và cung cấp các tác nhân kích thích để gọi các hành động.

[NGUỒN: 3.1, ISO/IEC 16500-8:1999]

2.2

Kiến trúc (architecture)

Khái niệm hoặc thuộc tính nền tảng của một hệ thống trong môi trường được bao gồm trong các phần tử, các quan hệ và theo các nguyên tắc thiết kế và tiến hóa.

[NGUỒN: 3.2, ISO/IEC/IEEE 42010:2011,]

2.3

Dàn dựng (choreography)

Kiểu tổ hợp (2.5) có các phần tử (2.8) tương tác theo kiểu không trực tiếp với mỗi phần tự trị đã biết và tuân theo một khuôn mẫu hành vi xác định có thể quan sát được đối với tổ hợp toàn thể (toàn cầu).

CHÚ THÍCH 1 Dàn dựng không đòi hỏi kiến thức hoàn chỉnh hoặc hoàn hảo về khuôn mẫu hành vi.

CHÚ THÍCH 2 Xem 8.3, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).

2.4

Cộng tác (collaboration)

Kiểu tổ hợp (2.5) có các phần tử (2.8) tương tác theo kiểu không trực tiếp, mỗi phần tử tuân theo từng kế hoạch và mục đích riêng mà không có một khuôn mẫu hành vi định trước.

CHÚ THÍCH 1 Xem 8 3, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).

2.5

Tổ hợp (composition)

Kết quả của việc thu thập một tập hợp các phần tử (2.8) cho mục đích nào đó.

CHÚ THÍCH 1 Xem 8.2, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).

2.6

Điểm cuối (endpoint)

Vị trí mà tại đó thông tin nhận được để gọi và thiết lập cấu hình tương tác.

2.7

Khả năng tác động (effect)

Kết quả của một tương tác với dịch vụ (2.20).

CHÚ THÍCH 1 Khả năng tác động là cách một dịch vụ phân phối các kết quả cho khách hàng, thông qua phần tử (2.8) thực hiện dịch vụ đó.

CHÚ THÍCH 2 Xem 7.10, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).

2.8

Phần tử (element)

Đơn vị ở mức trừu tượng đã cho và với ranh giới được xác định rõ ràng.

CHÚ THÍCH 1 Một phần tử có thể là bất kỳ kiểu thực thể (2.9) nào.

CHÚ THÍCH 2 Xem 5.1, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).

2.9

Thực thể (entity)

Phần tử (2.8) riêng trong một hệ thống có định danh và có thể hành động như một nhà cung cấp dịch vụ (2.50) hoặc khách hàng dịch vụ (2.29).

CHÚ THÍCH 1 Ví dụ về thực thể là các tổ chức, doanh nghiệp vá cá nhân, phần mềm và phần cứng.

2.10

Sự kiện (event)

Sự việc xảy ra mà một phần tử (2.8) có thể được chọn để đáp ứng.

CHÚ THÍCH 1 Bất kỳ phần tử nào có thể tạo ra (phát ra) hoặc đáp ứng với một sự kiện.

CHÚ THÍCH 2 Xem Điều 10, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).

2.11

Bối cảnh thi hành (execution context)

Tập các phần tử (2.8) kỹ thuật và nghiệp vụ cần thiết với các khả năng và nhu cầu để cho phép các nhà cung cấp dịch vụ (2.50) và khách hàng dịch vụ (2.29) thuyết minh và truyền thông.

CHÚ THÍCH 1 Bối cảnh thi hành một tương tác dịch vụ (2.37) là tập các phần tử hạ tầng, thực thể quá trình, việc xác nhận chính sách và cam kết được xác định là một phần của tương tác dịch vụ được tạo ra tức thời và do đó tạo thành một đường dẫn giữa các phần tử với nhu cầu và với khả năng.

CHÚ THÍCH 2 Xem Tài liệu tham khảo [8].

2.12

Tác nhân con người (human actor)

Tác nhân (2.1) được giới hạn cho thực thể (2.9) là cá nhân hoặc tổ chức.

CHÚ THÍCH 1 Phân loại này chưa đầy đủ mọi khía cạnh.

CHÚ THÍCH 2 Xem 6.2, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).

2.13

Tác vụ con người (human task)

Tác vụ (2.60) được thực thi bởi một tác nhân con người (2.12).

2.14

Giao diện (interface)

Ranh giới dùng chung giữa hai đơn vị chức năng, được xác định bởi các đặc tính kỹ thuật khác nhau liên quan đến các chức năng, liên kết nối vật lý, trao đổi tín hiệu và đặc tính kỹ thuật khác, khi thích hợp.

(NGUỒN: 21.21.308, ISO/IEC 2382:2015]

2.15

Nối kết lỏng (loose coupling)

Nguyên tắc mà trong đó các phụ thuộc giữa các phần tử (2.8) của một giải pháp SOA (2.56) được chủ định giảm.

2.16

Phối trí (orchestration)

Kiểu tổ hợp (2.5) mà một phần tử (2.8) cụ thể được sử dụng bởi tổ hợp để giám sát và chỉ đạo các phần tử khác.

CHÚ THÍCH 1 Phần tử chỉ đạo một phối trí không phải là một phần của chính phối trí đó (trường hợp tổ hợp).

CHÚ THÍCH 2 Xem 8.3, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).

2.17

Chính sách (policy)

Tuyên bố rằng một thực thể (2.9) có ý định tuân theo hoặc một thực thể khác nên tuân theo.

CHÚ THÍCH 1 Xem Điều 9, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).

2.18

Quá trình (process)

Kiểu tổ hợp (2.5) có các phần tử (2.8) gồm một trình tự hoặc luồng các hoạt động và tương tác với mục tiêu thực hiện công việc nhất định.

CHÚ THÍCH 1 Quá trình cũng có thể là một cộng tác (2.4), dàn dựng (2.3) hoặc phối trí (2.16).

CHÚ THÍCH 2 Xem 8.6, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).

2.19

Khả năng tác động môi trường thực (real-world effect)

Thay đổi liên quan và được trải nghiệm bởi các bên liên quan cụ thể.

CHÚ THÍCH 1 Xem Tài liệu tham khảo [8].

2.20

Dịch vụ (service)

Biểu diễn lô-gic của một tập các hoạt động có kết quả qui định, tự chứa, có thể bao gồm các dịch vụ khác và là một “hộp đen” đối với khách hàng dịch vụ.

CHÚ THÍCH 1 Từ “hoạt động” trong định nghĩa “dịch vụ” được sử dụng theo nghĩa chung của từ, không phải theo nghĩa quá trình cụ thể của từ [tức là hoạt động không nhất thiết phải là hoạt động quá trình (2.18)].

CHÚ THÍCH 2 Xem 7.2, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).

2.21

Bên môi giới dịch vụ (service broker)

Phần tử (2.8) cho phép liên lạc với các dịch vụ (2.20) ở mức nghiệp vụ hoặc ở mức thực thi, ví dụ: với các bên trung gian.

CHÚ THÍCH 1 Các bên trung gian cung cấp bất kỳ số lượng chức năng nào, chẳng hạn như đăng ký dịch vụ (2.51) thống nhất và công khai, phát hiện các dịch vụ (2.34), định tuyến, truy nhập dịch vụ vị trí rõ ràng cho các nhà cung cấp dịch vụ (2.50) và khách hàng dịch vụ (2.29).

2.22

Bus dịch vụ (service bus)

Khuôn mẫu thiết kế và thời gian chạy cho phép tương tác dịch vụ (2.20), như truyền thông, truy nhập, tiêu thụ, chuyển đổi, làm trung gian và định tuyến thông điệp.

CHÚ THÍCH 1 Một bus dịch vụ có thể gồm từ một tập hợp lô-gic các chức năng đến các chức năng được thu thập thành một sản phẩm thương mại đơn nhất. Bus dịch vụ được sử dụng rộng rãi trong một bối cảnh tổ chức và thường tương đương với bus dịch vụ doanh nghiệp (ESB).

2.23

Dịch vụ đề cử (service candidate)

Dịch vụ (2.20) được xác định trong vòng đời SOA (2.58) đáp ứng các yêu cầu dịch vụ rộng, từ đó một hoặc nhiều yêu cầu được chọn để phát triển thêm như một phần của giải pháp SOA (2.56) tổng thể.

2.24

Danh mục dịch vụ (service catalogue)

Sổ đăng ký/kho dịch vụ (service registry/repository)

reg/rep

Tập hợp lô-gic các mô tả dịch vụ (2.31) và các tạo tác liên quan để hỗ trợ xuất bản, đăng ký, tìm kiếm, quản lý và truy hồi các tạo tác đó.

2.25

Dàn dựng dịch vụ (service choreography)

Dàn dựng (2.3) có các phần tử (2.8) là dịch vụ (2.20).

CHÚ THÍCH 1 Xem Điều 8, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).

2.26

Cộng tác dịch vụ (service collaboration)

Cộng tác (2.4) có các phần tử (2.8) là dịch vụ (2.20).

CHÚ THÍCH 1 Xem Điều 8, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).

2.27

Thành phần dịch vụ (service component)

Phần tử (2.8) thực thi dịch vụ (2.20).

2.28

Tổ hợp dịch vụ (service composition)

Tổ hợp (2.5) cung cấp (theo nghĩa hoạt động) các dịch vụ (2.20) mức cao hơn là một tổ hợp dịch vụ (2.20) khác.

CHÚ THÍCH 1 Một tổ hợp có thể hỗ trợ các khuôn mẫu tổ hợp khác nhau, như cộng tác (2.4), dàn dựng (2.3), phối trí (2.16).

CHÚ THÍCH 2 Xem Điều 8, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016)).

2.29

Khách hàng dịch vụ (service consumer)

Thực thể (2.9) sử dụng dịch vụ (2.20).

CHÚ THÍCH 1 Khách hàng có thể tương tác với dịch vụ theo hoạt động hoặc hợp đồng (có trách nhiệm pháp lý).

CHÚ THÍCH 2 Xem 7.4, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).

2.30

Hợp đồng dịch vụ (service contract)

Các điều khoản, điều kiện và quy tắc mà khách hàng dịch vụ (2.29) và nhà cung cấp dịch vụ (2.50) đang tương tác phải cam kết (trực tiếp hoặc gián tiếp).

CHÚ THÍCH 1 Hợp đồng dịch vụ qui định cho tất cả các bên tham gia trong tương tác, bao gồm bản thân dịch vụ (2.20) và phần tử (2.8) cung cấp hợp đồng dịch vụ cho tương tác cụ thể theo câu hỏi.

CHÚ THÍCH 2 Xem 7.6, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).

2.31

Mô tả dịch vụ (service description)

Thông tin cần thiết để sử dụng hoặc xem xét việc sử dụng dịch vụ (2.20).

CHÚ THÍCH 1 Mô tả dịch vụ thường gồm các tác vụ (2.38) dịch vụ, hợp đồng và chính sách.

CHÚ THÍCH 2 Xem Điều 7, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).

2.32

Triển khai các dịch vụ (service deployment)

Các hoạt động thực thi dịch vụ (2.20) có thể để chạy trong môi trường phần cứng và phần mềm cụ thể và có thể được sử dụng bởi khách hàng dịch vụ (2.29).

2.33

Phát triển dịch vụ (service development)

Các hoạt động mà các nhu cầu và các ràng buộc được xác định và dịch vụ (2.20) được thiết kế như một phần của một giải pháp SOA (2.56) để giải quyết các nhu cầu đó trong các ràng buộc.

2.34

Phát hiện dịch vụ (service discovery)

Các hoạt động để khách hàng dịch vụ (2.29) có thể tìm dịch vụ (2.20) đáp ứng các yêu cầu chức năng và/hoặc phi chức năng cụ thể của dịch vụ.

2.35

Quản trị dịch vụ (service governance)

Cơ chế kiểm soát và chiến lược áp dụng trong suốt vòng đời dịch vụ (2.41) và danh mục đầu tư dịch vụ, bao gồm việc thiết lập các chuỗi trách nhiệm, thúc đẩy giám sát việc phù hợp với các chính sách bằng cách cung cấp các quá trình (2.18) thích hợp và các phép đo lường như một phần của quản trị giải pháp SOA (2.57).

CHÚ THÍCH 1 Các khía cạnh vòng đời dịch vụ cần được quản trị gồm: việc ghi địa chỉ các sửa đổi dịch vụ, các cập nhật phiên bản, thông báo hủy bỏ, phân vùng khai triển, khả năng đại lý, khả năng khai triển và khả năng đáp ứng nhu cầu cá nhân.

2.36

Thực thi dịch vụ (service implementation)

Các hoạt động thực hiện việc phát triển kỹ thuật và thực thi vật lý của dịch vụ (2.20), đây là một phần trong vòng đời dịch vụ (2.41) và dẫn đến việc tạo ra một thành phần dịch vụ (2.27).

2.37

Tương tác dịch vụ (service interaction)

Tham gia vào việc sử dụng khả năng được cung cấp, thường là trên một ranh giới giới quyền sở hữu, để đạt được một khả năng tác động môi trường thực (2.19) cụ thể mong muốn.

CHÚ THÍCH 1 Xem Tài liệu tham khảo [8].

2.38

Giao diện dịch vụ (service interface)

Tác vụ (2.14) có các phần tử (2.8) có thể tương tác và trao đổi thông tin với dịch vụ, trong đó hình thức yêu cầu và đầu ra của yêu cầu theo mô tả dịch vụ (2.31).

CHÚ THÍCH 1 Xem 7.13, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).

2.39

Tính tương hợp dịch vụ (service interoperability)

Khả năng của các nhà cung cấp dịch vụ (2.50) và khách hàng dịch vụ (2.29) để truyền thông, gọi dịch vụ (2.20) và trao đổi thông tin tại mức cú pháp và ngữ nghĩa dẫn đến các tác động như xác định bởi mô tả dịch vụ (2.31).

2.40

Cam kết mức độ dịch vụ (service level agreement)

SLA

Kiểu hợp đồng dịch vụ (2.30) xác định các điều kiện có thể đo lường được của mối tương tác giữa một nhà cung cấp dịch vụ (2.50) và một khách hàng dịch vụ (2.29).

CHÚ THÍCH 1 Cam kết mức độ dịch vụ có thể qui định; tập các dịch vụ (2.20) mà nhà cung cấp dịch vụ sẽ phân phối, định nghĩa đầy đủ, cụ thể về từng dịch vụ, trách nhiệm của nhà cung cấp dịch vụ và khách hàng dịch vụ, tập các phép đo để xác định xem nhà cung cấp dịch vụ có đang phân phối dịch vụ như đã cam kết, cơ chế kiểm toán để giám sát dịch vụ hay không, các biện pháp khắc phục sẵn có cho khách hàng dịch vụ và nhà cung cấp dịch vụ nếu các điều khoản trong SLA không được đáp ứng và cách thức mà SLA phải thay đổi theo thời gian.

2.41

Vòng đời dịch vụ (service lifecycle)

Tập các giai đoạn thực hiện một dịch vụ (2.20) có thể đi từ khái niệm và định danh đến khởi tạo và kết thúc.

2.42

Quản lý dịch vụ (service management)

Việc giám sát, kiểm soát, duy trì, tối ưu hóa và vận hành các dịch vụ (2.20).

2.43

Lập mô hình dịch vụ (service modeling)

Tập các hoạt động để phát triển một loạt các dịch vụ đề cử (2.23) cho các chức năng hoặc hành động trên một giải pháp SOA (2.56) có sử dụng các quá trình phân tích hướng dịch vụ (2.47).

2.44

Giám sát dịch vụ (service monitoring)

Theo dõi trạng thái và điều kiện vận hành liên quan đến việc thi hành, hiệu năng và các khả năng tác động môi trường thực (2.19) của dịch vụ (2.20).

2.45

Phối trí dịch vụ (service orchestration)

Phối trí (2.16) mà trong đó các phần tử (2.8) được phối trí là dịch vụ (2.20).

2.46

Sự định hướng dịch vụ (service orientation)

Các tiếp cận để thiết kế các hệ thống theo các điều khoản của dịch vụ (2.20) và phát triển các dịch vụ cơ sở.

2.47

Phân tích hướng dịch vụ (service oriented analysis)

Các bước thu thập thông tin ban đầu được hoàn thành để hỗ trợ một quá trình lập mô hình dịch vụ (2.43) mà kết quả là tạo ra một tập các dịch vụ (2.20).

CHÚ THÍCH 1 Phân tích này cung cấp hướng dẫn cho các giai đoạn tiếp theo trong vòng đời SOA và chỉ có thể thực hiện một lần cho mỗi quá trình (2.18) nghiệp vụ hoặc lặp lại.

2.48

Kiến trúc hướng dịch vụ (service oriented architecture)

SOA

Kiểu kiến trúc hỗ trợ sự định hướng dịch vụ (2.46) và là một mô thức cho việc xây dựng các giải pháp nghiệp vụ.

CHÚ THÍCH 1 Dịch vụ (2.20) được biết trong kiểu này sử dụng các hoạt động bao gồm các quá trình (2.18) nghiệp vụ, có các mô tả để đưa ra bối cảnh, có thể được thực thi thông qua tổ hợp dịch vụ (2.28), có các thực thi môi trường cụ thể được mô tả trong bối cảnh để ràng buộc hoặc cho phép các thực thi đó, yêu cầu quản trị và đặt các yêu cầu vào hạ tầng để đạt được tính tương hợp và tính minh bạch vị trí bằng cách sử dụng các tiêu chuẩn trong phạm vi lớn nhất có thể.

CHÚ THÍCH 2 Xem Điều 4, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).

2.49

Chính sách dịch vụ (service policy)

Chính sách (2.17) được áp dụng cho dịch vụ (2.20).

2.50

Nhà cung cấp dịch vụ (service provider)

Thực thể (2.9) cung cấp các dịch vụ (2.20).

CHÚ THÍCH 1 Nhà cung cấp dịch vụ có thể chịu trách nhiệm vận hành các dịch vụ hoặc ký kết hợp đồng đối với các dịch vụ (trách nhiệm pháp lý) hoặc cả hai.

CHÚ THÍCH 2 Xem 7.4, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).

2.51

Việc xuất bản các dịch vụ (service publishing)

Việc lập danh mục các mô tả dịch vụ (2.31) tại một vị trí có thể truy nhập, chẳng hạn như sổ đăng ký/kho dịch vụ (2.24), tại đó, hỗ trợ các hoạt động, chẳng hạn như tìm kiếm và truy hồi các mô tả, tạo thông tin dịch vụ trực quan và sẵn có cho các khách hàng dịch vụ (2.29) tiềm năng.

2.52

Thực thi SOA (SOA implementation)

Các phương pháp và kỹ thuật sử dụng để phát triển các giải pháp dựa trên SOA (2.48).

2.53

Sự thuần thục SOA (SOA maturity)

Đánh giá khả năng của tổ chức chấp thuận SOA (2.48) và mức chấp thuận hiện tại.

2.54

Mô hình thuần thục SOA (SOA maturity model)

Khung công tác nêu rõ các mục tiêu tổng thể và phương pháp để đánh giá sự thuần thục SOA (2.53) của tổ chức so với các mục tiêu này.

2.55

Tài nguyên SOA (SOA resource)

Các phần tử (2.8) cung cấp các tài nguyên IT được dịch vụ (2.20) sử dụng.

2.56

Giải pháp SOA (SOA solution)

Các giải pháp, một phần hoặc toàn bộ, được thực thi bằng cách áp dụng các nguyên tắc, khái niệm, phương pháp và kỹ thuật SOA (2.48).

CHÚ THÍCH 1 Các giải pháp SOA gồm trường hợp vật lý cụ thể của các thực thi dịch vụ (2.36), bao gồm hạ tầng, các phần tử kiến trúc khác và khả năng cần thiết để hỗ trợ các quá trình quản trị và vòng đời, cùng nhau cho phép các tác động miền cụ thể thể hiện một giải pháp dựa trên SOA đối với các vấn đề nghiệp vụ.

2.57

Quản trị giải pháp SOA (SOA solution governance)

Sự chuyên môn hóa quản trị IT đặc biệt tập trung vào các chiến lược và cơ chế quản lý cho giải pháp SOA (2.56) cụ thể của người sử dụng cuối.

CHÚ THÍCH 1 Quản trị giải pháp SOA quản lý toàn bộ vòng đời giải pháp SOA (2.58) bằng cách thiết lập về nhân sự, vai trò, thủ tục quản lý và việc ra quyết định. Quản trị giải pháp SOA cần chấp thuận phương pháp luận thích hợp và các qui phạm thực hành tốt Quản trị giải pháp SOA thường yêu cầu các công cụ hỗ trợ để tùy chỉnh và quản lý chiến lược quản trị theo nhu cầu.

CHÚ THÍCH 2 Trong khi quản lý có nghĩa là quá trình (2.18) cụ thể cho quản trị và kiểm soát để thi hành các chính sách, thì quản trị nhằm vào việc gán các quyền để đưa ra quyết định và việc quyết định các biện pháp sử dụng và các chính sách để đưa ra các quyết định đó.

2.58

Vòng đời giải pháp SOA (SOA solution lifecycle)

Tập các hoạt động để thiết kế kỹ thuật các giải pháp SOA (2.56), bao gồm phân tích, thiết kế, thực thi, triển khai, thử nghiệm và quản lý.

2.59

Quản lý giải pháp SOA (SOA solution management)

Việc đo lường, giám sát và lập cấu hình toàn bộ vòng đời của một giải pháp SOA (2.56).

CHÚ THÍCH 1 Trong thời gian chạy, đây là tập các hoạt động đo lường và vận hành cụ thể của việc thực thi giải pháp SOA theo các chiến lược và cơ chế được xác định bởi quá trình quản trị giải pháp SOA (2.57).

2.60

Tác vụ (task)

Hành động đơn vị để hoàn thành một kết quả xác định.

CHÚ THÍCH 1 Các tác vụ được tiến hành bởi con người các tổ chức, đặc biệt bởi tác nhân (2.12).

CHÚ THÍCH 2 Xem 6.4, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).

2.61

Dịch vụ Web (Web services)

Hệ thống phần mềm được thiết kế để hỗ trợ tương tác máy-máy tương hợp qua mạng.

CHÚ THÍCH 1 Định nghĩa gốc: Hệ thống phần mềm được thiết kế để hỗ trợ tương tác máy-máy tương hợp qua mạng. Hệ thống phần mềm có một tác vụ (2.14) được mô tả theo khuôn dạng có thể xử lý bằng máy (đặc biệt là WSDL). Các hệ thống khác tương tác với dịch vụ Web theo cách thức được qui định bởi mô tả bằng cách sử dụng các thông điệp SOAP, thường được truyền bằng cách sử dụng HTTP với một dạng XML chuyên dụng kết hợp với các tiêu chuẩn liên quan đến Web khác.

CHÚ THÍCH 2 Xem Tài liệu tham khảo [18].

3 Thuật ngữ viết tắt

Đối với các mục đích của tài liệu này, các thuật ngữ viết tắt sau đây được áp dụng.

ABB	Architectural Building Block	Khối xây dựng kiến trúc
BPMN	BussinessProcess Model and Notation	Ký hiệu và mô hình quá trình nghiệp vụ
COBIT	Control Objectives for Information and Related Technology	Tiêu chuẩn về mục tiêu kiểm soát đối với thông tin và công nghệ liên quan
EA	Enterprise Architecture	Kiến trúc doanh nghiệp
ESB	Enterprise Service Bus	Bus dịch vụ doanh nghiệp
HTTP	Hyper Text Transfer Protocol	Giao thức truyền tải siêu văn bản
HTTPS	Hyper Text Transfer Protocol Secure	Giao thức truyền tải siêu văn bản an toàn
IT	Information Technology	Công nghệ thông tin
ITIL	Information Technology Infrastructure Library	Thư viện hạ tầng công nghệ thông tin
KPI	Key performance Indicator	Chỉ số hiệu năng chính
L2TP	Layer 2 Tunneling Protocol	Giao thức đường hầm tầng 2
MPLS	Multiprotocol Label Switching	Chuyển mạch nhãn đa giao thức
OWL	Web Ontology Language	Ngôn ngữ bản thể học Web
PKI	Public Key Infrastructure	Hạ tầng khóa công khai
QoS	Quality of Service	Chất lượng dịch vụ
RA	Reference Architecture	Kiến trúc tham chiếu
REST	Representational State Transfer	Chuyển trạng thái biểu thị
RPC	Remote Procedure Call	Gọi thủ tục từ xa
SLA	Service Level Agreement	Cam kết mức độ dịch vụ
SOA	Service Oriented Architecture	Kiến trúc hướng dịch vụ
SOAP	Standard massage protocol to exchange structured data	Giao thức thông điệp chuẩn để trao đổi dữ liệu có cấu trúc
SQL	Structured Query Language	Ngôn ngữ truy vấn có cấu trúc
UML	Unified Modeling Language	Ngôn ngữ lập mô hình thống nhất
VPN	Virtual Private Network	Mạng riêng ảo
WSDL	Web Services Description Language	Ngôn ngữ mô tả dịch vụ Web
WSRP	Web Services Remote Portlet	Portlet từ xa dịch vụ Web
XML	Extensible Markup Languange	Ngôn ngữ đánh dấu mở rộng

4 Ký hiệu

4.1 Qui định chung

Nội dung dưới đây hướng dẫn cách diễn giải các sơ đồ.

4.2 UML

Hầu hết các sơ đồ không phải là UML. Các sơ đồ ở dạng văn bản có nghĩa trước khi xác định sơ đồ đó là kiểu sơ đồ UML để người đọc biết cách diễn giải.

4.3 Mối quan hệ thực thể

Các sơ đồ quan hệ thực thể (như Hình 1 và Hình 2) có các hộp, đường thẳng, mũi tên và các số được khoanh tròn cần được diễn giải theo quy tắc sau đây.

– Hộp là các khái niệm, các tầng, các khối xây dựng kiến trúc, các khả năng hoặc các thành phần siêu mô hình.

– Mũi tên là mối quan hệ giữa các khái niệm siêu mô hình; các đầu mũi tên đơn thể hiện hướng của mối quan hệ; các mũi tên hai đầu cho biết mối quan hệ là hai chiều.

– Các quan hệ được đặt tên, được biểu diễn dưới dạng các đường thẳng được ghi nhãn hoặc mũi tên, không hàm ý phần tử tập hợp.

– Các biểu thị phần tử tập hợp là các phần tử tham gia trong mối quan hệ, sử dụng các quy ước toán (*= = 0..*; 0..1 a = tùy chọn và chỉ 1; 1 = = theo yêu cầu như qui định trong ISO/IEC 15474-1).

4.4 Hình tròn

Các sơ đồ hình tròn với các trạng thái chỉ ra tiến trình của một trạng thái hoặc vòng đời và tiến trình theo chiều kim đồng hồ. Hình 10 là ví dụ của một sơ đồ hình tròn.

4.5 Luồng

Luồng thường được sử dụng làm ví dụ và nên diễn giải theo các quy tắc sau đây;

– Hộp là các tầng, khối xây dựng kiến trúc hoặc thành phần;

– Mũi tên có hướng chỉ hướng của luồng giữa các hộp;

– Số được khoanh tròn trên mũi tên luồng chỉ trình tự luồng và được sử dụng như một điểm tham khảo trong mọi văn bản giải thích.

Hình 5 và Hình 6 là các luồng làm minh họa.

5 Quy ước

Kiến trúc tham chiếu này được xác định trong ba phần. Tiêu chuẩn này qui định các thuật ngữ và khái niệm về kiến trúc hướng dịch vụ. Việc hiểu các thuật ngữ và khái niệm được qui định trong tiêu chuẩn này là quan trọng trước khi đọc hoặc sử dụng TCVN 12482-2 (ISO/IEC 18384-2) và TCVN 12482-3 (ISO/IEC 18384-3). Tiêu chuẩn này xác định một kiến trúc tham chiếu cho các giải pháp SOA. Kiến trúc này xác định một siêu mô hình, một tập các tầng của kiến trúc phân tầng và tập các kiểu dịch vụ chung. TCVN 12482-3 (ISO/IEC 18384-3) qui định bản thể học về SOA, có cách thể hiện chính thức hơn về các khái niệm SOA và mối quan hệ cốt lõi giữa các khái niệm. Thuật ngữ trong tiêu chuẩn này phù hợp với bản thể học trong TCVN 12482-3 (ISO/IEC 18384-3).

Tiêu chuẩn này có thể đọc theo trình tự hoặc được sử dụng như một tham khảo. Tiêu chuẩn này bao gồm bộ từ vựng và tài liệu giới thiệu toàn diện và các khái niệm SOA. TCVN 12482-2 (ISO/IEC 18384-2) đưa ra một giới thiệu ngắn về SOA. Tiếp theo giới thiệu này là tổng quan mức cao về 10 tầng và các kiểu dịch vụ được qui định trong tiêu chuẩn này. Tiếp theo là định nghĩa và giải thích siêu mô hình sử dụng trong SOA RA. Siêu mô hình xác định tầng, các khả năng và khái niệm ABB cùng với các khái niệm lô-gic khác. Các ABB và khả năng được xác định đơn nhất trong mỗi tầng. Các khả năng và ABB có thể yêu cầu các khả năng và ABB xác định trong các tầng khác để thực hiện đầy đủ các yêu cầu kiến trúc. Tất cả các tầng, khả năng và ABB trong tiêu chuẩn này là các phần tử lô-gic và bất kỳ tham khảo nào đến các phần tử lô-gic này là “thực hiện”, “hỗ trợ” hoặc “tương tác” khi một giải pháp SOA được phát triển. Việc thực hiện vật lý các khả năng và ABB thực sự là “thực hiện”, “hỗ trợ” hoặc “tương tác”.

6 Sự phù hợp

TCVN 12482 (ISO/IEC 18384) gồm ba phần, có những yêu cầu về sự phù hợp khác nhau:

a) Thuật ngữ và khái niệm – chỉ phù hợp với các thuật ngữ và phù hợp về ngữ nghĩa trong các định nghĩa;
b) Kiến trúc tham chiếu cho các giải pháp SOA – chỉ phù hợp về ngữ nghĩa của siêu mô hình và bất kỳ tầng nào, các ABB hoặc các khả năng được sử dụng;
c) Bản thể học SOA – phù hợp với các ứng dụng OWL hoặc phi OWL.

Sự phù hợp với tiêu chuẩn này được xác định như sau.

Nếu bất kỳ tài liệu, sản phẩm hoặc tiêu chuẩn nào khẳng định sự phù hợp, thì phải sử dụng các thuật ngữ trong tiêu chuẩn này với cùng ngữ nghĩa như các định nghĩa trong tiêu chuẩn.

Các nguyên tắc và khái niệm được cung cấp dưới dạng tài liệu giải thích và không có nghĩa về hiệu năng.

7 Các khái niệm SOA

7.1 Giới thiệu về SOA

Kiến trúc hướng dịch vụ (viết tắt là SOA) (xem 2.48) là một kiểu kiến trúc hỗ trợ định hướng dịch vụ (xem 2.46) và là một mô thức về nghiệp vụ và IT. Kiểu kiến trúc này là để thiết kế các hệ thống về dịch vụ sẵn có tại giao diện và đầu ra của dịch vụ. Như được CHÚ THÍCH trong 2.20, dịch vụ là một thể hiện lô-gic của một tập các hoạt động có kết quả được quy định, là tự bao gồm, có thể gồm dịch vụ khác và là một “hộp đen” đối với các khách hàng dịch vụ.

Chung với các kiểu kiến trúc khác, SOA

– Đặt các yêu cầu đơn nhất lên hạ tầng hệ thống,

– Có các thực thi môi trường cụ thể, được ràng buộc hoặc cho phép theo bối cảnh và được mô tả trong bối cảnh đó,

– Khuyến nghị quản trị về IT, các hệ thống và EA,

– Có các giải pháp nghiệp vụ được thiết kế để phản ánh các hoạt động nghiệp vụ trong môi trường thực, và

– Cung cấp các tiêu chí cho phép khách hàng xác định xem giải pháp nghiệp vụ đưa ra có thực hiện đúng và hoàn toàn theo kỳ vọng hay không.

Ngoài ra, SOA có các đặc tính phân biệt ngoài các kiểu kiến trúc khác, đặc biệt là:

a) Thúc đẩy việc sử dụng các tiêu chuẩn và các giao diện mở nhằm đạt được tính tương hợp và độ mở vị trí;
b) Dịch vụ và quá trình được thiết kế rõ ràng để hoạt động cả trong tổ chức hoặc giữa các tổ chức;
c) Yêu cầu mô tả rõ ràng về dịch vụ đưa ra;
d) Dịch vụ và quá trình được thiết kế để phản ánh các hoạt động nghiệp vụ trong môi trường thực;
e) Việc thể hiện dịch vụ sử dụng các mô tả nghiệp vụ để đưa ra bối cảnh (tức là quá trình nghiệp vụ, mục đích, quy tắc, chính sách, giao diện dịch vụ và thành phần dịch vụ);
f) Yêu cầu quản trị thích hợp đối với việc thể hiện và thực thi dịch vụ;
g) Tổ hợp dịch vụ được sử dụng như một phương tiện để thực thi quá trình nghiệp vụ;
h) Đưa ra các tiêu chí cho phép các khách hàng dịch vụ xác định xem dịch vụ đã được thực thi đúng và hoàn toàn phù hợp với mô tả dịch vụ không.

SOA coi “dịch vụ” là phần tử cơ bản để xây dựng các hệ thống thông tin phù hợp với các yêu cầu giải pháp khác nhau. Dịch vụ từ quan điểm nghiệp vụ là việc phân phối các kết quả nghiệp vụ của các quá trình nghiệp vụ; dịch vụ từ quan điểm IT là thực thi IT của các quá trình nghiệp vụ đó. Các hoạt động phát triển một giải pháp SOA có thể là riêng tư đối với một tổ chức (ví dụ triển khai một dịch vụ), cộng tác giữa một tập các thực thể nghiệp vụ (ví dụ các cuộc gọi và dàn dựng dịch vụ) hoặc các hoạt động chung để duy trì tính khả thi của hệ sinh thái dịch vụ (ví dụ việc phát hành dịch vụ mới).

Một số lợi ích dự định của việc sử dụng SOA là cải thiện khả năng tác động của việc phát triển hệ thống thông tin, khả năng tác động tích hợp và khả năng tác động sử dụng lại tài nguyên.

Trong khi có sự quan tâm đến SOA như một phương tiện phân phối các khả năng tác động, một tập đơn lẻ các nguyên tắc kỹ thuật SOA, chuẩn cụ thể và tiêu chuẩn chưa được thiết lập cho thị trường toàn thế giới. Các sản phẩm và giải pháp hiện tại sử dụng các tiêu chuẩn, phương pháp và công nghệ khác nhau, điều này là tăng thêm sự nhầm lẫn về khả năng tác động của SOA. Để tăng tiêu chuẩn hóa và tiềm năng chất lượng của các giải pháp, cũng như thúc đẩy việc áp dụng SOA có khả năng tác động trên quy mô lớn, cần phải thiết lập một tập các thuật ngữ, nguyên tắc và khái niệm thống nhất cho SOA.

Cần lưu ý rằng các nguyên tắc SOA được định nghĩa ở đây có thể áp dụng cho kỹ thuật phần mềm và cũng có thể áp dụng cho các hệ thống kỹ thuật để chính thức hóa các hệ thống dựa trên dịch vụ (tức là các hệ thống phức tạp, liên hệ thống, hệ thống của các hệ thống, kiến trúc doanh nghiệp).

7.2 Các khái niệm

7.2.1 Vai trò

7.2.1.1 Tổng quan

Nói chung, một vai trò được xác định bởi một tập các hoạt động phục vụ một mục đích chung. Khi một thực thể được gán hoặc giả định là một vai trò, thì thức thể đó thực hiện các hoạt động của vai trò.

Định nghĩa của một vai trò gồm tất cả các hoạt động được yêu cầu và thời điểm được thực thi. Các nhà cung cấp dịch vụ và khách hàng dịch vụ là những vai trò nền tảng trong một kiến trúc theo định hướng dịch vụ. Hệ sinh thái SOA bao gồm dịch vụ phân phối chức năng, các khách hàng dịch vụ tương tác với dịch vụ và các nhà cung cấp dịch vụ phát triển và lưu trữ các dịch vụ trên máy chủ cho khách hàng. Tuy nhiên, vai trò của các nhà cung cấp dịch vụ và khách hàng dịch vụ trải rộng trên nhiều hoạt động và có thể được thực thi bởi các bên khác nhau chịu trách nhiệm về các hoạt động khác nhau, tức là bên tham gia có trách nhiệm vận hành có thể không qui định trách nhiệm trong hợp đồng và ngược lại. Ngoài ra, bên tham gia giả định vai trò của nhà cung cấp dịch vụ trong một bối cảnh và vai trò của khách hàng dịch vụ trong một bối cảnh khác. Trong phần sau, thuật ngữ nhà cung cấp dịch vụ được sử dụng để chỉ ra một thực thể thực hiện một hoạt động liên quan đến vai trò nhà cung cấp dịch vụ; thuật ngữ khách hàng dịch vụ là một thực thể thực hiện một hoạt động liên quan đến vai trò khách hàng dịch vụ.

7.2.1.2 Nhà cung cấp dịch vụ

Đối với các nhà cung cấp dịch vụ, các hoạt động bao gồm việc phát triển, thử nghiệm và triển khai các dịch vụ đáp ứng một loạt các yêu cầu chức năng và phi chức năng. Các yêu cầu này bao gồm các đặc tính vận hành và các nghĩa vụ theo hợp đồng, cũng như việc hỗ trợ và đáp ứng các thông tin liên lạc từ các thực thể khác trong giải pháp hoặc hệ sinh thái trong SOA. Nhà cung cấp dịch vụ giám sát dịch vụ trong quá trình hoạt động để đánh giá sự phù hợp với các yêu cầu và để xác định và giảm thiểu hành vi không mong muốn. Nhà cung cấp dịch vụ chịu trách nhiệm xác định và thực thi quản trị các dịch vụ. Ngoài ra, nhà cung cấp dịch vụ chịu trách nhiệm đăng ký dịch vụ và duy trì mô tả dịch vụ.

Có hai bối cảnh mà nhà cung cấp dịch vụ có thể có trách nhiệm khi cung cấp các dịch vụ: theo vận hành và theo hợp đồng. Lưu ý rằng thực thể chịu trách nhiệm theo hợp đồng (bên tham gia trong hợp đồng hoặc cam kết mức dịch vụ) có thể không phải là cùng một thực thể chịu trách nhiệm về vận hành (tức là trao đổi thông điệp với khách hàng dịch vụ).

– Theo vận hành – nhà cung cấp dịch vụ có thể tham gia vào các hoạt động liên quan đến trao đổi thông điệp với khách hàng dịch vụ, cũng như tạo ra khả năng tác động được cam đoan để gọi dịch vụ. Các thực thể giả định trách nhiệm vận hành qua vòng đời dịch vụ có thể tham gia vào bất kỳ điều nào sau đây:

Phát triển các dịch vụ: các quá trình vòng đời để lập mô hình và tạo ra các thực hiện dịch vụ, trong đó việc triển khai các dịch vụ là một bước (xem các khái niệm vòng đời dịch vụ trong 7.2.8);
Triển khai các dịch vụ: đặt các tạo tác dịch vụ và nếu không sửa đổi môi trường dịch vụ sao cho dịch vụ có thể trao đổi thông tin dẫn đến thực hiện chức năng dịch vụ và các khả năng tác động liên quan;
Cung cấp các dịch vụ: hỗ trợ sử dụng dịch vụ được triển khai thông qua trao đổi thông tin và hỗ trợ hệ sinh thái SOA cần thiết để thực hiện chức năng dịch vụ và các khả năng tác động dịch vụ;
Xuất bản các dịch vụ: tạo ra và duy trì mô tả dịch vụ (bao gồm, phân loại dịch vụ phù hợp) để mọi bên tham gia dịch vụ có thể tìm kiếm và truy hồi được, bao gồm các nhà cung cấp dịch vụ, các khách hàng dịch vụ, các bên tham gia khác;
Lưu trữ các dịch vụ trên máy chủ: cung cấp và hỗ trợ sử dụng hạ tầng cần thiết cho việc phát triển, triển khai và cung cấp các dịch vụ;
Quản trị các dịch vụ: qui định các điều kiện và ràng buộc phù hợp với mục đích chung của các bên tham gia dịch vụ và các cấu trúc và quá trình cần thiết để xác định và đáp ứng các hành động được thực thi hướng đến việc thực hiện các mục đích đó;

– Theo hợp đồng – nhà cung cấp dịch vụ có thể tham gia vào các hoạt động liên quan đến việc xác định các khía cạnh nghiệp vụ và nghĩa vụ pháp lý liên quan đến việc sử dụng dịch vụ được cung cấp và phối hợp sử dụng và các cam kết liên quan với khách hàng dịch vụ như được ghi trong dịch vụ hợp đồng. Các thực thể giả định trách nhiệm theo hợp đồng qua vòng đời dịch vụ có thể tham gia vào bất kỳ điều nào sau đây:

Định giá dịch vụ: quyết định cách tính giá trị dịch vụ hoặc làm thế nào/có hay không khai thác chúng cho các giá trị khác;
Xác định các cam kết dịch vụ: trong hợp tác với khách hàng dịch vụ, việc quyết định loại cam kết chính thức nào, chẳng hạn như các kết mức dịch vụ (SLA), được yêu cầu sử dụng dịch vụ, bao gồm giải quyết các mâu thuẫn trong các chính sách dịch vụ ưu tiên;
Xác định các hợp đồng dịch vụ: nắm bắt các cam kết dịch vụ và áp dụng các khía cạnh quản trị một cách rõ ràng tạo điều kiện cho việc thực thi;
Thực thi các hợp đồng dịch vụ: tham gia vào các quá trình, có thể được xác định trong hợp đồng dịch vụ, để đảm bảo đủ điều kiện hợp đồng hoặc các hành động khắc phục theo qui định;
Quản trị nghiệp vụ và các hợp đồng: thiết lập các quy tắc nghiệp vụ, các chính sách và các yêu cầu cho hợp đồng và để cho phép và giám sát quản trị vận hành các dịch vụ.

7.2.1.3 Khách hàng dịch vụ

Khách hàng dịch vụ tham gia vào các hoạt động để xác định dịch vụ đáp ứng nhu cầu, đánh giá xem dịch vụ có thể đáp ứng các điều kiện được qui định về sử dụng (ví dụ: quyền truy nhập, cấp giấy phép và qui mô của các yêu cầu), hiểu các trao đổi thông tin và các giao thức cho phép truyền thông với dịch vụ và có thể cam kết các khả năng mạng để thực hiện truyền thông thành công. Khách hàng dịch vụ nên truy nhập và hiểu mô tả dịch vụ, cả khi dịch vụ liên quan đến việc xác định gốc và phù hợp với các thay đổi đối với các chi tiết về tương tác dịch vụ hoặc các điều kiện sử dụng.

Nhà cung cấp dịch vụ cũng có thể đồng thời hành động như một khách hàng dịch vụ. Trong trường hợp dịch vụ tổ hợp, nhà cung cấp dịch vụ đáp ứng một khách hàng dịch vụ bên ngoài nhưng sau đó trở thành khách hàng dịch vụ của dịch vụ thành phần để thực hiện các tác động được lập thành tài liệu đã tạo ra bởi tổ hợp đó.

Có hai bối cảnh mà các khách hàng dịch vụ có thể có trách nhiệm khi sử dụng dịch vụ: vận hành và hợp đồng. Như với các nhà cung cấp dịch vụ, thực thể chịu trách nhiệm theo hợp đồng (bên tham gia trong hợp đồng hoặc các kết mức dịch vụ) có thể không phải là cùng một thực thể chịu trách nhiệm về vận hành (tức là trao đổi thông điệp với nhà cung cấp). Lưu ý rằng các hoạt động theo vận hành và theo hợp đồng của khách hàng dịch vụ thường là các đối tác trực tiếp của các hoạt động nhà cung cấp.

– Theo vận hành – khách hàng dịch vụ có thể tham gia vào các hoạt động liên quan đến việc phát hiện các dịch vụ và trao đổi thông điệp với nhà cung cấp dịch vụ. Các thực thể giả định trách nhiệm theo hợp đồng qua vòng đời dịch vụ có thể tham gia vào bất kỳ điều nào sau đây:

Phát hiện các dịch vụ: tìm kiếm và kiểm tra các mô tả dịch vụ sẵn có để xác định dịch vụ đáp ứng nhu cầu của họ (ví dụ: thông qua tương tác với một đăng ký/ kho lưu trữ dịch vụ hoặc tư vấn các khuyến nghị khách hàng);
Gọi dịch vụ: trao đổi các thông điệp với một dịch vụ được cung cấp để gọi chức năng và nhận ra các khả năng tác động tương ứng;
Quản trị sử dụng dịch vụ: thiết lập và thực thi các chính sách nghiệp vụ cho việc sử dụng và ký kết hợp đồng dịch vụ để đáp ứng các nhu cầu nghiệp vụ;

– Theo hợp đồng – khách hàng dịch vụ có thể tham gia vào các hoạt động liên quan đến việc xác định các khía cạnh nghiệp vụ và nghĩa vụ pháp lý liên quan đến việc sử dụng một dịch vụ được cung cấp của họ và việc phối hợp các thỏa thuận liên quan đến nhà cung cấp dịch vụ như được ghi trong hợp đồng dịch vụ. Các thực thể giả định trách nhiệm theo hợp đồng qua vòng đời dịch vụ có thể tham gia vào bất kỳ điều nào sau đây:

Ký kết hợp đồng: thiết lập và tuân thủ bởi các hợp đồng;
Thanh toán dịch vụ: phù hợp với các cam kết dịch vụ nhận định việc trao đổi tiền hoặc dịch vụ để đổi lấy việc sử dụng dịch vụ được cung cấp;
Xác định các cam kết dịch vụ: trong việc phối hợp với nhà cung cấp dịch vụ, quyết định các loại cam kết chính thức, như các các kết mức dịch vụ (SLA), được qui định như những ràng buộc hoặc điều kiện sử dụng dịch vụ, bao gồm giải quyết mâu thuẫn trong các chính sách dịch vụ ưu tiên;
Xác định các hợp đồng dịch vụ: nắm bắt các cam kết dịch vụ và áp dụng các khía cạnh quản trị một cách rõ ràng tạo điều kiện cho việc thực thi;
Thực thi các hợp đồng dịch vụ: tham gia vào các quá trình, có thể được xác định trong hợp đồng dịch vụ, để đảm bảo đủ điều kiện hợp đồng hoặc các hành động khắc phục theo qui định;
Quản trị các hợp đồng: đảm bảo các hợp đồng phù hợp với các nhu cầu nghiệp vụ phát triển và được thực thi vận hành.

Hình 1 – Nhà cung cấp dịch vụ và khách hàng dịch vụ

7.2.2 Dịch vụ

Như được định nghĩa ở trên, dịch vụ (xem 2.20) là biểu diễn lô-gic của một tập các hoạt động có kết quả qui định, tự chứa, có thể bao gồm các dịch vụ khác và là một “hộp đen” đối với khách hàng dịch vụ (xem 7.4, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016)). Dịch vụ là bất khả tri cho dù khái niệm được áp dụng cho lĩnh vực nghiệp vụ hay lĩnh vực IT. Một dịch vụ có thể có một hoặc nhiều nhà cung cấp dịch vụ hoặc khách hàng dịch vụ và tạo ra kết quả qui định.

Khách hàng dịch vụ không biết cách thực thi các dịch vụ. Như trong Hình 1, khách hàng sử dụng mô tả để chọn một dịch vụ từ nhà cung cấp. Nếu hai dịch vụ có cùng một mô tả dịch vụ và tạo ra cùng khả năng tác động khi cùng các đầu vào, hai dịch vụ này có chức năng tương đương đối với khách hàng dịch vụ và có thể được sử dụng thay thế cho nhau. Đối với một nhà cung cấp dịch vụ, một là một phương tiện để lộ các khả năng và thực thi xác định tính tương đương.

Bản thân dịch vụ là sự thể hiện lô-gic, bất kỳ dịch vụ nào cũng nên có sự vật, sự việc có thể thi hành các quá trình và truyền thông cần thiết để thực hiện việc tạo kết quả khả năng tác động. Thực thi này được gọi là “triển khai các dịch vụ”. Dịch vụ có thể được thực thi bởi bất kỳ kiểu phần tử nào, bao gồm các thành phần phần mềm, những tác nhân và các tác vụ. Điều gì đó thực hiện một dịch vụ không rõ ràng cho bất cứ ai tương tác với nó. Dịch vụ có thể được thực thi bởi các phần tử khác so với các hệ thống. Điều này bao gồm các phần tử như các thành phần phần mềm, những tác nhân và các tác vụ.

Tương tự như vậy, một dịch vụ có thể được sử dụng bởi các phần tử khác, bản thân dịch vụ (như một sự biểu diễn hoàn toàn hợp lý) không sử dụng các phần tử khác. Tuy nhiên, điều triển khai các dịch vụ có thể rất tốt bao gồm việc sử dụng các phần tử khác (và chắc chắn phải trong trường hợp về tổ hợp dịch vụ).

Một phần tử tương tác với một dịch vụ có thể, ví dụ, thực thi bước sau đây:

– chọn dịch vụ để tương tác với (tuyên bố này là bất khả tri về việc liệu điều này được thực thi một cách linh động khi chạy hoặc tĩnh tại thiết kế và / hoặc xây dựng thời gian);

– chọn một phần tử triển khai các dịch vụ đó [trong một môi trường SOA điển hình, điều này hầu như thường được thực thi “bên trong” một bus dịch vụ (xem 2.22)];

– tương tác với phần tử được chọn triển khai các dịch vụ được chọn (cũng thường được tạo thuận lợi bởi một bus dịch vụ).

Các khái niệm, chẳng hạn như trung gian dịch vụ, người ủy quyền dịch vụ, các bus dịch vụ, v.v… được sử dụng để mô tả và thực thi khía cạnh vận hành của các hệ thống SOA. Tất cả chúng có thể được ghi lại như một một phần tử việc thể hiện dịch vụ. Sự biểu thị này cung cấp một mức độ vô hướng rất quan trọng khi chúng ta không muốn liên kết vận hành với một điểm cuối dịch vụ cụ thể và cho phép chúng ta duy trì nối kết lỏng và khả năng chuyển đổi phương án khi cần thiết. Hiểu những gì một dịch vụ thể hiện và được thể hiện bởi cho phép đóng gói tương tác vận hành phức tạp một cách tương đối (chọn dịch vụ, chọn một phần tử triển khai các dịch vụ và tương tác với các phần tử đã chọn).

Hình 2 – Dịch vụ và các phần tử SOA

Hình 2 cho thấy các phần tử SOA bao gồm dịch vụ, các tác nhân, tác vụ và các hệ thống. Dịch vụ được thực thi bởi bất kỳ phần tử nào. Các hệ thống có các bộ phận có thể là bất kỳ phần tử nào, bao gồm chính dịch vụ, các tác nhân, tác vụ và các hệ thống của chúng. Giải thích thêm về các tác vụ và hệ thống ở trong các Điều sau đây. (Xem TCVN 12482-3:2018 (ISO/IEC 18384-3:2016), Điều 5 cho việc giải thích thêm về các hệ thống và các hệ thống SOA.)

7.2.3 Ngữ nghĩa

Tất cả tác nhân liên quan đến giải pháp kiến trúc hướng dịch vụ, có yếu tố con người và phi con người có thể cần phân tích cú pháp các thông điệp một cách chính xác thông qua sự hiểu biết về tác nhân và được chấp thuận về cú pháp và ngữ nghĩa của thông điệp. Các cú pháp bao gồm các tác vụ, các giao thức và khuôn dạng thông diệp. Các ngữ nghĩa là sự hiểu biết chung về mục đích, trong đó những tác nhân có thể cần hành động để các thông điệp đó theo cách phù hợp với chủ định người gửi. Nói cách khác, những tác nhân phải có hiểu biết ngữ nghĩa chung về các yêu cầu nghiệp vụ được dịch vụ giải quyết và không chỉ nhằm mục đích cho tính tương hợp thông qua một kết nối cú pháp.

Ngoài ra, các ngữ nghĩa quan trọng trong mô tả dịch vụ và các tài nguyên khác trong giải pháp SOA. Việc phát hiện đòi hỏi một hiểu biết chung dựa trên sự phù hợp với các nhu cầu khách hàng dịch vụ đối với các khả năng tác động môi trường thực dẫn đến từ một tương tác dịch vụ. Nó cũng cần thiết cho sự hiểu biết rõ ràng về các điều kiện sử dụng cần được thỏa mãn để tương tác dịch vụ được tiến hành.

Các ngữ nghĩa có thể được chính thức chỉ định thông qua việc sử dụng các bản thể học và ứng dụng vào các miền sử dụng cụ thể để giải quyết một cộng đồng các khái niệm.

7.2.4 Tác vụ và hoạt động

Một tác vụ là một hành động đơn vị hoàn thành một kết quả xác định. Các tác vụ, bao gồm các tác vụ, được thực thi bởi con người hoặc tổ chức, đặc biệt là bởi các trường hợp tác nhân. Bởi vì các tác vụ là đơn vị, các tác vụ không thể được chia nhỏ ở mức chi tiết hơn và được thực thi bởi hầu hết một trường hợp tác nhân.

Từ “hoạt động” trong định nghĩa “dịch vụ” được sử dụng theo nghĩa tiếng Anh tổng quát của từ, không phải theo nghĩa quá trình cụ thể của cùng một từ đó (tức là các hoạt động không nhất thiết phải xử lý các hoạt động). Đặc biệt, ký hiệu và mô hình quá trình nghiệp vụ (BPMN) 2.0 (xem Tài liệu tham khảo [14]) xác định tác vụ như sau: “Một tác vụ là một hoạt động đơn vị trong một luồng quá trình. Một tác vụ được sử dụng khi công việc trong quá trình không thể được chia nhỏ ở mức chi tiết hơn. Nói chung, một người sử dụng cuối và/hoặc các ứng dụng được sử dụng để thực hiện tác vụ khi nó được thục thi.” Điều này chính thức phân tách ký hiệu về việc tiến hành từ ký hiệu của thực thi. Các tác vụ (tùy ý) được thực thi bởi những tác nhân, hơn nữa, (như các trường hợp về phần tử) các tác vụ có thể sử dụng dịch vụ được thực thi bởi các thành phần công nghệ. Đối với SOA, các tác vụ này không bị qui định cho luồng quá trình.

7.2.5 Tổ hợp và quá trình

7.2.5.1 Giới thiệu về các tổ hợp

Tổ hợp là một hệ thống đó là kết quả của việc thu thập một tập hợp các sự vật vì mục đích nào đó.

Trong trường hợp này, tổ hợp đề cập đến một tập hợp các phần được thu thập vì một mục đích và không phải hành động ranh giới soạn. Những tổ hợp được tổ chức theo một trong một tập các khuôn mẫu hay kiểu dáng: phối trí, dàn dựng và cộng tác.

Cũng giống như các hệ thống có thể bao gồm các hệ thống khác, các tổ hợp có thể gồm các tổ hợp khác. Không tổ hợp nào có thể là một phần của chính nó. Vì một tổ hợp là một tập hợp, nó sử dụng ít nhất một một phần tử khác và những phần tử đó có thể nằm ngoài ranh giới. Đối với SOA, các phần tử này thường là, nhưng không giới hạn đối với dịch vụ, các tổ hợp, quá trình, tác nhân và tác vụ.

Tổ hợp, giống như dịch vụ, không hữu hình với bên quan sát bên ngoài. Tuy nhiên, các khuôn mẫu tổ hợp đưa ra cái nhìn sâu sắc về quan điểm bên trong của tổ hợp và mô tả cách thức một tập hợp các phần tử được thu thập hoặc sử dụng để đạt được kết quả.

7.2.5.2 Các khuôn mẫu tổ hợp

Trong Hình 3, các tổ hợp có thể được hiểu rõ bằng cách sử dụng ba khuôn mẫu hoặc kiểu dáng có thể được phân biệt thông qua sự có mặt của một bên chỉ đạo của tổ hợp và sự tồn tại của khuôn mẫu định trước về hành vi hoặc luồng, trong đó các mũi tên chỉ luồng định hướng hoặc việc gọi giữa các phần tử trong tổ hợp.

Hình 3 – Các khuôn mẫu tổ hợp

Phối trí là một khuôn mẫu trong đó có một phần tử được sử dụng bởi tổ hợp để giám sát và chỉ đạo các phần tử khác. Việc chỉ đạo phần tử khác với việc phối trí và có thể nằm trong hoặc ngoài biên. Ví dụ, một luồng công việc là một phần của tổ hợp nhưng đang thực thi luồng. Trong Hình 3, bên chỉ đạo đang gọi các phần tử trong phối trí.

Dàn dựng là một khuôn mẫu về các tổ hợp sự nơi các phần tử được sử dụng bởi tương tác tổ hợp đều được biết và theo khuôn mẫu hành vi. Có một khuôn mẫu hoặc luồng hành vi dùng chung định trước. Dàn dựng không yêu cầu các phần tử phải có đầy đủ kiến thức về khuôn mẫu hành vi. Trong Hình 3, các phần tử tương tác với nhau theo một khuôn mẫu.

Cộng tác là một khuôn mẫu về các tổ hợp nơi các phần tử được sử dụng bởi tương tác tổ hợp theo kiểu không được chỉ đạo (không có bên chỉ đạo) và mọi phần hành động theo mục đích/kế hoạch của chính chúng không có khuôn mẫu hoặc luồng hành vi được định trước. Mối tương tác giữa các phần xảy ra khi cần thiết cho từng phần. Trong Hình 3, các phần tử trong tương tác cộng tác với nhau – nhưng không có khuôn mẫu hoặc bên chỉ đạo.

Hình 4 – Tổ hợp và các tầng con

Hình 4 ràng buộc các khái niệm về dịch vụ, hệ thống và tổ hợp. Các phần tử hệ thống là dịch vụ. các tác nhân, tác vụ và các hệ thống khác. Bất kỳ phần tử nào trong các phần tử này có thể thực hiện một dịch vụ. Hệ thống có thể có bất kỳ phần tử nào trong số các phần tử này như là một phần của hệ thống. Các tổ hợp là các hệ thống và do đó có thể có các bộ phận là dịch vụ, các tác nhân, tác vụ và hệ thống. Các tổ hợp có một thuộc tính cho biết tổ hợp khuôn mẫu được hỗ trợ: phối trí, dàn dựng hoặc cộng tác. Chỉ các tổ hợp mà sử dụng phối trí khuôn mẫu có một phần tử phối trí các phần của tổ hợp. Các tổ hợp và quá trình dịch vụ là các tổ hợp; do đó, có thể thể hiện bất kỳ các khuôn mẫu tổ hợp.

7.2.5.3 Tổ hợp dịch vụ

Tổ hợp dịch vụ là các tổ hợp để cung cấp (theo nghĩa vận hành) dịch vụ mức cao chỉ bao gồm các dịch vụ khác. Các tổ hợp dịch vụ có thể thể hiện một hoặc nhiều khuôn mẫu trong ba khuôn mẫu tổ hợp: phối trí, dàn dựng và cộng tác.

7.2.5.4 Quá trình

Quá trình là các tổ hợp có các phần tử được tạo thành một chuỗi hoặc luồng các hoạt động và mối tương tác với mục đích thực hiện công việc. Như trong Hình 4, quá trình có thể gồm các phần tử như các tác nhân, tác vụ, dịch vụ và quá trình. Ngoài ra, quá trình có thể thể hiện bất kỳ các khuôn mẫu tổ hợp nào.

Quá trình luôn thêm lô-gic vào thông qua khuôn mẫu sự tổ hợp; kết quả là nhiều các bộ phận hơn. Theo khuôn mẫu tổ hợp, các quá trình có thể:

– Được phối trí: Khi một quá trình được phối trí trong một hệ thống quản lý quá trình nghiệp vụ, thì kết quả của tạo tác IT trong thực tế là một phối trí; tức là có một phối trí khuôn mẫu tổ hợp. Kiểu quá trình này thường được gọi là phối trí quá trình.

– Được dàn dựng: Ví dụ, một mô hình quá trình thể hiện một khuôn mẫu xác định về hành vi. Kiểu quá trình này thường được gọi là dàn dựng quá trình.

– Cộng tác: Không có khuôn mẫu xác định (trước) về hành vi (mô hình); quá trình thể hiện hành vi được quan sát (được thi hành). (Xem Điều 8, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016)).

7.2.5.5 Quá trình nghiệp vụ

Quá trình nghiệp vụ là một tập xác định các hoạt động thể hiện các bước cần thiết để đạt được mục đích nghiệp vụ, bao gồm luồng và việc sử dụng thông tin và tài nguyên. Quá trình nghiệp vụ có thể cần được hỗ trợ bởi:

– Quản lý quá trình nghiệp vụ – các hoạt động cho phép phát hiện, lập mô hình, thi hành, thay đổi, quản trị và đạt được khả năng hiện thị từ đầu đến cuối các quá trình nghiệp vụ (xem Tài liệu tham khảo [14]);

– Giám sát hoạt động nghiệp vụ – các hoạt động giám sát các hoạt động nghiệp vụ và quá trình và sự kết hợp các SLA và các chỉ số hiệu năng chính (KPI).

7.2.6 Đăng ký và phát hiện dịch vụ

Đăng ký dịch vụ là quá trình mà các mô tả dịch vụ được tạo sẵn có cho các khách hàng dịch vụ tiềm năng. Điều này có thể được thực thi bằng cách sử dụng nhiều cơ chế khác nhau, bao gồm việc thêm mô tả dịch vụ vào một tập hợp các mô tả, lưu trữ nó trong một sổ đăng ký/kho dịch vụ cung cấp các khả năng quản lý và tìm kiếm khác hoặc làm cho nó sẵn có một cơ chế phát hiện các dịch vụ khác. Việc phát hành đơn giản các tài liệu có thể hoạt động tốt với một số lượng nhỏ dịch vụ, nhưng một sổ đăng ký/kho dịch vụ có thể tiến hành tìm kiếm khi có một số lượng lớn dịch vụ, vì nó cho phép một dữ liệu cơ sở lớn, có thể tìm kiếm được tạo ra và duy trì.

Đăng ký dịch vụ có thể yêu cầu khả năng thêm, xóa, chỉnh sửa, phân biệt và xác thực các mô tả dịch vụ và có thể được duy trì bởi các nhà cung cấp dịch vụ hoặc những người khác được chỉ định có trách nhiệm duy trì mô tả dịch vụ.

Các thuật ngữ sổ đăng ký, kho lưu trữ và hạng mục không được phân biệt. Thuật ngữ đơn lẻ, sổ đăng ký/kho dịch vụ, được sử dụng để chỉ tập hợp có tổ chức các mô tả dịch vụ và các tạo tác khác. Mô tả dịch vụ tập trung vào việc hỗ trợ đăng ký và phát hiện.

Phát hiện các dịch vụ là quá trình mà các khách hàng dịch vụ cung cấp các tiêu chí tìm kiếm, thường là về thông tin mô tả dịch vụ, để phát hiện các dịch vụ theo các yêu cầu chức năng hoặc phi chức năng cụ thể của họ. Phát hiện các dịch vụ được thực thi trong suốt thời gian thiết kế cũng như trong thời gian chạy. Trong quá trình phát hiện, một khách hàng dịch vụ có thể yêu cầu khả năng truy vấn và truy hồi các mô tả dịch vụ.

Một khách hàng dịch vụ có thể sử dụng sổ đăng ký/kho dịch vụ cho việc phát hiện các dịch vụ, thông thường, tại thời điểm thiết kế hoặc vào các thời điểm khác khi khách hàng cần tham khảo hoặc truy hồi thông tin chứa trong mô tả dịch vụ hoặc tham khảo hoặc truy vấn tạo tác dịch vụ khác là cần thiết, chẳng hạn như tìm điểm cuối dịch vụ để hỗ trợ cho việc kết thúc muộn.

Hình 5 minh họa các bước sử dụng sổ đăng ký/kho dịch vụ của khách hàng dịch vụ.

Hình 5 – Mô hình sử dụng sổ đăng ký/kho dịch vụ

Trong ví dụ ở Hình 5, khách hàng dịch vụ bắt đầu bằng đệ trình một tìm kiếm đến sổ đăng ký/kho dịch vụ: sổ đăng ký/kho dịch vụ các đáp ứng các kết quả tìm kiếm. Kết quả tìm kiếm chứa thông tin về nội dung sổ đăng ký/kho dịch vụ hợp khớp với tiêu chí tìm kiếm và các liên kết có thể có hoặc các cơ chế khác, ví dụ các cuộc gọi dịch vụ cho phép khách hàng dịch vụ truy hồi thông tin hoặc các tạo tác từ sổ đăng ký/kho. Ví dụ này minh họa khách hàng dịch vụ như việc tiêu thụ cả thông tin về tạo tác và bản thân các tạo tác của họ.

Như lưu ý với Hình 5, đăng ký/các kho lưu trữ không bị giới hạn chỉ để lưu trữ các mô tả dịch vụ nếu chúng hỗ trợ các khả năng khác trong giải pháp SOA, như các kiến trúc, quản lý và quản trị thông tin. Về kiến trúc, đăng ký/các kho lưu trữ có thể coi khác nhau trong một giải pháp SOA, nhưng trong khi thực hiện đăng ký/các kho lưu trữ này có thể được thu thập trong cùng một đăng ký/ kho lưu trữ, tận dụng các khía cạnh chung của mô tả và phát hiện, lưu trữ và truy hồi. Đăng ký/các kho lưu trữ hỗ trợ quản trị có thể truy nhập vào các chính sách quản trị và tài liệu của các quá trình truyền thông và thực thi; các mô tả dịch vụ có thể liên kết đến các chính sách và quá trình có liên quan đến dịch vụ cụ thể.

Đăng ký/các kho lưu trữ dịch vụ được quản trị và thường được sử dụng bởi các quá trình quản trị. Ví dụ, một quá trình quản trị để tối đa hóa việc sử dụng lại dịch vụ có thể yêu cầu các kiến trúc sư và nhà phát triển giải pháp tìm kiếm dịch vụ phù hợp hiện có trước khi phát triển các dịch vụ mới. Sử dụng lại khả năng tác động, trong trường hợp này, yêu cầu dịch vụ được mô tả rõ ràng và các mô tả đó sẵn có cho các nhà phát triển.

Quản lý đăng ký/các kho lưu trữ và đăng ký các quá trình được khuyến nghị và có thể bao gồm giám sát, quản lý lưu trữ, sao lưu, phục hồi và thông báo về các ngoại lệ và lỗi.

7.2.7 Mô tả, giao diện, chính sách và hợp đồng dịch vụ

7.2.7.1 Mô tả dịch vụ

Mô tả dịch vụ chứa thông tin cần thiết để tương tác với dịch vụ và có thể được mô tả trong các điều khoản như giao diện dịch vụ (đầu vào, đầu ra dịch vụ và các ngữ nghĩa liên quan) và các chính sách dịch vụ (các điều kiện sử dụng dịch vụ). Các hợp đồng dịch vụ có thông tin tham khảo trong các mô tả dịch vụ.

Mục đích của việc kết hợp các giao diện dịch vụ và các chính sách dịch vụ trong mô tả dịch vụ tổ hợp là tạo thuận lợi cho sự tương tác và khả năng hiển thị, đặc biệt là khi các bên tham gia ở các miền sở hữu khác nhau (xem Tài liệu tham khảo [17] giải thích về quyền sở hữu). Các mô tả dịch vụ rõ ràng cung cấp thông tin cần thiết để biết dịch vụ nào, điều kiện sử dụng là gì, kinh nghiệm người sử dụng trong quá trình tương tác, chi tiết trao đổi thông tin và vị trí nơi trao đổi thông tin xảy ra. Nó làm cho các bên tham gia tiềm năng có thể xây dựng các hệ thống theo các mô tả và không thực hiện.

Mô tả dịch vụ cho phép các khách hàng dịch vụ tiềm năng đánh giá liệu dịch vụ có phù hợp với nhu cầu hiện tại của họ và thiết lập liệu khách hàng dịch vụ có đáp ứng mọi yêu cầu của nhà cung cấp dịch vụ hay không.

7.2.7.2 Giao diện dịch vụ

Mô tả dịch vụ có thể gồm các giao diện dịch vụ, điều khoản hợp đồng và chính sách. Do đó, các giao diện dịch vụ, điều khoản hợp đồng và chính sách phải được định trước khi xác định mô tả dịch vụ. Các giao diện dịch vụ xác định cách thức các phần tử khác có thể tương tác và trao đổi thông tin với một dịch vụ trong xử lý yêu cầu dịch vụ (xem 7.13, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016)). Các giao diện bao gồm định nghĩa về các tham số được sử dụng để truyền thông tin khi một dịch vụ được gọi. Điều này thường được ghi lại trong mô tả dịch vụ.

Bản chất của cách một giao diện được gọi ra và cách thông tin được truyền trở lại khác nhau giữa các lĩnh vực nghiệp vụ. Các giao diện dịch vụ điển hình, nhưng không nhất thiết phải dựa trên thông điệp (để hỗ trợ nối kết lỏng). Hơn nữa, các giao diện dịch vụ luôn được xác định tự bao gồm với bất kỳ việc triển khai các dịch vụ nào (để hỗ trợ nối kết lỏng và điều chỉnh dịch vụ).

Bất kỳ dịch vụ nào cũng có ít nhất một giao diện dịch vụ. Có thể có các ràng buộc về tương tác được phép trên một giao diện dịch vụ như phạm vi giá trị nhất định chỉ được phép trên các thông số nhất định. Trong thực tế, tùy thuộc vào bản chất của dịch vụ và giao diện dịch vụ được đề cập, các ràng buộc này có thể được xác định chính thức (được tài liệu hóa) hoặc không chính thức (không có giấy tờ). Các ràng buộc phải được ghi lại và được xác định chính thức.

Một giao diện dịch vụ đơn có thể được sử dụng như một giao diện đa dịch vụ. Điều này không có nghĩa là dịch vụ này giống nhau, thậm chí chúng không có khả năng tác động giống nhau; nó chỉ có nghĩa là có thể tương tác với tất cả chúng theo cách thức được xác định bởi giao diện dịch vụ. Điều này cũng đòi hỏi rằng ngữ nghĩa của tác vụ được tôn trọng bởi tất cả các giao diện triển khai các dịch vụ.

Hình 6 – Nhà cung cấp dịch vụ và khách hàng dịch vụ sử dụng giao diện dịch vụ

Trong Hình 6, các nhà cung cấp dịch vụ và khách hàng dịch vụ tương tác qua các phần tử truyền thông sử dụng các giao diện dịch vụ, phần tử 2 trong khách hàng dịch vụ gửi một yêu cầu dịch vụ đến giao diện dịch vụ cho phần tử 1 trong nhà cung cấp dịch vụ và phần tử 1 thực thi chức năng phù hợp và gửi một đáp ứng dịch vụ (phù hợp với đáp ứng xác định giao diện dịch vụ) trở lại với phần tử 2.

7.2.7.3 Chính sách

Chính sách là một tập các tuyên bố pháp lý, chính trị, tổ chức, chức năng hoặc kỹ thuật về mục đích hoặc nghĩa vụ truyền thông và hợp tác. Như trong Hình 7, chính sách được tạo ra và được xác nhận bởi một tác nhân và cam kết duy trì và, nếu muốn hoặc cần thiết, thực thi. Một tác nhân xác nhận một chính sách; tuy nhiên, một chính sách có thể cung cấp một qui định cho bất kỳ tác nhân, có con người hoặc không có con người.

Hình 7 – Chính sách và các tập chính sách con

Chính sách như một khái niệm chung và có sự liên quan ngoài miền SOA. Các chính sách có thể áp dụng cho các sự vật khác phần tử (các đối tượng chính sách); trên thực tế, các chính sách có thể áp dụng cho bất kỳ điều gì, bao gồm các chính sách khác.

Chính sách là một khẳng định (tuyên bố ý định) có thể được tuyên bố và sau đó áp dụng cho bất kỳ số lượng đối tượng chính sách nào. Ví dụ, một chính sách có thể nói rằng tất cả các truyền thông với một dịch vụ SOA phải được mã hóa và sau đó xác nhận đơn nhất đó được áp dụng cho (và sự phù hợp có thể được đánh giá) mọi truyền thông với mọi dịch vụ. Một tác nhân khẳng định một chính sách có trách nhiệm thực thi thông qua hành động trực tiếp hoặc trách nhiệm được giao. Lưu ý rằng có chính sách áp dụng cho nhiều đối tượng không có nghĩa là các đối tượng này giống nhau, chúng chỉ (một phần) được điều chỉnh bởi cùng một mục đích. Ngược lại, một hoặc nhiều chính sách có thể được áp dụng cho bất kỳ đối tượng nào nào. Lưu ý rằng khi nhiều chính sách áp dụng cho cùng một đối tượng, điều này thường là do nhiều chính sách là từ nhiều miền chính sách khác nhau (chẳng hạn như bảo mật và quản trị).

Biết các chính sách áp dụng cho điều gì khiến dễ dàng và minh bạch hơn khi tương tác với chính sách đó. Các chính sách, tác nhân con người xác định các chính sách và các đối tượng mà chính sách áp dụng là các khía cạnh quan trọng của bất kỳ hệ thống nào và đặc biệt cho các hệ thống SOA với các phần tử tương tác khác nhau của chúng.

Từ quan điểm thiết kế, các chính sách có thể có nhiều phần chi tiết hơn hoặc có thể được thể hiện và hoạt động thông qua các quy tắc cụ thể.

Các chính sách khác với dịch vụ hợp đồng (được thảo luận chi tiết hơn trong 7.2.7.3). Trong khi chính sách được tuyên bố bởi tác nhân, một hợp đồng là một cam kết được thực thi bởi hai hoặc nhiều tác nhân (các bên ký kết hợp đồng) trên một tập các điều kiện (hoặc điều khoản hợp đồng) cùng với một tập các ràng buộc quản trị hành vi và/hoặc trạng thái trong việc hoàn thành các điều kiện đó. Những điều kiện và ràng buộc đó là cơ sở để đánh giá liệu các bên có phù hợp với các điều khoản của hợp đồng hay không.

Các chính sách có thể được tuyên bố bởi một nhà cung cấp dịch vụ như là điều kiện sử dụng mặc định cho một dịch vụ. Như trong Hình 7, mô tả dịch vụ là một nơi có khả năng nắm bắt các chính sách như vậy, có thể nêu chính sách trong mô tả nhưng có nhiều khả năng như một tham khảo đối với một tuyên bố bên ngoài chính sách. Một khách hàng dịch vụ cũng có thể nêu rõ các chính sách và dịch vụ hợp tác phục vụ như một nghị quyết về mâu thuẫn trong các chính sách đã nêu. Một chính sách mặc định có thể được tuyên bố hoặc tham khảo trong một dịch vụ mô tả bởi vì nó là một ràng buộc như được nêu bởi một bên – nhà cung cấp dịch vụ – và có thể áp dụng cho một chủ đề chính sách cụ thể – dịch vụ đó. Một dịch vụ hợp đồng, mặt khác, có thể được cụ thể cho các nhà cụ thể cung cấp các dịch vụ và dịch vụ khách hàng; nó thường không thể áp dụng cho dịch vụ và có thể có tính chất độc quyền giữa nhà cung cấp dịch vụ và khách hàng dịch vụ. Do đó, các hợp đồng dịch vụ phải không được bao gồm trong mô tả dịch vụ.

Trong khi các chính sách có thể áp dụng đối với các hợp đồng dịch vụ, chẳng hạn như các chính sách an toàn cho những người có thể thay đổi một hợp đồng dịch vụ đã có hoặc ngược lại được giới thiệu bởi các hợp đồng dịch vụ như một phần của các điều khoản, điều kiện và các quy tắc tương tác mà các bên tham gia tương tác đồng ý, các hợp đồng dịch vụ bản thân chúng không phải chính sách vì chính sách mô tả ý định của ít nhất một bên và hợp đồng là cam kết giữa nhiều bên.

7.2.7.4 Hợp đồng dịch vụ

Hợp đồng dịch vụ là tập các điều khoản, điều kiện và quy tắc tương tác mà các bên tham gia tương tác thỏa thuận (trực tiếp hoặc gián tiếp). Đây là bắt buộc đối với tất cả các bên tham gia trong tương tác: cả thể hiện lô-gic và vật lý của các khách hàng dịch vụ, nhà cung cấp dịch vụ và bản thân dịch vụ. Hợp đồng dịch vụ có thể bao gồm các cam kết cụ thể để xác định cách điều chỉnh sử dụng dịch vụ hoặc để đảm bảo tương tác dịch vụ xảy ra trong một chuỗi nhất định.

Tất cả các bên tham gia tương tác với một dịch vụ cần phải phù hợp với các khía cạnh tương tác của tất cả các hợp đồng dịch vụ áp dụng tương tác đó. Khía cạnh tương tác vận hành của một hợp đồng dịch vụ khác với ký hiệu của một giao diện dịch vụ trong đó một hợp đồng dịch vụ không tự xác định các giao diện dịch vụ, mà là nó xác định bất kỳ đa tương tác nào liên quan và/hoặc ràng buộc trình tự về cách sử dụng dịch vụ thông qua tương tác trên tập các giao diện dịch vụ của nó. Như một ví dụ đơn giản, một dịch vụ thanh toán có thể có một hợp đồng dịch vụ cho biết một khoản thanh toán phải được tạo trước khi nó có thể được theo dõi.

Hợp đồng dịch vụ qui định rõ ràng cả hai khía cạnh tương tác vận hành, ví dụ: các thỏa thuận dịch vụ (SLA) và các khía cạnh cam kết pháp lý về sử dụng dịch vụ. Có thể tách sự tương tác và các khía cạnh pháp lý thành hai hợp đồng dịch vụ khác nhau, tùy thuộc vào nhu cầu của ứng dụng. Các cam kết pháp lý có thể áp dụng cho một số tác nhân nhất định và việc sử dụng dịch vụ của họ. Các nghĩa vụ pháp lý thực tế đối với từng tác nhân này được xác định trong hợp đồng dịch vụ, bao gồm, ví dụ, nhà cung cấp, người tiêu dùng là ai từ một quan điểm nghĩa vụ pháp lý.

Tác nhân nhất định có thể là bên tham gia từ không hoặc nhiều hợp đồng dịch vụ. Tương tự như vậy, một hợp đồng dịch vụ nhất định có thể liên quan đến không hoặc nhiều tác nhân. Lưu ý rằng điều quan trọng là phải cho phép tìm kiếm hợp đồng khi có cam kết pháp lý giữa tác nhân A và tác nhân B (cả hai đều là bên tham gia hợp đồng dịch vụ), nhưng tác nhân B được xuất phát từ việc triển khai các dịch vụ đối với tác nhân C (còn gọi là tác nhân C triển khai các dịch vụ được đề cập, chứ không phải tác nhân B).

Lưu ý rằng các hợp đồng dịch vụ có thể (trong phần hợp pháp của chúng) thể hiện các khía cạnh thời gian như “có nghĩa vụ tại thời điểm này”, “có nghĩa vụ” và “có nghĩa vụ trong tương lai”.

Như trong Hình 8, điều quan trọng là phải phân biệt giữa một mô tả dịch vụ và một hợp đồng dịch vụ. Một mô tả dịch vụ nắm bắt sự thật của một dịch vụ tự bao gồm với bất kỳ sự tương tác cụ thể nào, một hợp đồng dịch vụ nắm bắt các điều kiện qui định một tập nhất định các nhà cung cấp dịch vụ, các khách hàng dịch vụ và có thể bên thứ ba quan tâm khác, như các nhà quản lý. Trong các sự kiện mô tả một dịch vụ có thể được phân phối giữa các tạo tác riêng biệt, tập được thu thập các sự kiện phải bao gồm một mô tả nhất quán hợp lý. Ngược lại, các hợp đồng dịch vụ được điều chỉnh cho phù hợp với các bên tham gia tương tác dịch vụ và do đó, bất kỳ số lượng hợp đồng dịch vụ nào có thể được liên kết với một dịch vụ nhất định. Một mô tả dịch vụ có thể cung cấp các điều kiện mặc định cho một hợp đồng dịch vụ, như hiệu năng mặc định, trong khi một hợp đồng dịch vụ có thể qui định nhiều hoặc ít hơn các mục đích hiệu năng nghiêm ngặt.

Hình 8 – Mối quan hệ hợp đồng dịch vụ

7.2.8 Vòng đời giải pháp SOA và dịch vụ

7.2.8.1 Vòng đời dịch vụ

Vòng đời dịch vụ gồm các hoạt động, vai trò và sản phẩm công tác chỉ cho dịch vụ. Điều này thường là mở rộng vòng đời phát triển phần mềm của tổ chức. Ngược lại, vòng đời giải pháp SOA giải quyết một phạm vi lớn hơn nhiều, tức là toàn bộ giải pháp định hướng dịch vụ cung cấp giá trị cho tổ chức. Những dịch vụ nào phải được phát triển được xác định bởi danh mục giải pháp SOA và trong suốt vòng đời giải pháp SOA.

Như trong Hình 9 (chu kỳ tiến trình theo chiều kim đồng hồ), vòng đời dịch vụ có thể bao gồm:

a) Phân tích và thiết kế – có thể bao gồm quản lý các yêu cầu, định nghĩa dịch vụ, lập kế hoạch triển khai các dịch vụ. Vòng đời có thể bắt đầu với một phân tích xác định dịch vụ nào nên có trong danh mục dịch vụ và thúc đẩy giá trị nghiệp vụ, còn được gọi là định danh dịch vụ.
b) Sáng tạo – bao gồm lập mô hình dịch vụ, việc triển khai các dịch vụ, thử nghiệm dịch vụ. Điều này bao gồm thiết kế việc triển khai các dịch vụ và phát triển việc triển khai các dịch vụ mã hóa các thành phần hỗ trợ khác.
c) Thu thập và triển khai – có thể bao gồm việc ghép nối hoặc mua lại dịch vụ, triển khai các dịch vụ, cấu hình dịch vụ, xuất bản các dịch vụ. Giai đoạn này bao gồm việc ghép nối các thành phần, dịch vụ và các tạo tác để cho phép triển khai. Sau khi phát triển tất cả các phần tử này, việc triển khai các dịch vụ vào các hệ thống vận hành của một nhà cung cấp dịch vụ có thể được thực thi. Tại thời điểm này, nó có thể được khởi tạo để việc thể hiện dịch vụ sẵn sàng tương tác với một khách hàng dịch vụ.
d) Quản trị và quản lý – có thể bao gồm quản lý dịch vụ và giám sát, hỗ trợ dịch vụ, dừng dịch vụ, quản lý dịch vụ.

Khi dịch vụ đã chuyển sang giai đoạn hoạt động, các số liệu nghiệp vụ chính, số liệu hiệu năng và tính sẵn có cần được theo dõi. Các kết quả giám sát được sử dụng trong bảng điều khiển, thực thi SLA, thanh toán, các quá trình quản trị, v.v. Trong giai đoạn vận hành này, dịch vụ có thể được cấu hình hoặc cấu hình lại, cố định nếu nó gặp trục trặc hoặc cải thiện nếu các yêu cầu nghiệp vụ thay đổi.

Các quá trình vòng đời dịch vụ cần được quản lý và quản trị, đặc biệt là quản trị các dịch vụ, quản lý chính sách, quản lý các yêu cầu và quá trình quản lý cấu hình. Việc triển khai các dịch vụ tài sản và sổ đăng ký/kho thường được sử dụng để quản lý và quản trị vì chúng cung cấp quyền truy nhập vào một số danh mục tài sản cần thiết để hỗ trợ vòng đời và quản lý. Các tài sản này bao gồm thực thi dịch vụ, các quá trình, các tài liệu. v.v.

Hình 9 – Ví dụ vòng đời dịch vụ

7.2.8.2 Vòng đời giải pháp SOA

Vòng đời giải pháp mô tả các hoạt động, vai trò và sản phẩm công tác khi liên quan đến việc cung cấp các giải pháp nghiệp vụ dựa trên SOA.

Vòng đời giải pháp SOA có thể bắt đầu với việc lập mô hình nghiệp vụ (nắm bắt thiết kế nghiệp vụ) bao gồm các chỉ số hiệu năng chính của các mục đích và mục đích nghiệp vụ, ghép nối và tịnh tiến mô hình vào thiết kế hệ thống thông tin, việc triển khai hệ thống thông tin đó, quản lý việc triển khai đó và sử dụng các kết quả ra khỏi môi trường đó để xác định các cách để tinh chỉnh thiết kế nghiệp vụ. Đó là tiền đề trong vòng đời mà đáp ứng được chuyển động đến và từ các giai đoạn trong các bước lặp lại của sự tinh chỉnh để tạo thuận lợi cho nhu cầu nghiệp vụ.

Vòng đời sau đó được phân tầng trên nền tảng của một bộ các quá trình quản trị SOA đảm bảo tuân thủ và các chính sách vận hành được thực thi cho giải pháp và thay đổi đó xảy ra theo một kiểu được kiểm soát và với quyền hạn thích hợp như được hình dung bởi thiết kế nghiệp vụ.

Như trong Hình 10 (theo tiến trình chiều kim đồng hồ), bốn giai đoạn trong vòng đời giải pháp SOA có thể như sau.

– Mô hình – Việc lập mô hình là quá trình thu thập thiết kế nghiệp vụ cho giải pháp SOA từ sự hiểu biết về các yêu cầu và mục đích nghiệp vụ và tịnh tiến thành đặc tính kỹ thuật của các các quá trình nghiệp vụ, các mục đích và các giả định, tạo mô hình mã hóa nghiệp vụ, cùng với các chỉ số hiệu năng chính.

– Ghép nối – Việc ghép nối sử dụng thiết kế nghiệp vụ để ghép nối các tạo tác phải triển khai thiết kế nghiệp vụ cho giải pháp SOA. Thiết kế nghiệp vụ có thể được chuyển đổi thành một tập các định nghĩa quá trình nghiệp vụ và các hoạt động tạo ra dịch vụ cần thiết và từ các định nghĩa hoạt động.

– Triển khai – Triển khai bao gồm một sự kết hợp tạo môi trường lưu trữ cho các giải pháp SOA và triển khai thực tế các giải pháp đó. Điều này bao gồm việc giải quyết các phụ thuộc tài nguyên của giải pháp SOA, các điều kiện vận hành, các các điều kiện, yêu cầu về khả năng và các ràng buộc về tính toàn vẹn và truy nhập. Ngoài ra, các kỹ thuật cho phép tính sẵn có độ tin cậy, tính toàn vẹn, khả năng tác động và khả năng phục vụ cần được xem xét cho giải pháp SOA.

– Quản trị và quản lý – Quản trị và quản lý xem xét cách duy trì môi trường hoạt động và các chính sách thể hiện trong việc ghép nối các giải pháp SOA được triển khai cho môi trường đó. Điều này bao gồm giám sát hiệu năng các yêu cầu dịch vụ và tính kịp thời của các đáp ứng dịch vụ, duy trì các bản ghi lỗi để phát hiện lỗi trong các thành phần hệ thống khác nhau, phát hiện và bản địa hóa những lỗi đó, định tuyến xung quanh chúng, phục hồi công việc bị ảnh hưởng bởi những lỗi đó, sửa lỗi và khôi phục lại trạng thái hoạt động của hệ thống.

Hình 10 – Vòng đời giải pháp SOA

Tiến trình xuyên suốt vòng đời không hoàn toàn tuyến tính. Ví dụ, các thay đổi đối với thông tin hiệu năng chính trong giai đoạn mô hình thường cần phải được nạp trực tiếp vào giai đoạn quản lý để cập nhật môi trường hoạt động. Các ràng buộc trong giai đoạn triển khai, chẳng hạn như hạn chế các giả định về vị trí đặt tài nguyên trong hệ thống, có thể điều kiện một số quyết định giai đoạn ghép nối. Các ràng buộc công nghệ thông tin được thiết lập trong giai đoạn ghép nối có thể hạn chế thiết kế nghiệp vụ được tạo ra trong giai đoạn mô hình.

7.2.8.3 Mối quan hệ dịch vụ và vòng đời giải pháp SOA

Các ý tưởng xung quanh dịch vụ và giải pháp SOA là sự bổ sung và gắn bó với nhau. Thường xem xét dịch vụ SOA như là các khối xây dựng giải pháp SOA, nhưng các giải pháp đó đưa ra dịch vụ và kết hợp thành các giải pháp khác. Rõ ràng, hai vòng đời liên quan chặt chẽ; vòng đời các giải pháp SOA cung cấp một bối cảnh cho vòng đời dịch vụ SOA. Hai vòng đời theo các giai đoạn chung cho phần mềm, tức là phân tích các yêu cầu, thiết kế, phát triển, triển khai, vận hành và hủy bỏ. Tuy nhiên, mục đích của mỗi giai đoạn là rất khác nhau. Vòng đời dịch vụ tập trung vào chính bản thân dịch vụ, nơi mà giải pháp bao gồm các khía cạnh nghiệp vụ và các quan hệ giữa dịch vụ, hệ thống vận hành và hỗ trợ các khía cạnh. Như trong Hình 11, cũng giống như các giải pháp là một bối cảnh cho vòng đời dịch vụ, phương pháp sức sống quản trị là một bối cảnh cho các giải pháp vòng đời.

Hình 11 – Mối quan hệ giữa dịch vụ, giải pháp SOA và vòng đời quản trị giải pháp SOA

Như với bất kỳ vòng đời, các vai trò, trách nhiệm và các sản phẩm công tác cần phải được xác định. Việc sử dụng các nguyên tắc và khái niệm SOA hàm ý:

– Mối quan hệ liên tục giữa các vai trò của nhà cung cấp dịch vụ và khách hàng dịch vụ,

– Các mô tả giải pháp và dịch vụ chính xác và được cập nhật,

– Các số liệu đầy đủ để hiểu rõ về hiệu năng và sự thiết lập các kỳ vọng khi sử dụng tổng thể phát triển và trưởng thành, và

– lập mô hình hệ sinh thái SOA để dự đoán và đáp ứng để phát triển và tiến hóa.

Một sự cân nhắc quan trọng như một tiến trình trong vòng đời mà dịch vụ và giải pháp tồn tại trong hệ sinh thái SOA và có thể đồng thời hỗ trợ các nhu cầu của nhiều khách hàng dịch vụ. Do đó, trong khi các vấn đề hiệu năng riêng lẻ là quan trọng và cần được xem xét, khi trọng tâm là tối ưu hóa toàn bộ, thì có thể cần phải cân nhắc các giao dịch để dịch vụ hoặc giải pháp riêng lẻ có thể chạy tối ưu. Mặc dù hiểu biết về tối ưu hóa nội vùng là quan trọng, một phương pháp tiếp cận SOA phải giới thiệu các giao dịch phức tạp hơn, làm cho mô hình trở nên thiết yếu hơn.

7.2.9 Nối kết lỏng

Nói chung, nối kết lỏng được thực thi bằng cách giảm sự phụ thuộc giữa các phần tử trong một hệ thống. Ví dụ, nối kết lỏng dịch vụ được cải thiện khi tiêu thụ dịch vụ được cách ly khỏi triển khai cơ bản, thường là thông qua việc sử dụng các giao diện dịch vụ, chính sách truy nhập và khả năng phát hiện các dịch vụ. Ngoài ra, nối kết lỏng giao diện dịch vụ có thể được cải thiện bằng cách trao đổi toàn bộ tài liệu bán cấu trúc. Thông thường, điều này cho phép nhiều thay đổi trong các chi tiết trao đổi thông tin hơn thủ tục gọi các trao đổi kiểu dáng.

Khi khách hàng dịch vụ hoàn toàn tin cậy các tiêu chuẩn dựa trên mô tả dịch vụ được coi như “hợp đồng” giữa khách hàng và người cung cấp, nhiều cách biệt được cung cấp. Các kiểu cách biệt này loại bỏ sự phụ thuộc của các ngôn ngữ lập trình, nền tảng hoặc bất kỳ quy ước nhà cung cấp đặc biệt nào như sắp xếp thời gian, ràng buộc địa chỉ, ngôn ngữ truy nhập hoặc giao thức truy nhập.

Kiểu kiến trúc hướng dịch vụ (SOA) hỗ trợ nối kết lỏng giao diện của một dịch vụ đang được tiêu thụ từ thực thi được cung cấp. Việc trao đổi thông điệp phải được xác định rõ nhưng vẫn cung cấp các cơ chế nguyên tắc cho các biến đổi về đầu vào và khả năng mở rộng.

Nối kết lỏng thể hiện sự công nhận tính biến thiên và tính linh hoạt và cho phép sử dụng lại và mạnh mẽ khi kết hợp theo hướng dịch vụ.

7.3 Mối quan tâm xuyên suốt

7.3.1 Xác định việc xuyên suốt

Các khía cạnh xuyên suốt là các khả năng và chức năng hợp lệ và áp dụng cho nhiều vai trò hoặc các tầng chức năng. Ví dụ, quản lý là một mối quan tâm xuyên suốt bởi vì nó áp dụng cho nhiều lĩnh vực, bao gồm cả các hệ thống vận hành, dịch vụ, các quá trình nghiệp vụ và các khách hàng dịch vụ. Tất cả những điều này cần được quản lý, nhưng cách quản lý khác nhau dựa trên mục đích quản lý. Việc quản lý hạ tầng như lưu trữ và cơ sở dữ liệu rất khác với việc quản lý các quá trình nghiệp vụ. Các khía cạnh xuyên suốt có thể áp dụng các khía cạnh xuyên suốt, do đó quản trị được áp dụng cho các tầng chức năng cũng như tích hợp, thông tin và quản lý.

Các khía cạnh xuyên suốt quan trọng cho SOA như sau.

7.3.2 Sự tích hợp

Sự tích hợp là một khía cạnh trung tâm của thiết kế và phát triển các giải pháp SOA vì thường có mối tương tác chéo giữa miền dịch vụ và giải pháp cần quan tâm. Việc cài đặt SOA phức hợp có thể đạt được trên toàn bộ đơn vị nghiệp vụ và ranh giới đối tác và sự tích hợp được sử dụng để tận dụng dịch vụ hiện có, cũng như kết hợp dịch vụ mới quan các miền dịch vụ. Sự tích hợp các khía cạnh và hỗ trợ các công nghệ cần được xác định ngay cả khi tương tác dịch vụ đơn giản hơn và trong một miền.

7.3.3 Sự tương tác miền chéo

Việc phát hiện và quản lý dịch vụ có thể cần phải trải rộng các miền giải pháp khác nhau trong một tổ chức hoặc giữa các tổ chức. Ngoài ra, việc phát hiện và quản lý có thể phải làm việc trên các công nghệ khác nhau vì các miền giải pháp khác nhau có thể đã chọn các phương tiện khác nhau để thực thi SOA của chúng.

Hình 12 là một ví dụ là một ví dụ cho thấy một số miền giải pháp, mỗi miền được triển khai với công nghệ riêng của mình, nơi mối tương tác giữa chúng cần được quản lý như một tổng thể.

Hình 12 – Sự tương tác miền chéo

Cả hạ tầng SOA miền giải pháp đơn lẻ và hạ tầng SOA liên kết không đồng nhất giải quyết việc quản lý các khía cạnh xuyên suốt, đặc biệt là việc phát hiện hiện dịch vụ, quản lý dịch vụ, an toàn dịch vụ và quản trị các dịch vụ.

Tùy thuộc vào bối cảnh nghiệp vụ hoặc kỹ thuật của khách hàng dịch vụ, dịch vụ tương tự có thể sẵn có từ các nhà cung cấp khác nhau bên trong và bên ngoài tổ chức, cũng như thông qua các công nghệ khác nhau. Dịch vụ này cụ thể hóa các điểm cuối có thể nằm trong các miền dịch vụ khác nhau. Chức năng tích hợp và sổ đăng ký/kho liên quan, trong miền dịch vụ của khách hàng để tìm kiếm và sử dụng (ràng buộc) việc triển khai các dịch vụ khác nhau này đơn giản hơn.

7.3.4 Sự tích hợp dịch vụ

Sự tích hợp dịch vụ là rất quan trọng vì nó cung cấp khả năng làm trung gian, chuyển đổi, định tuyến và vận chuyển các yêu cầu dịch vụ từ việc triển khai các dịch vụ đúng. Sự tích hợp dịch vụ có thể bao gồm định tuyến thông minh, chuyển đổi giao thức và các cơ chế chuyển đối tác vụ thường được xem trong bus dịch vụ. Chức năng tích hợp trong Hình 12 cho phép nối kết lỏng giữa yêu cầu và nhà cung cấp cụ thể hóa bằng cách đáp ứng yêu cầu dịch vụ và triển khai các dịch vụ.

Sự nối kết lỏng này không chỉ là một sự nối kết lỏng kỹ thuật giải quyết các giao thức, các vị trí hoặc các nền tảng, mà còn có thể là một ngữ nghĩa nghiệp vụ nối kết lỏng thực thi thích ứng yêu cầu giữa người yêu cầu dịch vụ và nhà cung cấp dịch vụ.

Ý nghĩa của việc nối kết lỏng và tính không đồng nhất trên thực tế của các tổ chức thúc đẩy sự cần thiết phải quản lý dễ dàng hơn dịch vụ và các tạo tác tương ứng. Ba khía cạnh tích hợp cần được xem xét là vận chuyển, chuyển đổi và hòa giải.

– Vận chuyển – Một thông điệp bắt nguồn từ một người gửi phải có thể tiếp cận được người nhận dự định. Điều này được thực thi thông qua việc sử dụng một hạ tầng vận chuyển cung cấp các giao thức cần thiết để truyền tải thông diệp giữa hai phương thức này. Người gửi và người nhận có thể được kết nối với một hạ tầng vận chuyển chung hoặc cầu nối phải là cần thiết giữa hạ tầng tương ứng của chúng. Cầu nối này có thể yêu cầu các dịch chuyển giao thức cũng như nhu cầu cung cấp định tuyến và tương quan các thông điệp giữa các điểm cuối.

– Chuyển đổi – Người gửi và người nhận phải có sự hiểu biết chung về nội dung thông điệp. Điều này có thể yêu cầu một chuyển đổi giữa các khuôn dạng trình bày nội dung hoặc giữa các từ vựng để căn chỉnh ngữ nghĩa cục bộ. Một ví dụ ở đây là nơi một điểm cuối sử dụng một phiên bản khác của khuôn dạng dữ liệu với các trường bổ sung, do đó, các trường bổ sung cần được loại bỏ để thông điệp được chấp nhận ở phía bên kia.

– Dàn xếp – Khi tích hợp các quá trình, không phải lúc nào cũng có một thông điệp tại bên tương đương với một thông điệp đơn nhất ở bên kia. Hai bên có thể ở các mức trừu tượng khác nhau, với một thông điệp dẫn đến việc loại khỏi nhiều thông điệp, với sự cần thiết phải kết hợp các đáp ứng vào một câu trả lời đơn nhất. Dàn xếp khả năng kết hợp tích hợp vận chuyển và chuyển đổi sự với các khuôn mẫu tích hợp quá trình phức tạp.

7.3.5 Quản lý và an toàn

7.3.5.1 Qui định chung

Mối quan tâm về quản lý và an toàn là một khía cạnh quan trọng đối với SOA và cung cấp các cách xử lý các yêu cầu phi chức năng (NFR) trong bất kỳ giải pháp đã cho nào. Điều này cung cấp các phương tiện kỹ thuật cho phép một giải pháp SOA đáp ứng các yêu cầu liên quan đến: giám sát, độ tin cậy, tính sẵn có, khả năng quản lý, khả năng giao dịch, khả năng duy trì, khả năng mở rộng, an toàn, an toàn, vòng đời, v.v. Nó bao gồm phạm vi của FCAPS truyền thống (lỗi, cấu hình, tài khoản, hiệu năng, an toàn) từ ITIL hoặc RAS (độ tin cậy, tính sẵn có, khả năng phục vụ).

Các khía cạnh chung về quản lý có thể cần thiết để hỗ trợ cần được hỗ trợ và quản lý là các giao dịch, tính sẵn có, độ tin cậy dịch vụ, quản lý siêu dữ liệu và dịch vụ quản lý.

Giao dịch phối hợp các hành động của dịch vụ đối với các tài nguyên có thể thuộc về các thành phần được phân phối khi các thành phần này được yêu cầu đạt cam kết nhất quán về đầu ra của tương tác dịch vụ. Người quản lý giao dịch thường phối hợp đầu ra trong khi ẩn các chi tiết của từng thành phần dịch vụ phối hợp và công nghệ triển khai các dịch vụ. Với cách tiếp cận đó, một ngữ nghĩa giao dịch phổ biến và chuẩn hóa có thể được sử dụng trên dịch vụ. Hai loại giao dịch là đơn vị (thường là ngắn hạn và hồi phục khi không thành công) và các giao dịch hoạt động nghiệp vụ (thường là dài hạn với các khoản bù trừ được xác định trong trường hợp thất bại). Xem Phụ lục B để biết thêm thông tin về các giao dịch trong các giải pháp SOA.

– Tính sẵn có bao gồm cả ở dịch vụ SOA và giải pháp SOA. Tính sẵn có của một giải pháp SOA là phần trăm thời gian mà giải pháp đang thực thi chức năng nghiệp vụ một cách thích hợp. Để đo lường điều này, điều quan trọng là phải xác định và giám sát các chỉ số hiệu năng chính cho giải pháp nói chung. Việc đo lường tính tính sẵn có của từng dịch vụ phải không bác phản ánh sẵn có và thực thi chức năng nghiệp vụ. Tính sẵn có của dịch vụ được gắn với phần trăm thời gian mà một dịch vụ có thể được gọi thành công.

Tính sẵn có của dịch vụ có thể được gắn với một nhà cung cấp, mạng và ranh giới khách hàng dùng, kiểm tra xem dịch vụ, hệ thống và mạng có đang hoạt động hay không. Tính sẵn có của dịch vụ khác với các ranh giới khác. Thông thường, tính sẵn có của dịch vụ có thể được đo bằng hạ tầng và công cụ thay mặt cho dịch vụ và số liệu được cung cấp là phổ biến, tức là phần trăm trên thời gian và số lượng các thông điệp thất bại. Tính sẵn có của dịch vụ thường là số liệu chính trong các các kết mức dịch vụ, các chính sách và các hợp đồng.

Trong khi tính sẵn có liên quan đến việc liệu một dịch vụ có hoạt động, nâng cấp và chạy và có thể xử lý các yêu cầu hay không, thì độ tin cậy liên quan đến việc đảm bảo yêu cầu và đáp ứng các thông điệp tin được gửi đi. Mặt khác, độ tin cậy liên quan đến việc phân phối thông điệp giữa khách hàng dịch vụ và nhà cung cấp dịch vụ, nó không giải quyết liệu một yêu cầu có thực sự được xử lý hay không bởi nhà cung cấp. Các giao dịch giải quyết xem một yêu cầu được xử lý hay không.

a) Độ tin cậy, trong bối cảnh SOA, là một chất lượng dịch vụ hướng vào mối tương tác giữa một khách hàng dịch vụ và một nhà cung cấp dịch vụ và được sử dụng để chỉ ra các mức độ đảm bảo khác nhau về các trung gian và mạng được gọi trao đổi các thông điệp trong suốt các cuộc gọi dịch vụ. Độ tin cậy là một thuộc tính đầu cuối, có nghĩa là cùng một chất lượng nên được bảo toàn trên toàn bộ đường dẫn từ khách hàng dịch vụ tới nhà cung cấp dịch vụ. Bốn chất lượng độ tin cậy cho các hệ thống lá: ít nhất một lần, nhiều nhất một lần, chính xác một lần và được yêu cầu. Để biết thêm thông tin về các vấn đề này, xem Phụ lục B. Độ tin cậy cần thiết cho giải pháp SOA và tương tác dịch vụ phải ảnh hưởng đến các quyết định kiến trúc chính. Ví dụ, không thể thiết kế một dịch vụ không cần thiết (xem Phụ lục B), có thể yêu cầu các chất lượng tin cậy khác, đáng kể nhất nhiều nhất một lần, chính xác một lần.
b) Dịch vụ quản lý thể hiện bộ công cụ quản lý được sử dụng để giám sát các luồng dịch vụ, sức khỏe của hệ thống cơ sở, sử dụng tài nguyên, xác định sự cố và tắc nghẽn, đạt được mục đích dịch vụ, thực thi chính sách hành chính và khôi phục từ thất bại. Dịch vụ quản lý có thể được sử dụng trong các mô hình dịch vụ như là một phần của giải pháp SOA để vừa cho phép vừa quản lý dịch vụ chức năng và các giải pháp SOA. Dịch vụ quản lý khác với các tác vụ chức năng và các tác vụ quản lý có thể được triển khai trực tiếp bởi dịch vụ cho phép quản lý.
c) Quản trị SOA và dịch vụ phải sử dụng quản lý để thực thi và thực thi quá trình và các chính sách quản trị. Các chính sách quản trị này cùng với các chính sách khác trong hệ thống an toàn, độ tin cậy, tính sẵn có, v.v… là các quy tắc thúc đẩy các hệ thống quản lý.

7.3.5.2 Quản lý giải pháp SOA

Các loại quản lý tương tự áp dụng cho nghiệp vụ nói chung là quan trọng để quản lý dịch vụ và các giải pháp SOA và có thể cần các phần mở rộng để xử lý bản chất định hướng dịch vụ và các ranh giới miền chéo của nhiều giải pháp SOA. Trong khi quản lý dịch vụ tập trung vào việc quản lý dịch vụ, quản lý SOA có phạm vi rộng hơn và quản lý toàn bộ giải pháp SOA hoặc tập các giải pháp SOA.

Quản trị các dịch vụ và SOA phải sử dụng quản lý để thực thi thực thể và thi hành các chính sách và quá trình quản trị. Các chính sách quản trị này cùng với các chính sách khác trong hệ thống an toàn, độ tin cậy, tính sẵn có, v.v… là các quy tắc thúc đẩy các hệ thống quản lý.

Các loại quản lý phổ biến được sử dụng cho các giải pháp SOA như sau.

– Giám sát, quản lý dịch vụ và giải pháp SOA: cung cấp giám sát và quản lý dịch vụ và ứng dụng phần mềm. Điều này bao gồm khả năng thu thập số liệu, giám sát và quản lý trạng thái ứng dụng và giải pháp. Đối với SOA, điều này có thể đang thách thức khi dịch vụ được quản lý hoặc giải pháp sử dụng dịch vụ nằm trong một miền sở hữu khác hoặc trong tổ chức hoặc tổ chức chéo. Số liệu cho mỗi khách hàng dịch vụ cần được thương lượng, thu thập và tạo sẵn, thường trên bảng điều khiển. Đối với dịch vụ miền chéo, việc phân phối thông tin đó có thể được gửi qua báo cáo, các sự kiện hoặc các nguồn cấp dữ liệu thông tin khác vào bảng điều khiển của chính chúng.

– Giám sát và quản lý hoạt động nghiệp vụ: cung cấp giám sát và quản lý các hoạt động nghiệp vụ, các sự kiện nghiệp vụ và quá trình nghiệp vụ. Nó cung cấp khả năng phân tích thông tin sự kiện (thời gian thực và gần thời gian thực), cũng như các sự kiện được lưu trữ (được lưu kho). Nó cho phép xem xét và đánh giá các hoạt động nghiệp vụ mà xác định phản ứng và đưa ra các cảnh báo/thông báo. Điều này thúc đẩy sự hỗ trợ trong tổ chức cho dịch vụ và quản lý giải pháp SOA và quản lý sự kiện. Phụ thuộc giữa các tổ chức nên được quản lý một cách thích hợp.

– Giám sát và quản lý hệ thống IT: cung cấp giám sát và quản lý hạ tầng và hệ thống IT, bao gồm khả năng giám sát và nắm bắt số liệu và trạng thái của các hệ thống và hạ tầng IT. Điều này bao gồm việc quản lý các hệ thống ảo hóa. Đối với các giải pháp SOA, các hệ thống này có thể được biểu diễn và có thể truy nhập như chính dịch vụ và các tài nguyên có thể nằm trong sự kiểm soát của tổ chức hoặc các miền chéo. Đối với các miền chéo, báo cáo với các khách hàng dịch vụ và các khách hàng có thể yêu cầu đàm phán và hỗ trợ đặc biệt.

– Quản lý an toàn: cung cấp giám sát và quản lý các giải pháp an toàn và an toàn. Điều này bao gồm khả năng quản lý vai trò, định danh, các quyền truy nhập và quyền lợi cũng như bảo vệ dữ liệu phi cấu trúc và cấu trúc khỏi truy nhập trái phép và mất dữ liệu. Quản lý an toàn cũng nên giải quyết cách phần mềm, hệ thống và dịch vụ được phát triển và duy trì trong suốt vòng đời phần mềm. Nó phải duy trì trạng thái an toàn thông qua các thay đổi chủ động phản ứng với các lỗ hổng đã xác định và các mối đe dọa mới và cho phép tổ chức IT quản lý các rủi ro và tuân thủ IT liên quan. Những khả năng này cung cấp cơ sở cho tự động hóa quản lý an toàn. Đối với SOA, các chính sách an toàn để thương lượng trên các miền tổ chức cần phải được xác định rõ trong các mô tả và được hỗ trợ.

– Giám sát và thực thi chính sách: cung cấp cơ chế giám sát và thực thi các chính sách và quy tắc nghiệp vụ cho các giải pháp và dịch vụ SOA. Điều này bao gồm việc tìm kiếm và tiếp cận các chính sách, đánh giá và thực thi các chính sách tại các điểm kiểm tra và các điểm thực thi. Thực thi chính sách bao gồm việc thực thi khi các số liệu được thu thập báo hiệu và ghi lại. Thực thi có thể gửi trạng thái tuân thủ, số liệu, thông báo và ghi nhật ký không tuân thủ. Thông báo cho các tổ chức khi các chính sách bị vi phạm cần được hỗ trợ. Ngoài ra, các thủ tục mở rộng về các chính sách chưa được đáp ứng phải được định trước và cho phép vận hành.

– Quản lý sự kiện: cung cấp khả năng quản lý các sự kiện và cho phép xử lý, ghi nhật ký và kiểm toán sự kiện. Đối với SOA, việc sử dụng các sự kiện giữa các tổ chức là một khuôn mẫu chung về thông báo từ các bảng điều khiển, các hệ thống giám sát và quản lý. Trong khi kiểm toán luôn luôn được cho phép, kiểm toán đặc biệt quan trọng đối với các giải pháp tổ chức chéo.

– Quản lý cấu hình và thay đổi: cung cấp khả năng thay đổi giải pháp, các mô tả và cấu hình dịch vụ. Quản lý cấu hình và thay đổi có thể cần phải được phối hợp giữa các tổ chức cho dịch vụ cụ thể và các giải pháp SOA.

– Giải pháp và quản lý dịch vụ vòng đời: cung cấp các cơ chế triển khai, khởi động/bật, dừng/tắt và hủy triển khai các dịch vụ và giải pháp SOA. Đối với các tổ chức sử dụng dịch vụ thuộc sở hữu của các miền hoặc tổ chức khác, vòng đời của dịch vụ trong danh mục đầu tư phải cần được phối hợp. Các cơ chế giao tiếp khi bảo trì hoặc cập nhật về dịch vụ là cần thiết hoặc khi khách hàng dịch vụ không còn cần dịch vụ nữa.

– Quản lý siêu dữ liệu dịch vụ: cung cấp quản lý siêu dữ liệu dịch vụ bổ sung và các tài liệu vật lý như các mô tả dịch vụ và chính sách liên quan đến dịch vụ. Siêu dữ liệu có thể được sử dụng để cho phép nhiều đặc tính SOA: tức là phát hiện, nối kết lỏng, tích hợp, cũng như các quan hệ và thuộc tính dịch vụ.

7.3.5.3 An toàn SOA

An toàn SOA giải quyết việc bảo vệ chống lại các mối đe dọa trên các kích thước lỗ hổng của một kiến trúc theo định hướng dịch vụ. Điều này bao gồm việc bảo vệ tương tác giữa các khách hàng dịch vụ và các nhà cung cấp dịch vụ và tất cả các phần tử đóng góp vào kiến trúc.

An toàn SOA nên tuân theo các qui phạm thực hành tốt của ngành, như đề xuất được ITU-T phát triển trên X.805 và các chiều kích được đề cập trong bộ tiêu chuẩn WS-An toàn (xem Tài liệu tham khảo [28]).

Các mối đe dọa mà an toàn SOA cần giải quyết là phá hủy, tham nhũng, loại bỏ, tiết lộ và gián đoạn (xem Phụ lục B để biết thêm thông tin về các mối đe dọa này).

Tám kích thước an toàn được yêu cầu để bảo vệ chống lại các mối đe dọa được liệt kê là kiểm soát truy nhập, xác thực, chống chối bỏ, bảo mật dữ liệu, an toàn truyền thông, tính toàn vẹn dữ liệu, tính sẵn có và quyền riêng tư (xem Phụ lục B để có thêm thông tin về các chiều kích cho các giải pháp SOA này).

Một số khái niệm chính có mối quan tâm đặc biệt đối với các giải pháp SOA như sau.

– Xác thực. Xác thực phải cung cấp bằng chứng định danh cho việc sử dụng dịch vụ hoặc bất kỳ thành phần nào trong việc sử dụng SOA, ví dụ, ví dụ, bí mật chia sẻ, PKI hoặc chữ ký số. Cần lưu ý rằng khi SOA giải quyết mối tương tác giữa các khách hàng dịch vụ và các nhà cung cấp dịch vụ, bằng chứng định danh phải được thực thi giữa khách hàng ban đầu và nhà cung cấp cuối cùng. Trong các dàn dựng dịch vụ, phải có nhiều tác nhân có thể phải được xác thực. Khi dịch vụ được đưa ra giữa hai hoặc nhiều thực thể là các tổ chức, có thể có một rủi ro mà nhóm người hành rời khỏi hoặc tham gia các thực thể này phải làm cho môi trường rất khó quản lý. Sử dụng các định danh liên kết để thực hiện mô hình tin cậy giữa các thực thể cần được xem xét đối với các giải pháp SOA nơi có sự truyền bá các mã xác nhận cung cấp xác thực nhất quán của người yêu cầu ban đầu thông qua một giao thức đáng tin cậy giữa các thành phần (một ví dụ là WS-Liên kết, xem Tài liệu tham khảo [29]).

– Chống chối bỏ. Chống chối bỏ nên ngăn chặn khả năng từ chối mà một một hoạt động trên các thành phần hoặc phần tử trong giải pháp SOA đã xảy ra. Ví dụ bao gồm các nhật ký hệ thống và chữ ký kỹ thuật số bảo vệ các thông điệp với chữ ký XML. Trong các dàn dựng dịch vụ, phải có nhiều tác nhân tương tác và nó có thể trở nên cần thiết để duy trì một dấu vết của tất cả các hành động từ tất cả tác nhân.

– Tính sẵn có. Tính sẵn có phải đảm bảo rằng các phần tử, dịch vụ và các thành phần sẵn có cho những người sử dụng hợp pháp. Điều này nên được phối hợp với các SLA và siêu dữ liệu hợp đồng khác qui định các điều kiện sử dụng dịch vụ.

7.3.6 Quản trị giải pháp SOA

Quản trị là việc thiết lập và thực thi cách mọi người và các giải pháp làm việc cùng nhau để đạt được mục đích tổ chức. Đối với một tổ chức thực thi nguyên tắc SOA, quản trị giải pháp SOA cần hỗ trợ thiết lập các kỳ vọng và cung cấp một phương tiện để giảm rủi ro, duy trì sự liên kết nghiệp vụ và hiển thị giá trị nghiệp vụ. Giống như các loại quản trị khác, vai trò của quản trị giải pháp SOA là tạo ra một cách tiếp cận nhất quán giữa dịch vụ, các quá trình, các tiêu chuẩn, các chính sách và các hướng dẫn trong khi đặt cơ chế kiểm soát và tuân thủ tại chỗ. Điều này tập trung vào việc kiểm soát tại chỗ phân biệt quản trị ngày với các hoạt động quản lý ngày (xem Tài liệu tham khảo [10]).

Một số lý do chung mà SOA thúc đẩy nhu cầu và đôi khi không thể thành công nếu không, quản trị như sau.

– SOA thường được thúc đẩy bởi những thay đổi tổ chức.

– SOA thường thúc đẩy những thay đổi tổ chức.

– SOA được thực thi trên các ranh giới tổ chức, đặc biệt là trong việc chia sẻ dịch vụ.

– Sử dụng lại dịch vụ thường yêu cầu các tổ chức tạo ra các yêu cầu chia sẻ chi phí mới.

– SOA thúc đẩy thực hành mới trong một tổ chức để xác định dịch vụ và chia sẻ dịch vụ.

Phụ lục A tóm tắt ISO/IEC 17998 tiêu chuẩn kỹ thuật khung công việc quản trị SOA, cung cấp chi tiết một mô hình tham khảo quản trị SOA, một phương pháp sức sống quản trị SOA và các qui phạm thực hành tốt để tạo ra một chế độ quản trị cho dịch vụ và các giải pháp SOA.

Trong khả năng tác động, quản trị giải pháp SOA mở rộng IT và quản trị EA. Điều này hàm ý quản trị không chỉ các khía cạnh thực hiện của SOA, mà còn cả việc hoạch định chiến lược các hoạt động. Nhiều tổ chức đã có một chế độ quản trị cho bộ phận IT của họ bao gồm tài trợ dự án, phát triển và duy trì các hoạt động. Đây có thể được xác định bằng cách sử dụng một trong các khung công việc quản trị IT tiêu chuẩn chính thức, chẳng hạn như COBIT, ITIL, v.v. hoặc khung công quản trị nội bộ đã được xây dựng trong nhiều năm qua.

Chế độ quản trị cho các giải pháp SOA nên bao gồm quản trị các dịch vụ, cũng như quản trị giải pháp SOA trong các thực thể. Quản trị nên được áp dụng những điều sau đây:

a) các quá trình – bao gồm quản trị và quá trình được quản trị. Đây là đơn nhất cho SOA;
b) các cấu trúc tổ chức – bao gồm các vai trò và trách nhiệm;
c) việc cho phép các công nghệ – bao gồm các công cụ và hạ tầng.

Để định rõ các thay đổi cần thiết phù hợp với SOA trong một chế độ quản trị hiện có, các hoạt động quản trị này được ánh xạ và tích hợp với các hoạt động đang được sử dụng trong chế độ hiện có. Mặc dù không có hai chế độ quản trị giống nhau, các tiêu chuẩn quản trị có thể xác định các qui phạm thực hành tốt và cung cấp một điểm khởi đầu cho việc tùy chỉnh giải pháp SOA. Nó nên bao gồm các hoạt động quản trị bị ảnh hưởng bởi SOA.

Việc quản trị các quá trình, tuân thủ, phân phối và truyền thông, nhận ra ý định của tổ chức. Các quá trình và các hoạt động đang được quản trị cho các giải pháp SOA là đặc thù cho việc lập kế hoạch, thiết kế và vận hành các khía cạnh của SOA. Như được mô tả trong Phụ lục A, quản trị giải pháp SOA nên xem xét các điều sau.

– Quản lý danh mục giải pháp SOA xác định các giải pháp SOA được phát triển và duy trì.

– Quản lý danh mục dịch vụ xác định những dịch vụ nào được phát triển và duy trì.

– Quản lý vòng đời giải pháp SOA chịu trách nhiệm phát triển, vận hành, sửa đổi và hủy bỏ cuối cùng các giải pháp SOA. Nó đưa ra các yêu cầu đối với việc phát triển các dịch vụ được giải quyết bằng cách quản lý danh mục dịch vụ và các yêu cầu đối với sửa đổi dịch vụ được giải quyết bằng cách quản lý vòng đời dịch vụ.

– Quản lý vòng đời dịch vụ chịu trách nhiệm phát triển, vận hành, sửa đổi và thu hồi dịch vụ cuối cùng.

Vì quản trị giải pháp SOA đòi hỏi một quá trình đang diễn ra để duy trì sự liên kết, do đó, không thực tế khi mong đợi một tổ chức xác định và triển khai một dự án đơn lẻ và chế độ quản trị giải pháp SOA mở rộng tổ chức đáp ứng nguyện vọng dài hạn như là mục đích cho SOA. Nó mong đợi phải tiến trình khi kinh nghiệm SOA của tổ chức phát triển. Để hỗ trợ điều này, một phương pháp sức sống quản trị SOA có một tổ chức cụ thể thông qua một số hoạt động theo từng giai đoạn tạo thành một vòng lặp cải tiến liên tục, xác định lộ trình triển khai quản trị. Đó là một quá trình liên tục, trong đó quá trình được đo lường, hiệu chỉnh đường đi được thực thi và các cập nhật được thực thi.

8 Các nguyên tắc kiến trúc SOA

8.1 Nguyên tắc kiến trúc được xác định

Các nguyên tắc kiến trúc trong SOA được đẩy đến một mức độ bởi tầm quan trọng của ba nguyên tắc tự bao gồm với SOA: tự bao gồm vị trí, tự bao gồm thực hiện và tự bao gồm giao thức.

– Tự bao gồm vị trí: không có vị trí ưu tiên cho các khách hàng dịch vụ và các nhà cung cấp dịch vụ. Cả hai đều minh bạch về vị trí trên cùng một hệ thống hoặc trong các tổ chức khác nhau và ở các địa điểm thực tế khác nhau.

– Tự bao gồm thưc hiện: không có yêu cầu đối với các nền tảng hoặc công nghệ triển khai cụ thể cho các khách hàng dịch vụ và các nhà cung cấp dịch vụ để chấp nhận. Họ không cần phải biết về môi trường kỹ thuật của bên kia hoặc các chi tiết thực hiện để tương thích với nhau.

– Tự bao gồm giao thức: có hỗ trợ cho dịch vụ được tiếp xúc và tiêu thụ với một loạt các giao thức vận chuyển và các giao thức thông điệp. Có thể có một giao thức hoặc thành phần hộp diêm ở giữa các mục đích tương tác. Trong trường hợp các giao thức khác nhau, các bus dịch vụ có thể thực hiện kết nối giữa dịch vụ không đồng nhất.

Dịch vụ nên được thiết kế để có thể: tương thích, mô tả, có thể sử dụng lại, khả năng phát hiện, khả năng kết hợp, tự trị, nối kết lỏng và khả năng quản lý được. Mỗi đặc tính này được mô tả trong Điều này sử dụng một danh sách các hoạt động mà các kiến trúc sư phải xem xét thực hiện để kiến trúc và phát triển các dịch vụ và các giải pháp SOA thể hiện những đặc tính này. Một số hoạt động áp dụng nhiều đặc tính. Ngoài ra, mỗi đặc tính bao gồm một danh sách các đặc tính hoặc lợi ích nghiệp vụ mà dịch vụ hoặc giải pháp SOA có thể thể hiện như là kết quả của việc thỏa mãn đặc tính.

8.2 Tương tác – Cú pháp, ngữ nghĩa

Đặc tính của tính tương hợp đạt được khi con người, các tổ chức và các hệ thống có thể giao tiếp, trao đổi thông tin và sử dụng khả năng tác động thông tin để làm việc cùng nhau.

Tính tương hợp có nhiều chiều và thường được xem từ góc độ kỹ thuật các hệ thống, bao gồm việc xem xét các phần tử kỹ thuật, cú pháp và ngữ nghĩa. Một cái nhìn rộng hơn về tính tương hợp có thể bao gồm xã hội, tổ chức, pháp lý, chính trị và các phần tử.

Tính tương hợp kỹ thuật liên quan đến việc sử dụng các phương pháp và dịch vụ phổ biến để truy nhập, truyền thông, lưu trữ và xử lý dữ liệu, thường trong nền tảng các ứng dụng và các miền hạ tầng truyền thông, dựa trên các tiêu chuẩn và/hoặc nền tảng IT thông thường

Tính tương hợp cú pháp là khi hai hoặc nhiều hệ thống có khả năng giao tiếp và trao đổi dữ liệu sử dụng một số khuôn dạng dữ liệu được chỉ định hoặc các giao thức truyền thông, ví dụ: XML (ngôn ngữ đánh dấu eXtended) hoặc các tiêu chuẩn SQL (ngôn ngữ truy vấn có cấu trúc). Tính tương hợp cú pháp là điều kiện tiên quyết để đạt được tính tương hợp cao hơn.

Tính tương hợp ngữ nghĩa có thể đạt được thông qua việc thiết lập sự hiểu biết chung về mục đích, cho phép người nhận hành động theo nội dung các thông điệp theo cách phù hợp với ý định của người gửi. Nói cách khác, phải có một sư hiểu biết chung về các yêu cầu nghiệp vụ được giải quyết bởi dịch vụ, không chỉ là một cam kết về cú pháp chung.

Tính tương hợp được tạo thuận lợi bởi

– việc xác định các định nghĩa giao thức bao gồm:

▪ định nghĩa về các kiểu thông điệp và các kiểu nội dung được trao đổi (cú pháp);

▪ mô tả về các kiểu nội dung, bao gồm mọi ràng buộc về các giá trị dữ liệu (để hỗ trợ ngữ nghĩa);

▪ định nghĩa trên cơ sở các giao thức vận chuyển có thể được sử dụng (các ràng buộc);

▪ định nghĩa về thông điệp trao đổi các khuôn mẫu, như các thông điệp yêu cầu và đáp ứng lại;

▪ định nghĩa về các mô hình, thông điệp và trạng thái lỗi;

▪ mô tả về tương tác đối thoại nào, ví dụ: các cuộc gọi lại.

▪ các định nghĩa về bất kỳ hạn chế nào đối với lệnh gọi, ví dụ: mở trước khi viết;

– việc xác định các chính sách ảnh hưởng đến độ tin cậy, tính sẵn có, an toàn và giao dịch.

Các lợi ích của tính tương hợp là nó

a) bao gồm một mức độ hiểu biết ngữ nghĩa tối thiểu về dịch vụ được tiêu thụ và cung cấp,
b) cải thiện sự hiểu biết và hợp tác qua các ranh giới hệ thống và tổ chức,
c) cho phép tăng khả năng hai hệ thống tương tác chính xác,
d) cho phép giảm mối tương tác sai, và
e) cho phép giảm sự mơ hồ khi các sai sót và lỗi xảy ra.

8.3 Được mô tả

Đặc tính của việc được mô tả được thực thi khi khách hàng dịch vụ, nhà cung cấp dịch vụ hoặc nhà phát triển có thể tìm, truy nhập, giải thích và xử lý một mô tả của một dịch vụ. Mô tả dịch vụ, như được mô tả trong 7.2.7, là siêu dữ liệu có thể bao gồm các chi tiết về hợp đồng dịch vụ, giao diện dịch vụ và các chính sách cho các khách hàng dịch vụ và cả các nhà cung cấp dịch vụ.

Việc được mô tả được tạo thuận lợi bởi

– nắm bắt hợp đồng tương tác dịch vụ ở khuôn dạng được tiêu chuẩn hóa, ví dụ XML, WSDL (ngôn ngữ định nghĩa dịch vụ Web, xem Tài liệu tham khảo [18]) cho các triển khai các dịch vụ Web,

– lưu trữ các mô tả trong sổ đăng ký/kho để có thể định vị, truy nhập và sử dụng lại,

– cô lập cấu hình thành các mô tả chính sách,

nắm bắt thông tin cho các các kết mức dịch vụ trong các mô tả,

nắm bắt QOS sẵn có trong các mô tả,

nắm bắt các quá trình nghiệp vụ, quản trị và quản lý sử dụng dịch vụ trong các mô tả và

nắm bắt vị trí dịch vụ.

Các lợi ích của việc được mô tả là nó

a) cho phép nối kết lỏng và bắt buộc trễ bằng cách cung cấp mô tả đầy đủ để có thể tìm kiếm và ràng buộc với dịch vụ nhất định trong thời gian chạy,
b) cho phép sử dụng lại bằng cách thêm siêu dữ liệu để dịch vụ thích hợp có thể được định vị và sử dụng lại,
c) cho phép sử dụng lại bằng cách thêm mô tả để dịch vụ thích hợp sẵn có đối với các chức năng cần thiết,
d) cho phép quản lý và cấu hình lại dịch vụ trong thời gian chạy và khi được sử dụng lại để giảm thiểu các thay đổi đối với việc triển khai các dịch vụ,
e) cho phép quản lý dịch vụ trong thời gian chạy bằng việc mô tả các quá trình và giám sát quản lý,
f) cho phép quản trị nghiệp vụ và IT về các giải pháp SOA và dịch vụ, và
g) cho phép bổ sung chức năng tích hợp (xem Hình 10), bus dịch vụ (xem 2.22).

8.4 Có thể sử dụng lại

Đặc tính của khả năng sử dụng lại đạt được khi cùng một định nghĩa hoặc triển khai các dịch vụ hoặc cả hai, được sử dụng nhiều hơn một giải pháp SOA. Việc cho phép sử dụng lại giúp giảm các chi phí phát triển và duy trì và tăng lợi tức đầu tư dài hạn cho giải pháp.

Khả năng sử dụng lại dịch vụ được tạo thuận lợi bởi

– Việc lập mô hình và phân tích dịch vụ – việc lập mô hình dịch vụ được phát triển để hỗ trợ giải pháp SOA, tìm kiếm các tác vụ chung và dịch vụ chia nhỏ trong giải pháp;

– Việc sử dụng mức chi tiết phù hợp – dịch vụ “tiện ích” chia nhỏ tốt hơn có thể được sử dụng lại trong các tổ hợp dịch vụ;

– Việc sử dụng các định nghĩa tự trị;

– Việc tôn trọng các nguyên tắc cho dịch vụ nối kết lỏng;

– Việc phát triển các dịch vụ được mô tả tốt để dịch vụ có thể được tìm thấy, đánh giá phù hợp và được sử dụng lại;

– Việc tạo dịch vụ có khả năng phát hiện;

– Việc ràng buộc sau đó các dịch vụ, lấy địa chỉ cho điểm cuối dịch vụ hiện tại vào thời gian chạy để dịch vụ khác có thể được thay thế khi chạy và không tái phát triển việc triển khai các dịch vụ;

– Việc quản trị nghiệp vụ với các quá trình tại chỗ để xác định tái phát triển và yêu cầu sử dụng lại dịch vụ hiện có;

– Việc thông hiểu cách dịch vụ phải được tài trợ để phát triển nếu nó được sử dụng trong các tổ chức;

– Việc có vòng đời phát triển và duy trì phần mềm thích hợp để hỗ trợ sử dụng lại dịch vụ trong nhiều giải pháp (tức là tác động khi thực hiện được cập nhật);

– Việc cho phép quản lý các dịch vụ để chính sách được thúc đẩy;

– Việc thực thi các dịch vụ có cấu hình được phân tách vào chính sách.

Các lợi ích sử dụng lại dịch vụ là nó

a) cho phép giảm chi phí phát triển bằng cách loại bỏ nhu cầu phát triển một tập các dịch vụ,
b) cho phép giảm chi phí SOA trên toàn tổ chức theo thời gian khi dịch vụ không cần phải được phát triển lại nhiều giải pháp hiện tại và trong tương lai,
c) cho phép giảm thời gian phát triển thành giá trị khi bạn đang sử dụng dịch vụ hiện có mà không phải được phát triển,
d) cho phép giảm rủi ro khi dịch vụ đã được thử nghiêm tốt trước khi được sử dụng lại,
e) cho phép tăng nhanh nơi dịch vụ có thể được sử dụng theo các cách không lường trước và
f) cho phép tăng nhanh nơi dịch vụ sẵn có để phát triển nhanh chóng.

8.5 Khả năng phát hiện

Đặc tính của khả năng khả năng phát hiện đạt được khi có thể tìm hiểu về sự tồn tại, vị trí và/hoặc mô tả của một dịch vụ, thường trong việc chuẩn bị một tương tác dịch vụ.

Khả năng định vị hoặc phát hiện các dịch vụ và mô tả dựa trên các tiêu chí cụ thể có thể được phép bởi một kiểu sổ đăng ký/kho hoặc các kiểu công nghệ tìm kiếm khác. Các khách hàng dịch vụ về cơ bản có thể tìm được dịch vụ và có tính tương hợp trước phần còn lại của quản lý, an toàn và quản trị là cần thiết.

Hạ tầng phát hiện tồn tại liên tục, từ việc được cung cấp một mô tả dịch vụ (không có phát hiện nào) để tìm kiếm trong một vị trí hoặc thư mục được xác định rõ ràng để sổ đăng ký/kho phức tạp, có thể tìm kiếm.

Dịch vụ có thể được phát hiện tại thiết kế hoặc thời gian chạy trong vòng đời dịch vụ. Việc hỗ trợ phát hiện trong thời gian chạy hỗ trợ bắt buộc trễ cho dịch vụ làm tăng sự nối kết lỏng.

Các kết nối cũng tồn tại trên một liên tục từ một tương tác trực tiếp tĩnh liên kết chặt chẽ, nơi thông tin dịch vụ có thể được cung cấp từ kiến thức tiên tiến trực tiếp vào việc triển khai các dịch vụ đến vị trí động của dịch vụ ứng cử, lựa chọn dịch vụ đó thông qua siêu dữ liệu và ràng buộc với đúng dịch vụ trong thời gian chạy. Ở giữa là mẫu khuôn mẫu chung của việc phát hiện mô tả dịch vụ trong thời gian thiết kế từ một sổ đăng ký/kho và sử dụng trong quá trình lập mô hình, thu thập và triển khai, tra cứu và ràng buộc địa chỉ dịch vụ khi chạy. Việc phát hiện các điểm cuối cho dịch vụ trong thời gian chạy có thể làm tăng độ nối kết lỏng.

Khả năng khả năng phát hiện được tạo thuận lợi bởi

– lưu trữ các tạo tác mô tả dịch vụ trong một sổ đăng ký/kho hoặc một số vị trí có thể dự đoán trước khác,

– cung cấp các phương tiện/công cụ tìm kiếm để có thể tìm kiếm, tìm và truy nhập mô tả dịch vụ và quản trị các quá trình đăng ký đọc và lưu trữ các mô tả dịch vụ.

Các lợi ích của khả năng phát hiện là nó

a) cho phép bắt buộc trễ đối với dịch vụ, làm tăng độ bền,
b) cho phép nối kết lỏng bằng cách cung cấp vị trí và truy nhập mô tả dịch vụ,
c) cho phép sử dụng lại dịch vụ bằng việc đảm bảo dịch vụ đang tồn tại và có thể sử dụng lại và các mô tả dịch vụ có thể định vị và sử dụng, và
d) cho phép tính kết theo hợp đồng.

8.6 Khả năng ràng buộc sau đó

Đặc tính của bắt buộc trễ sử dụng thông tin truy nhập trong thời gian chạy để thiết lập việc bắt buộc và có thể tự bao gồm với việc phát hiện các dịch vụ

Việc sử dụng bắt buộc trễ qua một sổ đăng ký/kho cũng cho phép khách hàng dịch vụ được tách biệt với các thay đổi về vị trí dịch vụ. Kết hợp việc sử dụng chính sách với việc bắt buộc trễ hơn nữa phải tách biệt khách hàng dịch vụ khỏi việc triển khai các dịch vụ bởi việc cho phép cấu hình tương tác dịch vụ. Cuối cùng, việc thêm vào việc sử dụng chức năng tích hợp tách biệt khách hàng dịch vụ và việc triển khai các dịch vụ và cho phép tăng độ tin cậy và tính sẵn có. Sự kết hợp các tính năng này cho phép thay đổi khả năng, tỷ lệ và chất lượng dịch vụ theo nhu cầu của nhu cầu nghiệp vụ mà không ảnh hưởng đến khách hàng hoặc việc triển khai các dịch vụ. Khả năng phát hiện và bắt buộc trễ có thể giúp tính kết theo hợp đồng.

Bắt buộc trễ được tạo thuận lợi bởi

– cung cấp các cơ sở/ công cụ tìm kiếm để có thể tìm kiếm, tìm và truy nhập mô tả dịch vụ, và

– quản trị các quá trình hỗ trợ việc sử dụng bắt buộc đối với điểm cuối cùng trong thời gian chạy.

Lợi ích của bắt buộc trễ là nó

a) cho phép tăng cường độ bền,
b) cho phép nối kết lỏng bởi việc cung cấp vị trí và truy nhập mô tả dịch vụ,
c) cho phép tăng cường độ bền và sự nhanh nhẹn của giải pháp SOA.
d) cho phép sử dụng lại dịch vụ bằng cách đảm bảo sự tổn hại và có thể sử dụng lại dịch vụ và các mô tả dịch vụ có thể được định vị và sử dụng, và
e) cho phép tính kết theo hợp đồng khi sổ đăng ký/kho dịch vụ được cho phép sử dụng.

8.7 Khả năng kết hợp

Đặc tính tính kết hợp đạt được khi dịch vụ có thể là một phần tử của một tổ hợp mà không phải thay đổi việc triển khai các dịch vụ.

Khả năng ranh giới soạn một dịch vụ được cho phép bởi dịch vụ được mô tả thích hợp được nối kết lỏng và tự trị.

Tính kết hợp tự bao gồm với các loại tổ hợp có thể được tạo ra, như các quá trình, các dàn dựng và phối trí.

Tính kết hợp được tạo thuận lợi bởi

– tôn trọng nguyên tắc sử dụng lại,

– phát triển các dịch vụ tự trị, và

– phát hiện các dịch vụ thông qua các tạo tác trong một sổ đăng ký/kho.

Những lợi ích của tính kết hợp là nó

– cho phép sự nhanh nhẹn bằng việc sử dụng lại dịch vụ hiện có để phát triển các dịch vụ mới mà không cần chờ đợi sự phát triển, và

– cho phép sự phát triển các tổ hợp, các quá trình, các dàn dựng và phối trí.

8.8 Tự bao gồm

Đặc tính của tự ngăn chặn hoặc tự trị, đạt được khi một dịch vụ có thể được gọi với chỉ thông tin sẵn có trong mô tả dịch vụ. Khách hàng dịch vụ phải được tách biệt khỏi các chi tiết triển khai các dịch vụ. Dịch vụ tự bao gồm nên được đóng gói và không nên phụ thuộc vào dịch vụ khác trong lãnh thổ hoặc là không rõ lãnh thổ. Dịch vụ là tổ hợp của dịch vụ khác có thể được tự bao gồm miễn là chúng không bị đóng gói hoặc cho phép các khách hàng dịch vụ xem hoặc hiểu cách dịch vụ được triển khai.

Tự ngăn chặn được tạo thuận lợi bởi

– tách biệt khách hàng dịch vụ khỏi thực thi (tính mờ),

phát triển các dịch vụ tự bao gồm,

phát triển các mô tả đầy đủ, và

cung cấp một tác vụ thực hiện tự bao gồm.

Những lợi ích của tự ngăn chặn là nó

a) cho phép tăng khả năng sử dụng lại và
b) cho phép tăng tính kết hợp.

8.9 Nối kết lỏng

Đặc tính của nối kết lỏng đạt được khi tiêu thụ dịch vụ được cách ly từ thực hiện cơ bản.

Trong hầu hết các ngành, bất kỳ thứ gì có thể sử dụng lại đều cho phép một số thay đổi và độ linh hoạt khi kết nối với các phần tử khác. Trong ngành công nghệ thông tin, điều này cho phép sự biến đổi và độ linh hoạt được tham chiếu như nối kết lỏng.

Kiểu dáng kiến trúc theo định hướng dịch vụ (SOA) hỗ trợ việc nối kết lỏng tác vụ của một dịch vụ đang được tiêu thụ từ thực thi được cung cấp. Trao đổi thông điệp nên được xác định rõ nhưng vẫn cung cấp cơ chế nguyên tắc cho các biến thể về đầu vào và khả năng mở rộng.

Nối kết lỏng được tạo thuận lợi bởi

– yêu cầu các khách hàng dịch vụ sử dụng các tác vụ và/hoặc các hợp đồng để tương tác với dịch vụ đảm bảo rằng các tính năng dịch vụ có thể được thực thi bởi bất kỳ thực thi sẵn có hơn là một ví dụ cụ thể của một thực thi,

– tách biệt thực thi khỏi cả việc ràng buộc và điểm cuối dịch vụ tác vụ,

– chọn các tác vụ kiểu văn bản thay vì RPC,

– có các khách hàng dịch vụ sử dụng bắt buộc trễ (trong thời gian chạy) cho các cá thể dịch vụ thông qua phát hiện các dịch vụ, có thể được cung cấp bởi cơ quan sổ đăng ký, kho lưu trữ, dàn xếp hoặc cơ chế khác,

– thể hiện ra ngoài cấu hình và các hợp đồng thời gian chạy trong chính sách, và

– sử dụng chức năng tích hợp (xem Hình 10) để cung cấp hỗ trợ cho các kết nối, dàn xếp giao thức, an toàn và các chất lượng khác của dịch vụ. Điều này làm giảm khách hàng dịch vụ và việc triển khai các dịch vụ từ việc cung cấp trực tiếp này hoặc phải thực hiện chất lượng dịch vụ trực tiếp “phù hợp”.

Các lợi ích của nối kết lỏng là nó

a) cho phép giảm thiểu thay đổi đối với các khách hàng dịch vụ theo thời gian, ngay cả khi các phiên bản thay đổi hoặc thay đổi là cần thiết cho chất lượng dịch vụ hoặc hỗ trợ giao thức, cho dịch vụ có thể chấp nhận được,
b) cho phép thay thế một dịch vụ luân phiên các khả năng tác động, ngữ nghĩa và các sách chính giống nhau,
c) cho phép giảm thiểu các thay đổi đối với dịch vụ của nhà cung cấp để thay đổi các phiên bản, giao thức, dung lượng và chất lượng dịch vụ,
d) cho phép giảm thiểu các thay đổi đối với việc triển khai các dịch vụ để hỗ trợ sử dụng lại dịch vụ trong các cơ hội mới, tăng tính nhanh nhẹn nghiệp vụ,
e) cho phép tăng khả năng cung cấp các dịch vụ và độ tin cậy cho các khách hàng dịch vụ bằng cách cho phép lựa chọn dịch vụ thích hợp với bắt buộc trễ trong thời gian chạy,
f) cho phép giảm chi phí (thông qua việc cho phép sử dụng lại dịch vụ),
g) cho phép bổ sung và lợi ích của tích hợp chức năng,
h) cho phép liên kết các miền SOA – chia sẻ dịch vụ từ một miền giải pháp SOA này sang miền khác,
i) cho phép quản lý dịch vụ được điều khiển chính sách và
j) cho phép sử dụng lại dịch vụ bằng cách tách biệt cấu hình trong chính sách.

Để đạt được những lợi ích của việc nối kết lỏng này, một số quản lý bổ sung siêu dữ liệu dịch vụ là cần thiết.

8.10 Khả năng quản lý

Đặc tính của khả năng quản lý đạt được khi dịch vụ và giải pháp có thể được phát triển, kiểm soát, giám sát, cấu hình và quản trị, như các chính sách, hợp đồng và các cam kết được tôn trọng.

Khả năng quản lý được tạo thuận lợi bởi.

– xác định và giám sát các số liệu chính về tính sẵn có, độ tin cậy, hiệu năng và quản trị,

– cung cấp các tác vụ cho khả năng quản lý cùng với các tác vụ cho các khả năng chức năng,

– việc cho phép quản lý dịch vụ để thúc đẩy chính sách,

– tách biệt cấu hình trong chính sách,

– cho phép cấu hình dịch vụ tại thiết kế và thời gian chạy,

– cho phép giám sát việc phù hợp với các hợp đồng,

– phát triển quản trị các chính sách và quá trình, và

– cho phép kiểm soát vòng đời của dịch vụ (bật, tắt).

Lợi ích của khả năng có thể là nó

a) cho phép nhận thức về tính sẵn có của dịch vụ,
b) cho phép giảm nguy cơ thất bại dịch vụ,
c) cho phép thực thi hợp đồng,
d) cho phép thi hành quá trình quản trị và tự động hóa,
e) cho phép điều chỉnh các yêu cầu nghiệp vụ và IT cho giải pháp SOA, và
f) cho phép tự động hóa dịch vụ và quản lý giải pháp SOA.

Phụ lục A

(tham khảo)

Khung quản trị SOA

Phụ lục này là một bản tóm tắt của ISO/IEC 17998 về khung quản trị SOA, đưa ra bối cảnh cho người đọc cần hiểu rõ hơn về quản trị SOA, quản trị các dịch vụ và chế độ quản trị SOA

Quản trị SOA cần được xem là ứng dụng quản trị doanh nghiệp, quản trị IT và quản trị EA đối với kiến trúc hướng dịch vụ (SOA). Theo kết quả, quản trị SOA mở rộng quản trị IT và EA, đảm bảo các lợi ích mà các tán dương SOA đáp ứng được. Điều này ngụ ý quản trị không chỉ là các khía cạnh thực hiện của SOA mà còn là các hoạt động lập kế hoạch chiến lược. Nhiều tổ chức đã có một chế độ quản trị cho bộ phận IT của họ bao gồm tài trợ dự án, phát triển và duy trì các hoạt động. Đây có thể được xác định bằng cách sử dụng một trong các khung quản trị IT tiêu chuẩn chính thức, chẳng hạn như COBIT, ITIL, v.v. hoặc khung quản trị nội bộ đã được xây dựng trong nhiều năm.

– Quản trị kiến trúc doanh nghiệp (EA) (“quản trị EA”) là qui phạm thực hành và hướng dẫn định hướng theo đó các kiến trúc doanh nghiệp và các kiến trúc khác được quản lý và kiểm soát tại mức toàn doanh nghiệp. Xem Tài liệu tham khảo [16].

– Quản trị về IT (“quản trị IT”) là hệ thống mà việc sử dụng IT hiện tại và trong tương lai được kiểm soát và chỉ đạo. Quản trị doanh nghiệp về IT liên quan đến đánh giá và chỉ đạo việc sử dụng IT để hỗ trợ tổ chức và giám sát việc sử dụng này để đạt được các kế hoạch. Nó bao gồm chiến lược và các sách chính sử dụng IT trong tổ chức. Xem 1.6.3, ISO/IEC 38500:2008.

– Quản trị nghiệp vụ (“quản trị doanh nghiệp”) là tập các quá trình, phong tục, chính sách, pháp luật và các tổ chức thẩm quyền ảnh hưởng đến cách tổ chức được chỉ đạo, quản lý hoặc kiểm soát

Hình A.1 – Chế độ quản trị SOA

Chế độ quản trị cho các giải pháp SOA bao gồm quản trị về dịch vụ, cũng như quản trị giải pháp SOA trong các thực thể. Quản trị được áp dụng cho những điều sau đây:

a) quá trình – bao gồm quản trị và quá trình được quản trị;
b) cấu trúc tổ chức – bao gồm các vai trò và trách nhiệm;
c) công nghệ đáp ứng – bao gồm các công cụ và hạ tầng.

Khung quản trị SOA có thể cho phép các doanh nghiệp xác định và triển khai các chế độ quản trị SOA tập trung và tùy chỉnh của chính chúng, dựa trên các phần tử cụ thể của doanh nghiệp, chẳng hạn như mô hình nghiệp vụ, độ trưởng thành của SOA và quy mô công ty. Nó mô tả những quyết định cần phải được thực thi, ai nên tạo ra chúng, cách chúng được tạo ra và giám sát và tổ chức và công cụ nào phải hỗ trợ chúng. Nó sử dụng một phương pháp gia tăng để các doanh nghiệp có thể tiếp tục đáp ứng nhu cầu hiện tại SOA của họ trong khi hoàn thành nguyện vọng và mục đích dài hạn của họ cho SOA.

Để nhận định các thay đổi cần thiết phù hợp với SOA trong một chế độ quản trị hiện có, các hoạt động quản trị này phải được lập bản đồ và tích hợp với các hoạt động đang được sử dụng trong chế độ hiện có. Mặc dù không có hai chế độ quản trị nào giống nhau, các tiêu chuẩn quản trị có thể xác định các qui phạm thực hành tốt và cung cấp một điểm khởi đầu để tùy chỉnh giải pháp SOA. Mô hình tham khảo quản trị SOA có thể được xác định và được sử dụng để phát triển một chế độ quản trị SOA tùy chỉnh của doanh nghiệp. Nó nên bao gồm các hoạt động quản trị chịu ảnh hưởng bởi SOA:

– Hướng dẫn – một tập các nguyên tắc hướng dẫn để thông báo việc ra quyết định trong thiết kế, triển khai và thực thi giải pháp SOA và chế độ quản trị SOA;

– Quá trình được quản trị – các mô tả về các hoạt động và quá trình tùy thuộc vào quản trị SOA. Bốn nhóm hoạt động được qui định để lập kế hoạch, thiết kế và vận hành các khía cạnh SOA:

– Quản lý danh mục giải pháp SOA xác định các giải pháp SOA nào được phát triển và duy trì.

– Quản lý danh mục dịch vụ xác định dịch vụ nào được phát triển và duy trì.

– Quản lý vòng đời giải pháp SOA chịu trách nhiệm phát triển, vận hành, sửa đổi và hủy bỏ cuối cùng các giải pháp SOA. Nó đưa ra các yêu cầu đối với việc phát triển các dịch vụ được giải quyết bằng cách quản lý danh mục dịch vụ và các yêu cầu sửa đổi dịch vụ được giải quyết bằng quản lý vòng đời dịch vụ.

– Quản lý vòng đời dịch vụ chịu trách nhiệm phát triển, vận hành, sửa đổi và hủy bỏ cuối cùng dịch vụ;

– Quá trình quản trị – các mô tả về quản trị các quá trình kiểm soát các hoạt động. Quản trị các quá trình nhận ra các ý định quản trị của tổ chức. Nói chung, chúng phải được tích hợp với các quá trình quản trị doanh nghiệp hiện có, hơn nữa tạo thành một tập đặc biệt dành riêng cho các quá trình SOA. Ba kiểu quá trình quản trị như sau.

– Quá trình tuân thủ đảm bảo các hoạt động được quản trị được thực thi một cách chính xác bằng cách xem xét các đầu ra tại các điểm kiểm tra quản trị.

– Quá trình cai quản cho phép một nhóm dự án hoặc giải pháp có được ngoại lệ từ các yêu cầu của quá trình tuân thủ, đặc biệt, các trường hợp ứng dụng bao trùm chính sách chung là không thích hợp.

– Quá trình truyền thông nhằm mục đích giáo dục các bên tham gia vào các hoạt động được quản trị và truyền thông tới chúng kiến trúc các hệ thống và chế độ quản trị. Điều này bao gồm việc thiết lập các môi trường và các công cụ cho phép dễ dàng truy nhập và sử dụng thông tin quản trị;

– Vai trò và trách nhiệm – xác định thông qua phân tích các kiểu bên tham gia vào các hoạt động đang được quản trị và mức độ trách nhiệm của họ đối với những hoạt động đó;

– Tạo tác – một tập các tạo tác được sử dụng bởi các quá trình quản trị và hiện cần lưu giữ và sẵn có cho các bên liên quan quản trị;

việc cho phép công nghệ – công nghệ cho phép và thực thi quá trình quản trị. Một khung về các khả năng công nghệ có thể nằm trong khả năng từ các quá trình định kỳ đến phần mềm thủ công. Đôi khi, cùng một công nghệ được sử dụng để thực hiện giải pháp SOA cũng có thể được sử dụng để hỗ trợ quản trị nó.

Khi quản trị là về việc duy trì sự căn chỉnh, nó đòi hỏi một quá trình đang diễn ra để hỗ trợ nó. Cũng không thực tế khi mong đợi một doanh nghiệp xác định và triển khai trong một dự án đơn nhất, một chế độ quản trị SOA doanh nghiệp-rộng đáp ứng nguyện vọng và mục đích dài hạn cho SOA, đặc biệt trong khi tiếp tục đáp ứng các nhu cầu SOA hiện tại. Do đó, một phương thức sức sống quản trị SOA cần xác định và triển khai các chế độ quản trị SOA một cách từng bước. Nó lấy mô hình tham khảo quản trị SOA như một đường cơ sở và điều chỉnh nó để phù hợp với một doanh nghiệp cụ thể thông qua một số hoạt động theo từng giai đoạn tạo thành một vòng cải tiến liên tục, xác định một lộ trình triển khai quản trị. Nó không phải là một hoạt động một lần mà là một quá trình liên tục, trong đó quá trình được đo, sửa chữa tiến trình được thực thi và các cập nhật được thực thi. Các giai đoạn trong một phương pháp như vậy nên bao gồm những điều sau đây:

a) Kế hoạch: xác định các yêu cầu về quản trị SOA, xem xét chế độ quản trị hiện có và xác định tầm nhìn, phạm vi và chiến lược cho các thay đổi được thực thi;
b) Xác định: tạo ra một chế độ quản trị SOA được thiết kế từ mô hình tham khảo quản trị SOA,¹ sử dụng các kết quả của giai đoạn kế hoạch. Sau đó phân tích sự khác biệt giữa chế độ này và theo chế độ quản trị hiện có để tạo ra các kế hoạch chuyển tiếp;
c) Thực thi: nhận ra chế độ quản trị SOA được thiết kế đã được tạo ra trong giai đoạn xác định dể tạo ra một chế độ quản trị SOA cho doanh nghiệp; về cơ bản nó thực thi kế hoạch chuyển tiếp từ giai đoạn xác định;
d) Giám sát: giám sát khả năng tác động vận hành của chế độ quản trị SOA được tạo ra trong giai đoạn thực hiện và liệu nó có đáp ứng mục đích dự định hay không. Điều này tạo ra các yêu cầu cho sự thay đổi có thể được giải quyết trong một chu kỳ mới của phương pháp sức sống quản trị SOA.

Phụ lục B

(tham khảo)

Mối quan tâm về quản lý và an toàn

B.1 Qui định chung

Phụ lục này mở rộng mối quan tâm xuyên suốt về quản lý và an toàn và cung cấp nội dung và thông tin bổ sung liên quan quản lý giao dịch, độ tin cậy dịch vụ, an toàn SOA và quản trị an toàn SOA.

Mối quan tâm về quản lý và an toàn hỗ trợ các yêu cầu phi chức năng (NFR) có liên quan như một tính năng/mối quan tâm chính của SOA và cung cấp một đầu mối để xử lý chúng trong bất kỳ giải pháp đã cho nào. Nó cung cấp các phương tiện đảm bảo một SOA đáp ứng các yêu cầu đối với: giám sát, độ tin cậy, tính sẵn có, khả năng quản lý, khả năng giao dịch, khả năng duy trì, khả năng mở rộng, an toàn, an toàn, vòng đời, v.v. Nó có phạm vi tương tự như FCAPS truyền thống (lỗi, cấu hình, tài khoản, hiệu năng, an toàn) từ ITIL hoặc RAS (độ tin cậy, tính sẵn có, khả năng dịch vụ). Ba khía cạnh quan trọng của quản lý và an toàn cần được hỗ trợ là quản lý giao dịch, tính sẵn có và độ tin cậy dịch vụ.

B.2 Quản lý giao dịch

Các giao dịch phối hợp các hành động của dịch vụ về các tài nguyên có thể phụ thuộc về các thành phần được phân phối khi các thành phần này được yêu cầu đạt được cam kết nhất quán về đầu ra của tương tác dịch vụ.

Người quản lý giao dịch thường phối hợp đầu ra trong khi ẩn các chi tiết cụ thể của từng thành phần dịch vụ được phối hợp và công nghệ triển khai các dịch vụ. Với cách tiếp cận đó, một ngữ nghĩa giao dịch phổ biến và chuẩn hóa có thể được sử dụng trên dịch vụ.

Các giao dịch này bao gồm hai loại giao dịch bao gồm cả các tiêu chuẩn dịch vụ Web, tức là WS-phối hợp (xem Tài liệu tham khảo [25]) là khuôn khổ cho WS-giao dịch đơn vị (xem Tài liệu tham khảo [26]) và WS- Hoạt động nghiệp vụ (xem Tài liệu tham khảo [27])

– Giao dịch đơn vị – Các giao dịch đơn vị xảy ra khi xây dựng các thành phần dịch vụ yêu cầu cam kết nhất quán về đầu ra của các hoạt động phân phối tồn tại trong thời gian ngắn có thuộc tính toàn bộ hoặc không có gì. Giao dịch đơn vị đòi hỏi tính chất đơn vị, tính nhất quán, tính tách biệt và độ bền (ACID) và do đó duy trì một khóa trong các tài nguyên đã thay đổi cho đến khi những thay đổi này được cam kết hoặc được khôi phục lại. Đầu ra của một dịch vụ phải là một sự thay đổi thành công của tất cả tài nguyên được điều phối bởi dịch vụ hoặc khôi phục lại trạng thái đã tồn tại trước khi tương tác dịch vụ.

– Giao dịch hoạt động nghiệp vụ – Các giao dịch hoạt động nghiệp vụ xảy ra khi xây dựng các dàn dựng mà yêu cầu cam kết nhất quán về đầu ra của tương tác dịch vụ phân phối dài hạn được phối hợp, nơi các khóa không thể được duy trì trong tài nguyên đã sửa đổi cho thang thời gian của dàn dựng. Do các khía cạnh dịch vụ không thống trị thông thường, các thay đổi xảy ra trên các tài nguyên được quản lý bởi một thành phần không thể được khôi phục sau tương tác dịch vụ. Do đó, trong trường hợp lỗi phối hợp, các hành động ngược lại phải được thực thi thông qua tương tác dịch vụ thích hợp để khôi phục trạng thái chấp nhận được đối với các tài nguyên được kiểm soát bởi từng thành phần dịch vụ. Những hành động này được gọi là bồi thường và vẫn có thể dẫn đến những thay đổi vĩnh viễn. Ví dụ, một số dịch vụ có thể không cho phép xóa tài nguyên mới được tạo, trong trường hợp đó, hành động bồi thường có thể là cài đặt một trạng thái không hoạt động. Các giao dịch hoạt động nghiệp vụ có thể được đệ quy trong tự nhiên, phải kết hợp nhiều phạm vi hoạt động nghiệp vụ.

B.3 Tính sẵn có

Tính sẵn có của giải pháp SOA là phần trăm thời gian mà giải pháp đang thực thi chức năng nghiệp vụ một cách thích hợp. Để đo lường điều này, điều quan trọng là xác định và giám sát các chỉ số hiệu năng chính cho toàn bộ giải pháp. Việc đo lường tính sẵn có của từng dịch vụ phải không bác bỏ tính sẵn cỏ và thực thi chức năng nghiệp vụ.

Tính sẵn có của dịch vụ được gắn với phần trăm thời gian mà một dịch vụ có thể được gọi thành công. Tính sẵn có của dịch vụ có thể được đo từ một nhà cung cấp, mạng và ranh giới khách hàng, việc kiểm tra dịch vụ hệ thống và mạng có đang hoạt động hay không. Tính sẵn có của dịch vụ khác với các ranh giới khác nhau, tức là đôi khi dịch vụ, hệ thống và mạng của nhà cung cấp hoạt động tốt nhưng có một nút thắt trong mạng giữa khách hàng dịch vụ và nhà cung cấp dịch vụ. Thông thường, tính sẵn có của dịch vụ có thể được đo bằng hạ tầng và các công cụ thay mặt cho dịch vụ và các số liệu được cung cấp là phổ biến, tức là tỷ lệ phần trăm thời gian và số lượng các thông điệp lỗi.

Tính sẵn có của dịch vụ thường là số liệu chính trong các các kết mức dịch vụ, các chính sách và các hợp đồng.

B.4 Độ tin cậy dịch vụ

Độ tin cậy về nội dung nếu SOA là chất lượng dịch vụ hướng vào mối tương tác giữa một khách hàng dịch vụ và một nhà cung cấp dịch vụ và được sử dụng để chỉ ra các mức bảo đảm khác nhau trên các trung gian và mạng liên quan đến trao đổi thông điệp trong các viện dẫn dịch vụ. Độ tin cậy là một thuộc tính cuối đến cuối, có nghĩa là cùng một chất lượng nên được bảo toàn trong toàn bộ đường dẫn từ khách hàng dịch vụ đến nhà cung cấp dịch vụ.

Về nguyên tắc chính khi thiết kế một dịch vụ là khái niệm về tính luỹ đẳng. Nếu một dịch vụ là luỹ đẳng sau đó các bản sao của cùng một viện dẫn dịch vụ, ví dụ, thông qua sự thực hiện lại, phải cho kết quả chính xác cùng một kết quả. Nói cách khác, một kết quả giống hệt nhau đạt được cho dù yêu cầu xảy ra một lần hoặc được lặp đi lặp lại nhiều lần. Tất cả các vận hành không thay đổi trạng thái (đọc/nhận), theo định nghĩa là luỹ đẳng. Để thực hiện một vận hành thay đổi trạng thái, luỹ đẳng yêu cầu thiết kế cẩn thận để đảm bảo rằng các yêu cầu trùng lặp dẫn đến cùng một trạng thái. Trường hợp không thể thiết kế một dịch vụ luỹ đẳng, các tính chất tin cậy khác có thể được yêu cầu giúp đỡ, chú ý, nhiều nhất một lần và chính xác một lần.

Bốn tính chất tin cậy có thể được cung cấp bởi hệ thống

– Ít nhất một lần: một yêu cầu được gửi một lần, nhưng nó là ok để cung cấp các bản sao. Các vận hành luỹ đẳng rất phù hợp với các ngữ nghĩa này.

– Nhiều nhất một lần: yêu cầu được phân phối một lần và không được phép phân phối bất kỳ bản sao nào như khả năng tác động của yêu cầu trùng lặp phải dẫn đến hành vi sai, ví dụ, trừ cùng số tiền từ tài khoản ngân hàng! Hành vi đúng của dịch vụ không có rủi ro nếu yêu cầu không được gửi.

– Chính xác một lần: yêu cầu được phân phối một lần và không được phép phân phối bất kỳ bản sao nào. Hành vi đúng của dịch vụ có thể có nguy cơ nếu yêu cầu không thành công. Nói cách khác, tất cả các nỗ lực hợp lý cần được thực thi để phân phối yêu cầu một lần và chỉ một lần.

– Có thứ tự: một khách hàng dịch vụ có thể khởi đầu nhiều yêu cầu khác nhau đối với cùng một nhà cung cấp trong một khoảng thời gian. Vì các trung gian và mạng tiềm ẩn có thể nhận được các yêu cầu như vậy, nên điều quan trọng là thứ tự yêu cầu có thứ tự được giữ nguyên nếu là yêu cầu giữa khách hàng dịch vụ và nhà cung cấp dịch vụ. Lưu ý rằng thứ tự có thể được kết hợp với ba thuộc tính khác.

Độ tin cậy tương phản với tính sẵn có và giao dịch. Trong khi tính sẵn có liên quan đến việc liệu một dịch vụ có hoạt động, lên và chạy và có thể xử lý các yêu cầu hay không, thì độ tin cậy quan tâm đến chính nó với việc đảm bảo yêu cầu và đáp ứng các thông điệp được phân phối. Mặt khác, độ tin cậy liên quan đến việc phân phối thông điệp giữa khách hàng dịch vụ và nhà cung cấp dịch vụ; nó không giải quyết liệu một yêu cầu có thực sự được xử lý hay không bởi nhà cung cấp. Giao dịch giải quyết xem yêu cầu được xử lý hay không.

B.5 Quản lý SOA

Các loại quản lý tương tự áp dụng cho nghiệp vụ nói qui định chung là quan trọng để quản lý dịch vụ và các giải pháp SOA và có thể cần mở rộng để xử lý bản chất hướng dịch vụ và ranh giới miền chéo của nhiều giải pháp SOA. Trong khi quản lý dịch vụ tập trung vào việc quản lý dịch vụ, quản lý SOA có phạm vi rộng hơn và quản lý toàn bộ giải pháp SOA hoặc tập các giải pháp SOA. Các loại quản lý phổ biến được sử dụng cho SOA giải pháp như sau.

– Quản lý và giám sát các hệ thống IT: cung cấp việc giám sát và quản lý các hệ thống và hạ tầng IT, bao gồm khả năng giám sát và nắm bắt số liệu và trạng thái của các hệ thống và hạ tầng IT. Điều này bao gồm quản lý các hệ thống ảo hóa.

– Quản lý và giám sát ứng dụng và giải pháp SOA: cung cấp việc giám sát và quản lý dịch vụ phần mềm và ứng dụng. Điều này bao gồm khả năng nắm bắt số liệu và để giám sát và quản lý ứng dụng và trạng thái giải pháp.

– Quản lý và giám sát hoạt động nghiệp vụ: cung cấp giám sát và quản lý các hoạt động nghiệp vụ và quá trình nghiệp vụ. Nó cung cấp khả năng phân tích thông tin sự kiện này cả trong thời gian thực/thời gian thực gần, cũng như lưu trữ (lưu kho) các sự kiện và để xem xét và đánh giá các hoạt động nghiệp vụ dưới dạng thông tin sự kiện và xác định sự đáp trả hoặc đưa ra cảnh báo/thông báo.

– Quản lý an toàn: quản lý và giám sát các giải pháp an toàn và an toàn. Điều này cung cấp khả năng quản lý các vai trò và bản sắc, quyền truy nhập và quyền lợi, bảo vệ dữ liệu phi cấu trúc và cấu trúc khỏi truy nhập trái phép và mất dữ liệu, giải quyết cách phần mềm, hệ thống và dịch vụ được phát triển và duy trì trong suốt vòng đời phần mềm, duy trì trạng thái an toàn thông qua các thay đổi chủ động phản ứng để xác định các lỗ hổng và các mối đe dọa mới, cho phép tổ chức quản lý rủi ro và tuân thủ IT liên quan và cung cấp cơ sở tự động hóa để quản lý an toàn.

– Quản lý sự kiện: cung cấp khả năng quản lý các sự kiện và cho phép xử lý, ghi nhật ký, kiểm toán sự kiện.

– Quản lý thay đổi và cấu hình. Hạng mục này về các khả năng cung cấp khả năng thay đổi giải pháp và cấu hình dịch vụ và mô tả.

– Giám sát và thực thi chính sách: cung cấp cơ chế giám sát và thực thi các quy tắc chính sách và nghiệp vụ cho giải pháp SOA và dịch vụ. Điều này bao gồm việc tìm kiếm và truy nhập các chính sách, đánh giá và thực thi các chính sách tại các điểm kiểm tra. Thực thi chính sách bao gồm việc thực thi khi các số liệu được thu thập, báo hiệu và ghi lại. Thực thi cũng gửi trạng thái hoặc chỉ số tuân thủ, cũng như thông báo và đăng nhập không tuân thủ.

– Quản lý vòng đời: cung cấp một cơ chế triển khai, bắt đầu/cho phép, ngừng/vô hiệu hóa và không triển khai các dịch vụ và các giải pháp SOA.

– Ngoài ra, quản trị SOA và dịch vụ phải sử dụng quản lý để thực sự thực hiện và thực thi quản trị các sách và quá trình. Việc quản trị các chính sách này cùng với các chính sách khác trong hệ thống an toàn, độ tin cậy, tính sẵn có, v.v.. là các quy tắc thúc đẩy các hệ thống quản lý.

B.6 Dịch vụ quản lý

Dịch vụ quản lý thể hiện tập các công cụ quản lý được sử dụng để giám sát các luồng dịch vụ, sức khỏe của hệ thống cơ sở, sử dụng tài nguyên, định danh sự cố và tắc nghẽn, đạt được mục đích dịch vụ, thực thi các chính sách quản trị và khôi phục từ thất bại. Ví dụ, khi thiết kế nghiệp vụ có thể được nắm bắt như là một mô hình và được sử dụng để ghép nối các dịch vụ giải pháp thực hiện thiết kế đó, tương quan giữa nghiệp vụ và hệ thống IT có thể được nắm bắt. Sự tương quan này, nếu được đưa vào môi trường triển khai, có thể được sử dụng bởi dịch vụ quản lý để giúp ưu tiên giải quyết các vấn đề bề mặt trong hệ thống thông tin hoặc chỉ đạo phân bổ khả năng thực thi cho các phần khác nhau của hệ thống dựa trên các mục đích mức độ dịch vụ chống lại thiết kế doanh nghiệp

Dịch vụ quản lý có thể được sử dụng trong các mô hình dịch vụ như là một phần của giải pháp SOA để vừa cho phép vừa quản lý dịch vụ chức năng và các giải pháp SOA.

Dịch vụ quản lý khác với các tác vụ chức năng và các tác vụ quản lý thực hiện trực tiếp bởi dịch vụ cho phép khả năng quản lý.

B.7 Quản lý siêu dữ liệu dịch vụ

Trong các môi trường SOA, khả năng quản lý siêu dữ liệu dịch vụ bổ sung và các tài liệu vật lý, chẳng hạn như các mô tả dịch vụ và các chính sách liên quan đến dịch vụ, trở nên cần thiết. Các đăng ký và kho lưu trữ cho phép khả năng này. Điều quan trọng là phải có điều này ngoài phát hiện các dịch vụ.

Một tập các thông tin dịch vụ là cần thiết để cho phép quản lý và ăng độ nối kết lỏng. Tập thông tin này cũng cho phép khả năng sử dụng các sổ đăng ký, kho lưu trữ, các chức năng tích hợp và liên kết miền chéo.

Thông tin cần thiết trong các cơ quan đăng ký có thể bao gồm các tài liệu vật lý mô tả một dịch vụ, các dẫn xuất lô-gic để truyền thông được cho phép và các thực thể liên quan đến dịch vụ để duy trì các quan hệ với các thực thể có khả năng bị ảnh hưởng.

Siêu dữ liệu cho các mô tả dịch vụ cần truy nhập có thể bao gồm: các thuộc tính dịch vụ (thông tin khác về dịch vụ), các quan hệ dịch vụ (thông tin về các quan hệ với dịch vụ) và phân loại dịch vụ (đối với mai mối).

Có các mô tả khác có thể cần thiết, cũng như để hiểu các miền dịch vụ, sự tích hợp (hoặc ESB) và liên kết dịch vụ.

B.8 An toàn SOA

An toàn SOA đề cập đến việc bảo vệ chống lại các mối đe dọa trên các khía cạnh dễ bị tổn thương của một kiến trúc theo định hướng dịch vụ, điều này bảo vệ sự tương tác giữa các khách hàng dịch vụ và các nhà cung cấp dịch vụ nhưng mà còn bảo vệ tất cả các phần tử góp phần vào kiến trúc.

Cách tiếp cận được sử dụng cho an toàn SOA tuân theo các phương pháp hay nhất của ngành, chẳng hạn như đề xuất được ITU-T phát triển trên X.805 và các tham số được đề cập trong thiết lập WS-An toàn (xem Tài liệu tham khảo [28]) về các tiêu chuẩn.

Sau đây là những mối đe dọa mà an toàn SOA cần phải giải quyết

– phá hoại (tấn công tính sẵn có): phá hoại thông tin và/hoặc tài nguyên và/hoặc các thành phần được truy nhập thông qua dịch vụ hoặc liên quan đến dịch vụ và vòng đời dịch vụ;

– làm sai lệch (tấn công tính toàn vẹn): giả mạo trái phép với một tài sản được truy nhập thông qua dich vụ hoặc liên quan đến dịch vụ và vòng đời dịch vụ;

– gỡ bỏ (tấn công tính sẵn có): trộm cắp, gỡ bỏ hoặc làm mất thông tin, và/hoặc các tài nguyên khác ảnh hưởng đến dịch vụ;

– tiết lộ (tấn công tính bảo mật): truy nhập trái phép vào một tài sản hoặc một dịch vụ;

– gián đoạn (tấn công tính sẵn có): gián đoạn dịch vụ. Dịch vụ phải không sẵn có hoặc không sử dụng được.

Tám thứ nguyên về an toàn được yêu cầu để bảo vệ chống lại các mối đe dọa là:

a) Kiểm soát truy nhập: giới hạn và kiểm soát quyền truy nhập vào dịch vụ và phần tử bằng cách sử dụng thẻ kiểm soát, các thành phần và các phần tử: mật khẩu, danh sách kiểm soát truy nhập, tường lửa.
b) Xác thực: cung cấp bằng chứng định danh việc sử dụng dịch vụ hoặc bất kỳ thành phần nào trong việc sử dụng SOA, ví dụ, bí mật dùng chung, PKI hoặc các chữ ký số. Nên lưu ý rằng khi SOA giải quyết mối tương tác giữa các khách hàng dịch vụ và các nhà cung cấp dịch vụ, bằng chứng định danh phải được thực thi giữa khách hàng ban đầu và nhà cung cấp dịch vụ cuối cùng. Trong các dàn dựng dịch vụ, phải có nhiều tác nhân khác có thể phải được xác thực. Một khía cạnh mà SOA phải quản lý là khi dịch vụ được đưa ra giữa hai hoặc nhiều thực thể là các tổ chức và có nguy cơ là những tác nhân rời khỏi hoặc tham gia các thực thể này phải làm cho môi trường rất khó quản lý. Đây là lý do tại sao các định danh liên kết thực hiện mô hình tin cậy giữa các thực thể thường được sử dụng trên SOA, với việc truyền các mã xác nhận cung cấp xác thực nhất quán của người yêu cầu ban đầu thông qua giao thức đáng tin cậy giữa các thành phần. Một ví dụ là WS-liên kết (xem Tài liệu tham khảo [29]).
c) Chống chối bỏ: ngăn chặn khả năng từ chối một hoạt động trên các thành phần hoặc các phần tử trong kiến trúc theo định hướng dịch vụ đã xảy ra. Ví dụ bao gồm: các nhật ký hệ thống và chữ ký kỹ thuật số bảo vệ các thông điệp với chữ ký – XML. Trong dịch vụ các dàn dựng phải có nhiều tác nhân tương tác và có thể cần thiết để duy trì một dấu vết của tất cả các hành động từ tất cả tác nhân.
d) Bảo mật dữ liệu: đảm bảo tính bảo mật của dữ liệu được trao đổi trong tương tác dịch vụ hoặc được quản lý bởi các thành phần kiến trúc. Để tránh những tiết lộ không cần thiết, bảo mật có thể phải được thực thi giữa khách hàng dịch vụ ban đầu và nhà cung cấp dịch vụ cuối cùng mà không bị gián đoạn. Một ví dụ là bảo vệ các thông điệp bằng cách sử dụng mã hóa với XML-Mã hóa.
e) An toàn truyền thông: đảm bảo chỉ các luồng thông tin từ nguồn mong đợi đến đích mong đợi. Ví dụ: sử dụng HTTPS, VPN, MPLS, L2TP. Trong kiến trúc SOA, việc xác nhận mức ứng dụng hoặc mức giải pháp trên các ranh giới thành phần có thể trở nên cần thiết để kiểm soát các nguồn và đích đến vào và ra.
f) Tính toàn vẹn dữ liệu: đảm bảo rằng dữ liệu được nhận như đã gửi hoặc được truy hồi như được lưu trữ trong tất cả mối tương tác giữa các thành phần dịch vụ, cho dù chúng là dành cho mục đích quản lý SOA hoặc vòng đời hoặc cho mối tương tác giữa các khách hàng dịch vụ và các nhà cung cấp. Ví dụ: chữ ký số với Chữ ký-XML, phần mềm chống vi-rút. Chữ ký XML chỉ nên được xử lý ở cuối tương tác dịch vụ để tránh tại vi phạm trong bất kỳ nút nào khác nhau có thể cấu thành kiến trúc giữa khách hàng dịch vụ và nhà cung cấp.
g) Tính sẵn có: đảm bảo các phần tử, dịch vụ và các thành phần sẵn có cho người sử dụng hợp pháp. Điều này phải được phối hợp với các SLA và siêu dữ liệu hợp đồng khác qui định các điều kiện sử dụng dịch vụ.
h) Riêng tư: đảm bảo định danh, sử dụng dịch vụ và quản lý dịch vụ được giữ riêng.

B.9 Quản trị an toàn SOA

Quản trị an toàn SOA là một miền quản trị cụ thể giải quyết an toàn SOA.

– Chức năng an toàn SOA: Quản trị an toàn SOA kiểm soát vòng đời các thành phần cung cấp các chức năng cho tám vấn đề an toàn để bảo vệ năm mối đe dọa được liệt kê dưới trước đó.

– Hạ tầng chính sách an toàn: Quản trị an toàn SOA xác định và thực thi thành phần quản lý các chính sách an toàn, phân phối các chính sách an toàn và chuyển đổi cho phù hợp các thành phần và các phần tử SOA, quyết định chính sách an toàn và các thành phần thực thi và cuối cùng là các thành phần giám sát và báo cáo về các chính sách an toán sử dụng và tuân thủ.

– Quá trình an toàn SOA: Quản trị an toàn SOA xác định IT và quá trình nghiệp vụ về rủi ro và sự phù hợp, quản lý tin cậy, định danh và vòng đời kiểm soát truy nhập, bảo vệ dữ liệu và kiểm soát tiết lộ và cuối cùng, an toàn cho tất cả các thành phần trong một kiến trúc theo định hướng dịch vụ, chẳng hạn như các đăng ký, ESB, v.v… Trong một môi trường đa thực thể, các quá trình này có thể bao gồm định nghĩa và trao đổi chứng chỉ hoặc khóa công khai giữa tác nhân tin cậy trước khi cho phép tác nhân khác trong các thực thể để tương tác.

Tính bảo mật và chống chối bỏ có thể làm tăng kích thước và dung lượng thông điệp do thông tin bổ sung cần thiết, chẳng hạn như chứng chỉ và thời gian xử lý bổ sung để quản lý chữ ký.

Thư mục tài liệu tham khảo

[1] ISO/IEC 2382, Information technology – Vocabulary

[2] ISO/IEC/IEEE 15288, Systems and software engineering – System life cycle processes

[3] ISO/IEC 12207, Systems and software engineering – Software life cycle processes

[4] ISO/IEC/IEEE 42010, Systems and software engineering – Architecture description

[5] ISO/IEC 10746-2, Information technology – Open distributed processing – Reference model: Foundations – Part 2

[6] ISO/IEC JTC 1/SC 38 N0043, Research Report on China’s SOA Standards System

[7] ISO/IEC JTC 1/SC 38 N0022, Chinese National Body Contribution on Proposed NP for General Technical Requirement of Service Oriented Architecture

[8] OASIS. Reference Model for SOA. Version 1.0, OASIS Standard, October 2006: Available from World Wide Web: http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf

[9] TCVN 12482-3 (ISO/IEC 18384-3), Công nghệ thông tin-Kiến trúc tham chiếu cho kiến trúc hướng dịch vụ (SOA SA)-Phần 3: Bản thể học kiến trúc hướng dịch vụ

[10] ISO/IEC 17998, Information technology – SOA Governance Framework

[11] ISO/IEC 15474-1, Information technology – COIF framework – Part 1: Overview

[12] ISO/IEC 16500-8, Information technology – Generic digital audio-visual systems – Part 8: Management architecture and protocols

[13] ISO/IEC 38500:2008,2) Information technology – Governance of IT for the organization

[14] OMG. Business Process Management Notation (BPMN), see http://www.omg.org/spec/BPMN/2.0/

[15] ISO/TR 9007, Information processing systems – Concepts and terminology for the conceptual schema and the information base

[16] The Open Group Architecture Framework (TOGAF), section 8.1.1 Version 9 Enterprise Edition, February 2009; see www.opengroup.org/togaf

[17] OASIS. Reference Architecture for SOA Foundation, Version 1.0, OASIS Committee Specification, 4 December 2012: see http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-v1.0-cs01.pdf

[18] W3C Web Services Description Language (WSDL) 1.1, W3C Note 15 March 2001, see http://www.w3.org/TR/wsdl

[19] OASIS. Web Services for Remote Portlets Specification v2.0 OASIS Standard, 1 April 2008 (WSRP), see http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-spec.html

[20] OMG. Model Driven Architecture (MDA) Guide, Version 1.0.1, Object Management Group (OMG), June 2003: see www.omg.org/docs/omg/03-06-01.pdf

[21] OMG. Unified Modeling Language (OMG UML), Superstructure, Version 2.2, OMG Doc. No.: formal/2009-02-02, Object Management Group (OMG), February 2009: see www.omg.org/spec/UML/2.2/Superstructure

[22] OMG. SOA Modeling Language (OMG SoaML) Specification for the UML Profile and Metamodel for Services (UPMS), Revised Submission, OMG Doc. No.: ad/2008-11-01 Object Management Group (OMG), November 2008 see www.omg.org/cgi-bin/doc?ad/08-11-01

[23] W3C Web Ontology Language (OWL), World Wide Web Consortium (W3C), April 2009: see www.w3.org/2007/OWL/wiki/OWL_Working_Group

[24] Garrett J.J. A New Approach to Web Applications, Feb 18, 2005 see http://www.adaptivepath.com/ideas/ajax-new-approach-Web-applications

[25] OASIS Web Services Coordination (WS-Coordination) Version 1.2, OASIS Standard, Feb 2, 2009, http://docs.oasis-open.org/ws-tx/wstx-wscoor-1.2-spec-os.pdf

[26] Web Services Atomic Transaction (WS-Atomic Transaction) Versions 1.2 OASIS Standard, Feb 2, 2009, http://docs.oasis-open.org/ws-tx/wstx-wsat-1.2-spec-os.pdf

[27] Web Services Business Activity (WS-Business Activity) Version 1.2 OASIS Standard, Feb 2. 2009, http://docs.oasis-open.org/ws-tx/wstx-wsba-1.2-spec-os.pdf

[28] Web Services Security (WS-Security) Version 1.1 OASIS Standard, Feb 1, 2006. http://docs.oasis-open.org/wss/v1.1/

[29] Web Services Federation (WS-Federation) Version 1.2 OASIS Standard, May 22, 2009, http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.doc

[30] ISO/IEC 20926, Software and systems engineering – Software measurement – IFPUG functional size measurement method 2009

[31] ISO/IEC 19505-2, Information technology – Object Management Group Unified Modeling Language (OMG UML) – Part 2: Superstructure

MỤC LỤC

1 Phạm vi áp dụng

2 Thuật ngữ và định nghĩa

3 Thuật ngữ viết tắt

4 Ký hiệu

5 Quy ước

6 Sự phù hợp

7 Các khái niệm SOA

8 Các nguyên tắc kiến trúc SOA

Phụ lục A (tham khảo) Khung quản trị SOA

Phụ lục B (tham khảo) Mối quan tâm về quản lý và an toàn

Thư mục tài liệu tham khảo

TIÊU CHUẨN QUỐC GIA TCVN 12482-1:2019 (ISO/IEC 18384-1:2016) VỀ CÔNG NGHỆ THÔNG TIN – KIẾN TRÚC THAM CHIẾU CHO KIẾN TRÚC HƯỚNG DỊCH VỤ – PHẦN 1: THUẬT NGỮ VÀ KHÁI NIỆM CHO KIẾN TRÚC HƯỚNG DỊCH VỤ
Số, ký hiệu văn bản	TCVN12482-1:2019	Ngày hiệu lực
Loại văn bản	Tiêu chuẩn Việt Nam	Ngày đăng công báo
Lĩnh vực	Xây dựng Giao dịch điện tử	Ngày ban hành	01/01/2019
Cơ quan ban hành		Tình trạng	Còn hiệu lực

Các văn bản liên kết

Văn bản được hướng dẫn		Văn bản hướng dẫn
Văn bản được hợp nhất		Văn bản hợp nhất
Văn bản bị sửa đổi, bổ sung		Văn bản sửa đổi, bổ sung
Văn bản bị đính chính		Văn bản đính chính
Văn bản bị thay thế		Văn bản thay thế
Văn bản được dẫn chiếu		Văn bản căn cứ

Tải văn bản

Tải văn bản về Bản PDF/Bản gốc