Đề 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