SOA bản thân nó không đưa ra một kiến trúc hình mẫu cho mọi bài toán mà chỉ đề ra các đặc điểm, tính chất và các quy tắc của hệ thống khi triển khai theo chuẩn SOA. Trong thực tế, mỗi một đơn vị cung cấp giải pháp triển khai SOA đều đưa ra các cách tiếp cận của riêng mình.
Khi triển khai kiến trúc tổng thể cho hệ thống phần mềm, chúng ta thường mắc phải một số nhược điểm như:
● Lựa chọn công nghệ quá sớm và thường gắn chặt với một vài công nghệ nào đó, trong thời đại hiện nay, công nghệ thường thay đổi rất nhanh, vì vậy nếu không tính toán kỹ bài toán về công nghệ này sẽ gây những ảnh hưởng lớn về sau, cản trở sự phát triển của hệ thống.
● Đội ngũ xây dựng hệ thống thiên về kỹ thuật mà quên đi những định hướng về nghiệp vụ mới chính là vấn đề cần giải quyết, đây là nhược điểm thường mắc phải đặc biệt trong những hệ thống lớn với sự tham gia của nhiều thành
phần, nhiều đối tượng như Chính phủ điện tử. Điều này dễ dẫn đến sự đầu tư không đúng, lãng phí thời gian và tính khả dụng của hệ thống không cao. ● Các giải pháp đưa ra thường chưa tính đến chiến lược lâu dài, một hệ thống
phần mềm lớn như Chính phủ điện tử đòi hỏi một giải pháp hướng đến lộ trình “dài hơi” có thể kéo dài vài năm đến hàng chục năm và có thể còn tiếp diễn về sau khi duy trì hệ thống.
Để hiện thực hóa SOA cho Chính phủ điện tử Việt Nam, trước tiên chúng ta phải hiểu rõ mục tiêu và tính chất của SOA như thế nào khi áp dụng vào bài toán Chính phủ điện tử trong bối cảnh hiện nay của Việt Nam, như đã đề cập trong các phần về SOA và Chính phủ điện tử Việt Nam, chúng ta có thể liệt kê các mục tiêu và tính chất cần đạt được của hệ thống phần mềm Chính phủ điện tử Việt Nam đó là:
● Nâng cao tính linh hoạt, tăng khả năng thích ứng của hệ thống với các yêu cầu nghiệp vụ mới, như các bài toán về cải cánh thủ tục hành chính, liên thông thủ tục hành chính đang được đề cập hiện nay ở nước ta. Mục tiêu này giúp cho chúng ta giải quyết nhược điểm về lộ trình “dài hơi” thường gặp phải của các hệ thống lớn.
● Đẩy mạnh khả năng tái sử dụng trong hệ thống, đây là mục tiêu quan trọng với Việt Nam hiện nay, vì đầu tư cho Chính phủ điện tử là bài toán lớn và lâu dài, đòi hỏi nguồn lực không hề nhỏ, tái sử dụng giúp chúng ta giảm thiểu được nguồn lực đầu tư mà vẫn đạt được mục đích.
● Chấp nhận thay đổi, và có sự quản lý thay đổi ngay trong nội tại hệ thống, Chính phủ điện tử phục vụ người dân, doanh nghiệp, vì vậy chấp nhận thay đổi là một yêu cầu bắt buộc, kiến trúc đạt được phải hỗ trợ sự thay đổi dựa trên cấu hình hệ thống hơn là lập trình lại hoặc xây dựng từ đầu.
● Tạo ra môi trường cộng tác giữa các hệ thống con bên trong, giảm thiểu các kết nối điểm - điểm giải quyết bài toán tích hợp, chúng ta sẽ hướng hệ thống đến bản chất của dịch vụ là loại bỏ liên kết chặt chẽ, các thành phần hệ thống liên kết “lỏng” tạo ra một mạng lưới các dịch vụ tương tự như hạ tầng kết nối phần cứng. Mục tiêu này tương đồng với yêu cầu về liên thông hiện nay của Chính phủ điện tử Việt Nam.
● Dựa trên nền tảng các dịch vụ để tạo ra quy trình nghiệp vụ hướng đến các yêu cầu nghiệp vụ thay vì chỉ đơn thuần là kết hợp chúng về mặt kỹ thuật, điều này giúp định hướng hệ thống luôn gắn theo các yêu cầu từ phía nghiệp vụ, giúp giải quyết nhược điểm thứ hai đã nêu ở trên.
Với những mục tiêu đề ra, chúng ta cần có phương hướng phù hợp với hoàn cảnh Chính phủ điện tử Việt Nam, dựa vào các tìm hiểu về SOA và Chính phủ điện tử Việt Nam ở trên, luận văn sẽ đưa ra các bước để hiện thực hóa SOA trong Chính phủ điện tử Việt Nam.
Chúng ta không xây dựng bài toán Chính phủ điện tử Việt Nam bắt đầu từ đầu mà dựa trên nền tảng hệ thống các ứng dụng đã triển khai cho từng đơn vị, việc định hướng mô hình kết nối, đề xuất mô hình khung sẽ dựa trên Khung chính phủ điện tử. Việc lựa chọn SOA như một mô hình tham chiếu để giải quyết các vấn đề gặp phải về mặt công nghệ như tính kết nối, liên thông, tính tái sửa dụng. Dựa trên SOA chúng ta sẽ cần đưa ra mô hình kết nối các ứng dụng để hiện thực hóa mô hình đề xuất cho các đơn vị đã được đề cập trong Khung chính phủ điện tử Việt Nam. Từ mô hình đề xuất chúng ta sẽ có nền tảng để giải quyết các vấn đề nghiệp vụ cụ thể trong Chính phủ điện tử, tiếp theo luận văn sẽ đưa ra các bước cụ thể để hiện thực hóa các bài toán nghiệp vụ theo định hướng SOA.
Bước 1: Nắm rõ về yêu cầu nghiệp vụ và đặt ra các mục tiêu cần đạt được khi hoàn thành yêu cầu
Xây dựng hệ thống các phần mềm Chính phủ điện tử là một bài toán lớn, với nhiều vấn đề cần giải quyết mà chúng ta thường không thể đưa ra giải quyết cùng lúc và trong thời gian ngắn. Với một bài toán lớn như vậy, hướng tiếp cận của SOA là đưa ra mô hình kiến trúc mục tiêu tổng quát mang tính định hướng và phát triển dần các thành phần bên trong theo từng yêu cầu nghiệp vụ.
Trong bước này, chúng ta sẽ phải làm rõ các yêu cầu từ phía nghiệp vụ, mô hình hóa các quy trình nghiệp vụ, đề ra các mục tiêu đạt được khi hoàn thành từng yêu cầu nghiệp vụ. Các yêu cầu về nghiệp vụ cần được chuẩn hóa lại về mặt mô hình, đảm bảo chung một ngôn ngữ mô hình hóa để tất cả các đối tượng tham gia xây dựng hệ thống đều có thể hiểu đúng và đủ.
Nắm rõ yêu cầu nghiệp vụ, đặt ra các mục tiêu cần đạt được Đề ra mục tiêu cần đạt được
Mô hình hóa quy trình nghiệp vụ theo các tình huống nghiệp vụ Danh sách mục tiêu Các quy trình đã mô hình hóa
Hình 3.4 Nắm rõ yêu cầu nghiệp vụ và đặt ra mục tiêu
Một ví dụ để chúng ta có thể hình dung về bước thực hiện này, khi chúng ta nhận được yêu cầu Xây dựng hệ thông một cửa điện tử cho một đơn vị thì điều đầu tiên cần xác định là trên hệ thống một cửa điện tử này, chúng ta sẽ cần cung cấp dịch vụ gì, mỗi quy trình cho các dịch vụ đưa ra cần mô hình hóa như thế nào và khi triển khai dịch vụ này ai sẽ là đối tượng tham gia, hiệu quả mang lại ra sao.
Bước 2: Xác định ứng dụng, thành phần ứng dụng liên quan đến bai toán
Chúng ta sẽ không biết bắt đầu từ đâu nếu như không chia nhỏ các yêu cầu nghiệp vụ và đưa ra các vấn đề liên quan cho từng quy trình nghiệp vụ, việc xác định phạm vi các vấn đề liên quan đến từng quy trình nghiệp vụ giống như chúng ta phân chia bài toán thành các miền nhỏ để giải quyết từng phần, đây là tư tưởng chung của SOA.
Một hệ thống lớn không nhất thiết phải được xây dựng đồng thời, việc phân chia các miền vấn đề sẽ giúp chúng ta biết được vấn đề cần giải quyết thực sự là gì và sắp thứ tự ưu tiên. SOA không hướng đến việc xây dựng Chính phủ điện tử một lần cho tổng thể, mà nó khuyến khích chúng ta xây dựng theo “nhu cầu” của từng thời điểm điều này phù hợp với bản chất của Chính phủ điện tử là một hệ thống “trưởng thành” theo thời gian.
Xác định các ứng dụng, thành phần ứng dụng liên quan Phân tích độ phức tạp hệ thống, phân chia miền các vấn đề, thu thập dữ liệu liên quan
Đề xuất mô hình gồm các thành phần liên quan theo hướng đóng gói các dịch vụ Mô tả các thành phần theo miền các vấn đề Mô hình đề xuất Hình 3.5 Xác định ứng dụng, thành phần ứng dụng liên quan
Mỗi quy trình nghiệp vụ thường gắn liền với yêu cầu nghiệp vụ cụ thể, như bài toán Một cửa điện tử bên trong nó có thể bao gồm các dịch vụ công như Cấp giấy khai sinh, cấp sổ hộ khẩu, chứng minh nhân dân… Mỗi dịch vụ công này lại gắn liền với miền các vấn đề riêng, như Cấp giấy khai sinh sẽ gắn liền với các dữ liệu về giấy chứng sinh tại Bệnh viện, về xác minh giấy tờ chứng minh của cha mẹ do Công an cấp. Như vậy chúng ta sẽ xác định được phạm vi của miền vấn đề về Cấp giấy khai sinh bao gồm thành phần liên quan đến các dịch vụ từ Bệnh viện và Công An. Từ đó đề ra mô hình phù hợp theo hướng các đối tượng tham gia sẽ cung cấp và xử dụng dịch vụ lẫn nhau để đảm bảo yêu cầu của SOA.
Bước 3: Làm rõ thông tin ứng dụng, bổ sung thông tin hồ sơ ứng dụng bao gồm các dịch vụ liên quan
Một điều rất rõ ràng là chúng ta không thể xử lý thông tin nếu không hiểu được thông tin mình cần quản lý. SOA hướng đến việc chia nhỏ hệ thống thành các dịch vụ đóng gói, do đó đối tượng chính cần quản lý là các dịch vụ, vì vậy chúng ta sẽ phải hiểu được các thông tin liên quan đến dịch vụ bao gồm cả các đặc tính và ngữ cảnh sử dụng chúng. Mục tiêu của chúng ta tại bước này chính là xuất phát từ các yêu cầu của từng ứng dụng để đưa ra được các thông tin về những dịch vụ cần cung cấp.
Làm rõ thông tin, bổ sung hồ sơ ứng dụng Làm rõ thông tin, cập nhật hồ sơ ứng dụng di sản (Legacy) Làm rõ thông tin, cập nhật hồ sơ ứng dụng mới và các dịch vụ liên quan Thông tin các ứng dụng đang có Các thông tin hệ thống mục tiêu Định nghĩa dữ liệu cần quản lý trong mỗi dịch vụ
Các thông tin cần quản lý trong từng dịch vụ
Hình 3.6 Làm rõ thông tin các ứng dụng
Trong bước trước, chúng ta đã có được thông tin các ứng dụng, thành phần ứng dụng và mô hình kết nối tổng thể, tại bước này, chúng ta sẽ tiếp tục làm rõ hơn các thông tin để đưa được ra các dịch vụ và thông tin liên quan đến các dịch vụ cần cung cấp trong hệ thống mục tiêu. Để làm được điều này, chúng ta cần dựa vào việc phân tích thông tin các hệ thống đang có (bao gồm cả ứng dụng nội tại trong hệ thống và ứng dụng có kết nối từ bên ngoài), từ đó đề ra được các thông tin cần quản lý trong hệ thống và phân chia các ứng dụng, thành phần ứng dụng thành các dịch vụ có tính đóng gói và tái sử dụng. Ví dụ từ thông tin đã làm rõ về các quy trình Cấp giấy khai sinh, chúng ta sẽ có được danh sách các ứng dụng liên quan, như hệ thống thông tin bệnh viện, hệ thống cơ sở dữ liệu về công dân của cơ quan Công an, từ đó làm rõ hơn các thông tin cần quản lý như thông tin về chứng minh nhân dân, thông tin về nơi cư trú, thông tin về độ tuổi, nghề nghiệp… đây là các thông tin bắt buộc phải duy trì trong hệ thống. Các thông tin tổng hợp lại sẽ cho chúng ta một khung nhìn rõ hơn về hệ thống, từ đó đưa ra được các dịch vụ và mô tả mức trừu tượng cao của các dịch vụ, như với trường hợp Cấp giấy khai
sinh, đó có thể là dịch vụ Kiểm tra số chứng minh nhân dân, dịch vụ vấn tin thông tin bệnh nhân…
Bước 4: Xác định và làm rõ thông tin các dịch vụ trong hệ thống mục tiêu
Khi đã xác định được các dịch vụ cần quản lý (bao gồm cả những dịch vụ có sẵn và dịch vụ được tạo mới), chúng ta sẽ cần làm rõ các thông tin về từng dịch vụ, một số thông tin như dịch vụ sẽ được thực thi ở đâu, mục đích của dịch vụ, thông tin về giao diện, các ràng buộc nếu có và đặc biệt là vấn đề về bảo mật (ai được gọi, ứng dụng nào được gọi, khả năng mã hóa dữ liệu…)
Mỗi dịch vụ được đưa ra đều nhằm giải quyết các yêu cầu của hệ thống, để tránh trùng lặp và nâng cao khả năng tái sử dụng, chúng ta cần cung cấp thông tin một cách chi tiết nhất có thể cho từng dịch vụ, việc làm này giúp cho hệ thống có sự rõ ràng trong tất cả các thành phần.
Một hệ thống phần mềm lớn như Chính phủ điện tử sẽ bao gồm rất nhiều ứng dụng nhỏ hơn, trong đó có thể có những ứng dụng đã được triển khai trước tại mỗi đơn vị, như hiện nay phần mềm Quản lý văn bản điều hành đang được triển khai khá tốt tại mỗi đơn vị cơ quan nhà nước, những ứng dụng đó cũng có thể là các cổng kết nối tới hệ thống bên ngoài như giao dịch tài chính với các ngân hàng. Vì có rất nhiều loại dịch vụ khác nhau trong hệ thống, nên cần xác định rõ thông tin của mỗi dịch vụ để chuẩn hóa danh sách và quản lý hệ thống được tốt hơn.
Bên cạnh những thông tin về chức năng của mỗi dịch vụ thì việc đưa ra các thông tin về hiệu năng và các yêu cầu bảo mật cũng hết sức quan trọng, một hệ thống phức tạp sẽ rất khó để kiểm soát hiệu năng, vì vậy cần kiểm soát hiệu năng ngay khi xác định và đưa ra thông tin của từng dịch vụ để lấy đó làm căn cứ khi sử dụng dịch vụ.
Trong bước này chúng ta cần đưa ra được một mẫu mô tả thống nhất cho tất cả các dịch vụ, việc xây dựng mẫu mô tả này sẽ được trình bày trong chương sau.
Bổ sung, cập nhật danh mục các dịch
vụ
Phân tích thông tin về các dịch vụ, đưa ra danh sách dịch vụ đã chuẩn
hóa
Phân tích dữ liệu và thông tin cho từng dịch vụ theo yêu cầu chức năng
Danh sách các dịch vụ đã chuẩn hóa
Dịch vụ và thông tin đi kèm theo tính năng
Phân tích, đưa ra các thông tin về hiệu năng của dịch
vụ
Dịch vụ và thông tin hiệu năng tương ứng
Hình 3.7 Xác định và làm rõ thông tin các dịch vụ
Kết quả của bước này, chúng ta sẽ có tập hợp danh sách các dịch vụ đã được chuẩn hóa và các thông tin mô tả tính năng, hiệu năng tương ứng.
Bước 5: Định nghĩa, xây dựng các dịch vụ mới.
Các dịch vụ mới này chính là thành phần làm nên SOA, dựa vào các thông tin về dịch vụ và các ứng dụng, chúng ta có thể phân loại các dịch vụ mới thành các loại:
● Các dịch vụ di sản (Legacy): Đây là các dịch vụ bao bên ngoài các ứng dụng sẵn có của hệ thống mà chúng ta vẫn sẽ cần duy trì, sử dụng trong hệ thống mục tiêu.
● Các dịch vụ kết hợp (Composite): Tổ hợp nhiều dịch vụ nhỏ thành một dịch vụ lớn có tính sử dụng cao hơn, việc phân chia này có thể dựa vào tần suất sử dụng của nhóm các dịch vụ.
● Loại dịch vụ thứ ba là dịch vụ xây dựng hoàn toàn từ đầu, đây là các dịch vụ mà chúng ta cần đầu tư nhiều thời gian hơn, việc xây dựng mới cần tính đến tái sử dụng về sau.
Để định nghĩa ra các dịch vụ mới chúng ta cần thực hiện qua các bước: Xây dựng các tài liệu mô tả định nghĩa dịch vụ, Thiết kế các dịch vụ, Cài đặt các dịch vụ trong hệ thống thực. Tài liệu mô tả dịch vụ sẽ được dùng cho các thành phần khác khi tham chiếu tới dịch vụ được xây dựng. Thiết kế và cài đặt dịch vụ chính là các bước để hiện thực