Lý thuyết kiến trúc hướng dịch vụ

MỤC LỤC KẾT LUẬN..........................................................................................83 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). 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ụ Web (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ụ Web 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 luận văn (NVLV) 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ụ Web, 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ụ Web 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ụ. DANH MỤC CÁC TỪ VIẾT TẮT DANH MỤC CÁC HÌNH VẼ Hình 1.1: Sự phát triển của các công ty 6 Hình 1.2: Sự phát triển của kiến trúc 6 Hình 1.3: Phát triển phần mềm theo mô đun 7 Hình 1.4: Phát triển phần mềm hướng đối tượng 8 Hình 1.5: Phát triển phần mềm hướng thành phần 8 Hình 1.6: Phát triển phần mềm hướng dịch vụ 9 Hình 1.7: Kiến trúc phần mềm theo định nghĩa cổ điển 10 Hình 1.8: Mô hình kiến trúc hướng dịch vụ 11 Hình 1.9: Ủy nhiệm dịch vụ 17 Hình 1.10: Thành phần 19 Hình 1.11: Dịch vụ 19 Hình 1.12: Mối quan hệ giữa thành phần và dịch vụ 19 Hình 1.13: Mô hình thành phần đơn đặt mua hàng 20 Hình 1.14: Các tầng cài đặt trong thiết kế: đối tượng dịch vụ, thành phần 23 Hình 1.15:Các tầng của SOA 25 Hình 1.16: Các mức độ thực hiện kiến trúc hướng dịch vụ 26 Hình 1.17: Một quy trình phát triển hướng dịch vụ 31 Hình 1.18: Mô hình kiến trúc Jini 36 Hình 1.19: Mô hình khung của Openwings 38 Hình 1.20: Mô hình ESB 40 Hình 2.1: Mô hình dịch vụ Web 44 Hình 2.2: Cấu trúc thông điệp SOAP 50 Hình 2.3: Các kiểu dữ liệu chính trong UDDI 54 Hình 2.4: Liên kết tĩnh 58 Hình 2.5: Liên kết động thời gian xây dựng 59 Hình 2.6: Liên kết động thời gian chạy 60 Hình 2.7: Một ví dụ dịch vụ Web 64 Hình 2.8: WSDL và việc sinh mã 68 CHƯƠNG I. LÝ THUYẾT KIẾN TRÚC HƯỚNG DỊCH VỤ 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 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 thẳng 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 dưới đây. 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 vớ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 có một dịch vụ khác có chất lượng tốt hơn tồn tại. 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ề SOA cũng như bản chất những khái niệm tạo nên SOA, chúng ta cần phải hiểu về lịch sử phát triển của SOA 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, giai đoạn 1960 - 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. Những 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ụ Web 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, 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ầ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ã bằng các phương pháp như kế thừa, kết tập, 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 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. 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. “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 Web Service có khả năng tái sử dụng. Trong khi Web Service 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 linh hoạt 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à “client” và “server” 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 trong 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 với các ứng dụng 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ự linh hoạt 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ụ. Thật ra, 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 quan trọng 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ụ web .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ừ 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ị