2010-01-29 37 views
27

Tôi thấy rất nhiều bài thuyết trình trên OSGi và tôi nghĩ rằng nó có vẻ đầy hứa hẹn để thực thi mô đun hóa tốt hơn. Rõ ràng là "hotdeployment" và "chạy các phiên bản khác nhau của x song song" cũng là điểm bán của thị trưởng.OSGi có thể giúp giảm độ phức tạp?

Tôi tự hỏi liệu những gì OSGi hứa hẹn sẽ giải quyết thậm chí là một vấn đề ...? Nó nhắc tôi nhớ về những ngày đầu của OO khi những tuyên bố tương tự là người giúp việc:

Khi OO là mới, đối số lớn là khả năng sử dụng lại. Nó đã được tuyên bố rộng rãi rằng khi sử dụng OO, người ta sẽ chỉ phải "viết một lần" và sau đó có thể "sử dụng ở khắp mọi nơi".

Trong thực tế, tôi chỉ thấy điều này làm việc cho một số ví dụ cấp độ khá thấp. Tôi nghĩ rằng lý do cho điều này là viết mã tái sử dụng là khó khăn. Không phải về mặt kỹ thuật mà là từ quan điểm thiết kế giao diện. Bạn phải dự đoán làm thế nào các khách hàng tương lai sẽ muốn sử dụng các lớp học của bạn và có những lựa chọn đúng ở phía trước. Điều này là khó bởi định nghĩa và do đó lợi ích tái sử dụng tiềm năng thường không thể cung cấp.

Với OSGi, tôi có nghi ngờ rằng ở đây chúng tôi có thể rơi vào lời hứa, giải pháp tiềm năng cho các sự cố mà chúng tôi không thực sự có. Hoặc nếu chúng tôi có chúng, chúng tôi không có chúng đủ số lượng và mức độ nghiêm trọng có thể biện minh để mua vào OSGi để được trợ giúp. "Hotdeployment" ví dụ về một tập hợp con các mô-đun chắc chắn là một ý tưởng tuyệt vời, nhưng tần suất thực hiện thực sự là có hoạt động không? Làm thế nào thường không phải vì nó bật ra bạn đã nhận mô-đun hóa sai cho vấn đề cụ thể? Làm thế nào về các thực thể mô hình được chia sẻ giữa nhiều mô-đun? Tất cả các mô-đun này có phải được thay đổi cùng một lúc không? Hoặc bạn làm phẳng các đối tượng của bạn để nguyên thủy và chỉ sử dụng các đối tượng trong giao tiếp giữa các mô-đun, để có thể giữ các giao diện giao diện?

Vấn đề khó khăn nhất khi áp dụng OSGi là, tôi sẽ đoán, để có được những mô-đun hóa "quyền". Tương tự như việc nhận các giao diện của các lớp của bạn ngay trong OO, với OSGi, vấn đề vẫn giữ nguyên, trên một quy mô lớn hơn lần này, gói hoặc thậm chí mức dịch vụ.

Như bạn có thể đã đoán, tôi hiện đang cố gắng đánh giá OSGi để sử dụng trong một dự án. Vấn đề chính của chúng tôi là tăng độ phức tạp khi codebase phát triển và tôi muốn phá vỡ hệ thống trong các mô-đun nhỏ hơn có tương tác ít được xác định hơn.

  • Với khung không bao giờ có thể giúp quyết định những gì thành mô đun hóa, OSGi có bao giờ thanh toán cho bạn không?
  • Làm cho cuộc sống của bạn dễ dàng hơn khi làm việc theo nhóm?
  • Có giúp giảm số lượng lỗi không?
  • Bạn đã bao giờ thành công "hotdeploy" các thành phần chính?
  • OSGi có giúp giảm sự phức tạp theo thời gian không?
  • OSGi có giữ lời hứa của mình không?
  • Điều đó có đáp ứng được kỳ vọng của bạn không?

Cảm ơn!

+0

OSGi trông giống như một khuôn khổ cải trang đối với tôi. – Anurag

+2

Hãy làm cho cộng đồng wiki này. – bmargulies

Trả lời

20

