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

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

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

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

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

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

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.

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à

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