Tại sao lại sử dụng JNDI cho các nguồn dữ liệu

Question

Bất cứ ai có thể giúp giải thích tại sao JNDI phải là một cách ưu tiên để trưng ra các dịch vụ như cơ sở dữ liệu/jms?

Các bài viết tôi chạy vào tất cả nói về lợi thế của việc không phải tải một trình quản lý trình điều khiển cụ thể, lợi ích từ kết nối tổng hợp, vv nhưng điều đó dễ dàng đạt được bằng cách chỉ định trình quản lý trình điều khiển trong tệp thuộc tính và sử dụng phản chiếu.

Kết nối tổng hợp cũng có thể đạt được bằng cách đấu dây trong việc triển khai đúng vào một ứng dụng đậu qua mùa xuân hoặc ngược lại.

Vậy tại sao sử dụng JNDI lại tốt hơn?

Answer 1

JNDI thực sự tỏa sáng khi bạn phải di chuyển một ứng dụng giữa các môi trường: phát triển để tích hợp để kiểm tra sản xuất. Nếu bạn cấu hình mỗi máy chủ ứng dụng để sử dụng cùng một tên JNDI, bạn có thể có các cơ sở dữ liệu khác nhau trong mỗi môi trường và không phải thay đổi mã của bạn. Bạn chỉ cần chọn tệp WAR và thả nó vào môi trường mới.

Dưới đây là một số giả định khác là rất quan trọng để biết khi nào đánh giá câu trả lời này:

• Tôi không có quyền truy cập vào các máy chủ mà trên đó các mã được triển khai ở tất cả, ngoại trừ chỉ đọc truy cập vào nhật ký.
• Người viết và đóng gói mã không phải là cùng một người định cấu hình và quản lý máy chủ.
• Khi tệp WAR bắt đầu trên hành trình của nó tới PROD, nó không thể thay đổi được nữa mà không quay lại phần đầu. Bất kỳ thử nghiệm nào được thực hiện bởi QA trên máy chủ thử nghiệm phải được thực hiện lại nếu WAR bị thay đổi.

Có lẽ bạn không thấy lợi ích này vì bạn là nhà phát triển duy nhất viết mã trên máy tính để bàn cục bộ và triển khai quyền sản xuất.

Answer 2

Tôi nghĩ cơ chế "ưa thích" là cơ chế được người quản trị và cấu hình ưa thích hơn. Như duffymo đã chỉ ra, điều quan trọng là cấu hình phải ở bên ngoài để tạo tác triển khai của bạn, nhưng nếu không, tôi sẽ nói bất cứ điều gì đi. Nếu sysadmin của bạn thích sử dụng GUI để cấu hình các mục JDNI, hãy làm mát. Nếu anh ta/cô ấy thích chỉnh sửa các tập tin thuộc tính với cssh và vi, mát quá. Nếu bạn chịu trách nhiệm cho cả việc phát triển và định cấu hình/triển khai ứng dụng của mình, thì đó là khá nhiều cuộc gọi của bạn. Cá nhân, tôi muốn giữ càng nhiều triển khai càng tốt trong phần tạo tác của tôi, có nghĩa là nguồn dữ liệu và trình điều khiển của tôi cũng tồn tại ở đó.

Nếu bạn đang hỏi về lợi ích kỹ thuật của JNDI qua các lựa chọn thay thế, tôi không chắc chắn có bất kỳ điều gì, nhưng bạn có thể muốn làm rõ câu hỏi của mình.

Answer 3

Như đã đề cập bởi những người khác JNDI cho hầu hết các phần được sử dụng để tra cứu vị trí dịch vụ nhưng chủ yếu cho DB như tài nguyên.

Điều khó chịu nhất là API LDAP của Java cũng là API JNDI. Khi làm việc với LDAP trừu tượng là rất rất khó hiểu. JNDI cũng có những bất lợi của đôi khi là một điểm duy nhất của thất bại.

Bạn có thể dễ dàng thực hiện hầu hết những gì JNDI thực hiện bằng cách sử dụng bí danh tên máy chủ lưu trữ. Điều đó tạo nên một bí danh có điểm MYRESOURCE thành 127.0.0.1 trong số /etc/hosts của bạn (hoặc bất kỳ nơi nào dành cho env của bạn). Sau đó, trong cấu hình ứng dụng của bạn sử dụng MYRESOURCE làm tên máy chủ lưu trữ (trong một url jdbc chẳng hạn).

Sau đó, khi bạn di chuyển ứng dụng sang sản xuất, chỉ cần thay đổi tệp /etc/hosts của sản xuất thành điểm MYRESOURCE thành tài nguyên/dịch vụ sản xuất (như máy chủ cơ sở dữ liệu prod).

Ở trên là một thư mục đặt tên dấu chân nhỏ hơn di động sẽ hoạt động ở các ngôn ngữ khác (ruby, python). Nó cũng sẽ làm việc với những thứ thường không được thực hiện với JNDI như các dịch vụ REST. Điều khó chịu duy nhất là bạn sẽ phải cập nhật các máy chủ của bạn lưu trữ các tệp nhưng điều này có thể được tự động thông qua các tập lệnh SSH.

Answer 4

Lợi ích thực sự của JNDI đối với tệp thuộc tính xuất hiện khi triển khai vào môi trường nhóm. Sử dụng các tệp thuộc tính để lại khả năng một số phiên bản máy chủ có giá trị khác. Khi sử dụng JNDI cùng một giá trị được đẩy ra cho tất cả các máy chủ được nhóm bởi bộ điều khiển miền, loại bỏ sự cần thiết phải sao chép cùng một tập tin thuộc tính cho tất cả các máy chủ (và có thể khởi động lại máy chủ/ứng dụng).

Answer 5

Một lĩnh vực mà JNDI giúp:

Nó tóm tắt tra cứu tài nguyên. Thông thường cấu hình JNDI được lưu trữ trong một tệp XML trên máy chủ ứng dụng, nhưng nó không cần thiết. Ví dụ, cấu hình có thể được lưu trữ trên một máy chủ LDAP, để làm cho nó dễ dàng hơn để duy trì tập trung.

Nếu ứng dụng bạn chạy sử dụng JNDI để tra cứu những gì họ cần, bạn có thể chuyển từ tệp cấu hình sang sử dụng máy chủ LDAP mà không sửa đổi ứng dụng. Nếu mỗi ứng dụng mong đợi một tệp thuộc tính với một tên mã cứng, bạn sẽ không may mắn. Hãy tưởng tượng một doanh nghiệp với hàng tá ứng dụng trong sản xuất - thay đổi tất cả chúng sẽ là một vấn đề quan trọng.

Nói cách khác, JNDI chủ yếu tỏa sáng cho các kịch bản triển khai phức tạp, như:

• nhiều máy chủ ứng dụng (có thể là cụm)
• nhiều ứng dụng khác nhau
• cấu hình trung
• giai đoạn máy chủ khác nhau (kiểm tra , sản xuất)

Vì vậy, có vẻ như quá mức lúc đầu, nhưng rất hữu ích trong các kịch bản đề tài. Tất nhiên, một số lợi ích được áp dụng ngay cả đối với các triển khai nhỏ, chẳng hạn như cấu hình chuẩn của các kết nối DB.