TIỂU LUẬN DỊCH VỤ PHẦN MỀM VÀ TÍCH HỢP HỆ THỐNG

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
VIỆN ĐÀO TẠO SAU ĐẠI HỌC

TIỂU LUẬN
DỊCH VỤ PHẦN MỀM VÀ TÍCH HỢP HỆ THỐNG
Giảng viên hướng dẫn: TS. Vũ Thị Hương Giang
Học viên nhóm 6: Nguyễn Văn Minh
Phạm Anh Thắng
Hà Nội - 11/2014
MỤC LỤC
MỤC LỤC 2
GIỚI THIỆU CHUNG VỀ DESIGN PATTERNS 6
PHẦN I: FOUNDATIONAL INVENTORY PATTERNS 7
1.Enterprise Inventory 7
1.1.Problem 7
1.2.Solution 8
1.3.Application 8
1.4.Impacts 9
1.5.Relationships 9
2.Domain Inventory 9
2.1.Problem 10
2.2.Solution 10
2.3.Application 11
2.4.Impacts 11
2.5.Relationships 12
3.Service Normalization 12
3.1.Problem 12
3.2.Solution 13
3.3.Application 13
3.4.Impacts 14
3.5.Relationships 14

4.Logic Centralization 14
4.1.Problem 14
4.2.Solution 15
4.3.Application 15
4.4.Impacts 15
4.5.Relationships 16
5.Service Layers 16
5.1.Problem 16
5.2.Solution 17
5.3.Application 17
5.4.Impacts 18
5.5.Relationships 18
6.Canonical Protocol 18
6.1.Problem 18
6.2.Solution 19
6.3.Application 19
6.4.Impacts 20
6.5.Relationships 21
7.Canonical Schema 21
7.1.Problem 21
7.2.Solution 21
7.3.Application 22
7.4.Impacts 22
7.5.Relationships 22
PHẦN II: FOUNDATIONAL SERVICE PATTERN 23
1.Functional Decomposition 23
1.1.Problem 23
1.2.Solution 23
1.3.Application 24
1.4.Impacts 24

1.5.Relationships 24
2.Service Encapsulation 25
2.1.Problem 25
2.2.Solution 25
2.3.Application 26
2.4.Impacts 26
2.5.Relationships 26
3.Agnostic Context 26
3.1.Problem 26
3.2.Solution 27
3.3.Application 27
3.4.Impacts 28
3.5.Relationships 28
4.Non-Agnostic Context 28
4.1.Problem 28
4.2.Solution 29
4.3.Application 29
4.4.Impacts 30
4.5.Relationships 30
5.Agnostic Capability 30
5.1.Problem 30
5.2.Solution 31
5.3.Application 32
5.4.Impacts 32
5.5.Relationships 32
PHẦN III: COMPOSITION IMPLEMENTATION PATTERNS 33
1.Agnostic Sub-Controller pattern 33
1.1. Problem 33
1.2.Solution 33
1.3.Application 34

1.4.Impacts 35
1.5. Relationships 35
2.Composition Autonomy pattern 36
2.1.Problem 36
2.2.Solution 36
2.3.Application 37
2.4.Impacts 37
2.5.Relationships 37
3.Atomic Service Transaction pattern 38
3.1.Problem 38
3.2.Solution 38
3.3.Application 39
3.4.Impacts 39
3.5.Relationships 40
4.Compensating Service Transaction pattern 41
4.1.Problem 41
4.2.Solution 41
4.3.Application 42
4.4.Impacts 42
4.5.Relationships 43
PHẦN IV: ỨNG DỤNG VÀO BÀI TOÁN ĐĂNG KÝ HỌC 44
1.Mô tả bài toán đăng ký học 44
2.Áp dụng Design pattern vào bài toán 45
2.1.Composition Autonomy pattern 45
2.2.Atomic Service Transaction pattern 45
2.3.Compensating Service Transaction pattern 46
3.Định nghĩa các dịch vụ 46
3.1.Mô tả dịch vụ 46
3.2.Triển khai các dịch vụ 48
3.3.Xây dựng sơ đồ tích phối 48

