ĐẠI HỌC QUỐC GIA HÀ NỘI
VIỆN CÔNG NGHỆ THÔNG TIN
o0o
BÁO CÁO
Môn: Kiến trúc hướng dịch vụ (SOA)
Đề tài:
SOA DESIGN PATTERNS
Giảng viên: TS. Võ Đình Hiếu
Nhóm thực hiện:
Vũ Đoàn
Đoàn Hữu Hậu
Nguyễn Thị Lan Anh
Lê Văn Khanh
Ngô Doãn Lập
Lớp: Quản lý hệ thống thông tin K2
SOA DESIGN PATTERNS QLHTTT K2
Hà Nội, tháng 04/2011
2
SOA DESIGN PATTERNS QLHTTT K2
MỤC LỤC
PHẦN I. TỔNG QUAN 4
I. Giới thiệu chung 4
II. Phân chia công việc 4
PHẦN II. SERVICE DESIGN PATTERNS 7
I. Foundational Service Patterns 7
1. Service Identification Patterns 7
1.1 Functional Decomposition - Phân tích chức năng 7
1.2 Service Encapsulation 9
2. Service Definition Pattern 12
II. Service Implementation Patterns 18
1. Service Façade 18

2. Redundant Implementation 20
III. Service Security Patterns 21
1. Exception Shielding 21
2. Message screening 23
TÀI LIỆU THAM KHẢO 25
3
SOA DESIGN PATTERNS QLHTTT K2
PHẦN I. TỔNG QUAN
I. Giới thiệu chung
Trong công nghệ phần mềm(software engineering) nói chung, design pattern là giải pháp
tổng quát có thể dùng lại cho các vấn đề phổ biến trong thiết kế phần mềm. Design
pattern không phải là design cuối cùng có thể dùng để chuyển thành code. Nó chỉ là các
gợi ý, mẫu mà chỉ ra cách giải quyết vấn đề trong các trường hợp. Các design pattern
trong thiết kế hướng đối tượng thường chỉ ra mối quan hệ và tương tác giữa các lớp hay
các đối tượng, chứ không chỉ ra các lớp, đối tượng cụ thể nào. Thuật toán không phải
design patterns vì chúng chỉ qiải quyết các vấn đề tính toán chứ không giải quyết các vấn
đề thiết kế.
Design pattern giúp tăng tốc độ phát triển phần mềm bằng cách đưa ra các mô hình test,
mô hình phát triển đã qua kiểm nghiệm. Thiết kế phần mềm hiệu quả đòi hỏi phải cân
nhắc các vấn đề sẽ nảy sinh trong quá trình hiện thực hóa (implementation). Dùng lại các
design pattern giúp tránh được các vấn đề tiềm ẩn có thể gây ra những lỗi lớn, đồng thời
giúp code dễ đọc hơn. Thông thường, chúng ta chỉ biết áp dụng một kĩ thuật thiết kế nhất
định để giải quyết một bài toán nhất định. Các kĩ thuật này rất khó áp dụng với các vấn
đề trong phạm vi rộng hơn. Design pattern cung cấp giải pháp ở dạng tổng quát.
Xem xét trên quan điểm xây dựng hệ thống phần mềm, kiến trúc hướng dịch vụ (SOA )
cũng có những mẫu thiết kế riêng của nó đã được kiểm chứng. Do vậy việc xem xét và
tìm hiểu các mẫu thiết kế trong kiến trúc hướng dịch vụ sẽ giúp cho quá trình thiết kế
được đảm bảo hơn, ít lỗi hơn Các vấn đề được giải quyết nhanh hơn, đôi khi có thể là
trọn vẹn hơn.
Với mục đích có cái nhìn tổng quan về các mẫu thiết kế trong kiến trúc hướng dịch vụ.

Nhóm chúng em nhận đề tài tìm hiểu các mẫu thiết kế trong SOA thông qua việc tìm hiểu
nội dung cuốn sách SOA design pattern của tác giả Thomas Erl.
II. Phân chia công việc
Trong kiến trúc hướng dịch vụ, đơn vị cơ bản nhất là dịch vụ (services). Một số services
có liên hệ với nhau cho một quy trình nghiệp vụ nào đó được gộp lại thành một dịch vụ
ghép (service composition). Tập hợp các dịch vụ ghép cho một lĩnh vực kinh doanh nào
đó được gộp lại thành một kho dịch vụ (service inventory). Hình dưới đây mô tả quan hệ
giữa chúng
4
SOA DESIGN PATTERNS QLHTTT K2
Các vấn đề về thiết kế trong SOA sẽ được trình bày theo luồng mạch từ các vấn đề liên
quan đến thiết kế dịch vụ (Service design pattern), thiết kế các dịch vụ ghép (Service
composition design pattern) đến thiết kế các kho dịch vụ (Service Inventory design
pattern). Hình dưới đây sẽ cho chúng ta có cái nhìn tổng quan về mô hình dịch vụ trong
SOA
Với nội dung công việc như vậy, nhóm phân chia công việc như sau
5
SOA DESIGN PATTERNS QLHTTT K2
Các nội dung tổng quan, nhóm đã trình bày trong buổi báo cáo kết quả tìm hiểu. Phần
tiếp theo của tài liệu này chỉ tổng hợp và trình bày cụ thể các vấn đề liên quan đến thiết
kế các dịch vụ. Đây là phần cơ sở nhất, nền tảng cho việc xây dựng kiến trúc hướng dịch
vụ.
6
SOA DESIGN PATTERNS QLHTTT K2
PHẦN II. SERVICE DESIGN PATTERNS
I. Foundational Service Patterns
Các pattern đưa ra trong phần này đại diện cho các bước đầu tiên cần thiết để phân
vùng, tổ chức giải pháp logic vào các dịch vụ hỗ trợ các pattern sau đó. Các pattern trong
phần này có thể được xem là nền tảng xây dựng nguyên lý định hướng dịch vụ.
1. Service Identification Patterns

