Đề tài Kiến trúc hướng dịch vụ và ứng dụng (service-Oriented-architecture)

MỤC LỤC

MỞ ĐẦU 1

CHƯƠNG 1: TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ (SERVICE-ORIENTED-ARCHITECTURE) 2

1.1. Kiến trúc phần mềm hiện nay 2

1.1.1. Một số kiến trúc phần mềm phân tán hiện nay 2

1.1.2. Vấn đề phát sinh, nguyên nhân và giải pháp 3

1.2. Kiến trúc hướng dịch vụ - SOA 5

1.2.1. Khái niệm 5

1.2.2. Nguyên lý SOA 7

1.2.3. Tính chất của SOA 8

1.2.4. Lợi ích của SOA 10

1.2.5. Ưu nhược điểm của SOA 11

CHƯƠNG 2: PHÁT TRIỂN PHẦN MỀM DỰA VÀO SOA 12

2.1. Mô hình hoạt động và kiến trúc chi tiết của hệ thống 12

2.1.1. Mô hình tổng thể của SOA 12

2.1.2. Mô hình giao tiếp bằng thông điệp (message) trong SOA 13

2.1.3. Kiến trúc phân tầng chi tiết 14

2.2. SOA và ứng dụng Web Service 16

2.2.1. Giới thiệu về Web service 16

2.2.2. SOA và Web service trong vấn đề tích hợp hệ thống 16

2.2.3. Cấu trúc và chi tiết các thành phần của Web service 18

2.3. Qui trình xây dựng hệ thống SOA 26

2.3.1. Thách thức khi xây dựng hệ thống 26

2.3.2. Vòng đời của hệ thống 28

2.3.3. Các pha cơ bản xây dựng hệ thống SOA 29

2.3.4. Các chiến lược xây dựng hệ thống 31

CHƯƠNG 3: KẾT QUẢ VÀ THẢO LUẬN 36

3.1. Chương trình demo 36

3.1.1. Chức năng chính của chương trình: 36

3.1.2. Xây dựng chương trình 36

3.2. Đánh giá chương trình 41

KẾT LUẬN 42

TÀI LIỆU THAM KHẢO 43

 

 

