Comments on: OSGi from Here to There http://www.nagarro.com/blog/osgi-from-here-to-there/ Nagarro blog: software development, design, architecture and usability Fri, 23 Dec 2011 18:21:47 -0800 http://wordpress.org/?v=2.8.4 hourly 1 By: Open Service Gateway Initiative (OSGI) | nova prima saputra web http://www.nagarro.com/blog/osgi-from-here-to-there/comment-page-1/#comment-520 Open Service Gateway Initiative (OSGI) | nova prima saputra web Tue, 02 Mar 2010 20:59:36 +0000 http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-520 [...] Perkembangan OSGI [...] [...] Perkembangan OSGI [...]

]]> By: OSGI (Open Service Gateway Initiative) | Komunitas Pelajar Indonesia http://www.nagarro.com/blog/osgi-from-here-to-there/comment-page-1/#comment-437 OSGI (Open Service Gateway Initiative) | Komunitas Pelajar Indonesia Wed, 18 Nov 2009 09:13:30 +0000 http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-437 [...] Perkembangan OSGI [...] [...] Perkembangan OSGI [...]

]]> By: Marco http://www.nagarro.com/blog/osgi-from-here-to-there/comment-page-1/#comment-191 Marco Mon, 31 Mar 2008 09:54:21 +0000 http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-191 Thanks for answering, Bill. In the meanwhile I think I better understand the philosophy of OSGi. I think it is important to see most of an application constructed via bundles. That means: Keep the runtime classpath as small as possible. If I have a classical framework functionality, I should try to provide it via services. And even if I just need superclasses for implementing new functionality, I should provide those superclasses via bundles that export the relevant packages. OSGi supports the fact that not all bundles have to register services. So why not a type of bundle which just export some classes? Seems fine to me. Thanks for answering, Bill. In the meanwhile I think I better understand the philosophy of OSGi. I think it is important to see most of an application constructed via bundles. That means: Keep the runtime classpath as small as possible. If I have a classical framework functionality, I should try to provide it via services. And even if I just need superclasses for implementing new functionality, I should provide those superclasses via bundles that export the relevant packages. OSGi supports the fact that not all bundles have to register services. So why not a type of bundle which just export some classes? Seems fine to me.

]]> By: Bill Kayser http://www.nagarro.com/blog/osgi-from-here-to-there/comment-page-1/#comment-190 Bill Kayser Thu, 14 Feb 2008 06:21:39 +0000 http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-190 Good point about OSGi not being a silver bullet. To answer your question (if I understood it correctly) I would put the abstract superclass for a service implementation in the same bundle where the service interface is defined. Other bundles that implement that service will have access to the abstract superclass. I'm not sure what you mean by anchorpoints, or the distinction between using a bundle and using java imports. I think you are always doing java imports. Good point about OSGi not being a silver bullet. To answer your question (if I understood it correctly) I would put the abstract superclass for a service implementation in the same bundle where the service interface is defined. Other bundles that implement that service will have access to the abstract superclass. I’m not sure what you mean by anchorpoints, or the distinction between using a bundle and using java imports. I think you are always doing java imports.

]]> By: Marco http://www.nagarro.com/blog/osgi-from-here-to-there/comment-page-1/#comment-189 Marco Tue, 12 Feb 2008 08:51:15 +0000 http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-189 Nice field report - thanks a lot for it. I am convinced that OSGi can help to build much better structured applications, yes! But let me point out one thing: OSGi is not the prerequisite to build well structured, flexible and maintainable systems - but it helps a lot to think in the right directions. I would like to ask one architectural thing here - maybe someone can answer...? If you look at Bundles and Inheritance, how do they fit together? What I mean: You surely can't provide every functionality with a service. This would reduce our programming model to a functional one. What if almost every bundle needs functionality provided by a superclass? For example an abstract model or controller, and every bundle has some subclassed ones? Would you provide those anchorpoints in form of a bundle? Or would you use normal java lib imports? Nice field report – thanks a lot for it.
I am convinced that OSGi can help to build much better structured applications, yes! But let me point out one thing:
OSGi is not the prerequisite to build well structured, flexible and maintainable systems – but it helps a lot to think in the right directions.
I would like to ask one architectural thing here – maybe someone can answer…?
If you look at Bundles and Inheritance, how do they fit together? What I mean: You surely can’t provide every functionality with a service. This would reduce our programming model to a functional one. What if almost every bundle needs functionality provided by a superclass? For example an abstract model or controller, and every bundle has some subclassed ones? Would you provide those anchorpoints in form of a bundle? Or would you use normal java lib imports?

]]> By: Bill Kayser http://www.nagarro.com/blog/osgi-from-here-to-there/comment-page-1/#comment-188 Bill Kayser Sun, 20 Jan 2008 01:10:07 +0000 http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-188 Verifydesign sounds interesting. Validating API's at build time is a very big deal for me. The Equinox group has some interesting tools for doing that but I don't know how ready they are. We did not use servicebinder. In fact we didn't use any services only because we already had a pretty fixed application service model and there was no point in converting. It would be really nice to build an application around the services model in OSGi, but even without leveraging that it still has a lot to offer. Verifydesign sounds interesting. Validating API’s at build time is a very big deal for me. The Equinox group has some interesting tools for doing that but I don’t know how ready they are.