4.Cài đặt 50
4.1.Orchestration 50
4.2.Choreography 51
4.3.Kết quả test webservice bằng application client : 51
4.4.Đăng ký và sử dụng dịch vụ trên JUDDI 51
GIỚI THIỆU CHUNG VỀ DESIGN PATTERNS
Trong công nghệ phần mềm, một mẫu thiết kế (Design Pattern) là một giải pháp có
thể áp dụng lại cho các vấn đề chung thường gặp trong thiết kế phần mềm. Một phần
mềm có thể hoàn thành mà không có sự góp mặt của Design Pattern nhưng sự có mặt của
Design Pattern sẽ giúp xác định bài toán nhanh hơn và giải quyết một cách hiệu quả hơn.
Một mẫu thiết kế không phải là một thiết kế hoàn thiện để có thể chuyển đổi trực tiếp
thành mã. Nó chỉ là các hướng dẫn hay là ví dụ mẫu chỉ ra cách giải quyết một vấn đề mà
chúng ta có thể áp dụng vào trong nhiều tình huống khác nhau.
Các mẫu thiết kế có thể giúp tăng tốc quá trình phát triển phần mềm bằng cách cung
cấp các mẫu hình phát triển đã được chứng thực và kiểm chứng. Thông thường, mọi
người chỉ biết cách áp dụng một số kĩ thuật thiết kế phần mềm nào đó vào một vài vấn đề
cụ thể nào đó. Những kĩ thuật này khó áp dụng mở rộng cho các vấn đề khác. Các mẫu
thiết kế cung cấp các giải pháp chung, được viết tài liệu dưới một định dạng mà không
gắn liền với một vấn đề cụ thể nào cả.
PHẦN I: FOUNDATIONAL INVENTORY PATTERNS
Các mẫu thiết kế tại Chương 6: Foundational Inventory Patterns này chủ yếu định
nghĩa tầm quan trọng của mô hình kiến trúc hướng dịch vụ trên nền kiến trúc kiểm kê -
Service Inventory Architecture. Những trục trặc về thiết kế dịch vụ được giải quyết bởi
những pattern này sẽ giúp cấu trúc của giải pháp thiết kế logic có được một môi trường
linh hoạt và nhanh nhẹn; phù hợp với kiến trúc hướng dịch vụ.
Mẫu kiểm kê - Inventory Design Patterns bao gồm 7 phần:
 Enterprise Inventory
 Domain Inventory
 Service Normalization
 Logic Centralization

 Service Layers
 Canonical Protocol
 Canonical Schema
1. Enterprise Inventory
Enterprise Inventory là một mẫu thiết kế tạo bởi Thomas Erl để trả lời cho câu hỏi:
“Làm thế nào để các dịch vụ được cung cấp có thể tối đa hóa việc tái cấu trúc”. Việc áp
dụng mô hình này cho kết quả là các tiêu chuẩn hóa trong các dịch vụ kiểm kê của doanh
nghiệp trên diện rộng.
1.1. Problem
Khi cung cấp các dịch vụ độc lập thông qua các dự án khác nhau tại một doanh
nghiệp có nguy cơ tạo ra các kiến trúc thực thi hoặc dịch vụ không phù hợp; ảnh hưởng
đến khả năng tái cấu trúc.
Tại một doanh nghiệp, các service được cung cấp như 1 phần của các dự án mà vẫn
đang tiếp tục phát triển. Bởi vì mỗi một dự án lại có độ ưu tiên và mục tiêu riêng do vậy
các dịch vụ và các kiến trúc thực thi được thiết kế một cách một cách độc lập , tối ưu hóa
để đáp ứng các yêu cầu kỹ thuật. Kết quả là sẽ sinh ra một tập các dịch vụ và kiến trúc
công nghệ khác nhau. Sự khác biệt trong các môi trường thực thi khác nhau có thể sinh ra
những vấn đề nghiêm trọng khi ta cố gắng cấu trúc các dịch vụ vào lại khung kiến trúc
ban đầu.
1.2. Solution
Giải pháp cho vấn đề này là đưa ra các tiêu chuẩn hóa cho các dịch vụ; đưa ra các
kiến trúc kiểm kê cho toàn bộ doanh nghiệp từ đó các dịch vụ có thể được tự do và liên
tục tái cấu trúc.
Một kiến trúc hướng dịch vụ áp dụng cho doanh nghiệp được thiết lập để hình thành
cơ sở cho một mẫu dịch vụ kiểm kê. Các dịch vụ cung cấp tại bất kỳ dự án nào của doanh
nghiệp được thiết kế riêng theo kiến trúc kiểm kê; đảm bảo theo các tiêu chuẩn của toàn
doanh nghiệp và đáp ứng khả năng tương tác nội tại.
1.3. Application
Việc kiểm kê dịch vụ áp dụng cho các doanh nghiệp ý tưởng là mô hình hóa cấp cao
các dịch vụ; các tiêu chuẩn của cả doanh nghiệp được áp dụng khi đưa ra các dịch vụ cho

