Tìm hiểu về lập trình hướng dịch vụ – service oriented programming

Tìm hiểu về lập trình hướng dịch vụ – service oriented programming

ĐẠI HỌC QUỐC GIA TPHCM TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

Mục Lục

Danh mục bảng 3

Danh mục hình 5

Lời giới thiệu 6

CHƯƠNG 1: GIỚI THIỆU VỀ LẬP TRÌNH HƯỚNG DỊCH VỤ 7

CHƯƠNG 2: CÁC PHẦN TỬ VÀ ĐẶC TRƯNG CỦA LẬP TRÌNH HƯỚNG DỊCH VỤ 8

2.1 Các phần tử (element) của lập trình hướng dịch vụ 8

2.2 Các đặc trưng của SOP 8

2.3 Ngôn ngữ mô tả kiến trúc – ADL 9

2.4 Các mẫu hỗ trợ cho SOP 11

2.4.1 Mẫu Java 11

2.4.1 Mẫu Jini 12

2.4.1 Mẫu Openwings 15

2.5 Xử lí các hư hỏng của dịch vụ 19

2.5.1 Giải pháp không làm gì “DO-NOTHING” 19

2.5.2 Truyền các ngoại lệ (exception) 20

2.5.3 Xác định các dịch vụ khác 20

2.5.4 Sử dụng sự ủy quyền dịch vụ 22

CHƯƠNG 3: CÔNG NGHỆ CHO LẬP TRÌNH HƯỚNG DỊCH VỤ 22

3.1 Microsoft NET 23

3.2 HP Cooltown 24

3.3 Jini 25

3.4 Openwings 25

CHƯƠNG 4: BÀI TOÁN SỬ DỤNG MÔ HÌNH LẬP TRÌNH HƯỚNG DỊCH VỤ 26

4.1 Giới thiệu bài toán 26

4.2 Giải pháp theo SOP cho bài toán 27

4.3 Lợi ích khi tiếp cận bài toán theo SOP 31

CHƯƠNG 5: KẾT LUẬN 31

Tài liệu tham khảo 32

Bảng 7: Mẫu Service Security 15

Bảng 8: Mẫu Service User Interfaces 15

Bảng 15: Mẫu Proxy 19

Bảng 16: Mẫu Management 19

Bảng 17: NET Component cho SOP 24

Bảng 18: NET Element cho SOP 24

Bảng 19: Các đặc tính SOP trên NET 25

Bảng 20: Các HP Cooltown Element 25

Bảng 21: Các đặc tính của HP Cooltown 25-26 Bảng 22: Các Element của Jini 26

Bảng 23: Các đặc trưng của SOP trong Jini 26

Bảng 24: Các phần tử SOP trong Openwings 27

Bảng 25: Các đặc trưng SOP trong Openwings 27

Danh mục hình

Hình 1: Ví dụ về ADL 11

Hình 2: ADL cho hệ thống MP3 30

Hình 3: Hệ thống MP3 31

Lời giới thiệu

Do nhu cầu phát triển phần mềm con người đã phát triển ra nhiều ngôn ngữ lập trình khác

nhau Từ C cho đến C++ rồi C# và Java Các ngôn ngữ này phát triển dựa trên nhiều mô hình

lập trình khác nhau từ lập trình thủ tục cho đến lập trình hàm và lập trình hướng đối tượng Và

mỗi mô hình lập trình này được sử dụng trong các bài toán đặc thù của nó Tuy nhiên các mô

hình lập trình hiện tại không giúp cho lập trình viên giảm bớt công việc phát triển phần mềm

vì khả năng sử dụng lại rất thấp Với mục đích sử dụng lại càng nhiều càng tốt một mô hình

lập trình mới ra đời dựa trên nền tảng của của lập trình hướng đối tượng đó là lập trình hướng

dịch vụ Nội dung trình bày trong các chương bên dưới sẽ cung cấp cho người đọc có cái nhìn

tổng thể về lập trình hướng dịch vụ – SOP

