<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Olaf&#039;s blog &#187; OSGI</title>
	<atom:link href="http://olafsblog.sysbsb.de/category/osgi/feed/" rel="self" type="application/rss+xml" />
	<link>http://olafsblog.sysbsb.de</link>
	<description>Olaf&#039;s blog on software development and life</description>
	<lastBuildDate>Thu, 18 Nov 2010 07:57:20 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Modular development with OSGI about to be very, very popular &#8211; finally.</title>
		<link>http://olafsblog.sysbsb.de/modular-development-with-osgi-about-to-be-very-very-popular-finally/</link>
		<comments>http://olafsblog.sysbsb.de/modular-development-with-osgi-about-to-be-very-very-popular-finally/#comments</comments>
		<pubDate>Mon, 02 Mar 2009 11:40:32 +0000</pubDate>
		<dc:creator>olaf</dc:creator>
				<category><![CDATA[J2EE]]></category>
		<category><![CDATA[JPA]]></category>
		<category><![CDATA[OSGI]]></category>
		<category><![CDATA[System architecture]]></category>
		<category><![CDATA[eclipselink]]></category>
		<category><![CDATA[java]]></category>
		<category><![CDATA[open source]]></category>
		<category><![CDATA[spring]]></category>

		<guid isPermaLink="false">http://olafsblog.sysbsb.de/?p=72</guid>
		<description><![CDATA[It&#8217;s quite exciting to see the tremendous progress in development tools, patterns, frameworks and libraries since the release of JAVA 1.0 in 1996.
Within just thirteen years, development improved from the first applets, from the dark ages of the first EJB standardization attempts and a lack of suitable development processes into an age where aspect oriented [...]]]></description>
			<content:encoded><![CDATA[<p>It&#8217;s quite exciting to see the tremendous progress in development tools, patterns, frameworks and libraries since the release of JAVA 1.0 in 1996.<br />
Within just thirteen years, development improved from the first applets, from the dark ages of the first EJB standardization attempts and a lack of suitable development processes into an age where aspect oriented programming, dependency injection and a freely available range of lightweight yet extremely powerful frameworks, libraries and API&#8217;s finally permitted the humble programmer to do what he always wanted to do &#8211; analyze problems, and elegantly write them down without spending all of his precious time on the syntax.</p>
<p>I would even go as far as saying that there was no object orientation before programming crosscutting concerns and using dependency injection became established mechanisms.<br />
Think about it: The original goal of OO is not to use inheritance, encapsulation, identity and polymorphism, but to express the <em>real world of things</em> &#8211; our reality &#8211; using an <em>abstract world of things</em>, while preserving most of the properties and relationships we observe in reality. </p>
<p>Before AOP, before being able to separate the description of things from creating, configurating and connecting concrete instances through dependency injection frameworks, this goal was hard to achieve.</p>
<h3>Modules larger than classes with OSGI</h3>
<p>Now however, we are about to reach a new stage in development of object orientation in JAVA: Developing modules that are <em>larger than classes</em>, modules which can, once properly identified, be developed independently using all the wonderful technology described beforehand. The technology used to achieve this has a name: <a href="http://en.wikipedia.org/wiki/OSGi">OSGI</a>. This technology has quite a long history of development, but a certain lack of elegance and light-weightiness barred this component model from becoming a real hit in the worldwide development community. This is about to change.<br />
<span id="more-72"></span></p>
<h3>Impact of OSGI on the development process</h3>
<p>Let me stress out here how important it is to be able to develop, manage and deploy such modules. The larger your system, the more developers your project involves, the longer you maintain it &#8211; you will always face the same problem: Developers concurrently working with party of the system that are directly or transitively connected will run into conflicts. You will have different parts of your system requiring different versions of the same library on the same class path. Changing one part of the system will always affect other parts of the system, most of the times in an unplanned fashion. </p>
<p>Test driven developments helps a lot along the way, but you still have a responsibility problem if there&#8217;s one team changing something and this causes a problem in a different part of the system, and dependency issues can be a real mess.</p>
<p>This is where OSGI can play out it&#8217;s strengths. Not only does it offer you complete, classloader-based module isolation. I believe the greatest benefit lies in the development process: Concurrent development is a lot easier with OSGI bundles than with a huge pile of tightly interconnected classes. You can have a lot of changes in the bundle, while exposing a relatively stable interface through which other components access your bundle&#8217;s services. Separation into OSGI bundles can bring the power of the SOA-Idea into &#8220;stand-alone&#8221; applications, without the massive overhead of connecting systems or components through, for example web services.</p>
<p>Of course, this concept has quite an impact on your way of thinking, since you will start to add a new level of decomposition: Which classes form tightly coupled components that could be isolated from other components and used as a service through a well-defined, slim and easy-to-use interface? </p>
<h3>OSGI about to &#8220;break through&#8221;</h3>
<p>Now, why am i so convinced that OSGI is about to finally become as common as using AOP or dependency injection? Because all the popular technologies are just about to embrace OSGI:</p>
<ul>
<li>
    <a href="http://www.jroller.com/habuma/entry/modular_java">Craig walls (Spring framework) has just finished his book an modular JAVA with the spring framework, featuring OSGI and Spring</a>, a very powerful combination.
 </li>
<li>
    <a href="http://it-republik.de/jaxenter/jax/sessions/jax/speaker/#3271">Doug Clarke</a> and <a href="http://it-republik.de/jaxenter/jax/sessions/jax/speaker/#2213">Shaun Smith</a> will hold a presentation on persistence and OSGI with eclipselink (the reference implementation of the JAVA persistence API (JPA))</a>, thus suitable persistence mechanisms for this level of modularization are likely to be close at hand.
 </li>
</ul>
<p>And if you <a href="http://it-republik.de/jaxenter/jax/sessions/?tid=1053">look at the schedule for the JAX, Europe&#8217;s most important software &#038; development conference, there have never been more OSGI topics featured</a> &#8211; at least I would doubt that.</p>
<p>In other words: OSGI will soon be so smoothly integrated with you favorite frameworks, IDE&#8217;s and API&#8217;s that using it will be a breeze &#8211; and a must, if you want to take the quality of your development process and software to the next level.</p>
]]></content:encoded>
			<wfw:commentRss>http://olafsblog.sysbsb.de/modular-development-with-osgi-about-to-be-very-very-popular-finally/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

