Simon Zambrovski » Simon Zambrovski | Tags : framework http://simon.zambrovski.org "One Cannot Not Communicate" - Watzlawick Tue, 15 Nov 2011 00:15:02 +0000 en hourly 1 http://wordpress.org/?v=3.1.4 Eclipse Common Navigator Framework http://simon.zambrovski.org/2009/04/eclipse-common-navigator-framework/ http://simon.zambrovski.org/2009/04/eclipse-common-navigator-framework/#comments Thu, 30 Apr 2009 04:45:21 +0000 Simon http://simon.zambrovski.org/?p=193 Michael “Mike” L. Baird, http://bairdphotos.com/
Just finished to correct mistakes (thanks to Francis) in the article I posted about the usage of the Common Navigator Framework (CNF). In doing so the article incorporates the information already covered in different blogs, but also focuses on the specific use case of providing a view of data structure completely unrelated to the Eclipse platform resources. So the aim is not to add some content to the “Project Explorer” which is an example of resource-oriented CNF usage, but to provide a view on a completely own data model. This post fostered some communication with Francis regarding the CNF documentation provided in Eclipse, so I’m happy if my contributions can be valuable. As usual, this kind of content goes to TechJava….

]]> http://simon.zambrovski.org/2009/04/eclipse-common-navigator-framework/feed/ 0 OSGi: Why Modularity is Important. http://simon.zambrovski.org/2008/09/osgi-why-modularity-is-important/ http://simon.zambrovski.org/2008/09/osgi-why-modularity-is-important/#comments Wed, 10 Sep 2008 10:21:11 +0000 Simon http://simon.zambrovski.org/2008/09/osgi-why-modularity-is-important/ OSGi1OSGi2OSGi3

Yesterday, the OSGi session took place in Hotel East in Hamburg. Peter Kriens, the OSGi evangelist showed a wonderful Zen Presentation on OSGi. I wrote a lot during his talk which happens to me very seldom. Here are the core statements I understood:

  • The core difference between usual plugin architectures and OSGi is that OSGi concentrates on collaboration of the components.
  • OSGi delivers a controlled environment, in which the question if a component runs or not can be answered in beforehand.
  • OSGi bundles use metadata (about versions, dependencies, etc) to predict an error, not discover it in runtime.
  • OSGi has a very narrow API containing the minimal common part.
  • OSGi consists of module, life cycle and services layers. The initially developed services layer required smart class loading mechanisms (module layer).
  1. The module layer is desigend to control the class loading machanisms (e.G. structureal class loader hierarchies instead of a linear classpath)
  2. Life cycle layer adds a management API (e.G. inform the others about installation event)
  3. Separation of concerns is promoted by definition of services for different tasks.
  • Services are used for decoupling of system parts (This is a standard application of service-orientation).
  • OSGI makes dependencies explicit (private, import, export)
  • OSGI tries to make the system managable, taking dynamics and lifecycle as fisrst-class citizens
  • OSGI will be extended to support distribution: the team works on policies, SLAs, etc…

I liked the talk and the way how Peter Kriens addressed the problems of OO in big systems. I was confirmed in some ideas about coupling that will be layed out in my thesis. After the presentation we had a delicious meal and wraped up the evening with interesting discussion about pros and contras of OSGi. Peter Friese showed me some remote OSGi staff, he was playing with. The lack of documentation in this area makes it a little difficult, but I hope he will post some news on it. As usual, you can find other pictures in my FlickR gallery.

]]> http://simon.zambrovski.org/2008/09/osgi-why-modularity-is-important/feed/ 0