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
GIỚI THIỆU CHUNG VỀ DESIGN PATTERNS ......................................................................... 5
PHẦN I: FOUNDATIONAL INVENTORY PATTERNS ............................................................. 6
1.
2.
3.
4.
5.
Enterprise Inventory ............................................................................................................. 6
1.1.
Problem ......................................................................................................................... 6
1.2.
Solution ......................................................................................................................... 7
1.3.
Application .................................................................................................................... 7
1.4.
Impacts .......................................................................................................................... 8
1.5.
Relationships ................................................................................................................. 8
Domain Inventory ................................................................................................................. 8
2.1.
Problem ......................................................................................................................... 8
2.2.
Solution ......................................................................................................................... 9
2.3.
Application .................................................................................................................. 10
2.4.
Impacts ........................................................................................................................ 10
2.5.
Relationships ............................................................................................................... 11
Service Normalization ........................................................................................................ 11
3.1.
Problem ....................................................................................................................... 11
3.2.
Solution ....................................................................................................................... 12
3.3.
Application .................................................................................................................. 12
3.4.
Impacts ........................................................................................................................ 13
3.5.
Relationships ............................................................................................................... 13
Logic Centralization ........................................................................................................... 13
4.1.
Problem ....................................................................................................................... 13
4.2.
Solution ....................................................................................................................... 14
4.3.
Application .................................................................................................................. 14
4.4.
Impacts ........................................................................................................................ 14
4.5.
Relationships ............................................................................................................... 15
Service Layers .................................................................................................................... 15
5.1.
Problem ....................................................................................................................... 15
5.2.
Solution ....................................................................................................................... 16
5.3.
Application .................................................................................................................. 16
5.4.
Impacts ........................................................................................................................ 17
5.5.
6.
7.
Relationships ............................................................................................................... 17
Canonical Protocol ............................................................................................................. 17
6.1.
Problem ....................................................................................................................... 17
6.2.
Solution ....................................................................................................................... 18
6.3.
Application .................................................................................................................. 18
6.4.
Impacts ........................................................................................................................ 19
6.5.
Relationships ............................................................................................................... 20
Canonical Schema .............................................................................................................. 20
7.1.
Problem ....................................................................................................................... 20
7.2.
Solution ....................................................................................................................... 20
7.3.
Application .................................................................................................................. 21
7.4.
Impacts ........................................................................................................................ 21
7.5.
Relationships ............................................................................................................... 21
PHẦN II: FOUNDATIONAL SERVICE PATTERN .................................................................. 22
1.
2.
3.
Functional Decomposition.................................................................................................. 22
1.1.
Problem ....................................................................................................................... 22
1.2.
Solution ....................................................................................................................... 22
1.3.
Application .................................................................................................................. 23
1.4.
Impacts ........................................................................................................................ 23
1.5.
Relationships ............................................................................................................... 23
Service Encapsulation......................................................................................................... 24
2.1.
Problem ....................................................................................................................... 24
2.2.
Solution ....................................................................................................................... 24
2.3.
Application .................................................................................................................. 25
2.4.
Impacts ........................................................................................................................ 25
2.5.
Relationships ............................................................................................................... 25
Agnostic Context ................................................................................................................ 25
3.1.
Problem ....................................................................................................................... 25
3.2.
Solution ....................................................................................................................... 26
3.3.
Application .................................................................................................................. 26
3.4.
Impacts ........................................................................................................................ 27
3.5.
Relationships ............................................................................................................... 27
4.
5.
Non-Agnostic Context ........................................................................................................ 27
4.1.
Problem ....................................................................................................................... 27
4.2.
Solution ....................................................................................................................... 28
4.3.
Application .................................................................................................................. 28
4.4.
Impacts ........................................................................................................................ 29
4.5.
Relationships ............................................................................................................... 29
Agnostic Capability ............................................................................................................ 29
5.1.
Problem ....................................................................................................................... 29
5.2.
Solution ....................................................................................................................... 30
5.3.
Application .................................................................................................................. 31
5.4.
Impacts ........................................................................................................................ 31
5.5.
Relationships ............................................................................................................... 31
PHẦN III: COMPOSITION IMPLEMENTATION PATTERNS ................................................ 32
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:
1.
Enterprise Inventory
Domain Inventory
Service Normalization
Logic Centralization
Service Layers
Canonical Protocol
Canonical Schema
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 “meetin-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.
4.
Relationships
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.
5.
Relationships
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.
6.
Relationships
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.
7.
Relationships
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ừ
- Xem thêm -