CHƯƠNG 1: GIỚI THIỆU VỀ LẬP TRÌNH HƯỚNG DỊCH VỤ

Với sự phát triển vượt bậc của công nghệ mạng, con người trở nên gần gủi nhau hơn

thông qua những kết nối rộng lớn Mọi người có thể gửi email hay những tin nhắn tới gia

đình hay chia sẽ dữ liệu qua hệ thống web Trên các trang web, chúng ta có thể sử dụng rất

nhiều dịch vụ như: điện thoại internet miễn phí, phiên dịch văn bản, so sánh giá cả, đấu giá

trực tuyến Các dịch vụ này bản thân nó rất hữu ích, nhưng Internet thì vẫn phát triển không

ngừng; việc kết nối các dịch vụ lại với nhau để tạo ra các dịch vụ mạnh mẽ hơn là một điều

hết sức khó khăn Ví dụ, một dịch vụ có thể tự động gọi điện thoại cho một người nào đó khi

món hàng mà họ muốn mua hay đấu giá thỏa mức giá ban đầu Việc sử dụng các dịch vụ

internet không theo cách làm của người tạo ra là một điều rất khó khăn Nguyên nhân dẫn đến

việc này có thể là các giao tiếp [interface] không được định nghĩa đầy đủ hay thiếu tài liệu

mô tả về các interface Sức mạnh của hệ thống mạng internet được đánh giá một cách đầy đủ

khi ta có thể tích hợp các dịch vụ để tạo ra dịch vụ mới với kiến trúc mạnh mẽ hơn

Để hiểu về lập trình hướng dịch vụ (Service-Oriented Programming), chúng ta cần có kiến

thức về một vài mô hình lập trình ra đời trước nó bao gồm: lập trình hướng đối tượng

(Object-Oriented Programming , OOP), lập trình khách chủ (Client-Server), mô hình các thành phần

(Component Models) Như chúng ta biết, OOP được xây dựng trên những vấn đề lập trình có

thể được mô hình hóa bằng những khái niệm của đối tượng Lập trình hướng đối tượng có

một vài đặc trưng của nó như: thừa kế (inheritance), bao đóng (encapsulation) và đa xạ

(polymorphism), trừu tượng (abstraction) Còn lập trình hướng dịch vụ (Service-Oriented

Programming) được xây dựng dựa trên OOP, thêm vào đó những tiền đề giúp cho chúng ta

có thể mô hình hóa các bài toán bằng những khái niệm của dịch vụ (Services) cái mà được

cung cấp và sử dụng bởi các đối tượng

Sau đây chúng ta sẽ tìm hiểu về khái niệm dịch vụ:

Dịch vụ (Service) là một hành vi (behavior) mang tính hợp đồng đã được định nghĩa trước

Các hành vi này có thể được hiện thực bởi bất kì thành phần (component) nào, nó cũng có thể

được cung cấp bởi thành phần nào, dựa trên một hợp đồng duy nhất Dịch vụ này có thể sử

dụng bởi dịch vụ khác.

Mô hình thành phần (component models) qui định rằng những bài toán về lập trình có thể

được xem như những hộp đen, chúng được triển khai một cách độc lập và giao tiếp với nhau

thông qua những hơp đồng

Mô hình client-server truyền thống không không định nghĩa trước những hợp đồng

công cộng (public contract) giữa client và server Việc hiện thực của client và server cũng

không thể độc lập nhau Một client chỉ có thể kết nối hay giao tiếp với một client duy nhất

Trong mô hình SOP thì có sự khác biệt, một client không bị bó buột với bất kì server nào

Thay vào đó, vai trò người cung cấp dịch vụ có thể thay đổi qua lại giữa client và server

CHƯƠNG 2: CÁC PHẦN TỬ VÀ ĐẶC TRƯNG CỦA LẬP

TRÌNH HƯỚNG DỊCH VỤ

2.1 Các phần tử (element) của lập trình hướng dịch vụ

Hợp đồng (Contract): là một giao diện (interface) định nghĩa cú pháp và ngữ nghĩa của một

hành vi (behavior) đơn lẽ