các dự án khác nhau.
Có rất nhiều yếu tố ảnh hưởng đến việc kiểm kê dịch vụ; các yếu tố này có thể làm
giảm quy mô phạm vi của dự án hoặc yêu cầu ta phải tìm kiếm một phương pháp thực thi
khác:
- Tính đáp ứng về công nghệ cho các dịch vụ được kế hoạch.
- Nền tảng công nghệ trong việc quản trị để đáp ứng cho việc quản lý và phát
triển các mẫu kiểm kê ngay khi nó đang được xây dựng và sau khi cung cấp.
Mẫu Kiểm kê dịch vụ không cần thiết phải dùng toàn bộ các thành phần của hệ
thống; Mục đích của mẫu này là để thiết lập một dịch vụ kiểm kê đơn lẻ đảm bảo đủ
phạm vi để dịch vụ có thể được tạo thành. Xa hơn nữa, ứng dụng cho mẫu này không là
kết quả cho việc tạo ra các dịch vụ vật lý. Nó chỉ thiết lập các khái niệm về dịch vụ kiểm
kê cho toàn bộ doanh nghiệp; bởi vậy các dịch vụ chỉ được định nghĩa qua các kế hoạch
và bản phân tích kiểm kê.
1.4. Impacts
Việc phân tích trước các dịch vụ rất quan trọng; nó cho phép các mẫu kiểm kê có thể
được số hóa và thiết kế chi tiết các tác động của tổ chức theo yêu cầu của nhà quản trị.
Để đạt được sự thống nhất trên dịch vụ kiểm kê của toàn doanh nghiệp, các phân
tích tiếp cận từ trên xuống top-down (đôi khi còn phân tích ở quy mô lớn) được dùng để
mô hình hóa và liên kết các dịch vụ trước khi cung cấp cho khách hàng. Việc phân tích có
thể gây tốn kém về tiền bạc cũng như đòi hỏi nhiều thời gian để hoàn thành.
Phương pháp thay thế - Alternative Methodologies - có thể được dùng trong giai
đoạn cung cấp các dịch vụ với chi phí phân tích ít hơn. Ví dụ, cách tiếp cận ở giữa “meet-
in-the-middle” cho phép phân tích ngay tại lúc các dịch vụ đang được xây dựng và thực
thi. Sau đó có một rằng buộc để xắp xếp lại các dịch vụ ngay sau thời điểm sản phẩm
được phân tích. Mặc dù được chứng minh là tốn ít thời gian hơn phương pháp tiếp cận từ
trên xuống top-down nhưng phương pháp này lại phức tạp và tốn nhiều chi phí hơn.
1.5. Relationships
Enterprise Inventory thiết lập một ranh giới kiến trúc với cấu trúc vật lý là các đối
tượng được áp dụng các mẫu kiểm kê. Inventory Endpoint có thể bổ sung cho các mẫu
này bằng cách cung cấp các tiêu chuẩn để truy cập đến các khách hàng bên ngoài doanh

nghiệp. Domain Inventory cung cấp các lựa chọn chủ yếu cho mẫu kiểm kê này.
2. Domain Inventory
Kiểm kê lĩnh vực - Domain Inventory - được xây dựng để trả lời cho câu hỏi: Làm
thế nào để các dịch vụ đã cung cấp có thể tối đa việc tái cấu trúc khi mà toàn bộ các tiêu
chuẩn của doanh nghiệp không khả thi.
2.1. Problem
Trong các môi trường rộng lớn, có thể không thực tế để định rõ hoặc duy trì một
mẫu kiểm kê dịch vụ cho các thực thể trong doanh nghiệp. Các tiêu chuẩn và thông điệp
quản lý phát ra có thể dẫn tới nhiều điều bận tâm do vậy hầu hết các tiêu chuẩn và thông
điệp này đều có xu hướng tổ chức hóa các đặc tính.
Việc thiết lập một mẫu kiểm kê dịch vụ riêng lẻ có thể làm doanh nghiệp không thể
quản lý hiệu quả và điều đó có thể làm ảnh hưởng đến sự thành công trong việc áp dụng
kiến trúc SOA vào hệ thống sản xuất.
2.2. Solution
Rất nhiều các kiểm kê dịch vụ được xây dựng cho từng doanh nghiệp. Phạm vi của
mỗi miêu tả dịch vụ này được xác định rõ trong các lĩnh vực của doanh nghiệp. Trong
mẫu lĩnh vực, các kiểm kê dịch vụ được tiêu chuẩn hóa và điều chỉnh độc lập.
2.3. Application
Dù có áp dụng hay không áp dụng mẫu này vào doanh nghiệp thì đều xuất hiện câu
hỏi là liệu rằng các mẫu kiểm kê dịch vụ có khả thi trong một môi trường nhất định hay
không. Rất nhiều các yếu tố (hầu hết là được tổ chức một cách cụ thể) đều được cân nhắc
đắn đo trên vấn đề này, tuy nhiên vẫn có nhiều các hướng dẫn sẵn dùng cho doanh
nghiệp.
Việc áp dụng mô hình này có thể vượt qua những trở ngại và đẩy nhanh quá trình
chuyển đổi hướng tới kiến trúc hướng dịch vụ. Đối với nhiều tổ chức, mô hình này cung
cấp các tùy chọn cho việc áp dụng SOA trong thực tế. Lý tưởng nhất là mẫu kiểm kê lĩnh
vực phải tương ứng với lĩnh vực kinh doanh của doanh nghiệp. Điều này cho phép mỗi
một kiểm kê phải được điều chỉnh để phát triển với các thiết lập tương ứng với mô hình
kinh doanh theo định hướng kiến trúc đặc trưng.
2.4. Impacts

