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

Sự phụ thuộc vào cơ sở hạ tầng

Nói trong SOA chỉ có các dịch vụ tương tác và không còn gì khác nghe thật hấp dẫn. Mô hình như thế có thể về mặt lý thuyết. Nhưng chúng ta đã nói tới Service Bus như đối tượng hạ tầng, tự thân nó không phải là dịch vụ. Hệ thống trao đổi tin nhắn Messaging System có thể được hình thành như dịch vụ và như một phần của hạ tầng. Hệ thống an ninh và quản lý truy nhập cũng là đối tượng của hạ tầng. Hạ tầng càng phức tạp thì các dịch vụ càng “dễ sống” hơn và càng đơn giản hơn để hình thành hệ thống thông tin. Nhưng sự phức tạp của hạ tầng lại có mâu thuẫn. Khó chuẩn hoá một hạ tầng với bộ chức năng đồ sộ. Còn khi mua từ các nhà cung cấp, chúng ta sẽ gặp rủi ro về tính tương thích do có sự khác nhau giữa SOA của Microsoft, SOA của Oracle v.v… Có lẽ, cần thừa nhận mức tối thiểu của hạ tầng cho dịch vụ. Những dịch vụ chức năng cần cho đa số dịch vụ đáng để đưa lên mức hạ tầng. Nhưng việc phát triển nó không ngừng có thể dẫn tới xoá sổ ý tưởng SOA.

Kế thừa và đa hình

Đã nói đến đóng gói thì không thể bỏ qua lưu ý đến cả quan hệ của SOA với 2 “hòn đá tảng” khác của lập trình hướng đối tượng là kế thừa và đa hình. Sự có mặt của cơ chế kế thừa trong phát triển các dịch vụ sẽ bổ sung rất nhiều tính mềm dẻo cho chúng, và có lẽ nó cho thấy rõ vấn đề đối với các dịch vụ được phát triển trong một môi trường duy nhất. Đa hình xuất hiện ở đây như hệ quả logic của kế thừa. Khó nói liệu có thể kế thừa bất kỳ dịch vụ nào. SOA hiện thời vẫn đặt ra nhiều câu hỏi hơn là cho câu trả lời.

Phổ biến quy trình kinh doanh

Câu chuyện đến giờ vẫn chỉ là về tổ chức kiến trúc dịch vụ thế nào để kích hoạt hệ thống phát triển, đơn giản hóa và giảm chi phí của việc phát triển và vận hành. Nhưng người dùng sẽ “sống” trong hệ thống này thế nào? Nếu không có những biện pháp đặc biệt, người dùng sẽ đơn giản là không thể chịu đựng trong hệ thống này. Các quy trình kinh doanh trong tương tác với con người sẽ diễn ra cùng và theo các dịch vụ. Người dùng buộc phải thường xuyên kết nối giữa các giao diện được phát triển bởi những người khác nhau trong những thời gian khác nhau theo các công nghệ khác nhau. Tính đến khả năng rất hạn chế của con người trong việc làm quen với các giao diện mới, không khó dự đoán các phản ứng của người dùng – đó là sự bất tiện hoàn toàn của hệ thống.

Không thể nói vấn đề này không được quan tâm. Để giải quyết nó, đã có hẳn công nghệ mô tả và thực hiện các quy trình kinh doanh – ngôn ngữ BPEL1 và các trình biên dịch của nó. Trình biên dịch của BPEL (Business Process Execution Language – Ngôn ngữ thực thi quy trình kinh doanh) chịu trách nhiệm ở lớp tương tác với người dùng, chuyển thể công việc lập tức cùng nhiều dịch vụ và giấu chúng khỏi người dùng. Tuy nhiên, hãy thử đánh giá, có bao nhiêu phần nỗ lực của bạn như một nhà phát triển được phân phối cho việc thực hiện thuật toán chính thức về thao tác dữ liệu và bao nhiêu phần được chi cho việc đảm bảo sự thuận tiện và năng suất cho người sử dụng? Đối với hầu hết các tính toán không chuyên khoa học và kỹ thuật, nhiều khả năng sẽ là đến 80% nghiêng về hướng cho giao diện người dùng. Mọi môi trường phát triển đồ hoạ hiện hành đều phát triển từ đầu như phương pháp tạo lập giao diện người dùng và sau đó được gán thêm những chức năng bên dưới (back-end) cần thiết. Nhiều trường hợp kéo dài cho đến tận bây giờ.

