TIÊU CHUẨN QUỐC GIA TCVN 12482-3:2019 (ISO/IEC 18384-3: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 3: BẢN THỂ HỌC KIẾN TRÚC HƯỚNG DỊCH VỤ

TIÊU CHUẨN QUỐC GIA

TCVN 12482-3:2019

ISO/IEC 18384-3: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 3: BẢN THỂ HỌC KIẾN TRÚC HƯỚNG DỊCH VỤ

Information Technology – Reference Architecture for Service Oriented Architecture (SOA RA) – Part 3: Service Oriented Architecture Ontology

Lời nói đầu

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

TCVN 12482-3: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 3: BẢN THỂ HỌC KIẾN TRÚC HƯỚNG DỊCH VỤ

Information Technology – Reference Architecture for Service Oriented Architecture (SOA RA) – Part 3: Service Oriented Architecture Ontology

1  Phạm vi áp dụng

Tiêu chuẩn này quy định bản thể học chính thức cho kiến trúc hướng dịch vụ (SOA), kiểu kiến trúc hỗ trợ định hướng dịch vụ. Các thuật ngữ được định nghĩa trong bản thể học này là các thuật ngữ chính từ bộ từ vựng trong TCVN 12482-1 (ISO/IEC 18384-1).

2  Tài liệu viện dẫn

Các tài liệu viện dẫn sau rất cần thiết cho việc áp dụng tiêu chuẩn này. Đối với các tài liệu viện dẫn ghi năm công bố thì áp dụng phiên bản được nêu. Đối với các tài liệu viện dẫn không ghi năm công bố thì áp dụng phiên bản mới nhất, bao gồm cả các sửa đổi, bổ sung (nếu có).

TCVN 12482-1 (ISO/IEC 18384-1), Công nghệ thông tin – Kiến trúc tham chiếu cho kiến trúc hướng dịch vụ (SOA RA) – Phần 1: Thuật ngữ và khái niệm về SOA.

3  Thuật ngữ, định nghĩa và từ viết tắt

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

Tiêu chuẩn này sử dụng các thuật ngữ và định nghĩa được quy định trong TCVN 12482-1 (ISO/IEC 18384-1) và các thuật ngữ và định nghĩa dưới đây.

3.1.1

Tính mờ (opaque)

Thuộc tính mà bên quan sát bên ngoài không thể nhìn thấy bất kỳ cấu trúc bên trong nào.

3.1.2

Bản thể học (ontology)

Mô hình thể hiện một miền và được sử dụng để lập luận về các đối tượng trong miền đó và các mối quan hệ giữa các đối tượng.

CHÚ THÍCH 1  Tiêu chuẩn này quy định mức cao và không sử dụng cho cách lập luận chính thức.

[NGUỒN: 2.1.9, ISO/IEC/TR 24800-1:2007]

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

Tiêu chuẩn này sử dụng các thuật ngữ viết tắt sau đây.

ABB	Architecture Building Block	Khối xây dựng kiến trúc
BPMN	Business Process Model and Notation	Mô hình và ký hiệu quá trình nghiệp vụ
EA	Enterprise Architecture	Kiến trúc doanh nghiệp
ESB	Enterprise Service Bus	Bus dịch vụ doanh nghiệp
IT	Information Technology	Công nghệ thông tin
OWL	Web Ontology Language	Ngôn ngữ bản thể học web
RA	Reference Architecture	Kiến trúc tham chiếu
RDF	Resource Definition Framework	Khung định nghĩa tài nguyên
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ụ
UML	Unified Modeling Language	Ngôn ngữ lập mô hình thống nhất

4  Ký hiệu

Bản thể học được thể hiện trong ngôn ngữ bản thể Web (OWL) được xác định bởi Hiệp hội World Wide Web OWL có ba ngôn ngữ con OWL-Lite, OWL-DL và OWL-Full (xem Tham khảo [10] về định nghĩa ba phương ngữ của OWL). Bản thể học này sử dụng OWL-DL, ngôn ngữ con cung cấp khả năng diễn đạt lớn nhất có thể trong khi vẫn giữ được tính đầy đủ và khả năng quyết định tính toán.

Bản thể học chứa các lớp và thuộc tính tương ứng với các khái niệm của SOA. Các định nghĩa OWL chính thức được bổ sung bằng các mô tả ngôn ngữ tự nhiên của khái niệm, với các minh họa đồ họa về mối quan và ví dụ về cách sử dụng. Để giải thích, bản thể học cũng bao gồm các sơ đồ UML (xem Tham khảo [8]) minh họa đồ họa các lớp và thuộc tính về bản thể học. Ngôn ngữ tự nhiên và các định nghĩa OWL có trong tiêu chuẩn này cấu thành định nghĩa về thẩm quyền bản thể học; các sơ đồ chỉ giải thích. Một số thuật ngữ ngôn ngữ tự nhiên được sử dụng để mô tả các khái niệm không được biểu thị chính thức trong bản thể học, những thuật ngữ này có nghĩa theo ngôn ngữ tự nhiên.

Tính sẵn có của khuôn dạng RDF tiêu chuẩn thể hiện OWL cho phép dễ dàng tải vào các công cụ cho các nhà kiến trúc và các nhà phát triển và cho phép xác thực.

Tiêu chuẩn này sử dụng ví dụ để minh họa bản thể học. Trong đó, ví dụ rửa xe được sử dụng nhất quán xuyên suốt để minh họa các khái niệm chính (xem Phụ lục A để biết ví dụ hoàn chỉnh). Ví dụ khác được sử dụng đặc biệt trong các mệnh đề riêng để minh họa các điểm cụ thể.

5  Quy ước

Phông chữ đậm được sử dụng cho các lớp, thuộc tính OWL và tên cụ thể xuất hiện trong văn bản mệnh đề.

Phông in nghiêng được sử dụng để nhấn mạnh và xác định trường hợp đầu tiên của từ cần định nghĩa. Cú pháp và định nghĩa OWL được hiển thị bằng phông chữ có chiều rộng cố định.

Mũi tên không ghi nhãn trong các sơ đồ UML là lớp con.

Ví dụ trong tiêu chuẩn này mang tính tham khảo và nhằm mục đích minh họa.

6  Sự phù hợp

TCVN 12482 (ISO/IEC 18384) gồm ba phần có các yêu cầu phù hợp khác nhau:

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

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

Có hai kiểu ứng dụng có thể phù hợp với bản thể học này. Một là các bản thể học dựa trên OWL (thường các mở rộng của bản thể học SOA); Hai là ứng dụng phi OWL, chẳng hạn như siêu mô hình hoặc phần mềm (xem Điều 2 đối với phiên bản OWL được yêu cầu)

Ứng dụng OWL phù hợp (được trích dẫn từ bản thể học dựa trên OWL)

– phải phù hợp với tiêu chuẩn OWL quy định trong Điều 2,

– phải gồm toàn bộ bản thể học có trong Phụ lục C,

– có thể bổ sung các cấu trúc OWL khác, bao gồm các định nghĩa lớp và thuộc tính, và

– có thể nhập các bản thể học khác ngoài bản thể học SOA.

Tiêu chuẩn này không sử dụng bất kỳ OWL 2 nào (xem các cấu trúc tham chiếu [15]); tuy nhiên các ứng dụng phù hợp có thể chọn sử dụng OWL hoặc OWL 2.

Ứng dụng phi OWL phù hợp

– phải gồm một sự biến đổi nhất quán và xác định (ít nhất là ánh xạ ngữ nghĩa) cho tập con quan trọng của bản thể học có trong Phụ lục C,

– có thể bổ sung các cấu trúc khác, bao gồm các định nghĩa lớp và thuộc tính, và

– có thể nhập vào và/hoặc sử dụng các bản thể học khác ngoài bản thể học SOA.

7  Tổng quan bản thể học SOA

7.1  Sơ lược

Trực quan hóa bằng đồ họa của toàn bộ bản thể học được thể hiện trong Hình 1.

Các khái niệm minh họa trong Hình 1 được mô tả trong nội dung.

Tiêu chuẩn này bắt đầu bằng cách giải thích khái niệm nền tảng cơ bản nhất của phần tử và các hệ thống theo sau bằng cách giải thích các phần tử của tác vụ và tác nhân con người SOA sau đó các khái niệm và mô tả dịch vụ và các hợp đồng dịch vụ và xây dựng để giải thích các tổ hợp dịch vụ. Cuối cùng, Tiêu chuẩn này kết thúc với các chính sách và sự kiện có liên quan đến tất cả các phần tử SOA.

Hình 1 – Bản thể học SOA – Tổng quan đồ họa

7.2  Sử dụng

Điều này mô tả các cảnh báo và giả định về cách diễn giải bản thể học.

– Bản thể học dự định cho thể hiện mức cao của khái niệm và không diễn giải cho lập luận chính thức

– Tiêu chuẩn này được thiết kế để người làm nghiệp vụ, nhà kiến trúc và nhà thiết kế phần mềm và hệ thống cho phép truyền thông giữa người làm nghiệp vụ và người làm kỹ thuật.

– Tiêu chuẩn này tập trung vào một tập tối thiểu các thuật ngữ SOA và việc lập mô hình chi tiết các thuật ngữ đó.

– Tiêu chuẩn này giải thích các mối quan hệ với các khái niệm quan trọng khác, nhưng không ở mức chi tiết như các thuật ngữ SOA. Ví dụ, chính sách được lập mô hình nhưng không chi tiết.

– Tiêu chuẩn này tự giới hạn đối với các cấu trúc OWL, không sử dụng các cấu trúc được giới thiệu trong OWL 2 (xem Tham khảo [15]), vì các khái niệm OWL phù hợp với phạm vi của tiêu chuẩn này. Tiêu chuẩn này phù hợp với OWL 2 và không loại trừ sự vật, sự việc khác khi sử dụng với OWL 2.

– Tiêu chuẩn này xây dựng trên các thuật ngữ SOA và các mối quan hệ trong TCVN 12482-1 (ISO/IEC 18384-1) và TCVN 12482-2 (ISO/IEC 18384-2). Siêu mô hình riêng biệt trong TCVN 12482-2 (ISO/IEC 18384-2) cung cấp cơ sở cho việc lập mô hình trong TCVN 12482-2 (ISO/IEC 18384-2) và được sử dụng để mô tả và hiểu kiến trúc tham chiếu.

– Tiêu chuẩn này xác định các khái niệm, thuật ngữ và ngữ nghĩa SOA trong các thuật ngữ nghiệp vụ và kỹ thuật để tạo nền tảng cho công việc tiếp theo trong các lĩnh vực cụ thể theo miền.

– Tiêu chuẩn này cung cấp phương tiện để nêu rõ các vấn đề và cơ hội và một cách rõ ràng để thúc đẩy sự hiểu biết lẫn nhau.

– Tiêu chuẩn này có thể cung cấp điểm khởi đầu cho việc phát triển hướng mô hình các giải pháp SOA.

7.3  Ứng dụng

Bản thể học SOA được phát triển để hỗ trợ sự hiểu biết và có thể đọc một cách đơn giản.

Bản thể học cũng có thể được sử dụng như điểm khởi đầu để phát triển hướng mô hình, bằng cách áp dụng cho các miền và ứng dụng sử dụng cụ thể.

Bản thể học được áp dụng cho một miền sử dụng cụ thể bằng cách thêm lớp SOA OWL của thực thể trong miền đó. Điều này đôi khi được gọi là “bản thể học cư trú”. Ngoài ra, ứng dụng có thể bổ sung các định nghĩa về các lớp và thuộc tính mới, có thể nhập các bản thể học khác và có thể nhập thể hiện OWL bản thể học vào các bản thể học khác.

Bản thể học xác định mối quan hệ giữa các thuật ngữ, nhưng không quy định chính xác cách áp dụng chúng. Để giải thích bản thể học là gì và tại sao chúng cần thiết, xem Tham khảo [11] và [14]. Ví dụ được cung cấp trong TCVN 12482 (ISO/IEC 18384) được mô tả một cách mà bản thể học có thể được áp dụng trong các tình huống thực tế. Các ứng dụng khác nhau của bản thể học cho các tình huống tương tự vẫn có thể có. Việc khởi tạo chính xác bản thể học trong các tình huống thực tế cụ thể là một vấn đề cho người sử dụng bản thể học, miễn là các khái niệm và các ràng buộc được xác định bởi bản thể học được áp dụng đúng, sự khởi tạo là hợp lệ.

8  Hệ thống và phần tử

8.1  Tổng quan

Hệ thống và phần tử là hai khái niệm trong bản thể học, các khái niệm này thường được sử dụng bởi người thực hành, bao gồm ký hiệu rằng các hệ thống có các phần tử và hệ thống đó có thể được kết hợp theo thứ bậc (hệ thống các hệ thống). Điều khác biệt giữa miền với miền là bản chất cụ thể của các hệ thống và phần tử, ví dụ, hệ thống điện có rất nhiều kiểu phần tử khác nhau hơn so với một hệ thống SOA.

Trong bản thể học, chỉ xem xét các phần tử và hệ thống trong miền SOA. Một vài miền con SOA sử dụng thuật ngữ thành phần, không dùng thuật ngữ phần tử. Điều này không mâu thuẫn, vì bất kỳ thành phần nào của hệ thống SOA cũng là một phần tử của hệ thống (Tổ hợp) đó.

Điều này mô tả các lớp bản thể học sau:

Element (Phần tử)

System (Hệ thống)

Ngoài ra, xác định các thuộc tính sau:

uses (sử dụng) và representedBy (được sử dụng bởi)

represents (thể hiện) và representedBy (thể hiện bởi)

8.2  Lớp Element (Phần tử)

Phần tử là một thực thể có tính mở và không thể phân chia ở mức trừu tượng nhất định. Phần tử có một ranh giới xác định rõ ràng. Khái niệm phần tử được thu nạp bởi lớp Element (Phần tử) OWL, minh họa trong Hình 2.

Hình 2 – Lớp Element (Phần tử)

Trong bối cảnh bản thể học SOA, chỉ xem xét chi tiết các phần tử chức năng thuộc miền SOA. Có các kiểu phần tử khác ngoài bốn lớp con (System (Hệ thống), HumanActor (Tác nhân con người), Task (Tác vụ) và Service (Dịch vụ)) được mô tả trong phần sau. Ví dụ về các kiểu phần tử khác như các thành phần phần mềm hoặc các thành phần công nghệ (chẳng hạn như các phần mềm triển khai Bus dịch vụ doanh nghiệp (ESB), v.v).

8.3  Các thuộc tính Uses (sử dụng) và representedBy (được sử dụng bởi)

Các phần tử có thể sử dụng các phần tử khác theo nhiều cách khác nhau. Nói chung, quan niệm về một vài phần tử sử dụng phần tử khác được áp dụng bởi người thực hành đối với tất cả các mô hình, các đối tượng vật lý và có thể thực thi. Điều khác biệt các miền là cách thức sử dụng được nhận thức.

Một phần tử sử dụng một phần tử khác nếu hai phần tử đó tương tác với nhau theo một số cách thức. Các tương tác ở đây được diễn giải rất rộng thông qua, ví dụ, phần tử đơn giản là một thành phần của (được sử dụng bởi) một số hệ thống (xem sau một định nghĩa chính thức của lớp System (Hệ thống)). Một phần tử tương tác với (đang sử dụng) phần tử khác (chẳng hạn như dịch vụ; xem sau một định nghĩa chính thức về lớp Service (Dịch vụ)) theo một cách đặc biệt, hoặc thậm chí sự phụ thuộc vào một tổ hợp (xem sau một định nghĩa chính thức của lớp Composition (Tổ hợp)). Thuộc tính uses (sử dụng) và ngược lại representedBy (được sử dụng bởi), thu nạp quan niệm trừu tượng về một phần tử sử dụng phần tử khác. Các thuộc tính này không chỉ thu nạp mối quan hệ nhất thời. Các minh họa về thuộc tính có thể gồm “sử dụng ngay lập tức”, “đã sử dụng” và “có thể sử dụng trong tương lai”.

Đối với mục đích bản thể học, vô số ngữ nghĩa có thể khác nhau về mối quan hệ sử dụng không được liệt kê và được xác định chính thức. Các giải thích ngữ nghĩa được để lại cho một miền con cụ thể, ứng dụng hoặc thậm chí thiết kế cách tiếp cận.

8.4  Element (Phần tử) – Ví dụ về tổ chức

Sử dụng ví dụ về tổ chức, các trường hợp điển hình của Element (Phần tử) là các đơn vị tổ chức và con người. Việc cảm nhận một phần của tổ chức như đơn vị tổ chức hay là tập con người trong đơn vị tổ chức đó là một sự lựa chọn quan trọng của mức độ trừu tượng.

Bên trong ranh giới của đơn vị tổ chức, khi đơn vị tổ chức có thể sử dụng con người thực tế là thành phần. Lưu ý rằng cùng một người trong thực tế có thể là thành phần của (được sử dụng bởi) nhiều đơn vị tổ chức.

Ngoài ranh giới, cấu trúc bên trong của một đơn vị tổ chức vẫn không rõ ràng đối với bên quan sát bên ngoài, vì doanh nghiệp muốn có thể thay đổi người trong đơn vị tổ chức mà không phải thay đổi định nghĩa của chính đơn vị tổ chức.

Ví dụ đơn giản này cho thấy một số phần tử có cấu trúc bên trong. Trong thực tế, từ quan điểm bên trong, chúng là một tập hợp có tổ chức các thứ đơn giản khác (được thu nạp bởi lớp System (Hệ thống) được định nghĩa trong 8.5).

8.5  Lớp System (Hệ thống)

Hệ thống là một tập hợp có tổ chức của các sự vật, sự việc khác. Cụ thể, sự vật, sự việc trong tập hợp hệ thống là các trường hợp Element (Phần tử), mỗi trường hợp như vậy được sử dụng bởi hệ thống. Khái niệm về hệ thống được thu nạp bởi lớp OWL System (Hệ thống), minh họa trong Hình 3.

Hình 3 – Lớp System (Hệ thống)

Định nghĩa về hệ thống này ảnh hưởng của ISO/IEC 42010:2011 (xem Tham khảo [13]).

Trong bối cảnh bản thể học SOA, chỉ xem xét chi tiết các hệ thống chức năng thuộc miền SOA. Lưu ý rằng trường hợp mô tả đầy đủ về System (Hệ thống) nên có bản chất (như một tập hợp), một mối quan hệ part of (một phần của) với ít nhất một trường hợp Element (Phần tử).

Do System (Hệ thống) là một lớp con của Element (Phần tử), nên tất cả hệ thống có một ranh giới và mở đối với bên quan sát bên ngoài (quan sát hộp đen). Điều này loại trừ khỏi các cấu trúc lớp System (Hệ thống) không có ranh giới xác định. Từ quan điểm SOA, đây không thực sự là một sự mất mát vì tất cả các System (Hệ thống) SOA thú vị đều có đặc tính có thể nhận thức được từ quan điểm bên ngoài (khách hàng). Hơn nữa, có System (Hệ thống) như lớp con của Element (Phần tử) cho phép chúng ta tự nhiên thể hiện quan niệm về hệ thống các hệ thống – các hệ thống cấp thấp hơn chỉ đơn giản là các phần tử được sử dụng bởi hệ thống mức cao hơn.

Đồng thời khi hỗ trợ một điểm nhìn bên ngoài (quan sát hộp đen), tất cả các hệ thống cũng hỗ trợ một điểm nhìn bên trong (xem hộp màu trắng) thể hiện cách chúng là một tập hợp có tổ chức. Như ví dụ, đối với quan niệm về một dịch vụ thường tương ứng với một cách nhìn đặc tả dịch vụ so với cách nhìn thực hiện dịch vụ (tương tự như cách SoaML [9] xác định các dịch vụ như có cả hộp đen/phần đặc tả và hộp màu trắng/phần thực hiện).

Điều quan trọng để nhận ra rằng mặc dù các hệ thống sử dụng các phần tử thể hiện một khía cạnh quan trọng của thuộc tính uses (sử dụng), không cần thiết phải “phát minh ra” một hệ thống chỉ để thể hiện một số phần tử sử dụng khác. Trên thực tế, ngay cả đối với các hệ thống, có thể cần phải thể hiện rằng chúng có thể sử dụng các phần tử ngoài ranh giới của chúng – mặc dù điều này trong nhiều trường hợp tốt nhất là không được thể hiện ở cấp độ hệ thống, mà thay vào đó là phần tử của việc sử dụng hệ thống bên ngoài trường hợp Element (Phần tử).

Hệ thống được định nghĩa là sự phân chia các lớp Service (Dịch vụ) và Tác vụ. Các trường hợp lớp này không được coi là các tập hợp của cái khác. System (Hệ thống) đặc biệt không được định nghĩa là sự phân chia lớp HumanActor (Tác nhân con người) khi một tổ chức có nhiều trường hợp trên thực tế chỉ là một kiểu hệ thống cụ thể. Một lớp giao nhau đặc biệt để thể hiện thực tế này không được xác định.

8.6  System (Hệ thống) – Ví dụ

8.6.1  Ví dụ về tổ chức

Tiếp tục ví dụ về tổ chức từ 8.5, đơn vị tổ chức có thể được thể hiện như một trường hợp System (Hệ thống) có con người là thành phần (và các trường hợp phần tử) trong hệ thống.

8.6.2  Ví dụ tổ hợp dịch vụ

Việc sử dụng ví dụ tổ hợp dịch vụ các dịch vụ A và B là những trường hợp Element (Phần tử) và tổ hợp của A và B là một trường hợp System (Hệ thống) (sử dụng A và B). Điều quan trọng là nhận ra rằng hành động kết hợp khác với tổ hợp như một sự vật – thuật ngữ tổ hợp được dùng theo nghĩa sau.

Xem Điều 11 đối với định nghĩa chính thức về các khái niệm dịch vụ và tổ hợp dịch vụ (và lặp lại ví dụ trong bối cảnh chính xác hơn).

8.6.3  Ví dụ rửa xe ô tô

Xem xét một doanh nghiệp rửa xe. Công ty nói chung là một đơn vị tổ chức và có thể được khởi tạo trong bản thể học theo cách sau:

– CarWashBusiness (Nghiệp vụ rửa xe ô tô) là một trường hợp System (Hệ thống).

– Joe (chủ sở hữu) là một trường hợp Element (Phần tử) và được sử dụng bởi (chủ sở hữu của) CarWashBusiness (Nghiệp vụ rửa xe ô tô).

– Mary (thư ký) là một trường hợp Element (Phần tử) và được sử dụng bởi (người làm công cho) CarWashBusiness (Nghiệp vụ rửa xe ô tô).

– John (người rửa sơ bộ trước) là một trường hợp Element (Phần tử) và được sử dụng bởi (người làm công cho) CarWashBusiness (Nghiệp vụ rửa xe ô tô).

– Jack (người quản lý và vận hành rửa xe) là một trường hợp Element (Phần tử) và được sử dụng bởi (người làm công cho) CarWashBusiness (Nghiệp vụ rửa xe ô tô).

8.7  Thuộc tính represents (thể hiện) và representedBy (thể hiện bởi)

Môi trường được mô tả bởi một SOA có bản chất tổ hợp theo thứ bậc (xem 11.2 đối với định nghĩa về lớp Tổ hợp); nói cách khác, các phần tử của hệ thống SOA có thể được biên soạn lặp lại theo các mức trừu tượng cao hơn. Một khía cạnh của điều này đã được giải quyết bằng cách uses (sử dụng) và representedBy (được sử dụng bởi) các thuộc tính trong đó quan niệm về hệ thống các hệ thống có thể được thể hiện. Đây vẫn là một mối quan hệ rất cụ thể và không thể hiện khái niệm trừu tượng kiến trúc. Nhu cầu trừu tượng kiến trúc được tìm thấy ở nhiều nơi, như vai trò thể hiện các người đóng vai trò đó, đơn vị tổ chức thể hiện các người bên trong nó (khác biệt khó thấy so với cùng đơn vị tổ chức đó sử dụng người trong nó, như mối quan hệ represents (thể hiện) chỉ ra đơn vị tổ chức như điểm tương tác thay thế), khối xây dựng kiến trúc thể hiện cấu trúc cơ sở (ví dụ, quan trọng đối với kiến trúc sư doanh nghiệp muốn phân biệt rõ ràng giữa các cấu trúc và khối xây dựng) và một bus dịch vụ doanh nghiệp (ESB) thể hiện các dịch vụ có thể truy cập thông qua nó (ví dụ, có liên quan khi tương tác và phụ thuộc vận hành lập mô hình rõ ràng). Khái niệm về quan điểm thay đổi rõ ràng, hoặc mức trừu tượng, được thu nạp bởi represents (thể hiện) và representedBy (thể hiện bởi) các thuộc tính minh họa trong Hình 4.

Hình 4 – Thuộc tính represents (thể hiện) và representedBy (thể hiện bởi)

Điều quan trọng là phải hiểu bản chất khác biệt giữa việc sử dụng một phần tử (E1) và sử dụng một phần tử khác (E2) thể hiện E1. Nếu E1 thay đổi, thì bất kỳ ai sử dụng E1 trực tiếp đều có thể thay đổi, nhưng ai đó đang sử dụng E2 không gặp bất kỳ thay đổi nào.

Khi áp dụng sự trừu tượng kiến trúc thông qua thuộc tính represents (thể hiện), có ba sự lựa chọn kiến trúc khác nhau có thể được thực hiện:

Một phần tử thể hiện phần tử khác theo nghĩa đen, đơn giản bởi việc che giấu sự tồn tại của phần tử đó và mọi thay đổi đối với nó. Có một mối quan hệ một-một giữa trường hợp Element (Phần tử) và trường hợp (khác) của Element (Phần tử) mà thể hiện. Ví dụ thực tế đơn giản là quan niệm về một nhà môi giới hoạt động như trung gian giữa một người bán (mà không muốn được biết đến) và một người mua.

Một phần tử thể hiện một khía cạnh cụ thể của một phần tử khác, có một mối quan hệ nhiều-một giữa nhiều trường hợp Element (Phần tử) (mỗi trường hợp thể hiện một khía cạnh khác nhau) và trường hợp (khác) của Element (Phần tử). Ví dụ thực tế đơn giản là quan niệm cùng một người có thể đóng vai (được thể hiện bởi) nhiều vai trò khác nhau.

Một phần tử là một trừu tượng thể hiện nhiều phần tử khác. Có mối quan hệ một-nhiều giữa trường hợp Element (Phần tử) (trừu tượng) và nhiều trường hợp khác của Element (Phần tử). Ví dụ thực tế đơn giản là quan niệm về một bản thiết kế kiến trúc thể hiện sự trừu tượng của nhiều tòa nhà khác nhau đang được xây dựng theo bản thiết kế chi tiết đó.

Lưu ý rằng trong hầu hết các trường hợp, trường hợp Element (Phần tử) chỉ thể hiện cho một kiểu. Cụ thể, trường hợp Element (Phần tử) thường thể hiện các trường hợp nhiều nhất một trong các lớp System (Hệ thống), Service (Dịch vụ), HumanActor (Tác nhân con người) và Task (Tác vụ) (trừ trường hợp cùng là một kiểu của cả trường hợp System (Hệ thống) và trường hợp HumanActor (Tác nhân con người)). Xem các Điều sau đối với các định nghĩa về Service (Dịch vụ), HumanActor (Tác nhân con người) và Task (Tác vụ).

8.8  Ví dụ represents (thể hiện) và representedBy (thể hiện bởi)

8.8.1  Ví dụ về tổ chức

Mở rộng hơn nữa về ví dụ có tổ chức tính, giả định một công ty mong muốn hình thành một đơn vị tổ chức mới 01. Có hai cách để làm điều này.

Xác định tổ chức mới trực tiếp dưới dạng tập hợp con người P1, P2, P3 và P4. Điều này có nghĩa là tổ chức mới được coi là một nhánh trong hệ thống phân cấp tổ chức và có nghĩa là với bất kỳ trao đổi nhân sự nào thì định nghĩa cũng cần phải thay đổi.

Xác định tổ chức mới là một tổ chức cấu trúc mức cao hơn, kết hợp hai tổ chức hiện có O3 và O4. Thật trùng hợp, O3 và O4 giữa chúng có thể có cùng 4 người P1, P2, P3 và P4, nhưng tổ chức mới thực sự không biết và bất kỳ thành phần nào của O3 hoặc O4 đều có thể thay đổi mà không cần thay đổi định nghĩa tổ chức mới. Hơn nữa, bất kỳ thành phần nào của O3 thực chất không hoạt động trong cùng một tổ chức với tư cách là thành phần của O4 (trên thực tế không cần biết họ) – trái với tùy chọn đầu tiên P1, P2, P3 và P4 là tất cả các đồng nghiệp trong cùng một tổ chức mới.

Theo cách này, khía cạnh trừu tượng của thuộc tính represents (thể hiện) tạo ra một sự khác biệt quan trọng trong ngữ nghĩa của tập hợp xác định tổ chức mới. Bất kỳ sự khởi tạo nào của bản thể học có thể và nên sử dụng thuộc tính represents (thể hiện) và representedBy (thể hiện bởi) để xác định rõ ràng các ngữ nghĩa hàm ẩn và các dòng hiển thị/thay đổi.

8.8.2  Ví dụ rửa xe ô tô

Joe tổ chức nghiệp vụ của mình thành hai đơn vị tổ chức, về hành chính và một cho việc rửa xe thực tế. Điều này có thể được khởi tạo trong bản thể học theo cách sau:

– CarWashBusiness (Nghiệp vụ rửa xe ô tô) là một trường hợp System (Hệ thống).

– AdministrativeSystem (Hệ thống-hành chính) là một trường hợp System (Hệ thống).

– Administration (Hành chính) là một trường hợp Element (Phần tử) thể hiện AdministrativeSystem (Hệ thống-hành chính) (khía cạnh đơn vị tổ chức mở, còn được biết là bỏ qua bất cứ đều gì khác về AdministrativeSystem (Hệ thống-hành chính)).

– CarWashBusiness (Nghiệp vụ rửa xe ô tô) sử dụng (có đơn vị tổ chức) Administration (Hành chính).

– CarWashSystem (Rửa xe ô tô) là một trường hợp System (Hệ thống).

– CarWash (Rửa xe ô tô) là một trường hợp Element (Phần tử) thể hiện Hệ thống-CarWash (Rửa xe ô tô) (khía cạnh đơn vị tổ chức mở, còn được biết là bỏ qua bất cứ đều gì khác về Hệ thống-CarWash (Rửa xe ô tô)).

– CarWash (Rửa xe ô tô) là một thành phần của CarWashBusiness (Nghiệp vụ rửa xe ô tô).

– Joe (chủ sở hữu) là một trường hợp Element (Phần tử) và bây giờ được sử dụng bởi AdministrativeSystem (Hệ thống-hành chính).

– Mary (thư ký) là một trường hợp Element (Phần tử) và bây giờ được sử dụng bởi AdministrativeSystem (Hệ thống-hành chính).

– John (người rửa sơ bộ trước) là một trường hợp Element (Phần tử) và bây giờ được sử dụng bởi CarWashSystem (Rửa xe ô tô).

– Jack (người quản lý và vận hành rửa xe) là một trường hợp Element (Phần tử) và bây giờ được sử dụng bởi Hệ thống-CarWash (Rửa xe ô tô).

9  HumanActor (Tác nhân con người) và Task (Tác vụ)

9.1  Tổng quan

Con người, tổ chức và sự vật, sự việc do con người, tổ chức làm là những khía cạnh quan trọng của hệ thống SOA. HumanActor (Tác nhân con người) và Task (Tác vụ) thu nạp sự vật, sự việc như tập các khái niệm cốt lõi khác của bản thể học. Cả hai đều là các khái niệm chung và có liên quan bên ngoài miền SOA. Vì mục đích bản thể học SOA, phạm vi cụ thể được đưa ra trong các tác vụ thực chất là đơn vị nhỏ nhất [tương ứng với, ví dụ, quan niệm mô thức quá trình doanh nghiệp (BPMN) 2.0 của Tác vụ (xem Tham khảo [4])] và tác nhân con người được giới hạn cho người và tổ chức.

Điều này mô tả các lớp bản thể học sau:

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

Task (Tác vụ)

Ngoài ra, xác định các thuộc tính sau:

does (làm) và doneBy (được hoàn thành bởi)

9.2  Lớp HumanActor (Tác nhân con người)

Tác nhân con người là một người hoặc tổ chức. Khái niệm Tác nhân con người được thu nạp bởi lớp OWL HumanActor (Tác nhân con người), minh họa trong Hình 5.

Hình 5 – Lớp HumanActor (Tác nhân con người)

HumanActor (Tác nhân con người) được định nghĩa là sự phân chia các lớp Service (Dịch vụ) và Task (Tác vụ). Các trường hợp lớp này không được coi là người hoặc tổ chức HumanActor (Tác nhân con người) đặc biệt không được định nghĩa là phân chia lớp System (Hệ thống) khi một tổ chức trong nhiều trường hợp trên thực tế chỉ là một kiểu hệ thống cụ thể. Một lớp giao nhau đặc biệt để thể hiện thực tế này không được xác định.

9.3  HumanActor (Tác nhân con người) – Ví dụ

9.3.1  Thuộc tính uses (sử dụng) và usedBy (được sử dụng bởi) áp dụng cho HumanActor (Tác nhân con người)

Theo một hướng, tác nhân con người có thể tự sử dụng sự vật, sự việc như các dịch vụ, hệ thống và tác nhân con người khác. Theo hướng khác, tác nhân con người có thể, ví dụ, được sử dụng bởi tác nhân con người khác hoặc bởi một hệ thống (như phần tử trong hệ thống đó chẳng hạn như tác nhân con người trong quá trình).

9.3.2  Thuộc tính represents (thể hiện) và representedBy (thể hiện bởi) áp dụng cho HumanActor (Tác nhân con người)

Như đã đề cập ở trên, các tác nhân con người bản chất là một phần của hệ thống khởi tạo các kiến trúc hướng dịch vụ. Tuy nhiên, trong nhiều trường hợp là một phần tử của hệ thống SOA, người hoặc tổ chức cụ thể không được thảo luận, thay vì một thể hiện trừu tượng tham gia vào các quá trình, cung cấp các dịch vụ, v.v… Nói cách khác, đề cập đến các phần tử thể hiện tác nhân con người.

Như trong ví dụ, bên môi giới (trường hợp HumanActor (Tác nhân con người)) thể hiện một người bán (trường hợp HumanActor (Tác nhân con người)) muốn ẩn danh, vai trò (trường hợp Element (Phần tử)) thể hiện (khía cạnh vai trò) nhiều trường hợp HumanActor (Tác nhân con người) và một đơn vị tổ chức (trường hợp HumanActor (Tác nhân con người) ) thể hiện nhiều người (tất cả các trường hợp HumanActor (Tác nhân con người)) là một phần.

Lưu ý rằng một “lớp vai trò” không được xác định, như việc sử dụng Element (Phần tử) với thuộc tính thể hiện là cách tiếp cận tổng quát hơn, không giới hạn khả năng xác định các hệ thống dựa trên vai trò. Đối với tất cả các mục đích thực tế, chỉ đơn giản là một “lớp vai trò con” của Element (Phần tử), lớp con không được xác định rõ ràng.

9.3.3  Ví dụ về tổ chức

ví dụ có tổ chức tính từ 8.8.1, P1 (John), P2 (Jack), P3 (Joe) và P4 (Mary) trình bày là một trường hợp Element (Phần tử) of Action action. O1 (Doanh nghiệp-ô tô-xe ô tô con), O3 (Ô tô-xe ô tô) và O4 (Hành chính) diễn tả như nhân viên hành động từ một hành động tại đồng thời chúng là các hệ thống khác nhau từ quan điểm bộ sưu tập / tổ hợp

Tiếp tục ví dụ về tổ chức từ 8.8.1, P1 (John), P2 (Jack), P3 (Joe) và P4 (Mary) bây giờ có thể được thể hiện như trường hợp Element (Phần tử) mà trong thực tế (người) trường hợp HumanActor (Tác nhân con người). Tất cả các O1 (CarWashBusiness (Nghiệp vụ rửa xe ô tô)), O3 (CarWash (Rửa xe ô tô)) và O4 (Hành chính) cũng có thể được thể hiện như (tổ chức) những tác nhân con người từ quan điểm hành động đồng thời chúng là các hệ thống từ quan điểm tập hợp/tổ hợp.

9.3.4  Ví dụ rửa xe ô tô

Xem Phụ lục A cho khía cạnh tổ chức hoàn chỉnh của ví dụ rửa xe ô tô.

9.4  Lớp tác vụ

Tác vụ là một hành động đơn vị nhỏ nhất hoàn thành một kết quả xác định. Các tác vụ được thực hiện bởi người hoặc các tổ chức, đặc biệt là bởi các trường hợp HumanActor (Tác nhân con người).

Ký hiệu mô hình quá trình nghiệp vụ (BPMN) 2.0 định nghĩa tác vụ như sau: “Tác vụ là một hoạt động đơn vị nhỏ nhất trong luồng quá trình (xem Tham khảo [4]). Tác vụ được sử dụng khi công việc trong Quá trình không thể được chia nhỏ chi tiết hơn. Nói chung, người 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.” Vì mục đích bản thể học, độ chính xác đã được thêm vào bởi quan niệm phân chia chính thức về việc làm từ quan niệm về thực hiện. Các tác vụ (tùy ý) được hoàn thành bởi những tác nhân con người, hơn nữa (như trường hợp Element (Phần tử)), các tác vụ có thể sử dụng các dịch vụ được thực hiện bởi các thành phần công nghệ (xem chi tiết trong 10.3; xem ví dụ trong Phụ lục A).

Khái niệm tác vụ được thu nạp bởi lớp OWL Task (Tác vụ), minh họa trong Hình 6.

Hình 6 – Lớp tác vụ

Task (Tác vụ) được định nghĩa là sự phân chia các lớp System (Hệ thống), Service (Dịch vụ) và HumanActor (Tác nhân con người). Các trường hợp lớp này không được coi là các hành động đơn vị nhỏ nhất.

9.5  Thuộc tính does (làm) và doneBy (được hoàn thành bởi)

Các tác vụ là bản chất được cho là do người hoặc tổ chức thực hiện. Nếu xem các tác vụ là những điều thực tế được làm, thì các yếu tố tập hợp tự nhiên là mỗi trường hợp Task (Tác vụ) được hoàn thành bởi hầu hết trường hợp HumanActor (Tác nhân con người). Do tính chất đơn vị nhỏ nhất của trường hợp Task (Tác vụ), trường hợp bị loại trừ khi ví dụ như vậy được làm cùng nhau bởi nhiều trường hợp Tác nhân con người. Các yếu tố tập hợp có thể là không nếu ai đó không chọn khởi tạo tất cả những tác nhân con người có thể. Nói cách khác, tương tự trường hợp HumanActor (Tác nhân con người) có thể (theo thời gian) dễ dàng làm nhiều hơn trường hợp Task (Tác vụ). Thuộc tính does (làm) và ngược lại doneBy (được hoàn thành bởi), thu nạp mối quan hệ giữa một tác nhân con người và các tác vụ.

9.6  Task (Tác vụ) – Ví dụ

9.6.1  Thuộc tính uses (sử dụng) và usedBy (được sử dụng bởi) áp dụng cho Task (Tác vụ)

Theo một hướng, trường hợp phổ biến nhất của một tác vụ sử dụng phần tử khác là nơi một tác vụ tự động (trong quá trình phối hợp; xem Điều 11 đối với định nghĩa về quá trình và sự phối hợp) sử dụng một dịch vụ như việc thực hiện nó. Theo hướng khác, tác vụ có thể, ví dụ, được sử dụng bởi một hệ thống (như phần tử trong hệ thống đó, chẳng hạn như tác vụ trong quá trình)

9.6.2  Thuộc tính represents (thể hiện) và representedBy (thể hiện bởi) áp dụng cho Task (Tác vụ)

Như đã đề cập trong phần giới thiệu về Điều này, các tác vụ bản chất là một phần của hệ thống SOA. Tuy nhiên, trong nhiều trường hợp là phần tử của hệ thống SOA, thực tế chưa được thảo luận, là một thể hiện trừu tượng được sử dụng như phần tử trong hệ thống, quá trình, v.v. Nói cách khác, thảo luận các phần tử thể hiện các tác vụ.

Ví dụ đơn giản, hoạt động trừu tượng trong mô hình quá trình (được liên kết với một vai trò) thể hiện một tác vụ cụ thể (được hoàn thành bởi một người thực hiện đầy đủ vai trò đó). Lưu ý rằng do tính chất đơn vị nhỏ nhất của một tác vụ nên không có ý nghĩa gì khi nói về nhiều phần tử thể hiện các khía cạnh khác nhau.

9.6.3  Ví dụ về tổ chức

Tiếp tục ví dụ về tổ chức từ 8.8.1, các tác vụ được hoàn thành bởi tác nhân con người (con người) P1, P2, P3 và P4 có thể được thể hiện và các tác vụ đó có thể là các phần tử trong các hệ thống lớn hơn mô tả sự vật, sự việc như các quá trình tổ chức. Điều 11 chính thức giải quyết với khái niệm tổ hợp, bao gồm thuộc tính xác định khái niệm về một quá trình như kiểu tổ hợp cụ thể.

9.6.4  Ví dụ rửa xe ô tô

Như một phần quan trọng trong hệ thống rửa xe, John và Jack thực hiện một số tác vụ thủ công cần thiết để rửa xe đúng cách.

– Jack và John là các trường hợp HumanActor (Tác nhân con người).

– WashWindows (cửa sổ rửa) là một trường hợp Task (Tác vụ) và được hoàn thành bởi John.

– PushWashButton (Nhấn nút rửa) là một trường hợp Task (Tác vụ) và được hoàn thành bởi Jack.

10  Service (Dịch vụ), ServiceContract (Hợp đồng dịch vụ) và ServiceInterface (Giao diện dịch vụ)

10.1  Tổng quan

Dịch vụ là một khái niệm cốt lõi về bản thể học này. Đây là một khái niệm nền tảng đối với SOA và luôn được sử dụng trong thực tế khi mô tả hoặc có tính kỹ thuật của hệ thống SOA, nhưng nó không phải là dễ dàng để xác định chính thức. Bản thể học dựa trên định nghĩa sau về dịch vụ:

Một dịch vụ là một “thể hiện lô-gic một tập các hoạt động có đầu ra xác định, khép kín, có thể bao gồm các dịch vụ khác và là “hộp đen” đối với khách hàng dịch vụ”

Điều này tương ứng với định nghĩa chính thức hiện có của thuật ngữ trong kiến trúc tham chiếu cho SOA, TCVN 12482-1 (ISO/IEC 18384-1).

Từ hoạt động trong định nghĩa dịch vụ được sử dụng theo nghĩa tiếng Anh nói chung của từ, không phải trong ý 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 là các hoạt động quá trình). Bản thể học bỏ qua có mục đích “nghiệp vụ” là một phần nội tại của định nghĩa dịch vụ. Lập luận cho điều này là quan niệm về nghiệp vụ liên quan đến quan điểm của một người, như ví dụ, quan niệm của một người về IT là quan niệm của một người khác về nghiệp vụ (nghiệp vụ IT). Dịch vụ như được xác định bởi bản thể học là không thể biết được liệu khái niệm đó có được áp dụng cho quan niệm lớp của một miền nghiệp vụ hay quan niệm lớp của một miền IT.