Thành phần (Component): là các phần tử tính toán có khả năng triển khai, có khả năng sử

dụng lại do tính độc lập của nó với các platform, giao thức (protocol), và môi trường triển

khai

Bộ nối hay đầu nối (Connector): là một bản đóng gói cho phần chi tiết về phương thức vận tải

(transport) đặc thù của một contract cụ thễ nào đó Đây cũng là một phần tử có khả năng triển

khai được

Bộ chứa (Container): là môi trường cho việc thực thi các component Nó chịu trách nhiệm

quản lí tính sẵn sàng (availability) và bảo mật

Ngữ cảnh (Context): là môi trường cho việc triển khai các thành phần (bao gồm plug và play).

Nó mô tả chi tiết việc cài đặt, bảo mật, khám phá và tìm kiếm

2.2 Các đặc trưng của SOP

Tính liên kết (conjunctive): Điều này nói đến khả năng sử dụng hoặc kết hợp các dịch vụ theo

những cách khác với các cách thức đã tạo ra chúng Nó hàm ý rằng những dịch vụ đó đã tạo

ra những interface cái mà chúng ta có thể dễ dàng nhận ra

Khả năng triễn khai (deployable): Điều này nói đến khả năng triển khai hoặc sử dụng lại các

thành phần trong bất kì môi trường nào Điều này đòi hỏi sự độc lập về môi trường bao gồm

sự độc lập về vận tải (transport), sự độc lập về nền tảng (platform) và sự độc lập về ngữ cảnh

Tính lưu động (mobile): Điều này nói đến khả năng di chuyển mã xung quanh mạng Nó được

sử dụng để di chuyển các proxy, giao diện người dùng và các dịch vụ di động

Tính sẵn sàng (available): Là một trong những tiền đề quan trọng của lập trình hướng dịch vụ

nghĩa là những mạng lưới nguồn tài nguyên dư thừa sẽ đảm bảo sự sẵn sàng cao cho SOP

Đây cũng là mục tiêu của SOP để xử lí các lỗi xảy ra trong tính toán phân bố

Sự bảo mật – Security: Những khái niệm của mã di động và những mạng lưới dịch vụ có khả

năng khám phá đã đưa đến những thách thức về mặt bảo mật Trong khi SOP cho phép giới

hạn sử dụng các dịch vụ rộng hơn, nó không thể thành công nếu thiếu việc bảo vệ các dịch vụ

trước việc sự dụng không đúng đắn

2.3 Ngôn ngữ mô tả kiến trúc – ADL

Chỉ giống như lập trình hướng đối tượng có ngôn ngữ mô hình riêng đó chính là UML,

lập trình hướng dịch vụ cũng định nghĩa ra một ngôn ngữ cho việc hô hình hóa dựa trên ngôn

ngữ mô tả cấu trúc (architecture description language) ADL bao gồm các khái niệm về các

thành phần (components), các đầu nối (connectors), các vai trò (roles), và các cổng (ports)

ADL là một kí hiệu chuẩn cho việc biểu diễn các kiến trúc giúp nâng cấp việc giao

tiếp, hình mẫu cho các thiết kế ban đầu, cho việc tạo ra sự trừu tượng cho các hệ thống có thể

chuyển nhượng, trong quá khứ việc sử dụng các hình vẽ như các hình hộp các đường để biểu

diễn các thành phần, các thuộc tính, ngữ nghĩa của các kết nối, hành vi của toàn bộ hệ thống

ADL là kết quả của việc các tiếp cận mang tính ngôn ngữ cho việc biểu diễn chính thức kiến

trúc của hệ thống ADL tập trung vào việc biểu diễn các thành phần của hệ thống

Các điểm mạnh và điểm yếu của ADL

 ADL là một công cụ chính thức cho việc biểu diễn hệ thống

 Con người và máy đều có khả năng đọc được ADL

 ADL hỗ trợ việc mô tả hệ thống ở cấp độ cao hôn trước đây

 ADL cho phép phân tích các kiến trúc – bao gồm sự đầy đủ, nhất quán, nhập nhằng,