Pattern (mẫu) định danh dịch vụ (hình 1) về bản chất thực hiện phân tách các vấn
đề (mối quan tâm) nghiệp vụ để hỗ trợ thiết kế kiến trúc định hướng dịch vụ.
Service Identification Pattern gồm hai loại: Functional Decomposition và Service
Encapsulation.
Hình 1. Hai mẫu trong trong Service Identification Pattern sẽ được áp dụng cho quá trình
phân tách các vấn đề (mối quan tâm) nghiệp vụ.
1.1Functional Decomposition - Phân tích chức năng
1.1.1. Vấn đề:
Để giải quyết một vấn để nghiệp vụ lớn, phức tạp – một khối giải pháp logic tương
ứng được đưa ra, điều này tạo ra một ứng dụng khép kín độc lập với các ràng buộc về
khả năng tái sử dụng và quản trị truyền thống.
7
SOA DESIGN PATTERNS QLHTTT K2
Hình 2. Một cách tiếp cận để giải quyết vấn đề lớn là xây dựng một khối giải pháp logic
tương ứng.
1.1.2. Giải pháp:
Functional Decomposition về bản chất như một ứng dụng dùng để phân tích các
vấn đề đưa ra ban đầu. Nguyên tắc của Functional Decomposition là phân tích các vấn đề
lớn thành các vấn đề nhỏ hơn (gọi là các mối quan tâm), trên cơ sở đó ta xây dựng các
đơn vị giải pháp logic tương ứng với các vấn đề nhỏ đã phân tách.
Hình 3. Thể hiện phương pháp tiếp cận chia vấn đề lớn thành các vấn đề nhỏ , giải pháp
logic tương ứng cũng được phân chia thành các đơn vị giải pháp logic riêng lẻ ứng với
từng vấn đề nhỏ
1.1.3. Ứng dụng:
Tùy theo tính chất, mức độ của vấn đề, một quy trình phân tích hướng dịch vụ có
thể được tạo ra để xây dựng các vấn đề nhỏ hơn.
Pattern Function Decomposition chỉ thực hiện phân tách các vấn đề lớn thành các
vấn đề nhỏ. Nó là một cách thức quan trọng để phân biệt định hướng dịch vụ với các
phương pháp thiết kế phân tách khác, Function Decomposition thực hiện phân tách sao
cho dựa trên kết quả phân tách ta sẽ xác định được cách thức định nghĩa các đơn vị giải

pháp logic tương ứng.
Pattern Function Decomposition không áp dụng riêng lẻ, nó là điểm bắt đầu cho
một quy trình: thực hiện phân tách các chức năng, dựa vào thể hiện cụ thể của từng chức
năng áp dụng các pattern tiếp theo để phân chia các đơn vị logic tương ứng.
1.1.4. Ảnh hưởng:
Việc quản lý nhiều chương trình nhỏ có thể dẫn đến độ phức tạp trong thiết kế
tăng lên và khó khăn trong việc quản lý (quản trị).
8
SOA DESIGN PATTERNS QLHTTT K2
Khi phân phối các đơn vị giải pháp loggic cần quan tâm tới tính kết nối, độ tin
cậy, bảo mật và bảo trì để đảm bảo chắc chắn rằng mỗi một đơn vị giải pháp trong chuỗi
liên kết quy trình hoạt động khi chạy đảm bảo tính ổn định và độc lập.
Hơn nữa, hiệu quả của việc ứng dụng pattern này phụ thuộc vào chất lượng định
nghĩa (cách đưa ra vấn đề). Đối với một quy trình nghiệp vụ (xem như một vấn đề lớn)
để phân chia được chính xác và phù hợp, nó cần được được ghi chép một cách chi tiết và
chính xác để trong quá trình phân tích có đủ cơ sở. Nếu việc định nghĩa quy trình nghiệp
vụ không tốt dẫn đến việc phân chia và tách các vấn đề không hiệu quả sẽ kéo theo việc
định nghĩa các dịch vụ sau này không hiệu quả.
1.1.5. Ví dụ:
Mối quan tâm sau phân tách Đơn vị giải pháp logic tương ứng
Từ yêu cầu đối với quy trình vận chuyển
hàng hóa theo dây chuyền, được phân tách
thành các vấn đề quan tâm tương ứng như
sau:
Với mỗi một vấn đề quan tâm, tương ứng
với một giải pháp được định nghĩa:
Quan tâm 1 - Làm thế nào để chất lượng
dầy chuyền được đảm bảo?
Giải pháp 1 – dây chuyền được kiểm tra
bằng tay.