Nhiều mẫu kiểm kê lĩnh vực khi thực thi gây ra một số áp đặt, trong đó nó cho phép
mỗi một kiểm kê cá nhân sẽ được tiêu chuẩn hóa khác nhau. Điều này dẫn đến sự cần
thiết phải chuyển đổi khả năng tương tác giữa các lĩnh vực như một phần của kiến trúc
doanh nghiệp tổng thể. Yêu cầu chuyển đổi đó xuất hiện để cho phép các lĩnh vực tác
động trao đổi dữ liệu cũng như nỗ lực phát triển các dịch vụ tương ứng trên cùng thời
gian thực hiện. Hơn nữa, sự độc lập mà mỗi mẫu kiểm kê có thể được xây dựng và phát
triển sẽ thường dẫn đến việc tạo ra các dịch vụ dự phòng trên các lĩnh vực.
2.5. Relationships
Các mẫu thiết kế tương tự như cấu trúc mẫu kiểm kê dịch vụ này sẽ kết thúc cơ cấu
được xác định qua Domain Inventory. Tuy nhiên, không như Enterprise Inventory, ứng
dụng của mẫu này nói chung sẽ dẫn tới sự cần thiết cho việc chuyển đổi mô hình như
Protocol Bridging và Data Model Transformation. Inventory Endpoint sẽ đóng vai trò nổi
bật để tạo điều kiện cho việc giao tiếp giữa các mẫu pattern kiểm kê dịch vụ.
3. Service Normalization
3.1. Problem
Ranh giới của một dịch vụ được xác định bởi bối cảnh chức năng của nó và tập hợp
các ranh giới chức năng bao quanh. Thậm chí ngay cả khi đã xác định trước ranh giới
kiểm kê thì khi các dịch vụ được cung cấp bởi các dự án khác nhau đều có thể gặp nguy
cơ chồng chéo chức năng lẫn nhau.
Điều này dẫn đến khả năng không chuẩn hóa (denormalization) của dịch vụ kiểm kê.
Việc không chuẩn hóa này có thể gây ra một số vấn đề, chẳng hạn như:
- Không có khả năng thiết lập tốt các chức năng cho dịch vụ.
- Kiến trúc dịch vụ phức tạp hơn; Các chức năng của dịch vụ có thể bị đồng
bộ hóa, dẫn tới cung cấp cùng một chức năng cho các bài toán khác nhau.
3.2. Solution
Các dịch vụ được mô hình hóa một cách tập thể trước khi các quy ước vật lý giữa
các dịch vụ được tạo ra. Điều này làm cho các khung dịch vụ được lên kế hoạch để đảm
bảo rằng nó không bị trùng lặp với các dịch vụ khác. Kết quả là sẽ tạo ra một dịch vụ
kiểm kê được tiêu chuẩn hóa về mặt chức năng ở mức rất cao.
3.3. Application