Các định nghĩa cụ thể khác của SOA về thuật ngữ dịch vụ bao gồm:

– “Cơ chế cho phép truy cập vào một hoặc nhiều khả năng, nơi truy cập được cung cấp bằng cách sử dụng một giao diện được quy định và được thực hiện phù hợp với các ràng buộc và các chính sách như được quy định bởi mô tả dịch vụ.” (xem Tham khảo [3])

– “Khả năng được đưa ra bởi một hoặc nhiều thực thể để các khả năng khác sử dụng “các thuật ngữ và định nghĩa” và các giao diện được xác định đúng.” (xem Tham khảo [9])

Theo mức độ chính xác thông thường của ngôn ngữ tiếng Anh, các định nghĩa này không mâu thuẫn; chúng đang nhấn mạnh các khía cạnh khác nhau của cùng một khái niệm. Tất cả ba định nghĩa đều là SOA cụ thể và thể hiện một giải thích cụ thể về thuật ngữ dịch vụ nói chung của tiếng Anh.

Điều này mô tả các lớp bản thể học sau:

– Service (Dịch vụ);

– ServiceContract (Hợp đồng dịch vụ);

– ServiceInterface (Giao diện dịch vụ);

– InformationType (Kiểu thông tin).

Ngoài ra, xác định các thuộc tính sau:

– performs (thực hiện) và performedBy (được thực hiện bởi);

– hasContract (có hợp đồng) và isContractFor (hợp đồng đối với);

– involvesParty (bên tham gia liên quan) và isPartyTo (là bên tham gia đối với);

– specifies (quy định) và isSpecifiedBy (được quy định bởi);

– hasInterface (có giao diện) và isInterfaceOf (là giao diện của);

– hasInput (có đầu vào) và isInputAt (là đầu vào tại);

– hasOutput (có đầu ra) và isOutputAt (là đầu ra tại).

10.2  Lớp Service (Dịch vụ)

Một dịch vụ là một thể hiện lô-gic về một tập các hoạt động quy định các đầu ra, là khép kín, có thể bao gồm các dịch vụ khác và là một “hộp đen” đối với các khách hàng dịch vụ. Khái niệm về dịch vụ được thu nạp bởi lớp OWL Service (Dịch vụ), minh họa trong Hình 7.

Hình 7 – Lớp Service (Dịch vụ)

Trong bối cảnh bản thể học SOA, chỉ các dịch vụ dựa trên SOA xem xét. Các miền khác, chẳng hạn như quản lý dịch vụ tích hợp, có thể có các dịch vụ không dựa trên SOA do đó nằm ngoài phạm vi dự định của bản thể học SOA.

Service (Dịch vụ) được định nghĩa là sự phân chia các lớp System (Hệ thống), Task (Tác vụ) và Tác nhân con người. Các trường hợp lớp này không được coi là các dịch vụ, mặc dù các lớp này có thể cung cấp các khả năng có thể được đưa ra dưới dạng dịch vụ.

10.3  Thuộc tính performs (thực hiện) và performedBy (được thực hiện bởi)

Tự dịch vụ chỉ là một thể hiện lô-gic, bất kỳ dịch vụ nào được thực hiện bởi một sự vật, sự việc. Sự vật, sự việc thực hiện một dịch vụ là không rõ ràng đối với bất kỳ ai tương tác, sự không rõ ràng là bản chất của lớp phần tử. Khái niệm này được thu nạp bởi các thuộc tính performs (thực hiện) và performedBy (được thực hiện bởi) như minh họa trong Lớp Service (Dịch vụ) ở Hình 7.

Điều này cũng chỉ ra thực tế rằng các dịch vụ có thể được thực hiện bởi các kiểu phần tử khác hơn 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, tác nhân con người và tác vụ.

Lưu ý rằng cùng trường hợp Service (Dịch vụ) có thể được thực hiện bởi nhiều trường hợp khác nhau của Element (Phần tử). Miễn là dịch vụ được thực hiện như nhau, bên quan sát bên ngoài không thể nói sự khác biệt (đối với các nghĩa vụ theo hợp đồng, SLA, v.v… xem định nghĩa của lớp ServiceContract (Hợp đồng dịch vụ) trong 10.6). Ngược lại, bất kỳ trường hợp nào của Element (Phần tử) có thể thực hiện nhiều hơn một dịch vụ hoặc không có gì cả.

Trong khi một dịch vụ có thể được thực hiện bởi các phần tử khác dịch vụ tự nó (như trình bày thuần lô-gic) không thực hiện các dịch vụ khác. Xem Ví dụ Simple Service Composition (tổ hợp dịch vụ đơn giản) (11.7.1) cho ví dụ về thể hiện các tổ hợp dịch vụ chính thức trong bản thể học.

10.4  Khách hàng dịch vụ và nhà cung cấp dịch vụ

Thuật ngữ dùng trong môi trường SOA thường gồm các quan niệm về các nhà cung cấp dịch vụ và các khách hàng dịch vụ. Có hai thách thức với thuật ngữ này:

– Không phân biệt giữa khía cạnh nghĩa vụ theo hợp đồng của việc tiêu thụ/cung cấp và khía cạnh tương tác của việc tiêu thụ/cung cấp. Nghĩa vụ theo hợp đồng không nhất thiết phải chuyển thành sư phụ thuộc tương tác, nếu không vì lập luận nào khác ngoài việc thực hiện nghĩa vụ theo hợp đồng có thể đã được cung cấp cho bên thứ ba.

– Tiêu thụ hoặc cung cấp dịch vụ là một tuyên bố chỉ có ý nghĩa về bối cảnh, bối cảnh hợp đồng hoặc tương tác. Do đó, các điều mục này không phù hợp để đưa ra các báo cáo về các phần tử và dịch vụ.

Đây là những lập luận tại sao bản thể học chọn việc không chấp nhận tiêu thụ và cung cấp như các khái niệm cốt lõi, thay vào đó cho phép các điều mục tiêu thụ hoặc cung cấp sử dụng với nghĩa vụ theo hợp đồng và/hoặc quy tắc tương tác được mô tả bởi các hợp đồng dịch vụ; xem định nghĩa về lớp ServiceContract (Hợp đồng dịch vụ) trong 10.6. Ở dạng đơn giản nhất, bên ngoài bối cảnh hợp đồng dịch vụ chính thức, khía cạnh tương tác của việc tiêu thụ và cung cấp dịch vụ thậm chí có thể được thể hiện đơn giản bằng cách nói rằng một số phần tử sử dụng (các khách hàng) hoặc thực hiện một số phần tử thực hiện (cung cấp) dịch vụ; xem ví dụ trong 10.5.

10.5  Service (Dịch vụ) – Ví dụ

10.5.1  Thuộc tính uses (sử dụng) và usedBy (được sử dụng bởi) áp dụng cho Service (Dịch vụ)

Theo một hướng, không thực sự hợp lý để nói về dịch vụ sử dụng một phần tử khác. Trong khi việc thực hiện dịch vụ có thể bao gồm việc sử dụng các phần tử khác (và chắc chắn trong trường hợp Service Composition (Tổ hợp dịch vụ)), bản thân dịch vụ (thể hiện thuần lô-gic) không sử dụng các phần tử khác.

Theo hướng khác, phổ biến nhất trong tất cả các tương tác được tìm thấy ở một môi trường SOA: quan niệm rằng một số phần tử sử dụng một dịch vụ bằng cách tương tác với nó. Lưu ý rằng từ quan điểm hoạt động, tương tác này thực sự đạt được phần nào ngoài dịch vụ bằng cách liên quan đến các bước điển hình 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ó được thực hiện tự động khi chạy hay tĩnh tại thiết kế và/hoặc xây dựng thời gian)

– chọn một phần tử thực hiện dịch vụ đó (trong môi trường SOA điển hình, điều này thường được thực hiện “bên trong” một bus dịch vụ doanh nghiệp (ESB)];

– tương tác với dịch vụ phần tử được chọn (thực hiện được chọn) (thường được tạo điều kiện bởi một ESB).

10.5.2  Thuộc tính represents (thể hiện) và representedBy (thể hiện bởi) áp dụng cho Service (Dịch vụ)

Các khái niệm như các đàm phán dịch vụ, ủy nhiệm dịch vụ, ESB, v.v …. là tự nhiên đối với người thực hành mô tả và thực hiện các khía cạnh vận hành các hệ thống SOA. Từ quan điểm bản thể học, tất cả những điều này có thể được thu nạp bởi một vài phần tử khác thể hiện dịch vụ, mức gián đoạn rất quan trọng khi không muốn liên kết hoạt động với một điểm cuối dịch vụ cụ thể, thay vì bảo toàn nối kết lỏng và khả năng chuyển đổi các phương án khi cần thiết. Lưu ý rằng bằng cách tận dụng thuộc tính represents (thể hiện) và representedBy (thể hiện bởi) trong kiểu này khuôn mẫu tương tác hoạt động tương đối phức tạp được mỏ tả trong 9.6.2 (chọn dịch vụ, chọn phần tử thực hiện dịch vụ và tương tác với phần tử đã chọn) được kết gói bổ sung.

Trong khi một dịch vụ được thể hiện bởi một sự vật, sự việc khác là khá tự nhiên thì khó có thể tưởng tượng bản thân dịch vụ thể hiện sự vật, sự việc. Ở mức độ nào đó dịch vụ thể hiện bất kỳ hiện thân nào được thu nạp, chỉ các thuộc tính performs (thực hiện) và performedBy (được thực hiện bởi) được chọn để mô tả điều này, không phải tính năng chung thuộc tính represents (thể hiện) và representedBy (thể hiện bởi). Kết quả là các ứng dụng thực tế của bản thể học có các dịch vụ thể hiện mọi điều không được mong đợi.

10.5.3  Thể hiện khác biệt giữa làm một tác vụ và thực hiện một dịch vụ

Sự khác biệt giữa một tác nhân con người thực hiện một tác vụ và một phần tử (công nghệ, tác nhân con người, hoặc người khác) thực hiện một dịch vụ là rất quan trọng. Tác nhân con người làm tác vụ có trách nhiệm mà nó được thực hiện.

Sự khác biệt giữa một tác nhân con người thực hiện một tác vụ và một phần tử (công nghệ, tác nhân con người, cái khác) thực hiện một dịch vụ là quan trọng. Tác nhân con người làm tác vụ có trách nhiệm thực hiện nó, nhưng thực tế có thể trong nhiều trường hợp thúc đẩy một số dịch vụ để đạt được đầu ra đó:

– John là một trường hợp HumanActor (Tác nhân con người).

– WashWindows (Cửa sổ rửa) là một trường hợp Task (Tác vụ) và được hoàn thành bởi John.

– SoapWater (Nước xà phòng) là một trường hợp Service (Dịch vụ).