OSGi trả tiền bởi vì nó thực thi mô đun hóa trong thời gian chạy, một cái gì đó bạn trước đây không có, thường gây ra thiết kế trên giấy và việc triển khai trôi dạt. Đây có thể là một chiến thắng lớn trong quá trình phát triển.

Nó chắc chắn sẽ giúp làm việc theo nhóm dễ dàng hơn, nếu bạn để các nhóm tập trung vào một mô-đun duy nhất (có thể là một tập hợp các gói) và nếu bạn có được quyền mô-đun hóa của mình. Người ta có thể tranh luận rằng người ta có thể làm điều tương tự với công cụ xây dựng như Ant + Ivy hoặc Maven và phụ thuộc, mức độ chi tiết của các phụ thuộc mà OSGi sử dụng là theo ý kiến ​​của tôi cao hơn nhiều, không gây ra "kéo tất cả mọi thứ cùng với bồn rửa nhà bếp" rằng phụ thuộc cấp JAR gây ra.

Mã mô-đun với ít phụ thuộc hơn có xu hướng dẫn đến mã sạch hơn và ít hơn, dẫn đến ít lỗi dễ kiểm tra và giải quyết hơn.Nó cũng khuyến khích các thành phần thiết kế đơn giản và dễ hiểu nhất có thể, đồng thời có tùy chọn để cắm vào các triển khai phức tạp hơn hoặc thêm các khía cạnh như bộ nhớ đệm làm các thành phần riêng biệt.

Triển khai nóng, ngay cả khi bạn không sử dụng nó trong thời gian chạy, là một thử nghiệm rất tốt để xác thực nếu bạn đã mô đun hóa ứng dụng của mình một cách chính xác. Nếu bạn không thể bắt đầu các gói của mình theo thứ tự ngẫu nhiên, bạn nên điều tra lý do tại sao. Ngoài ra, nó có thể làm cho chu kỳ phát triển của bạn nhanh hơn rất nhiều nếu bạn có thể cập nhật một gói tùy ý.

Miễn là bạn có thể quản lý các mô-đun và phụ thuộc của bạn, các dự án lớn vẫn có thể quản lý và có thể dễ dàng tiến hóa (tiết kiệm cho bạn khỏi "viết lại hoàn toàn" xấu).

Nhược điểm của OSGi? Đó là một khuôn khổ cấp rất thấp, và trong khi nó giải quyết các vấn đề nó được dự định khá tốt, có những thứ mà bạn vẫn cần phải giải quyết chính mình. Đặc biệt là nếu bạn đến từ môi trường Java EE, nơi bạn nhận được an toàn thread miễn phí và một số khái niệm khác có thể khá hữu ích nếu bạn cần chúng, bạn cần tự mình đưa ra các giải pháp cho OSGi.

Một lỗ hổng phổ biến là không sử dụng abstractions trên đỉnh OSGi để làm cho điều này dễ dàng hơn cho nhà phát triển trung bình. Đừng bao giờ để chúng lộn xộn với ServiceListeners hoặc ServiceTrackers bằng tay. Cẩn thận xem xét những bó nào và không được phép thực hiện: Bạn có sẵn sàng cấp cho nhà phát triển quyền truy cập vào BundleContext hay bạn ẩn tất cả những thứ này khỏi chúng bằng cách sử dụng một số dạng mô hình khai báo.

+0

+1 cho trải nghiệm chiến đấu. –

+2

Tại sao có sự thiếu hụt trong kiến ​​thức OSGi về SO? Bạn dường như là một trong số ít người ở đây có đủ câu trả lời cho các câu hỏi liên quan đến OSGi. – javamonkey79

+0

Cảm ơn các bạn đã từ. Có khá nhiều nhà phát triển OSGi có kinh nghiệm ở đây, nhưng tôi đồng ý có lẽ sẽ còn nhiều hơn nữa. Tuy nhiên, hãy lưu ý các câu hỏi, SO là một trang web tuyệt vời để tìm và tìm câu trả lời! –

8

Tôi đã làm việc với OSGi trong vài năm nay (mặc dù trong ngữ cảnh của dự án nhật thực, không phải trong dự án web). Rõ ràng là khuôn khổ không giải phóng bạn khỏi suy nghĩ làm thế nào để mô đun hóa.Nhưng nó cho phép bạn xác định các quy tắc.

