Nghiên cứu kiến trúc hướng dịch vụ và đối tượng - 2 pps

Trang hợp cao với hệ thống bên ngoài… Ngun nhân khó khăn là: không đồng thay đổi Hầu hết doanh nghiệp ngày sở hữu nhiều hệ thống, ứng dụng, với kiến trúc khác nhau, xây dựng vào khoảng thời gian khác dựa công nghệ khác Vào năm 1990, doanh nghiệp chọn giải pháp trọn gói, mua hẳn vài gói phần mềm lớn với module tích hợp sẵn thay cố gắng “sửa kết hợp” chúng với nhau, lúc kết hợp sản phẩm từ nhiều nhà cung cấp khác thực ác mộng Ngày nay, doanh nghiệp khơng thể chi trả vậy, giải pháp trọn gói thường khơng linh hoạt có giá thành cao Các doanh nghiệp quay lại tìm kiếm giải pháp kết hợp ứng dụng cũ cho thoả mãn nhu cầu, để ứng dụng giải phần việc mình, sau việc tổng hợp thơng tin trả Trong q trình kết hợp chắn gặp khó khăn như: • Khơng đủ khả quản lý quy trình nghiệp vụ • Tốn chi phi tích hợp • Số lượng lớn nhà cung cấp khách hàng, chưa kể đối thủ cạnh trạnh, quy trình nghiệp vụ phức tạp • Số lượng lớn ứng dụng cần kết hợp quản lý Enterprise Resource Planning (ERP), Supply Chain Management (SCM), Product Data Management(PDM) … • Quá nhiều định dạng liệu • Vấn đề bảo mật Trong thay đổi liên tục xảy • Tồn cầu hố dẫn đến tính cạnh tranh khốc liệt đòi hỏi phải rút ngắn quy trình sản phẩm để tăng ưu cạnh tranh với đối thủ • Nhu cầu yêu cầu khách hàng thường xuyên thay đổi nhanh chóng nhằm cho sản phẩm có tính cạnh tranh liên tục xuất thị trường • Cải tiến cơng nghệ dẫn đến thay đổi thành phần liên quan Trang Hình 1-5 – Thực trạng sở hạ tầng IT hầu hết tổ chức Đa phần khó khăn bắt nguồn từ ba nguyên nhân: phức tạp, không linh hoạt không bền vững • Phức tạp: Ngày doanh nghiệp cơng nghệ thơng tin có nhiều hệ thống đủ loại khác làm việc theo cách khác Các công ty phát triển phần mềm phải thuê nhóm nhân viên giàu kinh nghiệm, có khả nhiều lãnh vực khác để phát triển, triển khai quản lý ứng dụng hệ thống mà thân chúng không thống với Thêm vào việc nâng cấp rối rắm, tích hợp với nhu cầu bảo mật ngày tăng làm gia tăng tính phức tạp cho vấn đề vốn khó giái với doanh nghiệp • Khơng linh hoạt: với phức tạp tính cứng nhắc sách, chiến lược phát triển, sở hạ tầng công ty Hầu cơng ty có ứng dụng có sẵn mà khó nâng cấp, khó kết hợp hoạt động tệ hơn, khơng thể thay Vấn đề tích hợp trở nên tốn khó khăn • Khơng bền vững: trái ngược với cứng nhắc nói khơng bền vững với khả thất bại vấn đề khác kèm Các phương pháp tiếp Trang cận truyền thống việc xây dựng hệ thống phần mềm thường dẫn đến “mớ hỗn độn” giải pháp lắp ghép, tích hợp Kết có thay đổi quy trình nghiệp vụ yêu cầu cơng ty phải chấp nhận phát triển dự án nâng cấp tốn hủy thay hẳn công nghệ không phù hợp Rủi ro lúc tăng lên với phụ thuộc chồng chéo thành phần , hệ thống có sẵn Chính doanh nghiệp cần cách tiếp cận để giải vấn đề môi trường không đồng tốc độ chóng mặt thay đổi phải xoay sở với nguồn ngân sách hạn hẹp kinh tế khó khăn May mắn thay, có cách tiếp cận giải tồn diện khó khăn nêu triển khai thực tế Cách tiếp cận gọi “kiến trúc hướng dịch vụ” Serviceoriented Architecture (SOA) Trang 10 Chương GIỚI THIỆU VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ (SERVICE-ORIENTED ARCHITECTURE) Nội dung chương trình bày sở lý thuyết mơ hình SOA, bao gồm: khái niệm kiến trúc hướng dịch vụ (SOA), đặc trưng ích lợi đạt mơ hình kiến trúc Ngồi ra, chương sâu vào tìm hiểu tầng kiến trúc bên mơ hình SOA 2.1 Kiến trúc hướng dịch vụ ? Kiến trúc hướng dịch vụ (Service-oriented architecture) hướng tiếp cận với việc thiết kế tích hợp phần mềm, chức năng, hệ thống theo dạng module, module đóng vai trị “dịch vụ có tính loose coupling”, có khả truy cập thơng qua mơi trường mạng Hiểu cách đơn giản hệ thống SOA tập hợp dịch vụ chuẩn hoá mạng trao đổi với ngữ cảnh tiến trình nghiệp vụ Trong SOA có ba đối tượng chính, minh họa Hình 2-1 Hình 2-1 – Sơ đồ cộng tác SOA Trang 11 Nhà cung cấp (service provider) dịch vụ cần cung cấp thông tin dịch vụ cho dịch vụ lưu trữ thông tin dịch vụ (service registry) Người sử dụng (service consumer) thơng qua service registry để tìm kiếm thơng tin mơ tả dịch vụ cần tìm sau xây dựng kênh giao tiếp với phía nhà cung cấp SOA cung cấp giải pháp để giải vấn đề tồn hệ thống như: phức tạp, không linh hoạt không ổn định Một hệ thống triển khai theo mơ hình SOA có khả dễ mở rộng, liên kết tốt Đây sở tảng cho việc tích hợp, tái sử dụng lại tài nguyên có Thật ra, tư tưởng hệ thống SOA Comnon Object Request Broker Architecture (CORBA) mơ hình Distributed Component Object Model (DCOM) Microsoft hay Enterprise Java Bean (EJB) Java cung cấp tính từ lâu Tuy nhiên cách tiếp cận hướng dịch vụ gặp phải số vấn đề khó khăn (đã phân tích trên) SOA không cải tiến đáng kể giúp giải yếu điểm công nghệ trước mà đem đến nhiều ưu điểm trội ( xem lợi ích SOA mục 2.4 ) 2.2 Bốn nguyên tắc hệ thống SOA 2.2.1 Sự phân định ranh giới rạch ròi dịch vụ Các dịch vụ thực trình tương tác chủ yếu thông qua thành phần giao tiếp Thành phần giao tiếp qui định định dạng thơng điệp sử dụng q trình trao đổi : thông điệp chấp nhận thông điệp khơng xử lý Và cách để đối tượng bên ngồi truy cập thông tin chức dịch vụ Ta cần gửi thông điệp theo định dạng định nghĩa trước mà không cần phải quan tâm đến cách xử lý dịch vụ (môi trường thực thi, ngôn ngữ lập trình ) Điều đạt tách biệt thành phần giao tiếp thành phần xử lý kiến trúc dịch vụ Trang 12 2.2.2 Các dịch vụ tự hoạt động Các dịch vụ cần phải triển khai hoạt động thực thể độc lập mà không lệ thuộc vào dịch vụ khác Dịch vụ phải có tính bền vững cao, nghĩa khơng bị sụp đổ có cố Để thực điều này, dịch vụ cần trì đầy đủ thơng tin cần thiết cho q trình hoạt động để tiếp tục hoạt động trường hợp dịch vụ cộng tác bị hỏng; để tránh công từ bên ngồi (như gửi thơng điệp lỗi, hay gửi thơng điệp ạt) cách sử dụng kỹ thuật an tồn, bảo mật Đây ý nghĩa khái niệm ‘loose coupling service’ mà ta đề cập định nghĩa SOA 2.2.3 Các dịch vụ chia sẻ lược đồ Các dịch vụ nên cung cấp thành phần giao tiếp (interface) bên ngồi, hỗ trợ chia sẻ cấu trúc thông tin, ràng buộc liệu thông qua lược đồ liệu (schema) chuẩn (độc lập ngôn ngữ, độc lập hệ nền.) Như hệ thống ta có tính liên kết khả dễ mở rộng 2.2.4 Tính tương thích dịch vụ dựa sách Điều nghĩa là, dịch vụ muốn tương tác với dịch vụ khác phải thỏa mãn sách (policiy) yêu cầu (requirements) dịch vụ mã hóa, bảo mật Để thực điều này, dịch vụ cần phải cung cấp cơng khai u cầu, sách 2.3 Các tính chất hệ thống SOA 2.3.1 Loose coupling Vấn đề kết nối (coupling) ám đến số ràng buộc cách module với Có hai loại coupling rời (loose) chặt (tight) Các module có tính loose coupling có số ràng buộc mơ tả rõ ràng module có tính tight coupling lại có nhiều ràng buộc khơng thể biết trước Hầu kiến trúc phần mềm Trang 13 hướng đến tính loose coupling module Mức độ kết dính hệ thống ảnh hưởng trực tiếp đến khả chỉnh sửa hệ thống Kết dính chặt có nhiều thay đổi liên quan cần chỉnh sửa phía sử dụng dịch vụ có thay đổi xảy Mức độ coupling tăng dần khi bên sử dụng dịch vụ cần biết nhiều thông tin ngầm định bên cung cấp dịch vụ để sử dụng dịch vụ cung cấp Nghĩa bên sử dụng dịch vụ biết vị trí chi tiết định dạng liệu bên cung cấp dịch vụ quan hệ hai bên chặt Ngược lại, bên sử dụng dịch vụ không cần biết thông tin chi tiết dịch vụ trước triệu gọi quan hệ hai bên có tính loose coupling SOA hỗ trợ loose coupling thơng qua việc sử dụng hợp đồng liên kết (contract and binding) Một người sử dụng truy vấn đến nơi lưu trữ cung cấp thông tin dịch vụ (registry) để lấy thông tin loại dịch vụ cần sử dụng Registry trả tất dịch vụ thoải tiêu chuẩn tìm kiếm Từ người dùng việc chọn dịch vụ mà cần, thực thi phương thức theo mơ tả dịch vụ nhận từ registry Bên sử dụng dịch vụ không cần phụ thuộc trực tiếp vào cài đặt dịch vụ mà dựa hợp đồng mà dịch vụ hỗ trợ Application Application Programming Language Programming Language Database Agreements Object Model Object Model Messages Operating System Application Server Database Operating System Application Server Hình 2-2 - Tính chất loose-coupling Tính loose coupling giúp gỡ bỏ ràng buộc điều khiển hệ thống đầu cuối Mỗi hệ thống tự quản lý độc lập nhằm tăng hiệu suất, khả mở rộng Trang 14 khả đáp ứng cao Những thay đổi cài đặt che dấu Loose coupling đem đến độc lập bên cung cấp bên sử dụng địi hỏi interface phải theo chuẩn cần thành phần trung gian quản lý, trung chuyển yêu cầu hệ thống đầu cuối 2.3.2 Sử dụng lại dịch vụ Bởi dịch vụ cung cấp lên mạng đăng ký nơi định nên chúng dễ dàng tìm thấy tái sử dụng Nếu dịch vụ khơng có khả tái sử dụng, khơng cần đến interface mơ tả Các dịch vụ tái sử dụng lại cách kết hợp lại với theo nhiều mục đích khác Tái sử dụng lại dịch vụ giúp loại bỏ thành phần trùng lắp tăng độ vững cài đặt, cịn giúp đơn giản hố việc quản trị Thực tái sử dụng dịch vụ lại dễ dàng tái sử dụng thành tố hay lớp Những dịch vụ dùng chung tất ứng dụng hệ thống SOA gọi shared infrastructure service 2.3.3 Sử dụng dịch vụ bất đồng Trong phương thức triệu gọi dịch vụ bất đồng bộ, bên gọi gửi thông điệp với đầy đủ thông tin ngữ cảnh tới bên nhận Bên nhận xử lý thông tin trả kết thông qua “kênh thông điệp”, bên gọi chờ thông điệp xử lý xong Khi sử dụng kết hợp thông điệp dạng coarse-grained với dịch vụ chuyển thơng điệp, u cầu dịch vụ đưa vào hàng đợi xử lý với tốc độ tối ưu Do bên gọi chờ yêu cầu xử lý xong trả nên không bị ảnh hưởng việc xử lý trễ lỗi thực thi dịch vụ bất đồng Trên lý thuyết hệ thống SOA hỗ trợ gửi nhận thông điệp đồng bất đồng 2.3.4 Quản lý sách Khi sử dụng dịch vụ chia sẻ mạng, tùy theo ứng dụng có luật kết hợp riêng gọi policy Các policy cần quản lý áp dụng cho dịch vụ thiết kế lẫn thời gian thực thi Trang 15 Việc tăng khả tạo dịch vụ có đặc tính tái sử dụng Bởi policy thiết kế tách biệt, tùy vào ứng dụng nên giảm tối đa thay đổi phần mềm Nếu không sử dụng policy, nhân viên phát triển phần mềm, nhóm điều hành nhóm nhóm hỗ trợ phải làm việc với suốt thời gian phát triển để cài đặt kiểm tra policy Ngược lại , sử dụng policy, nhân viên phát triển phần mềm cần tập trung vào quy trình nghiệp vụ nhóm điều hành nhóm hỗ trợ tập trung vào luật kết hợp 2.3.5 Coarse granularity Khái niệm granularity dịch vụ hiểu theo hai cách Đầu tiên, hiểu phạm vi tồn kiến trúc cài đặt dịch vụ Thứ hai, hiểu phạm vi phương thức interface triển khai Mức độ granularity hiểu mức tương đối Ví dụ, dịch vụ cài đặt tất chức hệ thống ngân hàng, xem coarse-grained Nếu hỗ trợ chức kiểm tra thể tính dụng, lại xem fine-grained Trước có kiến trúc thành tố dịch vụ, hệ thống phân tán chủ yếu dựa ý tưởng phân tán đối tượng Những hệ thống phân tán đối tượng chứa bên nhiều đối tượng fine-grained trao đổi thơng tin với qua mạng Mỗi đối tượng có ràng buộc với nhiều đối tượng khác bên hệ thống Do truy cập đến đối tượng phải qua nhiều trung gian mà hiệu đạt không cao nên khuynh hướng thiết kế hệ thống phân tán đối tượng dần chuyển sang thiết kế coarser-grained interface Hình 2-3 minh họa hệ thống phân tán đối tượng với nhiều mối liên kết Cùng với kích thước độ phức tạp hệ thống ngày tăng, ràng buộc trở nên ngày khó quản lý Hiệu suất giảm tương ứng số lượng kết nối trung gian Khả bảo trì giảm số lượng ràng buộc đối tượng ngày tăng Khi đối tượng cần thay đổi interface, ảnh hưởng đến lượng lớn đối tượng phân tán khác Nhân viên phát triển phải biên dịch triển khai lại toàn đối tượng bị thay đổi đối tượng liên quan với chúng Trang 16 Một hệ thống dựa quản lý truy cấp đến đối tượng bên dịch vụ thơng qua số coarse-grained interface Hình 2-4 Một dịch vụ cài đặt tập đối tượng fine-grained thân đối tượng lại sử dụng trực tiếp qua mạng Trong service cài đặt đối tượng có nhiều đối tượng coarse-grained hoạt động facades phân tán đối tượng lại sử dụng qua mạng cho phép truy cập đến đối tượng sâu bên Tuy nhiên đối tựơng bên service trao đối trực tiếp với máy khơng phải mạng Hình 2-3 – Các đối tượng fine-grained Hình 2-4 – Các đối tượng coarse-grained Trang 19 Thêm vào đó, hệ thống dựa dịch vụ yêu cầu tách biệt interface cài đặt, nên có nhiều cài đặt khác cho interface Nếu thể service khơng hoạt động thể khác hồn tất giao dịch cho khách hàng mà không bị ảnh hưởng Khả có client tương tác với interface dịch vụ không tương tác trực tiếp cài đặt dịch vụ Đây tình chất hệ thống hướng dịch vụ 2.4 Lợi ích SOA Nói đến SOA nói đến ‘tiết kiệm’- tiết kiệm chi phí lẫn thu giá trị nhiều từ hệ thống có sẵn Hẳn phải có lý để hàng trăm tập đoàn ý đến SOA giải pháp tích hợp nhằm giảm giá thành đề án cách ấn tượng Sử dụng lại thành phần có sẵn Một lợi ích rõ ràng SOA giúp công ty thu giá trị nhiều cách sử dụng lại tài nguyên sẵn có; kết giảm chi phí cho phần kiến trúc tích hợp Ngồi cịn giúp giảm chi phí mua phần mềm Thời gian viết chương trình lấy liệu từ máy chủ trước tính tháng cịn tính phút ! Lợi ích việc sử dụng lại chia làm phần : • Lợi ích từ việc sử dụng lại thành phần nhằm giảm tính dư thừa • Lợi ích từ việc sử dụng lại thành phần có sẵn thiết kế cung cấp chức Đầu tiên nói, nhiều phần mềm doanh nghiệp phát triển thành nhóm phần mềm tách biệt (funtional silos), thông thường tương ứng với đơn vị kinh doanh Ví dụ cơng ty bán lẻ có nhóm phần mềm cho hệ thống phân phối, nhóm phần mềm cho hệ thống lưu kho nhóm phần mềm cho chức liên kết Thơng thường nhóm phần mềm đựơc phát triển nhiều tảng khác nhau, sử dụng nhiều ngơn ngữ lập trình khác Trang 20 thường có nhiều tính lặp lại chúng Một hệ thống SOA cho phép công ty tránh tình trạng lặp dư thừa, tạo đơn thể dịch vụ chia sẻ ứng dụng Trong hệ thống SOA, cần thay đổi phiên dịch vụ cần thay đổi cần kiểm thử lần, sử dụng kỹ tương ứng với kỹ dùng để phát triển dịch vụ Lợi ích rõ ràng giảm chi phí bảo trì phần mềm Ngồi điều giúp doanh nghiệp chịu trách nhiệm nhiều với thay đổi về mặt nghiệp vụ cho phép doanh nghiệp cập nhật tính nhanh Bằng cách phân rã ứng dụng thành đơn thể dịch vụ nghiệp vụ, sau cho dịch vụ liên kết lại với nhau, hệ thống sử dụng lại thành phần có sẵn, giảm chi phí phát triển phần độc lập cho tính chưa có Thay phải “thay đổi” , với SOA ta cần tạo “cầu nối” liên hệ hệ thống ứng dụng khác nhau, thay chỉnh sửa xây dựng lại từ đầu Bởi có đa phần dịch vụ sử dụng lại dịch vụ sẵn có phí phát triển thành phần giảm đến mức tối thiểu Nghĩa : • Các cơng ty triển khai tiến trình xử lý nhanh nhiều • Chi phí dành cho phát triển kiểm thử giảm đáng kể • Giảm rủi ro dịch vụ tạm ngưng hoạt động Lợi ích cuối việc tái sử dụng thường khó nhận thấy, sử dụng thành phần có sẵn trước có lỗi xảy ta giới hạn vào khu vực có thành phần phát triển Nhờ rủi ro lỗi phần mềm giảm tăng chất lượng dịch vụ Giảm chi phí phát triển kiểm thử, tránh công việc trùng lặp lợi ích mà SOA mang lại Nhưng quan trọng lợi ích từ việc tăng khả kinh doanh Nếu nhân tố đánh giá mức lợi ích mang lại đáng kể Trang 21 Giải pháp ứng dụng tổng hợp cho doanh nghiệp Cũng với ví dụ trên, SOA mang đến khả tổng hợp lớp ứng dụng cách kết hợp chức từ hệ thống có sẵn, cung cấp cho người cuối chức liên kết Ở số tiến trình cũ kết hợp với bên cổng thông tin (portal) giúp cho người dùng cuối cần truy cập lần mà có thơng tin hàng loạt sản phẩm doanh nghiệp Loại kết hợp khó khăn khơng sử dụng SOA địi hỏi việc tích hợp phức tạp, nỗ lực lập trình kiểm thử Nhưng với SOA , ứng dụng tổng hợp tổng hợp dễ dàng, khác địa lý công nghệ phát triển dịch vụ Điều cho phép doanh nghiệp phản ứng nhanh theo yêu cầu, giảm chi phí đến mức tối thiểu tăng sức mạnh thoả mãn yêu cầu người dùng cuối hiệu Tính loose coupling giúp tăng tính linh hoạt khả triển khai cài đặt Lợi ích đến từ tính loose coupling SOA, phía triệu gọi dịch vụ khơng cần quan tâm đến địa công nghệ tảng service Nó mang đến khả linh hoạt cao nhiều lợi ích khác Trong hệ thống SOA ta triệu gọi dịch vụ thông qua interface theo dạng thức chuẩn nên giúp lập trình viên tránh việc phải lặp lại công việc tạo service có khả hiểu tất cơng nghệ sử dụng dịch vụ hệ thống Thứ hai, trường hợp cần kết nối với đối tác thương mại dịch vụ có tính loose-coupling, interface chuẩn đem lại nhiều lợi ích Với hệ thống SOA, thật dễ dàng cung cấp loạt dịch vụ bên cho đối tác sử dụng Nhờ tính độc lập địa công nghệ SOA, đối tác không cần quan tâm đến dịch vụ cài đặt nào, nhờ dịch vụ theo chuẩn giao tiếp nên đối tác cần lượng thông tin nhỏ vừa đủ để sử dụng dịch vụ Tương tự cho điều ngược lại, đối tác xây dựng hệ thống SOA việc đem sử dụng chức số dịch vụ họ vào sử dụng bên hệ thống trở nên dễ dàng nhanh chóng Đặc tính SOA hứa hẹn tăng hiệu suất tự động hoá Trang 22 Cuối lợi ích mà tính loose coupling mang lại tăng khả triển khai Như phân tích trên, thành phần có tính loose coupling triệu gọi mà không cần biết chúng cài đặt mà cần biết cách thức triệu gọi chúng thơng qua interface chuẩn Vì cần bọc thành phần sử dụng interface ứng dụng thành dạng dịch vụ, ta có đơn thể thành phần sử dụng hệ thống SOA dịch vụ bình thường khác Thích ứng với thay đổi tương lai Các phương pháp tiếp cận truyền thống quy trình phát triển phần mềm mô tả ngắn gọn người dùng mô tả họ cần – cơng ty phát triển phần mềm – triển khai hệ thống theo yêu cầu Quy trình đơi gặp khó khăn gặp tình thay đổi không định trước Với SOA, công ty phát triển phần mềm tạo nên quy trình nghiệp vụ uyển chuyển, phức tạp biến đổi tùy “theo yêu cầu” theo “thời gian thực“ Hỗ trợ đa thiết bị đa tảng SOA cung cấp tầng giao tiếp trừu tượng từ tảng bên Điều cho phép hỗ trợ nhiều loại thiết bị đầu cuối khác bao gồm trình duyệt thiết bị di động pager, điện thoại di động, PDA thiết bị chuyên dụng khác sử dụng chức mà có thơng tin trả tùy theo dạng thiết bị Tính độc lập công nghệ giúp cho công ty tiết kiệm chi phí nhiều phải xử lý với vô số công nghệ sử dụng Tăng khả mở rộng khả sẵn sàng cung cấp Nhờ tính độc lập địa SOA, ta tăng khả mở rộng cách thêm nhiều thể (instance) service Công nghệ chia tải (load-balancing) tự động tìm định tuyến yêu cầu đến thể service thích hợp Tương tự, SOA chuyển tiếp nội dung yêu cầu đến thể khác cần,nhờ tăng khả sẵn sàng phục vụ Trang 23 Cần nhấn mạnh lợi ích mà SOA mang lại khơng phải mà ấn tượng Thực tế giá trị kinh tế mà SOA mang lại lớn tạp đoàn giới suy xét xem làm để chuyển toàn kiến trúc phần mềm có sẵn họ thành SOA 2.5 Một số mơ hình triển khai SOA Chúng ta thảo luận ba mơ hình triển khai SOA : service registy, service broker service bus Service registry : mơ hình truyền thống để định vị liên kết dịch vụ hệ thống SOA (xem hình Hình 2-6) Mơ hình service registry cần chuẩn Web services thông thường SOAP, WSD UDDI Vấn đề lớn mơ hình liên kết dịch vụ kết nối tĩnh phải định nghĩa thiết kế, điều làm cho mơ hình trở nên cứng nhắc Có cách cải tiến làm cho mơ hình linh hoạt tìm kiếm, định vị dịch vụ chạy UDDI hỗ trợ nhiều cấu hình khác cho dịch vụ cung cấp nhiều nhà cung cấp dịch vụ khác Điều cho phép chia tải tăng tính tin cậy service directory tìm kiếm dịch vụ tất nhà cung cấp dịch vụ có Hình 2-6 - Mơ hình service registry Trang 24 Service broker : Một trung gian làm việc dịch vụ cung cấp dịch vụ tiêu thụ Trong mơ hình bản, tất thông điệp trung chuyển qua service broker Dịch vụ làm nhiều chức định tuyến dựa liệu thông điệp, xử lý lỗi, chuyển đổi thông điệp, chia tải lọc thông tin Nó cung cấp dịch vụ bảo mật, chuyển đổi giao thức, lưu vết dịch vụ hữu ích khác Tuy nhiên, service broker nơi xảy tượng nghẽn cổ chai điểm dễ bị hỏng hóc Mơ hình broker phân tán bước cải tiến mới, tảng dịch vụ có broker cục cho phép giao tiếp với service broker trung tâm giao tiếp trực tiếp với service broker cấp tảng dịch vụ khác Hình 2-7 – Mơ hình service broker Trang 25 Service bus : mơ hình đời sau mơ hình sử dụng sản phẩm thương mại large-scale (như IBM, BEA) Service bus mơ hình có tính loose coupling mơ hình, dịch vụ khơng kết nối trực tiếp với Đôi service bus kết nối với thành mạng service bus Hình 2-8 – Mơ hình service bus Hình 2-9 – Mơ hình service bus phân tán Trang 26 2.6 Kiến trúc phân tầng chi tiết SOA Ở tầng thấp nhất, tầng kết nối (connectivity), dịch vụ mơ hình hoá dựa ứng dụng enterprise bên Tầng chứa dịch vụ “lấy thông tin chi tiết sản phẩm” “cập nhật thông tin khách hàng” , chúng tương tác trực tiếp với hệ thống phi dịch vụ bên Các dịch vụ đặc trưng cho ứng dụng enterprise Phía bên tầng kết nối số dịch vụ orchestration thêm vào để tạo dịch vụ thật xử lý chức nghiệp vụ độc lập dựa ứng dụng enterprise bên Những dịch vụ gọi dịch vụ tổng hợp (composite service) Trên tầng service orchestration ứng dụng tổng hợp sử dụng service and cung cấp giao diện cụ thể cho người sử dụng Hình 2-10 – Kiến trúc phân tầng hệ thống SOA 2.6.1 Tầng kết nối Mục đích tầng kết nối kết nối đến ứng dụng enterprise tài nguyên bên cung cấp chúng thành dạng dịch vụ Tầng tầng chuyên giao tiếp với nhà cung cấp, hoạt động chuyển đổi (adapter) ứng dụng phi dịch vụ mạng dịch vụ khác Tùy vào ứng dụng cụ thể mà chuyển đổi tương ứng sử dụng Trang 27 Về bản, tầng dùng để thực kết nối đến hệ sở liệu Những ngơn ngữ lập trình đại cung cấp tập hàm API cho phép truy cập đến hầu hết sở liệu thông dụng Với ứng dụng enterprise lại khác, nhà cung cấp cung cấp tập hàm API khác 2.6.2 Tầng orchestration Tầng orchestration chứa thành phần đóng vai trò vừa dịch vụ sử dụng vừa dịch vụ cung cấp Những dịch vụ sử dụng dịch vụ tầng kết nối dịch vụ orchestration khác để kết hợp chức cấp thấp thành dịch vụ hoạt động cấp cao hơn, có hành vi gần với chức nghiệp vụ thực Simple composite service : dịch vụ đơn kết hợp lời triệu gọi đến dịch vụ bên dưới, hoạt động mẫu mặt tiền Chúng giúp đơn giản hố qua trình tương tác với dịch vụ cấp thấp che dấu tính phức tạp tới người sử dụng dịch vụ tầng cao Process service: dịch vụ định tiến trình kết nối dịch vụ cấp thấp Điều hữu dụng thiết kế dịch vụ kết nối đến nhiều hệ thống enterprise bên sau thực thi tiến trình Ví dụ dịch vụ “Submit New Order” xem process service thực tương tác với sở liệu khách hàng để lấy thông tin chi tiết khách hàng, định dựa thông tin tài khoản khách hàng, tương tác hệ thống lưu kho hệ thống tài để hồn tất u cầu đặt hàng Bởi process service có đặc tính gần với quy trình nghiệp vụ doanh nghiệp nên có nhiều nỗ lực để chuẩn hoá cách thức định nghĩa chúng WSBPEL (Web Service Business Process Execution Language) tên tổ chức OASIS chọn cho chuẩn Cho đến tháng năm 2004, chuẩn liên tục cập nhật để mơ tả nhiều process đa dạng với mức độ phức tạp ngày cao Trang 28 Data service : dịch vụ cung cấp liệu thu thập từ nhiều nguồn liệu tách biệt khác Trong nhiều trường hợp liệu tồn nhiều ứng dụng sở liệu khác Ví dụ thường thấy thơng tin khách hàng Doanh nghiệp thường lưu trữ thông tin khách hàng hệ thống đặt hàng, hệ thống tài hệ thống CRM Mỗi hệ thống chứa phần liệu toàn liệu khách hàng Data service thường không xem dịch vụ orchestration mà chịu trách nhiệm tương tác trực tiếp với sở liệu bên thông qua phương thức truy cập phi dịch vụ (non-service oriented accesss) JDBC J2CA Chúng cung cấp liệu từ ứng dụng độc lập kết hợp liệu từ nhiều nguồn khác Data service thường sử dụng số ngôn ngữ truy vấn chế mô tả khác để xác định quan hệ lược đồ liệu (data schema) Các công nghệ phổ biến SQL, XSLT Xquery XQuery XSLT hai công nghệ việc truy vấn liệu bối cảnh Web Service chúng xử lý kết xuất liệu dạng XML 2.6.3 Tầng ứng dụng tổng hợp Dữ liệu truyền qua lại dịch vụ cuối định hướng đến người sử dụng theo nhiều dạng giao diện khác Tầng xem tầng tích hợp cuối q trình tích hợp Trang 29 Hình 2-11 – Một công thông tin cung cấp thông tin vùng nhìn Hình 2-12 – Các portlet truy xuất liệu từ nhiều nguồn khác cung cấp dạng dịch vụ Trang 30 Tầng ứng dụng tổng hợp tầng đơn sử dụng dịch vụ, cung cấp ứng dụng cho người dùng cuối Nhờ tính linh hoạt SOA đặc tính dịch vụ tổng hợp từ tầng orchestration, ứng dụng tổng hợp có khả biểu diễn loại thông tin từ nguồn thông tin, chí cịn cho phép người sử dụng gửi thơng tin tổng hợp mà thơng tin phân phối lại cho hệ thống bên Bản chất giao diện khó xây dựng Chúng khó chia thành thành phần logic tương tác với theo dạng chuẩn hố Đơi cố gắng phân rã thành phần giao diện thành phần nhỏ lại làm bố cục chặt chẽ khó sử dụng ứng dụng gốc Tầng ứng dụng tổng hợp chia làm hai tầng nhỏ Portal tầng Portlet Một Portlet định nghĩa ứng dụng chạy cửa số thành phần ngữ cảnh lớn với tách biệt rõ ràng Portlet ngữ cảnh Portlet thành phần cung cấp sử dụng dịch vụ Có điều dịch vụ chúng cung cấp dạng dịch vụ giao diện đặc biệt thiết kế đặc biệt để sử dụng UI Framework consumer (một Portal) Mỗi portlet sử dụng số dịch vụ liên quan tầng orchestration bên cho phép người sử dụng gửi thông tin bổ sung Công nghệ web Java Server Faces (JSF) ASP.NET hỗ trợ xây dựng portlet Portal khung tích hợp sử dụng Porlet, trang bị cho chúng vẻ thống thể thành giao diện hoàn chỉnh cho người dùng cuối Kiến trúc hướng dịch vụ thật đem đến lợi ích to lớn Thế để đạt lợi ích ta phải xây dựng triển khai thành cơng hệ thống SOA Chương trình bày vấn đề Trang 31 Chương XÂY DỰNG HỆ THỐNG SOA Chương trình bày vấn đề liên quan đến việc xây dựng triển khai hệ thống SOA thực tế cách hiệu quả, bao gồm phân tích thách thức gặp phải xem xét qui trình bước nên thực xây dựng hệ thống SOA 3.1 Những thách thức xây dựng hệ thống SOA Những lợi ích đạt hệ thống SOA rõ ràng Thế việc triển khai hệ thống SOA điều dễ dàng Trong thời gian qua, chứng kiến thay đổi mơ hình tính tốn tổ chức Từ mơ hình tính tốn tập trung (mainframe) sang mơ hình phân tán client/server, sau kiến trúc dựa tảng Web phát triển lớn mạnh Internet Và nay, q trình cịn tiếp tục Chúng ta thời kỳ độ sang mơ hình tính tốn dựa dịch vụ kiến trúc hướng dịch vụ (SOA) Với chuyển đổi có thảo luận, tranh cãi, kinh nghiệm…; có người “dẫn đường” người “nối bước”; có người “chiến thắng” người “thất bại”; có hệ thống vận hành hiệu hệ thống bị đổ vỡ… Lần khác Ta xem xét vấn đề mà gây nhiều trở ngại cho trình triển khai hệ thống SOA Phần trình bày thách thức mà tổ chức phải đối mặt tương ứng với pha dự án triển khai thực tế • Xác định dịch vụ ► Dịch vụ gì? Chức nghiệp vụ cần cung cấp dịch vụ? Độ “mịn” (granularity) dịch vụ tốt? ► Việc xác định dịch vụ định đối tượng cung cấp dịch vụ cách thích hợp, hiệu giai đoạn quan trọng giải pháp Trang 32 hướng dịch vụ Trong thực tế, nhiều chức nghiệp vụ tương tự cung cấp nhiều hệ thống tổ chức • Phân bổ dịch vụ ► Ta nên đặt dịch vụ vị trí hệ thống? ► Các dịch vụ thường hoạt động dựa thực thể nghiệp vụ Các đối tượng lưu quản lý hệ thống Vị trí thực thể vị trí tốt để đặt dịch vụ Tuy nhiên, đặc tính hệ thống phân tán nên đối tượng phân bố rải rác nhiều vị trí có tình trạng đối tượng quản lý nhiều nơi Vì thế, đồng liệu hệ thống trở nên yêu cầu quan trọng Trong môi trường dịch vụ đặt đâu? • Xác định miền dịch vụ ► Làm gom nhóm dịch vụ thành miền luận lý (logic domain)? ► Việc phân loại, gom nhóm dịch vụ thành miền luận lý đơn giản hóa kiến trúc hệ thống giảm số lượng thành phần cần xây dựng Ngoài ra, việc định nghĩa miền luận lý ảnh hưởng đến nhiều khía cạnh khác kiến trúc hệ thống cân tải (load balancing), điều khiển truy cập (access control), phân chia theo chiều sâu hay chiều rộng xử lý nghiệp vụ Tuy nhiên, điều khó khăn đạt đồng quan điểm đơn vị, phận kỹ thuật tính hợp lý miền tạo • Đóng gói dịch vụ ► Làm bao bọc chức sẵn có hệ thống cũ vào dịch vụ? ► Nếu hệ thống thiết kế quan tâm hỗ trợ vấn đê tích hợp với hệ thống vấn đề dễ dàng Tuy nhiên, hệ thống cũ trước xây dựng the mơ hình kín, đóng gói (monolithic) chứa tồn thơng tin ngun tắc qui trình Trang 33 xử lý nay, tích hợp, thơng tin cần chia sẻ phân bố nhiều ứng dụng khác • Service orchestration: ► Làm để tạo dịch vụ tổng hợp (composite service)? ► Nhu cầu kết hợp nhiều dịch vụ để đáp ứng nhiều yêu cầu phức tạp từ đối tượng sử dụng có thực Vấn đề kết hợp dịch vụ cách có hiệu quả, theo qui trình với ràng buộc phức tạp • Định tuyến dịch vụ ► Làm để chuyển yêu cầu từ đối tượng sử dụng dịch vụ đến dịch vụ hay miền dịch vụ thích hợp? ► Một hệ thống SOA phải có tính độc lập địa cho đối tượng sử dụng service hệ thống Ngòai phải quan tâm đến vấn đề hiệu suất hoạt động hệ thống việc định vị dịch vụ trình chiếm nhiều thời gian • Quản lý dịch vụ ► Vấn đề quản lý bảo trì dịch vụ, việc tạo xây, theo dõi thay đổi dịch vụ cho có hiệu quả? • Chuyển đổi thơng điệp chuẩn dịch vụ ► Làm để lựa chọn chuẩn định dạng thông điệp trao đổi chuẩn? Làm xây dựng chuẩn định dạng liệu mà hệ thống có khả hiểu xử lý Ngồi khó khăn tổ chức với đặc thù riêng phải đối diện với vấn đề khác trìnhtriển khai hệ thống ... niệm kiến trúc hướng dịch vụ (SOA), đặc trưng ích lợi đạt mơ hình kiến trúc Ngồi ra, chương sâu vào tìm hiểu tầng kiến trúc bên mơ hình SOA 2. 1 Kiến trúc hướng dịch vụ ? Kiến trúc hướng dịch vụ. .. thành phần xử lý kiến trúc dịch vụ Trang 12 2 .2. 2 Các dịch vụ tự hoạt động Các dịch vụ cần phải triển khai hoạt động thực thể độc lập mà không lệ thuộc vào dịch vụ khác Dịch vụ phải có tính bền... đến đối tượng bên dịch vụ thơng qua số coarse-grained interface Hình 2- 4 Một dịch vụ cài đặt tập đối tượng fine-grained thân đối tượng lại sử dụng trực tiếp qua mạng Trong service cài đặt đối tượng