Kiến trúc hướng dịch vụ & công nghệ dịch vụ mạng

e Service 7. HTTP Giao thức truyền siêu văn bản HyperText Transfer Protocol 8. NASSL Ngôn ngữ đặc tả dịch vụ có khả năng truy cập qua mạng Network Accessible Service Specification Language 9. RMI Triệu gọi phương thức từ xa Remote Method Invocation 10. SDL Ngôn ngữ đặc tả dịch vụ Service Description Language 11. SOA Kiến trúc hướng dịch vụ Service-Oriented Architecture 12. SOAP Giao thức truy cập đối tượng đơn giản Simple Object Access Protocol 13. UDDI Mô tả, tích hợp và tìm kiếm toàn cầu. Universal Description Discovery and Integration 14. WSDL Ngôn ngữ đặc tả dịch vụ mạng Web Service Description Language 15. XML Ngôn ngữ đánh dấu mở rộng eXtensible Markup Language Danh mục hình vẽ Hình 2.1: Mô hình dịch vụ mạng 45 Hình 2.2: Cấu trúc thông điệp SOAP 51 Hình 2.3: Các kiểu dữ liệu chính trong UDDI 56 Hình 2.4: Liên kết tĩnh 60 Hình 2.5: Liên kết động thời gian xây dựng 61 Hình 2.6: Liên kết động thời gian chạy 63 Hình 2.7: Một ví dụ dịch vụ mạng 67 Hình 2.8: WSDL và việc sinh mã 70 Hình 3.1: Mô hình kiến trúc hướng dịch vụ ở mức cao 72 Hình 3.2: Biểu đồ trường hợp sử dụng của bài toán 74 Hình 3.3: Cài đặt dịch vụ mạng 75 Hình 3.4: Trang kiểm thử dịch vụ mạng 79 Hình 3.5: Đăng ký dịch vụ với UDDI 79 Hình 3.6: Mô hình liên kết dịch vụ mạng động 80 Hình 3.7: Tìm kiếm trong UDDI 81 Hình 3.8: Sử dụng công cụ wsdl.exe 81 Hình 3.9: Giao diện dịch vụ UDDI 82 Hình 3.10: Giao diện của chương trình 83 Hình 3.11: Thông tin chi tiết về dịch vụ 83 Hình 3.12: Dịch vụ thay đổi 84 Hình 3.13: Truy vấn thay đổi dịch vụ thành công 84 Hình 3.14: Thông tin về dịch vụ thay đổi 85 Mục lục Danh mục từ viết tắt 1 Danh mục hình vẽ 3 Mục lục 5 MỞ ĐẦU 7 CHƯƠNG I. LÝ THUYẾT KIẾN TRÚC HƯỚNG DỊCH VỤ 9 1. Kiến trúc hướng dịch vụ - xu hướng mới trong công nghệ thông tin 9 2. Kiến trúc hướng dịch vụ - một giải pháp 11 2.1. Sự tiến hóa của lý thuyết phát triển phần mềm. 11 2.2 Kiến trúc hướng dịch vụ 14 2.3. Dịch vụ và thành phần 22 3. Thiết kế theo kiến trúc hướng dịch vụ 26 3.1. Các nguyên tắc trong thiết kế hướng dịch vụ 26 3.2. Các quyết định thiết kế và kiến trúc trong kiến trúc hướng dịch vụ 27 3.3. Các mức độ chấp nhận kiến trúc hướng dịch vụ 29 3.4. Các bước trong quy trình phát triển phần mềm theo định hướng dịch vụ 31 3.5. Vòng đời phát triển của dịch vụ 35 4. Các công nghệ hướng dịch vụ 36 4.1. Sun JINI 36 4.2. Openwings 37 4.3. Dịch vụ mạng 40 4.4. Enterprise Service Bus (ESB) 40 5. Kết luận chương 42 CHƯƠNG II. CÔNG NGHỆ DỊCH VỤ MẠNG 44 1. Kiến trúc dịch vụ mạng 45 2. Các chuẩn cho dịch vụ mạng 46 2.1. Ngôn ngữ mô tả dịch vụ mạng WSDL. 46 2.2. Giao thức truy cập đối tượng đơn giản SOAP. 50 2.3. Đặc tả mô tả và tích hợp tìm kiếm UDDI 55 3. Các kiểu liên kết trong dịch vụ mạng. 60 3.1 Liên kết tĩnh 60 3.2. Liên kết động trong thời gian xây dựng. 61 3.3. Liên kết động trong thời gian chạy. 62 5. Xây dựng dịch vụ mạng 64 5.1. Vòng đời của dịch vụ mạng 64 5.2. Bảo mật trong dịch vụ mạng 64 5.3. Tính liên thông giữa các dịch vụ mạng 70 6. Kết luận chương 70 Chương III: CÀI ĐẶT ỨNG DỤNG 72 1. Nhắc lại các yêu cầu của một hệ thống xây dựng theo kiến trúc hướng dịch vụ 72 2. Mô tả bài toán 73 3. Cài đặt bài toán 75 3.1. Thành phần cung cấp dịch vụ 75 3.2. Thành phần sử dụng dịch vụ. 80 3.3 Thành phần đăng ký dịch vụ. 81 4. Các kết quả đạt được 82 5. Đánh giá về ứng dụng 85 5.1. Ưu điểm 85 5.2. Các điểm hạn chế 86 KẾT LUẬN 87 Danh mục tài liệu tham khảo 89 MỞ ĐẦU Kiến trúc phần mềm của một hệ thống mô tả các thành phần của hệ thống và cách thức các thành phần này tương tác với nhau; tương tác giữa các thành phần được gọi là “liên kết” (connector) [1]. Trong một hệ thống phần mềm có quy mô lớn và phức tạp thì kiến trúc của hệ thống giữ một vị trí quan trọng trong việc hiểu hệ thống, việc tổ chức phát triển và tăng cường tái sử dụng. Ngày nay, khi mà độ phức tạp của phần mềm ngày càng tăng thì các kiến trúc phần mềm truyền thống dường như đang tiến tới giới hạn khả năng giải quyết vấn đề của chúng; trong khi đó, các tổ chức công nghệ thông tin vẫn phải đáp ứng được những yêu cầu đặt ra như: yêu cầu được đáp ứng nhanh, yêu cầu giảm giá thành, yêu cầu về khả năng thu hút và tích hợp với các đối tác mới v.v…, và đặc biệt là sự thay đổi nhanh chóng của các công nghệ. Trong suốt bốn thập kỷ qua, thực tế phát triển phần mềm đã trải qua nhiều phương pháp phát triển khác nhau. Mỗi phương pháp mới xuất hiện đều hướng tới mục tiêu quản lý độ phức tạp ngày càng tăng của phần mềm bằng cách đưa ra các cấu trúc có mức độ đóng gói tăng dần: từ hàm (function), lớp (class), tới thành phần (component); các cấu trúc này được xem như những phần mềm “hộp đen”, chúng che giấu cài đặt nhờ việc kiểm soát việc truy cập tới hành vi và dữ liệu của mình thông qua một giao diện tường minh. Ở mức độ đóng gói thấp, chúng ta sử dụng đối tượng để che giấu dữ liệu, ở mức độ đóng gói cao hơn, chúng ta sử dụng các thành phần để thực hiện việc này. Việc sử dụng đối tượng để che giấu thông tin hoạt động tốt với các hệ thống nhỏ, nó cho phép tạo ra các cấu trúc phần mềm phản ánh được các đối tượng trong thế giới thực. Vấn đề nảy sinh khi chúng ta cố gắng nhóm một số lượng lớn các đối tượng cùng với nhau. Mặc dù truy cập tới các đối tượng được điều khiển thông qua giao diện của chúng, mức độ đóng gói thấp của các đối tượng vẫn làm cho sự phụ thuộc giữa chúng trở nên khó kiểm soát trong một hệ thống tương đối lớn. Khái niệm thành phần được phát triển giúp quản lý các hệ thống lớn tốt hơn: một thành phần được định nghĩa là một nhóm các đối tượng hoạt động cùng nhau để thực hiện một chức năng của hệ thống. Các công nghệ như EJB (Enterprise Java Bean), .NET, CORBA (Common Object Request Broker Architecture) tỏ ra rất hiệu quả trong việc cài đặt các thành phần. Phương pháp phát triển phần mềm dựa thành phần (Component-based Development - CBD) cho phép những nhà phát triển tạo ra các hệ thống phức tạp hơn, có chất lượng cao hơn và nhanh hơn bất kỳ phương pháp phát triển phần mềm nào khác trước đó. Nhưng khi chúng ta xây dựng các thành phần trên các ngôn ngữ khác nhau, hay thậm chí là trên những nền tảng khác nhau (các thành phần không đồng nhất) cho một hệ thống thì cần có khả năng tích hợp chúng lại với nhau, nhưng một vấn đề nảy sinh: các thành phần dùng công nghệ EJB đòi hỏi việc triệu gọi phương thức thông qua RMI (Remote Method Invocation – Triệu gọi phương thức từ xa), trong khi đó, các thành phần dùng công nghệ CORBA thì lại dùng IIOP (Internet Inter-ORB Protocol), hơn nữa, khi các thành phần được định vị qua Internet, các thông điệp giữa chúng có thể bị chặn bởi tường lửa. Ngay cả khi không gặp phải những vấn đề trên thì để sử dụng được thành phần, chúng ta vẫn cần phải biết vị trí chính xác và giao diện của thành phần để nếu giao diện thay đổi, chúng ta cũng phải thay đổi cách gọi đến chúng. Vì số lượng người dùng thành phần có thể rất lớn nên việc này sẽ tạo ra các phụ thuộc có quy mô lớn, rất khó kiểm soát. Vậy làm thế nào chúng ta có thế giải quyết vấn đề này? Kiến trúc hướng dịch vụ (Service-oriented architecture, viết tắt là SOA) đang được phát triển và được xem như một bước đột phá tiếp theo trong kiến trúc phần mềm giúp giải quyết vấn đề “khủng hoảng” phần mềm. Sự xuất hiện của công nghệ dịch vụ mạng (Web services) trong vài năm trở lại đây đã tạo ra sự quan tâm mạnh mẽ tới kiến trúc này bởi Web service hiện thực hóa việc phát triển hệ thống theo kiến trúc hướng dịch vụ một cách tự nhiên và dễ dàng hơn. Web service và kiến trúc hướng dịch vụ đang thay đổi một cách căn bản cách thức xây dựng các hệ thống nội bộ (các hệ thống thông tin hỗ trợ trong các tổ chức) và cách các hệ thống nội bộ tương tác với các hệ thống bên ngoài mà chưa một kiến trúc nào trước đó có thể thực hiện được. Thuật ngữ “dịch vụ” trong kiến trúc hướng dịch vụ cũng không phải là khái niệm mới: các ứng dụng khách/chủ (client/server) trong những năm 90 đã sử dụng “dịch vụ” để chỉ khả năng thực hiện lời gọi phương thức từ xa. Kiến trúc hướng dịch vụ đặc biệt đề cao tính liên thông (interoperability) và sự trong suốt về vị trí của các dịch vụ, nói tới dịch vụ và kiến trúc hướng dịch vụ là nói về việc thiết kế và xây dựng các hệ thống sử dụng các thành phần phần mềm không đồng nhất. Sử dụng công nghệ dịch vụ mạng và kiến trúc hướng dịch vụ đem lại các lợi ích sau: Mở rộng các lựa chọn về mặt công nghệ. Các hệ thống được xây dựng linh hoạt và nhạy bén hơn. Giảm thời gian phát triển. Giảm chi phí bảo trì. Trong đồ án tốt nghiệp này, người viết đồ án (NVĐA) sẽ trình bày về lý thuyết của kiến trúc hướng dịch vụ và công nghệ dịch vụ mạng, tại sao những công nghệ này có thể xóa bỏ những rào cản công nghệ để tạo ra các hệ thống phần mềm có tính tích hợp cao, và tại sao lựa chọn công nghệ dịch vụ mạng là thích hợp nhất cho việc cài đặt ứng dụng theo kiến trúc hướng dịch vụ cũng như lợi ích của những ứng dụng này khi xây dựng theo kiến trúc hướng dịch vụ. CHƯƠNG I. LÝ THUYẾT KIẾN TRÚC HƯỚNG DỊCH VỤ Kiến trúc hướng dịch vụ là một làn sóng mới trong phát triển ứng dụng. Nó có thể được xem như là một tập hợp của các khái niệm kiến trúc hoặc một mô hình lập trình. Chương này sẽ trình bày các khái niệm cơ bản về : Sự tiến hóa của các kỹ thuật phát triển phần mềm. Kiến trúc hướng dịch vụ và phát triển phần mềm theo kiến trúc hướng dịch vụ. Các công nghệ giúp hiện thực hóa triết lý của kiến trúc hướng dịch vụ. 1. Kiến trúc hướng dịch vụ - xu hướng mới trong công nghệ thông tin Trong khi các nhà quản lý công nghệ thông tin đang phải đối đầu với việc giảm giá thành và tối đa lợi ích của các công nghệ hiện có, họ vẫn phải liên tục cố gắng để phục vụ khách hàng được tốt hơn, trở nên cạnh tranh hơn và phản ứng nhanh hơn với chiến lược của doanh nghiệp. Có hai yếu tố chính ẩn sau những áp lực này, đó là tính không đồng nhất của các hệ thống và sự thay đổi nhanh về mặt công nghệ. Phần lớn các doanh nghiệp ngày nay đều gồm nhiều hệ thống, ứng dụng và kiến trúc khác nhau với thời gian tồn tại và công nghệ khác nhau. Việc tích hợp các sản phẩm từ nhiều nhà cung cấp và nhiều nền tảng thực sự là điều khó khăn. Nhưng chúng ta cũng không thể cố gắng tiếp cận theo kiểu một nhà cung cấp đối với công nghệ thông tin vì các bộ ứng dụng và kiến trúc hỗ trợ rất không mềm dẻo. Sự thay đổi công nghệ là yếu tố thứ hai mà các nhà quản lý công nghệ thông tin phải đối mặt. Sự toàn cầu hoá và kinh doanh điện tử đang làm tăng tốc sự thay đổi. Sự toàn cầu hoá dẫn tới sự cạnh tranh gay gắt trong việc rút ngắn chu kỳ sản xuất để có thể chiếm ưu thế đối với đối thủ cạnh tranh. Các thay đổi về yêu cầu và nhu cầu của khách hàng nhanh chóng hơn do tác động của phân phối cạnh tranh và sự phong phú về thông tin sản phẩm trên Internet. Do đó lại càng thúc đẩy việc cải tiến trong sản phẩm và dịch vụ diễn ra nhanh hơn. Các cải tiến trong công nghệ tiếp tục tăng, làm tăng sự thay đổi yêu cầu của khách hàng. Doanh nghiệp phải nhanh chóng thích nghi để tồn tại, chưa kể đến việc phải thành công trong môi trường cạnh tranh động ngày nay, và hạ tầng công nghệ thông tin phải đem lại khả năng thích nghi cho các doanh nghiệp. Vì vậy, các tổ chức kinh doanh đang phát triển từ sự phân chia doanh nghiệp theo chiều dọc, cô lập của những năm 1980 về trước thành các cấu trúc chú trọng quy trình kinh doanh theo chiều ngang của những năm 1980, 1990, tới mô hình kinh doanh mới trong đó các doanh nghiệp có tác động lẫn nhau. Các dịch vụ kinh doanh ngày nay cần phải được thành phần hoá và phân tán. Cần chú trọng vào dây chuyền cung cấp mở rộng, cho phép khách hàng và đối tác truy cập tới các dịch vụ kinh doanh. Hình 1.1: Sự phát triển của các công ty Làm thế nào để môi trường công nghệ thông tin trở nên linh hoạt và nhạy bén hơn đối với sự thay đổi của các yêu cầu kinh doanh? Làm thế nào để các hệ thống và ứng dụng không đồng nhất trao đổi với nhau một cách liền mạch? Làm thế nào để đạt được các mục tiêu kinh doanh mà không làm phá sản các doanh nghiệp? Đã có nhiều giải pháp được đề ra song song với sự phát triển của các vấn đề kinh doanh, như được chỉ ra trong hình 1.2. Hiện nay, nhiều nhà quản lý và các chuyên gia công nghệ thông tin tin rằng chúng ta đang tiến ngày một gần hơn tới câu trả lời với kiến trúc hướng dịch vụ (SOA). Hình 1.2: Sự phát triển của kiến trúc Để đáp ứng được nhu cầu về sự không đồng nhất, tính liên thông và sự thay đổi yêu cầu không ngừng, một kiến trúc như vậy phải đem lại một nền tảng cho việc xây dựng các dịch vụ ứng dụng với các đặc tính sau: Liên kết lỏng lẻo (Loosely coupled) Vị trí trong suốt (Location transparent) Độc lập về giao thức (Protocol independent) Dựa trên một kiến trúc hướng dịch vụ như vậy, người dùng dịch vụ thậm chí không cần phải quan tâm tới một dịch vụ cụ thể mà mình đang trao đổi thông tin vì hạ tầng cơ sở, hay là tuyến dịch vụ (service bus), sẽ tạo ra một lựa chọn thích hợp cho người dùng. Các đặc tả kỹ thuật cụ thể từ các công nghệ cài đặt khác nhau như J2EE hay .NET không làm ảnh hưởng tới người dùng SOA. Người dùng cũng có khả năng cân nhắc và thay thế một cài đặt dịch vụ tốt hơn nếu tồn tại một dịch vụ khác có chất lượng tốt hơn. 2. Kiến trúc hướng dịch vụ - một giải pháp 2.1. Sự tiến hóa của lý thuyết phát triển phần mềm. Trước khi giải thích về kiến trúc hướng dịch vụ cũng như bản chất những khái niệm tạo nên kiến trúc hướng dịch vụ, chúng ta cần phải hiểu về lịch sử phát triển của kiến trúc hướng dịch vụ bằng cách nhìn lại những khó khăn mà những nhà phát triển phần mềm đã phải đối mặt trong vài thập kỷ qua và xem xét các giải pháp được đưa ra để giải quyết các khó khăn đó. Những người lập trình đã sớm nhận ra rằng việc viết phần mềm đã đang ngày càng phức tạp hơn. Họ cần một cách tốt hơn để sử dụng lại những đoạn mã đã viết. Khi những nhà nghiên cứu quan tâm tới vấn đề này, họ đã đưa ra khái niệm thiết kế mô đun. Với các quy tắc của thiết kế mô đun, các lập trình viên có khả năng viết các hàm và chương trình con và sử dụng lại mã đã viết. Đó quả là một bước đột phá và một điều tuyệt vời cho việc xây dựng phần mềm. Cách này có hiệu quả tốt trong một thời gian, từ 1960 đến 1980. Hình 1.3: Phát triển phần mềm theo mô đun Nhưng sau đó, các lập trình viên lại nhận thấy rằng họ đang thực hiện việc cắt dán các mô đun vào các ứng dụng khác, điều này bắt đầu tạo ra một cơn ác mộng về bảo trì: khi một lỗi được phát hiện trong một hàm nào đó, họ phải kiểm tra tất cả các ứng dụng có sử dụng hàm này và thay đổi mã để sửa chữa. Những nhà phát triển không muốn điều này, họ cần một mức trừu tượng cao hơn. Các nhà nghiên cứu đã đưa ra khái niệm các lớp và phần mềm hướng đối để giải quyết vấn đề này. Phương pháp phát triển phần mềm hướng đối tượng đã có hiệu quả trong một thời gian, từ 1980 đến 1990. Hình 1.4: Phát triển phần mềm hướng đối tượng Lại một lần nữa, khi độ phức tạp của phần mềm tăng lên, các nhà phát triển bắt đầu nhận thấy việc xây dựng và bảo trì phần mềm là rất phức tạp, họ muốn một cách nào đó để sử dụng lại và bảo trì các chức năng chứ không chỉ đơn thuần là mã nguồn. Các nhà nghiên cứu lại đưa ra một lớp trừu tượng khác để kiểm soát độ phức tạp này, đó là phần mềm dựa thành phần (Component-based software - CBD). Hình 1.5: Phát triển phần mềm hướng thành phần CBD là một giải pháp tốt cho việc sử dụng lại và bảo trì, nhưng nó không kiểm soát được tất cả các độ phức tạp mà các nhà phát triển hiện nay đang phải đối mặt như: phần mềm phân tán, các ứng dụng tích hợp, các nền tảng, thiết bị khác nhau v.v… Phần mềm ngày nay phải được xây dựng sao cho có thể đáp ứng được tất cả các yêu cầu trên. Và kiến trúc hướng dịch vụ cùng với công nghệ dịch vụ mạng xuất hiện đã đem lại một giải pháp cho tất cả các yêu cầu. Bằng cách thực hiện SOA, các nhà phát triển có thể loại bỏ được những sự không tương thích về giao thức, nền tảng và các ứng dụng được tích hợp một cách dễ dàng. Hình 1.6: Phát triển phần mềm hướng dịch vụ Như vậy, theo thời gian, chúng ta nhận thấy rằng những phương pháp phát triển phần mềm đã liên tục tiến hóa, từ phương pháp xây dựng phần mềm đơn giản nhất cho đến những phương pháp xây dựng phần mềm đồ sộ như ngày nay. Quá trình tiến hóa của phương pháp phát triển phần mềm có thể tóm lược lại như sau: ban đầu là phương pháp phát triển tự phát, tức là cần máy tính thực hiện như thế nào thì viết lệnh như thế đó. Đơn vị có thể tái sử dụng của phần mềm là rất nhỏ - từng dòng lệnh. Những phần mềm được viết ra thường nhỏ, và đơn giản, chủ yếu là các phần mềm hỗ trợ tính toán. Sau đó kỹ thuật phát triển phần mềm tiến thêm một bước mới, đó là phát triển phần mềm theo mô đun. Nhờ phương pháp này, những đơn vị chương trình có khả năng tái sử dụng đã tăng lên và quy mô của phần mềm cũng đã lớn hơn, không chỉ dừng ở các phần mềm hỗ trợ tính toán, mà còn bao gồm cả những ứng dụng thương mại. Kỹ thuật phát triển phần mềm hướng đối tượng đã trở thành một làn sóng mới về kỹ thuật phát triển phần mềm trong một vài thập kỷ gần đây, việc đưa ra các khái niệm lớp, hàm và biến thành phần, kế thừa, kết tập... đã khiến cho việc xây dựng phần mềm trở nên dễ dàng hơn, cấu trúc chương trình trở nên dễ hiểu hơn, với khái niệm đối tượng tương đối gần với các thực thể trong đời sống tự nhiên và xã hội. Kỹ thuật phát triển phần mềm hướng đối tượng đã làm tăng khả năng tái sử dụng mã, và nó cũng làm cho phần mềm có khả năng khả chuyển hơn do đặc tính khép kín của các lớp. Cùng với sự phát triển ngày càng nhanh của các phần mềm cả về quy mô lẫn yêu cầu về thời gian phát triển, phương pháp phát triển phần mềm hướng thành phần là mức trừu tượng hóa cao hơn của phương pháp phát triển hướng đối tượng. Đặc điểm chính của các phần mềm phát triển theo phương pháp này là chúng gồm nhiều thành phần, mỗi thành phần có thể hoàn thành một hoặc một số công việc cụ thể, nhất định. Mỗi thành phần bao gồm một tập các lớp, các đối tượng. Phần mềm được tạo ra bằng cách ghép các thành phần đó lại với nhau, thông qua việc sử dụng các giao diện giữa chúng. Phần mềm được tạo ra theo phương pháp này có khả năng tái sử dụng mã rất cao, việc bảo trì và nâng cấp khá dễ dàng. Tuy nhiên, quy mô của phần mềm ngày càng nở rộng, thời gian đưa ra thị trường được đòi hỏi ngày càng phải sớm hơn, yêu cầu về khả năng tái sử dụng mã và khả năng dễ bảo trì đối với phần mềm đã khiến cho phương pháp phát triển phần mềm hướng dịch vụ ra đời và đang được xem như là một làn sóng mới trong phát triển phần mềm. Bảng so sánh dưới đây cho ta thấy rõ ưu thế của phương pháp phát triển phần mềm hướng dịch vụ so với các phương pháp phát triển phần mềm trước đó. Hướng cấu trúc Hướng đối tượng Hướng thành phần Hướng dịch vụ Mức độ đóng gói Rất thấp Thấp Trung bình Cao Giao ước sử dụng Xác định Riêng tư /Công khai Công khai Xuất bản Khả năng tái sử dụng Thấp Thấp Trung bình Cao Độ gắn kết Chặt Chặt Lỏng lẻo Rất lỏng lẻo Các ràng buộc Thời gian biên dịch Thời gian biên dịch Thời gian biên dịch Thời gian chạy Phạm vi truyền thông Nội bộ ứng dụng Nội bộ ứng dụng Nội bộ ứng dụng Giữa các công ty 2.2 Kiến trúc hướng dịch vụ Kiến trúc phần mềm của một chương trình hoặc một hệ thống tính toán là cấu trúc hoặc các cấu trúc của hệ thống, bao gồm các thành phần phần mềm, các thuộc tính có thể nhìn thấy từ bên ngoài của các thành phần đó và các mối quan hệ giữa chúng[1]. Hình 1.7: Kiến trúc phần mềm theo định nghĩa cổ điển Kiến trúc hướng dịch vụ là một loại kiến trúc phần mềm đặc biệt có nhiều đặc tính riêng biệt. Hình 1.8: Mô hình kiến trúc hướng dịch vụ 2.2.1. Các định nghĩa về kiến trúc hướng dịch vụ Kiến trúc hướng dịch vụ (Service-oriented architecture - SOA) là một cụm từ thông dụng trong công nghệ thông tin ngày nay. Mặc dù đã có nhiều cố gắng nhưng vẫn không có được sự thống nhất trong định nghĩa về kiến trúc này [4]. “SOA là một framework cho phép tính năng ứng dụng được cung cấp, tìm ra và tiêu thụ như là các tập dịch vụ mạng có khả năng tái sử dụng. Trong khi dịch vụ mạng không phải là SOA, nó là một trong các chuẩn cho phép xây dựng SOA. SOA trừu tượng hoá tính phức tạp và chi tiết cài đặt, khiến cho nó trở thành một kiến trúc hoàn thiện để xây dựng các hệ thống phần mềm.” Scott Rosenbloom is chief strategist with WRQ Inc. “Các giải pháp công nghệ thông tin an toàn, tích hợp đáp ứng được các yêu cầu nghiệp vụ. Các giải pháp phải cài đặt, tối ưu và chỉ dẫn sự thực thi quy trình nghiệp vụ bằng cách kết hợp tính năng của các dịch vụ riêng lẻ, đóng kín và có khả năng tái sử dụng. SOA không nặng nề về việc phát triển ứng dụng phức tạp mà tập trung vào việc chuẩn hoá giao diện giữa các thành phần dịch vụ với sự quản lý tập trung và cài đặt phân tán”.Dave Morris, I.T. Security Lead TransAlta Corp “SOA mô hình hoá nghiệp vụ như là một tập các dịch vụ tự chứa đựng (self-contained) có hiệu lực giữa các tổ chức và có thể được gọi cả từ bên trong và bên ngoài thông qua các giao thức chuẩn.”. Dave McComb, president, Semantic Arts “SOA không phải là cái gì khác ngoài kiến trúc hướng nghiệp vụ, cái mà cho phép tính mềm dẻo của các ứng dụng nghiệp vụ, để trở thành độc lập nhưng cộng tác, trong khi cung cấp các dịch vụ của chúng. Các ứng dụng dưới kiến trúc này cùng một lúc có thể là trình khách và chủ với các dịch vụ tuỳ thích.” Satheesan Kunnel, USWWI “SOA là một hướng tiếp cận để thiết kế và tích hợp phần mềm theo một phương pháp mô đun trong đó, mỗi mô đun là một “dịch vụ được kết nối lỏng lẻo” có thể truy cập qua mạng và có khả năng tích hợp động với các dịch vụ khác trong thời gian chạy. Một dịch vụ phải đưa ra một giao diện chuẩn (WSDL) cho tính năng và các lời gọi các phương thức của nó.” Rajesh Dawar “Các dịch vụ cung cấp một số chức năng cho những người biết cách yêu cầu và tiêu thụ chúng mà không cần phải biết làm thế nào để tạo ra được chức năng ấy. SOA là một cách tiếp cận để xây dựng các ứng dụng phần mềm như là các tập hợp dịch vụ tự trị, tương tác không cần quan tâm tới nền tảng, cấu trúc dữ liệu hay các thuật toán bên trong của các dịch vụ khác.” Michael Champion, R&D specialist, Software AG “SOA là một kiểu thiết kế cố gắng cho phép sự tích hợp dễ dàng và các ứng dụng linh hoạt. Trong SOA, chức năng ứng dụng được thiết kế như là các dịch vụ có khả năng tái sử dụng và chia sẻ. Một dịch vụ là một phần của chức năng ứng dụng thể hiện chức năng của nó qua một giao diện trừu tượng, che giấu các phần việc bên trong của sự cài đặt dịch vụ.”Anne Thomas Manes, analyst, Burton Group “SOA là một kiến trúc cho quy mô doanh nghiệp (thường trải rộng nhiều ứng dụng trong một doanh nghiệp hoặc nhiều doanh nghiệp) trong đó thành phần cấu trúc chính là dịch vụ. Một dịch vụ là một tập hợp các chức năng nghiệp vụ liên quan tới nhau tương tác nội bộ hoặc từ xa sử dụng kiểu truyền thông truyền thông điệp / hướng tài liệu. Một dịch vụ bao gồm một giao diện dịch vụ và một cài đặt dịch vụ cài đặt một hoặc nhiều giao diện dịch vụ và gắn liền với một tập hợp tính năng nhất định. Các dịch vụ cụ thể được xác định dưới dạng giao thức vận chuyển/ ứng dụng/ thông điệp, chứ không phải dưới dạng một mô hình lập trình cụ thể. SOA điển hình bao gồm các dịch vụ kỹ thuật để quản lý siêu dữ liệu về các giao diện dịch vụ và các cài đặt, các nguồn cung cấp và nguồn tiêu thụ dịch vụ; và các dịch vụ cho việc quản lý và bắt tuân theo các chính sách, điều khiển truy cập, các tính năng bảo mật, các giao dịch, mặc dù tất cả các dịch vụ này đều là tuỳ chọn trong một thể hiện SOA cụ thể.” Stefan Tilkov, CEO, innoQ “SOA là một quy tắc kiến trúc tập trung vào quan điểm cho rằng các tài sản công nghệ thông tin được mô tả và thể hiện ra như là các dịch vụ. Các dịch vụ này có thể được kết hợp theo một cách thức lỏng lẻo để tạo thành các quy trình nghiệp vụ ở mức cao hơn, đem lại cho nghiệp vụ tính nhanh nhẹn trong sự không đồng nhất về mặt công nghệ thông tin. “Ronald Schmelzer, analyst, ZapThink LLC “SOA là một cách tiếp cận để phát triển các ứng dụng phân tán liên kết không chặt chẽ, độc lập giao thức tạo thành từ các tài nguyên phần mềm có tính hoàn toàn xác định, tự chứa đựng có khả năng truy cập như là các dịch vụ giữa các doanh nghiệp được mở rộng theo một cách được chuẩn hoá nhằm tăng cường tính tái sử dụng và liên thông. ” Ankur Gupta, marketing manager, Fiorano Software Inc. “SOA là một dạng của kiến trúc công nghệ gắn liền với các quy tắc của hướng dịch vụ. Khi được cài đặt thông qua nền tảng công nghệ Web Service, SOA tạo ra tiềm năng để hỗ trợ và thúc đẩy các quy tắc này trong toàn bộ quy trình nghiệp vụ và các miền tự động hoá của một doanh nghiệp.” Thomas Erl, chief architect, XMLTC Consulting Inc Nói tóm lại, SOA có thể được hiểu là một hướng tiếp cận để xây dựng các hệ thống phân tán cung cấp chức năng ứng dụng dưới dạng các dịch vụ tới các ứng dụng người dùng cuối hoặc các dịch vụ khác: SOA là một kiến trúc dùng các chuẩn mở để biểu diễn các thành phần phần mềm như là các dịch vụ. Cung cấp một cách thức chuẩn hóa cho việc biểu diễn và tương tác với các thành phần phần mềm. Các thành phần phần mềm riêng lẻ trở thành các khối cơ bản có thể sử dụng lại để xây dựng các ứng dụng khác. Được sử dụng để tích hợp các ứng dụng bên trong và bên ngoài tổ chức. Dịch vụ là yếu tố then chốt trong SOA. Có thể hiểu dịch vụ như là hàm chức năng (mô đun phần mềm) thực hiện quy trình nghiệp vụ nào đó. Các dịch vụ trong SOA có các đặc điểm sau: Các dịch vụ là có thể tìm kiếm được. Các dịch vụ có tính liên thông. Các dịch vụ không được gắn kết chặt chẽ với nhau. Các dịch vụ là phức hợp, bao gồm nhiều thành phần, được đóng gói ở mức cao. Các dịch vụ trong suốt về vị trí. Các dịch vụ có khả năng tự hàn gắn. Một cách cơ bản, SOA là tập hợp các dịch vụ kết nối “mềm dẻo” với nhau (nghĩa là một ứng dụng có khả năng giao tiếp với một ứng dụng khác mà không biết các chi tiết kỹ thuật bên trong), có giao diện đượ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. 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 diện chuẩn để che giấu sự phức tạp kỹ thuật bên dưới. Thiết kế SOA tách riêng phần thực hiện dịch vụ (phần mềm) với giao diện gọi dịch vụ. Điều này tạo nên một giao diện nhất quán cho ứng dụng sử dụng dịch vụ mà không cần quan tâm tới công nghệ thực hiện dịch vụ. Thay vì xây dựng các ứng dụng đơn lẻ và đồ sộ, nhà phát triển sẽ xây dựng các dịch vụ tinh gọn hơn có thể triển khai và tái sử dụng trong toàn bộ quy trình nghiệp vụ. Điều này cho phép tái sử dụng phần mềm tốt hơn, cũng như tăng sự mềm dẻo vì nhà phát triển có thể cải tiến dịch vụ mà không làm ảnh hưởng đến ứng dụng sử dụng dịch vụ. Triết lý SOA không hoàn toàn mới, DCOM và CORBA cũng có kiến trúc tương tự. Tuy nhiên, các kiến trúc cũ ràng buộc các thành phần với nhau quá chặt, ví dụ như các ứng dụng phân tán muốn làm việc với nhau phải được thỏa thuận về chi tiết tập hàm API, một thay đổi mã lệnh trong thành phần COM sẽ yêu cầu những thay đổi tương ứng đối với mã lệnh truy cập thành phần COM này. Ưu điểm lớn nhất của SOA là khả năng kết nối mềm dẻo và tái sử dụng. Các dịch vụ có thể được sử dụng trên nền tảng bất kỳ và đước viết với ngôn ngữ bất kỳ (ví dụ, ứng dụng Java có thể liên kết với dịch vụ mạng .NET và ngược lại). SOA dựa trên hai nguyên tắc thiết kế quan trọng: Mô đun: tách vấn đề lớn thành nhiều vấn đề nhỏ Đóng gói: che giấu dữ liệu và logic trong từng mô đun đối với truy cập từ bên ngoài Một thiết kế kiến trúc phù hợp với khái niệm của SOA cần tuân theo những tính chất sau: Một dịch vụ là một đơn vị phần mềm gồm các hoạt động nghiệp vụ có tính tự chứa đựng và mức độ đóng gói cao (coarse-grained). Một dịch vụ có thể dùng lại được, cho phép có thể xây dựng được một dịch vụ mới từ các dịch vụ hiện có. Do đó, việc quan sát các hàm ý có thể có của các thuộc tính phi chức năng như tính giao dịch là rất quan trọng. Một giao diện dịch vụ là một điểm cuối mạng (network endpoint) đảm bảo tính độc lập và trong suốt về vị trí. Một dịch vụ cần có khả năng được phát hiện ra một cách công khai bằng cách sử dụng một nơi đăng ký dịch vụ nhằm cho phép các liên kết động tới dịch vụ. Một dịch vụ cần đảm bảo tính liên thông bằng cách hỗ trợ các giao thức truyền thông được chuẩn hóa và các định dạng dữ liệu rõ ràng. Các đặc điểm trên đảm bảo cho một kiến trúc hướng dịch vụ khả năng gắn kết lỏng lẻo của các dịch vụ phân tán và có tính mô đun bằng cách sử dụng các giao ước dịch vụ để mô tả các định dạng thông điệp cần thiết. 2.2.2. Các thực thể trong kiến trúc hướng dịch vụ Các thực thể trong kiến trúc hướng dịch vụ bao gồm: Dịch vụ (service). Thành phần sử dụng dịch vụ (service consumer/ client/ requester). Thành phần cung cấp dịch vụ (service provider). Thành phần đăng ký dịch vụ (service registry). Giao ước dịch vụ (contract). Ủy nhiệm dịch vụ. Ràng buộc sử dụng dịch vụ (service lease). Dịch vụ: Dịch vụ là một chức năng rõ ràng, tự chứa đựng và không phụ thuộc vào ngữ cảnh hay trạng thái của các dịch vụ khác. Các thành phần sử dụng dịch vụ có thể truy cập tới dịch vụ thông qua giao diện dịch vụ được xuất bản. Dịch vụ có các tính chất sau: Dịch vụ có tính chất rõ ràng, là một đơn vị chức năng nghiệp vụ để có thể được triệu gọi. Có khả năng triệu gọi thông qua các giao thức truyền thông chung. Có tính liên thông và vị trí trong suốt. Dịch vụ được định nghĩa bằng các giao diện tường minh. Các giao diện độc lập với cài đặt. Cung cấp giao ước giữa các thành phần cung cấp và sử dụng dịch vụ Dịch vụ là các mô đun phức tạp, bao gồm nhiều thành phần. Mức độ đóng gói của dịch vụ càng cao thì dịch vụ càng có khả năng tái sử dụng và linh hoạt. Thành phần sử dụng dịch vụ: Thành phần sử dụng dịch vụ là một ứng dụng, một dịch vụ, hoặc một loại mô đun phần mềm khác có yêu cầu sử dụng dịch vụ. Đây là thực thể khởi tạo việc định vị dịch vụ tại một kho đăng ký dịch vụ, liên kết tới dịch vụ qua một kênh truyền thông và thực thi chức năng của dịch vụ. Thành phần này thực thi nhiệm vụ bằng cách gửi tới dịch vụ một yêu cầu được định dạng theo đúng giao ước. Thành phần cung cấp dịch vụ: Thành phần cung cấp dịch vụ là một thực thể có khả năng được địa chỉ hóa qua mạng, nó có thể chấp nhận và thực thi các._. yêu cầu từ những thành phần sử dụng dịch vụ. Thành phần cung cấp dịch vụ có thể là một hệ thống máy tính lớn, một thành phần, hoặc một loại hệ thống phần mềm khác có thể thực thi các yêu cầu dịch vụ. Thực thể này xuất bản giao ước dịch vụ của nó trong một kho đăng ký dịch vụ để các thành phần sử dụng dịch vụ có thể truy cập. Thành phần đăng ký dịch vụ: Thành phần đăng ký dịch vụ là một thư mục trên mạng có chứa các dịch vụ sẵn dùng. Đây là một thực thể chấp nhận và lưu trữ các giao ước từ các thành phần cung cấp dịch vụ và cung cấp các giao ước đó cho những thành phần sử dụng dịch vụ. Giao ước dịch vụ: Một giao ước là một bản đặc tả cách thức để thành phần sử dụng dịch vụ có thể tương tác với thành phần cung cấp dịch vụ. Nó chỉ ra khuôn dạng của thông điệp yêu cầu và thông điệp đáp ứng từ dịch vụ. Giao ước dịch vụ có thể đòi hỏi một tập các điều kiện tiên quyết và điều kiện sau. Các điều kiện này xác định trạng thái cần thiết của dịch vụ để thực thi một chức năng cụ thể. Bản giao ước cũng có thể bao gồm các mức độ chất lượng của dịch vụ, các đặc tả cho các khía cạnh phi chức năng của dịch vụ. Ủy nhiệm dịch vụ: Thành phần cung cấp dịch vụ cung cấp một ủy nhiệm dịch vụ cho thành phần sử dụng dịch vụ. Thành phần sử dụng dịch vụ thực thi yêu cầu bằng cách gọi một hàm API trên nó. Ủy nhiệm dịch vụ (hình 1.9) sẽ tìm một giao ước và một tham chiếu tới thành phần cung cấp dịch vụ trong nơi đăng ký. Sau đó, nó định dạng thông điệp yêu cầu và thực thi yêu cầu trên danh nghĩa của thành phần sử dụng dịch vụ. Ủy nhiệm dịch vụ là một thực thể không bắt buộc, nó chỉ đơn giản hóa cho thành phần sử dụng dịch vụ và thành phần sử dụng dịch vụ hoàn toàn có thể viết phần mềm để truy cập trực tiếp tới dịch vụ. Một thành phần cung cấp dịch vụ sẽ cung cấp nhiều ủy nhiệm cho các môi trường khác nhau, mỗi ủy nhiệm dịch vụ được viết bằng ngôn ngữ của thành phần sử dụng dịch vụ. Ví dụ, một thành phần cung cấp dịch vụ có thể cung cấp các ủy nhiệm cho Java, Visual Basic, Delphi nếu đó là các nền tảng của thành phần sử dụng dịch vụ sử dụng dịch vụ. Mặc dù ủy nhiệm dịch vụ là không bắt buộc nhưng nó có thể cải thiện một cách đáng kể hiệu năng và tính tiện dụng cho các thành phần sử dụng dịch vụ. Hình 1.9: Ủy nhiệm dịch vụ Ràng buộc sử dụng dịch vụ: Ràng buộc sử dụng dịch vụ mà thành phần đăng ký dịch vụ gán cho thành phần sử dụng dịch vụ rất cần thiết để dịch vụ bảo trì được thông tin trạng thái liên kết giữa thành phần sử dụng và thành phần cung cấp. Nó tạo ra sự gắn kết không chặt chẽ giữa các thành phần này bằng cách giới hạn khoảng thời gian mà chúng được liên kết với nhau. Không có ràng buộc, một thành phần sử dụng dịch vụ có thể liên kết với một dịch vụ mãi mãi và không bao giờ liên kết lại với giao ước của nó. Các thao tác trong kiến trúc hướng dịch vụ bao gồm: Xuất bản dịch vụ: Để có thể truy cập được, một mô tả dịch vụ phải được xuất bản để nó có thể được tìm thấy và triệu gọi bởi một người dùng dịch vụ. Tìm kiếm dịch vụ: Một người yêu cầu dịch vụ định vị một dịch vụ bằng cách yêu cầu nơi đăng ký dịch vụ một dịch vụ phù hợp với các tiêu chí đặt ra. Liên kết và thực thi dịch vụ: Sau khi nhận được mô tả dịch vụ, người dùng sẽ gọi dịch vụ theo các thông tin mô tả. 2.2.3. Lợi ích của kiến trúc hướng dịch vụ Như đã trình bày trong phần mở đầu, các doanh nghiệp đang phải đối mặt với hai vấn đề cơ bản: khả năng thay đổi một cách nhanh chóng, và yêu cầu giảm giá thành sản phẩm. Với kiến trúc hướng dịch vụ, chúng ta có thể nhận thấy nhiều lợi ích giúp các tổ chức thành công trong môi trường kinh doanh hiện nay: Thúc đẩy được các tài sản hiện có SOA cung cấp một lớp trừu tượng cho phép một tổ chức tiếp tục thúc đẩy đầu tư vào công nghệ thông in bằng cách đóng gói những tài sản hiện có này thành những dịch vụ cho các chức năng nghiệp vụ. Các tổ chức có thể tiếp tục thu được lợi nhuận từ các tài nguyên hiện có thay vì phải xây dựng lại chúng từ đầu. Tích hợp và quản lý độ phức tạp dễ dàng hơn Điểm tích hợp trong một kiến trúc hướng dịch vụ là đặc tả dịch vụ, không phải là cài đặt dịch vụ. Điều này làm cho cài đặt được trong suốt và tổi thiểu hoá ảnh hưởng khi thay đổi hạ tầng và cài đặt xảy ra. Bằng cách cung cấp một đặc tả dịch vụ trước các tài nguyên và tài sản hiện có được xây dựng trên các hệ thống riêng biệt, tích hợp trở nên dễ quản lý hơn vì độ phức tạp được cô lập. Việc này thậm chí còn trở nên quan trọng hơn khi nhiều nghiệp vụ hơn hoạt động cùng nhau để tạo nên một dây chuyền. Nhạy bén hơn và thời gian tung ra thị trường nhanh hơn. Khả năng tạo thành các dịch vụ mới từ những tài nguyên hiện có đem lại một lợi ích khác biệt cho một tổ chức phải nhanh chóng đáp ứng được yêu cầu nghiệp vụ thay đổi. Thúc đẩy các thành phần và dịch vụ hiện có làm giảm thời gian cần thiết để đi qua vòng đời phát triển phần mềm gồm: thu thập yêu cầu, thực hiện thiết kế, phát triển và kiểm thử. Việc này dẫn tới sự phát triển nhanh của các dịch vụ nghiệp vụ mới và cho phép tổ chức nhanh chóng đáp ứng được các thay đổi và giảm thời gian cần thiết để tung sản phẩm ra thị trường. Giảm giá thành và tăng cường tái sử dụng: Với các dịch vụ nghiệp vụ cốt lõi được thể hiện theo cách liên kết lỏng lẻo, chúng có thể được sử dụng một cách dễ dàng hơn và có thể được kết hợp dựa trên các yêu cầu nghiệp vụ; có nghĩa là giảm sự trùng lặp về tài nguyên, nâng cao tiềm năng tái sử dụng và hạ giá thành sản phẩm. SOA cho phép các doanh nghiệp sẵn sàng cho tương lai. Các quy trình nghiệp vụ bao gồm hàng loạt các dịch vụ nghiệp vụ có thể được tạo ra, thay đổi và quản lý một cách dễ dàng hơn để phù hợp với yêu cầu về thời gian. SOA đem lại tính linh hoạt và nhạy bén cần thiết cho các tổ chức có thể tồn tại và phát triển. Chuyển sang kiến trúc hướng dịch vụ không phải là một nhiệm vụ đơn giản. Thay vì việc chuyển toàn bộ các chức năng nghiệp vụ của một doanh nghiệp thành hướng dịch vụ, hướng tiếp cận được khuyến cáo là chỉ chuyển một tập con phù hợp của chức năng nghiệp vụ khi doanh nghiệp phát sinh nhu cầu hoặc đoán trước được các nhu cầu. Kiến trúc hướng dịch vụ tạo ra một viễn cảnh và một cách suy nghĩ khác so với các kiến trúc trước đây, nhưng kiến trúc hướng dịch vụ không phải là một sự thay thế, mà chỉ là sự bổ sung cho các kiến trúc trước, cốt lõi của nó vẫn là kỹ thuật lập trình hướng dịch vụ và hướng thành phần: kiến trúc hướng dịch vụ thích hợp cho tính liên thông giữa các môi trường thực thi khác nhau, bao gồm cả hướng đối tượng, hướng thủ tục, và các hệ thống khác. Khi sử dụng kiến trúc hướng dịch vụ, các hệ thống công nghệ thông tin hiện đang tồn tại có thể được xem như là các dịch vụ cung cấp các chức năng nghiệp vụ. Các dịch vụ này có thể dễ dàng tích hợp với nhau vì chúng có các giao diện rõ ràng và có thể truy cập nhờ việc sử dụng các chuẩn và các giao thức truyền thông phổ biến. Chính điều này đã đặt nền tảng cho việc tích hợp các dịch vụ thành những dịch vụ mới phản ánh các quy trình nghiệp vụ. 2.3. Dịch vụ và thành phần Thành phần là gì? “Thành phần là một gói các tạo tác phần mềm có thể được phát triển một cách độc lập và có thể được phân phối như là một đơn vị, các đơn vị này sau đó có thể kết hợp với nhau để tạo thành một thứ gì đó lớn hơn “. Hình 1.10: Thành phần Dịch vụ là gì? “Dịch vụ là một chức năng rõ ràng, tự chứa đựng và không phụ thuộc vào ngữ cảnh hoặc trạng thái của các dịch vụ khác.” Hình 1.11: Dịch vụ Mối quan hệ giữa dịch vụ và thành phần: Hình 1.12: Mối quan hệ giữa thành phần và dịch vụ Dịch vụ là một đơn vị xử lý có mức độ đóng gói cao, nó dùng và sinh ra các tập đối tượng được truyền theo kiểu tham trị. Dịch vụ không giống như đối tượng trong ngôn ngữ lập trình, nó gần với khái niệm giao dịch kinh doanh hơn. Một dịch vụ gồm một tập hợp các thành phần hoạt động cùng nhau để cung cấp một chức năng nghiệp vụ. Vì vậy, có thể nói rằng thành phần có mức độ đóng gói thấp hơn hơn dịch vụ. Ngoài ra, trong khi dịch vụ ánh xạ tới một chức năng nghiệp vụ thì thành phần ánh xạ tới các thực thể nghiệp vụ và quy tắc nghiệp vụ thao tác trên các thực thể đó. Ví dụ, xem xét mô hình thành phần Đơn đặt mua hàng (Purchase Order) cho ví dụ quản lý mạng lưới cung cấp trong hình sau: Hình 1.13: Mô hình thành phần đơn đặt mua hàng Trong thiết kế hướng thành phần, các thành phần được tạo ra gần tương đương với các thực thể nghiệp vụ (như Customer, Purchase Order, Oder Item) và đóng gói hành vi phù hợp với các hành vi mà thực thể cần. Ví dụ, thành phần Purchase Order cung cấp các hàm nhận thông tin về danh sách các sản phẩm được đặt và tổng số lượng của đơn đặt hàng; thành phần Item cung cấp các hàm để nhận được thông tin về số lượng và giá thành của sản phẩm được đặt. Cài đặt của mỗi thành phần được đóng gói sau giao diện. Vì vậy, một người dùng thành phần Purchase Order không biết về lược đồ bảng Purchase Order và thuật toán tính thuế, số tiền được giảm trên tổng số đơn đặt hàng. Trong thiết kế hướng dịch vụ, các dịch vụ được thiết kế không dựa trên các thực thể nghiệp vụ, thay vào đó, mỗi dịch vụ là một khối quản lý các thao tác trên một tập các thực thể nghiệp vụ. Ví dụ, dịch vụ Customer sẽ trả lời bất kỳ yêu cầu nào từ hệ thống hoặc dịch vụ khác cần truy cập tới thông tin khách hàng. Dịch vụ Customer có thể xử lý một yêu cầu cập nhật thông tin khách hàng, thêm, cập nhật, xoá các danh mục đầu tư, và điều tra về lịch sử đặt hàng của Customer. Dịch vụ Customer chứa tất cả các dữ liệu liên quan tới khách hàng mà nó đang quản lý và có khả năng tạo ra các yêu cầu dịch vụ với danh nghĩa là người dùng dịch vụ để cung cấp một khung nhìn dịch vụ khách hàng thống nhất. Điều này có nghĩa là một dịch vụ là một đối tượng quản lý tạo ra và quản lý tập các thành phần của nó. Kiến trúc hướng dịch vụ và phát triển hướng thành phần Ở rất nhiều khía cạnh, SOA là một sự phát triển các nguyên lý cơ bản của phát triển hướng thành phần (CBD – Component-based Development). Nó cũng biểu diễn một bước phát triển trong việc đem các nghiệp vụ và công nghệ thông tin xích lại gần nhau hơn. Trong khi các dịch vụ SOA là hữu hình đối với người dùng dịch vụ, các thành phần nền tảng của chúng là trong suốt. Đối với người cung cấp dịch vụ, thiết kế của các thành phần, sự thể hiện và quản lý dịch vụ phản ánh các quyết định thiết kế và kiến trúc chính cho phép phát triển dịch vụ trong SOA. Việc ra những quyết định đó đòi hỏi một sự hiểu biết về các thành phần của SOA và mô hình hóa SOA để nhận diện, phân loại, xác định và cấu trúc các thành phần của dịch vụ. Sự phát triển của SOA bắt nguồn từ phát triển hướng đối tượng và hướng thành phần. Thế giới của các đối tượng bắt đầu với sự xuất hiện của các ngôn ngữ lập trình hướng đối tượng và được phát triển thành mô hình, sau đó, nó được thêm vào các kỹ thuật thiết kế và các phương pháp phân tích thiết kế hướng đối tượng. Các dịch vụ hạ tầng, các công cụ, các nền tảng phát triển, các mẫu, và các kiến trúc tham chiếu xuất hiện sau đó. Phát triển hướng thành phần đã tạo ra một hướng tiếp cận mới trong việc thiết kế, xây dựng, cài đặt và phát triển của các ứng dụng phần mềm. Các ứng dụng được lắp ráp từ các thành phần từ nhiều nguồn khác nhau, các thành phần được viết trên nhiều ngôn ngữ lập trình khác nhau, nhiều môi trường khác nhau, và chạy trên các nền tảng khác nhau. Nhưng chỉ với phát triển hướng đối tượng, các dịch vụ hạ tầng, các công cụ, nền tảng phát triển và các mẫu mới làm cho phát triển hướng thành phần trở thành hiện thực. Cả hướng đối tượng và hướng thành phần đều yêu cầu tính tái sử dụng trong phát triển phần mềm. Với phát triển hướng đối tượng thì đó một yếu tố tùy chọn, còn với phát triển hướng thành phần là bắt buộc. Phát triển hướng dịch vụ đem lại khả năng tái sử dụng lớn hơn so với phát triển hướng đối tượng. SOA, với nền tảng là cả phát triển hướng đối tượng và hướng thành phần, còn tạo ra khả năng tái sử dụng cao hơn nữa. nó đã trở thành một nhân tố mới để đạt được kinh tế trong công nghệ phần mềm. Các khái niệm và quy tắc của phát triển hướng đối tượng và hướng thành phần được áp dụng để đem lại các framework thích hợp cho việc chỉ đạo thiết kế và phát triển các dịch vụ SOA. Rất nhiều các nhà cung cấp dịch vụ thường cài đặt một mô tả dịch vụ. Trong các thành phần, chúng ta có thể tìm thấy các quy tắc thiết kế của hướng đối tượng xác định các cấu trúc trong của thành phần. Do vậy, mô hình hóa dịch vụ là nhằm xác định đúng các dịch vụ, tổ chức chúng theo một cây phân cấp của các dịch vụ phức hợp (các thành phần có mức độ đóng gói thấp hỗ trợ các thành phần có mức độ đóng gói cao), sắp xếp chúng để hỗ trợ cho một quy trình nghiệp vụ. Về phía nhà cung cấp, các dịch vụ này hoặc là được cấp phát một cách trực tiếp cho các thành phần chứa hướng thành phần để cài đặt các chức năng của chúng, hoặc được cài đặt bằng cách thay đổi các chức năng sẵn có. Đây là bước tiến cơ bản trong công nghệ phần mềm hướng dịch vụ: thành phần sử dụng dịch vụ không cần phải quan tâm về việc cài đặt hay hiện thực hóa của dịch vụ, miễn là nó hỗ trợ các chức năng và chất lượng theo đúng yêu cầu của dịch vụ. Đây được gọi là khung nhìn của thành phần sử dụng (Consumer View). Bên cạnh đó, khung nhìn của thành phần cung cấp đưa ra một triển vọng về cách thiết kế cài đặt của thành phần cung cấp dịch vụ; các quyết định và thiết kế kiến trúc của nó. Một sự khác biệt chính với hướng đối tượng truyền thống là chúng ta không còn phải tạo ra các mô hình đối tượng lớn, mà chỉ cần tạo ra các thiết kế bên trong của các ranh giới thành phần có mức độ đóng gói cao hơn, thông qua hướng đối tượng có mức độ đóng gói thấp hơn. Các thành phần cung cấp dịch vụ không cần quan tâm tới các thành phần sử dụng dịch vụ, chỉ cần các giao ước sử dụng dịch vụ của chúng được thỏa mãn. Thành phần cung cấp dịch vụ cần thiết kế một cài đặt dịch vụ thỏa mãn các yêu cầu đó thông qua các quyết định về việc chúng chứa đựng, quản lý và cài đặt đặc tả dịch vụ như thế nào. Khung nhìn bên trong là khung nhìn của người sử dụng hoặc thành phần sử dụng – tức là những thành phần chỉ nhìn thấy dịch vụ thông qua thành phần cung cấp, và khung nhìn ngoài, ở đó thành phần cung cấp dịch vụ tạo ra các dịch vụ thông qua các giao diện của chúng. Để thực hiện được như vậy, chúng yêu cầu một tập trong gồm các thành phần có mức độ đóng gói thấp hơn, hoặc ngang bằng tham gia vào các cộng tác cần thiết để đáp ứng các dịch vụ. Do vậy, trong các thành phần cung cấp dịch vụ, chúng ta sẽ có các thành phần ở mức độ miền tương ứng với các mô hình đối tượng miền trong hướng đối tượng truyền thống và được cài đặt thông qua các cơ chế chứa đựng thành phần chuẩn hóa như các máy chủ ứng dụng (Application server). 3. Thiết kế theo kiến trúc hướng dịch vụ Trong sự tiến hóa của các các kỹ thuật xây dựng phần mềm, kỹ thuật lập trình hướng đối tượng thích hợp để cài đặt các thành phần. Trong khi các thành phần lại là cách thích hợp nhất để cài đặt các dịch vụ, mặc dù cần hiểu rằng một ứng dụng dựa thành phần tốt không cần thiết phải là một ứng dụng hướng dịch vụ tốt. Khi vai trò của dịch vụ trong kiến trúc ứng dụng được hiểu rõ, chúng ta có thể tích hợp các thành phần mới và các thành phần hiện có. Hình 1.14 minh hoạ cách các tầng công nghệ có thể được áp dụng cho kiến trúc ứng dụng để đem lại các cài đặt ở mức độ đóng gói cao hơn khi tiến gần hơn tới người dùng ứng dụng, nó cũng cho thấy dịch vụ là cách thích hợp để thể hiện khung nhìn ngoài của một hệ thống với sự tái sử dụng bên trong có sử dụng thiết kế thành phần truyền thống. Hình 1.14: Các tầng cài đặt trong thiết kế: đối tượng, thành phần, dịch vụ 3.1. Các nguyên tắc trong thiết kế hướng dịch vụ Việc tiếp cận xây dựng các hệ thống dựa trên mô hình hướng dịch vụ phải tuân theo bốn nguyên tắc sau [6]: Nguyên tắc 1 : Giao diện của dịch vụ phải rõ ràng. Các dịch vụ tương tác qua việc truyền đi các thông điệp tường minh. Chúng ta không cần biết về không gian nằm sau giao diện của dịch vụ. Vượt qua các giao diện của dịch vụ có thể tốn nhiều công sức và chi phí. Các giao diện rõ ràng cho phép cài đặt các tương tác độc lập – nghĩa là không cần biết về nền tảng hay các ngôn ngữ lập trình được lựa chọn để cài đặt các dịch vụ. Nguyên tắc 2: Dịch vụ là tự trị. Các dịch vụ hoạt động như là các thực thể độc lập. Không có quyền làm chủ trong một môi trường hướng dịch vụ. Các dịch vụ được triển khai, thay đổi, quản lý một cách độc lập. Nguyên tắc 3 : Các dịch vụ chia sẻ giao diện và giao ước không chia sẻ cài đặt. Các dịch vụ tương tác với nhau chỉ dựa vào giao diện và giao ước sử dụng dịch vụ. Giao ước của dịch vụ mô tả cấu trúc của thông điệp và các ràng buộc giữa các thông điệp, điều này cho phép chúng ta bảo toàn được tính toàn vẹn của dịch vụ. Các giao ước và giao diện phải được duy trì tính ổn định với thời gian. Vì vậy việc xây dựng chúng một cách mềm dẻo là rất quan trọng. Nguyên tắc 4 : Tính tương thích của dịch vụ dựa trên chính sách. Cả người cung cấp và người dùng dịch vụ sẽ phải có các chính sách để tương tác qua các giao diện của dịch vụ. Một ví dụ đơn giản về chính sách phía người cung cấp là một dịch có thể đỏi hỏi người gọi phải có một tài khoản hợp lệ với người cung cấp dịch vụ. Về phía người dùng dịch vụ, một tổ chức có thể đòi hỏi các lời gọi qua Internet phải được mã hóa. 3.2. Các quyết định thiết kế và kiến trúc trong kiến trúc hướng dịch vụ Có rất nhiều quyết định thiết kế và kiến trúc là nền tảng cho SOA để đạt được các mục tiêu và lợi ích mà kiến trúc này đã nêu ra. Các quyết định kiến trúc thường liên quan tới việc chọn lựa các công nghệ và sản phẩm cần thiết để đáp ứng chất lượng cho các thuộc tính dịch vụ được yêu cầu bởi một quy trình nghiệp vụ. Các quyết định thiết kế tập trung vào các lựa chọn dịch vụ sử dụng kỹ thuật được mô tả sau trong phân tích và thiết kế hướng đối tượng. Một số các quyết định chính là [5]: Xác định dịch vụ: các quyết định thiết kế quyết định thành công của một kiến trúc hướng dịch vụ. Thiết kế và cài đặt thành phần chứa: các quyết định thiết kế và kiến trúc rất quan trọng để một dịch vụ cung cấp các chức năng cho việc mở rộng vào bảo trì. Mức độ đóng gói: các lựa chọn thiết kế về dịch vụ phải phù hợp với mức độ tái sử dụng và mềm dẻo được yêu cầu trong ngữ cảnh cụ thể. Các dịch vụ có mức độ đóng gói cao hơn có thể trợ giúp việc đóng gói các thay đổi trong các dịch vụ kỹ thuật có mức độ đóng gói thấp hơn (các dịch vụ này thường có xu hướng thay đổi thường xuyên hơn so với các nghiệp vụ ở mức cao hơn). Các nhân tố của tính mềm dẻo sẽ là các tiêu chuẩn chính cho việc đóng gói hơn là việc chỉ đơn thuần đóng gói chức năng. Tính gắn kết không chặt chẽ và cấu hình lại động là một quyết định thiết kế yêu cầu việc tách các giao diện khỏi cài đặt và cài đặt giao thức thông qua các chuẩn mở. Kết nối giữa các thành phần cung cấp và sử dụng dịch vụ cần phải bền vững và được cấu trúc rõ ràng, có khả năng cấu hình lại linh hoạt. Có khả năng cấu hình lại có nghĩa lấcc thành phần sử dụng dịch vụ và các thành phần cung cấp dịch vụ hiện có có thể được lắp ghép lại với chức năng không bị thay đổi để đạt được các giải pháp nghiệp vụ trong các môi trường kỹ thuật khác nhau và với các ràng buộc thao tác khác nhau của các đối tác kinh doanh mới. Các tầng SOA: Các thành phần của một kiến trúc hướng dịch vụ. Các thành phần chính của một kiến trúc hướng dịch vụ là: Danh mục dịch vụ: mô tả các dịch vụ nghiệp vụ trong SOA, bao gồm một danh sách, phân loại và cấu trúc cây của các dịch vụ được xác định thông qua kx thuật phân tích và thiết kế hướng dịch vụ. Các thành phần: Cung cấp các cài đặt chức năng của dịch vụ. Thành phần sử dụng dịch vụ, thành phần cung cấp dịch vụ và thành phần môi giới dịch vụ (tùy chọn) với các kho đăng ký dịch vụ, ở đó, các định nghĩa và mô tả dịch vụ được xuất bản. Các tầng SOA: vị trí của các thành phần và dịch vụ. Hình 1.15 mô tả các tầng SOA. Với mỗi tầng, các quyết định thiết kế và kiến trúc được tiến hành. Hình 1.15: Các tầng của SOA Tầng 1: tầng dưới cùng, mô tả các hệ thống vận hành. Tầng này chứa các hệ thống hoặc ứng dụng hiện có, bao gồm các ứng dụng được đóng gói, các ứng dụng đang có, và các cài đặt hệ thống hướng đối tượng theo kiểu cũ cũng như các ứng dụng thu thập nghiệp vụ. Kiến trúc theo tầng của một kiến trúc hướng đối tượng có thể thúc đẩy các hệ thống hiện có, tích hợp chúng bằng cách sử dụng tích hợp hướng dịch vụ. Tầng 2: tầng thành phần, sử dụgn các kỹ thuật và thiết kế dựa đối tượng chứa trong phát triển hướng thành phần truyền thống. Tầng 3: cung cấp cơ chế để lấy các thành phần ở quy mô doanh nghiệp, các thành phần cho từng đơn vị nghiệp vụ cụ thể, và trong một số trường hợp là các thành phần của từng dự án và cung cấp các dịch vụ thông qua các giao diện của chúng. Trong tầng này, các giao diện được thể hiện ra ngoài thông qua các đặc tả dịch vụ, ở đó, các dịch vụ tồn tại một cách độc lập hoặc là tổng hợp của một số dịch vụ. Tầng 4: là một sự tiến hóa của việc tổng hợp dịch vụ thành các luồng hoặc sắp đặt các nhiệm vụ được phân nhóm vào một luồng để hoạt động như một ứng dụng. Các ứng dụng này hỗ trợ các trường hợp sử dụng và các quy trình nghiệp vụ cụ thể. Ở đây, các công cụ tổng hợp luồng trực quan có thể được sử dụng để thiết kế luồng ứng dụng. Tầng 5: Tầng trình diễn thường là nằm ngoài phạm vi của một kiến trúc hướng dịch vụ. Tầng 6: cho phép sự tích hợp của các dịch vụ thông qua việc định tuyến tin cậy và thông minh, giao thức trung gian, và một số cơ chế chuyển đổi khác, thường được mô tả như là một tuyến dịch vụ doanh nghiệp (ESB – Enterprise Service Bus). Tầng 7: đảm bảo chất lượng dịch vụ thông qua các cơ chế cảm biến và đáp ứng và các công cụ kiểm soát các ứng dụng SOA. 3.3. Các mức độ chấp nhận kiến trúc hướng dịch vụ Việc sử dụng kiến trúc hướng dịch vụ không bị giới hạn cho các tổ chức lớn. Trong thực tế, kiến trúc này tạo ra cơ hội cho các tổ chức vừa và nhỏ. Một ví dụ về việc các doanh nghiệp nhỏ có thể sử dụng dịch vụ là việc nhận các hóa đơn: chúng ta có thể dùng dịch vụ mạng để tạo ra một dịch vụ nhận hóa đơn. Các hóa đơn này sẽ được lưu trữ bởi dịch vụ cho đến khi hệ thống kế toán trên máy PC của người dùng kết nối đến nó để nhận hóa đơn về bằng cách sử dụng dịch vụ mạng. Các hóa đơn sau đó sẽ được cập nhận một cách tự động trên PC… Bằng cách này, bất kỳ tổ chức nào, không phụ thuộc vào quy mô lớn hay nhỏ, đều có thể nhận được lợi ích từ việc sử dụng kiến trúc hướng dịch vụ. Một tổ chức có thể dùng nhiều cách khác nhau để nhận được kiến trúc hướng dịch vụ, tuỳ thuộc vào mục tiêu và các ràng buộc công nghệ thông tin. Hình 1.16: Các mức độ thực hiện kiến trúc hướng dịch vụ Mức độ 1: Cài đặt các dịch vụ riêng lẻ. Mức độ này tạo ra các dịch vụ từ các nhiệm vụ có trong các ứng dụng mới hoặc các ứng dụng hiện có. Kiến trúc hướng dịch vụ đem lại khả năng thiết kế các ứng dụng và hệ thống cung cấp các dịch vụ cho các ứng dụng khác thông qua các giao diện được xuất bản. Cách tạo ra các ứng dụng này có thể đưa đến một mô hình lập trình mạnh hơn, linh hoạt hơn, giảm chi phí cả trong phát triển và bảo trì. Mức độ 2: Tích hợp hướng dịch vụ các chức năng nghiệp vụ Mức độ tiếp theo là tích hợp hướng dịch vụ. Bước này bao gồm việc tích hợp các dịch vụ từ nhiều ứng dụng khác nhau cả bên trong và bên ngoài doanh nghiệp để phục vụ cho mục đích nghiệp vụ. Mức độ này cũng phải hỗ trợ nhiều kiểu tích hợp, bao gồm: Tích hợp ứng dụng: gồm phát triển các giao diện mới để thể hiện các ứng dụng hiện có. Tích hợp thông tin: gồm cả dữ liệu doanh nghiệp và dữ liệu liên phòng ban. Tích hợp quy trình: gồm tích hợp qua sự tập hợp, sắp xếp các ứng dụng và dịch vụ với nhiều giao diện. Tích hợp hệ thống: gồm sự kết nối các hệ thống không đồng nhất, các hệ thống hiện có và tích hợp ứng dụng. Mức độ 3: Chuyển đổi doanh nghiệp công nghệ thông tin có quy mô lớn. Mức cài đặt SOA rộng hơn này là một cài đặt được kiến trúc hoá cho phép tích hợp nhiều chức năng nghiệp vụ trong toàn doanh nghiệp. Mức độ 4: Chuyển đổi nghiệp vụ theo yêu cầu. Đây là mức độ cuối cùng trong phát triển kiến trúc hướng dịch vụ. Mức độ này là sự định hướng chiến lược hướng tới sự chuyển đổi rộng của các mô hình nghiệp vụ hiện có hoặc sự triển khai của các mô hình nghiệp vụ mới. 3.4. Các bước trong quy trình phát triển phần mềm theo định hướng dịch vụ Hiện nay, chưa có một quy trình cụ thể để phát triển các ứng dụng theo kiến trúc hướng dịch vụ, tuy nhiên, dựa trên thực tế, 12 bước sau đã được đưa ra nhằm tham khảo khi quyết định chuyển sang định hướng dịch vụ [3]. 12 bước trong quy trình phát triển phần mềm theo kiến trúc hướng dịch vụ: Hiểu nghiệp vụ. Xác định phạm vi (miền) của vấn đề. Hiểu tất cả các ngữ nghĩa ứng dụng trong miền đó. Hiểu tất cả các dịch vụ hiện có trong miền. Hiểu tất cả các nguồn và đích của thông tin có trong miền. Hiểu tất cả các quy trình trong miền. Xác định và phân loại tất cả các giao diện bên ngoài miền cần thiết cho việc xây dựng ứng dụng (các dịch vụ và thông tin). Định nghĩa các dịch vụ mới và các ràng buộc thông tin của các dịch vụ đó. Định nghĩa các quy trình mới, cũng như các dịch vụ và ràng buộc thông tin cho các quy trình này. Lựa chọn tập công nghệ. Triển khai công nghệ SOA. Kiểm thử và đánh giá. Bước 1: Hiểu các mục đích nghiệp vụ, và xác định thành công. Đây là nhiệm vụ thu thập yêu cầu cơ bản. Nó đòi hỏi phải tiếp xúc với tài liệu, nhân sự và hệ thống để xác định thông tin cho phép việc tích hợp ứng dụng được xác định đúng để có thể phân tích, mô hình hóa và cải tiến. Chỉ sau khi thực hiện bước này thì tập giải pháp thích hợp mới được đưa ra. Cần lưu ý rằng có cả lợi ích hữu hình và vô hình từ việc cài đặt bất kỳ loại công nghẹ nào. Lợi ích hữu hình bao gồm việc tiết kiệm chi phí tức thì, như việc tự động hóa một hệ thống bán theo đơn đặt hàng thay cho việc bán hàng thủ công. Lợi ích vô hình thì khó nhận biết hơn, như sự thỏa mãn của khách hàng dẫn tới việc tăng doanh số bán hàng, hoặc cộng tác chặt chẽ hơn tăng cường chất lượng và cho phép các nhân công trao đổi thông tin tốt hơn. Bước 2: Xác định miền vấn đề. Phải xác định phạm vi của việc ứng dụng SOA trong một tổ chức. Hãy chia nhỏ tổ chức để áp dụng SOA thay vì áp dụng vào toàn bộ tổ chức. Cùng với thời gian, những thành công nhỏ sẽ dẫn tới các chiến lược thành công lớn hơn, phải thiết lập các đường ranh giới khi bắt đầu dự án để có thể tiến hành xây dựng ứng dụng một cách trọng tâm hơn. Bước 3: Hiểu tất cả các ngữ nghĩa ứng dụng trong miền vấn đề. Chúng ta không thể giải quyết các vấn để mà bản thân mình không hiểu rõ. Vì vậy, bước tiếp theo này là cực kỳ quan trọng để xác định tất cả các siêu dữ liệu ngữ nghĩa tồn tại trong miền ứng dụng nhằm giải quyết vấn đề một cách hoàn hảo. Sự hiểu biết về ngữ nghĩa ứng dụng thiết lập cách thức và khuôn dạng trong đó ứng dụng tham khảo các thuộc tính của quy trình nghiệp vụ. Ví dụ, cùng một số hiệu khách hàng nhưng trong một ứng dụng này có thể có một giá trị và ý nghĩa hoàn toàn khác trong một ứng dụng khác. Việc hiểu ngữ nghĩa của ứng dụng đảm bảo rằng sẽ không có bất kỳ sự xung đột thông tin nào khi nó được tích hợp với các ứng dụng khác ở mức độ thông tin hoặc dịch vụ. Xác định ngữ nghĩa của ứng dụng là một công việc khó khăn vì có thể nhiều hệ thống mà chúng ta đang phân tích đã cũ hoặc mang tính độc quyền. Bước đầu tiên trong việc xác định và định vị ngữ nghĩa là tạo ra một danh sách các hệ thống ứng viên. Danh sách này sẽ cho phép chúng ta có thể xác định những kho chứa dữ liệu nào tồn tại trong các hệ thống đó. Bất kỳ công nghệ nào có thể xây dựng lại các lược đồ dữ liệu vật lý và logic cũng sẽ có ích trong việc xác định dữ liệu trong các miền vấn đề. Tuy nhiên, trong khi lược đồ và mô hình dữ liệu có thể cho phép nhìn vào cấu trúc của cơ sở dữ liệu thì chúng lại không thể xác định những thông tin đó được sử dụng như thế nào trong ngữ cảnh của dịch vụ hoặc ứng dụng; đó là lý do chúng ta cần tới các bước tiếp theo. Bằng việc hiểu rõ các ngữ nghĩa của ứng dụng, chúng ta có thể hiểu trọn vẹn việc tích hợp ứng dụng, và đảm bảo rằng tất cả các hệ thống nguồn và đích trong và giữa các tổ chức được tích hợp một cách hoàn hảo. Bước 4: Hiểu tất cả các dịch vụ hiện có trong miền. Tìm hiểu các thông tin về dịch vụ, bao gồm: Vị trí của dịch vụ. Mục đích của dịch vụ. Thông tin ràng buộc của dịch vụ. Các phụ thuộc (nếu đó là một dịch vụ phức hợp). Các vấn đề bảo mật. Vị trí tốt nhất để bắt đầu tìm hiểu là thư mục dịch vụ. Giống như các thư mục khác, đây là một kho chứa các thông tin được thu thập về các dịch vụ hiện có, cùng với các tài liệu về mỗi dịch vụ, bao gồm mục đích của dịch vụ, các thông tin vào/ ra… Thư mục này được sử dụng cùng với những hiểu biết về ngữ nghĩa của ứng dụng để xác định các điểm tích hợp trong tất cả các hệ thống của miền vấn đề. Bước 5: Hiểu tất cả các nguồn và đích thông tin hiện có trong miền vấn đề. Bước này xác định các giao diện xử lý các thông tin đơn giản. Chúng có thể thực hiện một trong 2 vai trò: sử dụng thông tin (đích) hoặc cung cấp thông tin (nguồn). Chúng ta cần phải hiểu rõ các khía cạnh sau: Vị trí của chúng. Cấu trúc của luồng thông tin vào/ ra. Các ràng buộc tích hợp. Các phụ thuộc (các nguồn và đích khác, cũng có thể là các dịch vụ). Các vấn đề bảo mật. Bước 6: Hiểu tất cả các quy trình. Chúng ta cần xác định và liệt kê tất cả các quy trình nghiệp vụ tồn tài trong miền vấn đề, có thể là tự động hóa hoặc không phải tự động hóa. Việc này rất quan trọng vì chúng ta đã biết dịch các dịch vụ và nguồn/ đích thông nào hiện có, chúng ta cần phải xác định các cơ chế tương tác cao hơn, bao gồm tất cả các quy trình ở mức mức cao, mức trung bình và mức thấp. Trong nhiều trường hợp, những quy trình này vẫn chưa được tự động hóa hoặc chỉ có một phần được tự động hóa. Ví du, nếu một kiến trúc sư tích hợp ứng dụng cần hiểu tất cả các quy trình hiện có trong một ứng dụng kiểm kê, anh ta sẽ hoặc là đọc tài liệu hoặc là đọc mã nguồn để xác định quy trình nào đang được thực hiện. Sau đó, anh ta sẽ đưa quy trình nghiệp vụ vào phân loại và xác định mục đích của quy trình, ai là người sở hữu nó, nó chính xác là gì, và công nghệ để thực hiện nó (Java hoặc C++ …). Những quy trình này sau đó được gắn với các quy trình mới để đáp ứng được yêu cầu nghiệp vụ. Chúng ta cần phải xem xét khá._.ặt dịch vụ có thể được tìm thấy bằng cách: đầu tiên, định vị một doanh nghiệp hay một kiểu doanh nghiệp, sau đó, xác định các dịch vụ mà các doanh nghiệp đó cung cấp. Cài đặt dịch vụ cũng có thể được định vị bằng cách tìm kiếm một phân lớp dịch vụ, hoặc bằng cách định vị một kiểu dịch vụ (hoặc giao diện dịch vụ). Nếu giao diện dịch vụ là đích của thao tác tìm kiếm thì nó được sử dụng để định vị các cài đặt của giao diện dịch vụ. Tạo và triển khai uỷ nhiệm dịch vụ: Sử dụng giao diện dịch vụ cùng với cài đặt dịch vụ để sinh ra mã uỷ nhiệm dịch vụ được sử dụng để gọi dịch vụ. Sau khi mã được sinh ra, nó được biên dịch để chạy trong môi trường thời gian chạy. Gọi dịch vụ mạng: Mã uỷ nhiệm dịch vụ đã sinh ra được sử dụng để gọi dịch vụ mạng. 5. Xây dựng dịch vụ mạng 5.1. Vòng đời của dịch vụ mạng Vòng đời của dịch vụ mạng gồm 5 giai đoạn, đó là: mô tả - cài đặt – xuất bản, tìm kiếm và liên kết – gọi và thực thi – trả về kết quả. Mô tả: Định nghĩa trừu tượng của điểm cuối dịch vụ mạng được mô tả bằng file WSDL. WSDL mô tả dịch vụ mạng như là một tập hợp của các điểm cuối hoặc cổng. Cài đặt: SOAP được sử dụng để mô tả các yêu cầu và đáp ứng từ một dịch vụ mạng. Xuất bản, tìm kiếm và liên kết: Để máy khách có thể truy cập được, cài đặt của dịch vụ mạng cần được xuất bản trong nơi đăng ký UDDI. Nơi đăng ký UDDI mô tả thông tin về cách kết nối và tương tác với dịch vụ. Gọi và thực thi: Bộ phận lắng nghe SOAP nhận một yêu cầu và thông báo cho các thành phần quan tâm, có thể là ứng dụng hoặc dịch vụ mạng. Sau khi nhận được mọt thông điệp trả lời, SOAP xác thực thông điệp dựa trên lược độ XML mô tả trong WSDL. Cuối cùng, thông điệp SOAP được gửi đến dịch vụ mạng thích hợp. Trả về kết quả: kết quả của dịch vụ mạng được trả về cho máy khách gọi dịch vụ mạng tương ứng. 5.2. Bảo mật trong dịch vụ mạng Mô hình STRIDE Do bản chất tự nhiên, nhiều dịch vụ mạng được đặt trong một môi trường không an toàn – Internet. Vì lý do này, các dịch vụ mạng phải được triển khai những công nghệ bảo mật thích hợp. Trước khi xây dựng các hệ thống của mình, chúng ta nên đặt ra các câu hỏi sau: Một tin tặc chiếm quyền điều khiển giỏ hàng trực tuyến như thế nào? Mức độ ảnh hưởng khi một kẻ tấn công bằng cách từ chối sự truy cập vào dịch vụ của những người dùng hợp lệ là gì? Một kẻ tấn công có thể xem hoặc thay đổi dữ liệu truyền từ dịch vụ tới người dùng bằng cách nào? Để làm được điều này, chúng ta sử dụng mô hình STRIDE. STRIDE là một từ viết tắt của sáu loại nguy cơ an toàn sau: Sự giả mạo định danh (Snoofing identity): Sự giả mạo có nghĩa là việc truy cập một cách bất hợp pháp và sau đó sử dụng thông tin thẩm định quyền của người dùng khác, như username và mật khẩu. Sự giả mạo dữ liệu (Tampering with data): Sự giả mạo dữ liệu bao gồm việc cố tình sửa đổi dữ liệu, ví dụ: thực hiện các thay đổi không được phép đối với dữ liệu, thay đổi dữ liệu khi dữ liệu truyền giữa hai máy tính trên một hệ thống mạng mở như Internet. Từ chối (Repudiation): Từ chối xảy ra khi các người dùng từ chối thực hiện những hành động mà các bên khác không có cách nào để chứng minh điều ngược lại – ví dụ, một người dùng thực hiện một thao tác bất hợp pháp trong hệ thống không có khả năng ghi lại các thao tác bị cấm. Sự không thể chối từ là khả năng của hệ thống có thể chống lại các nguy cơ từ chối. Ví dụ, nếu một người dùng mua một món hàng thì anh ta sẽ phải ký vào mặt hàng này trên biên lai. Người bán hàng có thể sử dụng biên lai đó như một bằng chứng là khách hàng đã nhận được gói hàng. Sự lộ thông tin (Information disclosure): các nguy cơ lộ thông tin bao gồm việc phơi bày thông tin cho những người không được truy cập vào nó. Ví dụ, một người dùng có khả năng được được file mà mình không có quyền truy cập hoặc khả năng mọt kẻ đột nhập có thể đọc dữ liệu truyền giữa hai máy tính. Từ chối dịch vụ (Denial of Service): Các tấn công từ chối dịch vụ đối với những người dùng hợp lệ, ví dụ, bằng cách làm cho Web server tạm thời bị vô hiệu hóa. Sự nâng đặc quyền (Elevation of privilege): trong loại nguy cơ này, một người dùng không có quyền nhận được quyền truy cập và do đó, có khả năng truy cập để làm tổn hại hoặc phá hủy toàn bộ hệ thống. Quay trở lại các câu hỏi được đặt ra trước khi xây dựng hệ thống, chúng ta thấy rằng câu hỏi đầu tiên liên quan tới nguy cơ giả mạo dữ liệu (T), câu hỏi thứ hai liên quan tới nguy cơ từ chối dịch vụ (D) và câu hỏi thứ ba liên quan tới nguy cơ lộ thông tin và nguy cơ giả mạo thông tin (I và T). Một cách đơn giản nhất để áp dụng mô hình STRIDE cho ứng dụng là xem xét mỗi loại nguy cơ sẽ có ảnh hưởng tới mỗi thành phần và các kết nối giữa các thành phần như thế nào. Thực chất của việc này là xem xét mỗi phần của ứng dụng và quyết định xem nguy cơ S, T, R, I, D hay E tồn tại ở thành phần hoặc quy trình đó và ghi chúng lại. Lựa chọn các kỹ thuật để làm giảm nguy cơ. Bước tiếp theo là xác định các kỹ thuật làm giảm nguy cơ thích hợp. Bảng dưới đây chỉ ra một số kỹ thuật và công nghệ đó. Loại nguy cơ Kỹ thuật giảm nhẹ nguy cơ Giả mạo định danh Các quy tắc thẩm định quyền sử dụng các công nghệ như thẩm định cơ bản, thẩm định cốt yếu, chứng nhận X.509, thẩm định .NET Passport, và các thẩm định dựa form khác. Lưu ý rằng một số trường hợp cần thẩm định máy khách, còn một số trường hợp lại cần thẩm định máy chủ. Chúng ta cũng có thể chứng minh rằng dữ liệu đến từ một nơi nào đó bằng cách ký và xác nhận chữ ký. Không lưu giữ các thông tin mật một theo cách không an toàn, đặc biệt là các thông tin thẩm định quyền như mật khẩu hay số định danh cá nhân (PIN). Giả mạo thông tin Bảo vệ dữ liệu với các danh sách điều khiển truy cập (ACL – Access Control List) hoặc các quyền hợp lý. Xác định xem dữ liệu có bị làm giả không bằng cách sử dụng các mã băm hoặc các mã thẩm định thông điệp. Từ chối Bảo vệ khỏi nguy cơ từ chối bao gồm sự thẩm định và dữ liệu được ký, cũng như việc ghi và kiểm tra log. Lộ thông tin Dữ liệu có thể bảo vệ bằng cách sử dụng các danh sách điều khiển truy cập và các quyền hợp lý. Các kỹ thuật đảm bảo tính riêng tư như mã hóa có thể có ích nếu các khóa được sử dụng để mã hóa và giải mã cũng được bảo vệ khỏi nguy cơ bị lộ. Từ chối dịch vụ Các nguy cơ từ chối dịch vụ rất khó để chống lịa vì rất khó xác định khi nào máy chủ bận thật sự và khi nào nó bị tấn công. Nếu chúng ta hạn chế các yêu cầu người dùng, chúng ta có thể sẽ ngăn cản những truy cập của người dùng hợp lệ. Một kỹ thuật đơn giản là hạn chế những hành động mà người dùng vô danh có thể thực hiện. Ví dụ, chúng ta sẽ cấp phát 10% tài nguyên cho người dùng vô danh và 90% tài nguyên cho người dùng hợp lệ. Một số giải pháp khác không nằm trong tầm kiểm soát ứng dụng một cách trực tiếp bao gồm tường lửa và các bộ định tuyến lọc gói tin. Nâng đặc quyền Không yêu cầu các đặc quyền mà mình không cần đến. Bằng cách đó, nếu kẻ tấn công có biết được mã số an toàn thì cũng không thể gây nhiều tổn hại vì anh ta không có nhiều quyền. Một ví dụ về dịch vụ mạng. Xét một trường hợp đơn giản, trong đó một người dùng trao đổi thông tin với dịch vụ mạng, dịch vụ mạng sau đó lại trao đổi thông tin với một cơ sở dữ liệu và trả lại nội dung cho người dùng như trong hình dưới đây. Hình 2.7: Một ví dụ dịch vụ mạng Bảng dưới đây liệt kê một số nguy cơ đối với hệ thống và cách thức làm giảm nhẹ mức độ ảnh hưởng của những nguy cơ này. Đích ID Loại nguy cơ Mô tả Các kỹ thuật làm giảm nguy cơ Dịch vụ mạng 1 1 S Kẻ tấn công tấn công dịch vụ mạng bằng cách sử dụng tấn công từ chối dịch vụ phân tán và đặt dịch vụ của chính mình lên Internet. Ứng dụng của người dùng không biết rằng đang truyền thông với một dịch vụ giả mạo. Sử dụng một kết nối SSL/TLS từ người dùng để thẩm định máy chủ. Trên đường dữ liệu từ người dùng đến dịch vụ 22 T và I Kẻ tấn cống xem hoặc thay đổi thông tin trên đường từ người dùng tới máy chủ và ngược lại. Sử dụng SSL/TLS hoặc IPSec để mã hóa dữ liệu khi nó vào/ra khỏi dịch vụ mạng Trên đường dữ liệu từ người dùng đến dịch vụ 33 E Kẻ tấn công xem dữ liệu mật khẩu trên đường từ người dùng đến máy chủ, nếu người dùng là một quản trị hệ thống, kẻ tấn cống có thể sử dụng username và mật khẩu. Sử dụng một cơ chế thẩm định quyền không truyền mật khẩu dưới dạng tường minh hoặc sử dụng SSL/TLKS hoặc IPSec để bảo vệ kênh truyền tin. Dịch vụ mạng 44 D Kẻ tấn công làm quá tải dịch vụ mạng bằng hàng nghìn yêu cầu không có thật và làm dịch vụ mạng chậm lại. Sử dụng một tường lửa để giới hạn dữ liệu nào là được phép. Xây dựng các logic giới hạn lượng dữ liệu được gửi bởi một người dụng hoặc một địa chỉ IP. Việc giới hạn bằng các địa chỉ IP có thể là khó giải quyết, tuy nhiên, nhiều người dùng hợp lệ sử dụng các ISP có một số lượng hạn chế các địa chỉ IP, vì vậy, nhiều yêu cầu có thể đến từ cùng một địa chỉ IP trong khi thực tế thì chúng từ các người dùng khác nhau trong cùng một máy chủ ủy nhiệm (proxy server). Dữ liệu SQL Server 55 T và I Kẻ tấn công truy cập dữ liệu trong SQL Server một cách trực tiếp mà không thông qua dịch vụ mạng Giới hạn những dữ liệu được phép sử dụng để xây dựng các truy vấn SQL. SQL Server 66 S, T, R, I, D, E Kẻ tấn công sử dụng các thủ tục lưu (stored procedure) xp_cmdshell được xây dựng sẵn trong SQL Server để gọi mã nguy hiểm trong cơ sở dữ liệu SQL. Lệnh này có thể gọi bất kỳ lệnh nào tại máy chủ. Giới hạn những dữ liệu nào được phép sử dụng để xây dựng các truy vấn cơ sở dữ liệu. Loại bỏ các thủ tục lưu (stored procedure) mở rộng như xp_cmdshell. Không kết nối tới SQL Server bằng tài khoản của người quản trị hệ thống vì tài khoản này có thể thực hiện bất kỳ nhiệm vụ SQL Server nào, bao gồm cả việc gọi xp_cmdshell. Các công nghệ bảo mật dịch vụ mạng. Bước thứ ba trong quy trình mô hình hóa nguy cơ bao gồm việc chọn lựa các công nghệ phù hợp để áp dụng các kỹ thuật giảm tác hại của các nguy cơ đã được chọn lựa. Thẩm định quyền các dịch vụ mạng: Thẩm định quyền là khả năng chứng minh một thực thể - ví dụ, một người sử dụng hoặc một máy tính – đúng là thực thể như nó khẳng định. Chúng ta có thể xác nhận điều khẳng định này bằng cách sử dụng một thực thể được gọi là một ủy nhiệm cung cấp chứng nhận. Chứng nhận thường bao gồm tên người dùng (username) và mật khẩu. Một dịch vụ mạng chạy trên IIS có một số các giao thức thẩm định quyền cho nó, đáng chú ý nhất trong số đó là: Thẩm định người dùng vô danh. Thẩm định cơ sở. Thẩm định cốt yếu. Thẩm định Windows. Thẩm định dựa trên chứng thực. Thẩm định dựa trên form. Thẩm định .NET Passport. Quyền hạn của các dịch vụ mạng: Khi ứng dụng xác định một ủy nhiệm bằng cách sử dụng một cơ chế thẩm định quyền, nó cần xác định xem người dùng có truy cập tới các tài nguyên được bảo vệ hay không và có thể gọi các hàm cụ thể, trong đó đáng chú ý nhất là sự sử dụng các danh sách điều khiển truy cập. Một danh sách điều khiển truy cập gồm nhiều điểm vào kiểm soát truy cập (ACE – Access Control Entries). Mỗi điểm vào kiểm soát truy cập liệt kê một ủy nhiệm và chứa các thông tin về ủy nhiệm và các thao tác có thể thực hiện trên tài nguyên. Ví dụ, một vài người được trao quyền đọc và một số khác có thể có toàn quyền. Điểm mạnh thật sự của các danh sách điều khiển truy cập là ở chỗ chúng luôn luôn được tuân theo theo cùng một cách thức, không quan tâm tới cơ chế truy cập.Vì vậy, nếu vì một vài lý do nào đó mà một kẻ tấn công có thể qua được dịch vụ và do đó phá hỏng logic quyền hạn ở mức ứng dụng và truy cập tài nguyên một cách trực tiếp thì chính sách quyền hạn trong các danh sách điều khiển truy cập của tài nguyên vẫn còn có hiệu lực. 5.3. Tính liên thông giữa các dịch vụ mạng Khi dịch vụ mạng được sử dụng rộng rãi, các nhà cung cấp lại cố gắng thêm nhiều tính năng và nhiều chuẩn vào framework của mình để việc truyền thông giữa các hệ thống phong phú và mạnh hơn. Vì WSDL là một ngôn ngữ mà máy có thể hiểu được (file XML), các công cụ và hạ tầng quanh nó có thể được xây dựng một cách dễ dàng. Ngày nay, các nhà phát triển có thể sử dụng các định nghĩa WSDL để sinh mã có khả năng biết cách tương tác một cách chính xác với dịch vụ mạng mà nó mô tả. Loại sinh mã này che giấu những chi tiết nhàm chán không cần thiết trong việc gửi và nhận các thông điệp SOAP qua nhiều giao thức khác nhau và làm cho các dịch vụ mạng có thể được tiếp cận dễ dàng. Microsoft .NET Framework có tiện ích dòng lệnh wsdl.exe cho phép sinh các lớp từ các định nghĩa WSDL. Wsdl.exe có thể sinh ra mọt lớp dành cho việc sử dụng dịch vụ và lớp khác dành cho việc cài đặt dịch vụ. Apache Axis cũng có một tiện ích tương tự là WSDL2Java thực hiện chức năng tương tự cho các lớp Java. Các lớp được sinh ra từ cùng một định nghĩa WSDL có khả năng tương tác với nhau thông qua giao diện WSDL được cung cấp, không bị gắn chặt với ngôn ngữ lập trình dùng để viết ra chúng. Hình 2.8: WSDL và việc sinh mã 6. Kết luận chương Công nghệ dịch vụ mạng khá thích hợp để cài đặt một kiến trúc hướng dịch vụ. Về bản chất, các dịch vụ mạng có khả năng tự mô tả và là các ứng dụng có tính mô đun có thể thể hiện logic nghiệp vụ như các dịch vụ được xuất bản, tìm kiếm và thực thi qua Internet. Dựa trên chuẩn XML, dịch vụ mạng có thể được phát triển như các thành phần ứng dụng gắn kết không chặt chẽ với nhau, không quan tâm tới bất kỳ ngôn ngữ lập trình, giao thức hay nền tảng nào. Điều này làm các ứng dụng nghiệp vụ được xây dựng thành dịch vụ được có thể được truy cập bởi bất kỳ ai, vào bất kỳ thời điểm nào, tại bất kỳ vị trí nào và sử dụng bất kỳ nền tảng nào. Trong chương sau, NVĐA sẽ trình bày việc xây dựng chương trình tra cứu từ điển đa ngôn ngữ để minh họa cho những lý thuyết đã được đề cập ở chương I và chương II. Chương III: CÀI ĐẶT ỨNG DỤNG Sau khi lý thuyết kiến trúc hướng dịch vụ và dịch vụ mạng được trình bày trong các chương trước, chương này sẽ xây dựng ứng dụng tra từ điển đa ngôn ngữ (Anh – Việt, Việt – Anh, Pháp – Việt, Việt - Pháp) từ các dịch vụ từ điển để minh họa cho các lý thuyết trên. Nội dung sẽ trình bày: Nhắc lại yêu cầu của một hệ thống theo kiến trúc hướng dịch vụ. Mô tả bài toán xây dựng từ điển. Cài đặt bài toán tra từ điển. Đánh giá về ứng dụng. 1. Nhắc lại các yêu cầu của một hệ thống xây dựng theo kiến trúc hướng dịch vụ Nhìn ở mức cao, kiến trúc hướng dịch vụ bao gồm 3 thành phần: thành phần cung cấp dịch vụ, thành phần sử dụng dịch vụ và thành phần đăng ký dịch vụ. Vai trò của thành phần cung cấp và thành phần sử dụng dịch vụ là khá rõ ràng, còn thành phần đăng ký dịch vụ là trung gian giữa các thành phần này. Hình 3.1: Mô hình kiến trúc hướng dịch vụ ở mức cao Thành phần cung cấp dịch vụ đăng ký với thành phần đăng ký dịch vụ và thành phần sử dụng dịch vụ truy vấn thành phần đăng ký dịch vụ để tìm thành phần cung cấp dịch vụ. Sử dụng thành phần đăng ký dịch vụ trong kiến trúc hướng dịch vụ đem lại các lợi ích sau: Các dịch vụ có thể thêm dần vào thành phần đăng ký dịch vụ. Phân tách thành phần sử dụng và thành phần cung cấp dịch vụ. Cho phép cập nhật “nóng” dịch vụ. Cung cấp dịch vụ tìm kiếm, tra cứu cho thành phần sử dụng. Cho phép thành phần sử dụng chọn lựa các thành phần cung cấp dịch vụ trong thời gian thực thi, không phải gắn cứng vào một nhà cung cấp cụ thể nào đó. Các lợi ích của việc xây dựng ứng dụng theo định hướng dịch vụ là khá rõ ràng. Để xây dựng được những ứng dụng như vậy thì các dịch vụ tạo thành phải có các tính chất sau: Các dịch vụ là có thể tìm kiếm được. Các dịch vụ có tính liên thông. Các dịch vụ không được gắn kết chặt chẽ với nhau. Các dịch vụ trong suốt về vị trí. Một dịch vụ là một đơn vị phần mềm gồm các hoạt động nghiệp vụ có tính tự chứa đựng và mức độ đóng gói cao (coarse-grained). Một dịch vụ cần có khả năng được phát hiện ra một cách công khai bằng cách sử dụng một nơi đăng ký dịch vụ nhằm cho phép các liên kết động tới dịch vụ. Một dịch vụ cần đảm bảo tính liên thông bằng cách hỗ trợ các giao thức truyền thông được chuẩn hóa và các định dạng dữ liệu rõ ràng. Việc xây dựng từ điển đa ngôn ngữ không phải là vấn đề mới, tuy nhiên, ở đây tôi sẽ thực hiện việc xây dựng từ điển theo định hướng dịch vụ và cài đặt bằng dịch vụ mạng. 2. Mô tả bài toán Bài toán cần xây dựng là một ứng dụng cho phép tra từ điển trực tuyến đa ngôn ngữ. Ứng dụng được xây dựng theo kiến trúc hướng dịch vụ nên có 3 thành phần sau: Thành phần cung cấp dịch vụ: Thành phần cung cấp dịch vụ là các dịch vụ mạng có phương thức có đầu vào là từ cần tra nghĩa và đầu ra là nghĩa của từ đó (có 4 dịch vụ mạng cung cấp các từ điển Anh – Việt, Việt – Anh, Pháp – Việt, Việt – Pháp). Thành phần sử dụng dịch vụ: Thành phần sử dụng dịch vụ là ứng dụng từ điển của người dùng. Ứng dụng này sẽ tìm kiếm và tích hợp 4 dịch vụ mạng được cung cấp ở trên để xây dựng nên ứng dụng, do đó, việc phát triển diễn ra rất nhanh chóng và đảm bảo do các dịch vụ trên đã được xây dựng và kiểm thử. Thành phần đăng ký dịch vụ: Dịch vụ UDDI được tích hợp trong các phiên bản Windows 2003 (trừ phiên bản Web Edition) cho phép đăng ký, cập nhật, tìm kiếm thông tin về các dịch vụ cũng như các thành phần cung cấp dịch vụ. Yêu cầu của bài toán đặt ra là tách biệt giữa thành phần cung cấp và thành phần cài đặt dịch vụ. Ứng dụng tra từ điển của người dùng sẽ chỉ cần biết giao diện của dịch vụ cung cấp từ điển mà không cần quan tâm tới cài đặt chi tiết cũng như vị trí của dịch vụ và các dịch vụ được sử dụng để tạo nên ứng dụng cũng độc lập với nhau (ứng dụng được tạo thành từ 4 dịch vụ từ điển khác nhau). Các biểu đồ trường hợp sử dụng của ứng bài toán ở mức cao: Hình 3.2: Biểu đồ trường hợp sử dụng của bài toán 3. Cài đặt bài toán 3.1. Thành phần cung cấp dịch vụ Các bước xây dựng thành phần cung cấp dịch vụ: Tạo đặc tả giao diện WSDL. Cài đặt dịch vụ theo đặc tả giao diện đã có. Kiểm thử dịch vụ. Triển khai (đăng ký) dịch vụ. Ta cũng có thể xây dựng dịch vụ trước rồi sau đó tạo ra đặc tả giao diện nhờ các công cụ (wsdl.exe, Java2WSDL …): Hình 3.3: Cài đặt dịch vụ mạng Tạo cài đặt dịch vụ: Dữ liệu cho dịch vụ từ điển được cung cấp bởi T.S Hồ Ngọc Đức tại địa chỉ: (Anh - Việt, Việt – Anh ) và (Pháp - Việt, Việt – Pháp ) Cấu trúc của dữ liệu từ điển tuân theo định dạng chuẩn được đưa ra tại như sau: File data: chứa thông tin theo định dạng sau: @từ_cần_tra *từ_loại định_nghĩa_1 = ví_dụ_1 + nghĩa_của_ví_dụ_1 định_nghĩa_2 = ví_dụ_2 + nghĩa_của_ví_dụ_2 !thành_ngữ_1 định_nghĩa_thành_ngữ_1 = ví_dụ_thành_ngữ_1 + nghĩa_của_ví_dụ_thành_ngữ_1 *từ_loại định_nghĩa_3 Ví dụ: @acceptance * danh từ - sự nhận, sự chấp nhận, sự chấp thuận - sự thừa nhận, sự công nhận - sự hoan nghênh, sự tán thưởng, sự tán thành; sự tin =his statement will not find acceptance+ lời tuyên bố của ông ta sẽ không được ai tin - (thương nghiệp) sự nhận thanh toán (hoá đơn); hoá đơn được nhận thanh toán =general acceptance+ sự nhận thanh toán không cần có điều kiện =qualified acceptance+ sự nhận thanh toán có điều kiện !acceptance of persons - sự thiên vị File index: chứa từ cần tra (HeadWord), địa chỉ của từ tính từ đầu file (tính theo byte) dưới dạng mã BASE64, độ dài của từ (tính theo byte) dưới dạng mã BASE64 Ví dụ: acceptable MkG DB Dịch vụ sẽ cung cấp 2 phương thức: string LookUp (string HeadWord): trả về xâu biểu diễn định nghĩa của từ đúng như trong file data. Ví dụ: LookUp(acquit) sẽ trả về xâu: @acquit * ngoại động từ - trả hết, trang trải (nợ nần) =to acquit one's debt trang trải hết nợ nần+ tha bổng, tha tội, tuyên bố trắng án =to be acquitted of one's crime+ được tha bổng - to acquit oneself of làm xong, làm trọn (nghĩa vụ, bổn phận...) =to acquit oneself of a promise+ làm trọn lời hứa =to acquit oneself of one's task+ làm trọn nhiệm vụ !to acquit oneself - làm bổn phận mình, làm trọn phận mình; xử sự =to acquit oneself ill+ làm không tốt phần mình, xử sự xấu string LookUpXML(string HeadWord): trả về xâu biểu diễn nghĩa của từ dưới dạng XML (để có thể định dạng bằng file CSS). Ví dụ: LookUpXML(acquit) sẽ trả về xâu: acquit ngoại động từ trả hết, trang trải (nợ nần) to acquit one's debt trang trải hết nợ nần tha bổng, tha tội, tuyên bố trắng án to be acquitted of one's crime được tha bổng to acquit oneself of làm xong, làm trọn (nghĩa vụ, bổn phận...) to acquit oneself of a promise làm trọn lời hứa to acquit oneself of one's task làm trọn nhiệm vụ to acquit oneself làm bổn phận mình, làm trọn phận mình; xử sự to acquit oneself ill làm không tốt phần mình, xử sự xấu Cài đặt dịch vụ sử dụng cấu trúc cây AVL là cấu trúc điển hình trong việc xây dựng ứng dụng từ điển. Cây AVL là một dạng của cây nhị phân, tuy nhiên, không giống như cây nhị phân, thời gian tìm kiếm xâu nhất của cây AVL là O(logn). Cấu trúc dữ liệu AVL đạt được thời gian tìm kiếm nhanh như vậy do nó giới hạn sự chênh lệch về chiều cao giữa các cây con của cùng một nút và nó thực hiện việc cân bằng lại nếu giới hạn này bị vi phạm. Dịch vụ từ điển được tạo thành từ các lớp sau: public class AvlNode: Cài đặt cấu trúc của mỗi nút trong cây avl public class AvlTree: Cài đặt cây avl. public class LoadDict: Tải từ điển vào cây avl và cài đặt phương thức tra cứu từ. public class BASE64Converter: Chuyển đổi giữa dạng số thập phân và mã BASE64. public class XMLGenerator: Sinh ra xâu có nội dung là một file XML từ xâu trả về khi tra cứu nghĩa của từ. Tạo đặc tả giao diện WSDL: Giả sử dịch vụ sau khi được tạo ra có địa chỉ như sau: Khi đó, ta có thể xem file đặc tả giao diện WSDL tại địa chỉ: Kiểm thử: VS .NET tự động cung cấp trang kiểm thử cho dịch vụ mạng được tạo ra. Trang này có giao diện như sau: Hình 3.4: Trang kiểm thử dịch vụ mạng Nhập từ vào ô HeadWord và ấn Invoke để xem kết quả Triển khai (đăng ký) dịch vụ: Sau khi dịch vụ được kiểm thử, có thể đăng ký với dịch vụ UDDI. Hình 3.5: Đăng ký dịch vụ với UDDI 3.2. Thành phần sử dụng dịch vụ. Thành phần cung cấp dịch vụ và thành phần sử dụng dịch vụ liên kết động với nhau, theo như mô hình liên kết động trong chương 2, phần 3. Hình 3.6: Mô hình liên kết dịch vụ mạng động Các bước xây dựng: Tìm đặc tả cài đặt dịch vụ Tạo và triển khai ủy nhiệm dịch vụ. Gọi dịch vụ. Tìm đặc tả cài đặt dịch vụ: Đặc tả về dịch vụ được tìm kiếm nhờ dịch vụ UDDI. Hình 3.7: Tìm kiếm trong UDDI Tạo và triển khai ủy nhiệm dịch vụ: Sau khi tìm được đặc tả giao diện phù hợp, bước tiếp theo sẽ là tạo ra ủy nhiệm dịch vụ nhờ công cụ wsdl.exe của .NET. Hình 3.8: Sử dụng công cụ wsdl.exe Gọi dịch vụ: Việc gọi dịch vụ được thực hiện thông qua ủy nhiệm dịch vụ, kết quả là tạo ra được ứng dụng tra từ điển từ các dịch vụ mạng mà không cần biết cài đặt chi tiết của dịch vụ. 3.3 Thành phần đăng ký dịch vụ. Hiện trên thế giới có 2 nơi đăng ký dịch vụ công cộng do Microsoft ( ) và IBM ( ) quản lý. Khi nhà cung cấp dịch vụ đăng ký hay cập nhật dịch vụ tại một trong 2 nơi đăng ký thì thông tin về dịch vụ sẽ được cập nhật tới nơi đăng ký còn lại trong vòng 24 giờ. Chỉ có trong Windows 2003 (trừ bản Web Edition), Microsoft mới cho phép tích hợp nơi đăng ký dịch vụ riêng để sử dụng trong các mạng nội bộ, đó là dịch vụ UDDI (UDDI Services – thành phần này không được cài mặc định). Dịch vụ UDDI cho phép xuất bản, cập nhật và tìm kiếm các dịch vụ cũng như các nhà cung cấp dịch vụ. Giao diện của dịch vụ UDDI như sau: Hình 3.9: Giao diện dịch vụ UDDI 4. Các kết quả đạt được Ứng dụng từ điển được xây dựng từ 4 dịch vụ từ điển khác nhau là Anh – Việt, Việt – Anh, Pháp – Việt, Việt – Pháp. Giao diện của chương trình: Hình 3.10: Giao diện của chương trình Thông tin chi tiết về dịch vụ đang được sử dụng: Hình 3.11: Thông tin chi tiết về dịch vụ Khi thông tin về dịch vụ thay đổi (chẳng hạn vị trí của dịch vụ thay đổi) thì ứng dụng sẽ thực hiện việc truy vấn UDDI để cập nhật thông tin về dịch vụ mà không cần phải dịch lại chương trình. Hình 3.12: Dịch vụ thay đổi Truy vấn UDDI thành công, ứng dụng lại hoạt động như bình thường. Hình 3.13: Truy vấn thay đổi dịch vụ thành công Thông tin thay đổi về dịch vụ được thấy rõ khi xem thông tin chi tiết về dịch vụ (để ý rằng điểm truy cập của dịch vụ đã thay đổi): Hình 3.14: Thông tin về dịch vụ thay đổi 5. Đánh giá về ứng dụng 5.1. Ưu điểm Ứng dụng được xây dựng theo định hướng dịch vụ, tức là gồm có 3 thành phần: thành phần cung cấp dịch vụ (các dịch vụ từ điển), thành phần sử dụng dịch vụ (ứng dụng tra từ được xây dựng từ các dịch vụ từ điển) và thành phần đăng ký dịch vụ (dịch vụ UDDI của Windows 2003), do vậy, nó đã tách được phần giao diện ra khỏi phần cài đặt. Hơn nữa, nó được xây dựng theo cơ chế liên kết dịch vụ động nên đảm bảo tính linh hoạt khi dịch vụ thay đổi. Ứng dụng có giao diện sử dụng thân thiện, đã thể hiện được các tính chất căn bản cần có của một ứng dụng xây dựng theo kiến trúc hướng dịch vụ: Các dịch vụ có giao diện rõ ràng: Giao diện của dịch vụ được công bố trong UDDI, mô tả mọi thông tin cần thiết về chức năng cũng như các tham số đầu vào, đầu ra, điểm truy cập của dịch vụ, tạo ra giao ước sử dụng dịch vụ giữa thành phần sử dụng và thành phần cung cấp dịch vụ. Một dịch vụ là một đơn vị phần mềm gồm các hoạt động nghiệp vụ có tính tự chứa đựng và mức độ đóng gói cao (coarse-grained): Các dịch vụ từ điển đều thực hiện được một chức năng hoàn chỉnh, đó là tra từ. Các dịch vụ độc lập có thể tích hợp lại với nhau trong cùng một ứng dụng để làm nên ứng dụng tổng thể (từ điển đa ngôn ngữ). Mỗi dịch vụ lại được cấu tạo từ nhiều lớp khác nhau: AvlNode, AvlTree, LoadDict, BASE64Converter, XMLGenerator. Một dịch vụ cần có khả năng được phát hiện ra một cách công khai bằng cách sử dụng một nơi đăng ký dịch vụ nhằm cho phép các liên kết động tới dịch vụ: Điều này được thực hiện thông qua việc sử dụng dịch vụ UDDI. Các dịch vụ có tính liên thông: Do việc sử dụng dịch vụ chỉ cần biết đặc tả giao diện của dịch vụ là file WSDL tuân theo định dạng XML mà bất kỳ nền tảng nào cũng có thể hiểu được và không quan tâm tới cài đặt cụ thể của dịch vụ, việc truyền thông lại dùng giao thức phổ biến là HTTP nên các dịch vụ mạng được xây dựng có thể hoạt động và tương tác trên mọi nền tảng. Các dịch vụ không được gắn kết chặt chẽ: Thành phần sử dụng và thành phần cung cấp dịch vụ không gắn kết trực tiếp với nhau mà thông qua thành phần đăng ký dịch vụ là UDDI, điều này đảm bảo cho tính mềm dẻo và linh hoạt của dịch vụ. Các dịch vụ trong suốt về vị trí: Sự thay đổi vị trí của dịch vụ không làm ảnh hưởng tới thành phần sử dụng dịch vụ, do các thay đổi của dịch vụ đều được phản ánh trong UDDI, thành phần sử dụng dịch vụ chỉ truy vấn thông qua UDDI mà không liên kết trực tiếp tới dịch vụ. 5.2. Các điểm hạn chế Ứng dụng mới chỉ cung cấp chức năng cơ bản là tra từ. Chưa quan tâm tới vấn đề bảo mật cho dịch vụ mạng. KẾT LUẬN Khi độ phức tạp phần mềm tăng lên, các nhà nghiên cứu luôn tìm ra nhiều cách mới để khắc phục. Kiến trúc hướng dịch vụ, cùng với công nghệ dịch vụ mạng là câu trả lời cuối cùng cho vấn đề này. Trong khuôn khổ đồ án tốt nghiệp này, NVĐA đã trình bày những khái niệm về kiến trúc hướng dịch vụ và công nghệ dịch vụ mạng, cũng như việc áp dụng công nghệ dịch vụ mạng để xây dựng ứng dụng theo định hướng dịch vụ. Đây là một đề tài rất thú vị, không chỉ bởi tính thời sự của nó, mà còn bởi tư duy mới trong xây dựng phần mềm của nó. Việc nghiên cứu đề tài về kỹ thuật hướng dịch vụ đã giúp tôi có cái nhìn mới về phát triển phần mềm, các vấn đề của các kỹ thuật phát triển phần mềm hiện tại. Các kết quả đạt được: Nắm được bản chất của các mô hình phát triển phần mềm và sự tiến hóa của chúng. Nghiên cứu các bản chất, các yêu cầu và các thành phần của kiến trúc hướng dịch vụ. Hiểu được các lợi ích khi phát triển phần mềm theo kiến trúc hướng dịch vụ. Tìm hiểu về công nghệ dịch vụ mạng, tính liên thông giữa các dịch vụ mạng và các chuẩn cho phép thực hiện công nghệ dịch vụ mạng. Áp dụng thành công công nghệ dịch vụ mạng để xây dựng ứng dụng tra từ điển theo kiến trúc hướng dịch vụ. Các hạn chế: Do trình độ chuyên môn và thời gian hạn hẹp nên đồ án không tránh khỏi có nhiều thiếu sót: Chưa tìm hiểu sâu được về vấn đề bảo mật cho kiến trúc hướng dịch vụ. Chưa thử nghiệm được nhiều về tính liên thông giữa các dịch vụ. Chưa thật sự hoàn thiện chương trình ứng dụng. Chưa triển khai ứng dụng trên mạng Internet. Hướng phát triển tiếp theo của đề tài: Tìm hiểu các công nghệ khác áp dụng cho việc cài đặt kiến trúc hướng dịch vụ. Hoàn thiện giao diện và chức năng cho ứng dụng. Phát triển cơ chế bảo mật cho các dịch vụ. Việc nghiên cứu đề tài đã giúp tôi nắm được xu thế mới trong phát triển phần mềm - phát triển hướng dịch vụ, để từ đó áp dụng những lợi điểm của kỹ thuật phát triển này vào các sản phẩm trong tương lai của mình, cũng như khả năng tiếp cận và nắm bắt các công nghệ, công cụ mới hỗ trợ cho việc phát triển phần mềm theo kiến trúc hướng dịch vụ. Cuối cùng, một lần nữa tôi xin chân thành cảm ơn TS. Huỳnh Quyết Thắng, người đã định hướng cho tôi hướng nghiên cứu về đề tài này và là người hướng dẫn, giúp đỡ tôi rất nhiều trong quá trình thực hiện đề tài. Tôi cũng xin cảm ơn gia đình và bạn bè đã tạo điều kiện và giúp đỡ tôi trong suốt quá trình học tập cũng như thực hiện đề tài này. Danh mục tài liệu tham khảo [1]. Mark Endrei & others, Patterns: Service-Oriented Architecture and Web Services, IBM Press , 2004 [2]. Scott Short, Building XML Web Services for the Microsoft .NET Platform, Microsoft Press, 2002 [3]. David S. Linthicum, 12 Steps to implementing a Service-Oriented Architecture, 2004 [4]. Micheal S. Mimoso, A defining moment for SOA, 2004 [5]. Bernhard Borges & others, Delving into Service-Oriented Architecture and Web Services, [6]. Don Box, Four tenets to keep in mind when considering service orientation, 2004 [7]. Connecticut Object-Oriented User Group, Service-Oriented Architecture, 2003 [8]. Brent Carlson & Dmitry Tyomkin, Service-Oriented Architecture: Elements of good design, Business Integration, 2004 [9]. Sayed Hashimi, Service-Oriented Architecture Explained, 2003 [10]. Friedemann Lindermann, Service-Oriented Requirements Engineering and Verification, UTHH, 2004 [11]. Google, [12]. Vietnam Dictionary, ._.