Nếu bạn sử dụng các gói và định nghĩa (Trong tài liệu thiết kế? Verbal?) Các gói nhất định có thể không truy cập vào các lớp trong các gói khác, mà không thực thi ràng buộc này, nó sẽ bị hỏng. Nếu bạn thuê nhà phát triển mới, họ không biết quy tắc. Họ S break phá vỡ các quy tắc. Với OSGi, bạn có thể xác định các quy tắc trong mã. Đối với chúng tôi đây là một chiến thắng lớn, vì nó đã giúp chúng tôi duy trì kiến ​​trúc của hệ thống của chúng tôi.

OSGi không làm giảm độ phức tạp. Nhưng nó chắc chắn sẽ giúp xử lý nó.

3

Tôi đã sử dụng OSGI trong một dự án (tôi thừa nhận - không phải rất nhiều). Nó cung cấp những lời hứa tốt, nhưng như @Arne đã nói, bạn vẫn cần phải suy nghĩ về cách của bạn về cách bạn mô-đun hóa.

OSGI đã làm giúp dự án của chúng tôi vì nó làm cho kiến ​​trúc ổn định hơn. Phá vỡ mô đun hóa là "khó khăn" hơn, vì vậy các quyết định mà chúng tôi đưa ra về cách mô đun hóa mô-đun vẫn còn hiệu lực trong một thời gian dài hơn.
Để đặt nó khác nhau - không có OSGI và dưới áp lực thời gian để phân phối, đôi khi bạn hoặc thành viên trong nhóm của bạn thỏa hiệp, lối tắt và các hack khác và mục đích ban đầu của kiến ​​trúc bị mất.

Vì vậy, OSGI đã không làm giảm độ phức tạp, nhưng nó bảo vệ nó khỏi phát triển không cần thiết theo thời gian. Tôi đoán đó là một điều tốt :)

Tôi chưa sử dụng tính năng triển khai nóng, vì vậy tôi không thể nhận xét về điều đó.

Để trả lời điểm cuối cùng của bạn, nó đáp ứng được kỳ vọng của tôi, nhưng nó đòi hỏi một đường cong học tập và một số thích nghi, và tiền thưởng chỉ dành cho dài hạn.

(như một mặt lưu ý, câu hỏi của bạn làm tôi nhớ một chút về câu ngạn ngữ rằng "maven là AWT hợp đồng xây dựng hệ thống")

+0

Tôi không nghe nói về "maven là awt của các hệ thống xây dựng" nói trước đây, và không thể định vị nó với Google. Bạn có một liên kết? –

+0

Từ liên kết này: http://prezi.com/ngwwf1wcfn7n/your-next-sucessful-build/ ... văn bản ngay bên dưới bản trình bày: "Sử dụng Maven2 để xây dựng các công cụ giống như AWT cho các khung công tác UI: mang tính cách mạng, nhưng không không có nhược điểm. " – Yoni

4

Tôi đang sử dụng OSGi cho hơn 8 năm nay, và mỗi khi tôi lặn trong một dự án không thuộc hệ điều hành OSGI, tôi có cảm giác quá tốc độ mà không cần dây an toàn. OSGI làm cho việc thiết lập và triển khai dự án trở nên khó khăn hơn và buộc bạn phải suy nghĩ về mô đun hóa trả trước, nhưng mang lại cho bạn sự dễ dàng trong việc thực thi các quy tắc khi chạy. Lấy con lạc đà apache maven làm ví dụ. Khi bạn tạo một dự án maven mới và thêm lạc đà apache như là một phụ thuộc, các ứng dụng dường như có tất cả các phụ thuộc của nó, và bạn sẽ chỉ nhận thấy các ClassNotFoundExceptions khi chạy, điều đó là xấu. Khi bạn chạy trong một thùng chứa OSGI và tải các mô-đun lạc đà apache, các mô-đun với các phụ thuộc chưa được đáp ứng không được bắt đầu và bạn biết trước vấn đề là gì.

Tôi cũng sử dụng triển khai nóng mọi lúc và cập nhật các phần của ứng dụng của mình mà không cần phải khởi động lại.

2

