chương 1 trình bày về một số khó khăn của ngành công nghệ phần mềm hiện nay. Từ đó giới thiệu, phân tích các ưu khuyết điểm của một số mô hình kiến trúc phân tán được xây dựng để giải quyết các khó khăn trên như là CORBA, EJB, DCOM v. Thực trạng hiện tại Phần mềm ngày nay đang ngày càng trở nên phức tạp và dường như đang vượt khỏi khả năng kiểm soát của các mô hình phát triển phần mềm hiện có. Albert Einstein đã nói :“Mọi việc nên thực hiện theo cách đơn giản đến mức có thể…” , một thực trạng đáng buồn là có rất nhiều hệ thống phần mềm được xây dựng với kiến trúc quá phức tạp, chi phí phát triển và bảo trì cao, đặc biệt là với các hệ thống phần mềm cao cấp.
Hàng chục năm qua, nhiều kiến trúc phần mềm đã được xây dựng và triển khai nhằm giải quyết các vấn đề này. Thế nhưng độ phức tạp phần mềm vẫn cứ tiếp tục tăng và dường như đã trở nên vượt quá khả năng xử lý của các kiến trúc truyền thống. Nguyên nhân khiến cho độ phức tạp của các hệ thống phần mềm không ngừng tăng cao như thế là do sự xuất hiện của nhiều công nghệ mới tạo nên môi trường không đồng nhất, trong khi nhu cầu về trao đổi, chia sẻ, tương tác giữa các hệ thống không thể đáp ứng được trong một môi trường như vậy. Làm sao có thể dung hòa được những cách biệt giữa cái cũ và cái mới? Các hệ thống cũ (legacy systems) cần được sử dụng lại thay vì phải gỡ bỏ và thay mới bởi vì chi phí thực hiện lại từ đầu chắc chắn sẽ cao hơn việc chi phí chuyển đổi cái cũ rất nhiều lần.
Vấn đề này liên quan đến một khái niệm và cũng là một thách thức mà các tổ chức phải đối mặt, đó là “tích hợp hệ thống” (Enterprise Architecture Integration - EAI). Hiện các dự án dạng này đang được rất nhiều tổ chức quan tâm đến, với mức đầu tư về chi phí đang dẫn đầu so với các dạng dự án khác. Một nguyên nhân khác cũng góp phần dẫn đến tình trạng khó khăn như thế chính là vấn đề lập trình dư thừa và không thể tái sử dụng. Hãy xét một ví dụ, một ngân hàng có nhiều chi nhánh khác nhau – mỗi chi nhánh có một hệ thống tách biệt và cần kết nối với các hệ thống khác của ngân hàng để phục vụ khách hàng được hiệu quả hơn.
Giả sử rằng các hệ thống này đều được thiết kế rất tốt. Thế nhưng các hệ thống này được xây dựng trong những khoảng thời gian khác nhau, trong những dự án độc lập và khác nhau. Thông thường chức năng “lấy số liệu thống kê tài khoản” bị lặp lại trong mỗi hệ thống ATM, mỗi chi nhánh và trong hệ thống lưu trữ tài khoản, và ngay cả khi người dùng truy cập vào cùng một tài khoản trong cùng một cơ sở dữ liệu. Bây giờ nếu ngân hàng đó cần phát triển một hệ thống cung cấp LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 10 dịch vụ gửi tiền hay cho vay tiền qua mạng để tăng chất lượng phục vụ cho các khách hàng.
Hệ thống mới này sẽ được xây dựng thế nào? Nếu giải pháp chọn xây dựng lại hệ thống mới, thì lại tiếp tục mắc lại sai lầm trước đó: dư thừa, không đồng nhất … Còn nếu chọn giải pháp là sử dụng lại các chức năng sẵn có, thì ta phải đối mặt với chuyện thiết lập các mối liên kết với toàn bộ các hệ thống trước. Hầu như mọi tổ chức đều phải đối mặt với vấn đề tích hợp vì nhiều lý do, đặc biệt là trong thị trường ngày nay, sự thay đổi luôn diễn ra với tốc độ chóng mặt; có thể là mở rộng thêm chi nhánh, một hệ thống bạn hàng mới, hoặc chỉ đơn giản là cần kết nối các hệ thống có sẵn. Nếu có n hệ thống ứng dụng cần được kết nối trực tiếp với nhau, thì cần n*(n-1) kết nối, hoặc là thành phần giao tiếp (interface). App 1 App 2 App 3 App 4 App 5 Hình 1.
Tích hợp dạng điểm nối điểm [15] Tương tự, nếu có thêm một hệ thống ứng dụng thứ (n+1) cần đựơc tích hợp thêm vào hệ thống, thì nó đòi hỏi 2*n interface mới, bao gồm cả việc thu thập sưu liệu , kiểm thử, và bảo trì. Theo như Hình 1-1 trên thì 5 ứng dụng đòi hỏi 20 kết nối trực tiếp, một ứng dụng thứ 6 tích hợp thêm vào sẽ yêu cầu thêm 10 kết nối mới! Tệ hơn nữa, mã nguồn của các ứng dụng cũ phải được chỉnh sửa để thêm vào các kết nối, từ đó kéo theo chi phí kiểm thử, bảo trì. Những vấn đề trước chưa giải quyết, mà nay các tổ chức lại phải đối mặt với những thách thức mới: đáp ứng nhanh chóng các sự thay đổi, giảm chi phí phát triển, tăng tính tương thích và khả năng tái sử dụng. 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.
LUAN VAN CHAT LUONG download : add luanvanchat@agmail. Phân tích, đánh giá một số mô hình kiến trúc phân tán hiện tại Ba kiến trúc phân tán phổ biến nhất hiện này là CORBA, DCOM và EJB. Các kiến trúc này là sự mở rộng của các hệ thống hướng đối tượng bằng cách cho phép phân tán các đối tượng trên mạng. Đối tượng đó có thể có không gian địa chỉ bên ngoài ứng dụng, hoăc ở một máy khác với máy chứa ứng dụng trong khi vẫn được tham chiếu sử dụng như một phần của ứng dụng.
CORBA – Common Object Request Broker Architecture: CORBA được định nghĩa bởi Object Management Group (OMG), là một kiến trúc phân tán mở, độc lập nền tảng và độc lập ngôn ngữ. CORBA Component Model (CCM) là một cải tiến đáng kể nhằm định nghĩa các mô hình thành phần so với CORBA. Nó định nghĩa ra quy trình thiết kế, phát triển, đóng gói, triển khai và thực thi các thành phần phân tán. CCM định nghĩa khái niệm Ports cho các thành tố.
Các port này được sử dụng để kết nối các thành phần có sẵn với nhau, tạo các hệ thống phân tán phức tạp hơn. Mỗi thành phần CCM có một đối tượng Home chịu trách nhiệm quản lý chu kỳ sống của đối tượng và được triển khai bên trong một trình chứa (container). Ưu điểm của CORBA là các lập trình viên có thể chọn bất kỳ ngôn ngữ, nền tảng phần cứng, giao thức mạng và công nghệ để phát triển mà vẫn thoả các tính chất của CORBA. Tuy nhiên CORBA số một nhược điểm là nó là ngôn ngữ lập trình cấp thấp, rất phức tạp, khó học và cần một đội ngũ phát triển có kinh nghiệm.
Ngoài ra các đối tượng CORBA cũng khó có thể tái sử dụng. Các thành phần của đối tƣợng CORBA LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 12 EJB - Enterprise Java Bean: Kiến trúc EJB là một kiến trúc thành tố bên phía máy chủ dùng cho việc phát triển và triển khai các ứng dụng phân tán hướng đối tượng cỡ vừa và lớn. Kiến trúc EJB có 3 tầng với tầng đầu tiên là tầng trình diễn, tầng thứ hai là tầng xử lý nghiệp vụ, và tầng thứ ba là các tài nguyên như cơ sở dữ liệu máy chủ. Truyền thông giữa các đối tượng EJB thông qua Remote Method Invocation (RMI).
Các client không bao giờ tương tác trực tiếp với các bean. Thay vì vậy chúng sẽ sử dụng các phương thức được định nghĩa trong các interface Remote và Home. Mỗi bean tồn tại bên trong trình chứa, chịu trách nhiệm việc tạo thể hiện mới, lưu trữ dữ liệu và các quản lý khác. Trình chứa sẽ triệu gọi các phương thức (callback) của mỗi thể hiện bean khi có sự kiện tương ứng.
Không giống như CCM (CORBA Component Model), EJB không định nghĩa các port kết nối trực tiếp giữa các thành phần liên quan bởi vì mỗi bean bên trong trình chứa là một thực thể độc lập không có bất kỳ ràng buộc nào bên ngoài. EJB là một kiến trúc tốt cho việc tích hợp các hệ thống vì nó độc lập nền tảng nhưng nó cũng gặp vấn đề là nó không phải là một chuẩn mở, khả năng giao tiếp với các chuẩn khác vẫn còn hạn chế. Mô hình tƣơng tác của đối tƣợng EJB DCOM – Distributed Component Object Model: LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 13 DCOM là một mô hình phân tán dễ triển khai với chi phí thấp, hỗ trợ sự liên kết chặt chẽ (tight coupling) giữa các ứng dụng và hệ điều hành. Mô hình Component Object Model (COM) định nghĩa cách thức các các thành phần và client liên lạc trao đổi với nhau trên cùng một máy.
DCOM mở rộng COM bằng cách sử dụng các giao thức mạng chuẩn khi cần trao đối dữ liệu với máy khác trên mạng. DCOM hỗ trợ kết nối giữa các đối tượng và những kết nối này có thể được thay đổi lúc đang chạy. Các đối tượng DCOM được triển khai bên trong các gói nhị phân chứa các mã lệnh quản lý chu kỳ sống của đối tượng và việc đăng ký đối tượng. DCOM mang đến nhiều ưu điểm như tính ổn định, không phụ thuộc vị trí địa lý, quản lý kết nối hiệu quả và dễ dàng mở rộng, là một lựa chọn tốt cho các doanh nghiệp sử dụng công nghệ của Windows để chạy các ứng dụng có yêu cầu cao về sự chính xác và ổn định.
Tuy nhiên, các công nghệ của Microsoft có một nhược điểm lớn là chúng bị giới hạn trên nền tảng Windows. Mô hình tƣơng tác của đối tƣợng DCOM Các kiến trúc trên đều hướng đến việc xây dựng một hệ thống “hướng dịch vụ” tuy nhiên chúng vẫn còn gặp phải một số vấn đề. Đầu tiên là chúng sự liên kết chặt chẽ (tightly coupled), nghĩa là kiến trúc triển khai cài đặt bên phía nhà cung cấp dịch vụ và phía sử dụng dịch vụ phải giống nhau. Điều này đồng nghĩa với khó khăn mỗi khi có sự thay đổi từ một trong 2 phía bởi vì mỗi thay đổi cần được đánh giá, lên kế hoạch và sửa chữa ở cả 2 phía.
Tiếp đến những chuẩn trên đa phần là chuẩn đóng, chúng hầu như không thể kết hợp, hoạt động với chuẩn khác. Ví dụ như bắt đối tượng Java trao đổi dữ liệu trực tiếp với một đối tượng DCOM là không thể. Cuối cùng các đối tượng của các mô hình trên là fine grained, nghĩa là lượng thông tin giữa trong mỗi lần LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com 14 thực hiện giao dịch là ít, và được thực hiện nhiều lần dẫn đến chiếm dụng băng thông sử dụng và tăng thời lượng đáp trả dữ liệu.