Quan tâm 2 - Làm thế nào có thể ghi lại
tóm tắt thông tin hàng hóa trong dây
chuyền.
Giải pháp 2 – dây chuyền được ghi lại tự
động như là một phần của hệ thống kiểm
soát hàng hóa.
Quan tâm 3 - Làm thế nào dây chuyền có
thể tham chiếu tới bất kỳ một đơn đặt hàng
lại tương ứng?.
Giải pháp 3 - Sau khi ghi lại thông tin
hàng hóa, hệ thống sẽ thực hiện một kiểm
tra chéo cho các đơn đặt hàng lại, tiêu chí
tìm kiếm đưa ra ở đây là số hiệu hàng hóa.
Quan tâm 4 - Làm thế nào để dây chuyền
có thể xác định được đâu là đơn đặt hàng
lại?
Giải pháp 4 – đơn đặt hàng lại tiếp theo
trong hàng đợi được lấy ra từ hệ thống
quản lý đơn hàng (hồ sơ về hàng hóa) và
đánh dấu xác nhận.
Mối quan tâm 5 - Làm thế nào để dây
chuyền phân phối được các đơn đặt hàng
lại?
Giải pháp 5 - chuỗi này được vận chuyển
bằng tay.
1.2Service Encapsulation
1.2.1 Vấn đề:
Giải pháp logic được thiết kế cho một môi trường ứng dụng đơn lẻ thường rất hạn
chế khả năng tương tác và kết hợp với các phần khác của doanh nghiệp.
Quá trình phân tách khối giải pháp logic có thể diễn ra nhưng việc phân tách này

vẫn giới hạn bên trong ứng dụng khép kín. Trong thực tế, rất nhiều hệ thống phân tán
trước đây đã được xây dựng theo cách này. Việc quyết định phân chia giải pháp logic ra
thành các đơn vị giải pháp nhỏ hơn đem lại những lợi ích:
9
SOA DESIGN PATTERNS QLHTTT K2
- Tăng khả năng mở rộng (sau phát triển hệ thống k cần thay đổi nhiều): bằng cách
tách các phần của hệ thống thành nhiều phần nhỏ.
- Cải thiện khả năng bảo mật, các phần cụ thể riêng biệt của hệ thống sẽ được gắn
quyền truy cập riêng và đưa ra các yêu cầu bảo đảm tính bảo mật
- Tăng độ tin cậy, các phần của hệ thống sau khi phân tách sẽ được đặt tại các máy
chủ khác nhau không tập trung tại một máy.
- Tăng khả năng tái sử dụng các phần trong phạm vi của hệ thống (hoặc trong giới
hạn của doanh nghiệp đưa ra).
Hình 4. Một doanh nghiệp thực hiện việc phân tách các giải pháp nhưng trong giới hạn
của tổ chức.
Khi một doanh nghiệp bưng bít việc phân tách các giải pháp (như hình 4), nó có
thể gặp phải thách thức trong việc quản trị và thiết kế, như:
- Lãng phí và dư thừa không cần thiết
- Cung cấp ứng dụng không hiệu quả
- Môi trường kỹ thuật (phần cứng, hệ điều hành ) tốn kém
- Kiến trúc doanh nghiệp và cơ sở hạ tầng phức tạp, tốn kém
- Chi phí hoạt động, duy trì tốn kém
1.2.2 Giải pháp:
Giải pháp logic sau khi được phân tách phù hợp có thể xem như một tài nguyên
của doanh nghiệp, được đóng gói và thể hiện như một dịch vụ. Điều này có nghĩa là bản
thân của giải pháp logic có thể dùng làm nền tảng cho một dịch vụ mới , hoặc nó có thể
được đóng gói bởi các dịch vụ đã tồn tại khác. Điều này tạo ra một môi trường mà ở đó
các dịch vụ chia sẻ được cho nhau (hình 5).
10
SOA DESIGN PATTERNS QLHTTT K2

