Trong một vài từ OSGi là một tiêu chuẩn được sử dụng để xây dựng các ứng dụng mô-đun. Nó bổ sung thêm mức độ mới của mô-đun - bó (aka. Thành phần, mô-đun). Mỗi bó chứa các lớp và các giao diện và những gì là quan trọng nhất nó phải rõ ràng nhà nước:
- mà các thành phần khác hoặc Java gói nó sử dụng,
- và những gói nó muốn để lộ sẽ được sử dụng bởi các thành phần khác.
Từ các điểm xem kỹ thuật là các tệp jar có tệp mở rộng bit META-INF/MANIFEST.MF. Tất cả các thông tin nói trên được lưu trữ trong tập tin MANIFEST.MF.
Từ quan điểm thực tế, nhân chứng này có cả ưu điểm và nhược điểm. Đối với tôi, lợi thế lớn nhất là bạn buộc phải suy nghĩ về kiến trúc, mô-đun và tương tác giữa chúng nhiều hơn trong các ứng dụng tiêu chuẩn. Điều này có thể tạo ra kiến trúc tốt hơn trong đó mỗi mô-đun chịu trách nhiệm cho các nhiệm vụ và mô-đun được xác định rõ có thể được sử dụng lại. Nếu nói đến nhược điểm, việc tạo ra nhiều mô-đun có thể gây đau đớn đôi khi. Nó là khá dễ dàng để có rất nhiều mô-đun và nếu bạn thực sự có rất nhiều người trong số họ có thể khó để duy trì tất cả các phụ thuộc giữa các mô-đun (chu kỳ phụ thuộc là khá đau đớn).
OSGi không chỉ là tiêu chuẩn chỉ xây dựng các ứng dụng mô-đun. Nó cũng chỉ định môi trường trong đó các gói tồn tại và được chạy. Đây là điều bạn nên biết - khi sử dụng OSGi, bạn phải khởi động ứng dụng của mình trong một môi trường đặc biệt. Môi trường này (ví dụ: Eclipse Equinox) có trách nhiệm chạy ứng dụng của bạn. Nó cung cấp một số khả năng ưa thích. Ví dụ, bạn có thể thêm một gói vào ứng dụng đang chạy mà không cần phải dừng ứng dụng này - đây có thể là một yếu tố thực sự quan trọng trong một số loại ứng dụng (nhưng IMHO không có nhiều ứng dụng thực sự cần điều này). Điều thực sự thực sự quan trọng cũng là một thực tế rằng một số thư viện mã nguồn mở có thể không hoàn toàn tương thích với cơ sở hạ tầng OSGi và có thể khó sử dụng chúng ngoài hộp như trong các ứng dụng Java chuẩn (hãy nhớ rằng trong OSGi) mọi thứ nên là một gói). Tuy nhiên, rất nhiều thư viện phổ biến được gói thành bó - ví dụ Spring cung cấp bundles repository chứa nhiều thư viện phổ biến (nhưng không phải tất cả).
OSGi khá phức tạp và khó mô tả nó và khả năng của nó trong một vài từ.Những gì tôi đã viết chỉ là các yếu tố quan trọng nhất (IMO) của OSGi. Nhưng OSGI còn hơn thế nữa, ví dụ nhóm có thể gửi sự kiện cho nhau, họ có thể cung cấp dịch vụ cho nhau. Nếu bạn quan tâm đến nhiều chi tiết hơn, tôi khuyên bạn nên thực hiện một hướng dẫn. Tôi có thể đề nghị this one in Java World. Sau đó bạn có thể xem this free e-book về OSGi (nó chứa rất nhiều chi tiết). Tất cả các chi tiết về OSGi có thể được tìm thấy trong thông số kỹ thuật chính thức nhưng tôi không nói rằng chúng dễ đọc (ít nhất là ở đầu) - bạn có thể tìm thấy chúng here (trước khi tải xuống, bạn sẽ phải chấp nhận giấy phép và một số thông báo pháp lý) .
Để tóm tắt, tôi nghĩ OSGi rất hữu ích trong khi xây dựng các ứng dụng mô-đun nhưng điều này là chắc chắn không miễn phí. Đó là một tiêu chuẩn khá nặng có thể không cho phép bạn làm một số việc và buộc bạn phải làm những việc cách OSGi.
Một số liên quan SO câu hỏi:
Cảm ơn bạn rất nhiều vì câu trả lời chi tiết của bạn :) – Izza
bây giờ với sự ra đời của Microservices, các Microservices khác nhau hay tốt hơn như thế nào khi so sánh với OSGi? – yathirigan