Mục tiêu của mẫu này là để nhận biết tốt nhất các dịch vụ được cung cấp bằng cách
sử dụng nguyên lý thiết kế dịch vụ độc lập (Service Autonomy) trong giai đoạn xây dựng
mô hình dịch vụ.
Các bước thực hiện thông thường như sau:
- Định danh và phân rã các quy trình nghiệp vụ gắn liền với khung kiểm kê.
- Phân bổ từng phần của quy trình nghiệp vụ vào các dịch vụ mới hoặc các
dịch vụ đã tồn tại một cách thích hợp.
- Phê duyệt, hợp thức hóa các khung dịch vụ nếu chúng không bị trùng lặp.
Đây là các bước cơ bản để mô hình hóa các dịch vụ; để áp dụng hoàn toàn mẫu
Service Normalization đòi hỏi rằng quá trình này phải được thực hiện lặp đi lặp lại; các
quy trình nghiệp vụ được liên kết với quá trình kiểm kê dịch vụ. Thông qua các lần lặp
lại, bối cảnh chức năng và ranh giới của các dịch vụ ứng cử viên được liên tục cải tiến và
hợp thức hóa. Ranh giới chức năng của các dịch vụ được mô hình hóa như là một phần
của quá trình phân tích hình thức và còn áp dụng trên suốt quá trình thiết kế kiểm kê và
quản trị dịch vụ.
3.4. Impacts
Việc đảm bảo tiêu chuẩn hóa toàn bộ quá trình kiểm kê dịch vụ đòi hỏi rằng toàn bộ
các dịch vụ đã được mô hình hóa trước khi cung cấp, là một phần kế hoạch chi tiết của
kiểm kê dịch vụ. Tùy thuộc vào phạm vi của kế hoạch kiểm kê mà có thể dẫn đến việc
phân tích riêng rẽ các dự án trước khi các dịch vụ được xây dựng.
Theo dõi, quản trị thường xuên là việc làm rất cần thiết để đảm bảo rằng các dịch vụ
vẫn được duy trì bình thường trong suốt quá trình kiểm kê; đảm bảo các dịch vụ hoạt
động bình thường khi chúng được sửa đổi và phát triển theo các thời điểm khác nhau.
3.5. Relationships
4. Logic Centralization
4.1. Problem
Như ta đã biết từ chương trước, việc tái sử dụng chính là chìa khóa để đạt được việc
kết hợp các mục tiêu chiến lược với kiến trúc hướng dịch vụ. Tuy nhiên, ngay cả khi các
dịch vụ được thiết kế không biết đã tốt chưa được đưa vào quá trình kiểm kê dịch vụ, nó
không đảm bảo rằng các dự án sẽ xây dựng các giải pháp mới để sử dụng chúng.

Vì những lý do khác nhau, để có thể dễ dàng hơn, đơn giản hơn, các dịch vụ tái sử
dụng được dùng để thực hiện các nhiệm vụ ngắn hạn. Cách tiếp cận này có thể rất là
thuận tiện, nhưng cuối cùng kết quả là kiểm kê dịch vụ lại không được tiêu chuẩn hóa dẫn
đến việc dư thừa chức năng dịch vụ.
4.2. Solution
Để theo đuổi mục tiêu chiến lược liên quan đến tái sử dụng dịch vụ, các đặc tính tái
sử dụng phải được chuẩn hóa thành các tiêu chuẩn thiết kế nội bộ. Điều quan trọng nhất
của các tiêu chuẩn này cần phải được phân quyền, phân lớp các dịch vụ bất khả tri có
nghĩa là bằng cách đó các dịch vụ bất khả tri đều được triệu gọi bằng quyền truy cập. Nếu
dịch vụ bất khả tri không được nhất quán tái sử dụng, chức năng dự phòng có thể được
cung cấp cho các dịch vụ khác. Đây là cơ sở cho mẫu thiết kế Logic Centralization.
4.3. Application
Khi các dịch vụ được xây dựng từ các dự án khác nhau trong doanh nghiệp; luôn có
rủi ro khi 1 đội phát triển một dịch vụ với tư tưởng logic giống một phần của dịch vụ bất
khả tri. Lý do phổ biến cho việc này là:
- Nhóm dự án không nhận thức được khả năng tồn tại của dịch vụ bất khả tri
bởi vì các dịch vụ không thể mô tả hoặc khám phá đủ được tất cả.
- Nhóm dự án không sử dụng các dịch vụ bất khả tri có sẵn bởi vì chúng được
coi là quá cồng kềnh để xây dựng nên các dịch vụ mới.
4.4. Impacts
Rõ ràng là Logic Centralization rất là hữu ích, tuy nhiên rất khó để có thực hiện tốt
nó; đặc biệt là với các dịch vụ kiểm kê quy mô lớn. Đối với các tổ chức, doanh nghiệp
lớn; để đạt được trạng thái mà tất cả các đội phát triển dự án đều đồng ý không tự xây
dựng các logic dự phòng, thay vào đó sử dụng các dịch vụ hiện có thì có vẻ như đó là một
ý tưởng không thể đạt được.
Những mối quan tâm cần được giải quyết trước khi cung cấp dịch vụ bất khả tri để
tránh ảnh hưởng đến giá trị chiến lượng của việc kiểm kê dịch vụ. Nếu chỉ hỗ trợ một
phần cho việc cung cấp và sử dụng dịch vụ tái sử dụng trong một bộ phận CNTT, nhiều
nguy cơ sẽ xảy ra như kiến trúc kiểm kê dịch vụ không được tiêu chuẩn hóa và các dịch
vụ có độ phức tạp rất là đáng kể.

