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.

...

...

...

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,

...

...

...

- 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

...

...

...

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 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.

...

...

...

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)

...

...

...

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)

...

...

...

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ì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ụ

...

...

...

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ô).

...

...

...

- 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ử 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ô

...

...

...

- 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).

...

...

...

- 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)

...

...

...

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ư 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.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.

...

...

...

- 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:

...

...

...

- “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);

...

...

...

- 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.

...

...

...

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ụ

...

...

...

- 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)];

...

...

...

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) 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).

...

...

...

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ý)

...

...

...

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

...

...

...

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.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.

...

...

...

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.

...

...

...

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ụ.

...

...

...

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.

...

...

...

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)

...

...

...

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

...

...

...

- 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ô

...

...

...

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)

...

...

...

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.

...

...

...

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 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.

...

...

...

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

...

...

...

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 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)

...

...

...

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.

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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à

...

...

...

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à

...

...

...

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:

...

...

...

- 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

...

...

...

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).