Góc học tập
15/02/2017 11:04:56 AM

Tổng quan về kiến trúc hướng dịch SOA

Mọi việc nên thực hiện theo cách đơn giản đến mức có thể …” – Albert Einstein, đây cũng chính là vấn đề đặt ra hiện nay trong lĩnh vực phát triển phần mềm. Một thực trạng đáng buồn là có rất nhiều hệ thống phần mềm được thực hiện quá phức tạp, chi phí phát triển và bảo trì cao chót vót, đặc biệt với các hệ thống phần mềm cao cấp. Hàng chục năm qua, các kiến trúc phần mềm đã cố gắng giải quyết vấn đề này. Thế nhưng độ phức tạp vẫn tiếp tục tăng và dường như vấn đề này đã vượt quá khả năng xử lý của các kiến trúc truyền thống. Điều này một phần do ngày càng xuất hiện nhiều công nghệ mới tạo nên môi trường không đồng nhất, một phần do yêu cầu trao đổi tương tác giữa các hệ thống phần mềm với nhau. Những yêu cầu truyền thống đặt ra đối với tổ chức CNTT vẫn còn đó, cùng lúc phải đáp ứng nhanh chóng các yêu cầu mới, đòi hỏi phải liên tục giảm chi phí, có khả năng sử dụng và tích hợp các thành phần mới… Tất cả đã tạo nên một áp lực nặng nề đối với các nhà phát triển phần mềm.

Chúng ta đã có các kiến trúc như OOP (Object Oriented Programming), COM/DCOM (Distributed Common Object Model), CORBA (Common Object Request Broker Architecture)… và nhiều phương thức tích hợp ứng dụng nhanh và tốt hơn. Thế nhưng vẫn chưa có giải pháp nào hoàn chỉnh. Giờ đây, SOA đang được xem là ‘ứng cử viên sáng giá’ có thể đảm nhận trọng trách này và được kỳ vọng tạo nên cuộc cách mạng trong kiến trúc phần mềm.

SOA là gì?

SOA – Service Oriented Architecture (Kiến trúc Định hướng Dịch vụ), theo định nghĩa của DotNetGuru, là “Khái niệm về hệ thống trong đó mỗi ứng dụng được xem như một nguồn cung cấp dịch vụ”.

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 qui trình nghiệp vụ nào đó. 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ó thể ‘nói chuyện’ với một ứng dụng khác mà không cần biết các chi tiết kỹ thuật bên trong), có giao tiếp (dùng để gọi hàm dịch vụ) được định nghĩa rõ ràng và độc lập với nền tảng hệ thống, và có thể tái sử dụng. SOA là cấp độ cao hơn của phát triển ứng dụng, chú trọng đến qui trình nghiệp vụ và dùng giao tiếp chuẩn để giúp che đi sự phức tạp kỹ thuật bên dưới.

Thiết kế SOA tách riêng phần thực hiện dịch vụ (phần mềm) với giao tiếp gọi dịch vụ. Điều này tạo nên một giao tiếp nhất quán cho ứng dụng khách (client) sử dụng dịch vụ bất chấp 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 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 client 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 đạt đượ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” (nhờ sự chuẩn hóa giao tiếp) và tái sử dụng. Các dịch vụ có thể được sử dụng với trình client chạy 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ụ viết trên nền .NET và ngược lại).

SOA dựa trên 2 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 đi dữ liệu và lô-gic trong từng mô-dun (hay ‘hộp đen’) đối với truy cập từ ngoài.

SOA và OOP: Không loại trừ nhau

Có ý kiến cho rằng SOA (Service-Oriented – định hướng dịch vụ) sẽ thay thế phương thức lập trình hướng đối tượng – OOP (Object Oriented Programming). Ít nhất thì đây là thông điệp của Don Box, phụ trách bộ phận thiết kế Indigo – công nghệ tích hợp trong hệ điều hành Windows Longhorn (phiên bản hệ điều hành Windows thế hệ kế tiếp) mà theo Microsoft sẽ hỗ trợ hoàn toàn SOA. Thực sự đây chỉ là tuyên bố mang tính “giật gân”, gần giống như tuyên bố AOP thay thế OOP (tham khảo “AOP=Aspect Oriented Programming”, TGVT A số 01/2003 – trang 60).