hiệu năng

 ADL hỗ trợ việc tạo tự động các hệ thống phần mềm

 Không có thỏa thuận chung cho việc ADL nên biểu diễn gì, đặc biệt là các hành vi của

các bản kiến trúc

 Cách biểu diễn hiện tại đang được sử dụng thật sự rất khó để phân tích cú pháp, và

không có công cụ thương mại nào hỗ trợ việc phân tích này

 Đa số các ADL đều được tối ưu theo chiều dọc một dạng đặc biệt của phân tích

Sau đây là một ví dụ về ADL

Hình 1: ví dụ về ADL

2.4 Các mẫu hỗ trợ cho SOP

Một phần quan trọng của SOP là việc định nghĩa và sử dụng các mẫu Đa số các mẫu

áp dụng cho lập trình hướng dịch vụ đều thừa kế từ các mẫu của JAVA, Jini, và Openwings

Sau đây là các mẫu áp dụng cho SOP:

2.4.1 Mẫu Java

Jini phát triển hầu hết sức mạnh của nó từ JAVA, vì vậy, những mẫu liên quan tới

JAVA được trình bày dưới đây Để tiết kiệm thời gian, đối với các mẫu chúng ta chỉ phân tích

trên các khía cạnh chính sau:

Tên mẫu: Các hợp đồng (contracts)

Bài toán: Làm thế nào các hành vi (behaviors) có thể định nghĩa độc lập với

hiện thực (implementation)

Ngữ cảnh (context): Bất cứ nơi nào cần che dấu độ phức tạp

Giải pháp (solution): Khái niệm về một ý tưởng giao diện đã được bổ sung

vào Java để mô tả một hành vi cả trong cú pháp và ngữ nghĩa Các phương

thức (method), các kiểu phương thức, các kiểu tham số của phương thức, và

kiểu của các trường (fields) qui định cú pháp của các giao diện (interface)

Các chú thích (comments), tên phương thức, và tên trường mô tả ngữ nghĩa

của giao diện Trong mô hình này bất kì đối tượng (object) có thể hiện thực

giao diện và các giao diện có thể sử dụng tính thừa kế bao gồm cả đa thừa

kế

Bảng 1: Mẫu Contracts

Tên mẫu: Tính di động (mobility)

Bài toán: Làm thế nào để có thể di chuyển các mã thực thi thông qua hệ

thống mạng?

Ngữ cảnh (context): Việc chuyển mã có thể có lợi hơn so với việc di chuyển

dữ liệu cho việc bảo mật, hiệu suất và khả năng tương tác

Giải pháp (solution): Bằng cách làm cho mã trở nên khả chuyển, nó có thể

được di chuyển một cách dễ dàng từ máy này sang máy khác Java hỗ trợ cà

khả năng di động cho mã và khả năng di động cho các trạng thái Khả năng

di động của các trạng thái được cung cấp thông qua tuần tự hóa

(serialization) Khã năng di động của mã được cung cấp thông qua mã độc

lập với nền tảng, nó được JAVA đưa ra trong những gói được gọi là JAR

Chúng ta có thể sử dụng JAR với bất kì hình thức chuyển file nào

Bảng 2: Mẫu Mobility

Tên mẫu: Bảo mật mã (Code security)

Bài toán: Khi tải dữ liệu và chạy mã từ nhiều nguồn, làm thế nào nó có thể

được đảm bảo phần mềm sẽ không làm tổn hại đến hệ thống đích?

Ngữ cảnh (context): Bất cứ nơi nào mã di động được cung cấp từ nhiều

nguồn với độ tin cậy khác nhau

Giải pháp (solution): Java cung cấp một hôp cát (sandbox) bảo mật, chứng

thực dựa trên quyền truy cập và việc gán các quyền riêng lẻ

 Giải pháp mà mẫu sử dụng để giải quyết bài toán

Mục đích của phần này là đưa ra mô tả cho các mẫu được phát sinh từ công nghệ Jini

cua Java Jini khắc phục những vấn đề mà tính toán phân tán đang phải đối đầu, không giống