4.5. Relationships
5. Service Layers
5.1. Problem
Trong một dịch vụ kiểm kê nói chung, thông thường sẽ có xu hướng là dịch vụ có
cùng chung các bối cảnh chức năng giống nhau. Tuy nhiên những dịch vụ này có thể
được thiết kế và thực thi theo những cách khác nhau, tùy theo các yêu cầu của từng dự án
cụ thể. Điều này dẫn tới việc bỏ lỡ cơ hội thiết lập tính thống nhất; cách mà các khung
dịch vụ được định nghĩa; bỏ qua tính đóng gói logic của dịch vụ. Kết quả là hàng loạt các
dịch vụ kiểm kê không dễ dàng chia thành các nhóm khác nhau phục vụ mục đích chia để
trị.
5.2. Solution
Kiến trúc của một dịch vụ kiểm kê thường được thiết lập để chia thành các hồ sơ
(profiles) – phục vụ cho việc mô tả các loại dịch vụ nói chung trong việc kiểm kê. Những
profiles này được gọi là các mô hình dịch vụ, mỗi 1 profile đại diện cho một tập hợp các
đặc điểm thiết kế kết hợp với một loại dịch vụ đã được định nghĩa. Mô hình dịch vụ tạo
cơ sở cho mẫu Service Layers này, trong đó một tập các dịch vụ phù hợp với mô hình sẽ
thiết lập một tầng kiến trúc vật lý của các chức năng liên quan.
Khi áp dụng Service Layers phải đảm bảo rằng các dịch vụ này phải được thiết kế
cùng loại với các đặc điểm cơ bản giống nhau, như là có cùng nguồn gốc từ các mô hình
dịch vụ dùng chung. Các dịch vụ này có thể hình thành từ các vùng logic kiểm kê giống
nhau, có thể được phát triển và quản trị như là một nhóm.
5.3. Application
Các lớp của các dịch vụ thường được xác định ngay trước khi thực thi việc kiểm kê
dịch vụ. Trong quá trình mô hình hóa kế hoạch của dịch vụ kiểm kê, chức năng của các
dịch vụ ứng cử viên sẽ giúp xác định lớp nào của dịch vụ là phù hợp nhất. Bởi vậy, bất kỳ
dịch vụ kiểm kê nào thì đều có các lớp khác nhau; nguyên tắc là có ít nhất 2 lớp dịch vụ.
Các lớp cơ bản nhất là:
- Lớp mô tả đơn mục đích ( khả tri logic)
- Lớp mô tả đa mục đích (logic bất khả tri)
Bằng việc trừu tượng hóa khả tri logic thành một phần trong quá trình kiểm kê; các

