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

ĐẠI HỌC THÁI NGUYÊN KHOA CÔNG NGHỆ THÔNG TIN  ĐỀ TÀI NGHIÊN CỨU KHOA HỌC CẤP SINH VIÊN 2010 Đề tài: KIẾN TRÚC HƯỚNG DỊCH VỤ & ỨNG DỤNG (SERVICE-ORIENTED-ARCHITECTURE) Mã số đề tài Chủ nhiệm đề tài Cố vấn khoa học : S2010-08-21 : Nguyễn Thị Dung : Th.s. Nguyễn Hồng Tân Thái Nguyên 12/2010 i MỤC LỤC MỞ ĐẦU 1 CHƯƠNG 1: TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ (SERVICE-ORIENTED- ARCHITECTURE) 2 CHƯƠNG 2: PHÁT TRIỂN PHẦN MỀM DỰA VÀO SOA 12 CHƯƠNG 3: KẾT QUẢ VÀ THẢO LUẬN 36 41 KẾT LUẬN 42 TÀI LIỆU THAM KHẢO 43 CHỮ KÝ XÁC NHẬN 45 ii MỞ ĐẦU Sự phát triển của Internet đã thúc đẩy nhu cầu cộng tác, làm việc qua mạng và sử dụng các dịch vụ trực tuyến dần trở thành một nhu cầu thiết yếu trong cuộc sống của chúng ta. Điều đó đòi hỏi các ứng dụng không chỉ là những hệ thống hoạt động đơn lẻ trên một máy trạm (máy client) và chịu phụ thuộc vào một nền tảng cố định nào nữa, mà chúng phải là những hệ thống linh động giúp người dùng làm việc “mọi lúc, mọi nơi”. Điều đó đã làm nhà phát triển phải đối mặt với hàng loạt các vấn đề mới như làm sao tích hợp các thành phần phân tán lại với nhau; hay tái sử dụng những thành phần có sẵn; vấn đề triển khai và bảo trì… đang là một vấn đề làm điên đầu các nhà phát triển. Tuy nhiên, một thực tế hiện nay là phần mềm đang ngày càng trở nên phức tạp quá mức và dường như đang vượt khỏi khả năng kiểm soát của các mô hình phát triển hiện có. Nguyên nhân khiến cho hệ thống có độ phức tạp tăng cao là do 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 trao đổi, chia sẻ, tương tác giữa các hệ thống ngày càng tăng và không thể đáp ứng được trong môi trường như vậy. Cùng với đó là vấn đề lập trình dư thừa và không thể tái sử dụng gây tốn kém rất nhiều không những trong giai đoạn phát triển hệ thống mà trong cả vận hành bảo trì phần mềm. Giải pháp cho các vấn đề này là gì? “SOA” hay “Kiến trúc Hướng dịch vụ” là mô hình phần mềm không phải là mới, song đang rất phát triển hiện nay. Đây cũng được coi là giải pháp ưu việt cho các vấn đề đã đề cập ở trên. Kiến trúc này được phát triển từ đầu những năm 2000 đi đầu là IBM. Hiện nay SOA đang được ứng dụng rộng rãi với sự đầu tư nghiên cứu của rất các tập đoàn lớn như IBM, Oracle, SAP, Microsoft… Vậy thật sự SOA là gì ? Nó có thật sự hoàn hảo? Làm thế nào để triển khai SOA? Các vấn đề của hệ thống SOA là gì ? Đó cũng chính là những câu hỏi mà đề tài sẽ nghiên cứu và trả lời. Thái Nguyên, năm 2010 Nguyễn Thị Dung 1 CHƯƠNG 1: TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ (SERVICE-ORIENTED-ARCHITECTURE) 1.1. Kiến trúc phần mềm hiện nay 1.1.1. Một số kiến trúc phần mềm phân tán hiện nay Một số mô hình kiến trúc phân tán đang sử dụng phổ biến nhất hiện nay là: CORBA, RMI, DCOM, và EJB. Các kiến trúc này là sự mở rộng của các 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ể có không gian địa chỉ bên ngoài ứng dụng, hoặc ở một máy khác so với máy chứa ứng dụng trong khi vẫn được tham chiếu sử dụng như một phần của ứng dụng. RMI (Remote Method Invocation): RMI là một phần của bộ J2SDK (Java 2 Platform Standard Development Kit) của Sun và là các hàm thư viện hỗ trợ cho các lời triệu gọi phương thức từ xa và trả về giá trị cho các ứng dụng tính toán phân tán. RMI cho phép chạy các đối tượng trên môi trường JVM (Java Virtual Machine) triệu gọi với đối trượng chạy trên nền JVM khác thông qua việc sử dụng giao diện chung của các phương thức trên client và server. RMI cung cấp cho việc trao đổi truyền thông giữa các chương trình được viết bằng ngôn ngữ lập trình Java. Ưu điểm của kiến trúc đối tượng phân tán RMI là người lập trình chỉ cần lập trình các lời gọi phương thức vì đối tượng được gọi đã hiện diện trong máy ảo của nó. Nhưng nhược điểm là RMI chỉ thích hợp cho các ứng dụng viết trên ngôn ngữ Java. CORBA (Common Object Request Broker Architecture) Là một chuẩn công nghiệp được đưa ra bởi OMG (Object Management Group), cho phép gọi các phương thức từ xa và nhận kết quả trả về, nhưng không giống như RMI, nó có thể được sử dụng khi bên phía gọi và bên phía phương thức được gọi có thể sử dụng ngôn ngữ lập trình khác nhau, bao gồm cả trường hợp cả 2 bên không sử dụng ngôn ngữ Java. CORBA được định nghĩa từ 2 thứ: 2 • Thực thể mà cho phép liên lạc giữa 2 tiến trình được gọi là 1 mô giới yêu cầu đối tượng (Object Request Broker - ORB). • Một giao thức được ORB dùng để liên lạc giữa nhiều tiến trình, được gọi là IIOP (Internet Interoperability Protocol). Ưu điểm của CORBA: các lập trình viên có thể tùy chọn ngôn ngữ lập trình, nền tảng phần cứng, giao thức mạng và công nghệ để phát triển mà vẫn thỏa mãn các tính chất của CORBA. Tuy nhiên CORBA có nhược điểm là nó là ngôn ngữ lập trình cấp thấp, rất phức tạp, khó học và cần một đội ngũ phát triển có kinh nghiệm. Ngoài ra các đối tượng CORBA khó tái sử dụng. Các ứng dụng dựa trên CORBA hiện nay đang dần đi vào thoái trào. DCOM (Distributed Component Object Model) DCOM là công nghệ độc quyền của Microsoft, nó định nghĩa các thành phần của phần mềm được phân tán qua các mạng máy tính để truyền thông với các thành phần khác. DCOM hỗ trợ kết nối giữa các đối tượng và kết nối này có thể được thay đổi lúc đang chạy. Các đối tượng DCOM được triển khai bên trong các gói nhị phân chứa mã lệnh quản lý vòng đời của đối tượng và việc đăng ký đối tượng. Hình 1.1: Mô hình tương tác của các đối tượng DCOM. DCOM mang đến nhiều ưu điểm như: dễ triển khai, chi phí thấp, tính ổn định, không phụ thuộc vào địa lý, quản lý kết nối hiệu quả và dễ mở rộng. Tuy nhiên, các công nghệ của Microsoft có một nhược điểm lớn là bị giới hạn trên hệ nền Windows do chiến lược độc quyền của Microsoft. 1.1.2. Vấn đề phát sinh, nguyên nhân và giải pháp Hiện nay áp lực đặt lên các doanh nghiệp ngày càng lớn như: giảm chi phí đầu tư cơ sở hạ tầng, khai thác có hiệu quả các công nghệ có sẵn, phục vụ yêu cầu khách hàng tốt hơn, đáp ứng tốt các thay đổi thường xuyên về nghiệp vụ, khả năng tích hợp cao với các hệ thống bên ngoài… 3 Xây dựng được hệ thống đáp ứng được tất cả các nhu cầu đó quả là vấn đề vô cùng khó khăn. Bởi vậy một hướng đi mới cho các doanh nghiệp chính là tìm kiếm các giải pháp tích hợp các ứng dụng có sẵn hoặc kết hợp với ứng dụng của các doanh nghiệp khác sao cho thỏa mãn nhu cầu. Trong quá trình kết hợp chắc chắn sẽ gặp những khó khăn: - Không đủ khả năng quản lý quy trình nghiệp vụ - Tốn chi phí tích hợp - Quá nhiều định dạng dữ liệu - Nhu cầu và yêu cầu của khách hàng thường xuyên thay đổi nhanh chóng nhằm tạo ra tính cạnh tranh liên tục. - Vấn đề an ninh bảo mật. Đa phần những khó khăn trên là bắt nguồn từ các nguyên nhân sau: - Phức tạp: Ngày nay mỗi doanh nghiệp công nghệ thông tin có nhiều những hệ thống trên các nền tảng khác nhau, và hoạt động nghiệp vụ khác nhau. Các công ty phát triển phần mềm phải thuê các nhóm nhân viên giàu kinh nghiệm, có khả năng trên các lĩnh vực khác nhau để phát triển, triển khai và quản lý các ứng dụng và hệ thống mà bản thân chúng không đồng nhất. Thêm đó là việc nâng cấp khó khăn, tích hợp cùng với nhau, và bảo mật ngày càng cao đã làm gia tăng tính phức tạp cho hệ thống. - Không linh hoạt: Cùng với sự phức tạp trong chiến lược phát triển, cũng như cơ sở hạ tầng của các công ty. Hầu như công ty nào cũng có những ứng dụng có sẵn nhưng khó nâng cấp, khó kết hợp hoạt động, mà không thể thay thế được. Vấn đề tích hợp trở nên khó khăn hơn và tốn kém hơn. - Không bền vững: Tiếp đó là sự không bên vững của hệ thống. Các phương pháp tiếp cận truyền thống trong việc xây dựng các hệ thống phần mềm thương dẫn đến rất nhiều những giải pháp khác nhau được lắp ghép, tích hợp. Kết quả mỗi khi thay đổi về quy trình nghiệp vụ hay yêu cầu thì các công ty phải chấp nhận phát triển những dự án tốn kém hoặc thay thế các công nghệ không phù hợp. Chính vì vậy mà các doanh nghiệp cần phải có một hướng tiếp cận mới để giải quyết vấn đề môi trường không đồng nhất và tốc độ chóng mặt của sự thay đổi công nghệ trong khi nguồn ngân sách bị hạn hẹp. May mắn thay, vẫn còn có 4 một giải pháp để giải quyết khá toàn diện về mọi mặt khó khăn này và nó đã được triển triển khai trong thực tế. “Kiến trúc hướng dịch vụ” (Service Oriented Architecture - SOA) là cách tiếp cận để xây dựng hệ thống công nghệ thông tin cho phép các doanh nghiệp tận dụng những gì đang có và dễ dàng thay đổi theo yêu cầu để hỗ trợ cho doanh nghiệp. SOA được xem như là bước phát triển tiếp theo của nghành công nghệ phần mềm. 1.2. Kiến trúc hướng dịch vụ - SOA 1.2.1. Khái niệm  SOA (Service Oriented Architecture) – Kiến trúc Định hướng Dịch vụ là một cách tiếp cận hay một phương pháp luận để thiết kế và tích hợp các thành phần khác nhau, bao gồm các phần mềm và các chức năng riêng lẻ lại thành một hệ thống hoàn chỉnh. Kiến trúc SOA rất giống với cấu trúc của các phần mềm hướng đối tượng gồm nhiều module. Tuy nhiên khái niệm module trong SOA không đơn thuần là một gói phần mềm, hay một bộ thư viện nào đó. Thay vào đó, mỗi module trong một ứng dụng SOA là một dịch vụ được cung cấp rải rác ở nhiều nơi khác nhau và có thể truy cập thông qua môi trường mạng. Nói một cách ngắn gọn, một hệ thống SOA là một tập hợp nhiều dịch vụ được cung cấp trên mạng, được tích hợp lại với nhau để cùng cộng tác thực hiện các tác vụ nào đó theo yêu cầu của khác hàng. Một trong những cách hiểu sai lầm nhất về SOA là coi SOA là một công nghệ. Mặc dù SOA hoạt động được là nhờ công nghệ, nhưng khách hàng cần phải chuyển đổi từ chỗ chỉ việc tích hợp công nghệ SOA sang việc phải điều chỉnh các phương pháp thực hiện dự án, chính sách bảo trì và thay đổi để đạt được các lợi ích về khả năng trưởng thành và đáp ứng.  Dịch vụ (service) là yếu tố then chốt trong SOA. Có thể hiểu dịch vụ như là một loại module thực hiện một quy trình nghiệp vụ nào đó. Một trong những mục đích của SOA là giúp các ứng dụng có thể “giao tiếp” được với nhau mà không cần biết các chi tiết kỹ thuật bên trong. Để thực hiện điều đó SOA định ra một chuẩn giao tiếp (dùng để gọi hàm dịch vụ) được định nghĩa rõ ràng và độc lập với nền tảng hệ thống, và có thể tái sử dụng. Như vậy, SOA là cấp độ cao hơn của phát triển ứng dụng, chú trọng đến quy trình nghiệp vụ và dùng giao tiếp chuẩn để giúp che đi sự phức tạp kỹ thuật bên dưới. Sự trừu tượng là cốt lõi của 5 khái niệm dịch vụ, nó giúp cho các doanh nghiệp có thể tích hợp các thành phần hiện có vào các ứng dụng mới và các thành phần này có thể được chia sẻ hoặc tái sử dụng trong nhiều lĩnh vực khác nhau của công ty đó mà không cần phải chỉnh sửa mã nguồn hay phải tái cấu trúc lại hệ thống. Tóm lại, một dịch vụ có các đặc điểm sau:  Có ranh giới rõ ràng (Boundaries Are Explicit): Mỗi service được xây dựng dựa trên các giao chuẩn hóa đã được sử dụng rộng rãi. Chi tiết hiện thực của mỗi service sẽ không được thể hiện ra bên ngoài. Mỗi service chỉ công bố một số các giao của nó cho người sử dụng có thể dùng để gởi các yêu cầu và nhận kết quả trả về.  Tính tự trị (Autonomous): Về mặt lý thuyết, mỗi service có tính độc lập cao, có thể được xây dựng và đưa vào sử dụng mà không phụ thuộc vào các service khác.  Share the Schema and Contract, Not the Class: Về mặt trao đổi dữ liệu, các service không truyền các class và type. Thay vào đó, các class và type sẽ được đặc tả hình thức (data được đặc tả trong schema, behavior được đặc tả thành các contract).  Service Compatibility Is Based on Policy: Sự tương thích giữa các service được căn cứ vào các policy (chính sách). Tương thích về mặt cấu trúc dựa trên các đặc tả hình thức bao gồm contract (dựa trên Web Service Description Language (WSDL) hoặc Business Process Execution Language for Web Services (BPEL4WS)) và schema (XSD). Sự tương thích dựa trên policy cung cấp khả năng phân tích cũng như đảm bảo sự tương thích giữa các service. Có nhiều cách khác nhau để kết nối các dịch vụ, chẳng hạn dùng các giao thức mạng có sẵn, hoặc tạo một giao thức riêng. Nhưng từ năm 2001, các dịch vụ web (Web service) được xây dựng dựa trên nền tảng web toàn cầu, bất cứ nơi nào cũng có, đã trở thành một phương pháp phổ biến cho việc kết nối các thành phần của hệ thống SOA với nhau. Thoạt nhìn SOA và Web Service trông có vẻ giống nhau nhưng chúng không phải là một. Chúng ta sẽ tìm hiểu rõ hơn về các Web Service trong các phần tiếp theo. 6 Hình 1.2: Mô hình cơ bản của SOA. 1.2.2. Nguyên lý SOA SOA tìm cách giải quyết một số vấn đề theo cách nhìn lấy ứng dụng làm trung tâm. Có thể tóm gọn những phát biểu đó theo các nguyên lý như sau: - Ứng dụng phải mở ra khả năng cho phép các ứng dụng mới hoặc ứng dụng đang tồn tại có thể sử dụng được. Nó cũng phải có khả năng kết nối tới các dịch vụ được đưa ra bởi các ứng dụng khác để tạo thành các dịch vụ cao cấp hơn hay còn gọi là ứng dụng tổ hợp. - Sự khác biệt về công nghệ không thành vấn đề và khả năng tương tác trở thành mục tiêu then chốt. - Các chuẩn mở phải được thông qua để cho phép tích hợp giữa các doanh nghiệp. Phối hợp tiến trình nghiệp vụ giữa nhiều nhà cung cấp, nhiều đối tác thậm chí có thể với cả khách hàng. - Phải chú ý tới việc quản lý và và đảm bảo khả năng có thể quản trị của hệ thống để đảm bảo tính linh hoạt do ba nguyên tắc đầu tiên không bị xáo trộn và xung đột với nhau. Nói cách khác, SOA nhấn mạnh việc hạ thấp các rào cản truyền thống tới khả năng tái sử dụng của ứng dụng. Tôn trọng nguyên tắc thiết kế này của SOA sẽ giải quyết được bài toán lớn về vấn đề tích hợp cũng như bảo trì hệ thống phần mềm đang là thách thức đối với các nhà phát triển công nghệ thông tin trong giai đoạn hiện nay. Dựa trên nguyên lý, hệ thống SOA có những tính chất cơ bản. Để có thể xem xét hoạt động và xây dựng được hệ thống thì việc hiểu rõ tính chất của hệ thống đóng vai trò rất quan trọng. 7 1.2.3. Tính chất của SOA 1.2.3.1. Kết nối lỏng lẻo Vấn đề kết nối nói tới một số ràng buộc giữa các module lại với nhau. Có 2 loại kết nối là lỏng lẻo và chặt chẽ. Các module có tính chất kết nối lỏng lẻo có một số ràng buộc được mô tả rõ ràng trong khi các module có tính kết nối chặt lại có nhiều ràng buộc không thể biết trước. Hầu như mọi kiến trúc phần mềm đều hướng đến tính kết nối lỏng lẻo giữa các module. Mức độ kết nối của hệ thống ảnh hưởng trực tiếp đến khả năng chỉnh sửa hệ thống. Kết nối càng chặt bao nhiêu thì có nhiều thay đổi chỉnh sửa khi có sự thay đổi nào đó xảy ra. Mức độ kết nối 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 của bên cung cấp dịch vụ để sử dụng dịch vụ được cung cấp. Nghĩa là nếu bên sử dụng dịch vụ biết vị trí và chi tiết định dạng dữ liệu của bên cung cấp dịch vụ thì quan hệ sẽ càng trở nên chặt chẽ. Ngược lại, nếu bên sử dụng dịch vụ không cần biết mọi thông tin chi tiết của dịch vụ trước khi triệu gọi nó thì quan hệ giữa 2 bên càng có tính lỏng lẻo. Kết nối lỏng lẻo làm cho sự phụ thuộc ở mức tối thiểu. Khi đó, những sự thay đổi sẽ có ảnh hưởng ít nhất tới hệ thống và hệ thống vẫn có thể hoạt động khi có thành phần nào đó bị hư hỏng. Tối thiểu hóa sự phụ thuộc giúp hệ thống linh hoạt, và ít xảy ra sự cố. Tính kết nối lỏng lẻo 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 nhằm tăng năng xuất, khả năng mở rộng và khả năng đáp ứng cao. Những thay đổi cài đặt cúng được che dấu đi. Tính chất kết nối lỏng lẻo đem đến sự độc lập giữa bên cung cấp và bên sử dụng nhưng nó đòi hỏi các giao diện phải theo 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. 1.2.3.2. Tái sử dụng dịch vụ Bởi vì các dịch vụ được cung cấp trên môi trường mạng và được đăng ký ở một nơi nhất định nên chúng dễ ràng được tìm thấy và sử dụng lại. Nếu một dịch vụ không có khả năng tái sử dụng, nó cũng không cần đến giao diện mô tả. Các dịch vụ có thể được tái sử dụng lại bằng cách kết hợp lại với nhau theo nhiều mục đích khác nhau. Tái sử dụng lại các dịch vụ còn giúp loại bỏ những thành phần trùng lặp và tăng tốc độ vững chắc trong cài đặt, nó còn giúp đơn giản hóa việc quản trị. Thực ra tái sử dụng dịch vụ lại dễ dàng hơn tái sử dụng thành tố 8 [...]... đó là kiến trúc dựa trên nền tảng Web Và ngày nay quá trình này vẫn tiếp tục Chúng ta đang ở thời kỳ quá độ sang mô hình tính toán dựa trên dịch vụ là kiến trúc hướng dịch vụ (SOA) Kiến trúc này ngày nay cũng đã và đang áp dụng và phát triển cho nhiều doanh nghiệp trên thế giới Nhưng để xây dựng và triển khai được hệ thống SOA thì vẫn phải gặp một số vấn đề trở ngại: - Xác định dịch vụ • Dịch vụ là... được mô hình hóa bao gồm các logic và quy tắc cho nghiệp vụ cụ thể Trường hợp này, giống như hai tầng dịch vụ ứng dụng, bao gồm có các dịch vụ tiện ích và nhân bản - Bước 2: Design applicaion services Một vài các dịch vụ ứng dụng được mô hình hóa trong bước 1 có thể được trình bày thành bản thiết kế Các dich vụ có thể cung cấp thêm vào cho thiết kế Các dịch vụ ứng dụng tùy chọn sẽ cần đưa qua quá trình... vai trò vừa là dịch vụ sử dụng vừa là những dịch vụ cung cấp Những dịch vụ này sử dụng những dịch vụ của tầng kết nối và các dịch vụ orchestration khác để kết hợp những chức năng cấp thấp hơn thành những dịch vụ hoạt động ở cấp cao hơn, có hành vi gần với những chức năng nghiệp vụ hơn 14 - - Tầng Composite Application: là các ứng dụng tổng hợp nhằm mục đích trình diễn (presentation) và hiển thị thông... SOA Hệ thống gồm những dịch vụ nào? Tầng dịch vụ là được lược đồ hóa ra (mapped out), và chia dịch vụ ra thành các mô hình, bao gồm hệ thống SOA sơ bộ Bước 2: Thiết kế hướng dịch vụ (service-oriented design) Đây là giai đoạn có sự kết hợp chặt chẽ về sự thỏa hiệp của doanh nghiệp và nguyên lý hướng dịch vụ thành quy trình thiết kế dịch vụ Trong pha này, làm cho người thiết kế dịch vụ phải đương đầu với... cung cấp dịch vụ dựa trên thông tin địa chỉ registry đã cung cấp để 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 dùng để thực thi dịch vụ, bên sử dụng chỉ cần định dạng dữ liệu yêu cầu đúng theo mô tả và gửi đi Nhà cung cấp dịch vụ sẽ thực thi kiểm tra thẻ tín dụng và trả về một thông điếp có định dạng đúng như trong phần mô tả dịch vụ Mối... nghiệp vụ nào cần được cung cấp bởi một dịch vụ? Độ mịn(granularity) của một dịch vụ thế nào là tốt? • Việc xác định dịch vụ và quyết định đối tượng cung cấp dịch vụ một cách thích hợp, hiệu quả là giai đoạn quan trọng và đầu tiên trong một giải pháp hướng dịch vụ Trong thực tế nhiều chức năng nghiệp vụ tương tự nhau có thể được cung cấp bởi nhiều hệ thống trong một tổ chức 26 - Phân bổ dịch vụ : •... 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 chỉ cho đối tượng sử dụng các service của hệ thống.Ngoài ra còn phải quan tâm đến vấn đề hiệu suất hoạt động của hệ thống vì việc định vị một dịch vụ là một quá trình cũng chiếm mất nhiều thời gian - Quản lý dịch vụ: • Vấn đề quản lý và bảo trì các dịch vụ, việc tạo, xây dựng, theo dõi và thay đổi các dịch vụ. .. sẻ và phân bố trong nhiều ứng dụng khác nhau - Kết hợp các dịch vụ: 27 • Làm sao để có thể tạo ra các dịch vụ tổng hợp • Nhu cầu kết hợp nhiều dịch vụ để đáp ứng được yêu cầu phức tạp từ đối tượng sử dụng là có thực Vấn đề là làm sao kết hợp các dịch vụ này một cách hiệu quả, theo những qui trình với những rằng buộc phức tạp - Định tuyến dịch vụ: • Làm sao để chuyển một yêu cầu từ một đối tượng sử dụng. .. sử dụng các dịch vụ, trước tiên client phải tìm dịch vụ, ghi nhận thông tin về cách sử dụng và biết được đối tượng nào cung cấp dịch vụ UDDI định nghĩa một số thành phần cho biết các thông tin này, cho phép các client truy tìm và nhận những thông tin được yêu cầu khi sử dụng Web Service Những thông tin về Web Service được sử dụng và công bố lên mạng sử dụng giao thức này Nó sẽ kích hoạt các ứng dụng. .. kiến trúc này Thực ra, tên gọi kiến trúc định hướng giao tiếp” thích hợp hơn cho SOA Dịch vụ và module phần mềm nghiệp vụ được truy cập thông qua giao tiếp, thường theo cách thức yêu cầu - đáp trả Ngay cả với yêu cầu dịch vụ một chiều thì nó vẫn là yêu cầu trực tiếp có chủ đích từ một phần mềm này đến một phần mềm khác Một tương tác định hướng dịch vụ luôn bao hàm một cặp đối tác: nguồn cung cấp dịch . 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 của bên cung cấp dịch vụ để sử dụng dịch vụ được cung cấp. Nghĩa là nếu bên sử dụng dịch vụ biết vị trí và chi tiết định dạng. mềm. 1.2. Kiến trúc hướng dịch vụ - SOA 1.2.1. Khái niệm  SOA (Service Oriented Architecture) – Kiến trúc Định hướng Dịch vụ là một cách tiếp cận hay một phương pháp luận để thiết kế và tích. cứu và trả lời. Thái Nguyên, năm 2010 Nguyễn Thị Dung 1 CHƯƠNG 1: TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ (SERVICE-ORIENTED-ARCHITECTURE) 1.1. Kiến trúc phần mềm hiện nay 1.1.1. Một số kiến trúc