như nhiều mô hình tính toán phân tán trước đây Ví dụ, tính toán phân tán tồn tại hàng loạt

các vấn đề như: hư hỏng từng phần (partial failure), tính cục bộ của việc thực thi, giao diện

không đối xứng Hư hỏng từng phần có thể xảy ra khi các phần tử như các hệ thống mạng, hư

hỏng giữa các nút Tính cục bộ của việc thực thi nói đến những câu hỏi của việc gọi bằng

tham chiếu đối với việc gọi bằng tham trị Trong tính toán phân tán, điều này trở thành sự so

sánh giữa việc triệu gọi từ xa với tuần tự hóa các đối tượng (object serialization) Những vấn

đề về khả năng công tác xảy ra khi các phần tử được triển khai tại nhiều thời điểm khác nhau

có những giao diện không tương thích Thông qua việc sử dụng của mã di động,Jini loại bỏ

những vấn đề cộng tác này Trong phần này chúng ta sẽ mô tả những mẫu sau đây: cho thuê

(lease), khám phá (discovery), tìm kiếm, bảo mật các dịch vụ, và dịch vụ giao diện người

dùng

Tên mẫu: Cho Thuê (Lease)

Bài toán: Làm thế nào các hư hỏng tài nguyên có thể được tìm thấy?

Ngữ cảnh (context): Trong một môi trường phân tán nào đó, nơi mà các hư

hỏng từng phần có thể xảy ra ví dụ như các mạng ngừng hoạt động chẳng

hạn

Giải pháp (solution): Cả hai bên đồng ý việc cho thuê tài nguyên trong một

một khoảng thời gian Việc hết hạn cho thuê được nhận biết được cả hai bên,

bất chấp việc máy tính hay mạng bị hư hỏng, vì thế các hư hỏng từng phần

đảm bảo được tìm thấy một cách đúng đắn bởi các bên

Bảng 4: Mẫu Lease

Tên mẫu: Sự phát hiện (discovery)

Bài toán: Làm thế nào phần cứng và phần mềm có thể đạt được mục tiêu

“cắm vào là chạy”, tức là theo kiểu plug và play?

Ngữ cảnh (context): Trong bất kì hệ thống nào cần giảm thiểu công việc

quản trị và tính dễ sử dụng của hệ thống được cho là quan trọng

Giải pháp (solution): Một giao thức bootstrapping được sử dụng để tìm kiếm

các dịch vụ một cách tự động Khi dịch vụ được tìm thấy, mọi thứ khác có

thể được tìm thấy một cách dễ dàng Chừng nào mà kĩ thuật bootstrapping

vẫn còn thì phần mềm tương tự có thể tham gia vào trong một plug và vận

hành môi trường

Bảng 5: Mẫu Discovery

Tên mẫu: Tìm kiếm (lookup)

Bài toán: Làm thế nào để các dịch vụ có thể được xuất bản (publish) và phát

hiện dựa vào các hợp đồng và thuộc tính của chúng?

Ngữ cảnh (context): Được sử dụng ở nơi mà việc xuất bản các dịch vụ cho

mục đích dùng chung

Giải pháp (solution): Cho phép việc xuất bản và tìm kiếm các dịch vụ dựa

trên các hợp đồng và thuộc tính của chúng Không giống với mô hình đường

ống (pipe) trong client-server, các giao diện dịch vụ được xuất bản và có thể

sử dụng bởi bất kì thành phần nào

Bảng 6: Mẫu Look up

Tên mẫu: Bảo mật dịch vụ (Service security)

Bài toán: Làm thế nào để có thể bảo mật các dịch vụ nhằm ngăn chặn những

truy xuất trái phép?

Ngữ cảnh (context): Bất cứ nơi đâu các dịch vụ được xuất bản

Giải pháp (solution): Việc bảo mật các truy cập tới các dịch vụ tìm kiếm của

Jini và tới chính các dịch vụ đã được xuất bản là một công việc đang tiến

triển

Bảng 7: Mẫu Service Security

