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

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.

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. [...]... đầu tư Để đạt được những lợi ích này dẫn đến vấn đề phải thiết kế bổ sung thêm và vấn đề hiệu suất của dịch vụ Vấn đề quản trị của dịch vụ bất khả tri cũng là nhiều hơn đáng kể so với các phương pháp luận tương ứng Ngoài ra việc quản trị kiến trúc tổng thể cũng bị ảnh hưởng như số lượng của các dịch vụ bất khả tri trong việc kiểm kê sẽ bị tăng lên 3.5 Relationships 4 Non-Agnostic Context 4.1 Problem . 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. 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. 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