Hình 5. Một doanh nghiệp trong đó các giải pháp logic riêng lẻ sử dụng các giải pháp
logic đã đóng gói như các dịch vụ.
1.2.3 Ứng dụng:
Giải pháp logic phù hợp để đóng gói dịch vụ cần được xác định cụ thể. Không
phải tất cả các giải pháp logic đều được coi là nguồn tài nguyên của doanh nghiệp. Việc
xác định giải pháp logic nào được xem như một nguồn tài nguyên của doanh nghiệp căn
cứ theo các tiêu chí hướng dẫn sau:
- Giải pháp logic có chứa chức năng hữu ích đối với các phần bên ngoài giới hạn
ứng dụng của doanh nghiệp. Đây là giải pháp logic thông thường tạo cơ sở cho
dịch vụ trung lập (agnostic service).
- Giải pháp logic được thiết kế để thúc đẩy các nguồn tài nguyên của doanh nghiệp.
Giải pháp logic này được xây dựng sau khi các giải pháp trung lập ban đầu được
phân tách. Nó thống nhất với các dịch vụ trung lập. Giải pháp này thường tạo cở
sở cho dịch vụ (Non-Agnostic service )
- Việc thực thi giải pháp logic có bị ràng buộc cứng không. Với những giải pháp
logic ràng buộc cứng sẽ không được xem như tài nguyên của doanh nghiệp. Bất kể
bản chất của giải pháp logic thể hiện giống như tài nguyên của doanh nghiệp,
nhưng có những giới hạn, ràng buộc trong sẽ làm việc đóng gói hạn chế không
hiệu quả.
Áp dụng các tiêu chí ở trên để xác định các giải pháp logic phù hợp để đóng gói,
các giải pháp logic không phù hợp sẽ được lọc ra (hình 6)
Hình 6. Tập hợp các giải pháp logic tương ứng với các vấn đề nhỏ (thể hiện các hình
khối), những hình khối được tô đậm là những giải pháp logic được lọc ra để đóng gói.
Kiến thức quan trọng trong thiết kế kiến trúc hướng dịch vụ đó là xác định được
đúng giải pháp logic nào thích hợp để đóng gói dịch vụ. Nếu như các nguyên tắc thiết kế
ban đầu trong thiết kế hướng dịch vụ không được áp dụng chuẩn, việc đóng gói các giải
pháp logic sẽ khó khăn.
11
SOA DESIGN PATTERNS QLHTTT K2
Việc ứng dụng Pattern này chỉ để xác định và lọc ra các giải pháp logic (sẽ áp

dụng trong Pattern service definition ở bước sau). Các giải pháp logic được xem là phù
hợp cho đóng gói dịch vụ sẽ được đưa ra để ứng dụng tiếp sau đó.
1.2.4 Ảnh hưởng:
Việc đóng gói giải pháp logic như một dịch vụ cần xem xét về các chính sách
quản trị và thiết kế bổ sung thêm vào
1.2.5 Ví dụ:
Đơn vị giải pháp logic Tính phù hơp để đóng gói
Giải pháp 1 – dây chuyền được kiểm tra
bằng tay.
Không phù hợp, bởi giài pháp này là các
bước thực hiện bằng tay.
Giải pháp 2 – dây chuyền được ghi lại tự
động như là một phần của hệ thống kiểm
soát hàng hóa.
Phù hợp, vì các giải pháp này thực hiện tự
động,hữu ích cho doanh nghiệp, không bị
giới hạn .
Giải pháp 3 - Sau khi ghi lại thông tin
hàng hóa, hệ thống sẽ thực hiện một kiểm
tra chéo cho các đơn đặt hàng lại, tiêu chí
tìm kiếm đưa ra ở đây là số hiệu hàng hóa.
Phù hợp, vì các giải pháp này thực hiện tự
động,hữu ích cho doanh nghiệp, không bị
giới hạn .
Giải pháp 4 – đơn đặt hàng lại tiếp theo
trong hàng đợi được lấy ra từ hệ thống
quản lý đơn hàng (hồ sơ về hàng hóa) và
đánh dấu xác nhận.
Phù hợp, vì các giải pháp này thực hiện tự
động,hữu ích cho doanh nghiệp, không bị

giới hạn .
Giải pháp 5 - chuỗi này được vận chuyển
bằng tay.
Không phù hợp, bởi giài pháp này là các
bước thực hiện bằng tay.
Giải pháp cho mối quan tâm 1 và 5 vẫn là một phần của thiết kế giải pháp tổng
thể, tuy nhiên hai giải pháp này sẽ không cung cấp như một dịch vụ. Các giải pháp còn
lại (đối với mối quan tâm 2, 3, và 4) sẽ được áp dụng trong mẫu định nghĩa dịch vụ
(service definition pattern)
2. Service Definition Pattern
Việc xác định các giải pháp logic phù hợp để đóng gói dịch vụ, gom nhóm và
phân phối các giải pháp logic theo các chức năng nhất định là các bước thiết lập các biên
dịch vụ cơ bản. Đường biên này thực sự quan trọng khi một loạt các dịch vụ được tập
hợp và liên quan tới nhau.
Để xác định đường biên phù hợp nhất cho một dịch vụ cần căn cứ vào chức năng
mà dịch vụ đó thực hiện. Đường biên xác định chức năng nào thực hiện bên trong và bên
ngoài dịch vụ. Pattern định nghĩa dịch vụ giúp đưa ra tiêu chí để xác định dịch vụ nào là
agnostic, dịch vụ nào là non-agnostic, giúp tổ chức dịch vụ agnostic theo từng khả năng
riêng biệt.
12
SOA DESIGN PATTERNS QLHTTT K2
Hình 7. Service definition pattern - Mẫu định nghĩa dịch vụ tổ chức dịch vụ logic theo
từng phạm vi cụ thể từ đó thiết lập đường biên dịch vụ
2.1 Agnostic Context
2.1.1 Vấn đề:
Một giải pháp logic đưa ra để giải quyết một mối quan tâm (vấn đề) đơn lẻ thường
sẽ gồm những nguyên lý, các nguyên lý này không chỉ ứng dụng để giải quyết một mối
quan tâm đặt ra, nó cũng có thể phù hợp để giải quyết các vấn đề quan tâm khác. Gom
nhóm các tính năng (nguyên lý) đa ứng dụng (giải quyết được nhiều mối quan tâm) và
đơn ứng dụng với nhau vào thành một đơn vị logíc sẽ hạn chế hoặc thậm chí loại trừ

