Kiến trúc hướng dịch vụ (webservice)

26 371 0
Kiến trúc hướng dịch vụ (webservice)

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

Kiến trúc hướng dịch vụ (webservice) Kiến trúc hướng dịch vụ (webservice) Bởi: Khoa CNTT ĐHSP KT Hưng Yên Giới thiệu Trong nhà quản lý công nghệ thông tin phải đối đầu với việc giảm giá thành tối đa lợi ích công nghệ có, họ phải liên tục cố gắng để phục vụ khách hàng tốt hơn, trở nên cạnh tranh phản ứng nhanh với chiến lược cửa doanh nghiệp Có hai yếu tố ẩn sau áp lực này, tính không đồng hệ thống, ứng dụng kiến trúc khác với thời gian tồn công nghệ khác Việc tích hợp nhiều sản phẩm từ nhiều nhà cung cấp nhiều tảng thực điều khó khăn cố gắng tiếp cận theo kiểu nhà cung cấp công nghệ thông tin ứng dụng kiến trúc hỗ trợ không mềm dẻo Sự thay đổi mặt công nghệ yếu tố thứ hai mà nhà quản lý công nghệ thông tin phải đối mặt Sự toàn cầu hoá kinh doanh điện tử làm tăng tốc thay đổi dẫn đến cạnh tranh gay gắt việc rút ngắn chu kỳ sản xuất để chiếm ưu đối thủ cạnh tranh Các thay đổi yêu cầu nhu cầu khách hàng nhanh chóng tác động phân phối cạnh tranh phong phú thông tin sản phẩm dịch vụ diễn nhanh Các cải tiến công nghệ tiếp tục tăng nhanh, làm tăng thay đổi yêu cầu khách hàng Doanh nghiệp phải nhanh chóng thích nghi để tồn tại, chưa kể đến việc phải thành công môi trường cạnh tranh đông ngày nay, hạ tầng công nghệ thông tin phải đem lại khả thích nghi cho doanh nghiệp Vì vậy, tổ chức kinh doanh phát triển từ phân chia doanh nghiệp theo chiều dọc, cô lập năm 1980 trước thành cấu trúc trọng quy trình kinh doanh theo chiều ngang năm 1980, 1990, tới mô hình kinh doanh doanh nghiệp có tác động lẫn Các dịch vụ doanh nghiệp cần phải thành phần hoá phân tán Cần trú trọng vào dây chuyền cung cấp mở rộng, cho phép khách hàng đối tác truy cập tới dịch vụ kinh doanh 1/26 Kiến trúc hướng dịch vụ (webservice) Làm để môi trường công nghệ thông tin trở nên linh hoạt nhạy bén thay đổi yêu cầu kinh doanh? Làm để hệ thống ứng dụng không đồng trao đổi với cách liền mạch? Làm để đạt mục tiêu kinh doanh mà không bị phá sản doanh nghiệp? Đã có nhiều giải pháp đề song song với phát triển vấn đề kinh doanh: kiến trúc đơn vị riêng lẻ,có cấu trúc, mô hình khách chủ, mô hình ba lớp, mô hình đa lớp, mô hình đối tượng phân tán, thành phần, dịch vụ Hiện nay, nhiều nhà quản lý chuyên gia công nghệ thông tin tin tiến ngày gần tới câu trả lời với kiến trúc hướng dịch vụ (SOA) Để đáp ứng yêu cầu không đồng nhất, tính liên thông thay đổi yêu cầu không ngừng, kiến trúc phải đem lại tảng cho việc xây dựng dịch vụ ứng dụng đặc tính sau: - Liên kết lỏng lẻo (Loosely Couple) - Vị trí suốt (Location Transparent) - Độc lập giao thức (Protocol Independent) Dựa kiến trúc hướng dịch vụ vậy, người dùng dịch vụ chí không cần quan tâm tới dịch vụ cụ thể mà trao đổi thông tin hạ tầng sở, tuyến dịch vụ (Services bus), tạo lựa chọn thích hợp cho người dùng Các đặc tả kỹ thuật cụ thể từ công nghệ cài đặt khác J2EE hay NET không làm ảnh hưởng tới người dùng SOA Người dùng cân nhắc thay cài đặt dịch vụ tốt tồn dịch vụ khác có chất lượng tốt Định nghĩa kiến trúc hướng dịch vụ (HDV) Thuật ngữ kiến trúc hướng dịch vụ (SOA–Service Oriented Architectural) không gần nói đến nhiều, đặc biệt Microsoft cho đời công nghệ NET, mà việc phát triển dịch vụ (Service) trở nên dễ dàng hết Tùy theo quan điểm người dùng, có nhiều định nghĩa khác kiến trúc hướng dịch vụ Ví dụ định nghĩa kiến trúc hướng dịch vụ: "Kiến trúc hướng dịch vụ cách tiếp cận để tổ chức tài nguyên công nghệ thông tin mà liệu, logic nguồn lực hạ tầng truy cập thông qua giao diện (interface) thông điệp (Message)." 2/26 Kiến trúc hướng dịch vụ (webservice) Xét khía cạnh sử dụng hiểu đơn giản sau: "Dịch vụ tập chương trình (thư viện) cho phép chương trình chạy máy tính khác mạng triệu gọi sử dụng " Nói tóm lại, SOA hiểu hướng tiếp cận để xây dựng hệ thống phân tán cung cấp chức ứng dụng dạng dịch vụ tới ứng dụng người cuối dịch vụ khác: SOA kiến trúc dùng chuẩn mở để biểu diễn thành phần mềm dịch vụ Cung cấp cách thức chuẩn hoá cho việc biểu diễn tương tác với thành phần phần mềm Các thành phần phần mềm riêng lẻ trở thành khối để sử dụng lại để xây dựng ứng dụng khác Được sử dụng để tích hợp ứng dụng bên bên tổ chức Dịch vụ yếu tố then chốt SOA Có thể hiểu dịch vụ hàm chức (modul phần mềm) thực theo quy trình nghiệp vụ Các dịch vụ SOA có đặc điểm sau: Các dịch vụ tìm kiếm Các dịch vụ có tính liên thông Các dịch vụ không gắn kết chặt chẽ với Các dịch vụ phức hợp, bao gồm nhiều thành phần, đóng gói mức cao Các dịch vụ suốt vị trí Các dịch vụ có khả tự hàn gắn Một cách bản, SOA tập hợp dịch vụ kết nối “ mềm dẻo ” với (nghĩa ứng dụng có khả giao tiếp với ứng dụng khác mà không cần biết chi tiết hệ thống bên trong), có giao diện định nghĩa rõ ràng độc lập với tảng hệ thống, tái sử dụng SOA cấp độ cao phát triển ứng dụng, trọng đến quy trình nghiệp vụ dùng giao diện chuẩn để che dấu phức tạp kỹ thuật bên Thiết kế SOA tách riêng phần thực dịch vụ (phần mềm) với giao diện gọi dịch vụ Điều tạo nên giao diện quán cho ứng dụng sử dụng dịch vụ mà không cần quan tâm tới công nghệ thực dịch vụ Thay xây dựng ứng dụng đơn lẻ đồ sộ, nhà phát triển xây dựng dịch vụ tinh gọn triển khai tái tạo sử dụng toàn quy trình nghiệp vụ Điều cho phép tái sử dụng phần mềm tốt hơn, tăng mềm dẻo nhà phát triển cải tiến dịch vụ mà không làm ảnh hưởng đến ứng dụng sử dụng dịch vụ 3/26 Kiến trúc hướng dịch vụ (webservice) Tríêt lý SOA không hoàn toàn mới, DCOM CORBA có kiến trúc tương tự Tuy nhiên, kiến trúc cũ ràng buộc thành phần với chặt ví dụ ứng dụng phân tán muốn làm việc với phải thoả thuận chi tiết tập hàm API, thay đổi mã lệnh thành phần COM yêu cầu thay đổi tương ứng mã lệnh truy cập thành phần DCOM Ưu điểm lớn SOA khả kết nối mềm dẻo tái sử dụng Các dịch vụ sử dụng tảng viết với ngôn ngữ (ví dụ, ứng dụng Java liên kết với dịch vụ mạng NET ngược lại) SOA dựa hai nguyên tắc thiết kế quan trọng : - Modul: tách vấn đề lớn thành nhiều vấn đề nhỏ - Đóng gói: che dấu liệu logic modul truy cập từ bên Một thiết kế kiến trúc phù hợp với khái niệm SOA cần tuân theo tính chất sau: Một dịch vụ đơn vị phần mềm gồm hoạt động nghiệp vụ có tính chứa đựng mức độ đóng gói cao (coarse-grained) Một dịch vụ dùng lại được, cho phép xây dựng dịch vụ từ dịch vụ có Do đó, việc quan sát hàm ý có thuộc tính phi chức tính giao dịch quan trọng Một giao diện dịch vụ điểm cuối mạng (Network Endpoint) đảm bảo tính độc lập suốt vị trí Một dịch vụ cần có khả phát cách công khai cách sử dụng nơi đăng ký dịch vụ nhằm cho phép liên kết động tới dịch vụ Một dịch vụ cần đảm bảo tính liên thông cách hỗ trợ giao thức truyền thông chuẩn hoá định dạng liệu rõ ràng Các đặc điểm đảm bảo cho kiến trúc hướng dịch vụ khả gắn kết lỏng lẻo dịch vụ phân tán có tính modul cách sử dụng giao ước dịch vụ để mô tả định dạng thông điệp cần thiết Các thành phần mô hình kiến trúc HDV Với mục tiêu xây dựng kiến trúc dịch vụ thực đơn giản tính tương thích cao, SOA xây dựng dựa chuẩn phổ biến SOAP (Simple Object Access Protocol – giao thức truy xuất đối tượng đơn giản) XML (eXtensible Makup 4/26 Kiến trúc hướng dịch vụ (webservice) Language – ngôn ngữ đánh dấu mở rộng) Hai chuẩn đóng vai trò thành phần xương sống để truyền nhận thông điệp đối tượng truyền thông Tức là, thành phần hiểu giao thức hoàn toàn sử dụng dịch vụ mà không phụ thuộc vào ngôn ngữ lập trình hay hệ điều hành sử dụng Mô hình kiến trúc mô tả sau: Mô hình kiến trúc hướng dịch vụ Các thực thể kiến trúc hướng dịch vụ bao gồm: Dịch vụ (Services) Thành phần sử dụng dịch vụ (Services consumer/ Client / Request) Thành phần cung cấp dịch vụ (Services Provider) Thành phần đăng ký dịch vụ (Services Registry) Giao ước dịch vụ (Contract) Uỷ nhiệm dịch vụ Ràng buộc sử dụng dụng dịch vụ (Services lease) Dịch vụ: Dịch vụ chứa chức rõ ràng, tự chứa đựng không phụ thuộc vào ngữ cảnh hay trạng thái dịch vụ khác Các thành phần sử dụng dịch vụ truy cập tới dịch vụ thông qua giao diện dịch vụ xuất Dịch vụ có tính chất sau: Dịch vụ có tính chất rõ ràng, đơn vị chức nghiệp vụ triệu gọi Có khả triệu gọi thông qua giao thức truyền thông chung Có tính liên thông vị trí suốt Dịch vụ định nghĩa giao diện tường minh Các giao diện độc lập với cài đặt Cung cấp giao ước thành phần cung cấp sử dụng dịch vụ 5/26 Kiến trúc hướng dịch vụ (webservice) Dịch vụ modul phức tạp, bao gồm nhiều thành phần Mức độ đóng gói dịch vụ cao dịch vụu có khả tái sử dụng linh hoạt Thành phần sử dụng dịch vụ(Web Services Customer): Thành phần sử dụng dịch vụ ứng dụng, dịch vụ, loại modul phần mềm khác có yêu cầu sử dụng dịch vụ Đây thực thể khởi tạo việc định vị định vụ kho đăng ký dịch vụ, liên kết tới dịch vụ qua kênh truyền thông thực thi chức dịch vụ Thành phần náy thực thi nhiệm vụ cách gửi tới dịch vụ yêu cầu định dạng theo giao ước Thành phần cung cấp dịch vụ(Web Services Implementation): Thành phần cung cấp dịch vụ thực thể có khả địa hoá qua mạng, chấp nhận thực thi yêu cầu từ thành phần sử dụng dịch vụ Thành phần cung cấp dịch vụ hệ thôngs máy tính lớn, thành phần, loại hệ thống phần mềm khác thực thi yêu cầu dịch vụ Thực thể xuất giao ước dịch vụ kho đăng ký dịch vụ để thành phần sử dụng dịch vụ truy cập Thành phần đăng ký dịch vụ(UDDI): Thành phần đăng ký dịch vụ thư mục mạng có chứa dịch vụ sẵn dùng Đây thực thể chấp nhận lưu trữ giao ước từ thành phần cung cấp dịch vụ cung cấp giao ước cho thành phần sử dụng dịch vụ Dịch vụ UDDI, đóng vai trò người đường cho thành phần sử dụng dịch vụ, tạo suốt vị trí thành phần cung cấp dịch vụ; để thành phần thay đổi thành phần sử dụng dịch vụ không cần phải biên dịch hay cấu hình lại Giữa ba thành phần: cung cấp dịch vụ, sử dụng dịch vụ, đăng ký dịch vụ, việc trao đổi liệu hoàn toàn dùng giao thức SOAP nội dung bên định dạng XML Giao ước dịch vụ: Một giao ước đặc tả cách thức để thành phần sử dụng dịch vụ tương tác với thành phần cung cấp dịch vụ Nó khuôn dạng thông điệp yêu càu thôgn điệp đáp ứng từ dịch vụ Giao ước dịch vụ đòi hỏi tập điều kiện tiên điều kiện sau Các điều kiện xác định trạng thái cần thiết dịch vụ để thực thi chức cụ thể Bản giao ước bao gồm mức độ chất lượng dịch vụ, đặc tả cho khoá chạnh phi chức dịch vụ Uỷ nhiệm dịch vụ: 6/26 Kiến trúc hướng dịch vụ (webservice) Thành phần cung cấp dịch vụ cung cấp uỷ nhiệm dịch vụ cho thành phần sử dụng dịch vụ Thành phần sử dụng dịch vụ thực thi yêu cầu cách gọi hàm API Uỷ nhiệm dịch vụ (hình 1.9) tìm giao ước tham chiếu tới thành phần cung cấp dịch vụ nơi đăng ký Sau đó, định dạng thông điệp yêu cầu thực thi yêu cầu danh nghĩa thành phần sử dụng dịch vụ Uỷ nhiệm dịch vụ thực thể không bắt buộc, đơn giản hoá cho thành phần sử dụng dịch vụ thành phần sử dụng dịch vụ hoàn toàn viết phần mềm để truy cập tới dịch vụ Một thành phần cung cấp dịch vụ cung cấp nhiều uỷ nhiệm cho môi trường khác nhau, uỷ nhiệm dịch vụ viết ngôn ngôn ngữ thành phần sử dụng dịch vụ Ví dụ, thành phần cung cấp dịch vụ cung cấp uỷ nhiệm dịch vụ cho Java, Visual Basic, Delphi tảng thành phần sử dụng dịch vụ Mặc dù uỷ nhiệm dịch vụ không bắt buộc cải thiện cách đáng kể hiệu tính tiện dụng cho thành phần sử dụng dịch vụ Uỷ nhiệm dich vụ Ràng buộc sử dụng dịch vụ: Ràng buộc sử dụng dịch vụ mà thành phần đăng ký dịch vụ gán cho thành phần sử dụng dịch vụ cần thiết để dịch vụ bảo trì thông tin trạng thái liên kết thành phần sử dụng thành phần cung cấp Nó tạo gắn kết không chặt chẽ thành phần cách giới hạn khoảng thời gian mà chúng liên kết với Không ràng buộc, thành phần sử dụng dịch vụ liên kết với dịch vụ mãi không liên kết lại với giao ước Các thao tác kiến trúc hướng dịch vụ bao gồm: Xuất dịch vụ: để truy cập được, mô tả dịch vụ phải xuất để tìm thấy triệu gọi người dùng dịch vụ 7/26 Kiến trúc hướng dịch vụ (webservice) Tìm kiếm dịch vụ: người yêu cầu dịch vụ định vị dịch vụ cách yêu cầu nơi đăng ký dịch vụ dịch vụ phù hợp với tiêu chí đặt Liên kết thực thi dịch vụ: sau nhận mô tả dịch vụ, người dùng gọi dịch vụ theo thông tin mô tả Như hình 5.2, thành phần cung cấp dịch vụ đăng ký dịch vụ với UDDI service (thông tin đăng ký đặc tả theo định dạng gọi ngôn ngữ đặc tả dịch vụ – WSDL), đăng ký thành phần sử dụng dịch vụ muốn sử dụng truy xuất UDDI Service để lấy thông tin vị trí service đặt địa nào, sau thực request service mong muốn sau chạy service response kết cho phía sử dụng dịch vụ Xây dựng ứng dụng theo kiến trúc HDV Trong tiến hoá kỹ thuật xây dựng phần mềm, kỹ thuật lập trình hướng đối tượng thích hợp để cài đặt thành phần Trong thành phần lại cách thích hợp để cài đặt dịch vụ, cần hiểu ứng dụng dựa thành phần tốt không cần thiết ứng dụng dịch vụ tốt Khi vai trò dịch vụ kiến trúc ứng dụng hiểu rõ, tích hợp thành phần thành phần có Hình 1.14 minh hoạ cách cài đặt mức độ đóng gói cao tiến gần tới người sử dụng, cho thấy dịch vụ cách thích hợp để thể khung nhìn hệ thống với tái sử dụng bên có sử dụng thiết kế thành phần truyền thống Các tầng cài đặt thiết kế: đối tượng, thành phần, dịch vụ Các nguyên tắc thiết kế hướng dịch vụ Việc tiếp cận xây dựng hệ thống dựa mô hình hướng dịch vụ phải tuân theo bốn nguyên tắc sau: 8/26 Kiến trúc hướng dịch vụ (webservice) Nguyên tắc 1: Giao diện dịch vụ phải rõ ràng Các dịch vụ tương tác qua việc truyền thông điệp tường minh Chúng ta không cần biết không gian nằm sau giao diện dịch vụ Vượt qua giao diện dịch vụ tốn nhiều công sức chi phí Các giao diện rõ ràng cho phép cài đặt tương tác độc lập- nghĩa không cần biết tảng hay ngôn ngữ lập trình lựa chọn để cài đặt Nguyên tắc 2: Dịch vụ tự trị Các dịch vụ hoạt động thực thể độc lập Không có quyền làm chủ môi trường hướng dịch vụ Các dịch vụ triển khai, thay đổi, quản lý cách độc lập Nguyên tắc 3:Các dịch vụ chia sẻ giao diện giao ước không chia sẻ cài đặt Các dịch vụ tương tác với dựa vào giao diện giao ước sử dụng dịch vụ Giao ước dịch vụ mô tả cấu trúc thông điệp ràng buộc thông điệp, điều cho phép bảo toàn tính toàn vẹn dịch vụ Các giao ước giao diện phải trì tính ổn định với thời gian Vì việc xây dựng chúng cách mềm dẻo quan trọng Nguyên tắc 4: Tính tương thích dịch vụ phải dựa sách Cả người cung cấp người dùng dịch vụ phải có sách để tương tác qua giao diện dịch vụ Một ví dụ đơn giản sách phía người cung cấp dịch vụ đòi hỏi người gọi phải có tài khoản hợp lệ với người cung cấp dịch vụ Về phía người dùng dịch vụ, tổ chức đòi hỏi lời kêu gọi qua Internet phải mã hoá Các định thiết kế kiến trúc kiến trúc hướng dịch vụ Có nhiều định thiết kế kiến trúc tảng cho SOA để đạt mục tiêu lợi ích mà kiến trúc nêu Các định kiến trúc thường liên quan tới việc chọn lựa công nghệ sản phẩm cần thiết kế để đáp ứng chất lượng cho thuộc tính dịch vụ yêu cầu quy trình nghiệp vụ Các định thiết kế tập trung vào lựa chọn dịch vụ sử dụng kỹ thuật mô tả sau phân tích thiết kế hướng đối tượng Một số định là: Xác định dịch vụ: định thiết kế định thành công kiến trúc hướng dịch vụ Thiết kế cài đặt thành phần chứa: định thiết kế kiến trúc quan trọng để dịch vụ cung cấp chức cho việc mở rộng bảo trì Mức độ đóng gói : lựa chọn thiết kế dịch vụ phải phù hợp với mức độ tái sử dụng mềm dẻo yêu cầu ngữ cảnh cụ thể Các dịch vụ có mức độ đóng gói cao trợ giúp việc đóng gói thay đổi dịch vụ kỹ thuật có mức độ đóng gói thấp (các dịch vụ thường có xu hướng thay đổi thường xuyên so với nghiệp vụ ở mức cao hơn) Các nhân tố tính mềm dẻo tiêu chuẩn cho việc đóng gói việc đơn đóng gói chức 9/26 Kiến trúc hướng dịch vụ (webservice) Tính gắn kết không chặt chẽ cấu hình lại động định thiết kế yêu cầu việc tách giao diện khỏi cài đặt giao thức thông qua chuẩn mở Kết nối thành phần cung cấp sử dụng dịch vụ cần phải bền vững cấu trúc rõ ràng, có khả cấu hình lại linh hoạt Có khả cấu hình lại có nghĩa thành phần sử dụng dịch vụ thành phần cung cấp dịch vụ lắp ghép lại với chức không bị thay đổi để đạt giải pháp nghiệp vụ môi trường kỹ thuật khác với ràng buộc thao tác khác đối tác kinh doanh Các tầng SOA: Các thành phần kiến trúc hướng dịch vụ Danh mục dịch vụ: mô tả dịch vụ nghiệp vụ trogn SOA, bao gồm danh sách, phân loại cấu trúc dịch vụ xác định thông qua kỹ thuật phân tích thiết kế hướng dịch vụ Các thành phần: cung cấp cài đặt chức cuả dịch vụ Thành phần sử dụng dịch vụ, thành phần cung cấp dịch vụ thành phần môi giới dịch vụ với kho đăng ký dịch vụ, đó, định nghĩa mô tả dịch vụ xuất Các tầng SOA: vị trí thành phần dịch vụ Hình 5.4 mô tả tầng SOA Với tầng, định thiết kế kiến trúc tiến hành Các tầng SOA Tầng 1: tầng cùng, mô tả hệ thống vận hành Tầng chứa hệ thống ứng dụng có, bao gồm ứng dụng đóng gói, ứng dụng có, 10/26 Kiến trúc hướng dịch vụ (webservice) Các mức độ thực kiến trúc hướng dịch vụ Mức độ 1: Cài đặt dịch vụ riếng lẻ Mức độ tạo dịch vụ từ nhiệm vụ có ứng dụng ứng dụng có Kiến trúc hướng dịch vụ đem lại khả thiết kế ứng dụng hệ thống cung cấp dịch vụ cho ứng dụng khác thông qua giao diện xuất Cách tạo ứng dụng đưa đến mô hình lập trình manh hơn, linh hoạt hơn, giảm chi phí phát triển bảo trì Mức độ 2: Tích hợp hướng dịch vụ chức nghiệp vụ Mức độ tích hợp hướng dịch vụ Bước bao gồm việc tích hợp dịch vụ từ nhiều ứng dụng khác bên lẫn bên doanh nghiệp để phục vụ cho mục đích nghiệp vụ Mức độ phảI hỗ trợ nhiều kiểu tích hợp, bao gồm: Tích hợp ứng dụng: gồm phát triển giao diện để thể ứng dụng có Tích hợp thông tin: gồm liệu doanh nghiệp liệu phòng ban Tích hợp thông tin : gồm tích hợp qua tích hợp, xếp ứng dụng dịch vụ với nhiều giao diện Tích hợp hệ thống: gồm kết nối hệ thống không đồng nhất, hệ thống có tích hợp ứng dụng Mức độ 3: Chuyển đổi doanh nghiệp công nghệ thông tin có quy mô lớn 12/26 Kiến trúc hướng dịch vụ (webservice) Mức cài đặt SOA rộng cài đặt kiến trúc hoá cho phép tích hợp nhiều chức nghiệp vụ trogn toàn doanh nghiệp Mức dộ 4: Chuyển đổi nghiệp vụ theo yêu cầu Đây mức độ cuối phát triển theo kiến trúc hướng dịch vụ Mức độ định hướng chiến lược hướng tới chuyển đổi rộng mô hình nghiệp vụ có triển khai mô hình nghiệp vụ Các bước quy trình phát triển phần mềm theo định hướng dịch vụ Hiện chưa có quy trình cụ thể để phát triển ứng dụng theo kiến trúc hướng dịch vụ, nhiên, dựa thực tế, 12 bước sau đưa nhằm tham khảo định chuyển sang hướng dịch vụ Mười hai bước quy trình phát triển phần mềm theo kiến trúc hướng dịch vụ: Hiểu nghiệp vụ Xác định phạm vi (miền) vấn đề Hiểu tất ngữ nghĩa ứng dụng miền Hiểu tất dịch vụ có miền Hiểu tất nguồn đích thông tin có miền Hiểu tất quy trình miền Xác định phân loại tất giao diện bên miền cần thiết cho việc xây dựng ứng dụng (các dịch vụ thông tin) Định nghĩa dịch vụ ràng buộc thông tin ứng dụng dịch vụ Định nghĩa dịch vụ mới, dịch vụ ràng buộc thông tin cho quy trình Lựa chọn tập công nghệ Triển khai công nghệ SOA Kiểm thử đánh giá Bước 1: Hiểu mục đích nghiệp vụ, xác định thành công 13/26 Kiến trúc hướng dịch vụ (webservice) Đây nhiệm vụ thu thập yêu cầu Nó đòi hỏi phảI tiếp xúc với tài liệu, nhân hệ thống để xác định thông tin cho phép việc tích hợp ứng dụng xác định để phân tích, mô hình hoá cải tiến Chỉ sau thực bước thực thu tập giảI pháp thích hợp đời Cần lưu ý có lợi ích hữu hình vô hình từ việc cài đặt loại công nghệ Lợi ích hữu hình bao gồm việc tiết kiệm chi phí tức thì, việc tự động hoá hệ thống bán theo đơn đặt hàng thay cho việc bán hàng thủ công Lợi ích vô hình khó nhận biết hơn, thoả mãn khách hàng dẫn tới việc tăng doanh số bán hàng, cộng tác chặt chẽ tăng cường chất lượng cho phép cac nhân công trao đổi thông tin tốt Bước 2: Xác định miền vấn đề Phải xác định phạm vi việc ứng dụng SOA tổ chức Hãy chia nhỏ tổ chức để áp dụng SOA thay áp dụng vào toàn tổ chức Cùng với thời gian, thành công nhỏ dẫn tới chiến lược thành công lớn hơn, phải thiết lập đường ranh giới bắt đầu dự án tiến hành xây dựng ứng dụng cách trọng tâm Bước 3: Hiểu tất ngữ nghĩa ứng dụng miền vấn đề Chúng ta giải vấn đề mà thân không hiểu rõ Vì vậy, bước quan trọng để xác định tất siêu liệu ngữ nghĩa tồn miền ứng dụng nhằm giải vấn đề cách hoàn hảo Sự hiểu biết ngữ nghĩa ứng dụng thiết lập cách thức khuôn dạng ứng dụng tham khảo cac thuộc tính quy trình nghiệp vụ Ví dụ, số hiệu khách hàng ứng dụng có giá trị ý nghĩa hoàn toàn khác ứng dụng khác Việc hiểu ngữ nghĩa ứng dụng đảm bảo xung đột thông tin tích hợp với ứng dụng khác mức độ thông tin dịch vụ Xác định ngữ nghĩa ứng dụng công việc khó khăn nhiều hệ thống mà phân tích cũ mang tính độc quyền Bước việc xác định định vị ngữ nghĩa tạo danh sách hệ thống ứng viên Danh sách cho phép xác định kho chứa liệu tồn hệ thống Bất kỳ công nghệ xây dựng lại lược đồ liệu vật lý logic có ích việc xác định liệu miền vấn đề Tuy nhiên, lược đồ mô hình liệu cho phép nhìn vào cấu trúc sở liệu chúng lại xác định thông tin sử dụng ngữ cảnh dịch vụ ứng dụng; lý cần tới bước tiếp theo, Bằng việc hiểu rõ ngữ nghĩa ứng dụng, đảm bảo tất hệ thống nguồn đích tổ chức tích hợp cách hoàn hảo Bước 4: Hiểu tất dịch vụ có miền 14/26 Kiến trúc hướng dịch vụ (webservice) Tìm hiểu thông tin dịch vụ, bao gồm: Vị trí dịch vụ Mục đích dịch vụ Thông tin ràng buộc dịch vụ Các phụ thuộc (nếu dịch vụ phức hợp) Các vấn đề bảo mật Vị trí tốt để bắt đầu tìm hiểu thư mục dịch vụ Giống thư mục khác, kho chứa thông tin thu nhập dịch vụ có, với tài liệu dịch vụ, bao gồm mục đích dịch vụ, thông tin vào/ra Thư mục sử dụng với hiểu biết ngữ nghĩa ứng dụng để xác định điểm tích hợp tất hệ thống miền vấn đề Bước 5: Hiểu tất nguồn đích thông tin có miền vấn đề Bước xác định giao diện xử lý thông tin đơn giản Chúng thực hai vai trò: sử dụng thông tin (đích) cung cấp thông tin ( nguồn) Chúng ta cần phải hiểu rõ khía cạnh sau: Vị trí chúng Cấu trúc luồng thông tin vào/ra Các ràng buộc tích hợp Các phụ thuộc (các nguồn đích khác, dịch vụ) Các vấn đề bảo mật Bước 6: Hiểu tất quy trình Chúng ta cần xác định liệt kê tất quy trình nghiệp vụ tồn miền vấn đề, tự động hoá tự động hoá Việc quan trọng biết dịch dịch vụ nguồn/đích thông có, cần xác định chế tương tác cao hơn, bao gồm tất quy trình mức độ cao, mức trung bình mức thấp Trong nhiều trường hợp, quy trình chưa tự động hoá có phần tự động hóa Ví dụ, kiến trúc sư tích hợp ứng dụng cần hiểu tất quy trình có ứng dụng kiểm kê, đọc tài liệu đọc mã nguồn để xác định quy trình thực Sau đó, đưa quy trình nghiệp vụ vào phân loại xác định mục đích quy trình, người sở hữu nó, xác gì, công nghệ thực (Java C++ ) Những quy trình sau gán với quy trình để đáp ứng yêu 15/26 Kiến trúc hướng dịch vụ (webservice) cầu nghiệp vụ Chúng ta cần phải xem xét khái niệm quy trình chia sẻ quy trình riêng Một số quy trình quy trình riêng, đó, chúng không chia sẻ với thực thể bên ngoài( số trường hợp, chúng chí không chia sẻ với phần khác tôt chức) Các quy trình chia sẻ quy trình riêng tồn không gian quy trình với công nghệ tích hợp quy trình quản lý bảo mật người dùng Một số thông tin bảo trì phân loại, thông tin bao gồm biến sử dụng quy trình, lược đồ đối tượng, yêu cầu bảo mật, và/ đặc điểm hiệu suất Mỗi phân quy trình phải trì tập thuộc tính riêng nó, xây dựng tuỳ biến cho yêu cầu tích hợp ứng dụng cụ thể Bước 7: Xác định phân loại tất giao diện bên miền cần thiết cho việc xây dựng ứng dụng Chúng ta cần xác định tất giao diện bên mà hệ thống miền vẩn đề có tương tác với cần tương tác với để đem lại giá trị tối đa Điều quan trọng phải chắn tất giao diện cần thiết xác định, bao gồm khả thể dịch vụ miền đề bên cho đối tác, khả nhận biết thúc đẩy dịch vụ họ Các hệ thống đối tác cần hoạt động để hỗ trợ quy trình chia sẻ chung Bước 8: Xác định dịch vụ mới, dịch vụ phức hợp thông tin buộc dịch vụ Chúng ta cần xác định tất dịch vụ tạo thành SOA; dịch vụ chia làm loại/ Bước 9: Xác định quy trình mới, dịch vụ thông tin ràng buộc với quy trình Đến bước này, cần hiểu phần lớn thành phần cần thiết để xác định quy trình liên kết chúng với quy trình có tự động hoá quy trình mà trước chưa tự động hoá Bước 10: Lựa chọn tập công nghệ Có nhiều công nghệ để lựa chọn, gồm máy chủ ứng dụng, đối tượng phân tán, máy chủ tích hợp Sự lựa chọn công nghệ giống tổng hợp sản phẩm nhà cung cấp để đáp ứng yêu cầu cho SOA Rất có trường hợp nhà cung cấp có khả giải vấn đề Lựa chọn công nghệ công việc khó khăn yêu cầu lượng thời gian công sức đáng kể Việc tạo tiêu chuẩn cho công nghệ sản phẩm, việc hiểu rõ ràng giải 16/26 Kiến trúc hướng dịch vụ (webservice) pháp đưa ra, sau nối tiêu chuẩn với sản phẩm công việc không dễ dàng Đê thành công, việc kết nối tiêu chuẩn với sản phẩm thường đòi hỏi dự án thử nghiệm để chứng minh hoạt động Thời gian cần thiết để lựa chọn công nghệ phù hợp dài thời gian phát triển SOA, nản chí, dẫn tới việc lựa chọn công nghệ không phù hợp dẫn đến phá hỏng hệ thống Bước 11: Triển khai công nghệ SOA Đến bước này, hiểu tất cần thiết phải hiểu, xác định dịch vụ quy trình mới, lựa chọn tập công nghệ thích hợp, thời gian để xây dựng hệ thống Bước 12: Kiểm thử đánh giá Để đảm bảo cho việc kiểm thử cần xây dựng kế hoạch kiểm thử Cần phải hiểu 12 bước quy trình bắt buộc xây dựng dự án SOA thành công Trong số trường hợp, cần thêm vào loại bỏ số bước để phù hợp vói yêu cầu cụ thể Kiến trúc hướng dịch vụ đưa nhằm loại bỏ trùng lặp dư thừa qua việc tái sử dụng tích hợp Cách đơn giản để bắt đầu vói SOA thử với dịch vụ mà biết có nhiều cài đặt nhiều ứng dụng khác nhau, sau bắt đầu xây dựng kế hoạch chiến lược để loại bỏ dịch vụ dư thừa Quy trình cài đặt giúp đáp ứng yêu cầu tổ chức ẩn sau bước chuyển đổi thành công sang SOA Khi thực quy trình này, có công cụ hiểu biết để mở rộng quy mô áp dụng SOA tổ chức Vòng đời phát triển dịch vụ Việc đảm bảo có dịch vụ nghiệp vụ chuẩn hoá có mức trừu tượng cao xây dựng triển khai mối quan tâm việc xây dựng dịch vụ kiến trúc hướng dịch vụ Chỉ với việc tập trung ý vào quy trình xác định dịch vụ đảm bảo việc cài đặt SOA trở lên hiên hiệu mong đợi Dưới vòng đời phát triển định nghĩa dịch vụ cho phép tiến hành thực việc xem xét điểm kiểm tra từ sớm quy trình định nghĩa dịch vụ Điều giúp loại bỏ lỗi trước chúng làm cho chi phí khắc phục lỗi tăng vọt dịch vụ tiến hành phát triển triển khai 17/26 Kiến trúc hướng dịch vụ (webservice) Vòng đời phát triển dịch vụ Hình mô tả vòng đời phát triển dịch vụ, trạng thái định nghĩa sau: Khởi tạo: dịch vụ tiềm xác định từ việc phân tích yêu cầu doanh nghiệp từ xuống (top – down) việc mô hình hoá quy trình nghiệp vụ Thu nhận: đội ngũ kiến trúc dịch vụ thông báo nhận yêu cầu dịch vụ bắt đầu đánh giá Chứng nhận: đội ngũ kiến trúc dịch vụ đánh giá dịch vụ thống giao diện chức Phân loại: dịch vụ xác định chuyển giao cho đội phát triển Cài đặt: đội ngũ phát triển dịch vụ cài đặt dịch vụ theo quy tắc hướng dẫn phát triển định nghĩa framework Kiểm thử: đội ngũ kiểm thử dịch vụ kiểm chứng tính đặc tính chất lượng dịch vụ Xuất bản: dịch vụ xuất để sử dụng dịch vụ khác ứng dụng định hướng quy trình 18/26 Kiến trúc hướng dịch vụ (webservice) Các công nghệ hướng dịch vụ Sun JINI Công nghệ Jini cho phép xây dựng hệ thống mạng dịch vụ Các dịch vụ thêm vào xoá bỏ khỏi mạng, người dùng tìm kiếm dịch vụ có Tất xảy động, quản lý Dịch vụ dựa giao diện viết ngôn ngữ lập trình Java Nó không quan tâm đến việc dịch vụ cài phần cứng hay phần mềm Đối tượng dịch vụ mà người dùng tải cung cấp thành phần cung cấp dịch vụ Client cần biết họ làm việc với cài đặt giao diện viết ngôn ngữ lập trình Java Việc thiết kế dựa giao diện dịch vụ cho phép xây dựng hệ thống với tính sẵn dùng cao Một thành phần sử dụng dịch vụ phù hợp với giao diện, thay cấu hình tĩnh để giao tiếp với thành phần định Công nghệ Jini xây dựng phía công nghệ Java (xem hình dưới) Phương thức triệu gọi từ xa Java (RMI) cung cấp chế thu rác từ xa đối tượng từ xa khả chuyển trạng thái đối tượng mã đối tượng qua mạng Mô hình kiến trúc Jini Kiến trúc Jini bao gồm: Dịch vụ tra cứu (Looup Services): Dịch vụ tra cứu lưu trữ dịch vụ Jini cung cấp uỷ nhiệm để truyền thông với dịch vụ, thân dịch vụ Jini Dịch vụ Jini(Jini services): 19/26 Kiến trúc hướng dịch vụ (webservice) Dịch vụ Jini đăng ký với dịch vụ tra cứu có khả triệu gọi thông qua giao diện công khai (giao diện định nghĩa thông qua giao diện từ xa) Hệ thống tảng truyền thông Jini RMI Thành phần sử dụng dịch vụ Jini (Jini Client): Thành phần sử dụng dịch vụ Jini phần mềm yêu cầu đối tượng uỷ nhiệm từ dịch vụ tra cứu để gọi dịch vụ Jini Jini có số dịch vụ xây dựng sẵn, bao gồm: Dịch vụ tìm kiếm tra cứu (Lookup Discovery Services): Dịch vụ tìm kiếm tra cứu thông báo cho thành phần sử dụng dịch vụ thay đổi mạng Jini Các dịch vụ kết hợp tách khỏi mạng thời điểm Dịch vụ tái tạo ràng buộc(Lease Renewal Services): Khái niệm tái tạo ràng buộc hỗ trợ mạng dịch vụ Jini tính naưng tự hàn gắn khắc phục lỗi Dịch vụ phải tái tạo ràng buộc không tái tạo, dịch vụ ứng viên bị loại bỏ khỏi mạng lưới dịch vụ Trách nhiệm người quản trị lĩnh vực giảm tới mức tối thiểu nhờ tính tự hàn gắn hệ thống Dịch vụ giao dịch (Transactor Services): Dịch vụ cho phép sử dụng giao dịch hệ thống phân tán Thông thường, tổ chức sử dụng sở liệu để tạo hệ thống giao dịch Dịch vụ giao dịch Jini đưa tính giao dịch sở liệu lên mạng Các dịch vụ tham gia vào giao dịch để đảm bảo thuộc tính ACID (Atomicity- Consistency- IsolationDurability) gắn liền với giao dịch Dịch vụ hộp thư kiện (Event MailBox Services): Các thay đổi mạng dịch vụ Jini đựơc truyền trogn hệ thống cách sử dụng kiện phân tán dịch vụ hộp thư kiện hỗ trợ tính thông báo sự kiện cho dịch vụ dịch vụ không kích hoạt thời điểm Openwings Openwings khung kiến trúc hướng dịch vụ cho việc xây dựng hệ thống siêu hệ thống (hệ thống hệ thống) Mặc dù không bị ràng buộc cụ thể với Jini, cho phép xây dựng dựa khải niệm Java Jini để cung cấp giải pháp hoàn thiện 20/26 Kiến trúc hướng dịch vụ (webservice) Openwings có hàng loạt dịch vụ cốt lõi hỗ trợ tính toán hướng đối tượng Component Services (Các dịch vụ thành phần): cung cấp kỹ thuật cho việc đưa công bố dịch vụ hệ thống đảm bảo cho trình tìm kiếm phát (discover), thông qua sử dụng component cung thư viện cho phép: Tạo khả cung cấp, định vị sử dụng dịch vụ nói chung hệ thống mà không phụ thuộc vào kỹ thuật định vị/ tìm kiếm (location/lookup) Ví dụ kỹ thuật định vị/tìm kiếm Jini, UDDI với mô hình Web-services, giao thức phát (discovery) Bluetooth Quá trình giao tiếp thành phần hay dịch vụ định nghĩa với API chuẩn cho dịch vụ thông qua việc thiết kế thừa từ giao diện chuẩn mà openwings đề xuất Cung cấp component API cho giao thức tương tác dịch vụ qua mạng mà không phụ thuộc vào tính đồng hay không đồng dịch vụ Cung cấp khả điều khiển dịch vụ thành phần thời điểm dịch vụ gọi thực thi Hỗ trợ việc đưa báo cáo trạng thái thành phần tham gia vào hệ thống Cho phép thiết lập môi trường thực tho động dựa theo yêu cầu thời điểm sử dụng Qua hình vẽ minh hoạ sau, ta thấy vị trí trung tâm dịch vụ thành phần mô hình khung mà Openwings đề xuất: 21/26 Kiến trúc hướng dịch vụ (webservice) Mô hình khung Openwings Install services (Các dịch vụ cài đặt): thành phần dịch vụ framework cho phép thực cài đặt thành phần vào hệ thống Để cài đặt thành phần cần phải thông qua quy trình chuẩn mà openwings đề xuất Cung cấp khả cài đặt thêm dịch vụ để hạn chế tối đa tương tác tay cho người sử dụng Đảm bảo không gây ảnh hưởng tới thành phần hay dịch vụ cài đặt trước Cung cấp khả tự động dò tìm cho phép gọi thực với thành phần lưu trữ thiết bị lưu trữ tự động Có chế thẩm định quyền độ ưu tiên cho việc cài đặt gọi thực Có chế huỷ cài đặt an toàn cho hệ thông cần thiết Context Services (Các dịch vụ ngữ cảnh): thành phần cho hỗ trợ việc kết hợp dịch vụ môi trường hệ thống để có dịch vụ lớn Đồng thời hỗ trợ việc kết hợp dịch vụ chia sẻ mạng WAN 22/26 Kiến trúc hướng dịch vụ (webservice) Management Services (các dịch vụ quản lý): cung cấp phương thức hỗ trợ việc quản lý thành phần dịch vụ hệ thống Với hỗ trợ từ dạng quản lý hệ thống qua can thiệp bầng tay hay thông qua việc cài đặt chế quản lý tự động Các hỗ trợ đóng gói Mbean Security Services (các dịch vụ kết bảo mật): cung cấp phương thức cho việc mã hoá, truyền tải liệu hệ thống, hỗ trợ cho việc cấp quyền, thẩm định quyền, đảm bảo an toàn truyền tin, tính toàn vẹn, khả phát công đáp trả công vào hệ thống Connector Services (các dịch vụ kết nối): cung cấp kỹ thuật cho việc giao tiếp thành phần hay dịch vụ hệ thống Hỗ trợ trực tiếp cho kỹ thuật giao tiếp thông qua đối tượng chuyển tiếp trung gian CORBA, RMI, giao tiếp từ giao diện dịch vụ định hướng trước theo kỹ thuật chuyển tiếp trung gian chuẩn với chế động thời điểm diễn giao tiếp tuỳ theo yêu cầu sử dụng Với đầy đủ hỗ trợ cho việc giao phiên hay theo dạng giao tiếp không trì kết nối Hỗ trợ đầy đủ hàm cho phép làm việc với RMI, CORBA, JMS, SOAP Container Services (các dịch vụ chứa đựng): cung cấp môi trường tương ứng cho việc thực dịch vụ mô hình openwings Đây thành phần quan trọng việc tạo nên khả vận hành động không phụ thuộc vào tảng hay môi trường vận hành phân tán hệ thống Cung cấp khả gọi chạy dịch vụ máy qua hệ thống từ xa Hỗ trợ việc quản lý vòng đời tiến trình dịch vụ, phương thức cho phép tự động khởi động lại, tạm dừng hay huỷ dịch vụ Cung cấp khả gán hay thiết lập cho số tiến trình xây dựng Java hoạt động độc lập máy ảo Java mà không ảnh hưởng tới thành phần khác Hỗ trọ việc gọi khởi động dịch vụ không xây dựng Java Cung cấp phương thức cho ohép theo dõi tài nguyên hệ thống theo dõi thông tin độ dung lượng nhớ, khả hoạt động vi xử lý hay khả đáp ứng lưu lượng đường truyền tải liệu Dịch vụ web Mặc dù khái niệm tảng cho kiến trúc hướng dịch vụ thiết lập từ trước dịch vụ mạng xuất dịch vụ mạng đóng vai trò quan trọng kiến trúc hướng dịch vụ Đó dịch vụ mạng xây dựng tập giao thức biết tớí nhiều độc lập tảng Các giao thức bao gồm HTTP, 23/26 Kiến trúc hướng dịch vụ (webservice) XML, UDDI, SOAP Chính kết hợp giao thức làm dịch vụ mạng đáp ứng đựơc yêu cầu kiến trúc hướng dịch vụ: SOA yêu cầu dịch vụ phải phát triệu gọi động, yêu cầu thoả mãn UDDI, WSDL, SOAP; SOA yêu cầu dịch vụ có giao ước giao diện độc lập tảng, yêu cầu thoả mãn XML; SOA nhấn mạnh tới tính liên thông, yêu cầu thoả mãn HTTP Đây lý dịch vụ mạng mang lại có vai trò trung tâm kiến trúc hướng dịch vụ Chi tiết dịch vụ mạng đề cập chương sau Enterprise Services Bus (ESB) Các công nghệ dựa dịch vụ mạng ngày ứng dụng rộng rãi phát triển tích hợp ứng dụng tổ chức Một vấn đề lên việc tìm kiếm phương pháp hiệu việc thiết kế, phát triển triển khai dịch vụ mạng dựa hệ thống kinh doanh; quan trọng việc chuyển kiểu truyền thông dịch vụ mạng điểm tới điểm tới ứng dụng lớn công nghệ thành quy trình kinh doanh mức xí nghiệp Trong bối cảnh này, mô hình ESB xuất bước tiến phát triển dịch vụ mạng kiến trúc hướng đối tượng Mô hình ESB Dịch vụ mạng bản: Dịch vụ mạng (SOAP/HTTP điểm tới điểm) cung cấp tảng vững trắc cho việc cài đặt kiến trúc hướng dịch vụ, có vấn đề ảnh hưởng tới tính mềm dẻo khả bảo trì chúng kiến trúc quy mô xí nghiệp 24/26 Kiến trúc hướng dịch vụ (webservice) Thứ nhất, chất điểm tới điểm dịch vụ mạng có nghĩa người dùng dịch vụ thường cần phải sửa đổi giao diện người cugn cấp dịch vụ thay đổi Điều không thành vấn đề quy mô nhỏ, xí nghiệp lớn phải phải thay đổi trình khách có Thứ hai kết thúc kiến trúc dễ đổ vỡ không linh hoạt số dung lượng lớn người dùng dịch vụ người cung cấp dịch vụ liên lạc với sử dụng kết nối kiểu điểm tới điểm hỗn loạn Cuối cùng, dịch vụ mạng đòi hỏi người dùng phải có điều hợp giao thức thích hợp với nhà cung cấp dịch vụ Việc phải triển khai nhiều điều hợp giao thức nhiều ứng dụng khách làm tăng giá thành chi phí bảo trì Cách tiếp cậu ESB giải vấn đề Vậy ESB ? Khái niệm ESB sản phẩm, thực tiễn kiến trúc tốt cho việc cài đặt kiến trúc hướng dịch vụ Như hình dưới, thiết lập đường bus thông điệp lớp xí nghiệp kết hợp hạ tầng thông điệp với chuyển đổi thông điệp đinh tuyến dựa vào nội dung tâng tích hợp logic người dùng người cung cấp dịch vụ Mục đích ESB cung cấp trừu tượng hoá nguồn tài nguyên doanh nghiệp, cho phép nghiệp vụ doanh nghiệp phát triển quản lý độc lập với hạ tầng, mạng có có mặt dịch vụ doanh nghiệp khác Các nguồn tài nguyên ESB mô dịch vụ có hay nhiều thao tác Cài đặt ESB đòi hỏi tập hợp tích hợp dịch vụ phần hỗ trợ kiểu kiến trúc sau: Các kiến trúc hướng dịch vụ: đây, ứng dụng phân tán bao gồm dịch vụ sử dụng lại với giao diện rõ ràng, xuất tương thích với chuẩn Các kiến trúc hướng thông điệp: đây, ứng dụng gửi thông điệp qua ESB tới ứng dụng nhận thông điệp Các kiến trúc hướng kiện: đây, ứng dụng tạo sử dụng thông điệp độc lập lẫn Các dịch vụ phần giữa(middleware): đựơc cung cấp ESB cần chứa: 25/26 Kiến trúc hướng dịch vụ (webservice) Phần truyền thông hỗ trợ nhiều mô hình truyền thông (như đồng bộ, không đồng bộ, yêu cầu/ trả lời, chiều ), chất lượng dịch vụ (bảo mật, hiệu ), API, tảng giao thức độc lập Một chế cho việc chèn xử lý thông minh lần yêu cầu đáp ứng dịch vụ mạng Các công cụ dựa theo chuẩn phép tích hợp nhanh chóng dịch vụ Hệ thống quản lý cho ứng dụng liên kết lỏng tương tác chúng Kiến trúc hướng dịch vụ xác định kiến trúc hướng dịch vụ trừu tượng nhằm mục đích xây dựng hệ thốn phần mềm cách liên kết kết tập dịch vụ cục từ xa cách mềm dẻo Trong mô hình kiến trúc trước kiểm soát tính phức tạp cách gom nhóm chức chung, SOA lại cố gắng thực việc xác định yêu cầu kiến trúc cụ thể đảm bảo công nghệ hỗ trợ đảm nhiệm trách nhiệm công nghệ Bằng cách này, SOA đạt kiểu kiến trúc trừu tượng mà tập trung vào việc lắp ráp hoạt động nghiệp vụ theo yêu cầu Công nghệ dịch vụ mạng công nghệ hỗ trợ bật cho SOA Nó cung cấp khả giải pháp kỹ thuật cho phép thực hoá thành phần hệ thống phần mềm theo kiến trúc hướng dịch vụ Với trọng tập trung vào việc thiết kế quy trình nghiệp vụ, SOA yêu cầu việc phát triển phần mềm tương tác chặt chẽ với môi trường nghiệp vụ Một tham gia tích cực nhà quản lý phân tích nghiệp vụ cải tiến cách đáng kể kết việc thiết kế hệ thống 26/26 [...]... được kiến trúc hướng dịch vụ, tuỳ thuộc vào mục tiêu và các ràng buộc công nghệ thông tin 11/26 Kiến trúc hướng dịch vụ (webservice) Các mức độ thực hiện kiến trúc hướng dịch vụ Mức độ 1: Cài đặt các dịch vụ riếng lẻ Mức độ này tạo ra các dịch vụ từ các nhiệm vụ có trong các ứng dụng mới hoặc các ứng dụng hiện có Kiến trúc hướng dịch vụ đem lại khả năng thiết kế các ứng dụng và các hệ thống cung cấp dịch. .. tượng cũng như mã đối tượng qua mạng Mô hình kiến trúc Jini Kiến trúc Jini bao gồm: Dịch vụ tra cứu (Looup Services): Dịch vụ tra cứu lưu trữ các dịch vụ Jini và cung cấp các uỷ nhiệm để truyền thông với dịch vụ, bản thân nó cũng là một dịch vụ Jini Dịch vụ Jini(Jini services): 19/26 Kiến trúc hướng dịch vụ (webservice) Dịch vụ Jini được đăng ký với dịch vụ tra cứu và có khả năng được triệu gọi thông... Kiểm thử: đội ngũ kiểm thử dịch vụ kiểm chứng tính năng cũng như các đặc tính chất lượng của dịch vụ Xuất bản: dịch vụ được xuất bản để có thể được sử dụng bởi các dịch vụ khác hoặc các ứng dụng định hướng quy trình 18/26 Kiến trúc hướng dịch vụ (webservice) Các công nghệ hướng dịch vụ Sun JINI Công nghệ Jini cho phép xây dựng một hệ thống là một mạng của các dịch vụ Các dịch vụ có thể được thêm vào và... quan trọng trong một kiến trúc hướng dịch vụ Đó là bởi vì dịch vụ mạng được xây dựng trên một tập các giao thức được biết tớí nhiều và độc lập về nền tảng Các giao thức này bao gồm HTTP, 23/26 Kiến trúc hướng dịch vụ (webservice) XML, UDDI, và SOAP Chính sự kết hợp của các giao thức này đã làm dịch vụ mạng đáp ứng đựơc các yêu cầu của chính kiến trúc hướng dịch vụ: SOA yêu cầu dịch vụ phải được phát hiện... mô hình hoá quy trình nghiệp vụ Thu nhận: đội ngũ kiến trúc dịch vụ thông báo là đã nhận được yêu cầu dịch vụ và bắt đầu đánh giá nó Chứng nhận: đội ngũ kiến trúc dịch vụ đã đánh giá dịch vụ và thống nhất giao diện chức năng của nó Phân loại: dịch vụ được xác định và được chuyển giao cho đội phát triển Cài đặt: đội ngũ phát triển dịch vụ cài đặt dịch vụ theo các quy tắc và hướng dẫn phát triển được định... trong miền 14/26 Kiến trúc hướng dịch vụ (webservice) Tìm hiểu các thông tin về dịch vụ, bao gồm: 1 2 3 4 5 Vị trí của dịch vụ Mục đích của dịch vụ Thông tin ràng buộc của dịch vụ Các phụ thuộc (nếu đó là một dịch vụ phức hợp) Các vấn đề bảo mật Vị trí tốt nhất để bắt đầu tìm hiểu là thư mục dịch vụ Giống như các thư mục khác, đây là một kho chứa các thông tin được thu nhập về các dịch vụ hiện có, cùng... trắc cho việc cài đặt một kiến trúc hướng dịch vụ, nhưng có những vấn đề ảnh hưởng tới tính mềm dẻo và khả năng bảo trì của chúng trong các kiến trúc ở quy mô xí nghiệp 24/26 Kiến trúc hướng dịch vụ (webservice) Thứ nhất, bản chất điểm tới điểm của dịch vụ mạng cơ bản có nghĩa là người dùng dịch vụ thường cần phải được sửa đổi bất kỳ khi nào giao diện người cugn cấp dịch vụ thay đổi Điều này không... lượng dịch vụ thông qua các cơ chế cảm biến và đáp ứng các công cụ kiểm soát các ứng dụng SOA Các mức độ chấp nhận kiến trúc hướng dịch vụ Việc sử dụng kiến trúc hướng dịch vụ không bị giới hạn cho các tổ chức hơn Trong thực tế, kiến trúc này tạo ra cơ hội cho các tổ chức vừa và nhỏ Một ví dụ về việc các doanh nghiệp nhỏ có thể sử dụng dịch vụ là việc nhận các hoá đơn: chúng ta có thể dùng dịch vụ mạng... Thành phần sử dụng dịch vụ Jini (Jini Client): Thành phần sử dụng dịch vụ Jini là một phần mềm yêu cầu đối tượng uỷ nhiệm từ dịch vụ tra cứu để gọi dịch vụ Jini Jini có một số các dịch vụ được xây dựng sẵn, bao gồm: Dịch vụ tìm kiếm tra cứu (Lookup Discovery Services): Dịch vụ tìm kiếm tra cứu thông báo cho các thành phần sử dụng dịch vụ về các thay đổi trong mạng Jini Các dịch vụ có thể kết hợp hoặc... Context Services (Các dịch vụ ngữ cảnh): là các thành phần cho hỗ trợ việc kết hợp các dịch vụ trong môi trường hệ thống để có được một dịch vụ lớn hơn Đồng thời còn hỗ trợ việc kết hợp các dịch vụ được chia sẻ trong một mạng WAN 22/26 Kiến trúc hướng dịch vụ (webservice) Management Services (các dịch vụ quản lý): cung cấp các phương thức cơ bản hỗ trợ việc quản lý các thành phần và dịch vụ trong hệ thống ... dịch vụ 7/26 Kiến trúc hướng dịch vụ (webservice) Tìm kiếm dịch vụ: người yêu cầu dịch vụ định vị dịch vụ cách yêu cầu nơi đăng ký dịch vụ dịch vụ phù hợp với tiêu chí đặt Liên kết thực thi dịch. .. nhận kiến trúc hướng dịch vụ, tuỳ thuộc vào mục tiêu ràng buộc công nghệ thông tin 11/26 Kiến trúc hướng dịch vụ (webservice) Các mức độ thực kiến trúc hướng dịch vụ Mức độ 1: Cài đặt dịch vụ riếng... Hiểu tất dịch vụ có miền 14/26 Kiến trúc hướng dịch vụ (webservice) Tìm hiểu thông tin dịch vụ, bao gồm: Vị trí dịch vụ Mục đích dịch vụ Thông tin ràng buộc dịch vụ Các phụ thuộc (nếu dịch vụ phức

Ngày đăng: 31/12/2015, 14:52

Mục lục

  • Kiến trúc hướng dịch vụ (webservice)

  • Định nghĩa về kiến trúc hướng dịch vụ (HDV)

  • Các thành phần và mô hình trong kiến trúc HDV

  • Xây dựng ứng dụng theo kiến trúc HDV.

    • Các nguyên tắc trong thiết kế hướng dịch vụ

    • Các quyết định thiết kế và kiến trúc trong kiến trúc hướng dịch vụ

    • Các mức độ chấp nhận kiến trúc hướng dịch vụ

    • Các bước trong quy trình phát triển phần mềm theo định hướng dịch vụ

    • Vòng đời phát triển của dịch vụ

    • Các công nghệ hướng dịch vụ

      • Sun JINI

      • Enterprise Services Bus (ESB)

Tài liệu cùng người dùng

Tài liệu liên quan