logic bất khả tri có thể được định nghĩa và phát triển trong việc hỗ trợ khả năng tái sử
dụng.
5.4. Impacts
Xác định những gì mà mô hình dịch vụ nên hay không nên được sử dụng trong việc
kiểm kê dịch vụ đòi hỏi sự thông thạo các loại logic được sử dụng trong khung kiểm kê.
Bởi vậy, các lớp dịch vụ thường được phát triển ngoài giai đoạn lặp đi lặp lại của quá
trình phân tích hướng dịch vụ, đôi khi còn yêu cầu sửa đổi mô hình của các dịch vụ ứng
viên có sẵn. Do đó, việc dùng mẫu này có thể làm tăng thời gian và công sức cho vấn đề
định nghĩa chi tiết kế hoạch của dịch vụ kiểm kê.
5.5. Relationships
6. Canonical Protocol
6.1. Problem
Mỗi một dịch vụ đều tồn tại như một chương trình phần mềm độc lập. Khi các
chương trình này cần phải trao đổi thông tin, chúng có thể tạo một kết nối sử dụng các
giao thức khác nhau. Khi chương trình được thiết kế để sử dụng giao thức, chúng không
tương thích và không thể trao đổi thông tin mà không cần một chương trình dịch riêng
biệt để trao đổi thông tin lẫn nhau, ví dụ giao thức điểm cầu Protocol Bridging.
Xây dựng dịch vụ với các công nghệ thực thi khác nhau không phải là hiếm, nhưng
cho phép các dịch vụ giao tiếp dựa trên các giao thức khác nhau có thể dẫn tới nhiều hạn
chế. Vấn đề không tương thích có thể làm cho kết nối và khả năng sử dụng lại của dịch vụ
là không thể.
6.2. Solution
Kiến trúc công nghệ được thiết kế để giới hạn khả năng tương tác của các dịch vụ
thông qua các giao thức truyền thông và phiên bản giao thức. Các công nghệ hỗ trợ cho
việc giao tiếp thông tin khác nhau được chuẩn hóa; điều này đảm bảo khả năng tương
thích cho tất cả các công nghệ tạo ra dịch vụ.
6.3. Application
Để đảm bảo tất cả kiến trúc kiểm kê của các dịch vụ được thiết kế để hỗ trợ hiệu quả
khả năng tương tác và có khả năng tái cấu trúc liên tục thì phải đòi hỏi một công nghệ
truyền thông tập trung được chọn một cách cẩn thận.

Một nền tảng chung đáp ứng cho nhu cầu này là nền tảng dịch vụ web bởi vì nó hỗ
trợ rất tốt khả năng vận chuyển và các giao thức truyền tin (ví dụ HTTP, SOAP) một cách
rộng rãi.
6.4. Impacts
Vài điều cần cân nhắc trong khi chuẩn hóa trên một giao thức truyền thông là:
- Tính tin cậy và kỳ hạn – cho dù giao thức nào được chọn, sự tương tác dịch
vụ qua kiến trúc công nghệ đều bị hạn chế bởi giới hạn của nền tảng framework. Bởi
vậy tính tin cậy và kỳ hạn phải được đánh giá cẩn thận.
- Tuổi thọ - nếu có bất kỳ mối quan ngại rằng các nhà cung cấp có thể ngừng
hoặc từ bỏ hỗ trợ thì các rủi ro liên quan cần được tính đến.
- Chi phí – Xây dựng dịch vụ để hỗ trợ giao tiếp có thể bao gồm rất nhiều chi
phí ngầm. Chi phí có thể phát sinh nếu giao thức là một phần của nền tảng độc
quyền đòi hỏi chi phí bản quyền.
6.5. Relationships
7. Canonical Schema
7.1. Problem
Đối với dịch vụ cần gửi hoặc nhận dữ liệu, nó cần phải biết trước chính xác dữ liệu
được tổ chức và cấu trúc thế nào. Ví dụ, một văn bản kinh tế như là hóa đơn, có cấu trúc
dữ liệu riêng của mình; chứa thông tin được tổ chức theo bố cục cụ thể, bao gồm nhiều
loại dữ liệu và các rằng buộc kết hợp lẫn nhau.
Khi các dịch vụ khác nhau được cung cấp bởi các đội dự án khác nhau, mỗi một đội
có thể quyết định cấu trúc của một mô hình dữ liệu theo những cách khác nhau. Khi
những dịch vụ cần trao đổi dữ liệu tại một thời điểm cụ thể, có thể nó sẽ không tương
thích và yêu cầu mô hình dữ liệu phải chuyển đổi.
7.2. Solution
Dùng mô hình Data Model Transformation có thể giải quyết được tình huống này
bằng cách đảm bảo rằng các dịch vụ được thiết kế bằng các lược đồ tương thích ngay từ
thời điểm ban đầu. Điều này đạt được bằng cách áp dụng các tiêu chuẩn dữ liệu thiết kế
các mô hình dữ liệu trong việc thiết kế dịch vụ.
7.3. Application

Canonical Schema thường được áp dụng trong việc thực thi các dịch vụ như Dịch vụ
Web bởi vì lược đồ này cho phép mô hình dữ liệu được xác định bằng cách sử dụng các
ngôn ngữ tiêu chuẩn như XML. Trong trường hợp này, ngôn ngữ mô tả XML lưu trữ dữ
liệu và thông tin cho tất cả các dịch vụ khác nhau.
7.4. Impacts
Trong các tổ chức, doanh nghiệp lớn; phạm vi của chuẩn hóa mô hình dữ liệu có thể
cần phải được giới hạn để dễ dàng quản lý hơn. Trong thực tế, điều này được khuyến
khích và nên được cân nhắc để áp dụng cho Domain Inventory và Enterprise Inventory.
7.5. Relationships
PHẦN II: FOUNDATIONAL SERVICE PATTERN
Chương 11: Foundational Service Patterns bao gồm 5 phần:
 Functional Decomposition
 Service Encapsulation
 Agnostic Context
 Non-Agnostic Context
 Agnostic Capability