được khả năng sử dụng lại các giải pháp logic (hình 8)
Hình 8. Các đơn vị giải pháp logic sẽ được xây dựng để giải quyết các mối quan tâm
(thu được khi phân tách từ vấn đề lớn). Các đơn vị 1, 3 và 6 tương ứng là các giải
pháp logic chứa đa tính năng (ngoài tính năng giải quyết mối quan tâm tương ứng)
bên trong nó còn tính năng đơn có giải quyết mối quan tâm khác. Giải pháp logic với
tính năng đơn (non-agnostic) giải quyết duy nhất một mối quan tâm được thể hiện
bằng các hình sọc chéo.
13
SOA DESIGN PATTERNS QLHTTT K2
2.1.2 Giải pháp:
Các giải pháp logic trung lập có được từ các phân tách ở trên sẽ được tập hợp vào
để giải quyết vấn đề lớn khác. Một hay nhiều dịch vụ với các thuộc tính chức năng đa
ứng dụng (trung lập) cụ thể sẽ được xác định sau đó dựa vào phạm vi của giải pháp cung
cấp.
Hình 9. Áp dụng Pattern này dẫn đến một tập con các giải pháp logíc. Tập con này sẽ tiếp
tục được phân tách và phân phối vào trong các dịch vụ với các thuộc tính (phạm vi) trung
lập riêng.
2.1.3 Ứng dụng:
Các thuộc tính dịch vụ trung lập được xác định qua việc thực hiện các phân tích
hướng dịch vụ và qua các quy trình mô hình hóa dịch vụ.
Giải pháp logic sau đó sẽ được phân tách và tổ chức lại thành đầu vào để tiến hành
các quy trình mô hình hóa và phân tích. Agnostic logic được xác định và tiếp tục làm mịn
thành một tập thuộc tính dịch vụ xác định.
2.1.4 Ảnh hưởng:
Ứng dụng Pattern này sẽ gia tăng độ phức tạp trong thiết kế và các vấn đề liên
quan đến quản trị (Việc quản trị các dịch vụ trung lập sẽ phức tạp hơn so với giải pháp
logic dành riêng cho một mối quan tâm đơn lẻ)
2.1.5 Ví dụ:
Mối quân tâm Giải pháp Thuộc tính
Quan tâm 2 - Làm thế Giải pháp 2 – dây - tạo một bản ghi tóm tắt hàng

14
SOA DESIGN PATTERNS QLHTTT K2
nào có thể ghi lại tóm tắt
thông tin hàng hóa trong
dây chuyền.
chuyền được ghi lại tự
động như là một phần
của hệ thống kiểm soát
hàng hóa.
hóa mới.
- lấy thông tin số serial của dây
truyền.
- nhập thông tin dây chuyền,
thông tin dây chuyền nhập vào
sẽ được gán thêm số mô hình
xác định trước.
- lưu lại bản ghi.
Quan tâm 3 - Làm thế
nào dây chuyền có thể
tham chiếu tới bất kỳ một
đơn đặt hàng lại tương
ứng?.
Giải pháp 3 - Sau khi ghi
lại thông tin hàng hóa,
hệ thống sẽ thực hiện
một kiểm tra chéo cho
các đơn đặt hàng lại, tiêu
chí tìm kiếm đưa ra ở
đây là số hiệu hàng hóa.
- Thực hiện câu truy vấn từ khóa

là số mô hình gán vào thông tin
dây chuyền nhập ở trên để xác
định các đơn đặt hàng lại.
- Nếu có dữ liệu, câu truy vấn sẽ
trả về một danh sách các đơn đặt
hàng lại chưa xử lý sắp xếp theo
ngày.
- Nếu không có dữ liệu, chấm
dứt quá trình.
Quan tâm 4 - Làm thế
nào để dây chuyền có thể
xác định được đâu là đơn
đặt hàng lại?
Giải pháp 4 – đơn đặt
hàng lại tiếp theo trong
hàng đợi được lấy ra từ
hệ thống quản lý đơn
hàng (hồ sơ về hàng
hóa) và đánh dấu xác
nhận.
- Truy vấn dữ liệu các đơn đặt
hàng lại, xét đơn đặt hàng lại
đầu tiên (ngày xa nhất) (sau đó
lần lượt với các đơn đặt hàng lại
tiếp theo)
- Thay đổi trạng thái đơn hàng
từ "đặt hàng lại" thành "đã hoàn
thành"
- Lưu lại thông tin bản ghi vừa
sửa.

Sau khi xem xét, đánh giá các hành động trong các giải pháp trên. Các hành động
trong các giải pháp sẽ được phân loại để tái sử dụng lại (hình thành cơ sở các thuộc tính
chức năng trung lập), các hành động trong các giải pháp trên được tổ chức, gom nhóm
thành các agnostic service contexts sau (hình 10):
Inventory Processing
- Tạo một bản ghi tóm tắt hàng hóa mới
- Nhập thông tin dây chuyền, thông tin dây chuyền nhập vào sẽ được gán thêm số
mô hình xác định trước.
- Lưu lại bản ghi.
15
SOA DESIGN PATTERNS QLHTTT K2
Chain Information
- Lấy thông tin số serial của dây truyền
Order Processing
- Thực hiện câu truy vấn từ khóa là số mô hình gán vào thông tin dây chuyền nhập
ở trên để xác định các đơn đặt hàng lại.
- Nếu có dữ liệu, câu truy vấn sẽ trả về một danh sách các đơn đặt hàng lại chưa xử
lý sắp xếp theo ngày.
- Truy vấn dữ liệu các đơn đặt hàng lại, xét đơn đặt hàng lại đầu tiên (ngày xa nhất)
(sau đó lần lượt với các đơn đặt hàng lại tiếp theo)
- Thay đổi trạng thái đơn hàng từ "đặt hàng lại" thành "đã hoàn thành"
- Lưu lại thông tin bản ghi vừa sửa.
Hình 10. Các Agnostic service context đượt thành lập như là kết quả của việc áp dụng
Pattern, tất cả ba dịch vụ được dựa trên thực thể trừu tượng.
2.2 Non – Agnostic Context
2.2.1 Vấn đề:
Khi ứng dụng định hướng dịch vụ, ta nhấn mạnh vào sự trừu tượng hóa và vai trò
của giải pháp logic đóng vai trò trung lập với các quy trình nghiệp vụ và các thao tác
nghiệp vụ. Đây là cơ sở của nguyên tắc “Tái sử dụng” dịch vụ.
Kết quả, các Non-agnostic được lọc ra, không đóng gói thay vào đó chúng tồn tại