SOA sử dụng cùng một số nguyên lý như OOP, tuy nhiên triết lý SOA có khác biệt đáng kể so với OOP. SOA có thể thực hiện với cả chương trình theo hướng đối tượng (OO) và chương trình không hướng đối tượng.

Chúng ta có thể thấy sự ràng buộc giữa lớp thể hiện và các đối tượng của lớp nghiệp vụ. Chương trình client phải tương tác với mô hình đối tượng của lớp nghiệp vụ, điều này làm tăng sự ràng buộc và yêu cầu số lượng đáng kể các “gọi hàm” giữa các 2 lớp. Khi các đối tượng nghiệp vụ nằm ở máy tính xa thì đây sẽ là vấn đề. Tương tự, số lượng đối tượng nghiệp vụ mà lớp thể hiện phải thao tác làm giảm sự độc lập giữa các lớp và làm cho khó sử dụng lớp nghiệp vụ.

Ví dụ, xét đoạn mã sau:

Trích dẫn:

Nguyên văn bởi Mã

Customers customers = Customer.List();

Orders orders = customers[0].Orders;

Order order = orders.Add(‘ORDER001′, customerData.Customers[0]);

Order.Lines.Add(new Product(’53XYPR0D8’, 2);

Orders.Save(); // Nếu việc cập nhật không được thực hiện theo thời gian thực.

Chương trình làm việc với các đối tượng nghiệp vụ Customer, Order và Product. Ở đây sử dụng đối tượng Order để thực hiện việc cập nhật. Trong một số mô hình, việc cập nhật được thực hiện trực tiếp ngay trong từng lời gọi đến đối tượng nghiệp vụ. Những lời gọi đến máy chủ được tô đậm.

Khác biệt giữa SOA và mô hình đối tượng chính là lớp mới ‘Services’. Lớp thể hiện giờ đây không còn thao tác trực tiếp lên các đối tượng nghiệp vụ nữa, mà sử dụng dịch vụ để truy cập chúng. Các đối tượng nghiệp vụ được đặt trong thư viện và được dịch vụ nạp vào bộ nhớ – lớp dịch vụ và lớp nghiệp vụ nằm trong cùng tiến trình, nhờ vậy lời gọi hàm đến đối tượng nghiệp vụ sẽ không hề bị quá tải.

Dịch vụ đóng vai trò như ‘hộp đen’: cung cấp một lớp trung gian cho mô hình đối tượng và đưa ra tập chức năng rút gọn, làm giảm nhu cầu trao đổi giữa các lớp.

Đoạn mã ví dụ trên được thực hiện theo kiến trúc SOA như sau:

Trích dẫn:

Nguyên văn bởi Mã

CustomerData customerData = CustomerService.ListCustomers();

OrderData orderData = new OrderData();

OrderEntity order = orderData.Orderss.Add(‘ORDER001′, customerData.Customers[0].CustomerID);

Order.Lines.Add(’53XYPR0D8’, 2);

CustomerService.AddOrders(orderData);

CustomerService làm việc với các đối tượng dữ liệu CustomersData và OrderData. Trình client chuẩn bị các đối tượng dữ liệu và gửi chúng đi trong 1 lời gọi. Giờ đây nó tùy thuộc vào dịch vụ thực hiện cập nhật. Phương thức này thực hiện nhóm dữ liệu lại với nhau và làm giảm số lượng lời gọi đến server.

SOA và WebService (dịch vụ Web): Không phải là một

Đặc điểm chính của SOA là tách rời phần giao tiếp/gọi dịch vụ với phần thực hiện dịch vụ. Điều này có thể làm bạn liên tưởng đến một công nghệ được đề cập nhiều gần đây: WebService (dịch vụ web). Dịch vụ web cho phép truy cập thông qua định nghĩa giao thức-và-giao tiếp. SOA và dịch vụ web thoạt trông có vẻ giống nhau nhưng chúng không phải là một.

Về cơ bản, SOA là kiến trúc phần mềm phát xuất từ định nghĩa giao tiếp và xây dựng toàn bộ mô hình ứng dụng như là mô hình các giao tiếp, hiện thực giao tiếp và phương thức gọi giao tiếp. Giao tiếp là trung tâm của toàn bộ triết lý kiến trúc này; thực ra, tên gọi “kiến trúc định hướng giao tiếp” thích hợp hơn cho SOA. Dịch vụ và module phần mềm nghiệp vụ được truy cập thông qua giao tiếp, thường theo cách thức yêu cầu – đáp trả. Ngay cả với yêu cầu dịch vụ 1 chiều thì nó vẫn là yêu cầu trực tiếp có chủ đích từ một phần mềm này đến một phần mềm khác. Một tương tác định hướng dịch vụ luôn bao hàm một cặp đối tác: nguồn cung cấp dịch vụ và khách hàng sử dụng dịch vụ.

Định nghĩa cơ bản của dịch vụ web dựa trên một nền tảng khác: Tập hợp các công nghệ WSDL (Web Services Description Language), SOAP (Simple Object Access Protocol) và UDDI (Universal Description, Discovery ang Integration), cho phép xây dựng các giải pháp lập trình cho vấn đề tích hợp ứng dụng và truyền thông điệp. Theo thời gian, các công nghệ này có thể hoàn thiện hay có thể được thay bằng công nghệ khác tốt hơn, hiệu quả hơn hay ổn định hơn. (Hiện tại thì các công nghệ này làm việc tốt và hiệu quả).

Rõ ràng, theo định nghĩa thì dịch vụ web là đặc tả công nghệ còn SOA là triết lý thiết kế phần mềm. Dịch vụ web đưa ra giải pháp kỹ thuật để thực hiện SOA, nhưng SOA cũng có thể thực hiện với các giải pháp kỹ thuật khác không phải dịch vụ web (và không phải tất cả dịch vụ web đều có kiến trúc SOA). Tuy vậy, SOA và dịch vụ web có mối quan hệ tương hỗ: sự phổ biến của dịch vụ web giúp thúc đẩy sự phát triển của SOA, và kiến trúc tốt của SOA sẽ giúp dịch vụ web thành công.

Tương lai cho SOA

Tháng 5 năm 2006, BEA đưa ra sáng kiến Liquid Computing hỗ trợ dịch vụ web và SOA. Cũng trong tháng 5, IBM đã khai trương 4 trung tâm nghiên cứu và triển khai SOA tại Austin (Mỹ), Beijing (Trung Quốc), Delhi (Ấn độ) và Hursley (Anh). Các trung tâm này sẽ hỗ trợ cho công việc của IBM Global Services SOA Centers of Excellence. Như đã đề cập ở phần trên, phiên bản HĐH Windows thế hệ kế tiếp, tên mã Longhorn, sẽ hỗ trợ đầy đủ SOA với công nghệ tích hợp Indigo. Và SOA còn được sự ủng hộ của nhiều hãng tên tuổi khác như Sun, Oracle … Theo Gartner, trong khoảng 2 năm nữa, SOA sẽ hiện diện trong hầu hết các dự án phần mềm.

SOA sẽ giúp cho công việc phát triển phần mềm trở nên dễ dàng và nhanh chóng hơn. ‘Đừng tốn công chế tạo lại bánh xe’, hãy kết hợp những linh kiện (dịch vụ) có sẵn và bổ sung những gì cần thiết để ‘lắp ráp’ nhanh chóng ‘chiếc xe’ đưa bạn đến đích. Đó là triết lý của SOA! Ngay từ bây giờ bạn có thể áp dụng triết lý này cho các hệ thống phần mềm của mình để sẵn sàng cho những nhu cầu của ngày mai.

» Các tin khác: