Tiểu luận: Dịch vụ phần mềm và tích hợp hệ thống

Chia sẻ: Phạm Anh Thằng | Ngày: | Loại File: DOCX | Số trang:50

Thêm vào BST

Báo xấu

84
lượt xem 17
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Tiểu luận: Dịch vụ phần mềm và tích hợp hệ thống gồm 3 phần. Nội dung tiểu luận giới thiệu chung về design patterns, foundational inventory patterns, foundational service pattern và composition implementation patterns.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Tiểu luận: Dịch vụ phần mềm và tí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 DICH VỤ PHÂN MÊM VÀ TICH HỢP HỆ THÔNG ̣ ̀ ̀ ́ ́ Giảng viên hướng dẫn: TS. Vũ Thị 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
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