– WaterTap (Vòi nước) là một trường hợp Element (Phần tử).

– WaterTap (Vòi nước) thực thi SOApWater (Nước xà phòng).

– John sử dụng SoapWater (Nước xà phòng) (để làm WashWindows (Cửa sổ rửa)).

Lưu ý cách SoapWater (Nước xà phòng) làm không sạch WashWindows (Cửa sổ rửa), hoặc WaterTap (Vòi nước) không làm WashWindows (Cửa sổ rửa).

10.5.4  Ví dụ rửa xe ô tô

Joe đưa ra hai dịch vụ khác nhau cho khách hàng của anh ta: BasicWash (Rửa cơ bản) và GoldWash (Rửa cao cấp). Điều này có thể được khởi tạo trong bản thể học theo cách sau đây (tập con đối với phần có liên quan cho hai dịch vụ này):

– GoldWash (Rửa cao cấp) là một trường hợp Service (Dịch vụ).

– BasicWash (Rửa cơ bản) là một trường hợp Service (Dịch vụ).

– CarWash (Rửa xe ô tô) thực hiện cả BasicWash (Rửa cơ bản) và GoldWash (Rửa cao cấp).

– WashManager (Nhà quản lý rửa xe) thể hiện cả BasicWash (Rửa cơ bản) và GoldWash (Rửa cao cấp) (tức là điểm tương tác tại vị trí các khách hàng có thể đặt hàng dịch vụ cũng như thanh toán).

Lưu ý việc sử dụng có mục đích của WashManager (Nhà quản lý rửa xe) thể hiện cả hai dịch vụ. Điều này là do Joe quyết định rằng các khách hàng rửa xe của mình không được tương tác trực tiếp với máy rửa xe, thay vào đó, phải tương tác với bất kỳ cá nhân (tác nhân con người) thực hiện vai trò của nhà quản lý rửa xe.

10.6  Lớp ServiceContract (Hợp đồng dịch vụ)

Trong nhiều trường hợp, các cam kết cụ thể là cần thiết để xác định cách sử dụng dịch vụ. Điều này có thể là do mong muốn điều chỉnh việc sử dụng như vậy hoặc có thể đơn giản là vì dịch vụ không thuộc tính chức năng trừ khi tương tác với nó được thực hiện theo một trình tự nhất định. Một hợp đồng dịch vụ xác định các điều mục, điều kiện và quy tắc tương tác mà con người tham gia tương tác đồng ý (trực tiếp hoặc gián tiếp). Một hợp đồng dịch vụ là ràng buộc đối với tất cả con người tham gia trong tương tác, bao gồm chính dịch vụ và phần tử cung cấp nó cho tương tác cụ thể được đề cập. Khái niệm về hợp đồng dịch vụ được thu nạp bởi Lớp OWL ServiceContract (Hợp đồng dịch vụ), minh họa trong Hình 8.

Hình 8 – Lớp ServiceContract (Hợp đồng dịch vụ)

10.7  Thuộc tính kiểu dữ liệu interactionAspect (khía cạnh tương tác) và legalAspect (khía cạnh pháp lý)

Các hợp đồng dịch vụ điều chỉnh rõ ràng cả hai khía cạnh tương tác (xem các thuộc tính có hợp đồng và là hợp đồng cho) và các khía cạnh cam kết pháp lý (xem các thuộc tính bên tham gia có liên quan và là bên tham gia đối với) của việc sử dụng một dịch vụ. Hai kiểu khía cạnh này được thu nạp chính thức bằng cách xác định các thuộc tính kiểu dữ liệu interactionAspect (khía cạnh tương tác) và legalAspect (khía cạnh pháp lý) trên lớp ServiceContract (Hợp đồng dịch vụ). Lưu ý rằng các thuộc tính thứ hai này, các khía cạnh cam kết pháp lý, gồm các khái niệm như các cam kết mức dịch vụ (SLA).

Nếu muốn, nó có thể là một quy ước kiến trúc để tách các khía cạnh tương tác và pháp lý thành hai hợp đồng dịch vụ khác nhau. Các lựa chọn như vậy tùy thuộc vào bất kỳ ứng dụng nào sử dụng bản thể học này.

10.8  Thuộc tính hasContract (có hợp đồng) và isContractFor (hợp đồng đối với)

Thuộc tính hasContract (có hợp đồng) và ngược lại isContractFor (hợp đồng đối với), thu nạp quan niệm trừu tượng về một dịch vụ có một hợp đồng dịch vụ. Bất cứ ai muốn sử dụng một dịch vụ tuân theo các khía cạnh tương tác (như được định nghĩa trong thuộc tính kiểu dữ liệu interactionAspect (khía cạnh tương tác)) của bất kỳ hợp đồng dịch vụ áp dụng cho tương tác đó. Theo kiểu đó, các khía cạnh tương tác của một hợp đồng dịch vụ không phụ thuộc vào bối cảnh; thay chúng thu nạp các cách được xác định hoặc nội tại trong đó một dịch vụ có thể được sử dụng.

Theo định nghĩa, bất kỳ hợp đồng dịch vụ nào cũng là hợp đồng cho ít nhất một dịch vụ. Có thể hợp đồng dịch vụ tương tự có thể là hợp đồng cho nhiều dịch vụ; ví dụ, trong trường hợp một nhóm các dịch vụ chia sẻ cùng một mẫu tương tác hoặc hợp đồng dịch vụ (hợp pháp – xem các thuộc tính bên tham gia liên quan và là bên tham gia đối với trong 10.9) quy định việc cung cấp và tiêu thụ của nhiều dịch vụ.

10.9  Thuộc tính involvesParty (bên tham gia liên quan) và isPartyTo (là bên tham gia đối với)

Ngoài các quy tắc và quy định thực chất áp dụng cho bất kỳ tương tác nào với một dịch vụ (khía cạnh tương tác của hợp đồng dịch vụ được thu nạp trong thuộc tính kiểu dữ liệu interactionAspect (khía cạnh tương tác)) có thể có các cam kết pháp lý bổ sung áp dụng cho một số tác nhân con người nhất định và việc sử dụng dịch vụ. Thuộc tính involvesParty (bên tham gia liên quan) và isPartyTo (là bên tham gia đối với), thu nạp quan niệm trừu tượng về hợp đồng dịch vụ quy định nghĩa vụ pháp lý giữa tác nhân con người trong bối cảnh của việc sử dụng một hoặc nhiều dịch vụ mà hợp đồng dịch vụ là hợp đồng.

Trong khi các thuộc tính involvesParty (bên tham gia liên quan) và isPartyTo (là bên tham gia đối với) xác định các mối quan hệ với những tác nhân con người liên quan đến hợp đồng dịch vụ, các nghĩa vụ pháp lý thực tế đối với từng tác nhân con người được xác định trong thuộc tính kiểu dữ liệu legalAspect (khía cạnh pháp lý) trên hợp đồng dịch vụ. Điều này gồm khả năng xác định ai là nhà cung cấp và ai là khách hàng từ quan điểm nghĩa vụ pháp lý.

Có mối quan hệ nhiều chiều giữa các hợp đồng dịch vụ và tác nhân con người. Một tác nhân con người nhất định có thể là một bên không có, có một hoặc có nhiều hợp đồng dịch vụ. Tương tự, hợp đồng dịch vụ nhất định có thể liên quan đến không ai, hoặc nhiều tác nhân con người (không có trường hợp hợp đồng dịch vụ cụ thể chỉ quy định thuộc tính kiểu dữ liệu interactionAspect (khía cạnh tương tác)). 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 con người A và tác nhân con người B (cả hai bên là hợp đồng dịch vụ), nhưng tác nhân con người B có nguồn gốc của việc thực hiện dịch vụ cho tác nhân con người C (hay còn gọi là tác nhân con người C thực hiện dịch vụ được đề cập, không phải tác nhân con người B).

Thuộc tính involvesParty (bên tham gia liên quan) cùng với thuộc tính kiểu dữ liệu legalAspect (khía cạnh pháp lý) trên ServiceContract (Hợp đồng dịch vụ) thu nạp không không chỉ nghĩa vụ tạm thời. Chúng gồm khả năng diễn đạt “có nghĩa vụ ngay tại thời điểm này”, “có nghĩa vụ phải” và “trong tương lai có nghĩa vụ phải”.

10.10  Lớp khả năng tác động

Tương tác với một sự vật, sự việc thực hiện một dịch vụ có các khả năng tác động. Những điều này bao gồm đầu ra của sự tương tác đó và là cách một dịch vụ (thông qua phần tử thực hiện nó) mang lại giá trị cho khách hàng. Khái niệm về effect (khả năng tác động) được thu nạp bởi the Effect OWL class (lớp khả năng tác động), minh họa trong Hình 9.

Hình 9 – Lớp khả năng tác động

Lưu ý rằng the Effect OWL class (lớp khả năng tác động) thể hiện thuần cho cách kết quả hoặc giá trị được phân phối đến một người nào đó tương tác với dịch vụ. Bất kỳ sự hấp dẫn bên trong khả năng tác động nào có thể rõ ràng không bị khả năng tác động bởi the Effect OWL class (lớp khả năng tác động).

Effect (khả năng tác động) được định nghĩa là sự phân chia với lớp ServiceInterface (Giao diện dịch vụ). (Lớp ServiceInterface (Giao diện dịch vụ) được định nghĩa trong TCVN 12482 (ISO/IEC 18384) mới hơn này). Tương tác với một dịch vụ thông qua giao diện dịch vụ có thể có đầu ra hoặc cung cấp một giá trị (trường hợp Effect (khả năng tác động)) nhưng bản thân giao diện dịch vụ không cấu thành đầu ra hoặc giá trị đó.

10.11  Thuộc tính specifies (quy định) và isSpecifiedBy (được quy định bởi)

Trong khi một dịch vụ thực chất có một khả năng tác động ở mọi lúc khi ai đó tương tác, để tin sự khả năng tác động là một sự vật, sự việc cụ thể, thì khả năng tác động cần phải được quy định là một phần của hợp đồng dịch vụ. Thuộc tính specifies (quy định) và ngược lại isSpecifiedBy (được quy định bởi), thu nạp quan niệm trừu tượng về một hợp đồng dịch vụ quy định một khả năng tác động cụ thể là một phần cam kết việc sử dụng một dịch vụ. Lưu ý rằng khả năng tác động được quy định có thể áp dụng cho cả thuộc tính kiểu dữ liệu interactionAspect (khía cạnh tương tác) (chỉ cần quy định điều gì xảy ra khi tương tác với dịch vụ theo hợp đồng dịch vụ) và thuộc tính kiểu dữ liệu legalAspect (khía cạnh pháp lý) (quy định một khả năng tác động được hứa hẹn theo hợp đồng).

Bất cứ ai muốn một khả năng tác động được đảm bảo về sự tương tác với một dịch vụ nhất định đảm bảo rằng sự khả năng tác động mong muốn được quy định trong hợp đồng dịch vụ áp dụng cho tương tác đó. Theo định nghĩa, bất kỳ hợp đồng dịch vụ nào quy định ít nhất một khả năng tác động. Theo hướng khác, khả năng tác động là khả năng tác động của ít nhất một hợp đồng dịch vụ; điều này thể hiện thực tế rằng những khả năng tác động đó được quy định bởi các hợp đồng dịch vụ chỉ được chính thức hóa (và không phải tất cả các khả năng tác động bên trong của tất cả các dịch vụ).

10.12  ServiceContract (Hợp đồng dịch vụ) – Ví dụ

10.12.1  Các cam kết mức dịch vụ

Một cam kết mức dịch vụ (SLA) trên một dịch vụ đã được cam kết bởi các tổ chức A và B. Điều quan trọng là phải nhận ra SLA luôn có bối cảnh mà các bên đã đồng ý, bao gồm tối thiểu một “khách hàng” hợp pháp và một “nhà cung cấp” hợp pháp. Điều này có thể được thể hiện trong bản thể học như sau:

– A và B là các trường hợp HumanActor (Tác nhân con người);

– Dịch vụ là một trường hợp Service (Dịch vụ);

– ServiceContract (Hợp đồng dịch vụ) là một trường hợp ServiceContract (Hợp đồng dịch vụ);

– ServiceContract (Hợp đồng dịch vụ) là hợp đồng cho Service (Dịch vụ);

– ServiceContract (Hợp đồng dịch vụ) bên tham gia liên quan A;

– ServiceContract (Hợp đồng dịch vụ) bên tham gia liên quan B;

– Thuộc tính kiểu dữ liệu legalAspect (khía cạnh pháp lý) trên ServiceContract (Hợp đồng dịch vụ) mô tả SLA.

10.12.2  Dịch vụ nguồn

Các tổ chức A và B đồng ý B cung cấp các dịch vụ nhất định cho A, nhưng B muốn cung cấp nguồn thực tế các dịch vụ đó cho bên thứ ba C. Điều này có thể được thể hiện trong bản thể học như sau:

– A, B và C là các trường hợp HumanActor (Tác nhân con người);

– Dịch vụ là một trường hợp Service (Dịch vụ);

– C cung cấp Dịch vụ;

– ServiceContract (Hợp đồng dịch vụ) là một trường hợp ServiceContract (Hợp đồng dịch vụ);

– ServiceContract (Hợp đồng dịch vụ) is Hợp đồng cho Service (Dịch vụ);

– ServiceContract (Hợp đồng dịch vụ) bên tham gia liên quan A;

– ServiceContract (Hợp đồng dịch vụ) bên tham gia liên quan B.

– Thuộc tính kiểu dữ liệu legalAspect (khía cạnh pháp lý) trên ServiceContract (Hợp đồng dịch vụ) mô tả nghĩa vụ pháp lý của B để cung cấp Dịch vụ cho A.

10.12.3  Ví dụ rửa xe ô tô

Xem Phụ lục A về các khía cạnh Service và ServiceContract (Dịch vụ và hợp đồng dịch vụ) hoàn thiện của ví dụ rửa xe ô tô.

10.13  Lớp ServiceInterface (Giao diện dịch vụ)

Một đặc tính quan trọng của dịch vụ là chúng có các giao diện đơn giản, được xác định rõ. Điều này làm cho nó dễ dàng tương tác với chúng và cho phép các phần tử khác sử dụng chúng một cách có cấu trúc. Một 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ụ. Khái niệm này được thu nạp bởi lớp ServiceInterface (Giao diện dịch vụ) minh họa trong Hình 10.

Hình 10 – Lớp ServiceInterface (Giao diện dịch vụ)

Khái niệm về một giao diện nói chung được hiểu bởi người thực hành, bao gồm quan niệm rằng các giao diện xác định các tham số cho thông tin đi vào và ra khỏi chúng khi được gọi. Điều khác biệt giữa miền với miền là bản chất cụ thể về cách giao diện được gọi và cách thông tin được truyền qua lại. Các giao diện dịch vụ là đ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 định nghĩa độc lập với bất kỳ dịch vụ nào đang thực hiện chúng (để hỗ trợ các nối kết lỏng và hòa giải dịch vụ).

Từ một phối cảnh thiết kế các giao diện có thể có nhiều vận hành chi tiết hơn hoặc có thể bao gồm các giao diện khác, tuy nhiên, tiêu chuẩn này đã được giữ ở mức khái niệm và không bao gồm các khía cạnh thiết kế như vậy trong bản thể học.

ServiceInterface (Giao diện dịch vụ) được định nghĩa là sự phân chia Lớp Service (Dịch vụ) ServiceContract (Hợp đồng dịch vụ) và các khả năng tác động. Các giao diện của lớp này được coi là không xác định (bởi chính chúng) mà 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ụ. Lưu ý rằng có một sự kết hợp tự nhiên giữa thuộc tính kiểu dữ liệu ServiceInterface (Giao diện dịch vụ) và interactionAspect (khía cạnh tương tác) trên ServiceContract (Hợp đồng dịch vụ) khi sau này xác định bất kỳ đa tương tác và/hoặc các ràng buộc trình tự về cách sử dụng dịch vụ thông qua tương tác với giao diện dịch vụ.

10.14  Thuộc tính kiểu dữ liệu ràng buộc

Thuộc tính kiểu dữ liệu Constraints (các ràng buộc) trên ServiceInterface (Giao diện dịch vụ) thu nạp quan niệm rằng có thể có các ràng buộc trên tương tác được phép như chỉ có các khoảng giá trị nhất định được phép trên các thông số đã cho. 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 trong các ràng buộc này có thể được xác định chính thức hoặc không chính thức (trường hợp không chính thức có liên quan ở mức tối thiểu cho số kiểu dịch vụ thực tế nhất định).

10.15  Thuộc tính hasInterface (có giao diện) và isInterfaceOf (là giao diện của)

Thuộc tính hasInterface (có giao diện) và ngược lại isInterfaceOf (là giao diện của), thu nạp quan niệm trừu tượng về một dịch vụ có một giao diện dịch vụ cụ thể.

Một mặt, mọi dịch vụ đều có ít nhất một giao diện dịch vụ; mọi điều khác trái với định nghĩa về dịch vụ là một thể hiện của một tập các hoạt động có một đầu ra quy định và là một “hộp đen” cho khách hàng. Mặt khác, có thể có các giao diện dịch vụ không phải là giao diện của bất kỳ dịch vụ được xác định nào. Ngoài ra, cùng một giao diện dịch vụ có thể là một giao diện của nhiều dịch vụ. Điều thứ hai không có nghĩa là các dịch vụ này giống nhau, thậm chí chúng không có cùng sự khả năng tác động, nó chỉ có nghĩa là có thể tương tác với tất cả các dịch vụ này theo cách thức được định nghĩa bởi giao diện dịch vụ được đề cập đến.

10.16  Lớp InformationType (Kiểu thông tin)

Một giao diện dịch vụ có thể cho phép một phần tử khác cung cấp thông tin hoặc nhận thông tin từ một dịch vụ (khi nó sử dụng dịch vụ đó), cụ thể là các kiểu thông tin được cung cấp hoặc nhận được. Khái niệm về kiểu thông tin được thu nạp bởi lớp OWL InformationType (Kiểu thông tin), minh họa trong Hình 11.

Hình 11 – Lớp InformationType (Kiểu thông tin)

