ĐẠ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 [...]... 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.1 Vấ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ử... 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ể... 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... 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. .. 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... đề 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. .. 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... 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... 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 II 1 QLHTTT K2 Service Implementation Patterns 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ề... đượ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 . ĐẠ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. 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. 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