Tự tổ chức

Tất cả công thức và cách tiếp cận để xây dựng SOA đều đòi hỏi kiểm tra thực tế.

Chúng ta đã đề cập SOA phải giúp hệ thống thông tin “sống lâu” và “tiến hoá”. Có thể xem xét liền lúc mọi nhu cầu của hệ thống và phác hoạ cho nó một kế hoạch tổng thể không? Nếu được thì việc này cũng rất áng chừng với đầy rủi ro mắc lỗi. Hơn nữa, giao diện thống nhất được ứng dụng cho tương tác các phần của hệ thống thông tin cũng như các hệ thống thông tin với nhau đang làm cho ranh giới của chúng ngày càng mang tính “quản trị” hơn thay vì “kỹ thuật”. Đây là những nguyên lý để xây dựng Internet. Và mạng lưới này có các thuộc tính của tự tổ chức, không có kế hoạch tập trung.

Nếu việc sử dụng kiến trúc SOA gia tăng đến quy mô mong đợi thì nó nhất định phải có những thuộc tính của tự tổ chức. Khi xuất hiện nhiệm vụ tích hợp hai hệ thống SOA đang phát triển được quản lý riêng rẽ, chúng cần thực hiện nhanh chóng và hiệu quả. Nếu đúng là trong tập đoàn lớn, SOA bắt đầu phát triển tại các bộ phận độc lập thì việc tích hợp các phần phải diễn ra thuận lợi. Điều đó không có nghĩa là khi thành lập hệ thống thông tin trên cơ sở SOA, chúng ta không sợ bất kỳ sai lầm kiến trúc nào. SOA không cần thiết đòi hỏi thiết kế toàn bộ hệ thống ngay từ đầu “từ A đến Z” rồi mới chuyển sang thực hiện. Nó cần hỗ trợ nguyên lý “tiệm cận”. Tại ranh giới của 2 hệ thống, cần vứt bỏ các dịch vụ không giao nhau và thay vào đó các dịch vụ tiện lợi, đủ “nhẹ”. Kết quả của việc này phải trở thành bất biến trong kiến trúc SOA trong lần triển khai tiếp theo. Điều đó là tích cực vì doanh nghiệp dị ứng với các đòi hỏi tiền tỷ mà kết quả của chúng chỉ đơn giản là “công nghệ mới…”. Ngược lại, nếu kết quả lộ diện sớm thì tự thân công nghệ là sẽ “không quan trọng lắm” đối với doanh nghiệp.

“Tiệm cận” nghĩa là với SOA, mô hình phát triển tích hợp là phù hợp và cần thiết. Trong đó, cần nhanh chóng có mô hình dịch vụ, thử nghiệm nó, thực hiện các hiệu chỉnh cần thiết và lặp lại quy trình phát triển vài lần. Nguyên lý RAD (Rapid Application Development – Phát triển ứng dụng nhanh chóng) phải được phát huy trên 2 mức độ. Đầu tiên là nhanh chóng tích hợp mô hình dịch vụ, sau đó tích hợp lồng ghép dịch vụ vào kiến trúc hiện có và quan trọng là đưa vào được các quy trình kinh doanh có sẵn với sự tham gia trực tiếp của người dùng. Mô hình phát triển tích hợp là hiệu quả nhất hiện nay. Nó cần cho SOA, nếu không, SOA sẽ không thể chứng minh tính hiệu quả.

Tổ chức phát triển

Chúng ta cùng trở lại vấn đề tổ chức phát triển thế nào, chính xác hơn là tổ chức chu trình hệ thống thông tin dựa trên các nguyên lý SOA. Dễ hiểu là vấn đề lựa chọn nhà phát triển dịch vụ sẽ không còn quá cứng nhắc như hiện nay. Cần có khả năng tự phát triển các dịch vụ, đặt làm hoặc mua ngoài. Việc làm lại dịch vụ, nếu vì lý do nào đó là khó, thì phải thay thế. Quan trọng hơn là vấn đề ai sẽ quản lý các dịch vụ. Nhiệm vụ này phải đặt lên doanh nghiệp - chính doanh nghiệp là người chủ duy nhất của các quy trình kinh doanh không lặp lại của họ.

Nhưng cũng có thể chuyển nó cho nhà thầu, cái chính là không chuyển cho chính người tạo ra dịch vụ. Các lợi ích của nhà phát triển dịch vụ và nhà tích hợp hệ thống có thể mâu thuẫn nhau. Trong đó, cần hiểu rằng doanh nghiệp sẽ lệ thuộc đáng kể vào nhà tích hợp và buộc phải xây dựng chính sách hợp tác lâu dài với họ. Doanh nghiệp không thể không quan tâm hoàn toàn đến các nguồn lực thông tin của mình, thậm chí nếu mô hình SOA sẽ được thực thi và tất cả việc hỗ trợ hệ thống thông tin đã được thuê ngoài. Quy trình kinh doanh dẫu sao vẫn là phần không thể tách rời khỏi chính doanh nghiệp.

Đã đến lúc triển khai SOA?

Khi người đặt hàng hệ thống thông tin muốn ra quyết định triển khai SOA, người đó sẽ nhìn thấy quanh mình bức tranh đầy mâu thuẫn. Các nhà cung cấp then chốt nói rằng các công cụ và hạ tầng cần thiết đã sẵn sàng, có thể mua dùng. Trong bối cảnh cạnh tranh khốc liệt, mọi đối thủ lớn đều sẵn sàng trình diễn “bộ sưu tập xịn” về SOA. Ai đó còn nói rằng “SOA đã nằm trong sản phẩm” của họ. Kiểm tra việc này rất khó nhưng khó có thể chờ đợi thái độ khác của các nhà cung cấp.

Liên quan phần mềm nguồn mở, chúng ta biết rằng nhiều chuẩn đang trong quá trình phát triển, còn việc tung ra các mã (code) thì vẫn diễn ra liên tục. Trong trường hợp này, thường có sự xét lại nghiêm túc với các giải pháp đã được tiếp nhận trước đó. Các vấn đề ở đây không ít, vẫn còn rất nhiều khó khăn khách quan.

Có những công ty lớn tuyên bố họ từ lâu đã sử dụng công nghệ nào đó và hoàn toàn thấy rõ các lợi ích của nó. Nhưng khi tính đến việc gia tăng vốn liếng của các công ty này đầu tư cho các công nghệ đó, thật khó có thể nói chuyện gì đã thực sự xảy ra bên trong hàng rào nhà máy của họ.

Có các cuộc thăm dò với các chuyên gia CNTT và thấy rằng đa số họ ít nhiều chuẩn bị sử dụng SOA và không phản đối nó. Nhưng từ đó cũng hiểu, thời SOA được ứng dụng hàng loạt vẫn chưa đến. Có một đám đông những người hoài nghi nói rằng SOA là bộ thời trang tiếp theo, sẽ qua đi và được thay thế bởi cái mới khác…

Mọi thứ thì thế thật nhưng tác giả bài viết cũng muốn lưu ý những người hoài nghi rằng, SOA không liên quan chặt chẽ, “gắn chết” với công nghệ nào đó để có thể phải chết cùng nó. SOA trước hết được xác định bởi kết quả có thể nhận được chứ không phải là tập hợp của các phương pháp đạt được nó. Đây là tập hợp các nguyên lý logic và nhất quán, nhưng triển khai nó trên thực tế là bài toán rất không tầm thường.

Những công thức và cách thức xây dựng SOA không phải là thứ không thể tranh luận. Chúng đòi hỏi được kiểm chứng. Cách duy nhất để kiểm tra tính đúng đắn của chúng là xây dựng hệ thống thông tin trên các nguyên lý SOA với các công cụ hiện có và có thể hiểu được những hạn chế của chúng. Người muốn có chất lượng mới của hệ thống thông tin không thể lảng tránh quá trình này.