Đề tài Nghiên cứu kiến trúc hướng dịch vụ (service-Oriented architecture) và giải pháp của oracle

TRƯỜNG ĐẠI HỌC SƯ PHẠM HÀ NỘI KHOA CÔNG NGHỆ THÔNG TIN …………… a & b …………… BÁO CÁO NCKH ĐỀ TÀI: NGHIÊN CỨU KIẾN TRÚC HƯỚNG DỊCH VỤ (SERVICE-ORIENTED ARCHITECTURE) VÀ GIẢI PHÁP CỦA ORACLE MỤC LỤC Chương 1: Tổng quan về SOA Thực trạng hiện tại và một số mô hình trong hệ thống phân tán Thực trạng Một số mô hình trong hệ thống phân tán Giới thiệu kiến trúc hướng dich vụ SOA Kiến trúc hướng dịch vụ là gì? Các nguyên tắc chính của hệ thống SOA Các tính chất của hệ thống SOA Lợi ích của SOA Kiến trúc phân tầng chi tiết của SOA Một số mô hình triển khai SOA Xây dựng một hệ thống SOA Chu trình phát triển của một hệ thống SOA Các kỹ thuật hỗ trợ Dịch vụ và nguyên tắc thiết kế một dịch vụ Vấn đề bảo mật trong SOA Đặt vấn đề Giới thiệu một số kiến trúc hướng dịch vụ Giới thiệu một số chuẩn trong XML Vấn đề tích hợp trong SOA Quản lý tiến trình nghiệp vụ Kết luận Chương 2: Bộ giải pháp về SOA của Oracle Oracle SOA Suite hiện thực Web service với Jdeveloper Giới thiệu về SOA Suite Ứng dụng của SOA Suite Service Bus BPEL engine BPEL Designer Kết luận Chương 3: Thử nghiệm thực tế phần mềm BPEL của Oracle Thử nghiệm phần mềm SOA suite Xây dựng một số service trong website bán hàng cho một book_cafe. Chương 4. Kết luận chung Kết quả đạt được Hướng phát triển Phụ lục tham khảo Danh sách hình Danh sách các thuật ngữ và khái niệm Lời mở đầu Ngày nay, công nghệ thông tin đang ngày càng phát triển, trở thành ngành mũi nhọn trong chiến lược phát triển kinh tế của mỗi quốc gia. Đối tượng phục vụ chủ yếu hiện nay của CNTT là các tổ chức, các cơ sở doanh nghiệp. Với sự phát triển của Internet và với xu thế hội nhập chung của toàn thế giới, các tổ chức, doanh nghiệp cần bắt tay, phối hợp hoạt động và chia sẻ tài nguyên với nhau để nâng cao hiệu quả hoạt động. Khi đó các sản phẩm sẽ ngày càng phức tạp, kéo theo chi phí sản xuất, quản lý và bảo trì. Đặc biệt, ngành công nghệ phần mềm còn đối mặt với vấn đề hóc búa là bảo mật, và tái sử dụng lại các hệ thống sẵn có, vấn đề không tương thích về hệ thống giữa các tổ chức hợp tác với nhau. Để giải quyết vấn đề trên người ta đã đưa ra nhiều giải pháp và hiện nay, một giải pháp đang được quan tâm là kiến trúc hướng dịch vụ (Service Oriented Architecture – SOA). Các ứng dụng khi sử dụng dịch vụ này chỉ cần gửi thông điệp yêu cầu đến một dịch vụ (service) khác và chờ nhận kết quả từ dịch vụ đó và dịch vụ này không phụ thuộc vào môi trường hệ điều hành, ví dụ như các dịch vụ WEB hiện nay chẳng hạn, nó thể hiện rất rõ ý tưởng này. Công nghệ SOA giúp chúng ta trong việc phát triển các services này rất hiệu quả. Hiện nay nhiều công ty phần mềm lớn trên thế giới đều quan tâm phát triển hệ thống này ví dụ như Oracle, IBM, Microsoft,… Mong muốn tìm hiểu một cách khái quát về công nghệ SOA và những lợi ích đạt được của kiến trúc này chính là lý do em thực hiện đề tài: Kiến trúc hướng dịch vụ (Service Oriented Architecture - SOA) và giải pháp của Oracle. Mục tiêu của đề tài: Gồm những vấn đề sau: 1. Đề tài tập trung vào việc nghiên cứu một cách tổng quan về SOA - Nghiên cứu cơ sở lý thuyết của kiến trúc SOA, các tính chất và lợi ích của kiến trúc này. - Tìm hiểu những vấn đề liên quan đến xây dựng hệ thống SOA và các nguyên tắc thiết kế hệ thống này. - Ứng dụng vấn đề bảo mật trong kiến trúc hướng dịch vụ. Tìm hiểu một số chuẩn bảo mật trong XML và Web Service - Khả năng tích hợp hệ thống và quản lý các quy trình nghiệp vụ 2. Giải pháp của Oracle, cụ thể với phần mềm SOA Suite - Tìm hiểu thực tế phần mềm SOA Suite và các thành phần liên quan. - Môi trường phát triển và cách thiết kế, xây dựng ứng dụng, thực thi và quản lý các tiến trình nghiệp vụ 3. Viết một vài servies sử dụng công nghệ SOA trên ngôn ngữ BPEL của Oracle, bằng phần mềm SOA Suite - Xây dựng một ứng dụng nhỏ dùng phần mềm SOA Suite Chương 1: Tổng quan về SOA 1.1 Thực trạng hiện tại và một số mô hình trong hệ thống phân tán. 1.1.1. Thực trạng Phần mềm ngày nay đang dần trở nên phức tạp và dường như đang vượt quá sự kiểm soát của các mô hình hiện có. Theo Albert Einstein: “Mọi việc nên thực hiện theo cách đơn giản đến mức có thể… ”. Hiện nay, có nhiều hệ thống phần mềm đang được xây dựng với kiến trúc khá phức tạp với chi phí phát triển và bảo trì cao, đặc biệt là những phần mềm cao cấp. Độ phức tạp của các hệ thống kiến trúc phần mềm ngày một tăng do một số nguyên nhân sau: Sự xuất hiện của nhiều công nghệ mới tạo nên môi trường không đồng nhất trong khi nhu cầu chia sẻ, tương tác, trao đổi của các hệ thống không thể tiến hành trong môi trường như thế. Giải quyết vấn đề này nghĩa là các doanh nghiệp cần phải thay đổi hệ thống theo một chuẩn thống nhất chung nào đó. Điều chủ yếu là hệ thống cũ cần được sử dụng lại chứ không phải là gỡ bỏ thay mới bởi vấn đề chi phí cho thiết lập một hệ thống quản lý mới tốn kém hơn nhiều so với chuyển đổi cái cũ. Vấn đề này đưa đến một khái niệm là “Tích hợp hệ thống ” (Enterprise Architecture Intergration - EAI) – đang được nhiều tổ chức quan tâm đầu tư với mức chi phí cao dẫn đầu hiện nay cho các dự án dạng này. Vấn đề lập trình dư thừa và tái sử dụng. Chẳng hạn, một doanh nghiệp có nhiều chi nhánh khác nhau, mỗi chi nhánh lại có một hệ thống tách biệt và xây dựng ở những thời điểm khác nhau và cần kết nối lại với nhau sẽ không tránh khỏi việc sử dụng dư thừa tài nguyên, dữ liệu không đồng nhất… Hầu như mọi tổ chức đều phải đối mặt với vấn đề tích hợp vì nhiều lí do như mở rộng thêm chi nhánh, thêm hệ thống bạn hàng mới, hoặc là cần kết nối các hệ thống có sẵn… Vấn đề kéo theo là chi phí thay đổi mã nguồn cũ, kiểm thử, bảo trì… Thực trạng này tạo thêm một áp lực nặng nề với các doanh nghiệp và tổ chức, các nhà phát triển phần mềm. 1.1.2. Một số mô hình trong hệ thống phân tán Ba kiến trúc phân tán phổ biến nhất hiện nay là DCOM, CORBA và EJB. Các kiến trúc này là sự mở rộng của hệ thống hướng đối tượng bằng cách cho phép phân tán các đối tượng trên mạng. Đối tượng đó có thể không nằm trong vùng không gian ứng dụng, hoặc nằm trên một máy khác không chứa ứng dụng nhưng vẫn được tham chiếu sử dụng như một phần ứng dụng. CORBA - Common Object Request Broker Architecture CORBA được định nghĩa bởi Object Managerment Group (OMG), là một kiến trúc phân tán mở, độc lập nền tảng và độc lập ngôn ngữ. CORBA Common Model (CCM) định nghĩa ra qui trình thiết kế, phát triển, đóng gói, triển khai và thực thi các thành phần phân tán. CCM định nghĩa khái niệm Ports cho các thành tố. Các Ports này được dùng để kết nối các thành phần có sẵn với nhau, tạo các hệ thống phân tán phức tạp hơn. Ưu điểm của CORBA: có thể thoả mãn mọi ngôn ngữ, nền tảng phần cứng, giao thức mạng và công nghệ để phát triển CORBA. Nhược điểm: là ngôn ngữ lập trình cấp thấp, khó học và cần đội ngũ phát triển có kinh nghiệm. Các đối tượng CORBA khó có thể tái sử dụng. DCOM – Distributed Component Object Model DCOM là mô hình phân tán dễ dàng triển khai với chi phí thấp, hỗ trợ tigh coupling giữa các ứng dụng và hệ điều hành. Mô hình Component Object Model (COM) định nghĩa cách thức các thành phần clien liên lạc và trao đổi với nhau trên một máy. DCOM mở rộng COM bằng cách sử dụng các giao thức mạng chuẩn khi cần trao đổi dữ liệu với các máy khác trong mạng. Ưu điểm: tính ổn định, không phụ thuộc vị trí địa lý, quản lý kết nối hiệu quả và dễ dàng mở rộng. Thuận lợi cho các doanh nghiệp sử dụng các ứng dụng cùng chạy trên nền Windows. Nhược điểm: tất nhiên các công nghệ này chỉ chạy được trên nền windows Hình 1: Mô hình tương tác của các đối tượng trong kiến trúc DCOM EJB – Enterprise Java Bean Là kiến trúc dùng bên phía máy chủ dùng cho việc triển khai các ứng dụng phân tán hướng đối tượng cỡ vừa và lớn Kiến trúc EJB có 3 tầng với tầng đầu là tầng trình diễn, tầng thứ hai là tầng xử lý nghiệp vụ, tầng thứ 3 là các tài nguyên như cơ sở dữ liệu máy chủ. EJB là một kiến trúc tốt cho tích hợp hệ thống vì nó độc lập trên nền tảng, nhưng nó không phải là một chuẩn mở và khả năng giao tiếp với các chuẩn khác còn hạn chế. Hình 2: Mô hình tương tác của các đối tượng trong kiến trúc EJB Tóm lại, các kiến trúc trên đều hướng đến vấn đề xây dựng kiến trúc hướng dịch vụ nhưng chúng còn gặp phải một số vấn đề như: Tigh coupling: kiến trúc triển khai cài đặt phía nhà cung cấp và phía sử dụng dịch vụ phải giống nhau. Những chuẩn trên đa phần là những chuẩn đóng. Ví dụ: đối tượng java trong mô hình EJB chỉ trao đổi được với các đối tượng cùng mô hình và không thể trao đổi được với các đối tượng DCOM. Lượng thông tin trong mỗi lần giao dịch là ít, được thực hiện nhiều lần vì vậy dẫn đến chiếm dụng băng thông sử dụng và thời gian đáp trả dữ liệu nhanh. Một vấn đề đặt ra là làm thế nào để các hệ thống phân tán phát triển trên các công nghệ khác nhau có thể giao tiếp được với nhau? Cách tiếp cận mới này đáp ứng được yêu cầu đó. Đó là cách tiếp cận theo kiểu “kiến trúc hướng dịch vụ.” Giới thiệu kiến trúc hướng dich vụ SOA Kiến trúc hướng dịch vụ là gì Kiến trúc hướng dịch vụ (Service Oriented Architecture) là một hướng tiếp cận với việc thiết kế và tích hợp các phần mềm, chức năng hệ thống theo dạng module, trong đó mỗi module đóng vai trò là một “dịch vụ có tính loose coupling” và có khả năng truy cập thông qua môi trường mạng. Một cách đơn giản thì một hệ thống SOA là tập hợp các dịch vụ được chuẩn hoá trên mạng, trao đổi với nhau trong ngữ cảnh một tiến trình nghiệp vụ. SOA có ba đối tượng chính minh hoạ trong hình sau: Hình 3: Sơ đồ cộng tác trong SOA hiện nay Nhà cung cấp dịch vụ (Service Provider) cần cung cấp thông tin về những dịch vụ của mình trong một dịch vụ lưu trữ thông tin dịch vụ (Service Registry). Người sử dụng (Service Consumer) tìm kiếm thông tin về dịch vụ cần thiết trong Service Regisstry sau đó xây dựng kênh giao tiếp với nhà cung cấp. SOA cung cấp các giải pháp để giải quyết các vấn đề tồn tại của các hệ thống hiện nay như: phức tạp, không linh hoạt và không ổn định. Một hệ thống triến khai theo mô hình SOA có khả năng dễ mở rộng, liên kết tốt. Đây chính là điều kiện cơ sở, nền tảng để tích hợp, tái sử dụng những tài nguyên hiện có. Thật ra, tư tưởng về một kiến trúc hướng dịch vụ không phải là mới mà CORBA, DCOM (mô hình của Microsoft), EJB (mô hình của java) đã thực hiện từ lâu, tuy nhiên cách tiếp cận này còn gặp nhiều hạn chế (như đã nói ở trên). SOA không chỉ cải tiến đáng kể mà còn đem đến nhiều ưu điểm nổi trội hơn Các nguyên tắc chính của hệ thống SOA Một hệ thống SOA phải đảm bảo đủ 4 nguyên tắc chính sau: Sự phân định rạch ròi giữa các dịch vụ Do có sự tách biệt giữa thành phần giao tiếp và thành phần thực hiện dịch vụ trong kiến trúc hướng dịch vụ. Các dịch vụ này sẽ thực hiện quá trình tương tác chủ yếu thông qua thành phần giao tiếp. Thành phần này sẽ quy định những dạng thông điệp trong quá trình trao đổi: thông điệp nào sẽ được chấp nhận và thông điệp nào sẽ không được xử lý. Và đây chính là cách duy nhất để các đối tượng bên ngoài có thể truy cập vào thông tin và chức năng của dịch vụ. ta chỉ cần gửi thông điệp được định dạng đến trước để yêu cầu dịch vụ mà không cần biết thông điệp đó sẽ được xử lý như thế nào. Các dịch vụ tự hoạt động Các dịch vụ cần được triển khai và hoạt động như một thực thể độc lập mà không phụ thuộc vào các dịch vụ khác. Dịch vụ phải có tính bền vững cao, nghĩa là nó không bị sụp đổ khi có sự cố. Để thực hiện điều này, các dịch vụ cần duy trì đầy đủ thông tin cần thiết cho quá trình hoạt động của mình để có thể tiếp tục hoạt động trong trường hợp dịch vụ cộng tác của nó bị hỏng, đồng thời sử dụng các biện pháp bảo mật để tránh các cuộc tấn công ồ ạt từ bên ngoài vào như gửi thông điệp lỗi hoặc thông điệp ồ ạt. Đây chính là ý nghĩa của khái niệm Loose coupling 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) của nó ra bên ngoài và hỗ trợ chia sẻ các cấu trúc thông tin, các ràng buộc dữ liệu thông qua các lược đồ dữ liệu (Schema) chuẩn. Như thế hệ thống sẽ có tính dễ liên kết và dễ dàng mở rộng Tính tương thích của các dịch vụ dựa trên chính sách Một dịch vụ muốn tương tác với các dịch vụ khác thì phải thoả mãn các chính sách (Policy), các yêu cầu (Requirements) của dịch vụ đó như: mã hoá, bảo mật. Mỗi dịch vụ phải cung cấp công khai các chính sách và các yêu cầu bảo mật của mình. Các tính chất của hệ thống SOA Loose coupling Vấn đề kết nối ám chỉ các ràng buộc giữa một số module với nhau. Có hai loại kết nối là rời (loose) và chặt (tigh). Các module có tính loose coupling có một số ràng buộc được mô tả rõ ràng, trong khi các module có tính tigh coupling thì lại có một số ràng buộc không được biết trước. Hầu hết các phần mềm đều hướng đến tính loose coupling. SOA sử dụng loose coupling thông qua việc sử dụng hợp đồng và liên kết (contract and binding). Một người sử dụng truy vấn đến nơi lưu trữ và cung cấp thông tin dịch vụ (Registry) để lấy thông tin về loại dịch vụ cần sử dụng. Registry sẽ trả về mọi dịch vụ thoả mãn tiêu chuẩn tìm kiếm. Từ đó người dùng chỉ việc chọn dịch vụ mình cần, thực thi phương thức trên đó theo mô tả để nhận dịch vụ từ Registry. Bên sử dụng dịch vụ không cần phụ thuộc trực tiếp vào tin cài đặt của dịch vụ mà chỉ dựa trên hợp đồng dịch vụ đó hỗ trợ. Tính loose coupling giúp gỡ bỏ những ràng buộc điều khiển giữa những hệ thống đầu cuối. Mỗi hệ thống có thể tự quản lý độc lập làm tăng hiệu suất, khả năng mở rộng và khả năng đáp ứng cao. Loose coupling làm tách biệt giữa bên cung cấp và bên sử dụng, nhưng nó đòi hỏi các interface phải theo một chuẩn và cần một thành phần trung gian quản lý để trung chuyển yêu cầu giữa các hệ thống đầu cuối Tái sử dụng dịch vụ Những dịch vụ được dùng chung bởi tất cả các ứng dụng của một hệ thống SOA gọi là shared infrastructure service. Tái sử dụng dịch vụ loại bỏ thành phần trùng lặp, tăng độ vững chắc trong cài đặt và đơn giản hoá việc quản trị Sử dụng dịch vụ bất đồng bộ Phương thức triệu gọi bất đồng bộ như sau: bên gọi gửi một 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 và trả về kết quả cho bên gọi thông qua một kênh thông điệp. Bên gọi không phải chờ cho đến khi thông điệp được xử lý xong. Phương thức đồng bộ: Trên lý thuyết, SOA có thể sử dụng cả phương thức đồng bộ và bất đồng bộ. Quản lý các Policy Khi sử dụng các dịch vụ trên mạng, tuỳ theo mỗi ứng dụng sẽ có một luật kết hợp riêng gọi là các Policy. Việc quản lý các Policy tăng khả năng tạo ra các đặc tính tái sử dụng dịch vụ vì các Policy được thiết kế tách biệt và tuỳ vào mỗi ứng dụng nên giảm tối đa các thay đổi phần mềm đồng thời có thể chia các nhóm làm việc mà không cần phụ thuộc vào nhau (nhóm phát triển phần mềm và nhóm điều hành,nhóm hỗ trợ). Coarse granularity Khái niệm Granularity trong dịch vụ có thể hiểu theo 2 cách: trong phạm vi toàn bộ kiến trúc của dịch vụ hoặc trong phạm vi từng phương thức của từng interface triển khai. Mức độ granularity cũng có hai loại: coarse – grained (ví dụ dịch vụ cài đặt tất cả các chức năng của một ngân hàng) và fined – grained (ví dụ dịch vụ chỉ hỗ trợ chức năng rút tiền tự động…). Một hệ thống có chứa các đối tượng fined – grained thì phức tạp hơn là hệ thống coarse – grained. Khả năng cộng tác SOA nhấn mạnh đến khả năng cộng tác (interoperability), khả năng mà các hệ thống khác nhau có thể giao tiếp trên nhiều nền tảng ngông ngữ khác nhau. Mỗi dịch vụ cung cấp một interface có thể được triệu gọi thông qua một dạng kết nối. Một kết nối gọi là interoperable chứa trong nó một giao thức và một định dạng dữ liệu mà mỗi client kết nối đến nó đều hiểu. Interoperability đạt được bằng cách hỗ trợ các giao thức và định dạng dữ liệu chuẩn của dịch vụ và client Hệ thống ánh xạ mỗi tính chất và ngôn ngữ qua một đặc tả trung gian. Đặc tả này sẽ chịu trách nhiệm ánh xạ giữa định dạng dữ liệu khả kết (interoperable) đến định dạng của dữ liệu tuỳ thuộc vào hệ thống. Ví dụ Wrb Service là một đặc tả trung gian cho giao tiếp giữa các hệ thống JAX-RPC, JAXM chuyển các đối tượng dạng Java thành SOAP. Tự động dò tìm và ràng buộc động SOA hỗ trợ khái niệm dò tìm dịch vụ (Service discovery). Một người sử dụng cần một dịch vụ nào đó có thể tìm kiếm dịch vụ theo những tiêu chuẩn khi cần. Người sử dụng dịch vụ chỉ cần hỏi một Registry về dịch vụ thoả mãn yêu cầu của họ. Ví dụ, một hệ thống chuyển khoản (Consumer) yêu cầu Registry tìm kiếm tất cả các dịch vụ có khả năng kiểm tra thẻ tín dụng. Registry trả về một tập các thông tin thoả mãn yêu cầu. Các entry chứa thông tin về dịch vụ bao gồm cả phí dịch vụ. Bên sử dụng sẽ chọn một dịch vụ có chi phí thấp nhất và kết nối đến nhà cung cấp dịch vụ đó dựa trên thông tin của entry mà registry tìm được để yêu cầu sử dụng dịch vụ kiểm tra thẻ tín dụng. Trong phần mô tả dịch vụ kèm theo đã có tất cả các tham số cần thiết để thực thi dịch vụ. Bên sử dụng chỉ cần định dạng dữ liệu cần thiết theo mô tả của nhà cung cấp dịch vụ và gửi đi. Nhà cung cấp sẽ thực thi kiểm tra thẻ tín dụng và trả về kết quả là một thông điệp theo đúng định dạng như trong phần mô tả dịch vụ. Mối ràng buộc duy nhất giữa nhà cung cấp và người 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 chứ không phải là ràng buộc trong thời gian biên dịch. Tất cả cá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ới SOA, bên sử dụng không cần biết định dạng của thông điệp yêu cầu cũng như thông điệp trả về, hay địa chỉ dịch vụ khi gọi đến. Bên sử dụng triệu gọi một cách động. Tự hồi phục Một hệ thống tự hồi phục (Self - healing) là một hệ thống có khả năng tự hồi phục sau khi bị lỗi mà không cần đến sự can thiệp của con người. Đây là một yếu tố quan trọng trong các ứng dụng hệ thống phân tán. Độ tin cậy (reliability) là mức độ đo khả năng một hệ thống xử lý tốt như thế nào trong tình trạng hỗn loạn. Trong SOA, mỗi dịch vụ có khả năng hoạt động hoặc ngừng bất cứ lúc nào, nhất là những ứng dụng tổ hợp của nhiều dịch vụ thuộc 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 gặp 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 kiến trúc hỗ trợ kết nối và thực thi động như thế sẽ có khả năng tự phục hồi cao hơn kiến trúc không hỗ trợ tính năng này. Một tính chất cơ bản khác của hệ thống hướng dịch vụ là: có sự tách biệt giữa interface và cài đặt, nên có thể có nhiều cài đặt khác nhau cho một interface. Nếu một thể hiện dịch vụ 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 có được nghĩa là client chỉ tương tác với interface của dịch vụ chứ không tương tác trực tiếp tới cài đặt của dịch vụ. Lợi ích của SOA SOA là một giải pháp hiệu quả và tiết kiệm chi phí Sử dụng lại những thành phần có sẵn Một trong những lợi ích rõ ràng nhất của SOA là giúp công ty sử dụng lại được những tài nguyên có sẵn, kết quả là giảm chi phí cho phần kiến trúc và tích hợp. Ngoài ra nó còn giúp giảm chi phí mua phần mềm mới. Việc tái sử dụng có lợi ích to lớn, thứ nhất là giảm tính dư thừa, thứ hai là sử dụng lại được những thành phần sẵn có để thiết kế phần mềm mới, giảm chi phí phát triển cho từng phần độc lập của mỗi tính năng mới chưa có. Với SOA, thay vì phải “thay đổi”, chúng ta chỉ cần tạo các cầu nối liên hệ giữa các ứng dụng và hệ thống trên môi trường khác nhau. Giải pháp ứng dụng tổ hợp cho doanh nghiệp SOA mang đến khả năng tổng hợp một lớp các ứng dụng mới bằng cách kết hợp chức năng từ các hệ thống có sẵn, cung cấp cho người cuối những chức năng liên kết. Tức là một số tiến trình cũ có khả năng được kết hợp với nhau bên trong một cổng thông tin (portal) giúp cho người dùng có thể truy cập một lần mà vẫn có thể có hàng loạt thông tin về các sản phẩm của các doanh nghiệp. Với SOA, một ứng dụng tổng hợp có thể được tổng hợp dễ dàng bất kể sự khác nhau về địa lý hoặc công nghệ phát triển dịch vụ đó. Điều này cho phép doanh nghiệp phản ứng nhanh theo yêu cầu, giảm chi phí và tăng hiệu quả kinh doanh. Tăng tính linh hoạt và triển khai cài đặt nhờ tính loose coupling Tính loose coupling đem lại lợi ích cho SOA là phía triệu gọi dịch vụ không cần quan tâm đến địa chỉ hay công nghệ cài đặt dịch vụ. Việc triệu gọi dịch vụ thông qua một giao diện chuẩn nên giúp cho các lập trình viên tránh được việc phải lặp lại các công việc tạo mới các service có khả năng hiểu được mọi công nghệ sử dụng trong cùng một hệ thống. Lợi ích thứ hai mà Loose coupling đem lại là với một hệ thống SOA, các doanh nghiệp dễ dàng cung cấp các dịch vụ ra bên ngoài cho một đối tác nào đó sử dụng. Đối tác đó không cần biết cách thức cài đặt và công nghệ của dịch vụ như thế nào. Tương tự, nếu đối tác đó cũng cài đặt hệ thống SOA thì việc tích hợp và sử dụng các dịch vụ cũng dễ dàng hơn nhiều. Cuối cùng, tính loose coupling tăng khả năng triển khai. Chỉ cần bọc những thành phần sử dụng interface ứng dụng lại thành một dịch vụ, ta đã có một thành phần dịch vụ độc lập trong hệ thống SOA như những dịch vụ khác. Thích ứng với những thay đổi trong tương lai Hỗ trợ đa thiết bị và đa nền tảng SOA cung cấp một tầng giao tiếp trừu tượng từ các nền tảng bên dưới. Điều này cho phép hỗ trợ nhiều loại thiết bị đầu cuối khác nhau như các Browser, thiết bị di động như điện thoại, pager, PDA… sử dụng cùng một chức năng mà vẫn có thông tin trả về tuỳ theo dạng thiết bị. Tính chất độc lập về công nghệ này của SOA tiết kiệm rất nhiều cho các công ty về mặt chi phí, đặc biệt là giai đoạn các công nghệ phát triển đa dạng như hiện nay. Tăng khả năng mở rộng và khả năng sẵn sàng cung cấp Nhờ tính độc lập địa chỉ của SOA, ta có thể tăng khả năng mở rộng bằng cách thêm nhiều thể hiện (instance) của một service. Công nghệ chia tải (load - balancing) tự động tìm và định tuyến yêu cầu đến thể hiện service thích hợp. Tương tự, SOA có thể chuyển tiếp các yêu cầu đến một thể hiện khác khi cần, nhờ đó tăng khả năng sẵn sàng phục vụ Kiến trúc phân tầng chi tiết của SOA Ở tầng thấp nhất, tầng kết nối (Connectivity), những dịch vụ được mô hình hoá dựa trên những ứng dụng enterprise bên dưới. Tầng này chứa các dịch vụ như “lấy thông tin chi tiết sản phẩm” hoặc “cập nhật thông tin khách hàng”, chúng tương tác trực tiếp với các hệ thống phi dịch vụ bên dưới. các dịch vụ này là đặc trưng cho mỗi ứng dụng enterprise. Phía bên trên tầng kết nối là một số dịch vụ Orchestration được thêm vào để tạo ra các dịch vụ thật sự xử lý các chức năng nghiệp vụ độc lập dựa trên những ứng dụng enterprise bên dưới. Những dịch vụ này còn gọi là những dịch vụ tổng hợp (Composite service). Tầng trên cùng của service orchestrstion là tầng ứng dụng tổng hợp sử dụng các service và cung cấp giao diện cụ thể cho người sử dụng Hình 3. Kiến trúc phân tầng của SOA Tầng kết nối Mục đích của tầng kết nối là kết nối các ứng dụng enterprise hoặc tài nguyên bên dưới và cung cấp chúng thành dạng những dịch vụ. Tầng này là tầng chuyên giao tiếp với các nhà cung cấp, hoạt động như một bộ chuyển đổi (adapter) giữa các ứng dụng phi dịch vụ và mạng các dịch vụ khác. Tuỳ vào ứng dụng cụ thể mà bộ chuyển đổi tương ứng được sử dụng. Về cơ bản, tầng này có thể được dùng để thực hiện kết nối đến các hệ CSDL. Những ngôn ngữ lập trình hiện đại cung cấp các tập hàm API cho phép truy cập đến hầu hết các hệ CSDL thông dụng. Với các ứng dụng enterprise thì lại khác vì mỗi nhà cung cấp cung cấp tập hàm API khác nhau. Tầng Orchestration Tầng Orchestration chứa các thành phần đơn đóng vai trò vừa là những 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 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 chức năng nghiệp vụ thực hơn. Simple composite service Là những dịch vụ đơn thuần kết hợp với những lời triệu gọi gọi tới các dịch vụ bên dưới, hoạt động như một mẫu mặt tiền. Chúng giúp đơn giản hoá quy trình tương tác với các dịch vụ cấp thấp và che dấu đi tính phức tạp với những người sử dụng dịch vụ ở tầng cao. Process service Là những dịch vụ định ra một tiến trình kết nối các dịch vụ ở cấp thấp hơn. Điều này rất hữu dụng với việc thiết kế các dịch vụ kết nối đến nhiều hệ thống enterprise bên dưới sau đó thực thi như một tiến trình. Ví dụ, dịch vụ “Submit New Order” có thể được xem như một process service thực hiện tương tác với CSDL khách hàng để lấy thông tin khách hàng, quyết định dựa trên thông tin tài khoản của khách hàng, tương tác hệ thống lưu kho và hệ thống tài chính để hoàn tất đơn đặt hàng. Process service có rất nhiều đặc tính phù hợp quy trình nghiệp vụ của doanh nghiệp nên có rất nhiều nỗ lực để chuẩn hoá cách thức định nghĩa ra chúng. Tổ chức OASIS đã đưa ra chuẩn WS – BPEL (Web Service Business Process Execution Language) cho process service Data service Là những dịch vụ cung cấp dữ liệu thu thập được từ nhiều nguồn dữ liệu khác nhau. Trong nhiều trường hợp, dữ liệu cùng tồn tại trên nhiều CSDL và ứng dụng khác nhau. Ví dụ thường thấy là thông tin về khách hàng. Doanh nghiệp thường lưu thông tin về khách hàng trong hệ thống đặt hàng, hệ thống tài chính và hệ thống CRM. Mỗi hệ thống chỉ chứa một phần dữ liệu trong toàn bộ dữ liệu về khách hàng Data service thường không chỉ được xem như một dịch vụ orchestration mà nó còn chịu trách nhiệm tương tác trực tiếp với CSDL bên dưới thông qua những phương thức truy cập phi dịch vụ (non – service oriented access) như JDBC hoặc J2CA. Chúng cung cấp dữ liệu từ những ứng dụng độc lập và kết hợp dữ liệu từ nhiều nguồn khác nhau. Data service thường sử dụng một số ngôn ngữ truy vấn và cơ chế mô tả khác để xác định quan hệ giữa những lược đồ dữ liệu (data schema). Các công nghệ phổ biến hiện nay là SQL, XSLT và Xquery trong đó XSLT và Xquery là hai công nghệ thuần về việc truy vấn dữ liệu trong bối cảnh Web service vì chúng xử lý và kết xuất dữ liệu dạng XML Tầng ứng dụng tổng hợp Dữ liệu truyền qua lại giữa những dịch vụ cuối cùng cũng định hướng đến người sử dụng theo nhiều dạng giao diện khác nhau. Tầng này được xem là tầng tích hợp cuối cùng của quá trình tích hợp. Tầng ứng dụng tổng hợp là tầng đơn thuần sử dụng các dịch vụ, nó cung cấp các ứng dụng cho người dùng cuối. Nhờ tính linh hoạt của SOA và đặc tính của các dịch vụ được tổng hợp từ tầng orchestration, các ứng dụng có khả năng biểu diễn mọi loại thông tin từ mọi nguồn thông tin, thậm chí cho phép người sử dụng gửi thông tin tổng hợp mà thông tin đó sẽ được phân phối lại cho các hệ thống bên dưới. Tầng ứng dụng tổng hợp chia làm hai tầng nhỏ hơn là portal và portlet. Một Portlet được định nghĩa như một ứng dụng chạy trong một cửa sổ thành phần trong một ngữ cảnh với sự tách biệt rõ ràng giữa Portlet và ngữ cảnh của nó. Portlet là thành phần cung cấp và sử dụng dịch vụ. Có điều là chúng cung cấp một dạng dịch vụ giao diện đặc biệt được thiết kế đặc biệt để sử dụng bởi một bộ UI Framework consumer (một Portal). Mỗi Portlet sử dụng một số dịch vụ liên quan của tầng orchestration bên dưới và cho phép người sử dụng gửi thông tin bổ sung. Công nghệ web hiện nay như Java Server Faces (JSF) và ASP.NET đều hỗ trợ xây dựng portlet. Portal là một bộ khung tích hợp sử dụng các Portlet, trang bị cho chúng một vẻ ngoài thống nhất và thể hiện chúng thành một giao diện hoàn chỉnh cho người dùng cuối. Một số mô hình triển khai SOA Mô hình Service Registry Mô hình Service Broker Mô hình Service Bus Xây dựng một hệ thống SOA Có hai phương pháp để thiết kế một hệ thống SOA là Top-down và Bottom-up Phương pháp Top-down: là phương pháp mà ddiem xuất phát của nó là từ các yêu cầu nghiệp vụ để xác định các yêu cầu chức năng các tiến trình và các tiến trình con, các trường hợp sử dụng (use cases) để tiến tới việc xác định các thành phần hệ thống. (component) và các dịch vụ… Bottom-up: dựa trên phân tích tình trạng các tài nguyên của hệ thống hiện có và sẽ tái sử dụng các tài nguyên này trong việc xây dựng các dịch vụ mới Chu trình phát triển của SOA: develop-->integrate-->orchestrate-->deploy-->manage-->secure-->access 1. Develop Giai đoạn này ta tập trung phát triển các service và tạo web service Mô hình: webservicemyservice - web service: để bên ngoài tương tác với service chúng ta - myservice: hiện thực service bằng Java class hoặc EJB Trong quá trình hiện thực myservice thì có thể service của chúng ta cần giao tiếp với cơ sở dữ liệu. Bình thường thì chúng ta có thể tự mở CSDL và query sau đó đóng gói dữ liệu vào trong class Java. Điều này dễ dàng thực hiện trong các ứng dụng nhỏ. Vì người làm database và ứng dụng rất gần với nhau, đôi khi chỉ là một. Nhưng với những vấn đề lớn, thì hầu như là người phát ứng dụng không biết hoặc biết rất ít về database. Do đó, chúng ta nên mapping giữa CSDL và đối tượng Java, khi bạn mapping xong thì bạn chỉ cần read hoặc write 1 đối tượng thì hệ thống runtime sẻ lo công việc query CSDL. 2. Integrate Bạn có thể tích hợp component hoặc tích hợp rule. Rule: nhằm để tách giữa ứng dụng và nghiệp vụ, do đó bạn có thể thay đổi nghiệp vụ 1 cách đễ dàng mà không cần phải code lại chương trình 3. Orchestrate Đây là giai đoạn tích hợp các service. Khi bạn có qui trình nghiệp vụ thì bạn đưa ra được business workflow. Từ business workflow bạn phân tích ra các service. Bạn sẻ hiện thực hoặc sử dụng lại các service. Khi có đầy đủ các service thì chúng ta phải tích hợp lại. Công việc tích hợp này chúng ta dùng ngôn ngữ BPEL để tích hợp các service. Bạn có thể sử dụng BPEL của IBM hoặc của Oracle. Với bộ design của BPEL chúng ta có thể tích hợp các service 1 cách nhanh chóng và dễ dàng. Business process được tích hợp xong cũng được xem là một service và nó tương tác với bên ngoài thông qua web service. Và nó có thể được tích hợp bởi các business process khác. 4. Deploy Khi các service đã được tạo xong. Bạn test nó cẩn thận và đạt rồi thì chúng ta tiến hành đóng gói các service và sau đó deploy nó lên server đích. 5. Manage và Secure Đối với các hệ thống phát triển theo mô hình SOA thì hệ thống ngày càng phức tạp dần, và càng ngày có nhiều service hơn do đó thì yêu cầu quản lí và bảo mật các Web service được đặt ra. Hiện nay bạn có thể sử dụng Oracle Web service Manager cho công việc bảo mật này. Với bộ này chúng ta có thể đưa ra những chiến lược cho việc tổ chức và bảo mật một cách dễ dàng. 6. Access Chúng ta bắt đầu truy xuất vào trong hệ thống. Các kỹ thuật hỗ trợ SOA Giao thức vận chuyển SOAP Định dạng WSDL Định dạng UDDI và ebXML Kiến trúc service Dịch vụ và các nguyên tắc thiết kế một dịch vụ Service: là những ứng dụng mà mình muốn cho bên ngoài sử dụng. Thí dụ: Chương trình chỉ có 1 class Java đơn giản như sau Class HelloWorld { public HelloWorld() { super();}public String sayHello(String str) { Return “Hello, “ + str; } } Khi người khác sử dụng chương trình của chúng ta và họ truyền vào 1 chuỗi str, thì chúng ta sẻ trả lại cho họ chuổi “Hello, “ + str. Chuẩn để thiết kế có thể theo các bước sau: Apply naming standards. Vì một interface miêu tả cho bản chất của service nên cần phải có những nguyên tắt đặt tên cho nó: + Tên của service. + Tên của phương thức( operation). + Giá trị message (message value). Thừơng thì sẽ đặt tên giống như cách đặt tên của hướng đối tượng(OO): Object thường là danh từ, method thường là động từ. Ví dụ: service Employee thì có các phương thức là: GetID, GetName. Apply a suitable level of interface granularity. Tính chất hạt của interface là thể hiện mức độ mịn hay thô (coarse-grained, finer-grained ). Mức độ mịn hay thô là phụ thuộc vào tính reuse của service. Cụ thể nếu một service ở tầng business process thì sẽ thô hơn những service ở tầng application Design service operations to be inherently extensible Bên cạnh tính reusability, composability thì trong suốt quá trình thiết kế phải đảm bảo được tính extensibility (tính có thể mở rộng được). Một điều quan trọng nhất cho việc thiết kế những phương thức và những thông điệp là đảm bảo tính hoạt động độc lập cao nhất. Identify known and potential service requestors. Sẽ hữu ích và thực tế hơn nếu trong quá trình thiết kế ta đoán trước những tính năng sẽ phục vụ cho những yêu cầu mới trong tương lai, từ đó kết hợp với những yêu cầu hiện tại áp dụng cho việc thiết kế cho service của mình. Điều này sẽ dẫn đến thêm vào môt số phương thức có thể không cần thiết cho những yêu cầu ở hiện tại so với phạm vi, ngân sách, hay những yêu cầu có liên quan. Vì vậy cũng phải sàng lọc lại để không ảnh hưởng nhiều đến project hiện tại. Consider using modular WSDL documents Sử dụng những file XSD schema để định nghĩa những kiểu dữ liệu phức tạp, từ đó ta có thể sử dụng cùng một file XSD schema cho nhiều file WSDL. Khai báo import được sử dụng trong thẻ types của file WSDL để khai báo cho một file XSD schema hay một file WSDL khác. (dữ liệu nên đặt trong file .xsd hay . wsdl) Use namespaces carefully. Chuẩn WS-I Basic Profile yêu cầu đặt thuộc tính targetNamespace để định ra một namespace cho một file WSDL hoặcmột file XSD schema được nhúng trong những file WSDL Use the SOAP document and literal attribute values Có hai thuộc tính quan trọng trong SOAP message là stype trong phần soap:binding và use trong phần soap:body. Nó liên quan đến dạng format và kiểu dữ liệu trình bày của SOAP message. Thuộc tính stype có hai giá trị là “document ” và “rpc”. Thuộc tính use có hai giá trị là “literal ” và “encoded”. Người ta thường dùng kết hợp 3 thuộc tính như sau: + style:RPC + use:encoded + style:RPC + use:literal + style:document + use:encoded + style:document + use:literal Use WS-I Profiles even if WS-I compliance isn't required Giúp ích cho ta trong phần bảo mật các service thông qua gateway hoặc agent Document services with metadata Khi thiết kế một document cho server theo kiểu metadata nghĩa là khi có một request đến sẽ trả về cho requestor tất cả những thông tin của service provider. Thông tin trả về bao gồm: file WSDL, file XSD schema, và địa chỉ của policies. Vấn đề bảo mật trong SOA Đặt vấn đề Với việc phát triển không ngừng của công nghệ web service đã tạo nên những ảnh hưởng nhất định trong việc xây dựng các mô hình tính toán phân tán. Các kiến trúc phân tán hướng đối tượng DOA (Distributed Object Architecture) sử dụng các công nghệ như là CORBA, DCOM, DCE và Java RMI đang nhanh chóng chuyển sang các kiến trúc hướng dịch vụ (SOA) với những công nghệ mới như SOAP, HTTP, XML. Việc thay đổi kiến trúc hệ thống như thế đã dẫn đến những thay đổi nhất định trong việc đưa ra các giải pháp cho vấn đề bảo mật của hệ thống. Hầu hết các giải pháp bảo mật hiện nay đều dựa trên thực trạng là cả hệ thống máy khách và máy chủ đều đặt tại cùng một mạng vật lý (như LAN) hay mạng logic (như VPN). Những giải pháp này đảm bảo an toàn hệ thống hay thắt chặt an ninh thông qua việc giám sát tất cả mọi ngõ ngách ra vào của mạng. Tuy nhiên, với một hệ thống mở như SOA thì các giải pháp này không còn thích hợp nữa Giới thiệu kiến trúc bảo mật hướng dịch vụ Một số yêu cầu đặt ra của kiến trúc Chứng thực Hầu hết các nhà cung cấp dịch vụ đều yêu cầu các bên sử dụng dịch vụ phải được chứng thực trước khi yêu cầu sử dụng dịch vụ được chấp nhận Các đối tượng sử dụng dịch vụ cũng phải chứng thực nhà cung cấp dịch vụ khi nhận được các kết quả trả về Hệ thống nên hỗ trợ nhiều cơ chế chứng thực và các cơ chế này phải đủ linh hoạt để có thể dễ dàng thay đổi theo các yêu cầu đặc trưng của dịch vụ Phân quyền Các đối tượng sử dụng phải có một quyền nhất định nào đó. Việc kiểm tra các quyền này thông qua các chính sách (ví dụ như đối tượng nào được quyền sử dụng các dịch vụ nào, và trong điều kiện gì…) Nên sử dụng nhiều mô hình phân quyền khác nhau: Discretionary Access Control (DAC): mô hình này kiểm soát việc truy cập dựa trên ID của đối tượng muốn truy cập. ID có thế là mật khẩu, tên truy cập hay các dấu hiệu đặc trưng của phần mềm hay phần cứng… Mandatory Access Control (MAC): bảo vệ thông tin bằng cách gán cho mọi thông tin một giá trị “nhạy cảm” và sẽ so sánh giá trị này với giá trị “nhạy cảm” của người truy cập. Đây sẽ là cơ sở để thực hiện việc cấp quyền truy cập thông tin. Mô hình này thích hợp cho các hệ thống đòi hỏi độ an toàn cao. Role - Base Access Control (RBAC): quyết định cho phép truy cập dựa trên vai trò của từng cá nhân và trách nhiệm trong tổ chức của cá nhân đó. Độ tin cậy Phải có cơ chế để bảo vệ môi trường truyền dữ liệu bên dưới cũng như các thông điệp và tài liệu được truyền trên môi trường đó sao cho chúng không bị truy cập bởi các đối tượng không có quyền. Toàn vẹn dữ liệu Bảo vệ dữ liệu không bị xâm hại trong suốt quá trình truyền Cơ chế định danh Nhằm đảm bảo các đối tượng tham gia trong quá trình tương tác không thể phủ nhận vai trò của mình (người gửi không thể phủ nhận những gì mình đã gửi và người nhận không thể chối bỏ những gì mình đã nhận). Yêu cầu này đặc biệt quan trọng trong môi trường thương mại ngày nay khi mà các cuộc gặp gỡ không thể tận mặt được. Có một cơ chế quản lý Kiến trúc an ninh của hệ thống phải cung cấp các cơ chế để quản lý các tính năng ở trên bao gồm quản lý người dùng, quản lý các chính sách bảo mật… Cơ chế ghi nhận Thực hiện tất cả các ghi nhận liên quan đến tất cả các quá trình tương tác của đối tượng với hệ thống Góp phần hỗ trợ cho yêu cầu về xây dựng cơ chế định danh Xử lý bảo mật liên miền Kiến trúc phải cung cấp mô hình tin cậy nhằm bảo vệ quá trình tương tác giữa các web service trong những miền khác nhau Khả năng liên kết cao Khả năng dễ mở rộng, liên kết và tích hợp với các hệ thống khác là một đặc trưng nổi bật trong hệ thống của SOA. Vì thế, yêu cầu kiến trúc bảo mật khi được tích hợp vào sẽ vẫn duy trì tốt nhất đặc trưng này trong SOA Cho phép kiến trúc của ta có thể tích hợp với những giải pháp, sản phẩm về an toàn dữ liệu khác mà không phải bỏ ra chi phí quá cao. Tại những vị trí quan trọng thì việc tích hợp, mở rộng hệ thống như giữa nhà cung cấp và các đối tượng sử dụng dịch vụ; giữa nhà cung cấp dịch vụ và cơ sở hạ tầng của kiến trúc bảo mật bên dưới; giữa những kiến trúc bảo mật của những miền khác nhau phải được thiết kế với các yêu cầu về tính ổn định, đồng nhất và hiệu quả dựa trên các chuẩn mở. Kiểm soát được những thay đổi về yêu cầu bảo mật Trong các giải pháp bảo mật trước đây, mọi tài nguyên, dịch vụ đều dùng chung một chính sách bảo vệ. Giải pháp dùng chung như thế có chi phí không cao nhưng hệ thống sẽ quá lỏng lẻo, cứng nhắc, không thích hợp với đặc trưng về tính đa dạng của các tài nguyên và dịch vụ Trong hệ thống SOA, các dịch vụ ở tầng khác nhau sẽ đòi hỏi chính sách bảo mật khác nhau. Ví dụ, một dịch vụ cần chứng thực theo tên, mật khẩu… Khái niệm kiến trúc bảo mật hướng dịch vụ Mô hình SOSA không hướng đến việc thay thế hoàn toàn các kiến trúc bảo mật hiện có mà muốn đưa ra một giải pháp để liên kết các cơ sở hạ tầng sẵn có. Nghĩa là chúng ta sẽ sử dụng lại các kỹ thuật, dịch vụ bảo mật hiện có dựa trên những nguyên tắc của SOA để tạo nên một kiến trúc bảo mật hướng dịch vụ mới.Mục tiêu là tạo ra một tầng liên kết bên trên các dịch vụ, công nghệ bảo mật đó. Các nghi thức, nguyên tắc, cơ chế vận hành trong SOSA không nên lệ thuộc vào một môi trường thực thi cụ thể nào, thay vào đó nên dựa trên những chuẩn chung của “mô hình uỷ thác” (dựa trên độ tin cậy và sự uỷ quyền). Các nghi thức này bao gồm: Cơ chế định danh một đối tượng, như là đối tượng sử dụng dịch vụ, dịch vụ, tài nguyên, chính sách, nhà cung cấp dịch vụ. Có thể dùng cơ chế định danh URIs (Uniform Resouce Identifier) Định nghĩa của những dấu hiệu mật và chính sách Policy: là một tập hợp các cơ chế xác nhận Policy Cơ chế xác nhận (Policy Assertion): một Policy Assertion có thể xem như một quy tắc liên quan đến cách thức hoạt động của hệ thống. Ví dụ như loại security token nào cần được dùng, thông điệp trao đổi có cần được chứng thực, thời gian trao đổi thông điệp còn được bao lâu?...) Security Token: có thể là dạng binary (X.509, Kerberos ticket ) hay XML (SAML, XrML). Nghi thức tạo, trao đổi các token và policy Việc phát sinh và phân phối các chính sách nên được thực hiện cùng một lúc với việc tạo ra và gửi thông tin định nghĩa về dịch vụ (WSDL, UDDI) Việc tạo và phân phối các security token Đặt các token trong các thông điệp trao đổi Kiểm tra xem các token có phù hợp với yêu cầu. Tóm lại, hệ thống SOA sẽ phải xây dựng được: các nghi thức chung dùng trong việc trao đổi các token của các đối tượng sử dụng dịch vụ và các nguyên tắc chung xử lý các token đó của phía nhà cung cấp. Kiến trúc bảo mật hướng dịch vụ (SOSA) Đối tượng sử dụng dịch vụ và nhà cung cấp dịch vụ trao đổi các security token thông qua Standard-based Security Info Exchange Platform. Cơ sở hạ tầng bảo mật ở tầng dưới được cung cấp ra ngoài dưới dạng các web service. Các kiến trúc công nghệ giải pháp bảo mật hiện có được tái sử dụng lại thông qua tầng Integration backplane. Cấu trúc phân tầng của Standard-based Security Info Exchange Platform Hình 4: Cấu trúc phân tầng của Standard-based Security Info Exchange Platform Tầng Trusted Communication Tầng này được xây dựng dựa trên các đặc tả SOAP Foundation, WS – Security và WS – SecureConversation. WS – Security là thành phần chính hỗ trợ để xây dựng một tầng liên kết bền vững, đảm bảo các luồng thông tin được trao đổi một cách an toàn WS – Security được thiết kế một cách linh hoạt, được sử dụng như là nền tảng trong việc xây dựng nhiều mô hình bảo mật khác nhau, gồm Public Key Infrastructure, Kerberos và SSL. Đặc biệt, WS – Security còn cung cấp hỗ trợ cho nhiều dạng security tokens, nhiều vùng uỷ thác (trust domain), nhiều định dạng chứng thực và nhiều thuật toán mã hoá. WS – Security chỉ định nghĩa thêm cấu trúc mở rộng cho phần đầu của một thông điệp dạng SOAP nhằm mang thông tin bảo mật (chữ ký điện tử, security token, mã hoá…) trong quá trình trao đổi thông điệp với mục đích là phía nhận sẽ tin tưởng vào nội dung của thông điệp cũng như đối tượng gửi thông điệp Với WS – SecureConversation, hai bên đều có thể tái sử dụng được ngữ cảnh bảo mật (security context) trong những lần trao đổi thông điệp, tức là hai bên sẽ không cần thực hiện lại những thủ tục như trong lần trao đổi đầu tiên. Tầng Trusted Service Tầng này được thiết kế dựa trên các đặc tả WS-PolicyAssertion, WS-Security Policy, WS-Authorization, WS-Privacy, WS-PolicyAttachment, WS-Policy. Tầng này cho phép xây dựng các cơ chế tạo ra các Policy mở rộng và gắn kèm các thông tin này vào phần mô tả thông tin của web service WS-Policy: định nghĩa các mô hình cơ bản của policy, policy satement và các cơ chế xác nhận policy WS-PolicyAssertion : định nghĩa một vài cơ chế xác nhận policy tổng quát WS-PolicyAttachment: định nghĩa cách gắn một policy vào một dịch vụ hoặc trực tiếp bằng cách nhúng vào thông tin trong WSDL, hay gián tiếp thông qua UDDI WS-Security Policy: định nghĩa các cơ chế xác nhận policy tương ứng cho các thuộc tính trong WS-Security, như là các yêu cầu về toàn vẹn thông điệp, yêu cầu về độ tin cậy của thông điệp, yêu cầu về loại security token… Đối tượng sử dụng dịch vụ phải lấy được các thông tin này để đáp ứng được các yêu cầu về bảo mật mà dịch vụ đưa ra Tầng Trusted Managerment Web Tầng này được xây dựng dựa trên các đặc tả WS-Federation và WS-Trust. Hai tầng Trusted Communication và Trusted Service đảm bảo cho đối tượng sử dụng và cung cấp dịch vụ tương tác với nhau trong một môi trường bảo mật và tin cậy. Tuy nhiên chúng cần phải có giả thiết rằng Cả hai phía đều sử dụng cùng một công nghệ, một kỹ thuật bảo mật; cả hai phía đều tin tưởng vào cùng một domain. Điều này có nghĩa là vấn đề sẽ phát sinh khi các bên tương tác thuộc những domain khác nhau, sử dụng công nghệ mã hoá khác nhau. Giải quyết vấn đề này là nhiệm vụ của tầng Trusted Managerment Web WS – Trusted WS-Trusted đưa ra một khái nhiệm gọi là Security Token Service (STS). Nhiệm vụ của thành phần này là cấp phát, kiểm tra và chuyển đổi các loại security token khác nhau khi có các yêu cầu. Về cơ bản, vai trò của một STS rất giống với một tổ chức chứng thực PKI (PKI Certifycate Authority), tuy nhiên nó vượt trội hơn với hai đặc điểm nổi bật : Nó cấp phát tất cả các loại token (về quyền, vai trò,…) chứ không chỉ là token dùng để định danh. STS không chỉ đơn giản là cấp phát và chứng thực các token mà còn có khả năng thực hiện việc chuyển đổi các token với nhau (ví dụ như X.509 Certifate -> Kerberos). Đây chính là tính năng khiến nó có vai trò làm trung gian trong quy trình tương tác giữa các đối tượng Vai trò của STS là kết nối các hệ thống bảo mật đơn lẻ tạo thành một liên kết thống nhất với nhau. Các STS phải được thiết kế một cách trong suốt (transparent) với đối tượng cử dụng dịch vụ trong quá trình tương tác. Ta gọi mạng các STS này là Trusted Management Web. Trusted Managerment Web có thể được cấu thành bởi nhiều mạng các STS khác nhau. Mỗi mạng STS cung cấp một dịch vụ tin cậy khác nhau như là máy chủ chứng thực sẽ cung cấp khả năng chứng thực của một STS trong mạng các STS, hay máy chủ quản lý về quyền sẽ có nhiệm vụ kiểm tra về quyền của của nhiều STS WS – Federation WS-Federation sẽ giải quyết các vấn đề liên quan đến việc quản trị các thành phần của kiến trúc bên trong chưa được WS-Trusted đề cập đến: Nên chọn mô hình nào cho các mắt xích STSs? Việc quản lý chu kỳ hoạt động các thành phần của kiến trúc (STS, Policy, cơ chế bảo mật ở tầng dưới…) Quản lý thông tin trạng thái của các policy và token phân tán, cụ thể là cơ chế ghi nhớ lại một lượng thông tin nào đó. Từ đây sẽ phát sinh một vấn đề mới là vấn đề xử lý việc đồng nhất về thông tin. DNS có thể xem là mô hình cho việc giải quyết vấn đề này. Các DNS server sẽ lưu lại kết quả phân giải để khi xử lý yêu cầu tiếp theo, nếu yêu cầu cùng một kết quả thì nó sẽ đáp ứng ngay mà không phải tìm trong các root server. Hỗ trợ cho quá trình lưu lại các ghi chú về thông tin trạng thái, kết quả xử lý… Giới thiệu một số chuẩn bảo mật trong XML WS-Security Là chuẩn được đề xuất dưới sự hợp tác của hãng IBM, Microsoft và Verisign. Hiện chuẩn này đã được tổ chức OASIS thông qua và đang tiếp tục phát triển WS-Security là một chuẩn an toàn bao trùm cho SOAP và cả những phần mở rộng của SOAP - Sử dụng các sercurity token trong phần đầu của các thông điệp SOAP để hỗ trợ cho việc định danh và chứng thực - Sử dụng XML-Encryption để đảm bảo độ tin cậy cho dữ liệu - Sử dụng XML-Signatures đảm bảo tính toàn vẹn và xác thực của dữ liệu WS-Sercurity cũng bao gồm cả việc xác định xem chèn những dữ liệu nhị phân khác biệt và dấu hiệu của XML sercurity trong phần đầu WS – Sercurity cho mục đích xác thực về phân quyền. - Username và password. : định nghĩa một khách hàng của WS có thể cung cấp một username khi có một phiên cần xác thực ; username có thể được gắn với password mảng băm - X.509 Certificate: Một cấu trúc dữ liệu được đánh dấu thiết kế để gửi một khoá công cộng tới một địa điểm nhận. - Kerberos ticket: phân quyền và xác nhận phiên làm việc - SAML (Sercurity Assertion Markup Language). - REL (Right Expression Language) là ngôn ngữ được thêm vào header của WS-Sercurity để phân quyền - XCBF: ngôn ngữ XML Common Biometric Format định nghĩa cho việc xác thực với WS – Sercurity. XML-Signature Được chứng thực bởi tổ chức W3C. Chuẩn này quan tâm đến cú pháp và cách xử lý trong việc chứng thực một thành phần nào đó trong tài liệu XML bằng các công nghệ chứng thực khoá đồng bộ hay bất đồng bộ XML-Encryption Security Assertion Markup Language (SAML) Chuẩn này được đưa ra bởi OASIS. SAML định nghĩa một nền tảng cho việc trao đổi các thông tin bảo mật dưới dạng XML. Những thông tin bảo mật này có thể là: thông tin chứng thực, các quyết định về phân quyền, hoặc là thuộc tính của các đối tượng được lưu trữ ở dạng XML và được cấp phát bởi nơi cung cấp chứng thực SAML SAML cũng định nghĩa các giao thức, quy tắc trong quá trình vận chuyển các thông tin bảo mật Vấn đề tích hợp trong SOA Quản lý tiến trình nghiệp vụ trong SOA Kết luận Chương 1 đã trình bày một cách tổng quan về SOA. Chính vì những lợi ích to lớn mà SOA mang lại, các doanh nghiệp ngày nay đã đầu tư rất nhiều cho công nghệ này để phát triển hệ thống của mình và đạt được hiệu quả không nhỏ. Tuy nhiên, vấn đề tích hợp và quản lý các tiến trình nghiệp vụ cho hệ thống đòi hỏi đội ngũ phát triển có năng lực và kinh nghiệm. Do trình độ có hạn và thời gian gấp rút nên em mới chỉ tìm hiểu được một phần nhỏ về công nghệ SOA. Vấn đề tích hợp và quản lý tiến trình em chưa hoàn thành được. Rất mong thầy nhận xét và chỉ bảo thêm cho em hoàn thành đề tài tốt hơn. Chương 2: Bộ giải pháp về SOA của Oracle Ứng dụng SOA Suite Giới thiệu về SOA Suite SOA Suite là một trong những giải pháp phần mềm chính cho công nghệ SOA của công ty Oracle. SOA Suite cung cấp một môi trường dùng để: Quản lý các dịch vụ một cách hiệu quả Hỗ trợ quá trình thiết kế, phát triển, triển khai và quản lý các tiến trình từ các dịch vụ sẵn có từ môi trường bên ngoài hay bên trong hệ thống SOA Suite gồm ba thành phần chính: ServiceBus: cung cấp môi trường quản lý các dịch vụ nội bộ trong hệ thống BpelEngine: cung cấp môi trường thực thi cho các tiến trình nghiệp vụ BPEL Designer: cung cấp môi trường thiết kế các định nghĩa các tiến trình nghiệp vụ. Hình 5. Mô hình kiến trúc SOA suite ServiceBus Vai trò của Service Bus Service Bus được xây dựng nhằm cung cấp một môi trường kết nối logic giữa các dịch vụ và đối tượng sử dụng dịch vụ thông qua cơ chế truyền thông điệp. Môi trường giao tiếp này là độc lập với xử lý bên trong và được xây dựng dựa trên “cơ sở tri thức liên kết” (Connectivity Knowledge Base – KB). Dữ liệu trong KB bao gồm các thông tin mô tả kết nối vật lý và cách thức xử lý các thông điệp. KB có thể tồn tại dưới dạng những kho lưu trữ ảo như các cơ sở dữ liệu, các tập tin cấu hình, các thông điệp… Các tính năng của Service Bus Độc lập với phần xử lý của các dịch vụ: tính năng này giúp ta có thể xây dựng hệ thống từ nhiều nguồn khác nhau mà không phải quan tâm đến phần xử lý bên trong được xây dựng trên ngôn ngữ hay hệ nền nào. Do đó hệ thống có tính liên kết cao và dễ dàng mở rộng Liên kết dạng loose coupling với các KB: do khả năng thay đổi các môi trường của hệ thống và những thành phần tích hợp cao dẫn đến các KB cũng phải thay đổi theo. Vì vậy tính năng này rất cần thiết. Nếu hệ chịu ít ràng buộc vào KB thì hệ càng ít chịu ảnh hưởng bởi sự thay đổi đó Cung cấp một dịch vụ Boot để thiết lập trạng thái ban đầu cho hệ thống bus. Cơ chế hoạt động của dịch vụ boot này có thể chỉnh sửa linh hoạt thông qua KB của nó. Với dịch vụ boot, ta có thể thiết lập thay đổi trạng thái khởi động ban đầu của service bus khi cần thiết bao gồm một số hoạt động liên quan đến việc nạp và khởi động các thành phần khi cần thiết. Hỗ trợ một số bộ lọc chuẩn: thực hiện tuỳ biến một cách linh hoạt cho cách thức xử lý các dịch vụ, có ý nghĩa trong việc tái sư dụng chức năng dùng chung. Cho phép quản lý cơ chế hoạt động của bus thông qua các KB: hệ thống sẽ linh hoạt hơn vì có thể thay đổi cơ chế thông qua thay đổi nội dung của các KB Hỗ trợ tích hợp với IIS: các dịch vụ không chỉ được dùng trong một môi trường cục bộ mà có thể sẽ có nhu cầu cung cấp chức năng của dịch vụ đó ra bên ngoài. Service Bus và cơ sở tri thức Mỗi Service Bus bao gồm một cơ sở tri thức (KB), nhưng KB này có thể tham chiếu đến nhiều KB khác nữa. Service Bus thực chất là một thư viện liên kết động (DLL) được nạp lên bởi một tiến trình. KB của Service Bus sẽ được chứa trong tập tin cấu hình của tiến trình đó. Các thành phần của Service Bus Dịch vụ: Bootstrapper Bus Manager Filters BpelEngine BpelEngine cung cấp một môi trường thực thi cho các tiến trình nghiệp vụ Bpel Engine nhận vào định nghĩa một tiến trình và một số thông tin khác như các thông tin mô tả web service WSDL và tạo các thể hiện của tiến trình này. Sau đó, với mỗi yêu cầu sử dụng tiến trình nó sẽ tạo ra một thể hiện của tiến trình và thực thi thể hiện này. Bpel engine có thể thực thi nhiều tiến trình, mỗi tiến trình lại bao gồm nhiều xử lý, các xử lý này có thể chứa trong nó những xử lý khác. Bpel engine tạo ra một tiến trình từ thông tin định nghĩa tiến trình đó (dùng ngôn ngữ định nghĩa tiến trình BPEL) và sau đó thực thi tiến trình này Thành phần BPEL Designer BPEL Designer giúp cho người sử dụng định nghĩa các tiến trình theo đúng chuẩn BPEL một cách dễ dàng trực quan và nhanh chóng. Designer cung cấp cho người sử dụng một môi trường phát triển tích hợp IDE có thể hoạt động online hoặc offline Chức năng của BPEL Designer Tạo mới, chỉnh sửa, thiết kế một tiến trình Kết xuất tiến trình ra file ảnh Triển khai một tiến trình mới lên server Chương 4. Kết luận Kết quả đạt được Vì thời gian gấp rút và kiến thức của em còn nhiều hạn chế nên đề tài còn chưa hoàn thành cho đến thời điểm này. Kính mong các thầy cô nhận xét và góp ý để em có thể hoàn thiện đề tài hơn. Hướng phát triển Em sẽ cố gắng hoàn thiện đề tài trong thời gian sớm nhất có thể.