ĐỂ GIỮ CHO JAVA LUÔN HẤP DẪN
THÁCH THỨC TỪ .NET
Năm 2001, Microsoft tiết lộ công nghệ “sẽ tiêu diệt Java” của họ với cái tên nền tảng .Net (.NET frameworks). Mặc dù trình thực thi của .Net hỗ trợ rất nhiều ngôn ngữ khác nhau bao gồm cả C++, Visual Basic, Microsoft tiếp tục giới thiệu một ngôn ngữ hoàn toàn mới gọi là C# với cấu trúc mã tương tự như của Java. C# cũng mượn của Java khái niệm biên dịch tạm thời (semi-compiled), tính năng quản lý bộ nhớ và khả năng cho phép môi trường thực thi áp dụng một số giới hạn an toàn riêng. Thêm vào đó, C# được bổ sung một số tính năng cạnh tranh như ngôn ngữ ASP.NET giúp cho việc thiết kế giao diện web cho ứng dụng trở nên dễ dàng hơn bao giờ hết (đây là vấn đề mà Java hiện vẫn chưa giải quyết triệt để).
Mặc dù vậy, một năm sau khi được phát hành, .Net vẫn không lôi kéo được những người phát triển sử dụng Java sang sang công nghệ .NET. Ngược lại, những khó khăn trong quá trình chuyền đổi từ mã Windows sang cấu trúc mới của .NET chính là một cơ hội để Java thể hiện những tính năng của nó đối với những người phát triển trong môi trường Windows. Ngày nay, rất nhiều các ứng dụng đều sử dụng cả 2 công nghệ để giải quyết vấn đề: Java thường đóng vai trò quan trọng trong môi trường doanh nghiệp lớn tron gkhi .Net được sử dụng phổ biến cho các dự án nhỏ hơn. Hơn nữa, những tín hiệu gần đây hứa hẹn một mối quan hệ chặt chẽ hơn của hai công nghệ này.
Năm 2004, Sun và Microsoft cuối cùng đã dàn xếp xong cuộc chiến pháp lý về phiên bản Java đã sửa đổi của Microsoft – đưa hai công ty trở lại vị trí của những đối tác. Gần đây, CEO của Sun là Scott McNealy thậm chí còn ám chỉ rằng mục tiêu của công ty trong thời gian tới sẽ là xây dựng một cơ chế tích hợp chặt chẽ hơn giữa môi trường thực thi của Java và .NET. Thật khó để có thể hiểu chính xác điều này có nghĩa là gì, nhưng chắc chắn chúng ta có thẻ hi vọng rằng một ngày nào đó, một đối tượng viết bằng công nghệ này sẽ có thể được tuy cập bởi các ứng dụng viết bằng công nghệ kia (hiện tại, điều này chỉ có thể được thực hiện thông qua WS hoặc sử dụng các công nghệ độc quyền khác).
VẤN ĐỀ VỀ SỰ PHỨC TẠP HÓA
Rất nhiều những công nghệ doanh nghiệp của Java hiện đang được xem xét lại bởi một vấn đề càng ngày càng trở nên nghiêm trọng: sự phức tạp của quá trình phát triển. Với rất nhiều những bổ sung được thêm vào gần đây trong phần nền (core), J2EE đang dần trở thành một tổ hợp vô cùng lớn của rất nhiều những công nghệ như truyền thông điệp, dịch vụ email, khả năng kết nối cơ sở dữ liệu, cơ chế đặt tên và cấu trúc thư mục (directory), vân vân… Điểm hấp dẫn của sự phong phú này là nó cho phép bạn giải quyết gần như bất kỳ bài toán nào của các doanh nghiệp – trừ việc viết những chương trình đơn giản!
Trở thành một chuyên gia trong tất cả các công nghệ quan trọng của Java hiện tại là một yêu cầu không thể đối với những người phát triển J2EE. Đơn giản là nó có quá nhiều công nghệ khác nhau mà mỗi trong số chúng là một lĩnh vực đòi hỏi sự chuyên sâu. Hậu quả là quá trình cấu trúc, viết mã và sửa lỗi trong các ứng dụng J2EE là một công việc đau đầu.
Rất nhiều doanh nghiệp giờ đây quyết định chọn chỉ sử dụng một phần (subset) của J2EE. Ví dụ, họ sẽ chỉ dựa trên một gói đơn như Apache Tomcat – truy cập cơ sở dữ liệu qua JDBC và xử lý giao diện người dùng với Struts. Những công nghệ này cho phép họ xây dựng một quá trình phát triển trộn lẫn mà không phải ôm trọn toàn bộ J2EE. Tuy nhiên, cho những ứng dụng phức tạp, J2EE vẫn là giải pháp duy nhất khả thi.
HỘP ĐẬU?
(Chú thích: tiêu đề tiếng Anh là một kiểu chơi chữ: “Canned BEANS” – “Bean” lấy từ cái tên JavaBeans – nhưng nó cũng có nghĩa là hạt đậu. “Canned beans” là đậu bỏ trong hộp – một kiểu đồ hộp đóng kín mít)
Vấn đề thứ hai của J2EE năm ngay trong một trong những tính năng hứa hẹn nhất của nó: EJBs (Enterprise JavaBeans). EJBs rất khó viết, áp dụng và kiểm tra. Chúng yêu cầu việc sử dụng của cơ chế thưa hưởng (inheritance) và dựa trên mô hình phức tạp để đảm bảo đặc tính của dữ liệu - hay đơn giản và dễ hiểu hơn, đó là việc lưu dữ liệu vào đĩa.
Mặc dù đã có nhiều lần chỉnh sửa quan trọng trong chuẩn EJB, nhiều nhà phát triển vẫn tìm kiếm một lựa chọn khác thay thế nếu có thể. May mắn thay, cộng đồng mã nguồn mở đã cung cấp những lựa chọn này dưới dạng những frameworks quản lý phần lớn những chi tiết phức tạp bên trong J2EE – có thể lấy Hibernate và Spring là hai sản phẩm ví dụ phổ biến nhất.
Hibernate là một cấu trúc (framework) lưu các đối tượng trong một cơ sở dữ liệu quan hệ. Mặc dù không được bao quát như các cấu trúc tương tự, sự đơn giản và khả năng hỗ trợ cho phần lớn các phương thức quan trọng giúp Hibernate được chấp nhận rộng rãi.
Spring, ngược lại, là một cấu trúc rất nhỏ sử dụng POJOs (Plain Old Java Objects – tạm dịch “Đối tượng Java truyền thống”) thay cho EJB. Thiết kế này giúp cho việc viết mã và kiểm tra các thành phần ứng dụng trở nên dễ dàng hơn đối với người phát triển. Thú vị là Spring sẽ vẫn hoạt động trơn tru với Hibernate và các cấu trúc khác xuất hiện trong tương lai.
Trong khi đó, Sun hiện tại đang tiếp tục xây dựng phiên bản mới của EJB, một phần trong nỗ lực chỉnh sửa lại J2EE gọi là J2EE 5.0, với mục tiêu là giúp đơn giản hóa quá trình truy cập và sử dụng các dịch vụ của EJB. Điểm mới của J2EE 5.0 là khả năng đính kèm các chú thích và các thông tin ẩn (metadata) vào trong mã Java, cho phép người phát triển có thể xác định các thuộc tính của đối tượng một cách nhanh chóng. Sun cũng sẽ sử dụng POJOs, vốn rất dễ cho mục đích phát triển, sử dụng và đặc biệt là kiểm tra. Những doanh nghiệp quan tâm đến các dự án J2EE mới có lẽ nên suy nghĩ thật kỹ về quá trình chuyển đổi này.
Trang 3: Kết luận & biểu đồ tổng kết lịch sử 10 năm
Trang: Previous pageNext page










Nguyễn Thanh Sơn
Viet Nam
đến từ
Chào bạn,
Trước đây mình có xem qua 1 số bài viết của bạn cụ thể mình quan tâm đến AJAX, bài viết của bạn rất hay và mình thấy rất có phong cách.
Hôm hay lang thang vô tình lại lạc vào đây thấy có nhiều thay đổi và mong rằng bạn sẽ có nhiều bài viết hay như vậy để anh em được học tập
Thân chào.