Trong bất kỳ tương tác cụ thể nào thông qua một giao diện dịch vụ, các kiểu thông tin trên giao diện đó được các mục thông tin khởi tạo, tuy nhiên đối với chính giao diện dịch vụ, nó là các kiểu quan trọng. Lưu ý rằng thuộc tính kiểu dữ liệu constraints (các ràng buộc) trên ServiceInterface (Giao dịch-dịch vụ), nếu cần thiết, có thể được sử dụng để thể hiện các ràng buộc trên các giá trị được phép cho số kiểu thông tin nhất định.

10.17  Thuộc tính hasInput (có đầu vào) và isInputAt (là đầu vào tại)

Thuộc tính hasInput (có đầu vào) và ngược lại isInputAt (là đầu vào tại), thu nạp quan niệm trừu tượng về kiểu thông tin cụ thể được cung cấp khi tương tác với một dịch vụ thông qua giao diện dịch vụ.

Lưu ý rằng có mối quan hệ nhiều-nhiều giữa các giao diện dịch vụ và các kiểu thông tin đầu vào. Một kiểu thông tin nhất định có thể bổ sung vào ở nhiều giao diện dịch vụ hoặc không có gì cả. Tương tự, giao diện dịch vụ nhất định có thể có nhiều kiểu thông tin như đầu vào hoặc không có kiểu thông tin nào cả. Điều quan trọng là nhận ra rằng một số dịch vụ có thể chỉ có đầu vào (nhấn một hành động không đồng bộ mà không có đáp trả xác định) và các dịch vụ khác chỉ có thể có đầu ra (các phần tử thực hiện các dịch vụ này thực thi độc lập nhưng có thể cung cấp đầu ra được sử dụng bởi các phần tử khác).

10.18  Thuộc tính hasOutput (có đầu ra) và isOutputAt (là đầu ra tại)

Thuộc tính hasOutput (có đầu ra) và ngược lại isOutputAt (là đầu ra tại), thu nạp quan niệm trừu tượng về kiểu thông tin cụ thể được nhận khi tương tác với một dịch vụ thông qua giao diện dịch vụ.

Lưu ý rằng có mối quan hệ nhiều-nhiều giữa các giao diện dịch vụ và các kiểu thông tin đầu ra. Một kiểu thông tin nhất định có thể là đầu ra ở nhiều giao diện dịch vụ hoặc không có gì cả. Tương tự, giao diện dịch vụ nhất định có thể có nhiều kiểu thông tin như đầu ra hoặc không có kiểu thông tin nào cả. Điều quan trọng là nhận ra rằng một số dịch vụ có thể chỉ có đầu ra (nhấn một hành động không đồng bộ mà không có đáp trả xác định) và các dịch vụ khác chỉ có thể có đầu ra (các phần tử thực hiện các dịch vụ này thực thi độc lập nhưng có thể cung cấp đầu ra được sử dụng bởi các phần tử khác).

10.19  Ví dụ

10.19.1  Trình tự tương tác

Một hợp đồng dịch vụ trên một dịch vụ diễn giải các giao diện dịch vụ trên dịch vụ được sử dụng theo một thứ tự nhất định.

– Dịch vụ là một trường hợp Service (Dịch vụ).

– ServiceContract (Hợp đồng dịch vụ) là một trường hợp ServiceContract (Hợp đồng dịch vụ).

– ServiceContract (Hợp đồng dịch vụ) là hợp đồng cho Service (Dịch vụ).

– X là một trường hợp ServiceInterface (Giao diện dịch vụ).

– X là giao diện của Dịch vụ.

– Y là một trường hợp ServiceInterface (Giao diện dịch vụ).

– Y là giao diện của Dịch vụ.

– Thuộc tính kiểu dữ liệu interactionAspect (khía cạnh tương tác) trên ServiceContract (Hợp đồng dịch vụ) mô tả X được sử dụng trước khi Y có thể được sử dụng.

10.19.2  Ví dụ rửa xe ô tô

Xem Phụ lục A về khía cạnh ServiceInterface (Giao diện dịch vụ) hoàn thiện của ví dụ rửa xe ô tô.

11  Tổ hợp và các lớp con của nó

11.1  Tổng quan

Quan niệm về Tổ hợp là một khái niệm cốt lõi của SOA. Các dịch vụ có thể bao gồm các dịch vụ khác. Các quá trình gồm tác nhân con người, tác vụ và có thể là các dịch vụ. Người thực hành SOA có kinh nghiệm áp dụng một cách trực giác tổ hợp như phần không thể thiếu của kiến trúc, thiết kế và thực hiện các hệ thống SOA; trên thực tế, bất kỳ môi trường SOA có cấu trúc tốt nào thực chất tổ hợp theo cách các dịch vụ và các quá trình hỗ trợ khả năng nghiệp vụ. Điều khác biệt với người thực hành là bản chất của tổ hợp, khuôn mẫu tổ hợp đang được áp dụng.

Điều này mô tả các lớp bản thể học sau

Composition (Tổ hợp) (như lớp con của System (Hệ thống))

Service Composition (Tổ hợp dịch vụ) (như lớp con của Composition (Tổ hợp))

Quá trình (như lớp con của Composition (Tổ hợp))

Ngoài ra, xác định thuộc tính kiểu dữ liệu sau:

CompositionPattern (khuôn mẫu tổ hợp)

11.2  Lớp tổ hợp

Một tổ hợp là kết quả của việc nhóm gộp một tập hợp các sự vật, sự việc cho một mục đích cụ thể. Lưu ý đặc biệt là hành động biên soạn được phân biệt một cách có mục đích từ kết quả tổ hợp như sự vật, sự việc và theo ý nghĩa mới hơn khái niệm về tổ hợp được sử dụng ở đây. Khái niệm về tổ hợp được thu nạp bởi lớp OWL Composition (Tổ hợp), minh họa trong Hình 12.

Hình 12 – Lớp Composition (Lớp tổ hợp)

Bản chất một tập hợp có tổ chức về sự vật, sự việc khác, đơn giản hơn, lớp Composition (Tổ hợp) là một lớp con của lớp hệ thống. Trong khi một tổ hợp thường cũng là một hệ thống, hệ thống không nhất thiết là một tổ hợp trong đó không nhất thiết là kết quả nào đó, lưu ý ở đây là sự khác biệt giữa một hệ thống tạo ra một kết quả và bản thân hệ thống là một kết quả. Có lẽ một sự khác biệt trông thấy giữa một hệ thống và một tổ hợp là sau đó kết hợp với một khuôn mẫu tổ hợp cụ thể làm cho tổ hợp (như tổng thể) là kết quả khi khuôn mẫu tổ hợp đó được áp dụng cho các phần tử sử dụng trong tổ hợp. Một ngụ ý của điều này là không có một thành phần đơn lẻ nào của một tổ hợp thể hiện (là một phần tử) mà tổ hợp như tổng thể; nói cách khác, bản thân tổ hợp không phải là một trong sự vật, sự việc được nhóm gộp. Mặt khác, tổ hợp là một khái niệm đệ quy (như tất cả các lớp con của System (Hệ thống)), là một hệ thống, tổ hợp cũng là một phần tử có nghĩa là nó có thể được sử dụng bởi một tổ hợp cấp độ cao hơn.

Trong bối cảnh bản thể học SOA, chỉ các tổ chức chức năng thuộc miền SOA mới được xem xét chi tiết. Lưu ý rằng trường hợp được mô tả đầy đủ về Tổ hợp bởi bản chất là một mối quan hệ sử dụng với ít nhất trường hợp Element (Phần tử). (Nó không nhất thiết phải có nhiều hơn vì khuôn mẫu tổ hợp được áp dụng, ví dụ, có thể là chỉ đơn giản là một phép biến đổi.) Một lần nữa (đối với System (Hệ thống)) điều quan trọng là nhận ra rằng một tổ hợp có thể sử dụng các phần tử bên ngoài ranh giới.

Vì Composition (Tổ hợp) là một lớp con của Element (Phần tử), tất cả các tổ hợp có một ranh giới và không rõ ràng với bên quan sát bên ngoài (quan sát hộp đen). Khuôn mẫu tổ hợp lần lượt là điểm nhìn bên trong (xem hộp trắng) của một tổ hợp. Ví dụ, đối với quan niệm về một tổ hợp dịch vụ tương ứng với sự khác biệt giữa xem tổ hợp dịch vụ là một phần tử cung cấp dịch vụ (mức cao hơn) hoặc xem tổ hợp dịch vụ như cấu trúc hỗn hợp dịch vụ (cấp thấp hơn).

11.3  Thuộc tính kiểu dữ liệu compositionPattern (khuôn mẫu tổ hợp)

11.3.1  Tổng quan

Như thảo luận trong 11.2, bất kỳ tổ hợp nào kết hợp với nó một khuôn mẫu tổ hợp cụ thể, khuôn mẫu đó miêu tả cách một tập hợp các phần tử được nhóm gộp thành một kết quả. Khái niệm về một khuôn mẫu tổ hợp được thu nạp bởi thuộc tính kiểu dữ liệu compositionPattern (khuôn mẫu tổ hợp). Lưu ý rằng mặc dù một số kiểu khuôn mẫu tổ hợp nhất định được quan tâm bắc biệt trong SOA (xem 11.3.2), thuộc tính kiểu dữ liệu compositionPattern (khuôn mẫu tổ hợp) có thể lấy bất kỳ giá trị nào miễn là giá trị mô tả cách nhóm góp các phần tử được sử dụng bởi tổ hợp mà nó được liên kết.

11.3.2  Khuôn mẫu tổ hợp phối trí

Một kiểu khuôn mẫu tổ hợp được quan tâm bắc biệt trong SOA là một Phối trí. Trong phối trí (một tổ hợp mà khuôn mẫu tổ hợp là một phối trí), có một phần tử đặc biệt được sử dụng bởi tổ hợp giám sát và chỉ đạo các phần tử khác. Lưu ý rằng phần tử chỉ đạo một phối trí theo định nghĩa khác với bản thân phối trí (trường hợp Composition (Tổ hợp)).

Nghĩ về một luồng công việc có thể thực thi được phối trí thấp như ví dụ về một phối trí. Luồng công việc thấp xây dựng chính nó là một trong các phần tử đang được sử dụng trong tổ hợp, nhưng nó khác với bản thân tổ hợp, bản thân tổ hợp là kết quả của việc áp dụng (thực thi) các luồng công việc thấp trên các quá trình, các tác nhân con người, các dịch vụ, v.v. được phối trí sắp xếp bởi cấu trúc thấp của luồng công việc.

Ví dụ phi IT là người quản đốc của một đội sửa chữa đường. Nếu nhà quản lý chọn để kiểm soát trực tiếp các tác vụ được thực hiện đội của mình, thì dẫn đến tổ hợp trở thành một phối trí (với người quản đốc là giám đốc và nhà cung cấp của khuôn mẫu tổ hợp). Lưu ý rằng trong các trường hợp khác, với một mô hình tổ hợp khác, đội sửa chữa đường cũng có thể đóng vai trò cộng tác hoặc dàn dựng (xem 11.3.3 và 11.3.4 để biết định nghĩa về cộng tác và dàn dựng).

Như ví dụ cuối cùng cho thấy rõ ràng, việc sử dụng một khuôn mẫu tổ hợp phối trí không đảm bảo rằng “không có gì có thể sai”. Trên thực tế, điều đó phụ thuộc vào khả năng của giám đốc phối trí xử lý các ngoại lệ.

11.3.3  Khuôn mẫu Tổ hợp dàn dựng

Một kiểu khuôn mẫu tổ hợp khác được quan tâm bắc biệt trong SOA là Dàn dựng. Trong dàn dựng (một tổ hợp có khuôn mẫu tổ hợp là một dàn dựng) các phần tử được sử dụng bởi tổ hợp tương tác theo kiểu không định hướng, nhưng với mỗi thành phần tự trị biết và tuân theo một khuôn mẫu hành vi được xác định trước cho toàn bộ tổ hợp.

Nghĩ về một mô hình quá trình như ví dụ của dàn dựng. Mô hình quá trình không chỉ đạo các phần tử bên trong nó, nhưng vẫn cung cấp một khuôn mẫu định trước về hành vi mà mỗi phần tử đó được kỳ vọng phù hợp khi “thực thi”.

11.3.4  Khuôn mẫu Tổ hợp cộng tác

Một kiểu thứ ba của khuôn mẫu tổ hợp được quan tâm đặc biệt trong SOA is Cộng tác. Trong cộng tác (một tổ hợp có khuôn mẫu tổ hợp là một cộng tác) các phần tử được sử dụng bởi tổ hợp tương tác theo kiểu không định hướng, theo từng kế hoạch và mục đích của chúng không có một khuôn mẫu hành vi định trước. Mỗi phần tử đơn giản biết những gì nó đã làm và làm nó độc lập, bắt đầu tương tác với các thành phần khác của tổ hợp như áp dụng với sáng kiến của riêng mình. Điều này có nghĩa là không có “luồng” định trước về sự cộng tác, mặc dù có thể có thời gian “luồng được nhìn thấy cả các tương tác”.

Ví dụ điển hình về sự cộng tác là một cuộc họp công việc. Không có kịch bản nào cho cuộc họp diễn ra như thế nào và chỉ sau khi cuộc họp kết thúc, chuỗi các tương tác thực sự xảy ra được mô.

11.4  Thuộc tính phối trí và phối trí bởi

Một phối trí có một phần tử đặc biệt giám sát và chỉ đạo các phần tử khác được sử dụng bởi tổ hợp. Kiểu quan hệ này đủ quan trọng để quan niệm trừu tượng được thu nạp trong thuộc tính orchestrates (các dàn dựng) và ngược lại orchestratedBy (dàn dựng bởi).

Một mặt, tổ hợp có tối đa một phần tử dàn dựng nó và số lượng các phần tử chỉ có thể là một nếu trong thực tế khuôn mẫu tổ hợp đó là một phối trí. Mặt khác, phần tử có thể dàn dựng nhiều nhất một tổ hợp mà sau đó có một phối trí như khuôn mẫu tổ hợp.

Lưu ý rằng trong các ứng dụng thực tế của bản thể học, mặc dù Service (dịch vụ) là một lớp con của Element (Phần tử), dịch vụ (là một thể hiện thuần lô-gic) không được mong đợi để dàn dựng một tổ hợp.

11.5  Lớp tổ hợp dịch vụ

Một khái niệm chính của SOA là quan niệm về tổ hợp dịch vụ, kết quả của việc nhóm gộp một tập hợp các dịch vụ để thực hiện một dịch vụ mức cao mới. Khái niệm về tổ hợp dịch vụ được thu nạp bởi The ServiceComposition OWL class (lớp OWL tổ hợp dịch vụ) minh họa trong Hình 13

Hình 13 – Lớp tổ hợp dịch vụ

Vì một tổ hợp dịch vụ là kết quả nhóm gộp một tập hợp các dịch vụ, ServiceComposition (tổ hợp dịch vụ) bản chất là một lớp con của Composition (tổ hợp).

Một tổ hợp dịch vụ có thể và thông thường bổ sung lô-gic (hoặc thậm chí “mã”) qua khuôn mẫu tổ hợp. Lưu ý rằng một tổ hợp dịch vụ bản thân không phải là dịch vụ mức cao mới (để các lớp System (Hệ thống) và Dịch vụ đang bị phân tách); hơn là nó thực hiện (như phần tử) dịch vụ mức cao.

11.6  Lớp quá trình

Một khái niệm chính của SOA khác là quan niệm về quá trình. Một quá trình là một tổ hợp có các phần tử biên soạn thành một chuỗi hoặc một 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. Định nghĩa này phù hợp với, ví dụ, định nghĩa Ký hiệu mô hình hóa quá trình nghiệp vụ (Business Process Modeling Notation – BPMN) 2.0 của một quá trình. (xem Tham khảo [4]). Khái niệm về quá trình được thu nạp bởi lớp OWL Quá trình minh họa trong Hình 14.

Hình 14 – Lớp quá trình

Các phần tử trong các tổ hợp quá trình có thể là sự vật, sự việc như những tác nhân con người, các tác vụ, các dịch vụ, các quá trình khác, v.v… Một quá trình luôn thêm lô gic thông qua khuôn mẫu tổ hợp, kết quả là nhiều hơn các phần. Theo mô hình hợp tác của họ, các quá trình có thể như sau:

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

– Được phối trí: Một mô hình quá trình thể hiện một khuôn mẫu xác định về hành vi thường được gọi là một “Phối trí quá trình”.

– Hợp tác: Không (trước) khuôn mẫu xác định về hành vi (mô hình); quá trình thể hiện quan sát (thực thi) hành vi.

11.7  Tổ hợp dịch vụ và ví dụ quá trình

11.7.1  Ví dụ tổ hợp dịch vụ đơn giản

Việc sử dụng ví dụ tổ hợp dịch vụ, các dịch vụ A và B là các trường hợp Service (Dịch vụ) và tổ hợp A và B là một trường hợp ServiceComposition (tổ hợp dịch vụ) (sử dụng A và B):

– A và B là các trường hợp Service (Dịch vụ),

– X là một trường hợp ServiceComposition (Tổ hợp dịch vụ), và

– X sử dụng cả A và B (soạn thảo chúng theo theo khuôn mẫu tổ hợp dịch vụ).

Lưu ý rằng có nhiều cách khác nhau trong đó khuôn mẫu tổ hợp dịch vụ có thể thành A và B, tất cả đều có liên quan trong tình huống khác. Ví dụ, các giao diện X có thể hoặc không thể gồm một vài tập con của giao diện A và B. Hơn nữa, các giao diện A và B cũng có thể hoặc không thể (trực tiếp) bất khả xâm phạm mà không đi qua X, nghĩa là, vấn đề các hợp đồng dịch vụ và/hoặc các chính sách truy cập áp dụng cho A và B. Cuối cùng, X cũng có thể sử dụng các phần tử khác mà không phải là dịch vụ nào cả (ví dụ là mã tổ hợp, các bộ chuyển đổi, v.v….).

11.7.2  Ví dụ quá trình