Tên mẫu: Giao diện người dùng dịch vụ (Service User Interface)

Bài toán: Làm thế nào để các giao diện người dùng có thể gắn liền với các

dịch vụ?

Ngữ cảnh (context): Bất cứ khi nào có một giao diện người dùng kiểu đồ họa,

âm thanh hay một dạng nào khác cần được cung cấp bởi một dịch vụ nào đó

Giải pháp (solution): Jini sử dụng khái niệm của một giao diện dịch vụ

(ServiceUI), ServiceUI có thể gắn với bất kỳ dịch vụ nào Các factory được

định nghĩa cho mỗi loại giao diện người dùng (giọng nói, đồ họa, ) Những

factory được sử dụng để lấy các mã di động, các mã di động này đảm nhận

việc cung cấp giao diện người dùng Điều này sẽ tạo ra thuận lợi cho các phần

mềm client và server bởi vì chúng luôn được đồng bô hóa

Bảng 8: Mẫu Service User Interfaces

2.4.1 Mẫu Openwings

Jini và Java cung cấp những tính năng giúp chúng ta có thể phát huy sức mạnh của

SOP Tuy nhiên, một vài phần tử đã bị bỏ qua, điều đó sẽ cho phép sự phát triển của các hệ

thống hướng dịch vụ qui mô lớn Openwings tập trung vào việc khắc phục các lỗ hỏng và

cung cấp cho chúng ta một tập đầy đủ các phần tử và các khía cạnh bên trong của SOP Trong

phần này những mẫu sau đây sẽ được trình bày: thành phần (component), bộ nối (connector),

bộ chứa (container), ngữ cảnh (context), bộ cài đặt (installer), chính sách (policy), proxy

Tên mẫu: Thành phần (component)

Bài toán: Thành phần nhỏ nhất (đơn vị) của việc triển khai dịch vụ là gi?

Ngữ cảnh (context): Bất kì hệ thống nào bao gồm các thiết bị phần cứng và

phần mềm cần trừu tượng hóa thành các dịch vụ

Giải pháp (solution): Một thành sẽ đóng gói từng đơn vị triển khai của phần

cứng hay phần mềm Các thành phần chính là đơn vị triển khai cơ bản cho

các dịch vụ (một thành phần có thể cung cấp hay sử dụng nhiều dịch vụ)

Các dịch vụ là các hợp đồng cụ thể, được cung cấp và sử dụng bởi các thành

phần Xét trong ngữ cảnh của việc triển khai thì các thành phần là các đơn vị

hoàn toàn độc lập Ngoài ra các thành phần cũng phải là các đơn vị độc lập

của các nền tảng (platform), giao thức vận tải (transport protocol), và chi tiết

về môi trường triển khai chẳng hạn như mô hình mạng

Bảng 9: Mẫu Components

Tên mẫu: Bộ nối (connector)

Bài toán: Làm thế nào để các thành phần có giao thức vận tải khác nhau có

thể phối hợp và cộng tác với nhau?

Ngữ cảnh (context): Bất kì nơi nào khả năng cộng tác và hiệu quả sử dụng

băng thông được cho là quan trọng

Giải pháp (solution): Các bộ nối cung cấp một sự trừu tượng hóa cho tính

độc lập về vận tải Các bộ nối được phân thành hai loại đồng bộ và bất đồng

bộ Các bộ nối bao gồm một proxy người dùng và một proxy người cung

cấp Một proxy người dùng cung cấp một đối tượng, nó sẽ hiện thực một hợp

đồng còn proxy người cung cấp nắm giữ đối tượng này Các bộ nối có thể

gắn lại với nhau thành một chuỗi một cách tự nhiên Chúng cũng cung cấp

những chổ chèn vào cho việc bảo mật vận tải và chất lượng của dịch vụ Các

bộ nối có thể được bọc lại trong các thành phần

Bảng 10: Mẫu Connectors

Tên mẫu: Bộ chứa (Container)

Bài toán: Làm thế nào để quản lí tính bảo mật, tính sẵn sàng, tính di động

