• Thứ Bảy, 19/03/2011 17:30 (GMT+7)

    Bí mật SOA: Làm thế nào có được giá trị thực?

    NND
    Những vấn đề về sử dụng đúng đắn kiến trúc hướng dịch vụ (Service Oriented Architecture – SOA) vẫn được để ngỏ. Tính mục tiêu và sự hợp thời của việc ứng dụng SOA vẫn là đề tài nóng hổi...

    Bí mật SOA: Làm thế nào có được giá trị thực? (Phần 1) 

    Gần đây, nhiều công ty đã nghiêm túc nghiên cứu, đầu tư không ít tiền của, sức lực vào SOA. SOA đang trở thành cách tiếp cận ngày càng phổ biến trong việc xây dựng mới hệ thống thông tin doanh nghiệp. SOA ngày càng dễ hiểu với tầng lớp lãnh đạo và việc phát triển nó không còn phức tạp với dân lập trình. Tuy nhiên, không phải mọi thứ đều đơn giản như vậy. Vấn đề sử dụng đúng SOA vẫn còn để ngỏ. Đề tài về tính hữu ích và hợp thời của việc ứng dụng SOA vẫn còn nóng hổi...

    Như với nhiều khái niệm CNTT khác, SOA chưa có định nghĩa nào được đông đảo thừa nhận. Có hàng loạt phương án định nghĩa ít nhiều phù hợp, hướng đến các khía cạnh công nghệ hoặc khái quát hóa từ đó. Nhưng tất cả chúng đều không trả lời câu hỏi làm thế nào SOA giúp đạt được những kết quả rõ rệt như mô tả, và SOA khác với ‘không SOA’ như thế nào. Hãy cùng tìm hiểu những vấn đề này.

    Tổ chức và sử dụng các nguồn lực

    Mọi định nghĩa về SOA đều gặp nhau ở chỗ những hệ thống thông tin mới cần được xây dựng như tập hợp của các dịch vụ phân bổ trên một mạng máy tính thống nhất, và tương tác với nhau theo các chuẩn. Dịch vụ là những tài nguyên phần mềm và phần cứng tương đối độc lập nào đó, có thể được truy vấn để xử lý thông tin. Chúng thường được gọi là dịch vụ web (web service), nhưng khái niệm này không có nghĩa là giao thức HTTP đóng vai trò đặc biệt, độc đáo và duy nhất nào đó và chỉ có sử dụng nó thì các dịch vụ web mới được coi là dịch vụ web.

    Bởi vậy, hiểu theo nghĩa rộng, dịch vụ web là các dịch vụ có thể hoạt động trong môi trường SOA. Nhưng trong trường hợp này lại phải trả lời câu hỏi: Các hệ thống thông tin hiện đại không phải là các hệ thống được xây dựng trên nguyên lý dịch vụ? Về tổng quát, cách tiếp cận dịch vụ đã được biết đến từ thời Internet hình thành. Tổ chức dạng mô-đun của một hệ thống thông tin thường được coi là một "giá trị vĩnh cửu". Vậy gần đây, có gì mới cho phép định nghĩa SOA như một mô hình tổ chức mới và sử dụng các nguồn lực thông tin phân tán?

    SOA nên giúp chúng ta sống trong sự thay đổi.
    Tất nhiên, đó là những chuẩn mới. Đầu tiên, đó là chồng giao thức tương tác dịch vụ, với giao thức chính là SOAP (Simple Object Access Protocol - Giao thức truy cập đối tượng đơn giản). Nó dựa trên chuẩn XML cho các ngôn ngữ mô tả dịch vụ Web (Web Services Description Language - WSDL). Cơ chế tìm kiếm của chúng là UDDI (Universal Description, Discovery and Integration - Mô tả, khám phá và tích hợp toàn thể)… Nói chung, XML đã làm được rất nhiều cho việc phát triển các dịch vụ web. Lần đầu tiên cơ sở công nghệ cho sự tương tác dịch vụ đã xuất hiện, không liên quan đến một nhà sản xuất phần mềm nào, không liên quan đến một ngôn ngữ lập trình hay công nghệ “của riêng” nào khác. Nhưng công nghệ không phải là một đặc tính xác định SOA. Thứ nhất, có các chuẩn thay thế. Thứ hai, tự thân việc ứng dụng các công nghệ không làm nên SOA và không mang lại cho hệ thống thông tin một chất lượng mới. Vậy thì các tiêu chí nằm ở đâu?

    Siêu nhiệm vụ kinh tế của SOA

    Chúng ta muốn gì từ SOA? Hiển nhiên, chúng ta muốn khắc phục “lời nguyền lập trình”. Chúng ta lập trình mọi thứ và cuối cùng sẽ đạt tới mức độ phức tạp tối đa của hệ thống – mức độ mà ngân sách và các nguồn lực cần thiết để tiếp tục công việc trở nên không thể chấp nhận. Hoặc khi chúng ta mua phần mềm đóng gói nhưng nó không đáp ứng các nhu cầu đặc thù của chúng ta và việc sửa sang nó lại là không hiện thực hoặc sẽ không kịp cho mục đích kinh doanh. Và trên thực tế, trong một số trường hợp, hệ thống thông tin rệu rã, không còn khả năng thay đổi và đáp ứng kinh doanh, không còn khả năng tích luỹ kinh nghiệm trong cấu trúc của mình…

    Thế giới lý tưởng mới của hệ thống thông tin nên như sau:

    • Cấu tạo từ các mô-đun dịch vụ
    • Hạ tầng cần để thực hiện các dịch vụ phải đủ đơn giản và có thể mua từ các nhà cung cấp khác nhau
    • Việc thay thế một dịch vụ không đòi hỏi thay thế lập tức những dịch vụ khác
    • Các dịch vụ có giá gia công xử lý không cao
    • Sự biến mất khỏi thị trường vài nhà phát triển dịch vụ không kéo theo những hậu quả nghiêm trọng cho hệ thống thông tin
    • Hệ thống liên tục "sống", các dịch vụ mới "đấu nối" vào, các dịch vụ cũ được thay đổi, nâng cấp
    • Hệ thống thông tin có thể thay đổi thường xuyên với một ngân sách phù hợp.

    Chính tiêu chí cuối cùng diễn đạt một cách cô đọng siêu nhiệm vụ kinh tế của SOA – phải làm sao với một nguồn ngân sách không lớn, hệ thống thông tin vẫn có thể từng bước phát triển. Không thể để xảy ra tình huống, chỉ thay đổi gì đó trong hệ thống thông tin mà phải dỡ bỏ hệ thống để thiết lập lại từ đầu. Những khoản đầu tư và hệ thống thông tin không được giảm giá trị quá nhanh. Với các hệ thống thông tin lớn, đây nói chung là phương pháp phát triển duy nhất có thể. SOA cần giúp chúng ta sống trong các điều kiện thay đổi.

    Các dịch vụ phải thế nào?

    Khi đã làm rõ chúng ta muốn gì ở SOA về phương diện kinh tế, thì câu chuyện “vì sao ứng dụng giao diện đặc thù với SOA (cũng như SOAP) giữa các thành phần của hệ thống thông tin không giải quyết được vấn đề của chúng ta” trở nên rõ ràng. Cần có thêm điều gì đó. Nhưng là gì? Các dự án phải như thế nào để có thể liên kết với hệ thống và mang lại cho hệ thống một chất lượng mới? Hãy thử đưa ra cho các nhà phát triển các lời khuyên thực tế và chứng minh một số điều quan trọng.

    Độ chi tiết

    Chúng ta đã đề cập ở trên về chuyện các dịch vụ phải đủ “nhẹ” và rẻ. Thực tiễn sản xuất phần mềm cho thấy, các nhóm lập trình viên từ 5 – 10 người làm việc với dự án kéo dài từ 3 – 6 tháng là có hiệu quả nhất. Các dịch vụ cần được thảo ra, và nếu cần thiết, cần soạn lại trong khuôn khổ nguồn lực như vậy. Việc phát triển toàn bộ hay một phần hệ thống thông tin như một dịch vụ với số lượng giao diện lớn trong thời gian một vài năm bởi một công ty từ 50 – 100 người có khả năng sẽ không đạt yêu cầu SOA ngay cả nếu mọi đòi hỏi công nghệ đã được tuân thủ. Các chức năng lớn cần được tách ra thành một loạt dịch vụ, giao diện giữa chúng sẽ được mô tả công khai. Giao diện này không thể là vấn đề nội bộ của công ty phát triển. Và quan trọng không hẳn là nó có phù hợp với các chuẩn mực SOA hay không, mà là có được điều đó một cách công khai. Khi cần, sự thay đổi và nâng cấp hệ thống cần phải được đảm bảo ở tầng dịch vụ ngay cả khi thiếu vắng nhà phát triển bộ mã ban đầu.

    Đóng gói

    Cái gì cản trở kiến trúc sư SOA cắt nhỏ dịch vụ hơn nữa như mô tả ở đoạn trước? Có lẽ là do một nguyên tắc: Để thực hiện các hành vi như nhau, bạn cố gắng dùng cùng một mã (code). Nếu xem phần text của các chương trình này, sẽ thấy nguyên tắc này thể hiện đến cực đoan, và phần lớn các phương pháp bao gồm từ 2 - 3 dòng code. Phương pháp luận này khó có thể được thừa nhận là thành công.

    Giấu sự phức tạp của việc triển khai dịch vụ bên trong nó và không để những chi tiết này ám ảnh người dùng là công việc quan trọng không chỉ với lập trình hướng đối tượng mà cả với SOA. Để hiệu quả của việc đóng gói là tối đa, dịch vụ dù sao cũng phải đủ lớn. Nếu không, sự phức tạp về logic của hệ thống sẽ bị loại khỏi mức độ tương tác dịch vụ.

    Gắn kết

    Vậy là, dịch vụ không được quá lớn và không được quá nhỏ. Tính phức tạp logic của chức năng hệ thống thông tin phải được chia tách hợp lý ở tầm mức nội bộ dịch vụ - nơi mà hệ thống được đóng gói; và ở tầm mức giữa các dịch vụ - nơi nó phải được công khai; và các giao diện phải được mô tả chính thức. Khi thực hiện những đòi hỏi này, cần chia cắt các dịch vụ sao cho tính gắn kết của chúng là tối thiểu. Trong trường hợp này, chúng ta đơn giản hoá mức độ tương tác giữa các dịch vụ mà không phải hy sinh độ chi tiết tối ưu của các dịch vụ. Việc tối thiểu hoá độ gắn kết các bộ phận không phải là nguyên lý mới trong xây dựng kiến trúc phần mềm. Khi thiết kế SOA, phải duy trì các nguyên lý lập trình cơ bản mà không tuân thủ bất cứ nguyên lý nào một cách tuyệt đối.

    SOA hiện thời đặt ra nhiều câu hỏi hơn là cho câu trả lời.
    Hệ thống phân cấp

    Bây giờ, ta cùng hình dung tình huống mức độ chi tiết khuyến cáo được duy trì, nhưng số lượng dịch vụ tương tác vẫn lớn và nảy sinh những khó khăn trong sự tương tác dịch vụ. Ví dụ, các giao diện dịch vụ có ngữ nghĩa tương tự nhưng không thật giống nhau. Trong trường hợp này, chúng ta có thể chuyển một phần chức năng sang cơ sở hạ tầng tương tác dịch vụ, ví dụ, sang Service Bus hay là hệ thống trao đổi tin nhắn Messaging System. Những khả năng hỗ trợ từ phía hạ tầng sẽ đủ nhanh còn độ phức tạp của hệ thống cũng sẽ được khắc phục.

    Giả sử, ngay từ đầu, ta cần đặt ra bài toán tổ chức dịch vụ trong hệ thống phân cấp. Cấu trúc phẳng của dịch vụ chưa chắc đứng vững trước thử thách của hệ thống thông tin phức tạp. Cần có các dịch vụ có khả năng tổng hợp và đóng gói các dịch vụ khác. Khi có các dịch vụ như thế, sẽ có khả năng tổ chức hệ thống thông tin như hệ thống phân cấp dịch vụ nhiều mức mà vẫn giữ được sự đơn giản và rõ ràng của tương tác dịch vụ trên từng mức một. Dịch vụ tổng hợp không thể cung cấp đầy đủ các dịch vụ có khả năng cung cấp các tập hợp dịch vụ riêng biệt, nhưng điều này là không cần thiết. Dịch vụ tổng hợp cần giấu sự phức tạp về logic ở mức dưới.

    Xem tiếp : 12>