Comments for Of Programming and Architecture http://blogs.nagarro.net/kayser Sun, 06 Jul 2008 01:29:10 +0000 http://wordpress.org/?v=2.3 Comment on OSGi from Here to There by Marco http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-66 Marco Mon, 31 Mar 2008 09:54:21 +0000 http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-66 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.

]]> Comment on OSGi from Here to There, Part II by People Over Process » links for 2008-02-16 http://blogs.nagarro.net/kayser/osgi-from-here-to-there-part-ii/#comment-62 People Over Process » links for 2008-02-16 Sat, 16 Feb 2008 07:18:54 +0000 http://blogs.nagarro.net/kayser/osgi-from-here-to-there-part-ii/#comment-62 [...] OSGi from Here to There, Part II “OSGi now managed all of the issues we were trying to solve with classloaders.” (tags: OSGi classloaders java programming equinix) [...] […] OSGi from Here to There, Part II “OSGi now managed all of the issues we were trying to solve with classloaders.” (tags: OSGi classloaders java programming equinix) […]

]]> Comment on OSGi from Here to There by Bill Kayser http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-53 Bill Kayser Thu, 14 Feb 2008 06:21:39 +0000 http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-53 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.

]]> Comment on SOA in a JVM by CalArch http://blogs.nagarro.net/kayser/soa-in-a-jvm/#comment-49 CalArch Wed, 13 Feb 2008 11:17:19 +0000 http://blogs.nagarro.net/kayser/soa-in-a-jvm/#comment-49 Love the blog, if i may ask, what software are you using? how much does it cost? where do you get it? If it's not a secret email me some details wouldya? thanks in advance! Love the blog, if i may ask, what software are you using? how much does it cost? where do you get it? If it’s not a secret email me some details wouldya?

thanks in advance!

]]> Comment on OSGi from Here to There by Marco http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-47 Marco Tue, 12 Feb 2008 08:51:15 +0000 http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-47 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?

]]> Comment on SOA in a JVM by links for 2008-01-26 http://blogs.nagarro.net/kayser/soa-in-a-jvm/#comment-42 links for 2008-01-26 Sat, 26 Jan 2008 08:25:43 +0000 http://blogs.nagarro.net/kayser/soa-in-a-jvm/#comment-42 [...] Of Programming and Architecture » Blog Archive » SOA in a JVM There has never really much debate about whether Service Oriented Architecture is a good idea or not. Based on principles such as loose coupling, encapsulation, location transparency, and the separation of infrastructure and applications, it has always ha (tags: architecture article build dependencies design equinox java osgi patterns programming software toread SOA) [...] […] Of Programming and Architecture » Blog Archive » SOA in a JVM There has never really much debate about whether Service Oriented Architecture is a good idea or not. Based on principles such as loose coupling, encapsulation, location transparency, and the separation of infrastructure and applications, it has always ha (tags: architecture article build dependencies design equinox java osgi patterns programming software toread SOA) […]

]]> Comment on SOA in a JVM by Peter Kriens http://blogs.nagarro.net/kayser/soa-in-a-jvm/#comment-41 Peter Kriens Tue, 22 Jan 2008 07:09:26 +0000 http://blogs.nagarro.net/kayser/soa-in-a-jvm/#comment-41 > ... and not relying too much on the services part. The services part is where you actually gain most in the decoupling ... :-) Nice article! Kind regards, Peter Kriens > … and not relying too much on the services part.
The services part is where you actually gain most in the decoupling … :-)

Nice article! Kind regards,

Peter Kriens

]]> Comment on OSGi from Here to There by Bill Kayser http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-40 Bill Kayser Sun, 20 Jan 2008 01:10:07 +0000 http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-40 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.

]]> Comment on OSGi from Here to There by Dean Hiller http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-39 Dean Hiller Sat, 19 Jan 2008 01:37:42 +0000 http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-39 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.

]]> Comment on OSGi from Here to There by Dean Hiller http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-38 Dean Hiller Sat, 19 Jan 2008 01:31:27 +0000 http://blogs.nagarro.net/kayser/osgi-from-here-to-there/#comment-38 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

]]>