Việc sử dụng ví dụ quá trình, các tác vụ T1 và T2 là các trường hợp Task (Tác vụ), các vai trò R1 và R2 là các trường hợp Element (Phần tử) và tổ hợp của T1, T2, R1 và R2 là một trường hợp Quá trình (sử dụng T1, T2, R1 và R2):

– T1 và T2 là các trường hợp Task (Tác vụ),

– R1 và R2 là các trường hợp Element (Phần tử),

– Y là một trường hợp Process (Quá trình), và

– Y sử dụng tất cả T1, T2, R1 và R2 (soạn thảo chúng theo theo khuôn mẫu tổ hợp dịch vụ).

11.7.3  Ví dụ quá trình và tổ hợp dịch vụ

Xây dựng trên ví dụ quá trình trong 11.7.2, nếu T1 được làm bằng cách sử dụng dịch vụ S thì:

– S là một trường hợp Service (Dịch vụ), và

– T1 sử dụng S.

Lưu ý rằng tùy thuộc vào cách tiếp cận thiết kế cụ thể được chọn (và dẫn đến khuôn mẫu tổ hợp), Y có thể hoặc không thể sử dụng S trực tiếp. Điều này phụ thuộc vào việc Y mang liên kết giữa T1 và S hay liệu ràng buộc đó có được đóng gói trong T1 hay không.

11.7.4  Ví dụ rửa xe ô tô

Xem Phụ lục A về khía cạnh Process (Quá trình) của ví dụ rửa xe ô tô.

12  Policy (Chính sách)

12.1  Tổng quan

Các chính sách, các tác nhân con người xác định chúng và sự vật, sự việc mà chúng áp dụng là những khía cạnh quan trọng của bất kỳ hệ thống nào, chắc chắn cũng là các hệ thống SOA với nhiều các phần tử tương tác khác nhau của chúng. Các chính sách có thể áp dụng cho bất kỳ phần tử nào trong hệ thống. Khái niệm về Chính sách được thu nạp bởi lớp Policy (Chính sách) và các mối quan hệ với HumanActor (Tác nhân con người) và các lớp Thing (sự vật, sự việc) khác.

Điều này mô tả các lớp của bản thể học sau: Policy (Chính sách)

Ngoài ra, xác định các thuộc tính sau:

appliesTo (Áp dụng với) và isSubjectTo (phải chịu)

thiết lập Policy (Chính sách) và isSetBy (được thiết lập bởi)

12.2  Lớp Policy (Chính sách)

Một chính sách là một tuyên bố về hướng mà một tác nhân con người có thể có ý định dõi theo hoặc có thể có ý định một tác nhân con người khác nên làm theo. Việc biết các chính sách áp dụng cho một sự vật, sự việc làm cho nó dễ dàng hơn và minh bạch hơn để tương tác với điều gì đó. Khái niệm về chính sách được thu nạp bởi lớp OWL Policy (Chính sách) minh họa trong Hình 15.

Hình 15 – Lớp Policy (Chính sách)

Chính sách như khái niệm chung và liên quan ngoài miền SOA. Với mục đích bản thể học SOA, không cần thiết hoặc có liên quan để hạn chế bản chất chung của chính lớp Policy (chính sách). Các mối quan hệ giữa Policy (Chính sách) và HumanActor (Tác nhân con người) bị ràng buộc bởi các hạn chế cụ thể về SOA đã được áp dụng trên định nghĩa của HumanActor (Tác nhân con người).

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à vận hành thông qua các quy tắc cụ thể. Tiêu chuẩn này ở cấp độ khái niệm và không bao gồm các khía cạnh thiết kế như vậy trong bản thể học.

Chính sách khác biệt với tất cả các khái niệm khác trong bản thể học này; do đó, lớp Policy (Chính sách) được định nghĩa là sự phân chia với tất cả các lớp xác định khác. Đặc biệt, Policy (Chính sách) được phân chia với ServiceContract (Hợp đồng dịch vụ). Mặc dù các chính sách có thể áp dụng các hợp đồng dịch vụ chẳng hạn như chính sách an ninh đối với người có thể thay đổi dịch vụ đã cho hoặc ngược lại tham khảo bởi các hợp đồng dịch vụ như phần các Điều, các điều kiện và các quy tắc tương tác mà người tham gia đồng ý tương tác, các hợp đồng dịch vụ bản thân chúng không phải là chính sách vì chúng không mô tả một hành động dự định trước.

12.3  Thuộc tính áp dụng với và phải chịu

Các chính sách có thể áp dụng cho sự vật, sự việc khác ngoài các phần tử; 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. Ví dụ, chính sách an ninh có thể quy định những tác nhân con người nào có quyền thay đổi một số sách chính khác. Thuộc tính appliesTo (áp dụng với) và ngược lại isSubjectTo (phải chịu), thu nạp quan niệm trừu tượng mà một chính sách có thể áp dụng cho bất kỳ trường hợp nào của Thing (sự vật, sự việc). Lưu ý cụ thể rằng Phần tử là một lớp con của Thing (sự vật, sự việc), do đó các chính sách bằng suy luận có thể áp dụng cho bất kỳ trường hợp nào của Element (phần tử).

Một mặt, chính sách có thể áp dụng là không (trong trường hợp chính sách đã được xây dựng nhưng chưa áp dụng rõ ràng đối với bất kỳ thứ gì), là một hoặc nhiều trường hợp Thing (sự vật, sự việc). Lưu ý rằng có một chính sách áp dụng cho nhiều điều không có nghĩa là những điều này là như nhau, chúng chỉ là (một phần) sắp đặt bởi cùng một ý định. Mặt khác trường hợp Thing (sự vật, sự việc) có thể phải chịu không, hoặc nhiều chính sách. Lưu ý rằng trong đó nhiều chính sách áp dụng cho cùng trường hợp Thing (sự vật, sự việc) này thường là do nhiều chính sách từ nhiều miền chính sách khác nhau (chẳng hạn như an ninh và quản trị).

Bản thể học SOA có thể không cố gắng liệt kê các miền chính sách khác nhau; các chi tiết tập trung vào chính sách này được coi là phù hợp hơn cho một bản thể học chính sách. Nó có giá trị chỉ ra rằng một bản thể học chính sách cụ thể cũng có thể hạn chế (nếu muốn) các kiểu điều mà các chính sách có thể áp dụng.

12.4  Thuộc tính setsPolicy (thiết lập chính sách) và isSetBy (được thiết lập bởi)

Thuộc tính setsPolicy (thiết lập chính sách) và ngược lại isSetBy (được thiết lập bởi), thu nạp quan niệm trừu tượng mà một chính sách có thể thiết lập bởi một hoặc nhiều tác nhân con người.

Một mặt, chính sách có thể được thiết lập bởi không (trong trường hợp những tác nhân con người thiết lập chính sách việc lựa chọn không được xác định hay thu nạp), một, hoặc nhiều tác nhân con người. Lưu ý đặc biệt là một số chính sách được thiết lập bởi nhiều tác nhân con người trong liên kết với nhau, nghĩa là tất cả tác nhân con người này cần thảo luận và chấp thuận chính sách trước khi nó có thể khả năng tác động đến. Ví dụ trong môi trường thực là hai cha mẹ liên kết với nhau trong việc thiết lập các chính sách cho hành vi trẻ em có thể chấp nhận được. Mặt khác, tác nhân con người có thể thiết lập (hoặc là một phần của việc thiết lập) nhiều chính sách.

Bản thể học SOA tách riêng có mục đích việc thiết lập bản thân chính sách và ứng dụng của chính sách tới một hoặc nhiều trường hợp Thing (sự vật, sự việc). Trong vài trường hợp, hai hành động này có thể bị ràng buộc không thể tách rời, nhưng trong các trường hợp khác, chúng không xác định. Ví dụ như vậy là một chính sách phù hợp tổng thể được xây dựng ở cấp độ doanh nghiệp nhưng được áp dụng bởi cán bộ phù hợp trong mỗi ngành nghề nghiệp vụ.

Ngoài ra, trong khi trường hợp đặc biệt quan tâm đối với bản thể học này là nhà cung cấp dịch vụ có một chính sách cho dịch vụ, chính sách cho một dịch vụ không nhất thiết thuộc sở hữu của nhà cung cấp. Ví dụ, các quy định về vệ sinh và thực phẩm của chính phủ (một chính sách là luật) bao gồm các dịch vụ nhà hàng độc lập với bất kỳ điều gì mong muốn hoặc được xác định bởi chủ nhà hàng.

12.5  Ví dụ

12.5.1  Ví dụ rửa xe ô tô

Xem A.5 đối với khía cạnh Policy (Chính sách) về ví dụ rửa xe ô tô.

13  Sự kiện

13.1  Tổng quan

Các sự kiện và các phần tử tạo ra hoặc đáp ứng với chúng là những khía cạnh quan trọng của bất kỳ hệ thống phát ra sự kiện. Các hệ thống SOA trên thực tế, thường là phát ra sự kiện, do đó. Sự kiện được định nghĩa là một khái niệm trong Bản thể học SOA.

Điều này mô tả các lớp của bản thể học sau:

Event (Sự kiện)

Ngoài ra, xác định các thuộc tính sau:

generates (tạo thành) và generatedBy (được tạo thành bởi)

respondsTo (đáp ứng) và respondedToBy (được đáp ứng bởi)

13.2  Lớp Sự kiện

Một Sự kiện là điều gì đó xảy ra, mà một phần tử có thể chọn đáp ứng. Các sự kiện có thể được đáp ứng bởi bất kỳ phần tử nào. Tương tự, các sự kiện có thể được tạo ra (được phát ra) bởi bất kỳ phần tử nào. Việc biết các sự kiện tạo ra hoặc đáp ứng bởi một phần tử làm cho nó dễ dàng hơn và minh bạch hơn để tương tác với phần tử đó. Lưu ý rằng một số Sự kiện có thể xảy ra cho dù được tạo ra hay được đáp ứng bởi một phần tử hoặc không. Khái niệm về một Sự kiện được thu nạp bởi lớp OWL Sự kiện minh họa trong Hình 16.

Hình 16 – Lớp Sự kiện

Sự kiện như khái niệm chung và có liên quan đến miền của SOA cũng như nhiều tên miền khác. Đối với mục đích bản thể học, Sự kiện được sử dụng theo nghĩa chung.

Từ quan điểm thiết kế, các sự kiện có thể có nhiều phần chi tiết hơn hoặc có thể được biểu diễn và vận hành thông qua cú pháp hoặc ngữ nghĩa cụ thể. TCVN 12482 (ISO/IEC 18384) này ở cấp độ khái niệm và không bao gồm các khía cạnh thiết kế như vậy trong bản thể học.

13.3  Thuộc tính tạo thành và được tạo thành bởi

Các sự kiện có thể, nhưng không nhất thiết, được tạo ra bởi các phần tử. Thuộc tính generates (tạo thành) và ngược lại generatedBy (được tạo thành bởi), thu nạp quan niệm trừu tượng mà một phần tử tạo thành một sự kiện.

Lưu ý rằng sự kiện giống nhau có thể được tạo ra bởi nhiều phần tử khác nhau. Tương tự, phần tử giống nhau có thể tạo ra các sự kiện khác nhau

13.4  Thuộc tính respondsTo (đáp ứng) và respondedToBy (được đáp ứng bởi)

Các sự kiện có thể, nhưng không nhất thiết, được đáp ứng bởi các phần tử. Thuộc tính respondsTo (đáp ứng) và ngược lại respondedToBy (được đáp ứng bởi), thu nạp quan niệm trừu tượng mà một phần tử đáp ứng với một sự kiện.

Sự kiện giống nhau có thể đáp ứng với nhiều phần tử khác nhau. Tương tự, phần tử giống nhau có thể đáp ứng nhiều sự kiện khác nhau.

 

Phụ lục A

(tham khảo)

Ví dụ hoàn thiện rửa xe ô tô

A.1  Quy định chung

Phụ lục này gồm ví dụ hoàn thiện rửa xe ô tô đã được sử dụng trong các phần thông qua các Điều xác định của bản thể học.

A.2  Khía cạnh tổ chức

Joe chủ sở hữu chọn tổ chức doanh nghiệp của anh ta theo hai đơn vị tổ chức: Administration (hành chính) và CarWash (Rửa xe ô tô).

– CarWashBusiness (Nghiệp vụ rửa xe ô tô) là một trường hợp cả HumanActor (tác nhân con người) và System (Hệ thống),

– Administration (Hành chính) là một trường hợp HumanActor (tác nhân con người) (đơn vị tổ chức),

– CarWash (Rửa xe ô tô) là một trường hợp HumanActor (tác nhân con người) (đơn vị tổ chức),

– CarWashBusiness (nghiệp vụ rửa xe ô tô) sử dụng (có các đơn vị tổ chức) Administration (hành chính) và CarWash (rửa xe ô tô),

– AdministrativeSystem (hệ thống-hành chính) là một trường hợp System (hệ thống),

– Administration (hành chính) thể hiện AdministrativeSystem (hệ thống-hành chính),

– Hệ thống-CarWash (Rửa xe ô tô) là một trường hợp System (hệ thống), và

– CarWash (rửa xe ô tô) thể hiện Hệ thống-CarWash (rửa xe ô tô).

Và sử dụng các vai trò được xác định rõ trong mỗi tổ chức:

– Owner (Chủ sở hữu) (vai trò) là một trường hợp Element (phần tử) và được sử dụng bởi AdministrativeSystem (Hệ thống-hành chính),

– Joe là một trường hợp HumanActor (tác nhân con người) và được thể hiện bởi (có vai trò) Owner (chủ sở hữu),

– Secretary (thư ký) (vai trò) là một trường hợp Element (phần tử) và được sử dụng bởi AdministrativeSystem (hệ thống-hành chính),

– Mary là một trường hợp HumanActor (tác nhân con người) và được thể hiện bởi (có vai trò) Secretary (thư ký),

– Người BasicWash (rửa cơ bản) (vai trò) là một trường hợp Element (phần tử) và được sử dụng bởi CarWashSystem (Rửa xe ô tô),

– John là một trường hợp HumanActor (tác nhân con người) và được thể hiện bởi (có vai trò) Người BasicWash (rửa cơ bản),

– WashManager (nhà quản lý rửa xe) (vai trò) là một trường hợp Element (phần tử) và được sử dụng bởi CarWashSystem (rửa xe ô tô),

– WashOperator (người vận hành) rửa (vai trò) là một trường hợp Element (phần tử) và được sử dụng bởi CarWashSystem (rửa xe ô tô), và

– Jack là một trường hợp Human Actor (tác nhân con người) và được thể hiện bởi (có các vai trò) cả WashManager (nhà quản lý rửa xe) và WashOperator (người vận hành rửa).

Hình A.1 – Ví dụ rửa xe ô tô – Khía cạnh tổ chức

A.3  Các Dịch vụ rửa

Joe đưa ra hai dịch vụ khác nhau cho các khách hàng của anh ta: BasicWash (rửa cơ bản) và GoldWash (rửa cao cấp):

– GoldWash (rửa cao cấp) là một trường hợp Service (dịch vụ),

– BasicWash (rửa cơ bản) là một trường hợp Service (dịch vụ),

– CarWash (rửa xe ô tô) thực hiện cả BasicWash (rửa cơ bản) và GoldWash (rửa cao cấp), và

– WashManager (nhà quản lý rửa xe) thể hiện cả BasicWash (rửa cơ bản) và GoldWash (rửa cao cấp) (tức là nó là điểm tương tác tại vị trí các khách hàng có thể đặt hàng các dịch vụ cũng như trả tiền cho dịch vụ).

Để đáp lại việc thanh toán, dịch vụ BasicWash (rửa cơ bản) của Joe làm sạch chiếc xe của khách hàng Judy:

– Judy là một trường hợp HumanActor (tác nhân con người) (khách hàng),

– Hợp đồng BasicWash (rửa cơ bản) là một trường hợp ServiceContract (hợp đồng dịch vụ),

– BasicWash (rửa cơ bản) có hợp đồng hợp đồng BasicWash (rửa cơ bản),

– CleanCar (làm sạch xe) là một trường hợp Effect (khả năng tác động),

– Hợp đồng BasicWash (rửa cơ bản) quy định CleanCar (làm sạch xe) là khả năng tác động của nó,

– Hợp đồng BasicWash (rửa cơ bản) liên quan đến các bên tham gia CarWashBusiness (nghiệp vụ rửa xe ô tô) và Judy và quy định rằng Judy (như khách hàng pháp lý) trả CarWashBusiness (nghiệp vụ rửa xe ô tô) (như nhà cung cấp pháp lý) $10 cho một lần BasicWash (rửa cơ bản) với khả năng tác động của (một) CleanCar (làm sạch xe). Lưu ý rằng BasicWash (rửa cơ bản) thực sự được thực hiện bởi CarWash (rửa xe ô tô) và không phải bởi nhà cung cấp pháp lý CarWashBusiness (nghiệp vụ rửa xe ô tô), trong ví dụ cụ thể này CarWash (rửa xe ô tô) xảy đến với một thành phần của CarWashBusiness (nghiệp vụ rửa xe ô tô) nhưng không phải lúc nào cũng vậy, CarWash (rửa xe ô tô) có thể có một vài bên thứ ba là nhà cung cấp và

– Judy sử dụng WashManager (nhà quản lý rửa xe) (để gọi là BasicWash (rửa cơ bản) dịch vụ).

Lưu ý rằng trong ví dụ này Judy không tương tác với (trừu tượng) BasicWash (rửa cơ bản) dịch vụ trực tiếp, thay vào đó cô ấy tương tác với WashManager (nhà quản lý rửa xe) thể hiện dịch vụ. Điều này là do Joe quyết định rằng trong khách hàng rửa xe của mình không được tương tác trực tiếp với máy rửa.

Hình A.2 – Ví dụ rửa xe ô tô – Các Dịch vụ rửa

A.4  Giao diện cho các Dịch vụ rửa

