Sự khác nhau cơ bản giữa OSGi và Java EE là gì?

Question

Vì vậy, tôi đã dành một chút thời gian vào chiều nay để cuối cùng ngồi xuống và bắt đầu đọc trên "OSGi" bí ẩn và khó nắm bắt và cái gọi là bó.

OK, vì vậy tôi nghĩ Tôi hiểu. Gói "OSGi" về cơ bản là một JAR với một số thông tin kê khai bổ sung. Và, thay vì triển khai nó đến một máy chủ ứng dụng bình thường (hoặc thùng chứa khác), bạn triển khai nó đến một máy chủ OSGi như Apache Felix. Nó chạy và sau đó cung cấp dịch vụ cho người dùng/khách hàng.

Điều này khác gì so với EAR bình thường được triển khai cho máy chủ ứng dụng ???

OSGi dường như đang tăng lên (tôi tiếp tục chạy vào nó!), Nhưng đối với cuộc sống của tôi, tôi không hiểu nó cung cấp những gì bạn có thể làm với doanh nghiệp thực máy chủ như GlassFish hoặc Spring.

Tôi biết thế giới đã không phát điên, vì vậy tôi rõ ràng là thiếu cái gì đó. Chỉ cần không thể tìm ra cái gì. Cảm ơn sự giúp đỡ hoặc thông tin chi tiết!

Answer 1

Gói OSGi là phần mềm "mô-đun phần mềm" nhiều hơn tệp "jar", "chiến tranh" hoặc "tai". Gói OSGi hiếm khi cung cấp lợi ích nếu chúng đóng gói toàn bộ ứng dụng; tuy nhiên, chúng rất có lợi trong việc tự động hóa và xử lý chính xác việc kết nối nhiều thư viện.

Vì vậy, hãy xem xét vấn đề OSGi đã cố gắng giải quyết và bạn sẽ hiểu rõ hơn về nơi nó phù hợp. Nó tương đương với Java của mẫu "thừa kế kim cương" từ C++. Bạn bao gồm hai thư viện, mỗi thư viện cần một thư viện ghi nhật ký phổ biến, nhưng trong trường hợp này, nó không phải do đa thừa kế, vì nó có nhiều câu lệnh include.

Nếu cả hai thư viện đều hoạt động với cùng một phiên bản của thư viện ghi nhật ký chung, bạn sẽ gặp may. Nếu không, thì để mỗi thư viện hoạt động độc lập một cách chính xác, bạn cần tải hai bản sao của cùng một thư viện, mỗi thư viện có khả năng sử dụng cùng một không gian tên (và thường là cùng một tên lớp).

OSGi là một phương tiện đi kèm cho phép hai phiên bản của cùng một thư viện được tải, sử dụng cùng một không gian tên, cùng tên lớp, nhưng được tạo vào các thời điểm khác nhau. Nó cũng kết nối phiên bản "đúng" với gói OSGi "đúng", ngăn không cho gói sử dụng bản phát hành "sai" của thư viện "đúng".

Java EE thực hiện rất nhiều, nhưng đây không phải là điều mà Java EE thậm chí còn đề cập đến. Tốt nhất, dự án Jigsaw đang làm việc trên cùng một vấn đề. Trường hợp sự nhầm lẫn Java EE/OSGi đi vào hoạt động là hầu hết những người chấp nhận sớm gói OSGi là những người đã triển khai chức năng tương tự như một số thư viện được cung cấp trong Java EE. Điều đó nói rằng, khung công tác kết nối container thực tế (OSGi) không có gì liên quan đến chức năng đi kèm (mặc dù một số phát hiện đã được sửa đổi về mặt cấu trúc để tuân thủ các yêu cầu của gói OSGi).

Answer 2

Hầu hết các lợi ích chính, ít nhất là lý do chúng tôi sử dụng OSGi, được liệt kê tại http://karaf.apache.org/, đặc biệt là hai trường hợp đầu tiên.

Ngoài ra, liên minh OSGi có một danh sách dài các lợi ích: https://www.osgi.org/developer/benefits-of-using-osgi/.

Answer 3

So sánh Java EE với OSGi giống như so sánh táo và cam với phần thưởng bổ sung không biết cái gì là gì.

Java EE tập trung vào các ứng dụng kinh doanh đa cấp có thể mở rộng trong môi trường không đồng nhất và tích hợp nhiều hệ thống thông tin của doanh nghiệp.

OSGi bắt đầu ở một góc khác bằng cách tích hợp một số mã độc lập vào một JVM (vui lòng giải thích cho tôi là cực kỳ ngắn gọn).

Tất nhiên một số vấn đề (ví dụ: triển khai nóng) phổ biến cho cả hai môi trường - nhưng ở mức độ khác nhau.

Tất nhiên bạn có thể nâng cấp, hạ cấp và lai giữa cả hai và họ sẽ gặp ở đâu đó ở giữa.

Vì vậy, câu hỏi không nên là "Lợi ích nào có A trên B" nhưng giống như "Trong trường A nào có lợi thế rõ ràng so với B và ngược lại?" Hãy để tôi nói lại rằng: "Khi nào tôi cần một cái búa và khi nào tôi cần một cái cưa?"

Answer 4

Tôi xin lỗi nhưng TẤT CẢ các câu trả lời ở đây đều hoàn toàn buồn cười. Các vấn đề phiên bản phụ thuộc được giải quyết với OSGi? Pooooohlease .... Bao giờ nghe nói về các chính sách của trình nạp lớp trong các máy chủ ứng dụng?

OSGi có vẻ như một ý tưởng để tiếp tục bán sách mới và đào tạo, trong khi các nhu cầu chức năng đã được đề cập đến eons bằng cách triển khai JAR/EAR & triển khai trong JEE. Những người mua vào nó chỉ đơn giản là không bao giờ hiểu cách họ đang bị thao túng. Ngoài ra còn có một câu hỏi về xu hướng và thời trang. I E. những cân nhắc phi kỹ thuật là một điều đáng tiếc đối với ngành công nghiệp này.

Tái phát minh ra bánh xe có lợi nhuận vì có hàng tấn kẻ ngu trên đó. Thật không may, có rất nhiều loại đơn giản về quản lý, những người muốn ở trên “khía cạnh chảy máu của công nghệ”, người sẽ sẵn lòng tài trợ cho các khóa học của nhân viên, hấp thụ đường cong học tập, và sau đó trả tiền bằng cách "tái kỹ thuật" không có gì sai với họ để bắt đầu.

Đó không phải là câu hỏi "Tôi có sử dụng tuốc nơ vít của búa hay không". Đó là một câu hỏi của "hey ông chủ, có điều mới này ra khỏi đó được gọi là HEMMAR, và nó thực sự mát mẻ!". "Nó không phải là một HAMMER?", "Không không, nó waaaaay tốt hơn, đó là một HEMMAR, nó cho lái xe đinh vào bảng, nó sẽ cách mạng hóa thế giới".