Hệ thống thành phần của OSGi mang lại lợi ích gì cho bạn?
Vâng, đây là một danh sách:
Giảm độ phức tạp - Phát triển với công nghệ OSGi có nghĩa là phát triển các gói: các thành phần OSGi. Gói là các mô-đun. Họ giấu nội bộ của mình khỏi các gói khác và liên lạc thông qua các dịch vụ được xác định rõ. Ẩn nội bộ có nghĩa là tự do hơn để thay đổi sau này. Điều này không chỉ làm giảm số lượng lỗi, nó còn giúp phát triển các gói đơn giản hơn vì các gói có kích thước chính xác thực hiện một phần chức năng thông qua các giao diện được xác định rõ. Có một blog thú vị mô tả những gì công nghệ OSGi đã làm cho quá trình phát triển của họ.
Tái sử dụng - Mô hình thành phần OSGi giúp sử dụng rất nhiều thành phần bên thứ ba trong một ứng dụng. Ngày càng nhiều dự án nguồn mở cung cấp các JAR của họ đã sẵn sàng cho OSGi. Tuy nhiên, các thư viện thương mại cũng đang trở nên có sẵn như là các gói sẵn sàng.
Thế giới thực -Khung OSGi là động. Nó có thể cập nhật các gói trên bay và các dịch vụ có thể đến và đi. Các nhà phát triển đã sử dụng Java truyền thống hơn, coi đây là một tính năng rất có vấn đề và không thấy được lợi thế. Tuy nhiên, hóa ra thế giới thực rất năng động và có các dịch vụ năng động có thể đến và đi khiến các dịch vụ trở thành một kết hợp hoàn hảo cho nhiều kịch bản trong thế giới thực. Ví dụ: một dịch vụ có thể mô hình hóa một thiết bị trong mạng. Nếu thiết bị được phát hiện, dịch vụ được đăng ký. Nếu thiết bị biến mất, dịch vụ không được đăng ký. Có một số lượng đáng ngạc nhiên các kịch bản trong thế giới thực phù hợp với mô hình dịch vụ năng động này. Do đó, các ứng dụng có thể sử dụng lại các nguyên hàm mạnh mẽ của đăng ký dịch vụ (đăng ký, nhận, liệt kê bằng ngôn ngữ bộ lọc biểu cảm và chờ đợi các dịch vụ xuất hiện và biến mất) trong miền riêng của chúng. Điều này không chỉ tiết kiệm mã viết, nó còn cung cấp khả năng hiển thị toàn cầu, công cụ gỡ lỗi và nhiều chức năng hơn so với triển khai cho một giải pháp chuyên dụng. Viết mã trong một môi trường năng động như vậy nghe có vẻ như một cơn ác mộng, nhưng may mắn thay, có những lớp hỗ trợ và khung công tác chiếm phần lớn, nếu không nói là hết nỗi đau.
Triển khai dễ dàng - Công nghệ OSGi không chỉ là một tiêu chuẩn cho các thành phần. Nó cũng chỉ định cách các thành phần được cài đặt và quản lý. API này đã được sử dụng bởi nhiều gói để cung cấp một tác nhân quản lý. Tác nhân quản lý này có thể đơn giản như trình vỏ lệnh, trình điều khiển giao thức quản lý TR-69, trình điều khiển giao thức OMA DM, giao diện điện toán đám mây cho EC2 của Amazon hoặc hệ thống quản lý IBM Tivoli. API quản lý được tiêu chuẩn hóa giúp tích hợp công nghệ OSGi rất dễ dàng trong các hệ thống hiện tại và tương lai.
Cập nhật động - Mô hình thành phần OSGi là mô hình động. Các gói có thể được cài đặt, bắt đầu, dừng, cập nhật và gỡ cài đặt mà không làm sập toàn bộ hệ thống. Nhiều nhà phát triển Java không tin rằng điều này có thể được thực hiện một cách đáng tin cậy và do đó ban đầu không sử dụng điều này trong sản xuất. Tuy nhiên, sau khi sử dụng điều này trong phát triển một thời gian, hầu hết bắt đầu nhận ra rằng nó thực sự hoạt động và giảm đáng kể thời gian triển khai.
Thích nghi - Mô hình thành phần OSGi được thiết kế từ đầu để cho phép trộn và kết hợp các thành phần. Điều này đòi hỏi các phụ thuộc của các thành phần cần phải được chỉ định và nó yêu cầu các thành phần phải sống trong một môi trường mà các phụ thuộc tùy chọn của chúng không phải lúc nào cũng có sẵn. Sổ đăng ký dịch vụ OSGi là một sổ đăng ký động nơi các gói có thể đăng ký, nhận và nghe các dịch vụ. Mô hình dịch vụ động này cho phép các gói tìm ra những khả năng nào có sẵn trên hệ thống và điều chỉnh chức năng mà chúng có thể cung cấp. Điều này làm cho mã linh hoạt hơn và linh hoạt hơn với các thay đổi.
Tính minh bạch - Gói và dịch vụ là công dân hạng nhất trong môi trường OSGi. API quản lý cung cấp quyền truy cập vào trạng thái bên trong của gói cũng như cách nó được kết nối với các gói khác. Ví dụ, hầu hết các khung công tác cung cấp một vỏ lệnh cho thấy trạng thái bên trong này. Các phần của ứng dụng có thể bị dừng để gỡ lỗi một vấn đề nhất định hoặc có thể đưa các gói chẩn đoán vào. Thay vì nhìn chằm chằm vào hàng triệu dòng đầu ra đăng nhập và thời gian khởi động lại lâu, các ứng dụng OSGi thường có thể được gỡ lỗi bằng vỏ lệnh trực tiếp.
Phiên bản - Công nghệ OSGi giải quyết JAR hell. Địa ngục JAR là vấn đề mà thư viện A hoạt động với thư viện B; version = 2, nhưng thư viện C chỉ có thể hoạt động với B; version = 3. Trong Java tiêu chuẩn, bạn không gặp may. Trong môi trường OSGi, tất cả các gói được phiên bản cẩn thận và chỉ các gói có thể cộng tác được nối với nhau trong cùng một không gian lớp. Điều này cho phép cả bó A và C hoạt động với thư viện riêng của chúng. Mặc dù không nên thiết kế các hệ thống có vấn đề về phiên bản này, nhưng nó có thể là một trình cứu sinh trong một số trường hợp.
Đơn giản - API OSGi đơn giản đến bất ngờ. API lõi chỉ là một gói và ít hơn 30 lớp / giao diện. API lõi này đủ để viết các gói, cài đặt chúng, bắt đầu, dừng, cập nhật và gỡ cài đặt chúng và bao gồm tất cả các lớp nghe và bảo mật. Có rất ít API cung cấp rất nhiều chức năng cho rất ít API.
Nhỏ - Khung công tác OSGi Release 4 có thể được triển khai trong tệp JAR khoảng 300KB. Đây là một chi phí nhỏ cho số lượng chức năng được thêm vào ứng dụng bằng cách bao gồm OSGi. Do đó, OSGi chạy trên một loạt các thiết bị: từ rất nhỏ, nhỏ đến máy tính lớn. Nó chỉ yêu cầu một máy ảo Java tối thiểu để chạy và thêm rất ít vào đầu nó.
Nhanh - Một trong những trách nhiệm chính của khung OSGi là tải các lớp từ các gói. Trong Java truyền thống, các JAR hoàn toàn hiển thị và được đặt trong danh sách tuyến tính. Tìm kiếm một lớp học yêu cầu tìm kiếm thông qua danh sách này (thường rất dài, 150 không phải là hiếm). Ngược lại, OSGi gói trước dây và biết chính xác từng gói cung cấp lớp. Sự thiếu tìm kiếm này là một yếu tố tăng tốc đáng kể khi khởi động.
Lười biếng - Lười trong phần mềm là tốt và công nghệ OSGi có nhiều cơ chế để thực hiện mọi thứ chỉ khi chúng thực sự cần thiết. Ví dụ, các gói có thể được khởi động một cách háo hức, nhưng chúng cũng có thể được cấu hình để chỉ bắt đầu khi các gói khác đang sử dụng chúng. Dịch vụ có thể được đăng ký, nhưng chỉ được tạo khi chúng được sử dụng. Các thông số kỹ thuật đã được tối ưu hóa nhiều lần để cho phép các loại kịch bản lười biếng này có thể tiết kiệm chi phí thời gian chạy rất lớn.
Bảo mật - Java có một mô hình bảo mật hạt mịn rất mạnh ở phía dưới nhưng nó thực sự rất khó cấu hình trong thực tế. Kết quả là hầu hết các ứng dụng Java an toàn đang chạy với lựa chọn nhị phân: không có khả năng bảo mật hoặc rất hạn chế. Mô hình bảo mật OSGi tận dụng mô hình bảo mật hạt mịn nhưng cải thiện khả năng sử dụng (cũng như làm cứng mô hình ban đầu) bằng cách yêu cầu nhà phát triển gói xác định các chi tiết bảo mật được yêu cầu ở dạng dễ kiểm tra trong khi người vận hành môi trường vẫn chịu trách nhiệm hoàn toàn. Nhìn chung, OSGi có thể cung cấp một trong những môi trường ứng dụng an toàn nhất vẫn còn thiếu các nền tảng điện toán được bảo vệ bằng phần cứng.
Không xâm nhập - Các ứng dụng (gói) trong môi trường OSGi được để riêng. Họ có thể sử dụng hầu như bất kỳ cơ sở nào của VM mà không cần OSGi hạn chế chúng. Cách thực hành tốt nhất trong OSGi là viết các Đối tượng Java cũ đơn giản và vì lý do này, không có giao diện đặc biệt nào được yêu cầu cho các dịch vụ OSGi, thậm chí một đối tượng Chuỗi Java có thể hoạt động như một dịch vụ OSGi. Chiến lược này làm cho mã ứng dụng dễ dàng chuyển sang môi trường khác.
Chạy mọi nơi - Vâng, điều đó phụ thuộc. Mục tiêu ban đầu của Java là chạy mọi nơi. Rõ ràng, không thể chạy tất cả mã ở mọi nơi vì khả năng của máy ảo Java khác nhau. Một VM trong điện thoại di động có thể sẽ không hỗ trợ các thư viện giống như máy tính lớn của IBM chạy ứng dụng ngân hàng. Có hai vấn đề cần quan tâm. Đầu tiên, API OSGi không nên sử dụng các lớp không có sẵn trên tất cả các môi trường. Thứ hai, một gói không nên bắt đầu nếu nó chứa mã không có sẵn trong môi trường thực thi. Cả hai vấn đề này đã được quan tâm trong thông số kỹ thuật của OSGi.
Nguồn: www.osgi.org/Tĩ/WhyOSGi