như các service consumer.
Hình 11. Các giải pháp logic Non-agnostic không được đóng gói thành một dịch vụ, do
đó nó có thể làm giảm hiệu quả của các thành phần dịch vụ bao gồm cả các dịch vụ
Agnostic
16
SOA DESIGN PATTERNS QLHTTT K2
2.2.2 Giải pháp:
Non-agnostic được đóng gói thể hiện như một dịch vụ với các thuộc tính chức
năng tương ứng (hình 12). Dịch vụ này có vị trí logic như một phần của service
inventory. Khi đóng gói thể hiện như một dịch vụ, các thành phần dịch vụ khác có thể sử
dụng giải pháp này bất kỳ khi nào.
Hình 12. Non-agnostic service logic được đóng gói trên cơ sở các thuộc tính đơn tương
ứng.
2.2.3 Ứng dụng:
Dịch vụ Non-agnostic được định hình thông qua các nguyên tắc thiết thế tương tự
như các dịch vụ agnostic nhưng không tính tới nguyên tắc tái sử dụng dịch vụ.
Chú ý: nếu chức năng tái sử dụng tìm thấy bên trong biên dịch vụ Non-agnostic nó
có thể được thể hiện như một Agnostic Sub-Controller.
Kết quả cuối cùng khi áp dụng hai pattern trên là tất cả các giải pháp logic phù
hợp cho đóng gói được tổ chức thành một tập hợp các ngữ cảnh dịch vụ cụ thể rõ ràng.
(hình 13).
Hình 13. Các dịch vụ cụ thể sau khi đóng gói
2.2.4 Ảnh hưởng:
Ứng dụng Pattern này sẽ gia tăng độ phức tạp trong thiết kế và hiệu quả lợi ích
mang lại không cao như các dịch vụ Agnostic
17
SOA DESIGN PATTERNS QLHTTT K2
II. Service Implementation Patterns
1. Service Façade
1.1. Vấn đề:

Việc liên kết giữa phần lõi logic của dịch vụ với các ràng buộc về giao tiếp và
việc thực thi chúng có thể làm hạn chế sự phát triển của dịch vụ và ảnh hưởng đến đối
tượng sử dụng dịch vụ.
Hình 14. Nếu phần lõi của dịch vụ logic kết nối trực tiếp tới các giao tiếp (contract), bất
kỳ một thay đổi nào trong tương tác giữa người dùng và dịch vụ sẽ cần thay đổi lõi dịch
vụ theo trương ứng.
1.2. Giải pháp:
Các thành phần của dịch vụ mặt ngoài (service façade) được sử dụng như là một
bộ phận trong kiến trúc dịch vụ.
Service façade - dạng thức mặt ngoài(Façade) được thêm vào trong kiến trúc dịch
vụ để thiết lập một hay nhiều lớp trừu tượng , các lớp này sẽ thực hiện các điều chỉnh phù
hợp khi có thay đổi trong cách thức giao tiếp của dịch vụ và việc thực thi chúng(Hình
15).
Hình 15. Façade logic được đặt ở giữa phần lõi dịch vụ và các giao tiếp
(contract). Điều này cho phép phần lõi logic dịch vụ tách rời với giao tiếp.
1.3. Ứng dụng:
Các thành phần mặt ngoài được thiết kế để tích hợp với dịch vụ.
Dịch vụ mặt ngoài được xem như là một phần trong toàn bộ các dịch vụ logic
nhưng nó có sự khác biệt với các dịch vụ logic khác như sau:
18
SOA DESIGN PATTERNS QLHTTT K2
- Lõi dịch vụ logic cung cấp một loạt các chức năng chịu trách nhiệm thực hiện các
thể hiện đưa ra trong service contract.
- Dịch vụ mặt ngoài chủ yếu thực hiện việc cung cấp, bổ sung và xử lý hỗ trợ lõi
dịch vụ logic.
Service façade là một phần độc lập và riêng rẽ của kiến trúc dịch vụ. Thông
thường thì dịch vụ mặt ngoài sẽ gồm cá thành phần sau:
Khối chuyển tiếp(Relaying Logic ) – Khối logic mặt ngoài đơn giản chuyển tiếp
thông tin vào, ra giữa các giao tiếp(contract) và dịch vụ cơ sở hoặc giữa dịch vụ cơ sở và
các thành phần khác trong kiến trúc dịch vụ.