OSGi KHÔNG trả hết. Thực tế là OSGi không dễ sử dụng và vào cuối ngày hoặc năm tùy thuộc vào thời gian bạn mất để có được những thứ làm việc, nó không thêm giá trị:

  • Ứng dụng của bạn sẽ không có nhiều mô đun tổng thể hơn , ngược lại, nó kết thúc được tiếp xúc nhiều hơn và không bị cô lập từ các ứng dụng khác vì nó là một chia sẻ tất cả mọi thứ thay vì chia sẻ không có gì vòm.
  • Phiên bản được đẩy xa hơn xuống ngăn xếp, bạn vật lộn với phụ thuộc maven transitive chỉ để làm điều đó một lần nữa khi chạy trong OSGI.
  • Hầu hết các thư viện được thiết kế để hoạt động như thư viện trong trình nạp lớp ứng dụng không phải là gói với trình nạp lớp của riêng chúng.
  • Có thể thích hợp cho các kiến ​​trúc plugin, nơi các nhà phát triển bên thứ ba cần phải được sandbox hoặc có thể nó chỉ là EJB2.0 trên một lần nữa.

Tôi đã thêm các trang trình bày sau và tôi sẽ theo dõi mã ví dụ để minh họa cách làm việc thành công với OSGi nếu nó bị ép buộc bạn. http://www.slideshare.net/ielian/tdd-on-osgi

+0

Chào mừng bạn đến với [so].Bạn có thể muốn mở rộng câu trả lời của bạn, chẳng hạn như tại sao OSGi khó sử dụng và liệu OSGi có bất kỳ lợi ích nào không. Bạn có thể muốn xem [answer], cung cấp các gợi ý hữu ích về cách viết các câu trả lời tuyệt vời. –

+0

Cảm ơn nhận xét của bạn. Tôi hy vọng các trang trình bày tôi đã bao gồm trợ giúp với điều đó. – eliani

+0

"chia sẻ mọi thứ thay vì chia sẻ không có gì." -> Hệ thống con OSGi. "Phiên bản được đẩy xa hơn ngăn xếp, bạn vật lộn với phụ thuộc maven transitive chỉ để làm điều đó một lần nữa trong thời gian chạy trong OSGI." -> nó thực sự giải quyết rất nhiều vấn đề liên quan đến phụ thuộc transitive, khi có một phiên bản va chạm. "Hầu hết các thư viện được thiết kế để hoạt động như thư viện trong trình nạp lớp ứng dụng không phải là gói" -> chỉ có rất ít thư viện có vấn đề thực tế đang được sử dụng trong môi trường OSGi (hibernate, lần trước tôi kiểm tra, là ví dụ tốt nhất) – santiagozky

-1

Không, OSGI sẽ sớm đưa bạn đến màu xám.

+2

Điều này không cung cấp một câu trả lời cho câu hỏi. Để phê bình hoặc yêu cầu làm rõ từ tác giả, hãy để lại nhận xét bên dưới bài đăng của họ. –

+0

Vậy thì sao? Với khung không bao giờ có thể giúp quyết định những gì để modularize, có OSGi bao giờ trả tiền cho bạn? no Làm cho cuộc sống của bạn dễ dàng hơn khi làm việc theo nhóm? no Có giúp giảm số lượng lỗi không? no Bạn đã bao giờ thành công "hotdeploy" các thành phần chính? no OSGi có giúp giảm sự phức tạp theo thời gian không? no OSGi có giữ lời hứa của mình không? no Nó có đáp ứng được kỳ vọng của bạn không? không có – Jeb

+0

Thừa nhận một thực tế rằng bình luận cuối cùng của Jeb @ đầy những lời chỉ trích đôi khi không cần thiết tôi có thể liệt kê nhiều trường hợp từ kinh nghiệm của tôi chứng minh rằng anh ấy đúng. Ngoài ra, nhiều khung chính bị bỏ rơi hỗ trợ của OSGI, sử dụng libs của bên thứ ba trở thành một vấn đề thực sự ngay cả với thời gian chạy gói đến các gói, được cung cấp bởi ví dụ của Apache Karaf. Một trích dẫn từ một người đàn ông thông minh mô tả chính xác nhiều năm kinh nghiệm của tôi với OSGI - "Nghe hay, không hoạt động". – Yuriy

Các vấn đề liên quan