doc48 trang | Chia sẻ: oanh_nt | Lượt xem: 7975 | Lượt tải: 1download
Bạn đang xem trước 20 trang tài liệu Đề tài Kiến trúc hướng dịch vụ và ứng dụng (service-Oriented-architecture), để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
ịnh dạng đúng như trong phần mô tả dịch vụ. Mối ràng buộc duy nhất giữa bên cung cấp và bên sử dụng là bản hợp đồng được cung cấp bởi registry trung gian. Mối ràng buộc này là ràng buộc trong thời gian chạy. Tất cả thông tin cần thiết về dịch vụ được lấy về và sử dụng trong khi chạy. Vậy với SOA, bên sử dụng dịch vụ không cần biết định dạng của thông điệp yêu cầu và thông điệp trả về, cũng như địa chỉ dịch vụ cho đến khi cần. 1.2.3.5. Khả năng tự hồi phục Với kích cỡ và độ phức tạp của những hệ thống phân tán ngày nay, khả năng phục hồi của một hệ thống sau khi bị sự cố là một yếu tố rất quan trọng. Một hệ thống tự phục hồi là hệ thống có khả năng tự phục hồi sau khi lỗi mà không cần sự can thiệp của con người. Độ tin cậy là mức độ đo khả năng của một hệ thống xử lý tốt như thế nào trong tình trạng hỗn loạn. Trong SOA, các dịch vụ luôn có thể hoạt động hay ngừng hoạt động bất cứ lúc nào, nhất là đối với những áp dụng tổng hợp từ nhiều dịch vụ của nhiều tổ chức khác nhau. Độ tin cậy phụ thuộc vào khả năng phục hồi của phần cứng sau khi bị lỗi. Hạ tầng mạng phải cho phép các kết nối động từ nhiều hệ thống khác nhau kết nối đến trong khi chạy. Một khía cạnh khác ảnh hưởng đến độ tin cậy là kiến trúc mà dựa trên đó những ứng dụng được xây dựng. Một kiến trúc hỗ trợ kết nối và thực thi động sẽ có khả năng tự phục hồi hơn một hệ thống không hỗ trợ những tính năng trên. Ngoài ra, những hệ thống dựa trên dịch vụ yêu cầu tách biệt giữa giao diện và cài đặt, nên có thể có nhiều cài đặt khác nhau cho cùng một giao diện. Nếu một thể hiện service nào đó không hoạt động thì một thể hiện khác vẫn có thể hoàn tất giao dịch cho khách hàng mà không bị ảnh hưởng gì. Khả năng này chỉ có được khi client tương tác với giao diện của dịch vụ chứ không tương tác trực tiếp cài đặt của dịch vụ. Đây là một trong những tính chất cơ bản của hệ thống hướng dịch vụ (SOA). 1.2.4. Lợi ích của SOA Sử dụng mô hình SOA trong việc thiết kế hệ thống mang lại rất nhiều lợi ích về cả mặt kinh tế và kỹ thuật. Về mặt kinh tế: Doanh nghiệp có điều kiện tập trung thời gian để tìm kiếm các giải pháp cho các bài toán liên quan đến kinh tế. Thúc đẩy khả năng phát triển của hệ thống hiện có cũng như khả năng mở rộng của hệ thống trong tương lai. Lợi ích về mặt kỹ thuật: Độc lập hệ thống : những service không phụ thuộc vào hệ thống và mạng cụ thể. Có khả năng tái sử dụng. Khả năng hồi đáp thích nghi tốt và nhanh hơn để đáp ứng với sự thay đổi về yêu cầu giao dịch. Cho phép dễ dàng triển khai chương trình, môi trường chạy và quản lý service dễ dàng hơn. Những sự xác nhận và chứng minh của Service consumer về những tính năng security dựa trên giao tiếp Service tốt hơn cơ chế kết nối chặt chẽ. 1.2.5. Ưu nhược điểm của SOA SOA có thể được coi là một kiến trúc ưu việt trong thiết kế và xây dựng hệ thống phần mềm cho doanh nghiệp bởi: Hệ thống uyển chuyển và lâu dài thuận tiện cho việc chỉnh sửa, nâng cấp hoặc mở rộng hệ thống. Dễ dàng và nhanh chóng tạo ra các tiến trình nghiệp vụ từ các service đã có. Khả năng tương tác của các service. Tuy nhiên, bên cạnh những ưu điểm SOA vẫn tồn tại một số yếu điểm như sau: Hệ thống phức tạp. Khó miêu tả dữ liệu không cấu trúc trong header của message. Đặc biệt, khi xây dựng ứng dụng tổng hợp từ nhiều dịch vụ với tính tái sử dụng cao thì vấn đề bảo mật như: xác thực, phân quyền, bí mật và toàn vẹn dữ liệu, bảo vệ quyền riêng tư… trở thành một bài toán hết sức phức tạp và đòi hỏi giải quyết bằng những hướng tiếp cận bảo mật hoàn toàn mới so với các phương pháp bảo mật truyền thống. Trên đây là những trình bày tổng quan và đặc trưng nhất của SOA. Vậy SOA hoạt động như thế nào? Bằng cách nào để triển khai nguyên lý SOA vào hệ thống phần mềm thực tế và qui trình xây dựng hệ thống ra sao? Phần tiếp theo sẽ đi sâu hơn về SOA và trả lời các câu hỏi đó. CHƯƠNG 2: PHÁT TRIỂN PHẦN MỀM DỰA VÀO SOA 2.1. Mô hình hoạt động và kiến trúc chi tiết của hệ thống 2.1.1. Mô hình tổng thể của SOA Hình 2.1: Mô hình tổng quan của SOA Service Provider: Cung cấp các service phục vụ cho một nhu cầu nào đó. User (service consumer) không cần quan tâm đến vị trí thực sự mà service họ cần sử dụng đang hoạt động. Họ chỉ cần quan tâm dịch vụ đó là gì. Serive Consumer: khách hàng dịch vụ hay những user sử dụng service được cung cấp bởi Service Provider. Service Registry: Nơi lưu trữ thông tin về các service của các Service Provider khác nhau, Service Consumer dựa trên những thông tin này để tìm kiếm và lựa chọn Service Provider phù hợp. Service Provider sẽ đăng ký thông tin về service mà mình có thể cung cấp (các chức năng có thể cung cấp, khả năng của hệ thống (resource, performance, giá cả dịch vụ...) vào Service Registry. Service Consumer khi có nhu cầu về một service nào đó sẽ tìm kiếm thông tin trên Service Registry. Ngoài chức năng hỗ trợ tìm kiếm, Service Registry còn có thể xếp hạng các Service Provider dựa trên các tiêu chí về chất lượng dịch vụ, bầu chọn từ các khách hàng đã sử dụng service... Những thông tin này sẽ hỗ trợ thêm cho quá trình tìm kiếm của Service Consumer. Khi đã xác định được Service Provider mong muốn, Service Consumer thiết lập kênh giao tiếp trực tiếp với Service Provider nhằm sử dụng service hoặc tiến hành thương lượng thêm (về mặt giá cả, resource sử dụng...). 2.1.2. Mô hình giao tiếp bằng thông điệp (message) trong SOA So với kiểu thiết kế Component-Based (hướng thành phần), điểm khác biệt chính của SOA là cung cấp khả năng giao tiếp giữa các thành phần trong hệ thống sử dụng thông điệp (message) dựa trên các giao thức đã được chuẩn hóa (HTTP, FTP, SMTP...). Chính nhờ đặc điểm này, hệ thống SOA trở nên độc lập với nền (platform independent). Các service hoạt động trên các platform khác nhau vẫn có thể giao tiếp với nhau nhờ vào các interface giao tiếp đã được chuẩn hóa để cộng tác xử lý một tác vụ nào đó. Hình 2.2: Message được truyền nhận giữa các dịch vụ Sử dụng thông điệp (message) để giao tiếp có các lợi thế sau: • Độc lập nền: thông điệp (message) trở thành ngôn ngữ chung của các platform và các ngôn ngữ lập trình khác nhau. Điều này đảm bảo các service trên các platform khác nhau hoạt động với cấu trúc dữ liệu đặc thù của platform đó. • Giao tiếp bất đồng bộ: Người gửi và người nhận không cần phải chờ thông điệp trả lời sau khi đã gởi đi một thông điệp. Điều này giúp cho người gửi và người nhận tiếp tục xử lý công việc sau khi gửi thông điệp mà không cần dừng thực thi để chờ thông điệp trả lời. • Giao tiếp tin cậy: các thông điệp từ bên gửi có thể được gửi đến một service trung gian có nhiệm vụ lưu trữ (store) các thông điệp. Service trung gian sẽ chuyển tiếp (forward) thông điệp cho bên nhận khi bên nhận có thể xử lý yêu cầu tiếp theo. Cơ chế Store-and-Forward này đảm bảo các thông điệp sẽ không bị thất lạc trong trường hợp Receiver bị quá tải và không thể nhận thêm yêu cầu mới. • Quản lý luồng: Việc trao đổi thông điệp theo cơ chế bất đồng bộ giúp ứng dụng không cần ngừng thực thi để chờ một tác vụ kết thúc mà có thể tạo ra các luồng (thread) xử lý các công việc khác nhau. • Giao tiếp từ xa: Các thông điệp lưu trữ thông tin về các đối tượng dữ liệu dưới dạng đặc tả hình thức thay thế việc phải serialization and deserialization các đối tượng dữ liệu truyền qua mạng khi ứng dụng thực hiện gọi từ xa một ứng dụng khác. • Bảo mật end-to-end: Thông điệp có thể lưu trữ thông tin về hình thức bảo mật của kênh giao tiếp. Điều này cung cấp khả năng điều khiển liên quan đến bảo mật như xác thực và phân quyền. 2.1.3. Kiến trúc phân tầng chi tiết Hiện nay chưa có một mô hình chính thức nào của SOA. Thật sự SOA là một phương pháp luận giúp chúng ta tận dụng sức mạnh của các nguồn lực, nguồn tài nguyên khác nhau trong mạng máy tính để trở thành một hệ thống nhất. Mỗi một công ty có một mô hình SOA khác nhau. Nhìn chung mô hình SOA có các đặc điểm sau: Hình 2.3: Kiến trúc chi tiết của SOA Tầng Connectivity: đây là tầng thấp nhất của SOA, có nhiệm vụ giao tiếp trực tiếp với các thành phần khác như cơ sở dữ liệu, giao tiếp với các ứng dụng khác, các web service… Vì vậy có thể coi đây là tầng vật lý của SOA. Tầng Orchestration: là các dịch vụ xử lý các quy trình nghiệp vụ và độc lập với tầng vật lý phía bên dưới. Tầng orchestration chứa các thành phần đóng vai trò vừa là dịch vụ sử dụng vừa là những dịch vụ cung cấp. Những dịch vụ này sử dụng những dịch vụ của tầng kết nối và các dịch vụ orchestration khác để kết hợp những chức năng cấp thấp hơn thành những dịch vụ hoạt động ở cấp cao hơn, có hành vi gần với những chức năng nghiệp vụ hơn. Tầng Composite Application: là các ứng dụng tổng hợp nhằm mục đích trình diễn (presentation) và hiển thị thông tin cho người dùng cũng như cung cấp một giao diện cho người dùng tương tác với hệ thống như là một phần mềm duy nhất. Tầng này có thể là các website, portal, các ứng dụng client mở rộng (rich client), các thiết bị di động thông minh (smart device),… Các thành phần khác: gồm có quy trình phát triển (development), quản lý các dịch vụ (service management), và quản lý con người (governance). Như vậy có thể thấy SOA không chỉ đơn thuần là về mặt công nghệ mà nó là tổng hòa của rất nhiều yếu tố: công nghệ, cơ sở hạ tầng, con người và quy trình nghiệp vụ. Hình 2.4: Các thành phần tham gia triển khai hệ thống SOA Vậy khi nào sử dụng SOA? Đó là khi thiết kế hệ thống đặt ra một câu hỏi lớn là việc cân nhắc giữa khả năng sử dụng lại và hiệu năng của hệ thống. Nếu hệ thống cần việc chạy nhanh cho một ứng dụng đặc biệt thì RMI, CORBA, DCOM là sự lựa chọn. Nhưng hệ thống khó có thể thay đổi hoặc sử dụng lại. Nếu hệ thống dự định thay đổi thường xuyên mà không yêu cầu quá cao về tốc độ thì SOA là phương cách tiếp cận tốt nhất. Nó dễ dàng sử dụng lại trong tương lai và cho phép các ứng dụng tương tự được thiết kế một cách nhanh chóng. SOA là tư duy hệ thống ưu việt cho giai đoạn công nghệ hiện nay. Vậy làm cách nào để triển khai tư duy đó vào các ứng dụng thực tế? Đó là vấn đề về công nghệ. Phần tiếp theo sẽ trình bày một công nghệ có thể nói là thể hiện tốt nhất cho SOA hiện nay – Web Service. 2.2. SOA và ứng dụng Web Service 2.2.1. Giới thiệu về Web service Đặc điểm chính của SOA là tách rời phần giao tiếp với phần thực hiện dịch vụ. Điều này cho phép chúng ta liên tưởng đến một công nghệ được đề cập nhiều hiện nay: Web Service. Web Service cho phép truy cập thông qua định nghĩa giao thức-và-giao tiếp. Về cơ bản, SOA là kiến trúc phần mềm phát xuất từ định nghĩa giao tiếp và xây dựng toàn bộ mô hình ứng dụng như là mô hình các giao tiếp, hiện thực giao tiếp và phương thức gọi giao tiếp. Giao tiếp là trung tâm của toàn bộ triết lý kiến trúc này. Thực ra, tên gọi “kiến trúc định hướng giao tiếp” thích hợp hơn cho SOA. Dịch vụ và module phần mềm nghiệp vụ được truy cập thông qua giao tiếp, thường theo cách thức yêu cầu - đáp trả. Ngay cả với yêu cầu dịch vụ một chiều thì nó vẫn là yêu cầu trực tiếp có chủ đích từ một phần mềm này đến một phần mềm khác. Một tương tác định hướng dịch vụ luôn bao hàm một cặp đối tác: nguồn cung cấp dịch vụ và khách hàng sử dụng dịch vụ. Web service là một công nghệ triệu gọi từ xa có tính khả chuyển cao nhất hiện nay: mang tính độc lập nền, độc lập ngôn ngữ. Với web service, các chương trình viết bằng các ngôn ngữ lập trình khác nhau, chạy trên các nền tảng (phần cứng & OS) khác nhau đều có thể trao đổi với nhau thông qua công nghệ này. Tầng transport của Web Service thường dùng những công nghệ truyền tải phổ dụng nhất như HTTP, SMPT... (tuy hiện nay thường chỉ dùng HTTP) nên khả năng phân tán trên diện rộng như Internet là rất thuận tiện. Mà SOA là kiến trúc kết nối lỏng lẻo các service và các service đó tương tác với nhau thông qua Web service. Do đó, kiến trúc SOA sử dụng Web service như là một giải pháp chính để giải quyết vấn đề tích hợp nghiệp vụ giữa các hệ thống. Và đặc biêt trong quá trình internet hóa mọi dịch vụ hiên nay, thì triển khai dịch vụ bằng Web service có thể nói là điều “tất nhiên”. 2.2.2. SOA và Web service trong vấn đề tích hợp hệ thống Web services là những thành phần ứng dụng, giao tiếp bằng cách sử dụng giao thức mở chứa đựng và mô tả chính nó, có thể được phát hiện bằng cách sử dụng UDDI và có thể được sử dụng bởi ứng dụng khác khác nhau. Web service hoạt động dựa trên nền tảng là XML và HTTP. Trong đó: XML cung cấp một ngôn ngữ mà có thể được sử dụng giữa các nền tảng và ngôn ngữ lập trình khác nhau và vẫn thể hiện thông điệp và chức năng phức tạp; Các giao thức HTTP là giao thức Internet được sử dụng nhiều nhất. Web Service với mô hình hoạt động 3 bên tương ứng với mô hình hoạt động của SOA, sử dụng một bộ các chuẩn công nghệ. Đó là: XML: Chuẩn định dạng dữ liệu và thông điệp. SOAP: Giao thức dựa trên XML và HTTP cho phép giao tiếp trên môi trường mạng. WSDL: Ngôn ngữ mô tả Web Service theo chuẩn. UDDI: Một bộ khung chuẩn cho phép mô hình hóa và cụ thể hóa các Web Service đã được đăng ký. Hình 2.5: Mô hình hoạt động của web service Hoạt động của mô hình Web Service như sau: Service Provider: Dùng Web Services Description Language (WSDL) để mô tả dịch vụ mà mình có thể cung cấp và xuất bản (đăng ký) với Service Broker (tương tự với Service Registry trong SOA). Service Broker: Lưu trữ thông tin về các service được cung cấp bởi các Service Provider. Cung cấp chức năng tìm kiếm hỗ trợ Service Requester (Service Consumer trong SOA) trong việc xác định Service Provider phù hợp. Thành phần chính của Service Broker là các kho lưu trữ được mô tả bởi Universal Discovery, Description, and Integration (UDDI). Service Requester: Dùng WSDL để đặc tả nhu cầu sử dụng (loại service, thời gian sử dụng, resource cần thiết, mức giá ...) và gởi cho Service Broker. Bằng việc sử dụng UDDI và chức năng tìm kiếm của Service Broker, Service Requester có thể tìm thấy Service Provider thích hợp. Ngay sau đó, giữa Service Requester và Service Provider thiết lập kênh giao tiếp sử dụng SOAP để thương lượng giá cả và các yếu tố khác trong việc sử dụng service. Như vậy, sử dụng Web Service cho việc tích hợp SOA giúp ứng dụng đạt được những mục tiêu theo nguyên lý SOA: Thông qua các chuẩn công nghiệp. Các chuẩn này gồm Web Service với các định nghĩa thành phần chuẩn công nghiệp cho XML. Sử dụng được những phần mềm thương mại đã xây dựng sẵn nhiều nhất có thể. Phần mềm phải cung cấp các kênh giao tiếp (adapter) cho Web service. Đóng gói các ứng dụng cho phép kế thừa với giao diện đúng theo chuẩn công nghệ chung. Các Web Service đều phải được sử dụng thông qua giao diện này. Sử dụng dữ liệu và tầng dữ liệu độc lập nằm giữa các ứng dụng để ẩn đi cấu trúc dữ liệu bên dưới. Mọi tương tác với dữ liệu đều phải thông qua Web Service. Làm thế nào Web Service có thể đạt được những mục tiêu trên? Chúng ta sẽ đi vào xem xét chi tiết các công nghệ và kỹ thuật thực hiện của Web Service. 2.2.3. Cấu trúc và chi tiết các thành phần của Web service Nền tảng của các dich vụ web gồm các yếu tố: XML (eXtensible Markup Language), SOAP (Simple Object Access Protocol), UDDI (Universal Description, Discovery and Integration), WSDL (Web Services Description Language). Hình 2.6: Các thành phần của Web service 2.2.3.1. XML - eXtensible Markup Language XML là một chuẩn mở do W3C đưa ra và được phát triển từ SGML. XML là một ngôn ngữ mô tả văn bản với cấu trúc do người sử dụng định nghĩa, nó được sử dụng để định nghĩa các thành phần dữ liệu trên trang web và cho những tài liệu B2B. Về hình thức, XML hoàn toàn có cấu trúc thẻ giống như ngôn ngữ HTML, nhưng không tuân theo một đặc tả quy ước như HTML, người sử dụng hay các chương trình có thể quy ước định dạng các tag XML để giao tiếp với nhau. Trong khi HTML định nghĩa thành phần được hiển thị như thế nào thì XML lại định nghĩa những thành phần đó chứa cái gì. Với XML, các thẻ có thể được lập trình viên tự tạo ra trên mỗi trang web và được chọn là định dạng thông điệp chuẩn bởi tính phổ biến và hiệu quả mã nguồn mở. Do Web Service là sự kết hợp của nhiều thành phần khác nhau nên nó sử dụng các tính năng và đặc trưng của các thành phần đó để giao tiếp. Vì vậy XML là công cụ chính để giải quyết vấn đề này và là kiến trúc nền tảng cho việc xây dựng một Web Service, tất cả dữ liệu sẽ được chuyển sang định dạng thẻ XML. Khi đó, các thông tin mã hóa sẽ hoàn toàn phù hợp với các thông tin theo chuẩn của SOAP hoặc XML-RPC và có thể tương tác với nhau trong một thể thống nhất. Ví dụ về tài liệu XML: Xin Chào XML Đây là chương trình XML đầu tiên Tài liệu XML chỉ chứa dữ liệu, không nhắc đến cách trình bày. Điều này có ý nghĩa đó là một XML parser, không cần phải hiểu ý nghĩa của các thẻ. Nó chỉ cần tìm các thẻ và xác định đây là một tài liệu XML hợp lệ vì trình duyệt không cần phải hiểu ý nghĩa của các thẻ, nên người dùng có thể tạo ra các thẻ bất kì để sử dụng. 2.2.3.2. SOAP (Simple Object Access Protocol) Là một giao thức dựa trên XML để cho phép các ứng dụng trao đổi thông tin qua HTTP, được thiết kế đơn giản và dễ mở rộng. Đơn giản, SOAP là một giao thức để truy cập một Web Service, một giao thức truyền thông hay một định dạng để gửi tin nhắn. Tất cả các thông điệp SOAP đều được mã hóa sử dụng XML, cho nên không bị ràng buộc bởi bất kỳ ngôn ngữ lập trình nào hoặc công nghệ nào. Vì những đặc trưng này, nó không quan tâm đến công nghệ gì được sử dụng để thực hiện miễn là người dùng sử dụng các message theo định dạng XML. Tương tự, service có thể được thực hiện trong bất kỳ ngôn ngữ nào, miễn là nó có thể xử lý được những message theo định dạng XML. Hình 2.7: Mô hình gửi nhận thông điệp qua SOAP Bộ khung của một thông điệp SOAP bao gồm: Protocol Header: Cho biết thông tin về các chuẩn giao thức được sử dụng. SOAP Envelop: Phần chính của thông điệp. Thông tin chính của message bao gồm: SOAP Header: Chứa các SOAP header. SOAP body: Thông tin về name và data được đặc tả dưới dạng XML. Ngoài ra còn có trường lỗi được dùng để gởi các web service exception. Hình 2.8: Cấu trúc của một SOAP message Ví dụ: ... ... ... 2.2.3.3. WSDL (Web Service Discription Language) WSDL là một ngôn ngữ dựa trên XML dùng để mô tả giao diện của Web Service. Nó cung cấp một cách thức chuẩn để mô tả các kiểu dữ liệu được truyền trong các thông điệp thông qua Web Service, các hoạt động được thực hiện trên các thông điệp và ánh xạ các hoạt động này đến giao thức vận chuyển. WSDL dựa trên XML. WSDL được dùng để mô tả các Web Service . WSDL được dùng để xác định vị trí Web Service. WSDL là một chuẩn của W3C. WSDL định nghĩa cách mô tả Web Service theo cú pháp tổng quát của XML, bao gồm các thông tin: Tên dịch vụ. Giao thức và kiểu mã hóa sẽ được sử dụng khi gọi các hàm của Web Service. Loại thông tin: thao tác, tham số, những kiểu dữ liệu (có thể là giao diện của Web Service cộng với tên cho giao diện này). Một WSDL hợp lệ gồm hai phần: Phần giao diện: mô tả giao diện và giao thức kết nối. Phần thi hành: mô tả thông tin để truy xuất service. Cả hai phần này sẽ được lưu trong 2 tập tin XML: Tập tin giao diện service (cho phần 1). Tập tin thi hành service (cho phần 2). Hình 2.9: Cấu trúc WSDL Tập tin giao diện - Service Interface Một tài liệu WSDL mô tả một Web Service gồm các thành phần chính: Element Defines Các kiểu dữ liệu được sử dụng bởi các Web Service Các thông điệp được sử dụng bởi các Web Service Các hoạt động được thực hiện bởi các Web Service Các giao thức truyền thông được sử dụng bởi các Web Service Cấu trúc một tài liệu WSDL sẽ như sau: definition of types definition of a message definition of a port definition of a binding.... Một tài liệu WSDL cũng có thể có các yếu tố khác, như thành phần mở rộng, và các yếu tố một dịch vụ mà làm cho nó nhóm lại với nhau để có thể định nghĩa của một số Web Service trong một tài liệu WSDL. Tập tin thi hành - Service Implementation WSDL mô tả 2 loại thông tin chính bao gồm : service và port. Dịch vụ (Service) Thực hiện những gì đã được định nghĩa trong tập tin giao diện và cách gọi web services theo thủ tục và phương thức nào đó: Port Là một cổng đầu cuối, nó định nghĩa như một tập hợp của binding và một địa chỉ mạng. Ở đây chúng ta thấy rằng thuộc tính kết hợp tên là qname. Nó tham chiếu tới một mối kết hợp. Một cổng chứa đựng chính xác một địa chỉ mạng, bất kỳ cổng nào trong phần thi hành phải tương ứng chính xác với một tham chiếu trong phần giao diện. Giao diện của một Web Service được miêu tả trong phần này đưa ra cách thức làm thế nào để giao tiếp qua Web Service. Tên, giao thức liên kết và định dạng thông điệp yêu cầu để tương tác với Web Service được đưa vào thư mục của WSDL. WSDL thường được sử dụng kết hợp với XML schema và SOAP để cung cấp Web Service qua Internet. Một client khi kết nối tới Web Service có thể đọc WSDL để xác định những chức năng sẵn có trên server. Sau đó, client có thể sử dụng SOAP để lấy ra chức năng chính xác có trong WSDL. 2.2.3.4. UDDI (Universal Description, Discovery and Integration) UDDI là một dịch vụ thư mục nơi mà các công ty có thể đăng ký và tìm kiếm các Web Service. UDDI cung cấp một khung ứng dụng về các nghiệp vụ để xuất bản một Web Service, khám phá các Web Service hiện hữu và xây dựng các đăng ký dịch vụ chung. • UDDI là một thư mục để lưu trữ các thông tin về các Web Service. • UDDI là một thư mục của các Web Service giao diện mô tả bởi WSDL. • UDDI truyền qua SOAP. • UDDI được xây dựng trên Microsoft NET. Để có thể sử dụng các dịch vụ, trước tiên client phải tìm dịch vụ, ghi nhận thông tin về cách sử dụng và biết được đối tượng nào cung cấp dịch vụ. UDDI định nghĩa một số thành phần cho biết các thông tin này, cho phép các client truy tìm và nhận những thông tin được yêu cầu khi sử dụng Web Service. Những thông tin về Web Service được sử dụng và công bố lên mạng sử dụng giao thức này. Nó sẽ kích hoạt các ứng dụng để tìm kiếm thông tin của Web Service khác nhằm xác định xem dịch vụ nào sẽ cần đến nó. Những UDDI registry hiện có: UDDI Business Registry: bộ đăng ký được bảo trì bởi Microsoft, IBM đặc điểm của bộ đăng ký này là nó phân tán về mặt vật lý. IBM Test Registry: bộ đăng ký cho những người phát triển để thử nghiệm công nghệ và kiểm tra những service của họ. Private registries IBM ships: bộ đăng ký UDDI cá nhân. Trên đây là mô tả bộ chuẩn công nghiệp mà Web Service sử dụng để triển khai mô hình hoạt động theo tư duy SOA. Thoạt nhìn, SOA và Web Service có vẻ giống nhau nhưng chúng không phải là một. Định nghĩa cơ bản của Web Service dựa trên các công nghệ XML, WSDL, UDDI và SOAP cho phép xây dựng các giải pháp lập trình cho vấn đề tích hợp ứng dụng và truyền thông điệp. Theo thời gian, các công nghệ này có thể hoàn thiện hay có thể được thay bằng công nghệ khác tốt hơn, hiệu quả hơn hay ổn định hơn. Rõ ràng, theo định nghĩa thì Web Service là đặc tả công nghệ còn SOA là triết lý thiết kế phần mềm. Web Service đưa ra giải pháp kỹ thuật để thực hiện SOA, nhưng SOA cũng có thể thực hiện với các giải pháp kỹ thuật khác không phải Web Service (và không phải tất cả Web Service đều có kiến trúc SOA). Tuy vậy, SOA và Web Service có mối quan hệ tương hỗ: sự phổ biến của Web Service giúp thúc đẩy sự phát triển của SOA, và kiến trúc tốt của SOA sẽ giúp Web Service thành công. 2.3. Qui trình xây dựng hệ thống SOA 2.3.1. Thách thức khi xây dựng hệ thống Cũng như các phương pháp phát triển phần mềm khác, để xây dựng được một ứng dụng hướng dịch vụ cũng phải trải qua các giai đoạn tương tự. Tuy vậy, dù những lợi ích đạt được từ hệ thống SOA là rất lớn nhưng việc triển khai một hệ thống SOA không phải là điều dễ dàng. Từ mô hình tính toán tập trung (mainframe) sang mô hình phân tán client/server, rồi sau đó là kiến trúc dựa trên nền tảng Web. Và ngày nay quá trình này vẫn tiếp tục. Chúng ta đang ở thời kỳ quá độ sang mô hình tính toán dựa trên dịch vụ là kiến trúc hướng dịch vụ (SOA). Kiến trúc này ngày nay cũng đã và đang áp dụng và phát triển cho nhiều doanh nghiệp trên thế giới. Nhưng để xây dựng và triển khai được hệ thống SOA thì vẫn phải gặp một số vấn đề trở ngại: Xác định dịch vụ Dịch vụ là gì?chức năng nghiệp vụ nào cần được cung cấp bởi một dịch vụ? Độ mịn(granularity) của một dịch vụ thế nào là tốt? Việc xác định dịch vụ và quyết định đối tượng cung cấp dịch vụ một cách thích hợp, hiệu quả là giai đoạn quan trọng và đầu tiên trong một giải pháp hướng dịch vụ .Trong thực tế nhiều chức năng nghiệp vụ tương tự nhau có thể được cung cấp bởi nhiều hệ thống trong một tổ chức. Phân bổ dịch vụ : Ta nên đặt dịch vụ ở vị trí nào trong hệ thống? Các dịch vụ thường hoạt động dựa trên các thực thể nghiệp vụ.Các đối tượng này được lưu và quản lí trong hệ thống.Vị trí của các thực thể này cũng là vị trí tốt nhất để đặt dịch vụ.Tuy nhiên bởi đặc tính của hệ là phân tán nên các đối tượng này phân bố rải rác ở nhiều vị trí và có thể một đối tượng được quản lí ở nhiều nơi.Vì vậy đồng bộ dữ liệu giữa các hệ thống trở nên là một yêu cầu quan trọng.Trong môi trường như thế thì

Các file đính kèm theo tài liệu này:

  • docKiến trúc hướng dịch vụ và ứng dụng (service-oriented-architecture).doc