Khối chuyển đổi(Broker Logic ) – Khối logic mặt ngoài thực hiện các chuyển đổi
logic để phù hợp (hỗ trợ) Service Broker (707). Điều này đặc biệt cần thiết khi một đơn
vị lõi của dịch vụ logic sử dụng đồng thời nhiều giao tiếp.
Khối xử lý (Behavior Correction) – Khối logic mặt ngoài đuợc dùng khi có các
thay đổi của dịch vụ cơ sở trong việc duy trì giữa liên lạc giữa dịch vụ sử dụng và các
dịch vụ cơ sở.
Contract-Specific Requirements – Dịch vụ mặt ngoài luôn tương thích nhiều loại
dịch vụ (service consumers). Chúng có thể tìm thấy và hỗ trợ bất cứ yêu cầu tương tác
nào. Điều này bao gồm các lĩnh vực như an ninh, độ tin cậy và chế độ xử lý.
Các thành phần dịch vụ mặt ngoài(Service façade ) trong kiến trúc định hướng
dịch vụ có thể nằm ở nhiều vị trí khác nhau và phụ thuộc vào tính chất và yêu cầu mở
rộng.
Hình 16. Sử dụng các thành phần mặt ngoài cho phép bổ sung thêm nhiều service
contract mà không ảnh hưởng lớn đến lõi dịch vụ. Các thành phần của dịch vụ mặt ngoài
luôn đi cùng với các contract,cho phép các dịch vụ lõi liên kết lỏng hơn với các giao tiếp.
1.4. Ảnh hưởng:
Việc có thành phần mặt ngoài làm tăng sự phân chia logic vật lý. Điều này cũng
tăng thêm công việc thiết kế và phát triển cũng như việc tăng thêm yêu cầu liên hệ. Một
số công việc quản lý tăng lên theo yêu cầu tăng thêm các thành phần cho mỗi dịch vụ do
việc các thành phần nghiệp vụ được thêm vào.
19
SOA DESIGN PATTERNS QLHTTT K2
2. Redundant Implementation
2.1Vấn đề:
Dịch vụ trung lập (Agnostic service) thường được sử dụng lại ở nhiều tác vụ
khác nhau , khi dịch vụ này bị lỗi nó có thể là điểm dẫn đến giảm độ tin cậy của các dịch
vụ khác đang tham chiếu sử dụng nó.
Hình 17. Khi một dịch vụ trung lập (dịch vụ khả năng tái sử dụng cao) đột nhiên không
ứng dụng được, nó sẽ ảnh hưởng tới tất cả các service consumer đang sử dụng nó.
2.2Giải pháp:

Dịch vụ được tái sử dụng được triển khai các phương pháp dự phòng hoặc hỗ trợ
chuyển đổi dự phòng để luôn đảm bảo tính sẵn sàng và độ tin cậy cao ngay cả khi các
ngoại lệ không mong muốn hoặc dịch vụ ngừng hoạt động xảy ra (Hình 18)
Hình 18. Thực thi bổ sung thêm các dịch vụ Agnostic để thay thế khi có dịch vụ bị lỗi.
2.3Ứng dụng:
Khi một dịch vụ triển khai phương án dự phòng, có một số cách sau:
- Quá trình triển khai dịch vụ dự phòng có thể được thiết lập cho các bộ service
consumer khác nhau.
- Quá trình thực thi một dịch vụ được chỉ rõ (định rõ) như là điểm tiếp xúc (liên kết)
chính với người sử dụng cuối. Trong trường hợp việc thực thi dịch vụ bị lỗi hay
dịch vụ không sẵn sàng việc xử lý (thực thi) sau đó (tiếp theo) được thực hiện bởi
một hoặc nhiều quá trình thực thi đã được lưu .
Hình 19. Minh họa cách triển khai dịch vụ theo cách thứ nhất (dịch vụ dự phòng
thiết lập với các service consumer khác nhau). Một cho việc truy cập bởi các service
consumer bên trong (các yêu cầu dịch vụ bên trong hệ thống), một cho việc truy cập bởi
20
SOA DESIGN PATTERNS QLHTTT K2
các consumer service bên ngoài.
Hình 19. Dịch vụ A có nhiều liên kết dịch vụ, cho phép các chương trình của người tiêu
dùng cuối khai thác thuận lợi
2.4Ảnh hưởng:
Việc ứng dụng Redundant Implementation (quá trình dự phòng) sẽ nâng cao
quyền tự chủ, độ tin cậy và khả năng mở rộng của các dịch vụ và service inventory được
xem như một khối toàn thống nhất. Tuy nhiên nó cũng có một số ảnh hưởng nhất định
như: tăng các yêu cầu và chi phí về cơ sở hạ tầng, các yêu cầu tới hoạt động quản trị
III. Service Security Patterns
1. Exception Shielding
1.1. Vấn đề:
Khi một ngoại lệ xuất hiện trong lúc dịch vụ đang chạy, dịch vụ này có thể phát ra
một tin nhắn hồi đáp tới người dùng (các thông báo xử lý ngoại lệ). Như trong hình 13.1