Cách tương tác với các dịch vụ rửa xe đơn giản đối với khách hàng, anh ta hoặc cô ta chỉ đơn giản là đưa tiền cho WashManager (nhà quản lý rửa xe) và yêu cầu phải rửa xe bằng một trong hai dịch vụ rửa có sẵn. Do thực tế là Joe đã quyết định chuyển WashManager (nhà quản lý rửa xe) giữa khách hàng và máy rửa, khách hàng thực sự không bao giờ tương tác với bản thân dịch vụ rửa. Một dịch vụ ủy nhiệm được cung cấp bởi WashManager (nhà quản lý rửa xe) có thể đã được xác định chính thức, nhưng mức độ hình thức trong ví dụ thực tế này đã bị bỏ qua.

WashManager (nhà quản lý rửa xe) lần lượt tương tác với các dịch vụ rửa thông qua các giao diện của chúng được xác định như sau:

– WashingMachineInterface (giao diện máy rửa) là một trường hợp ServiceInterface (giao diện dịch vụ).

– TypeOfWash (kiểu rửa) là một trường hợp InformationType (kiểu thông tin);

– WashingMachineInterface (giao diện máy rửa) có Kiểu rửa đầu vào;

– BasicWash (rửa cơ bản) có giao diện WashingMachineInterface (Giao diện máy rửa);

– GoldWash (rửa cao cấp) có giao diện WashingMachineInterface (Giao diện máy rửa);

Lưu ý rằng cả hai dịch vụ rửa trên thực tế đều có cùng một giao diện dịch vụ. Mặc dù Joe đã chọn để cung cấp BasicWash (rửa cơ bản) và GoldWash (rửa cao cấp) như hai dịch vụ khác nhau, cả hai đều trong khả năng tác động được thực hiện bởi cùng một máy rửa (một cách đơn giản là phải chọn kiểu rửa khi khởi tạo máy rửa).

A.5  Các Quá trình rửa

Một phần quan trọng của hệ thống rửa xe là bản thân các quá trình rửa xe như sau:

– AutomatedCarWashProcess (quá trình rửa xe ô tô tự động) là một trường hợp cả Process (quá trình) và Orchestration (phối trí);

– Wash (rửa) là một trường hợp Task (tác vụ) và được sử dụng bởi AutomatedCarWashProcess (quá trình rửa xe ô tô tự động);

– Dry (làm khô) là một trường hợp Task (tác vụ) và được sử dụng bởi AutomatedCarWashProcess (quá trình rửa xe ô tô tự động);

– CarWash (rửa xe ô tô) tự động là một trường hợp Element (phần tử) (máy rửa tự động) và thể hiện AutomatedCarWashProcess (quá trình rửa xe ô tô tự động) (đóng gói quá trình) cũng như chỉ đạo AutomatedCarWashProcess (quá trình rửa xe ô tô tự động);

– Quá trình CarWash (rửa xe ô tô) là một trường hợp Process (quá trình) và được sử dụng bởi (một phần của) Hệ thống-CarWash (rửa xe ô tô) (không cần phải tạo một khối xây dựng minh bạch mà không rõ ràng);

– CarWash (rửa xe ô tô) tự động được sử dụng bởi Quá trình CarWash (rửa xe ô tô) (hoạt động tự động trong quá trình);

– WashWindows (cửa sổ rửa) là một trường hợp Task (tác vụ) và được hoàn thành bởi John;

– PreWash (rửa trước) là một trường hợp Element (phần tử), thể hiện WashWindows (cửa sổ rửa) và được sử dụng bởi Quá trình CarWash (rửa xe ô tô) (hoạt động lô-gic trong quá trình);

– PrewashGuy (người rửa cơ bản) là một thành phần của Quá trình CarWash (rửa xe ô tô) (vai trò trong quá trình);

– PushWashButton (nhấn nút rửa) là một trường hợp Task (tác vụ) và được hoàn thành bởi Jack;

– InitiateAutomatedWash (khởi động rửa tự động) là một trường hợp Element (phần tử), thể hiện PushWashButton (nhấn nút rửa) và được sử dụng bởi Quá trình CarWash (rửa xe ô tô) (hoạt động lô-gic trong quá trình);

– WashOperator (người vận hành rửa) là một thành viên của Quá trình CarWash (rửa xe ô tô) (vai trò trong quá trình).

Hình A.3 – Ví dụ rửa xe ô tô – Các Quá trình rửa

A.5.1  Các chính sách rửa

Joe thiết lập chính sách trả trước cho các dịch vụ rửa như sau:

– PaymentUpFront (thanh toán trả trước) là một trường hợp cả Policy (chính sách);

– PaymentUpFront (thanh toán trả trước) được thiết lập bởi Joe;

– PaymentUpFront (thanh toán trả trước) áp dụng cho cả GoldWash (rửa cao cấp) và BasicWash (rửa cơ bản).

Lưu ý cách thức chính sách PaymentUpFront (thanh toán trả trước) tăng cường hợp đồng dịch vụ Hợp đồng BasicWash (rửa cơ bản). Trong khi Hợp đồng BasicWash (rửa cơ bản) chỉ quy định Judy phải trả $10 cho một lần dùng dịch vụ BasicWash (rửa cơ bản), chính sách PaymentUpFront (thanh toán trả trước) quy định thanh toán phải xảy ra trước đó. Một trong những lợi thế của chính sách tách biệt hợp đồng dịch vụ là chính sách thanh toán có thể thay đổi độc lập so với hợp đồng dịch vụ. Ví dụ, tại một số thời điểm sau khi Joe có thể quyết định rằng khách hàng định kỳ không cần trả trước và có thể thay đổi chính sách này mà không thay đổi bất kỳ điều gì khác liên quan đến CarWashBusiness (nghiệp vụ rửa xe ô tô).

 

Phụ lục B

(tham khảo)

Ví dụ mua hàng qua internet

Jill mua một TIVI mới trên Internet thông qua một trang bán hàng trực tuyến

– Jill là một trường hợp Actor (con người).

– PurchaseTV (mua TIVI) là một trường hợp Task (tác vụ).

– Jill thực hiện PurchaseTV (mua TIVI).

– BuyTVOnline (mua TIVI trực tuyến) là một trường hợp Service (dịch vụ).

– PurchaseTV (mua TIVI) sử dụng BuyTVOnline (mua TIVI trực tuyến).

OnlineTVSales (bán TIVI trực tuyến) là công ty bán TIVI:

– OnlineTVSales (bán TIVI trực tuyến) là một trường hợp Actor (con người) (tổ chức).

– BuyTVOnlineContract (hợp đồng mua TIVI trực tuyến) là một trường hợp ServiceContract (hợp đồng dịch vụ) (và mô tả cách tương tác với BuyTVOnline (mua TIVI trực tuyến) cũng như hợp đồng pháp lý giữa người mua TIVI và bán TIVI trực tuyến).

– BuyTVOnline (mua TIVI trực tuyến) có hợp đồng BuyTVOnlineContract (hợp đồng mua TIVI trực tuyến).

– OnlineTVSales (bán TIVI trực tuyến) là bên tham gia vào BuyTVOnlineContract (hợp đồng Mua TIVI trực tuyến). Jill là bên tham gia vào BuyTVOnlineContract (hợp đồng Mua TIVI trực tuyến).

Trang trực tuyến triển khai sử dụng phần mềm trang trực tuyến:

– OnlineSalesComponent (thành phần bán hàng trực tuyến) là một trường hợp Element (phần tử).

– OnlineSalesComponent (thành phần bán hàng trực tuyến) thực hiện OnlineTVSales (bán TIVI trực tuyến).

– SelectWhatToBuyComponent (thành phần chọn mua gì) là một trường hợp Element (phần tử).

– SelectWhatToBuyService (dịch vụ chọn mua gì) là một trường hợp Service (dịch vụ).

– SelectWhatToBuyComponent (thành phần chọn mua gì) thực hiện SelectWhatToBuyService (dịch vụ chọn mua gì).

– PayComponent (thành phần thanh toán) là một trường hợp Element (phần tử).

– PayService (dịch vụ thanh toán) là một trường hợp Service (dịch vụ).

– PayComponent (thành phần thanh toán) thực hiện PayService (dịch vụ thanh toán).

– OnlineSalesComponent (thành phần bán hàng trực tuyến) cũng là một trường hợp ServiceComposition (tổ hợp dịch vụ).

– OnlineSalesComponent (thành phần bán háng trực tuyến) sử dụng SelectWhatToBuyService (dịch vụ chọn mua gì) và PayService (dịch vụ thanh toán).

Để hoàn tất giao dịch mua, Jill cần thanh toán cho giao dịch mua và sau đó TIVI được giao đến:

– PayForTV (thanh toán cho TIVI) là một trường hợp Task (tác vụ).

– Jill thực hiện PayForTV (thanh toán cho TIVI).

– PayForTV (thanh toán cho TIVI) sử dụng BuyTVOnline (mua TIVI trực tuyến).

– DeliverTV (chuyển giao TIVI) là một trường hợp Task (tác vụ)

– OnlineTVSales (bán TIVI trực tuyến) thực hiện DeliverTV (chuyển giao TIVI).

– OnlineTVSalesProcess (quá trình bán TIVI trực tuyến) là một trường hợp Process (quá trình).

– OnlineTVSalesProcess (quá trình bán TIVI trực tuyến) sử dụng Jill. OnlineTVSales (bán TIVI trực tuyến), PurchaseTV (mua TIVI), PayForTV (thanh toán cho TIVI) và DeliverTV (chuyển giao TIVI).

 

Phụ lục C

(quy định)

Định nghĩa OWL về Bản thể học SOA

Bản thể học OWL có sẵn trực tuyến trên: http://www.w3.org/2007/OWL/wiki/OWL Working Group

Bản thể học được tái tạo như dưới đây.

 

Phụ lục D

(tham khảo)

Ma trận mối quan hệ Lớp

Phụ lục này gồm một ma trận quan hệ lớp để minh họa các mối quan hệ lớp-đến-lớp bên trong các định nghĩa OWL của bản thể học SOA. Ma trận tiền định bắt nguồn từ các định nghĩa OWL của bản thể học. Mỗi hàng X và cột Y tương ứng với một lớp OWL. Quan hệ xuất hiện trong ô (X, Y), khi và chỉ khi, lớp X là một phần của miền và lớp Y là một phần trong dải thuộc tính OWL tương ứng. Lưu ý điều này có nghĩa các thuộc tính kiểu dữ liệu (không có dải) không gồm trong ma trận mối quan hệ lớp.

Như đã nêu trong nội dung tiêu chuẩn, có bốn mối quan hệ trong bảng (cộng với các nghịch đảo và dẫn xuất lớp con) về mặt kỹ thuật cho phép theo các định nghĩa OWL, nhưng không kỳ vọng sẽ xảy ra trong ứng dụng thực tế của bản thể học. Cụ thể, không kỳ vọng: các dịch vụ thực hiện dịch vụ; các dịch vụ sử dụng phần tử (một cách trực tiếp), các dịch vụ thể hiện các phần tử và các dịch vụ dàn dựng các tổ hợp, tất cả do Lớp Service (Dịch vụ) đang được định nghĩa như một thể hiện lô-gic của một tập các hoạt động; xem chi tiết 10.3, 10.5.1, 10.5.2 và 11.3.2 để biết chi tiết.

 

Bảng D.1

Phần tử

Hệ thống

Dịch vụ

Tác nhân con người

Tác vụ

Tổ hợp

Quá trình

Tổ hợp dịch vụ

Hợp đồng dịch vụ

Khả năng tác động

Giao diện Dịch vụ

Information Type (Kiểu thông tin)

Sự Kiện