1. Functional Decomposition
1.1. Problem
Hầu hết các nhiệm vụ kinh tế hoặc quy trình kinh doanh đều đòi hỏi phải tự động
hóa. Một giải pháp được dùng để giải quyết vấn đề tự động hóa các vấn đề đã được xây
dựng thành một ứng dụng. Trước khi ra đời tính toán phân tán, các ứng dụng tùy chỉnh đã
được thiết kế.
Đối với nhiều tổ chức, việc tự động hóa các nhiệm vụ đặt ra là những thách thức
đáng kể liên quan đến việc mở rộng và kết nối giữa các dịch vụ khác nhau. Hơn nữa, hệ
thống có thể sẽ trở nên cồng kềnh và tốn kém để duy trì và khi có quá nhiều thay đổi sẽ
làm cho những ứng dụng này ảnh hưởng đến sự phát triển tổng thể của toàn tổ chức.
1.2. Solution
Chức năng phân rã (Functional Decomposition) về cơ bản là một ứng dụng của sự
tách biệt của thuyết liên quan. Nguyên lý thiết lập kỹ thuật này thúc đẩy sự phân rã của
một vấn đề lớn thành các vấn đề nhỏ hơn – gọi là các kịch bản (concerns) tương ứng là

các units của giải pháp logic được xây dựng.
1.3. Application
Như đã nói, chức năng phân rã - Function Decomposition – về cơ bản được thực
hiện bằng cách chia nhỏ thành các kịch bản riêng biệt trong kiến trúc hướng dịch vụ. Điều
khác biệt chính giữa hướng dịch vụ và các phương pháp thiết kế phân phối khác là cách
thức mà sự phân tách được thực hiện và làm thế nào để các units của giải pháp logic được
xác định.
Do vậy, mẫu này không áp dụng một cách độc lập. Nó miêu tả thời điểm ban đầu
của quá trình phân rã chức năng và tiếp tục qua quá trình chia các logic riêng biệt vào
trong dịch vụ.
1.4. Impacts
Phân tán các units của giải pháp logic yêu cầu đến sự kết nối liên thông giữa các
dịch vụ, an ninh, độ tin cậy và khả năng duy trì để đảm bảo rằng chuỗi các hành động
theo thời gian vẫn còn đầy đủ và đáng tin cậy. Một môi trường thường sẽ chứa đựng một
số lượng lớn các chương trình phần mềm nhỏ hơn do đó có nhiều phức tạp trong việc
quản lý thiết kế và có nhiều thách thức trong việc kết hợp các phần mềm thành một khối
duy nhất.
1.5. Relationships
2. Service Encapsulation
2.1. Problem
Một tập hợp các chương trình phần mềm liên quan bị phân rã thành các giải pháp
logic vẫn có thể tiếp tục tồn tại trong một khung ứng dụng bị quản lý. Trong thực tế, rất
nhiều hệ thống phân tán đều được xây dựng theo cách này. Việc quyết định phân vùng
các giải pháp logic thành các đơn vị units nhỏ hơn thường được cân nhắc như sau:
- Tăng khả năng mở rộng bằng cách phân tách các bộ phận của hệ thống.
- Cải thiện bảo mật bằng cách cách lý các phần cụ thể của hệ thống với quyền
truy cập đặc biệt.
- Tăng độ tin cậy bằng cách phân phối các phần quan trọng của hệ thống trên
nhiều máy chủ vật lý.
- Tăng khả năng tái sử dụng trong khung ranh giới của hệ thống.

2.2. Solution
Giải pháp logic phù hợp cho việc phân loại các nguồn lực của doanh nghiệp có thể
được đóng gói lại và cung cấp ra như một dịch vụ. Điều này về cơ bản có nghĩa là ngay
chính bản thân logic có thể hình thành cơ sở cho một dịch vụ mới, hoặc là logic có thể
được đóng gói bởi một dịch vụ đã tồn tại. Kết quả dẫn tới một môi trường mà tất cả các
dịch vụ sẽ được chia sẻ.