(dưới đây), tin nhắn này có thể chứa những thông tin không an toàn, các thông tin này có
thể được khai thác để tấn công dịch vụ và môi trường xung quanh nó.
21
SOA DESIGN PATTERNS QLHTTT K2
Hình 20. Thông báo xử lý ngoại lệ có thông tin dữ liệu không an toàn
1.2. Giải pháp:
Phần dữ liệu không an toàn trong thông báo hồi đáp sẽ được “ tinh chỉnh- làm
sạch” bằng cách thay thế vào đó là những thông tin an toàn trước khi tới tay người dùng
cuối. Do đó, thông tin hồi đáp đến tay người dùng cuối cùng sẽ không có các các thông
tin nhạy cảm, không có lỗi chi tiết, không tiết lộ các chi tiết có hại cho hoạt động bên
trong của hệ thống (hình 13.2)
Hình 21. Dữ liệu trong thông báo ngoại lệ đã được tinh chỉnh làm sạch
1.3. Ứng dụng:
Các thủ tục “tinh chỉnh – làm sạch” có thể được xây dựng trong thời gian thiết kế
dịch vụ ban đầu hoặc trong giai đoạn tái cấu trúc lại dịch vụ hoặc trong giai đoạn thực thi
dịch vụ. Để làm được điều này cần phải có chi tiết các ngoại lệ được xác định từ trước.
Tuy nhiên, pattern này chỉ tập trung vào thời điểm khi thực thi dịch vụ.
Quy trình tinh chỉnh bao gồm các bước sau:
Bước 1. Người dùng gửi yêu cầu tới dịch vụ.
Bước 2. Dịch vụ nắm bắt các yêu cầu và thực thi các yêu cầu. Phát sinh ngoại lệ,
dịch vụ sẽ ném ra các thông tin về ngoại lệ. Thông tin ngoại lệ có thể chứa thông tin an
toàn và không an toàn.
Bước 3. Các thủ tục Exception shielding xây dựng bên trong các dịch vụ logic sẽ
kiểm tra thông tin ngoại lệ đưa ra. Nếu thông tin đó an toàn thì có nghĩa là nó đã được
chỉnh và sẽ gửi tới người dùng. Còn trong TH, thông tin ngoại lệ không an toàn, nó sẽ
được thay thế với những thông tin ngoại lệ an toàn.
Bước 4. Dịch vụ trả về thông tin ngoại lệ an toàn đối với người dùng.
1.4. Ảnh hưởng:
Thông tin ngoại lệ đã đc tinh chỉnh có thể tạo ra hàng loạt các lỗi khó hơn đối với
người dùng cuối do thiếu các chi tiết đưa ra. Ngoài ra, khi áp dụng pattern này có thể tăng

thời gian chạy lọc và xử lý thông tin.
22
SOA DESIGN PATTERNS QLHTTT K2
Hơn nữa, việc xây dựng pattern này đòi hỏi các nhà phát triển phải có sự hiểu biết
về một loạt các mối đe dọa bảo mật tiềm năng. Nếu không hiểu biết đầy đủ có thể dẫn tới
hiểu sai về tính an toàn của thông tin.
2. Message screening
2.1Vấn đề:
Một kẻ tấn công có thể truyền tải thông điệp tới dịch vụ với nội dung độc hại hoặc
không đúng theo định dạng, nó có thể là nguyên nhân gây ra các xử lý không mong muốn
của dịch vụ (hình 22).
Hình 22. dữ liệu độc hại được truyền bởi kẻ tấn công, các phần mầu da cam thể
hiện cho dữ liệu độc hại.
2.2Giải pháp:
Khi thiết kế các dịch vụ logic, ta đảm bảo rằng tất cả dữ liệu đầu vào đều được
kiểm tra đảm bảo không có thông tin độc hại. Do đó các thủ tục lọc thông điệp cụ thể cần
được thêm vào bên trong dịch vụ logic. Các thủ tục logic này thực thi các chính sách đã
được định nghĩa rõ ràng.
Hình 23. Do dịch vụ logic được trang bị thêm các thủ tục màn lọc thông điệp, các thông
tin dữ liệu độc hại và không đúng có thể được phát hiện và loại bỏ trước khi nó có cơ hội
ảnh hưởng dịch vụ.
23
SOA DESIGN PATTERNS QLHTTT K2
2.3Ứng dụng:
Khi dịch vụ nhận được thông điệp, nó thực hiện một số kiểm tra để lọc ra phần nội
dung độc hại.
Ứng dụng Pattern này đòi hỏi các thủ tục lọc thông điệp cần thiết được bổ sung
vào dịch vụ, theo cách như vậy chúng sẽ được gọi ra khi có dữ liệu đẩy vào. Những thủ
tục này sẽ được thiết kế để thực thi một loạt các thao tác lọc chuẩn hóa, như:
- So sánh kích cỡ của thông điệp yêu cầu với kích thước cho phép tối đa đã được

quy định đối với một thông điệp yêu cầu.
- Phân tích toàn bộ thông điệp yêu cầu để tìm nội dung độc hại ( đối với dịch vụ
web, nội dung độc hại có thể có trong phần thân hoặc tiêu đề thông điệp SOAP,
do đó cần tiến hành kiểm tra toàn bộ)
Khi thiết kế logic lọc, cần cân nhắc một số yếu tố sau:
- Nếu thông điệp được mã hóa bởi một lớp bảo vệ, nó có thể không kiểm tra được
dữ liệu để xác định nội dung độc hại trừ khi thông điệp được giải mã trước hoặc
logic lọc có key giải mã.
- Logic lọc thông điệp cần phải rất hiệu quả khi nó thực hiện việc xác thực các kiểm
tra nếu không nó có thể biến thành một nút thắt cổ chai của hệ thống và chính nó
lại trở thành mục tiêu của một cuộc tấn công từ chối dịch vụ.
2.4Ảnh hưởng:
Xây dựng và duy trì logic lọc thông điệp đòi hỏi các kỹ năng chuyên ngành để
đảm bảo rằng tất cả các mối đe dọa có thể được kiểm tra. Khi áp dụng Pattern này có thể
dẫn đến cảm giác sai về an toàn nếu như các thủ tục lọc được thiết kế, xây dựng không
phù hợp.
Mặt khác, việc thực hiện kiểm tra dữ liệu sẽ yêu cầu thêm thời gian chạy dẫn đến
tăng độ trễ trong xử lý dịch vụ.
24
SOA DESIGN PATTERNS QLHTTT K2
TÀI LIỆU THAM KHẢO
1. Soa Design Patterns – Thomas Erl
2.
25