của việc thực thi các thành phần?

Ngữ cảnh (context): Mẫu này được sử dụng khi các dịch vụ được triển khai

như những component

Giải pháp (solution): Một máy chủ ứng dụng (application server) là một ví

dụ của bộ chứa Một bộ chứa của Java sẽ thực thi việc bảo mật mã bằng cách

cấu hình cho Java Security Manager Bô chứa này có khả năng khắc phục

những thiếu xót của Java, đó là khả năng ánh xạ nhiều tiến trình với một

máy ảo Java (Java Virtual Machine – JVM) Điều này giúprút ngắn thời gian

khởi động các chương trình Java Mẫu này có thể quản lí các bô quét của

Java và đưa ra các quyết định cân bằng tải Các bô chứa có thể kết hợp với

nhau để tạo thành các cụm, chúng đảm bảo các dịch vụ đã được gom cụm có

thể duy trì hoạt động Các bô chứa còn cung cấp một môi trường để hỗ trợ

cho các dịch vụ di động

Bảng 11: Mẫu Container

Tên mẫu: Ngữ cảnh (Context)

Bài toán: Làm thế nào để tạo ra và quản lí một ngữ cảnh về sự hình thành hệ

thống và việc phát hiện các dịch vụ?

Ngữ cảnh (context): Mẫu này hữu ích trong môi trường tính toán phân bố

Trong môi trường này các hệ thống cần phải tự hình thành và tự hồi phục

Giải pháp (solution): Một ngữ cảnh cung cấp một môi trường cho việc tự

hình thành và tự phục hồi của hệ thống Một ngữ cảnh sẽ thực thi một ranh

giới hệ thống, cung cấp cho việc cài đặt tự động các thành phần (xem các mô

hình trình cài đặt- installer pattern), cung cấp

dịch vụ lõi cho sự hình thành hệ thống, và quy định cách thưc để xuất bản

các dịch vụ và phát hiện chúng ra ngoài nhóm làm việc (workgroup) Mẫu

ngữ cảnh dựa trên thành phần có tính độc lập về môi trường (xem mẫu chiến

lược - Policy)

Bảng 12: Mẫu Context

Tên mẫu: Trình cài đặt (Installer)

Bài toán: Làm thế nào để cài đặt các phần mềm một cách an toàn và tư động

Ngữ cảnh (context): Mẫu này hữu ích cho các hệ thống có sử dụng mẫu ngữ

cảnh

Giải pháp (solution): Mẫu “trình cài đặt” đã đảo ngược cách tiếp cận cài đặt

truyền thống Thông thường phần mềm được cung cấp kèm với trình cài đặt

riêng của nó Bởi vì trình cài đặt được đóng gói không có kiền thức về ngữ

cảnh triển khai, người dùng phải trả lời nhiều câu hỏi về nơi và cách thức cài

đặt phần mềm Trong môi trường hướng dịch vụ mã di động rất phổ biến,

nhưng điều này lại khó chấp nhận Thay vào đó, các thành phần được phân

phối cùng như các gói cùng với một ngữ cảnh của việc chạy một trình cài đặt

Dịch vụ chuẩn bị cài đặt có thể xác nhận xem các thành phần có nên được cài

đặt hay không (bằng chữ kí)

Bảng 13: Mẫu Installer

Tên mẫu: Điều khoản (Policy)

Bài toán: Làm thế nào để trừu tượng hóa các chi tiết của môi trường từ mã

(code)

Ngữ cảnh (context): Một điều khoản sẽ hữu ích bất cứ nơi nào đã sử dụng

một file cấu hình trước đó

Giải pháp (solution): Các chính sách hay điều khoản là các file cấu hình có

thể được tìm thấy Ví dụ, mẫu ngữ cảnh sử dụng các plolicy để mô tả cho các

thành phần đã triển khai thông tin về môi trường triển khai của chúng Các

điều khoản bao gồm cả hai dạng: dạng có thể đọc được và dạng các đối

tượng Một đối tượng kiểu “điều khoản” tự bản thân chúng có thể biết được