We did not use servicebinder. In fact we didn’t use any services only because we already had a pretty fixed application service model and there was no point in converting. It would be really nice to build an application around the services model in OSGi, but even without leveraging that it still has a lot to offer.

]]> By: Dean Hiller http://www.nagarro.com/blog/osgi-from-here-to-there/comment-page-1/#comment-187 Dean Hiller Sat, 19 Jan 2008 01:37:42 +0000 http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-187 Question, did you use the servicebinder bundle(hmmm, does that have a new name now)???? That part of osgi absolutely ROCKS...because then your services are all POJO and you don't need to use the Activator stuff at all. Question, did you use the servicebinder bundle(hmmm, does that have a new name now)???? That part of osgi absolutely ROCKS…because then your services are all POJO and you don’t need to use the Activator stuff at all.

]]> By: Dean Hiller http://www.nagarro.com/blog/osgi-from-here-to-there/comment-page-1/#comment-186 Dean Hiller Sat, 19 Jan 2008 01:31:27 +0000 http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-186 If you like osgi's api and implementations, you should try verifydesign which at compile time checks to make sure your package design matches your code and code matches the package design....it is quite nice for guaranteeing apis vs. implementations at build time so autobuilds can notify team if someone violates the design by having an impl depending on impl....ie. no need to wait until runtime to find out....also can define your design in more detail then just api and impl too. a tutorial on it is here... http://www.devx.com/opensource/Article/33729 If you like osgi’s api and implementations, you should try verifydesign which at compile time checks to make sure your package design matches your code and code matches the package design….it is quite nice for guaranteeing apis vs. implementations at build time so autobuilds can notify team if someone violates the design by having an impl depending on impl….ie. no need to wait until runtime to find out….also can define your design in more detail then just api and impl too. a tutorial on it is here…

http://www.devx.com/opensource/Article/33729

]]> By: Chris Aniszczyk http://www.nagarro.com/blog/osgi-from-here-to-there/comment-page-1/#comment-185 Chris Aniszczyk Tue, 15 Jan 2008 15:07:58 +0000 http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-185 To help with plug-in building, may I suggest pluginbuilder.org as an option. If you have any suggestions on improving PDE Build, feel free to file bugs. To help with plug-in building, may I suggest pluginbuilder.org as an option.

If you have any suggestions on improving PDE Build, feel free to file bugs.

]]> By: Bill Kayser http://www.nagarro.com/blog/osgi-from-here-to-there/comment-page-1/#comment-184 Bill Kayser Tue, 15 Jan 2008 06:37:06 +0000 http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-184 I can't say enough about the Plug-in Development Environment (PDE). Building applications out of bundles wouldn't mean near as much if you had to write thousands of lines of ant code to compile everything, or if you discovered all the dependency problems only after the OSGi runtime tries wiring everything up. The PDE does all this incredible work to enforce the constraints defined in the OSGi manifests. This means that when you configure the dependencies of a bundle, the packages it exports and imports, the Java version it requires, and any other OSGi properties, Eclipse will ensure that everyone is playing by those rules. On top of that it has the mechanics to package bundles up as jar files, doing the compilation, building the libraries, placing them in the correct location and setting the internal classpath accordingly. And perhaps most importantly, the platform includes headless build support, so that all of this can be done outside of the IDE. When you consider everything that has to be taken into account when assembling a product out of bundles, it's nothing short of a miracle that it even works. I won't say the PDE build is pretty, and it certainly isn't fast. It did take me a long time to figure out how to set it up properly, but the most important thing is that the configuration, when you get it right, turns out to be a very small artifact to manage for a product--typically a boilerplate property file with just a few modifications. Everything is driven off of the manifest, feature and product definitions for which the PDE supplies really outstanding GUI tools. I can’t say enough about the Plug-in Development Environment (PDE). Building applications out of bundles wouldn’t mean near as much if you had to write thousands of lines of ant code to compile everything, or if you discovered all the dependency problems only after the OSGi runtime tries wiring everything up.

The PDE does all this incredible work to enforce the constraints defined in the OSGi manifests. This means that when you configure the dependencies of a bundle, the packages it exports and imports, the Java version it requires, and any other OSGi properties, Eclipse will ensure that everyone is playing by those rules.

On top of that it has the mechanics to package bundles up as jar files, doing the compilation, building the libraries, placing them in the correct location and setting the internal classpath accordingly.

And perhaps most importantly, the platform includes headless build support, so that all of this can be done outside of the IDE. When you consider everything that has to be taken into account when assembling a product out of bundles, it’s nothing short of a miracle that it even works.

I won’t say the PDE build is pretty, and it certainly isn’t fast. It did take me a long time to figure out how to set it up properly, but the most important thing is that the configuration, when you get it right, turns out to be a very small artifact to manage for a product–typically a boilerplate property file with just a few modifications. Everything is driven off of the manifest, feature and product definitions for which the PDE supplies really outstanding GUI tools.

]]> By: Chris Aniszczyk http://www.nagarro.com/blog/osgi-from-here-to-there/comment-page-1/#comment-183 Chris Aniszczyk Mon, 14 Jan 2008 23:07:27 +0000 http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-183 How about a shout-out for the wonderful PDE tooling that exists for that wonderful OSGi runtime known as Equinox :)? How about a shout-out for the wonderful PDE tooling that exists for that wonderful OSGi runtime known as Equinox :) ?

]]> By: A story of migrating a Java application to Equinox and OSGi « Ian Skerrett http://www.nagarro.com/blog/osgi-from-here-to-there/comment-page-1/#comment-182 A story of migrating a Java application to Equinox and OSGi « Ian Skerrett Mon, 14 Jan 2008 20:15:20 +0000 http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-182 [...] story of migrating a Java application to Equinox and OSGi Bill Kayser has written an interesting summary of his experience migrating a 600,000 line multi-tier swing based application to run on Equinox. He begins the story with a [...] [...] story of migrating a Java application to Equinox and OSGi Bill Kayser has written an interesting summary of his experience migrating a 600,000 line multi-tier swing based application to run on Equinox. He begins the story with a [...]

]]>