Policy (Chính sách

Thing (sự vật, sự việc)

Phần tử

sử dụng được sử dụng bởi thể hiện thể hiện bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi thực hiện

sử dụng được sử dụng bởi thể hiện thể hiện bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng

tạo thành đáp ứng

phải chịu

Hệ thống

sử dụng được sử dụng bởi thể hiện thể hiện bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi thực hiện

sử dụng được sử dụng bởi thể hiện thể hiện bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng

tạo thành đáp ứng

phải chịu

Dịch vụ

sử dụng được sử dụng bởi thể hiện thể hiện bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi thực hiện thực hiện bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi thực hiện bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi thực hiện bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng

hasCon-tract

hasInter-face

tạo thành đáp ứng

phải chịu

Tác nhân con người

sử dụng được sử dụng bởi thể hiện thể hiện bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi thực hiện

sử dụng được sử dụng bởi thể hiện thể hiện bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi does

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng

isPartyTo

tạo thành đáp ứng

Thiết lập chính sách phải chịu

Tác vụ

sử dụng được sử dụng bởi thể hiện thể hiện bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi thực hiện

sử dụng được sử dụng bởi thể hiện thể hiện bởi thực hiện bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng

tạo thành đáp ứng

phải chịu

Tổ hợp

sử dụng được sử dụng bởi thể hiện thể hiện bởi được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi thực hiện được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng bởi

tạo thành đáp ứng

phải chịu

Quá trình

sử dụng được sử dụng bởi thể hiện thể hiện bởi được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi thực hiện được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng bởi

tạo thành đáp ứng

phải chịu

Tổ hợp dịch vụ

sử dụng được sử dụng bởi thể hiện thể hiện bởi được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi thực hiện được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng được dàn dựng bởi

sử dụng được sử dụng bởi thể hiện thể hiện bởi các dàn dựng bởi

tạo thành đáp ứng

phải chịu

Hợp đồng dịch vụ

Hợp đồng cho

Liên quan bên tham gia

quy định

phải chịu

Khả năng tác động

được quy định bởi

phải chịu

Giao diện dịch vụ

isInterfaceOf

có đầu vào có đầu ra

phải chịu

Kiểu thông tin

đầu vào tại đầu ra tại

phải chịu

Sự kiện

được tạo bởi đáp ứng bởi

được tạo bởi đáp ứng bởi

được tạo bởi đáp ứng bởi

được tạo bởi đáp ứng bởi

được tạo bởi đáp ứng bởi

được tạo bởi đáp ứng bởi

được tạo bởi đáp ứng bởi

được tạo bởi đáp ứng bởi

phải chịu

Chính sách

áp dụng bới

áp dụng với

áp dụng với

được thiết lập bởi áp dụng với

áp dụng với

áp dụng với

áp dụng với

áp dụng với

áp dụng với

áp dụng với

Applies To

áp dụng với

áp dụng với

áp dụng với phải chịu

áp dụng với

Sự vật, sự việc

phải chịu

 

 

Phụ lục E

(tham khảo)

Ánh xạ thuật ngữ giữa các phần SOA RA

Phụ lục này gồm một bảng ánh xạ các định nghĩa trong các tiêu chuẩn trong bộ TCVN 12482. Cụ thể, các định nghĩa trong TCVN 12482-1 (ISO/IEC 18384-1) cho các thuật ngữ bản thể học trong TCVN 12482-3 (ISO/IEC 18384-3) để làm nổi bật vị trí có thông tin bổ sung về từng thuật ngữ và khái niệm cũng như minh họa có thể được tìm thấy cũng như minh họa tại vị trí các định nghĩa được căn chỉnh hoặc sai lệch. Nếu có sai lệch giữa các định nghĩa, thì phân tích định nghĩa đó và sự khác biệt được in nghiêng. Cột thứ ba gồm các thuật ngữ trong TCVN 12482-2 (ISO/IEC 18384-2), tại vị trí các khái niệm được định nghĩa, thảo luận, hoặc Tham khảo. Cột cuối cùng cho biết các thuật ngữ được xác định nếu được định nghĩa ở tại vị trí khác. Nếu không có khái niệm trong TCVN 12482-3 (ISO/IEC 18384-3) hoặc ISO/IEC 18384-4 thì ghi ‘không có (n/a)’ trong cột

TCVN 12482-1 (ISO/IEC 18384-1)	TCVN 12482-3 (ISO/IEC 18384-3)	TCVN 12482-2 (ISO/IEC 18384-2)	Tham khảo khác
Điều và định nghĩa	Điều và định nghĩa/thảo luận	Số Điều mà khái niệm được thảo luận
3.1 tác nhân (ISO/IEC 16500-8:1999, 3.1) 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	n/a	Thảo luận trong 4.5, Điều 9, Điều 11, Điều 12	(ISO/IEC 16500-8:1999, 3.1) BPMN
3.2 kiến trúc (ISO/IEC/IEEE 42010:2011, 3.2). 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.	n/a	Thảo luận trong Điều 4	(ISO/IEC/IEEE 42010:2011, 3.2).
3.3 dàn dựng 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) Đặc tính có thể quan sát được thêm vào định nghĩa bản thể học	11.3.3 Trong dàn dựng (một tổ hợp có khuôn mẫu tổ hợp là một dàn dựng) các phần tử được sử dụng bởi tương tác tổ hợp theo kiểu không định hướng, nhưng với mỗi thành phần tự trị biết và tuân theo một khuôn mẫu hành vi xác định trước cho toàn bộ tổ hợp.	Thảo luận trong Điều 8
3.4 cộng tác 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	11.3.4 Trong cộng tác (một tổ hợp có khuôn mẫu tổ hợp là một cộng tác) các phần tử được sử dụng bởi tương tác tổ hợp theo kiểu không định hướng, theo từng kế hoạch và mục đích của riêng chúng mà không có một khuôn mẫu hành vi xác định trước.	Thảo luận trong Điều 4, Điều 8 Các dịch vụ cộng tác trong 15 Cũng được sử dụng dụng theo nghĩa tiếng Anh
3.5 tổ hợp 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 đó.	11.2 Một tổ hợp là kết quả của việc nhóm gộp một tập hợp sự vật, sự việc vì một mục đích cụ thể.	Thảo luận trong Điều 4, Điều 5, Điều 8, Điều 9, Điều 10, Điều 11, Điều 12, Điều 15 Được sử dụng theo nghĩa tiếng Anh
3.6 điểm cuối 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.	n/a	Thảo luận trong Điều 4, Điều 10
3.7 khả năng tác động Kết quả của một tương tác với dịch vụ (2.20).	10.10 Tương tác với một sự vật, sự việc thực hiện một dịch vụ có khả năng tác động. Chúng bao gồm đầu ra của tương tác đó và là cách một dịch vụ (thông qua phần tử thực hiện nó) đem lại giá trị cho người tiêu dùng của nó	Thảo luận trong Điều 4, Điều 6, Điều 11
3.8 phần tử Đơn vị ở mức trừu tượng đã cho và với ranh giới được xác định rõ ràng.	8.2 Một phần tử là một thực thể mờ và có thể nhìn thấy ở mức trừu tượng nhất định. Phần tử có ranh giới xác định rõ ràng.	Thảo luận trong Điều 4 và nhiều điều khác Cũng được sử dụng theo nghĩa tiếng Anh
3.9 thực thể Phần tử (3.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ụ (3.49) hoặc khách hàng dịch vụ.	n/a chỉ được sử dụng trong định nghĩa của phần tử và trích dẫn từ Thư mục 4	Thảo luận trong Điều 4, Điều 15	SoaML
3.10 Sự kiện Sự việc xảy ra mà một phần tử (2.8) có thể được chọn để đáp ứng	13.2 là sự vật, sự việc xảy ra, mà một phần tử có thể chọn để đáp ứng. Các sự kiện có thể đáp ứng bất kỳ phần tử nào. Tương tự như vậy, các sự kiện định có thể được tạo ra (phát ra) bởi bất kỳ phần tử nào	Thảo luận trong Điều 4, Điều 8, Điều 10, Điều 11, Điều 12
3.11 bối cảnh thi hành 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.	n/a	n/a	SOA RM
3.12 tác nhân con người 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	9.2 Tác nhân con người Một tác nhân con người là một người hoặc tổ chức. Phân tách với các lớp Service (Dịch vụ) và Task (Tác vụ)	Thảo luận trong Điều 4, Điều 9
3.13 tác vụ Tác vụ (2.60) được thực thi bởi một tác nhân con người (2.12)	Task (Tác vụ) không được xác định, tác vụ tương đương 9.4 tác vụ Một tác vụ là một hành động đơn vị nhỏ nhất hoàn thành một kết quả xác định. Các tác vụ được thực hiện bởi người hoặc tổ chức, đặc biệt bởi trường cộng tác nhân con người	Thảo luận trong Điều 8
3.14 Giao diện 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]	10.13 giao diện thảo luận (nhất quán) Khái niệm về một giao diện nói quy định chung là hiểu biết rõ hơn bởi người thực hành, bao gồm quan niệm các giao diện xác định các tham số cho thông tin vào và ra chứa chúng khi được gọi. Điều khác biệt từ miền đến miền là tính chất cụ thể về cách thức giao diện được gọi và cách thông tin được truyền qua lại. Từ quan điểm thiết kế các giao diện có thể có nhiều vận hành hơn hoặc có thể bao gồm các giao diện khác;	Thảo luận trong Điều 4, Điều 7 Điều 9, Điều 14	[NGUỒN: ISO/IEC 2382- 1:1993, 01.01.38]
3.15 nối kết lỏng 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.	n/a 10.13 thảo luận về nối kết lỏng một cách ngẫu nhiên nhưng nhất quán Các giao diện dịch vụ là điển hình, nhưng không cần thiết, thông điệp dựa trên (để 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 độc lập với bất kỳ dịch vụ nào đang thực hiện chúng (để hỗ trợ nối kết lỏng và hòa giải dịch vụ).	Thảo luận trong Điều 4, Điều 6, Điều 10,
3.16 phối trí 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.	11.3 Trong phối trí (một tổ hợp có khuôn mẫu tổ hợp là một phối trí), có một phần tử 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. Lưu ý rằng phần tử chỉ đạo một phối trí bởi định nghĩa khác so với chính phối trí (trường hợp Tổ hợp).	Thảo luận trong Điều 4, Điều 8, Điều 9, Điều 10
3.17 chính sách 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.	12 Một chính sách là một tuyên bố hướng một tác nhân con người có thể có ý định theo hoặc định hướng tác nhân con người khác phải theo. Các chính sách có thể áp dụng cho bất kỳ phần tử nào trong hệ thống. Bản thể học hẹp hơn Phần 1, chỉ cho phép tác nhân con người để xác định/theo chính sách.	Thảo luận trong Điều 4, Điều 11, Điều 13, Điều 14
3.18 quá trình 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	11.6 Một quá trình là một tổ hợp có các phần tử được biên soạn thành một chuỗi hoặc luồng các hoạt động và tương tác với mục tiêu thực hiện một số công việc nhất định.	Thảo luận trong Điều 4, Điều 8, Điều 11, Điều 13, Điều 14 Cũng được xử lý theo nghĩa tiếng Anh
3.19 khả năng tác động môi trường thực Thay đổi liên quan và được trải nghiệm bởi các bên liên quan cụ thể. (Xem Tham khảo [6])	n/a tương đương với ‘khả năng tác động’ khả năng tác động: Tương tác với một sự vật, sự việc thực hiện một dịch vụ có các khả năng tác động. Chúng bao gồm đầu ra của sự tương tác đó và là cách một dịch vụ (thông qua phần tử thực hiện nó) mang lại giá trị cho khách hàng của nó	Thảo luận trong Điều 4, Điều 6	SOA RM
3.20 dịch vụ Biểu diễn lô-gic của một tập các hoạt động có kết quả quy đị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.2, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016))	10.2 Một dịch vụ là một thể hiện lo-gic của một tập các hoạt động có các đầu ra quy định, khép kín, có thể gồm các dịch vụ khác và là một “hộp đen” đối với các khách hàng dịch vụ.	Thảo luận trong Điều 4, phần còn lại của tài liệu
3.21 bên môi giới dịch vụ 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	n/a	n/a
3.22 bus dịch vụ 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.	Thảo luận trong Điều 7, Điều 11, Điều 13	n/a
3.23 dịch vụ đề cử 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ể.	n/a	Thảo luận trong Điều 8
3.24 sổ đăng ký/kho lưu trữ dịch vụ danh mục dịch vụ 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 đó.	n/a	Thảo luận trong Điều 4, Điều 9, Điều 12, Điều 13
3.25 dàn dựng dịch vụ Dàn dựng (2.3) có các phần tử (2.8) là dịch vụ (2.20). (xem Điều 8, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016))	Điều 11 thảo luận nhất quán Không định nghĩa cụ thể nhưng mở rộng tổ hợp – sau đó nó là ‘kết quả của việc nhóm gộp một tập hợp các dịch vụ’ để nhất quán với dàn dựng của dịch vụ	Thảo luận trong Điều 4, Điều 8, Điều 15 Thảo luận dàn dựng về các dịch vụ
3.26 cộng tác dịch vụ Cộng tác (2.4) có các phần tử (2.8) là dịch vụ (2.20) (xem Điều 8, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016))	Điều 11 thảo luận nhất quán Không định nghĩa cụ thể nhưng mở rộng tổ hợp – sau đó nó là ‘kết quả của việc nhóm gộp một tập hợp các dịch vụ’ để nhất quán với cộng tác các dịch vụ	Thảo luận trong Điều 4, Điều 8, Điều 15 Thảo luận cộng tác về các dịch vụ Cộng tác trong nghĩa tiếng Anh
3.27 thành phần dịch vụ Phần tử (2.8) thực thi dịch vụ (2.20)	n/a	Thảo luận trong Điều 4, Điều 6, Điều 7, Điều 8, Điều 15
3.28 tổ hợp dịch vụ 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.	11.5 Một khái niệm chính SOA là quan niệm về tổ hợp dịch vụ, kết quả của việc nhóm gộp một tập hợp các dịch vụ để thực hiện một dịch vụ mức cao mới.	Thảo luận trong Điều 4, Điều 5, Điều 8
3.29 khách hàng dịch vụ Thực thể (2.9) sử dụng dịch vụ (2.20)	10.4 một vài phần tử sử dụng (các khách hàng) một dịch vụ	Thảo luận trong Điều 4, Điều 8, Điều 9, Điều 10
3.30 hợp đồng dịch vụ 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). Phần 1 hạn chế con người tham gia	10.6 Một hợp đồng dịch vụ xác định các điều mục, điều kiện và quy tắc tương tác mà sự tương tác con người tham gia đồng ý (trực tiếp hoặc gián tiếp).	Thảo luận trong Điều 4, Điều 11, Điều 13, Điều 14
3.31 mô tả dịch vụ 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).	n/a được sử dụng trong viện dẫn từ tài liệu tham khảo 10.1 “Một cơ chế cho phép truy cập vào một hoặc nhiều khả năng, tại vị trí truy cập được cung cấp bằng cách sử dụng một giao diện được quy định trước và được thực hiện phù hợp với các ràng buộc và các chính sách như được quy định bởi mô tả dịch vụ.”	Thảo luận trong Điều 4. Điều 6, Điều 7, Điều 14
3.32 triển khai dịch vụ 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).	n/a	Thảo luận trong Điều 4, Điều 6, Điều 14
3.33 phát triển dịch vụ 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.	n/a	Thảo luận trong Điều 6, Điều 14
3.34 phát hiện dịch vụ các hoạt động thực hiện phát triển công nghệ và việc thực hiện vật lý của dịch vụ (3.20) là một phần của vòng đời dịch vụ (3.40) và dẫn đến việc tạo ra một thành phần dịch vụ (3.27)	n/a	Thảo luận trong Điều 4, Điều 5, Điều 6, Điều 14, Điều 15
3.35 phát hiện dịch vụ 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ụ.	n/a	Thảo luận trong Điều 7, Điều 8, Điều 10, Điều 13
3.36 quản trị dịch vụ 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).	n/a	Thảo luận trong Điều 13
3.37 tương tác dịch vụ 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. (xem Tham khảo [6])	10.8 thảo luận các khía cạnh tương tác – không mâu thuẫn với tương tác dịch vụ, nhưng không xác định Các khía cạnh tương tác Bất cứ ai muốn sử dụng một dịch vụ tuân theo các khía cạnh tương tác (như xác định trong thuộc tính kiểu dữ liệu khía cạnh tương tác) của bất kỳ hợp đồng dịch vụ nào áp dụng cho tương tác đó. Theo cách này, các khía cạnh tương tác của một hợp đồng dịch vụ là bối cảnh độc lập; chúng thu nạp các cách được xác định hoặc nội tại trong đó một dịch vụ có thể được sử dụng.	Thảo luận trong Điều 4, Điều 7, Điều 10	SOA RM
3.38 giao diện dịch vụ 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). (xem 7.13, TCVN 12482-3:2018 (ISO/IEC 18384-3:2016).	10.13 Một giao diện dịch vụ xác định cách mà các phần tử có thể tương tác và trao đổi thông tin với một dịch vụ	Thảo luận trong Điều 4, Điều 9, Điều 10, Điều 14
3.39 tính tương hợp dịch vụ 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).	n/a	Thảo luận trong Điều 4, Điều 6, Điều 10, Điều 14
3.40 Cam kết mức dịch vụ 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).	n/a	Thảo luận trong Điều 4, Điều 11, Điều 13, Điều 14
3.41 vòng đời dịch vụ 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.	n/a	Thảo luận trong Điều 4, Điều 11, Điều 13, Điều 14
3.42 quản lý dịch vụ 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).	n/a	Thảo luận trong Điều 4, Điều 11, Điều 13
3.43 lập mô hình dịch vụ 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).	n/a	Thảo luận trong Điều 4, Điều 11, Điều 12, Điều 13
3.44 giám sát dịch vụ 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).	n/a	Thảo luận trong Điều 4, Điều 11, Điều 14
3.45 phối trí dịch vụ Phối trí (2.16) mà trong đó các phần tử (2.8) được phối trí là dịch vụ (2.20).	Điều 11 thảo luận nhất quán Không có định nghĩa cụ thể nào nhưng mở rộng tổ hợp dịch vụ – nó là ‘kết quả của việc nhóm gộp một tập hợp các dịch vụ’ để nhất quán với sự phối trí của dịch vụ	Thảo luận trong Điều 4, Điều 8, Điều 10
3 46 sự định hướng dịch vụ 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ở.	n/a	Thảo luận trong Điều 4
3.47 phân tích hướng dịch vụ 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).	n/a	n/a
3.48 kiến trúc hướng dịch vụ 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ụ.	Giới thiệu Kiến trúc hướng dịch vụ (SOA) là một kiểu kiến trúc trong đó các hệ thống nghiệp vụ và IT được thiết kế về các dịch vụ có sẵn tại một giao diện và các đầu ra những dịch vụ này. Một dịch vụ là một thể hiện lô-gic của một tập các hoạt động được quy định các đầu ra và khép kín, nó có thể bao gồm các dịch vụ khác nhưng khách hàng dịch vụ không cần phải hiểu biết về bất kỳ cấu trúc nội bộ nào.	Thảo luận trong giới thiệu, Điều 4 và khác nữa
3.49 chính sách dịch vụ Chính sách (2.17) được áp dụng cho dịch vụ (2.20).	Chính sách dịch vụ được thảo luận nhưng không được xác định rõ ràng – sử dụng một cách nhất quán áp dụng với một dịch vụ và tách biệt với hợp đồng 12.2 Chính sách Một chính sách là một tuyên bố về hướng mà một tác nhân con người có thể có ý định theo hoặc có thể dành cho một tác nhân con người khác phải theo. Nhà cung cấp một dịch vụ có một chính sách về dịch vụ, chính sách cho một dịch vụ không nhất thiết thuộc về nhà cung cấp. Một trong những lợi thế của việc tách biệt chính sách từ hợp đồng dịch vụ là chính sách thanh toán có thể thay đổi độc lập với hợp đồng dịch vụ.	Thảo luận trong Điều 4, Điều 7, Điều 11, Điều 13
3.50 nhà cung cấp dịch vụ Thực thể (2.9) cung cấp các dịch vụ (2.20).	10.4 một số phần tử thực hiện (cung cấp) một dịch vụ	Thảo luận trong Điều 4, Điều 7, Điều 10, Điều 13, Điều 14
3.51 việc xuất bản dịch vụ 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 lưu trữ 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.	n/a	Thảo luận trong Điều 4, Điều 6, Điều 8, Điều 14, Điều 15 Một số thảo luận trên về việc xuất bản các Sự kiện
3.52 thực thi SOA 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).	n/a	n/a
3.53 sự thuần thục SOA Đá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.	n/a	Thảo luận trong Điều 4, Điều 13
3.54 mô hình thuần thục SOA 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.	n/a	n/a
3.55 tài nguyên 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.	n/a	n/a
3.56 giải pháp SOA 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).	n/a (được sử dụng trong giới thiệu một cách nhất quán)	Thảo luận trong Điều 4, Điều 5, Điều 8, Điều 9, Điều 10, Điều 11, Điều 13, Điều 14, Điều 15
3.57 quản trị giải pháp SOA 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.	n/a	Thảo luận trong Điều 4, Điều 13
3.58 vòng đời giải pháp SOA 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ý.	n/a	Thảo luận trong Điều 4, Điều 11
3.59 quản lý giải pháp SOA 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)	n/a	Thảo luận trong Điều 4, Điều 11
3.60 tác vụ Hành động đơn vị để hoàn thành một kết quả xác định, (xem 18384-3 6.4)	9/4 Một tác vụ là một hành động đơn vị nhỏ nhất hoàn thành một kết quả xác định	Thảo luận trong Điều 4, Điều 8, Điều 15 8.1.2: có tác vụ phân hủy, mà không nhất quán với đơn vị nhỏ nhất	BPMN 2.0
3.61 Dịch vụ Web 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.	n/a	Thảo luận trong Điều 4

 

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

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

[2] ISO/IEC/TR 24800-1:2007, Information technology – JPSearch – Part 1: System framework và components

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

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

[5] ISO Technical Report TR9007, Concepts và Terminology for the Conceptual Schema and the Information Base

[6] OASIS. Reference Architecture for SOA Foundation, Version 1.0, OASIS Public Review Draft 1, April 2008: see docs.oasis-open.org/s oa-rm/soa-ra/v1.0/soa-ra-pr-01.pdf

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

[8] 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

[9] OMG. SOA Modeling Language (OMG SoaML) Specification for the UML Profile và Metamodel for Dịch vụ (UPMS), Revised Submission, OMG Doc. No.: ad/2008-11-01, Object Management Group (OMG), November 2008: see www.omg.org/c gi-bin/doc?ad/08-11-01

[10] OWL. Web Ontology Language, World Wide Web Consortium (W3C), February 2004: xem www.w3.org/TR/owl-ref

[11] Beyond Concepts: Ontology as Reality Representation, by Barry Smith; available from http://ontology.buffalo.edu/bfo/BeyondConcepts.pdf.

[12] Std I.E.E.E. 1471-2000: IEEE Recommended Practice for Architectural Description of Software-intensive Systems (also published as ISO/IEC 42010: 2007); available from standards.ieee.org.

[13] ISO/IEC 42010: 2007, Systems and Software Engineering – Recommended Practice for Architectural Description of Software-intensive Systems, available from www.iso.org.

[14] What is an Ontology? Stanford University; available from w w w-ksl.stanford.edu/kst/what-is-an-ontology.html.

[15] OWL 2 Web Ontology Language (Second Edition), World Wide Web Consortium (W3C), December 2012: see http://w w w.w3.org/TR/owl-overview/

[16] OWL Web Ontology Language Reference, W3C Recommendation, 10 February 2004, World-Wide Web Consortium; available from w w w.w3.org/TR/owl-ref.

 

MỤC LỤC

Lời nói đầu

1  Phạm vi

2  Tài liệu viện dẫn

3  Thuật ngữ, định nghĩa và từ viết tắt

4  Ký hiệu

5  Quy ước

6  Sự phù hợp

7  Tổng quan bản thể học SOA

8  Hệ thống và phần tử

9  HumanActor (Tác nhân con người) và Task (Tác vụ)

10  Service (Dịch vụ), ServiceContract (Hợp đồng dịch vụ) và ServiceInterface (Giao diện dịch vụ)

11  Composition (Tổ hợp) và các lớp con của nó

12  Chính sách

13  Sự kiện

Phụ lục A (tham khảo) Ví dụ hoàn thiện rửa xe ô tô

Phụ lục B (tham khảo) Ví dụ mua hàng qua Intenet

Phụ lục C (quy định) Định nghĩa OWL về Bản thể học SOA

Phụ lục D (tham khảo) Ma trận mối quan hệ Lớp

Phụ lục E (tham khảo) Ánh xạ thuật ngữ giữa các phần SOA RA

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