huyen14_10
New Member
Download miễn phí Đồ án Ứng dụng kiến trúc hướng dịch vụ và công nghệ dịch vụ mạng trong xây dựng phần mềm
Mục lục
Danh mục từ viết tắt 1
Danh mục hình vẽ 3
Mục lục 5
MỞ ĐẦU 7
CHƯƠNG I. LÝ THUYẾT KIẾN TRÚC HƯỚNG DỊCH VỤ 9
1. Kiến trúc hướng dịch vụ - xu hướng mới trong công nghệ thông tin 9
2. Kiến trúc hướng dịch vụ - một giải pháp 11
2.1. Sự tiến hóa của lý thuyết phát triển phần mềm. 11
2.2 Kiến trúc hướng dịch vụ 14
2.3. Dịch vụ và thành phần 22
3. Thiết kế theo kiến trúc hướng dịch vụ 26
3.1. Các nguyên tắc trong thiết kế hướng dịch vụ 26
3.2. Các quyết định thiết kế và kiến trúc trong kiến trúc hướng dịch vụ 27
3.3. Các mức độ chấp nhận kiến trúc hướng dịch vụ 29
3.4. Các bước trong quy trình phát triển phần mềm theo định hướng dịch vụ 31
3.5. Vòng đời phát triển của dịch vụ 35
4. Các công nghệ hướng dịch vụ 36
4.1. Sun JINI 36
4.2. Openwings 37
4.3. Dịch vụ mạng 40
4.4. Enterprise Service Bus (ESB) 40
5. Kết luận chương 42
CHƯƠNG II. CÔNG NGHỆ DỊCH VỤ MẠNG 44
1. Kiến trúc dịch vụ mạng 45
2. Các chuẩn cho dịch vụ mạng 46
2.1. Ngôn ngữ mô tả dịch vụ mạng WSDL. 46
2.2. Giao thức truy cập đối tượng đơn giản SOAP. 50
2.3. Đặc tả mô tả và tích hợp tìm kiếm UDDI 55
3. Các kiểu liên kết trong dịch vụ mạng. 60
3.1 Liên kết tĩnh 60
3.2. Liên kết động trong thời gian xây dựng. 61
3.3. Liên kết động trong thời gian chạy. 62
5. Xây dựng dịch vụ mạng 64
5.1. Vòng đời của dịch vụ mạng 64
5.2. Bảo mật trong dịch vụ mạng 64
5.3. Tính liên thông giữa các dịch vụ mạng 70
6. Kết luận chương 70
Chương III: CÀI ĐẶT ỨNG DỤNG 72
1. Nhắc lại các yêu cầu của một hệ thống xây dựng theo kiến trúc hướng dịch vụ 72
2. Mô tả bài toán 73
3. Cài đặt bài toán 75
3.1. Thành phần cung cấp dịch vụ 75
3.2. Thành phần sử dụng dịch vụ. 80
3.3 Thành phần đăng ký dịch vụ. 81
4. Các kết quả đạt được 82
5. Đánh giá về ứng dụng 85
5.1. Ưu điểm 85
5.2. Các điểm hạn chế 86
KẾT LUẬN 87
Danh mục tài liệu tham khảo 89
Kiến trúc phần mềm của một hệ thống mô tả các thành phần của hệ thống và cách thức các thành phần này tương tác với nhau; tương tác giữa các thành phần được gọi là “liên kết” (connector) [1]. Trong một hệ thống phần mềm có quy mô lớn và phức tạp thì kiến trúc của hệ thống giữ một vị trí quan trọng trong việc hiểu hệ thống, việc tổ chức phát triển và tăng cường tái sử dụng.
Ngày nay, khi mà độ phức tạp của phần mềm ngày càng tăng thì các kiến trúc phần mềm truyền thống dường như đang tiến tới giới hạn khả năng giải quyết vấn đề của chúng; trong khi đó, các tổ chức công nghệ thông tin vẫn phải đáp ứng được những yêu cầu đặt ra như: yêu cầu được đáp ứng nhanh, yêu cầu giảm giá thành, yêu cầu về khả năng thu hút và tích hợp với các đối tác mới v.v…, và đặc biệt là sự thay đổi nhanh chóng của các công nghệ.
Trong suốt bốn thập kỷ qua, thực tế phát triển phần mềm đã trải qua nhiều phương pháp phát triển khác nhau. Mỗi phương pháp mới xuất hiện đều hướng tới mục tiêu quản lý độ phức tạp ngày càng tăng của phần mềm bằng cách đưa ra các cấu trúc có mức độ đóng gói tăng dần: từ hàm (function), lớp (class), tới thành phần (component); các cấu trúc này được xem như những phần mềm “hộp đen”, chúng che giấu cài đặt nhờ việc kiểm soát việc truy cập tới hành vi và dữ liệu của mình thông qua một giao diện tường minh. Ở mức độ đóng gói thấp, chúng ta sử dụng đối tượng để che giấu dữ liệu, ở mức độ đóng gói cao hơn, chúng ta sử dụng các thành phần để thực hiện việc này. Việc sử dụng đối tượng để che giấu thông tin hoạt động tốt với các hệ thống nhỏ, nó cho phép tạo ra các cấu trúc phần mềm phản ánh được các đối tượng trong thế giới thực. Vấn đề nảy sinh khi chúng ta cố gắng nhóm một số lượng lớn các đối tượng cùng với nhau. Mặc dù truy cập tới các đối tượng được điều khiển thông qua giao diện của chúng, mức độ đóng gói thấp của các đối tượng vẫn làm cho sự phụ thuộc giữa chúng trở nên khó kiểm soát trong một hệ thống tương đối lớn. Khái niệm thành phần được phát triển giúp quản lý các hệ thống lớn tốt hơn: một thành phần được định nghĩa là một nhóm các đối tượng hoạt động cùng nhau để thực hiện một chức năng của hệ thống. Các công nghệ như EJB (Enterprise Java Bean), .NET, CORBA (Common Object Request Broker Architecture) tỏ ra rất hiệu quả trong việc cài đặt các thành phần. Phương pháp phát triển phần mềm dựa thành phần (Component-based Development - CBD) cho phép những nhà phát triển tạo ra các hệ thống phức tạp hơn, có chất lượng cao hơn và nhanh hơn bất kỳ phương pháp phát triển phần mềm nào khác trước đó. Nhưng khi chúng ta xây dựng các thành phần trên các ngôn ngữ khác nhau, hay thậm chí là trên những nền tảng khác nhau (các thành phần không đồng nhất) cho một hệ thống thì cần có khả năng tích hợp chúng lại với nhau, nhưng một vấn đề nảy sinh: các thành phần dùng công nghệ EJB đòi hỏi việc triệu gọi cách thông qua RMI (Remote Method Invocation – Triệu gọi cách từ xa), trong khi đó, các thành phần dùng công nghệ CORBA thì lại dùng IIOP (Internet Inter-ORB Protocol), hơn nữa, khi các thành phần được định vị qua Internet, các thông điệp giữa chúng có thể bị chặn bởi tường lửa. Ngay cả khi không gặp phải những vấn đề trên thì để sử dụng được thành phần, chúng ta vẫn cần biết vị trí chính xác và giao diện của thành phần để nếu giao diện thay đổi, chúng ta cũng phải thay đổi cách gọi đến chúng. Vì số lượng người dùng thành phần có thể rất lớn nên việc này sẽ tạo ra các phụ thuộc có quy mô lớn, rất khó kiểm soát. Vậy làm thế nào chúng ta có thế giải quyết vấn đề này?
Kiến trúc hướng dịch vụ (Service-oriented architecture, viết tắt là SOA) đang được phát triển và được xem như một bước đột phá tiếp theo trong kiến trúc phần mềm giúp giải quyết vấn đề “khủng hoảng” phần mềm. Sự xuất hiện của công nghệ dịch vụ mạng (Web services) trong vài năm trở lại đây đã tạo ra sự quan tâm mạnh mẽ tới kiến trúc này bởi Web service hiện thực hóa việc phát triển hệ thống theo kiến trúc hướng dịch vụ một cách tự nhiên và dễ dàng hơn. Web service và kiến trúc hướng dịch vụ đang thay đổi một cách căn bản cách thức xây dựng các hệ thống nội bộ (các hệ thống thông tin hỗ trợ trong các tổ chức) và cách các hệ thống nội bộ tương tác với các hệ thống bên ngoài mà chưa một kiến trúc nào trước đó có thể thực hiện được. Thuật ngữ “dịch vụ” trong kiến trúc hướng dịch vụ cũng không phải là khái niệm mới: các ứng dụng khách/chủ (client/server) trong những năm 90 đã sử dụng “dịch vụ” để chỉ khả năng thực hiện lời gọi cách từ xa. Kiến trúc hướng dịch vụ đặc biệt đề cao tính liên thông (interoperability) và sự trong suốt về vị trí của các dịch vụ, nói tới dịch vụ và kiến trúc hướng dịch vụ là nói về việc thiết kế và xây dựng các hệ thống sử dụng các thành phần phần mềm không đồng nhất.
Sử dụng công nghệ dịch vụ mạng và kiến trúc hướng dịch vụ đem lại các lợi ích sau:
• Mở rộng các lựa chọn về mặt công nghệ.
• Các hệ thống được xây dựng linh hoạt và nhạy bén hơn.
• Giảm thời gian phát triển.
• Giảm chi phí bảo trì.
Trong đồ án tốt nghiệp này, người viết đồ án (NVĐA) sẽ trình bày về lý thuyết của kiến trúc hướng dịch vụ và công nghệ dịch vụ mạng, tại sao những công nghệ này có thể xóa bỏ những rào cản công nghệ để tạo ra các hệ thống phần mềm có tính tích hợp cao, và tại sao lựa chọn công nghệ dịch vụ mạng là thích hợp nhất cho việc cài đặt ứng dụng theo kiến trúc hướng dịch vụ cũng như lợi ích của những ứng dụng này khi xây dựng theo kiến trúc hướng dịch vụ.
Do Drive thay đổi chính sách, nên một số link cũ yêu cầu duyệt download. các bạn chỉ cần làm theo hướng dẫn.
Password giải nén nếu cần: ket-noi.com | Bấm trực tiếp vào Link để tải:
Ai cần download tài liệu gì mà không tìm thấy ở đây, thì đăng yêu cầu down tại đây nhé:
Nhận download tài liệu miễn phí
Mục lục
Danh mục từ viết tắt 1
Danh mục hình vẽ 3
Mục lục 5
MỞ ĐẦU 7
CHƯƠNG I. LÝ THUYẾT KIẾN TRÚC HƯỚNG DỊCH VỤ 9
1. Kiến trúc hướng dịch vụ - xu hướng mới trong công nghệ thông tin 9
2. Kiến trúc hướng dịch vụ - một giải pháp 11
2.1. Sự tiến hóa của lý thuyết phát triển phần mềm. 11
2.2 Kiến trúc hướng dịch vụ 14
2.3. Dịch vụ và thành phần 22
3. Thiết kế theo kiến trúc hướng dịch vụ 26
3.1. Các nguyên tắc trong thiết kế hướng dịch vụ 26
3.2. Các quyết định thiết kế và kiến trúc trong kiến trúc hướng dịch vụ 27
3.3. Các mức độ chấp nhận kiến trúc hướng dịch vụ 29
3.4. Các bước trong quy trình phát triển phần mềm theo định hướng dịch vụ 31
3.5. Vòng đời phát triển của dịch vụ 35
4. Các công nghệ hướng dịch vụ 36
4.1. Sun JINI 36
4.2. Openwings 37
4.3. Dịch vụ mạng 40
4.4. Enterprise Service Bus (ESB) 40
5. Kết luận chương 42
CHƯƠNG II. CÔNG NGHỆ DỊCH VỤ MẠNG 44
1. Kiến trúc dịch vụ mạng 45
2. Các chuẩn cho dịch vụ mạng 46
2.1. Ngôn ngữ mô tả dịch vụ mạng WSDL. 46
2.2. Giao thức truy cập đối tượng đơn giản SOAP. 50
2.3. Đặc tả mô tả và tích hợp tìm kiếm UDDI 55
3. Các kiểu liên kết trong dịch vụ mạng. 60
3.1 Liên kết tĩnh 60
3.2. Liên kết động trong thời gian xây dựng. 61
3.3. Liên kết động trong thời gian chạy. 62
5. Xây dựng dịch vụ mạng 64
5.1. Vòng đời của dịch vụ mạng 64
5.2. Bảo mật trong dịch vụ mạng 64
5.3. Tính liên thông giữa các dịch vụ mạng 70
6. Kết luận chương 70
Chương III: CÀI ĐẶT ỨNG DỤNG 72
1. Nhắc lại các yêu cầu của một hệ thống xây dựng theo kiến trúc hướng dịch vụ 72
2. Mô tả bài toán 73
3. Cài đặt bài toán 75
3.1. Thành phần cung cấp dịch vụ 75
3.2. Thành phần sử dụng dịch vụ. 80
3.3 Thành phần đăng ký dịch vụ. 81
4. Các kết quả đạt được 82
5. Đánh giá về ứng dụng 85
5.1. Ưu điểm 85
5.2. Các điểm hạn chế 86
KẾT LUẬN 87
Danh mục tài liệu tham khảo 89
Kiến trúc phần mềm của một hệ thống mô tả các thành phần của hệ thống và cách thức các thành phần này tương tác với nhau; tương tác giữa các thành phần được gọi là “liên kết” (connector) [1]. Trong một hệ thống phần mềm có quy mô lớn và phức tạp thì kiến trúc của hệ thống giữ một vị trí quan trọng trong việc hiểu hệ thống, việc tổ chức phát triển và tăng cường tái sử dụng.
Ngày nay, khi mà độ phức tạp của phần mềm ngày càng tăng thì các kiến trúc phần mềm truyền thống dường như đang tiến tới giới hạn khả năng giải quyết vấn đề của chúng; trong khi đó, các tổ chức công nghệ thông tin vẫn phải đáp ứng được những yêu cầu đặt ra như: yêu cầu được đáp ứng nhanh, yêu cầu giảm giá thành, yêu cầu về khả năng thu hút và tích hợp với các đối tác mới v.v…, và đặc biệt là sự thay đổi nhanh chóng của các công nghệ.
Trong suốt bốn thập kỷ qua, thực tế phát triển phần mềm đã trải qua nhiều phương pháp phát triển khác nhau. Mỗi phương pháp mới xuất hiện đều hướng tới mục tiêu quản lý độ phức tạp ngày càng tăng của phần mềm bằng cách đưa ra các cấu trúc có mức độ đóng gói tăng dần: từ hàm (function), lớp (class), tới thành phần (component); các cấu trúc này được xem như những phần mềm “hộp đen”, chúng che giấu cài đặt nhờ việc kiểm soát việc truy cập tới hành vi và dữ liệu của mình thông qua một giao diện tường minh. Ở mức độ đóng gói thấp, chúng ta sử dụng đối tượng để che giấu dữ liệu, ở mức độ đóng gói cao hơn, chúng ta sử dụng các thành phần để thực hiện việc này. Việc sử dụng đối tượng để che giấu thông tin hoạt động tốt với các hệ thống nhỏ, nó cho phép tạo ra các cấu trúc phần mềm phản ánh được các đối tượng trong thế giới thực. Vấn đề nảy sinh khi chúng ta cố gắng nhóm một số lượng lớn các đối tượng cùng với nhau. Mặc dù truy cập tới các đối tượng được điều khiển thông qua giao diện của chúng, mức độ đóng gói thấp của các đối tượng vẫn làm cho sự phụ thuộc giữa chúng trở nên khó kiểm soát trong một hệ thống tương đối lớn. Khái niệm thành phần được phát triển giúp quản lý các hệ thống lớn tốt hơn: một thành phần được định nghĩa là một nhóm các đối tượng hoạt động cùng nhau để thực hiện một chức năng của hệ thống. Các công nghệ như EJB (Enterprise Java Bean), .NET, CORBA (Common Object Request Broker Architecture) tỏ ra rất hiệu quả trong việc cài đặt các thành phần. Phương pháp phát triển phần mềm dựa thành phần (Component-based Development - CBD) cho phép những nhà phát triển tạo ra các hệ thống phức tạp hơn, có chất lượng cao hơn và nhanh hơn bất kỳ phương pháp phát triển phần mềm nào khác trước đó. Nhưng khi chúng ta xây dựng các thành phần trên các ngôn ngữ khác nhau, hay thậm chí là trên những nền tảng khác nhau (các thành phần không đồng nhất) cho một hệ thống thì cần có khả năng tích hợp chúng lại với nhau, nhưng một vấn đề nảy sinh: các thành phần dùng công nghệ EJB đòi hỏi việc triệu gọi cách thông qua RMI (Remote Method Invocation – Triệu gọi cách từ xa), trong khi đó, các thành phần dùng công nghệ CORBA thì lại dùng IIOP (Internet Inter-ORB Protocol), hơn nữa, khi các thành phần được định vị qua Internet, các thông điệp giữa chúng có thể bị chặn bởi tường lửa. Ngay cả khi không gặp phải những vấn đề trên thì để sử dụng được thành phần, chúng ta vẫn cần biết vị trí chính xác và giao diện của thành phần để nếu giao diện thay đổi, chúng ta cũng phải thay đổi cách gọi đến chúng. Vì số lượng người dùng thành phần có thể rất lớn nên việc này sẽ tạo ra các phụ thuộc có quy mô lớn, rất khó kiểm soát. Vậy làm thế nào chúng ta có thế giải quyết vấn đề này?
Kiến trúc hướng dịch vụ (Service-oriented architecture, viết tắt là SOA) đang được phát triển và được xem như một bước đột phá tiếp theo trong kiến trúc phần mềm giúp giải quyết vấn đề “khủng hoảng” phần mềm. Sự xuất hiện của công nghệ dịch vụ mạng (Web services) trong vài năm trở lại đây đã tạo ra sự quan tâm mạnh mẽ tới kiến trúc này bởi Web service hiện thực hóa việc phát triển hệ thống theo kiến trúc hướng dịch vụ một cách tự nhiên và dễ dàng hơn. Web service và kiến trúc hướng dịch vụ đang thay đổi một cách căn bản cách thức xây dựng các hệ thống nội bộ (các hệ thống thông tin hỗ trợ trong các tổ chức) và cách các hệ thống nội bộ tương tác với các hệ thống bên ngoài mà chưa một kiến trúc nào trước đó có thể thực hiện được. Thuật ngữ “dịch vụ” trong kiến trúc hướng dịch vụ cũng không phải là khái niệm mới: các ứng dụng khách/chủ (client/server) trong những năm 90 đã sử dụng “dịch vụ” để chỉ khả năng thực hiện lời gọi cách từ xa. Kiến trúc hướng dịch vụ đặc biệt đề cao tính liên thông (interoperability) và sự trong suốt về vị trí của các dịch vụ, nói tới dịch vụ và kiến trúc hướng dịch vụ là nói về việc thiết kế và xây dựng các hệ thống sử dụng các thành phần phần mềm không đồng nhất.
Sử dụng công nghệ dịch vụ mạng và kiến trúc hướng dịch vụ đem lại các lợi ích sau:
• Mở rộng các lựa chọn về mặt công nghệ.
• Các hệ thống được xây dựng linh hoạt và nhạy bén hơn.
• Giảm thời gian phát triển.
• Giảm chi phí bảo trì.
Trong đồ án tốt nghiệp này, người viết đồ án (NVĐA) sẽ trình bày về lý thuyết của kiến trúc hướng dịch vụ và công nghệ dịch vụ mạng, tại sao những công nghệ này có thể xóa bỏ những rào cản công nghệ để tạo ra các hệ thống phần mềm có tính tích hợp cao, và tại sao lựa chọn công nghệ dịch vụ mạng là thích hợp nhất cho việc cài đặt ứng dụng theo kiến trúc hướng dịch vụ cũng như lợi ích của những ứng dụng này khi xây dựng theo kiến trúc hướng dịch vụ.
Do Drive thay đổi chính sách, nên một số link cũ yêu cầu duyệt download. các bạn chỉ cần làm theo hướng dẫn.
Password giải nén nếu cần: ket-noi.com | Bấm trực tiếp vào Link để tải:
You must be registered for see links
Ai cần download tài liệu gì mà không tìm thấy ở đây, thì đăng yêu cầu down tại đây nhé:
Nhận download tài liệu miễn phí