tag:blogger.com,1999:blog-40306577730748287172024-03-13T08:42:54.360+00:00OSGi thoughtsDavid Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.comBlogger43125tag:blogger.com,1999:blog-4030657773074828717.post-46052610411763508692013-08-12T10:50:00.002+01:002013-08-12T10:50:39.151+01:00Presentation: The Benefits of OSGi in PractiseA little while ago I created a presentation around how I see the benefits of OSGi. It can serve as an introduction to those who like to learn more about OSGi and how it can solve real-world problems.<br />
<br />
I've now put this presentation on slide share. You can find it here: <a href="http://www.slideshare.net/bosschaert/benefits-of-osgi-in-practise">http://www.slideshare.net/bosschaert/benefits-of-osgi-in-practise</a>David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com0tag:blogger.com,1999:blog-4030657773074828717.post-86131523014505564362013-06-28T10:44:00.000+01:002013-06-28T10:57:52.747+01:00Polyglot OSGi: new C/C++ and JavaScript RFPs!OSGi has been a great Modularity and Services platform for Java for many years. If you look at the Core, Enterprise, Compendium and Residential specifications you will see that a broad spectrum of topics and technologies is covered by OSGi specs.<br />
<br />
However, Java isn't the only language in town. And indeed OSGi is already being used by other JVM-based languages, such as Scala as you can see from the <a href="http://wiki.osgi.org/wiki/SbtScalaBndToolchain" target="_blank">Scala Tool Chain</a> page on the OSGi wiki.<br />
<br />
Going forward, OSGi will go places where there is no JVM available! Recent work is looking at gathering requirements for OSGi frameworks for JavaScript and C/C++.<br />
<br />
A new RFP around OSGi for JavaScript was started. This RFP currently mainly focuses on the OSGi Service Layer and bringing something like that to native JavaScript. You can already find an implementation of many of the concepts in Eclipse Orion. The JavaScript Microservices RFP 159 is in available in bugzilla here: <a href="http://www.osgi.org/bugzilla/show_bug.cgi?id=169">http://www.osgi.org/bugzilla/show_bug.cgi?id=169</a><br />
<br />
On the C/C++ side, there have been a number of projects that implemented an OSGi-like core framework either in C or in C++. These are use in a variety of contexts from embedded in hardware to image processing systems. The authors of all these projects have put their heads together and started an RFP on a Native OSGi Core Framework. You can find RFP 156 here: <a href="https://www.osgi.org/bugzilla/show_bug.cgi?id=165">https://www.osgi.org/bugzilla/show_bug.cgi?id=165</a><br />
<br />
I think this is pretty exciting! The concepts of OSGi apply to many environments and languages and its great to now see standardization work happening in these new areas too!<br />
<br />
If you have any feedback on these RFPs, leave a comment on the bugs!David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com0tag:blogger.com,1999:blog-4030657773074828717.post-23645155951473287512013-05-30T13:42:00.000+01:002013-05-30T13:42:03.658+01:00InfoQ interview about work in the EEGA little while ago I did an interview with Alex Blewitt from InfoQ about current activities in the OSGi Enterprise Expert Group. The interview is now available from here: <a href="http://www.infoq.com/interviews/Bosschaert-changes-OSGi-Enterprise-Specification">http://www.infoq.com/interviews/Bosschaert-changes-OSGi-Enterprise-Specification</a>David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com0tag:blogger.com,1999:blog-4030657773074828717.post-85319198627575973782013-03-19T14:45:00.001+00:002013-03-19T14:45:44.448+00:00OSGi Cloud Ecosystems RFC 183 in public draftRecently the OSGi Alliance has made an Early Access Draft available of many of the RFCs that are currently being worked on in the Enterprise Expert Group (EEG) and the Core Platform Expert Group (CPEG).<br />
<br />
One of these is RFC 183: OSGi Cloud Ecosystems.<br />
OSGi Cloud Ecosystems is about having a many OSGi frameworks co-operating in a Cloud or Cloud-like environment. Its about having multiple cloud nodes work together to provide a coherent logical function. This includes the ability to reconfigure your deployments to scale up when needed or scale down when possible. It also includes providing the ability to react to volatility in your Cloud environment, as nodes might die unexpectedly or may become unresponsive for some reason.<br />
<br />
A large portion of RFC 183 is about how you discover things. How do I discover what OSGi frameworks are available in my environment? And what are the characteristics of those frameworks? What cloud or other environment are they running on and where? For certain applications knowing the actual country or region of your deployment is vital, so this is one of the pieces of information available.<br />
<br />
When a cloud node appears it often appears on a dynamically assigned node. RFC 183 is about letting the other OSGi frameworks in the environment know that there is a new Framework available so that they can communicate with it. Information passed to other frameworks includes things as the IP address of the node, which is obviously vital in order to be able to communicate. Additionally information about the type of infrastructure the node is running on is made available. Typically the process that reacts to changes in the topology involves some of the following:<br />
<ul>
<li>If a new framework appears, it needs to be provisioned, meaning that an entity in the system needs to decide what artifacts need to be deployed on it.</li>
<li>Once provisioned it needs to become part of the overall function of the system. This means that other entities on the various participating nodes must be wired up to use the new node.</li>
<li>Similarly, when a VM is taken out of the environment, the interested other nodes are informed so that they can adjust to the situation.</li>
<li>Other conditions may also require a change in the way the system is provisioned can be:</li>
<ul>
<li>when the load on a particular node gets too high - we need to find some quiet nodes that can take over some of the load.</li>
<li>when the functionality offered by the application changes, maybe the user has changed the application configuration.</li>
<li>when the system is quiet - we can give some resources back for consumption by other components.</li>
</ul>
</ul>
RFC 183 aims at making it really easy to use OSGi services across Cloud nodes. This means that as a developer you're just writing OSGi services (which are really just Java POJOs) and that you can make these available across your Cloud Ecosystem to all the frameworks available. The mechanics are based on the OSGi Remote Services specs. The nice thing is that the Discovery piece takes care of wiring these services up, so you don't need to know <i>where</i> the service is running, you can simply find it in your local Service Registry and use it. If the service migrates to another VM, or another copy of it becomes available, Discovery will update the Service Registry in your framework so that it's up to date with what services are available in the ecosystem. The OSGi service model is already very much geared towards dynamicity of services, so the potential volatility of a cloud deployment fits here very well. Existing service component such as Declarative Services, Blueprint and others can work well with these Distributed Services while providing a very simple programming model at the same time.<br />
<br />
RFC 183 is really about providing a base layer for dynamic applications that run in the cloud. It's minimal in the sense that it provides some <i>primitives</i> that allow you to create a dynamic, service-based cloud system in a way that is very familiar if you are used to OSGi services. It gives you all you need to write a provisioner that is part of the system, but it does not define a cloud deployment descriptor format or anything like that. At this stage you need to write your own provisioner that knows how to provision your application, although a more generic provisioning system could be written using the primitives provided.<br />
Or maybe someone wants to create a PaaS that can take direct deployment of Blueprint beans or Declarative Service components. These too could also be modeled atop of what RFC 183 attempts to provide.<br />
<br />
At the moment RFC 183 does not attempt to provide a standard mechanism for creating or shutting down compute nodes. There are already a number of projects that abstract over this and I think it would be best to utilize those right now, although it might make sense to describe at some point how these are integrated with the OSGi Service Registry.<br />
<br />
It's still early days, this is the first EA draft that contains RFC 183, but from speaking with people who are using OSGi in a cloud environment, many solutions are moving into a similar direction, so it looks like things are converging.<br />
<br />
You can find RFC 183 in the draft here: <a href="http://www.osgi.org/Download/File?url=/download/osgi-early-draft-2013-03.pdf">http://www.osgi.org/Download/File?url=/download/osgi-early-draft-2013-03.pdf</a><br />
<br />
If you have any thoughts about it, let us know what you think at the <a href="https://mail.osgi.org/mailman/listinfo/osgi-dev" target="_blank">osgi-dev mailing list</a> or to create a bug around the topic in <a href="https://www.osgi.org/bugzilla/enter_bug.cgi?product=OSGi%20Specification" target="_blank">OSGi buzilla</a>.<br />
<br />
Additionally, I'll be talking about this topic at EclipseCon: <a href="http://www.eclipsecon.org/2013/sessions/osgi-cloud-ecosystems">http://www.eclipsecon.org/2013/sessions/osgi-cloud-ecosystems</a>David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com0tag:blogger.com,1999:blog-4030657773074828717.post-49521603792998997382012-11-15T09:20:00.003+00:002012-11-15T09:20:44.061+00:00Current themes in the OSGi Enterprise Expert GroupAfter the <a href="http://www.osgi.org/Download/Release5" target="_blank">OSGi Enterprise R5 release</a> this summer, the OSGi Expert groups have started working on new items for the OSGi R6 releases.<br />
<br />
At this point in time, the main themes in the Enterprise Expert Group are <i>Cloud</i> and <i>JavaEE integration</i>. In the EEG the following documents are currently being discussed:<br />
<br />
<ul>
<li>OSGi/CDI integration (RFC 193) - jointly led by <a href="http://www.jboss.org/jbossas/osgi" target="_blank">Red Hat/JBoss</a>, <a href="http://www.serli.com/" target="_blank">SERLI</a> and <a href="http://www.luminis.eu/" target="_blank">Luminis</a>. This RFC aims to define a standard for OSGi-CDI implementations. A number of different implementations currently exist such as <a href="http://mathieuancelin.github.com/weld-osgi/" target="_blank">weld-osgi</a>, <a href="http://team.ops4j.org/wiki/display/PAXCDI/Pax+CDI" target="_blank">Pax CDI</a> and in <a href="http://glassfish.java.net/" target="_blank">Glassfish</a> and others. The aim is to bring the CDI programming model to OSGi with portability across compliant implementations.</li>
<li>OSGi Cloud Ecosystems (RFC 183) - jointly led by <a href="http://www.jboss.org/jbossas/osgi" target="_blank">Red Hat/JBoss</a> and <a href="http://www.paremus.com/" target="_blank">Paremus</a>. A standard OSGi-based PaaS definition with a focus on creating a highly portable dynamic cloud environment. This work is still in the early stages of discussion but you can find some of the thinking in my EclipseCon Europe presentation: <a href="http://www.slideshare.net/bosschaert/osgi-cloud-ecosystems">http://www.slideshare.net/bosschaert/osgi-cloud-ecosystems</a></li>
<li>Complex Repository Requirements (RFC 187) - lead by <a href="http://www.jboss.org/jbossas/osgi" target="_blank">Red Hat/JBoss</a>. This is a small enhancement to the OSGi Repository specification which was released as part of the Enterprise R5 release and for which Thomas Diesler did the <a href="http://github.com/jbosgi/jbosgi-repository" target="_blank">Reference Implementation at JBoss</a>. The enhancements discussed in this RFC focus on more complex requirements for the Repository back end.</li>
<li>Portable Java Contracts (RFC 180) - lead by <a href="http://www.ibm.com/" target="_blank">IBM</a>. Read more about this RFC in my <a href="http://osgithoughts.blogspot.ie/2012/10/new-osgi-eeg-early-access-draft.html" target="_blank">previous blog post</a>.</li>
<li>Enhancements to the OSGi HTTP Service (RFC 189)* - lead by <a href="http://www.adobe.com/" target="_blank">Adobe</a>. The OSGi HTTP Service specification is highly popular because its such an easy way to get Servlets up and running. However the specification was long overdue an update. This is what this RFC is about. It is about modernising the Servlet API and also brings the white board pattern to this specification.</li>
<li>REST management (RFC 182) - lead by <a href="http://www.ibm.com/" target="_blank">IBM</a>. This RFC focuses on being able to remotely manage an OSGi Framework through REST, for example for use in a Cloud environment. For more information see my <a href="http://osgithoughts.blogspot.ie/2012/10/new-osgi-eeg-early-access-draft.html" target="_blank">previous post</a>.</li>
<li>OSGi/EJB integration (RFC 194) - lead by <a href="http://www.ibm.com/" target="_blank">IBM</a>. This RFC has just started and aims at addressing the requirements from <a href="https://www.osgi.org/bugzilla/show_bug.cgi?id=148" target="_blank">RFP 152</a>.</li>
<li>Blueprint version 1.1 (RFC 184) - lead by <a href="http://www.ibm.com/" target="_blank">IBM</a>. Discusses a number of improvements to blueprint, which include configuration around service damping and the grace period.</li>
<li>Declarative Services Enhancements (RFC 190)* - lead by <a href="http://www.adobe.com/" target="_blank">Adobe</a>. This document discusses a number of improvements to DS among which are an Administrative API and new annotations.</li>
</ul>
<div>
Note that the OSGi/JCA integration (RFC 146), lead by Jesper Pedersen from Red Hat/JBoss is likely to become active again soon.</div>
<div>
<br /></div>
<div>
Additionally, a group of people is proposing an OSGi standard for C/C++. They are working on a new RFP which should be available in the near future.</div>
<div>
<br /></div>
<div>
At this stage many documents are still at the early stages of the technical design. The target date for the OSGi Core and Enterprise R6 releases is currently Q1 2014.</div>
<div>
<br /></div>
<div>
Note - if you're interested in getting involved in the RFC discussions and you are working for an OSGi member company, <a href="http://www.blogger.com/profile/13786738766478890804" target="_blank">contact me</a> (or any of the other EG co-chairs). If you're interested but don't work for a member company, have a look at the OSGi membership page: <a href="http://www.osgi.org/Join">http://www.osgi.org/Join</a></div>
<div>
<br /></div>
<div>
* These RFCs are crossover topics with the OSGi Core Expert Group CPEG.</div>
David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com0tag:blogger.com,1999:blog-4030657773074828717.post-20489230227946429502012-10-12T16:32:00.000+01:002012-10-12T16:32:25.392+01:00New OSGi EEG Early Access Draft availableA new Early Access Draft has been published at OSGi that contains 3 RFCs that are currently being discussed in the Enterprise Expert Group.<br />
<br />
<b><i>Blueprint Transactions (RFC 164)</i></b><br />
This RFC focuses on how to add declarative transaction support to the OSGi Blueprint standard.<br />
<br />
<b><i>Portable Java Contracts (RFC 180)</i></b><br />
OSGi has always been very outspoken about versioning Java packages (for more info see the Semantic Versioning white paper: <a href="http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf">http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf</a>) however, what version to use for APIs defined by JavaEE has been unclear. While many people have been talking about these APIs in terms of the JavaEE versions (e.g. Servlet 2.5, Servlet 3.0) these version numbers don't always match with the Semantic Versioning ideas that OSGi promotes. For example, with Semantic Versioning you would only increase the major version if you are breaking backward compatibility. When Servlet 3.0 came out of the JCP it did actually <i>not</i> break compatibility with 2.5, but still the major version was increased. In the end the various OSGi-enabled application server implementors used different versioning schemes for JavaEE packages, which made it unclear how to use these in a portable way from OSGi. This RFC aims at addressing this issue in a way that is both natural to people familiar with the JavaEE version numbers as well as being able to cope with the various package version numbers used in the OSGi capable Application Servers.<br />
<br />
<i><b>REST Management Interface (RFC 182)</b></i><br />
In the context of Cloud Computing, REST is becoming the dominant way of accessing and controlling remote applications running in the cloud. This RFC defines a remote management interface for OSGi bundles over REST and defines both JSON as well as XML data bindings.<br />
<br />
You can find the Early Access Draft here: <a href="http://www.osgi.org/News/20121011">http://www.osgi.org/News/20121011</a><br />
Remember that these drafts are not final - if you have any feedback, let us know either via bugzilla (<a href="http://www.osgi.org/bugzilla">http://www.osgi.org/bugzilla</a>) or via the osgi-dev mailing list: <a href="http://www.osgi.org/MailLists">http://www.osgi.org/MailLists</a>David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com0tag:blogger.com,1999:blog-4030657773074828717.post-89758352744567249082012-09-12T22:12:00.000+01:002012-09-12T22:12:42.696+01:00Disappointed by Jigsaw delay? Java Modularity is here today!I recently heard that some people are expressing disappointment over the lack of a built-in module system in Java 8, now that Jigsaw is delayed. Some are apparently even looking at technologies other Java because of this. Well, I'd like to point out that <b><i>There is No Need To Wait</i></b>! All the modularity that your application needs is already available with OSGi! OSGi pretty much supports everything that Jigsaw was planning to support to allow modularization of applications. And OSGi has <i>more</i> features such as a dynamic lifecycle and a very useful services model. Still OSGi frameworks can be remarkably small. Of the popular implementations <a href="http://felix.apache.org/" target="_blank">Apache Felix</a> is probably the smallest with its implementation in under 500kilobytes. But <a href="http://www.eclipse.org/equinox/" target="_blank">Eclipse Equinox</a> and our own <a href="http://www.jboss.org/jbossas/osgi" target="_blank">JBoss OSGi Framework inside AS7</a> are also very good opensource implementations.<br />
<br />
Want to learn how to use OSGi? Like many people I like learning stuff by reading a book. Recently a number of books have been published that provide really good explanations of how to use OSGi, notably <a href="http://manning.com/hall/" target="_blank">OSGi in Action</a>, <a href="http://manning.com/alves/" target="_blank">OSGi in Depth</a> and Kirk Knoernschilds <a href="http://modularity.kirkk.com/" target="_blank">Modular Architecture book</a>, but probably my favorite book is <a href="http://manning.com/cummins/" target="_blank">Enterprise OSGi in Action</a>. Besides containing a good description of a number of Enterprise OSGi specs, it also describes really well why certain things are done in OSGi they way they are, which give you a nice and deep understanding of the technology. Additionally it contains some great chapters on how to get your build, test and development environments to work smoothly with OSGi. Enterprise OSGi in Action will be in print later this year, but you can already get it in <a href="http://manning.com/cummins/" target="_blank">electronic form from here</a>.<br />
<br />
Besides the books, the <a href="http://www.osgi.org/javadoc/r5/core/index.html" target="_blank">OSGi Javadoc</a> can be very useful and if you really want to know the details of it all, the <a href="http://www.osgi.org/Download/Release5" target="_blank">OSGi specs</a> are a great resource.
Oh, and don't forget to check out the Wikipedia page that shows <a href="http://en.wikipedia.org/wiki/OSGi_Specification_Implementations" target="_blank">where you can get implementations</a> of the various OSGi technology.<br />
<br />
So in short - no need to wait or turn away from Java if you need Modularity. OSGi is here today and has been used in production by numerous users for many years, just get started by downloading one of the opensource implementations and try it out!
David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com4tag:blogger.com,1999:blog-4030657773074828717.post-79809964000962935712012-09-05T13:58:00.000+01:002012-09-05T13:58:16.411+01:00Presenting about Cloud Ecosystems at OSGi Community Event 2012Over the past few months I've been piloting what I started to call an OSGi Cloud Ecosystem. You can see the details on my technical blog <span style="font-family: Courier New, Courier, monospace;"><a href="http://coderthoughts.blogspot.com/2012/08/dynamic-provisioning-osgi-cloud.html" target="_blank"><coderthoughts/></a></span>. I am coming to the conclusion that OSGi can provide a really interesting basis for a Platform as a Service that can support the fluidity of the cloud, where services migrate from one VM to another and systems can scale up and down as needed, without having to worry about getting swamped by configuring what runs where etc. Your OSGi system is based on a Service Oriented Architecture where your services are implemented and consumed using the widely supported OSGi services programming model. Your system is comprised for multiple cloud VMs each of which may take different roles over time. As the need arises you add or remove cloud VMs that contain some of your OSGi services, migrating services across VMs as needed. However as a consumer you simply use the OSGi Service Registry to find and use your services.<div>
The postings on <coderthoughts/> show a pilot that implements these ideas and I'll be talking more about them (and showing a demo) at the OSGi Community Event 2012 (which is part of EclipseCon Europe 2012) on October 23-25 in Ludwigsburg, Germany. See here for the programme: <a href="http://www.osgi.org/CommunityEvent2012/Agenda">http://www.osgi.org/CommunityEvent2012/Agenda</a> for general conference information go here: <a href="http://www.osgi.org/CommunityEvent2012">http://www.osgi.org/CommunityEvent2012</a></coderthoughts></div>
<div>
<br /></div>
<div>
Hope to see you there!</div>
<div>
<br /></div>
David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com1tag:blogger.com,1999:blog-4030657773074828717.post-23088652434737704632012-08-30T10:59:00.001+01:002012-08-30T10:59:40.880+01:00Feedback requested for OSGi RFPsNow that the summer holidays are drawing to a close for most, it would be a good time to look at some of the new work that is happening at OSGi.<br />
In OSGi new specification efforts are kicked off by creating an RFP, a document that lists the uses-cases and requirements that the ultimate specification must implement. Once an RFP is agreed on the actual technical design and spec-work starts through the creation of a follow-up RFC.<br />
<br />
Recently 4 new RFPs have been made public via OSGi bugzilla to see if people have further input or requirements, a process that has worked really well for the <a href="http://www.osgi.org/bugzilla/show_bug.cgi?id=141">OSGi/CDI RFP</a> and a little longer ago for the <a href="http://www.osgi.org/bugzilla/show_bug.cgi?id=114">OSGi Cloud RFP</a>.<br />
<br /><b><i>RFP 143 OSGi Connect</i></b><div>
The people at <a href="https://code.google.com/p/pojosr/">PojoSR</a> have done some great work in showing how you can use OSGi Services in cases where you may not want to take on OSGi modularity (yet). RFP 143 captures requirements for creating a specification around this. The RFP can be found here: <a href="http://www.osgi.org/bugzilla/show_bug.cgi?id=145">RFP 143</a>.<br /><br /><b><i>RFP 150 HTTP Service Updates</i></b></div>
<div>
The OSGi HTTP Service is widely used and it provides a very nice programming model for sevlets in an OSGi environment. However the specification is in need for an update to modernize it in relation to the Servlet spec itself. Additionally, the whiteboard pattern is introduced for servlet. You can find the RFP here: <a href="http://www.osgi.org/bugzilla/show_bug.cgi?id=146">RFP 150</a>.<br /><br /><b><i>RFP 151 Declarative Service Updates</i></b></div>
<div>
A variety of updates are proposed to the Declarative Services specification. They can be found in <a href="http://www.osgi.org/bugzilla/show_bug.cgi?id=147">RFP 151</a>.<br /><br /><b><i>RFP 152 EJB Integration</i></b></div>
<div>
EJB integration with OSGi has been done at Apache Aries, Glassfish and ObjectWeb (EasyBeans / JOnAS). Other appservers such as JBoss and others also provide some form of interaction between EJBs and OSGi. This RFP aims a writing a specification for this integration to make OSGi-enabled EJBs portable. You can find the RFP here: <a href="http://www.osgi.org/bugzilla/show_bug.cgi?id=148">RFP 152</a>.<br /><br />So if you have any thoughts about these topics, do chime in and leave your comments or ideas on the associated bugs!</div>
David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com0tag:blogger.com,1999:blog-4030657773074828717.post-3332583722463404692012-07-18T07:00:00.000+01:002012-07-18T07:00:47.830+01:00No Jigsaw for JavaSE 8Yesterday Mark Reinhold announced that Oracle will not pursue modularity for JavaSE 8: <a href="http://mreinhold.org/blog/late-for-the-train">http://mreinhold.org/blog/late-for-the-train</a>. Following long delays for the Modularity JSR the decision was made not to postpone JavaSE 8 or rush through the JSR but rather postpone the Modularity part of Java 8 and push ahead with the rest of it.<br />
<br />
So what does this mean for Modularity in Java? Well, I think its an appropriate decision to not rush things through. As modularity is such a fundamental piece of functionality you don't want to cut corners with the architecture. <a href="http://www.osgi.org/">OSGi</a> has been providing modularity to Java for over 12 years now and there are a lot of lessons to be learnt from it.<br />
<br />
Project Jigsaw is a prototype of a modularity system that's part of the Java runtime, but at this stage it's just one approach to this. In <a href="http://openjdk.java.net/projects/penrose/">Project Penrose</a> work is ongoing around improving the extensibility of Jigsaw so that it can work better with other module systems such as OSGi.<br />
<br />
<span style="background-color: white;">While some work is definitely needed to modularize Java itself, as an application developer you don't need to wait for this. If you need modularity in your applications, then OSGi provides all that you need today and it has been proven for years by many in the field</span><span style="background-color: white;">.</span><br />
<br />
It's good that the Modularity JSR will get some proper time now. I hope the process will be democratic and that the result will provide the best technology possible that keeps extensibility in mind.<br />
<br />David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com1tag:blogger.com,1999:blog-4030657773074828717.post-91878719699725486552012-06-14T11:22:00.001+01:002012-06-14T11:22:12.035+01:00OSGi Enterprise R5 specifications releasedWhile the Early Access draft was already available for a couple of months, the OSGi R5 Core and Enterprise specifications are now officially released. The Enterprise release contains a couple of significant new specifications. While the <a href="http://blog.osgi.org/2012/06/core-release-5-and-enterprise-release-5.html">blog post on the OSGi website</a> gives general information about this release, I'm spending a few more words on the new specs that are part of the Enterprise release here.<br />
<i><br />The Repository specification</i><br />
Repository is a very interesting new spec that provides an API based on generic capabilities and requirements to access (possible remote) repositories. With this API you can do things like: 'I need a bundle that exports package javax.servlet version 2.5' or you can say 'I need a bundle that provides a Declarative Services implementation version 1.2' without having to know what the name of the bundle is. The Repository can be used with any kind of resource (it doesn't have to be an OSGi bundle) and it works with any type of capability. So you can also make your own capabilities and express requirements in terms of those to find your resources.<br />
Besides the API it also defines an XML interchange format that can be used to export and import repository information across repositories. Note that the resources known to the repository don't actually need to reside inside it, they can live anywhere as long as its accessible via a URL.<br />
The Reference Implementation of the Repository is currently being worked on in the <a href="http://www.jboss.org/jbossas/osgi">JBoss OSGi project</a>.<br />
<i><br />The Resolver Specification</i><br />
OSGi Frameworks have contained resolvers for a long time. This specification allows other entities to use this resolver as a standalone entity as well. The Resolver can obviously be used to resolve OSGi type of requirements, which can be used to evaluate what-if scenarios. The Resolver is stateless, and doesn't need to perform its operations in relation to the local framework, so it can be used to see whether a bundle or set of bundles would resolve in another framework. Additionally, the Resolver can be used on any type of constraint that can be expressed as generic capabilities and requirements, and, as with the Repository, it doesn't need to operate on bundles per se. It can resolve requirements over a set of capabilities provided by any type of resource. While I haven't tried it (yet) you should be able to use it in completely different domains. The RI of the Resolver is in a well-advanced stage at the <a href="http://felix.apache.org/site/index.html">Apache Felix project</a>.<br />
<i><br />Subsystems</i><br />
The Subsystems specification can be described in many different ways. One of the things it allows you to do is to create an archive (an .esa file) which contains a number of bundles which together provide a piece of functionality. For example, take the <a href="http://cxf.apache.org/distributed-osgi.html">CXF-DOSGi project</a> which implements the Remote Services specification. To deploy CXF-DOSGi you previously had to deploy a large number of bundles. Composite systems like this can now be bundled in a subsystem, where you only need to deploy a single subsystem to get all these bundles in your framework. There are many other aspects to subsystems too. Instead of bundeling up all the bundles in the .esa file you can also describe the subsystem purely in a declarative sense, by only having a descriptor that says 'my subsystem is defined by bundle1, bundle2 and bundle3'. The subsystem implementation can then use the Repository and Resolver to locate these bundles, pull in their transitive dependencies and deploy the whole lot in your OSGi framework.<br />
Additionally, Subsystems provides a feature for QA teams. It allows you to add an additional Deployment manifest which can lock down the actual versions of the bundles that the subsystem is to be used with. QA teams can use this to lock down the versions to the ones they tested.<br />
Besides all this, Subsystems provides isolation features which are aimed at allowing multiple subsystems to run within the same framework without interference. The Subsystems RI is being implemented in <a href="http://aries.apache.org/">Apache Aries</a>.<br />
<i><br />ServiceLoader Mediator Specification</i><br />
This specification deals with getting <span style="font-family: 'Courier New', Courier, monospace;">java.lang.ServiceLoader</span> to work in an OSGi framework. ServiceLoader has been in JavaSE since version 6 and there are lots of problems with it, the main ones being that its non-modular and non-dynamic by design. However there is code out there that uses ServiceLoader and this code needs to work in an OSGi framework as well. That's what this specification enables. The reference implementation is being done in the <a href="http://aries.apache.org/modules/spi-fly.html">Apache Aries SPI-Fly component</a>.<br />
<i><br />Common Namespaces Specification</i><br />
Namespaces in this context describe various types of information that can be expressed as generic capabilities and requirements. This specification describes a number of these namespaces. They can be used during the resolution process but also as part of the metadata in a Repository so that they can be found using Repository queries. The following namespaces are defined in this spec (note that the Core spec also defines a number of different namespaces):<br />
<ul>
<li><span style="font-family: 'Courier New', Courier, monospace;">osgi.extender</span>: this allows a bundle to express that it needs an particular extender (e.g. I need Blueprint in order to function). The extenders themselves provide this capability.</li>
<li><span style="font-family: 'Courier New', Courier, monospace;">osgi.contract</span>: can be used as a convenient way to import a number of packages that together provide a certain contract. For example you could say: give me all the packages that are part of the Servlet 3.0 spec. This namespace is intended for tools to allow developers to specify a contract rather than the individual imports. Under the covers this contract can automatically be expanded into the appropriate import-package statements.</li>
<li><span style="font-family: 'Courier New', Courier, monospace;">osgi.service</span>: allows a bundle to express that it needs a given service and similarly allows a bundle to express that it can provide a certain service.</li>
<ul>
</ul>
</ul>
Also included is a new <i>Coordinator</i> specification (which was first released in the Compendium 4.3 release) and significant updates to the <i>JMX specification</i>. The <i>Configuration Admin</i> specification got some new features (among which are 'targeted pids') and some minor changes were made to a number of other specs.<br />
<br />
You can download the OSGi Enterprise R5 specification from here: <a href="http://www.osgi.org/Release5">http://www.osgi.org/Release5</a>David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com0tag:blogger.com,1999:blog-4030657773074828717.post-62019089330198796642012-05-15T11:27:00.002+01:002012-05-15T12:34:14.558+01:00Java 8: extensible module definitions with JSONWhile the Java Modularity JSR [1] is still AWOL (come on, Oracle, I thought that this JSR was planned to be launched by September 2011!), I did some work in OpenJDK Penrose around changing the Java SE 8 module metadata from the .java/.class format into JSON.<br />
<br />
JSON is quite nice because<br />
<ul>
<li>it's a simple text format</li>
<li>easy to read by humans</li>
<li><a href="http://hg.openjdk.java.net/penrose/jigsaw/jdk/file/8ddc73840820/src/share/classes/java/lang/module/JSONParser.java" target="_blank">easy to parse for computers</a></li>
<li>its highly extensible</li>
</ul>
<div>
with JSON, the SE 8 <a href="http://openjdk.java.net/projects/jigsaw/doc/quickstart.html" target="_blank">Quick Start</a> module <b><i>org.astro</i></b> module definition looks like this:</div>
<div>
<br />
<span style="font-family: 'Courier New', Courier, monospace;">{</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> "module" :</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> {</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> "name" : "org.astro",</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> "version" : "1.2",</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> "exports" : [ {"name" : "org.astro"} ]</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> }</span><br />
<span style="font-family: 'Courier New', Courier, monospace;">}</span><br />
<div>
<span style="font-family: 'Courier New', Courier, monospace;"><br /></span></div>
</div>
<div>
and the same module info file can be expanded to contain OSGi metadata, for example to add a version to the exported package like this:</div>
<div>
<br />
<span style="font-family: 'Courier New', Courier, monospace;">{</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> "module" :</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> {</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> "name" : "org.astro",</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> "version" : "1.2",</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> "exports" : </span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> [</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> { </span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> "name" : "org.astro", </span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> <span class="Apple-tab-span" style="white-space: pre;"> </span>"org.osgi.version" : "1.2.3"</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> }</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> ]</span><br />
<span style="font-family: 'Courier New', Courier, monospace;"> }</span><br />
<span style="font-family: 'Courier New', Courier, monospace;">}</span><br />
<br />
Any OSGi metadata can be added to the JSON module descriptor. I've added a simple test to the Penrose codebase to give an idea what this looks like: <a href="http://hg.openjdk.java.net/penrose/jigsaw/jdk/file/8ddc73840820/test/org/openjdk/jigsaw/hello-json-custom.sh">hello-json-custom.sh</a>.<br />
<br />
This works today in OpenJDK project Penrose. The codebase still supports module-info.java, to allow a gradual migration to JSON-based metadata, however I'd like to see the module-info.java/.class support go away ultimately.</div>
<div>
<br /></div>
<div>
While Jigsaw/Penrose are two variants on a module system for Java SE, other ones are clearly possible. Once the modularity JSR is up in action, it should seriously consider OSGi as a module system for Java SE 8. <a href="http://harmony.apache.org/" target="_blank">Apache Harmony</a> has clearly demonstrated in the past that modularizing the Java platform using OSGi metadata works quite well. OSGi has proven to be an excellent module system for Java for the last 12 or so years, so it would be foolish not to take that experience on board...<br />
<br />
On the lack of Modularity JSR, I think at that at this stage we can expect that it will delay the release of Java 8, given that modularity is such an important building block for Java, and is certainly not something that can be rushed through.<br />
<br />
[1] 'Java Platform Module System' JSR as mentioned in the <a href="http://www.jcp.org/en/jsr/detail?id=337" target="_blank">Java SE 8 umbrella JSR</a>.</div>David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com3tag:blogger.com,1999:blog-4030657773074828717.post-73894482354173687692012-04-02T21:44:00.000+01:002012-04-02T21:44:41.953+01:00Presentation on new specs in OSGi 5.0 Enterprise release (EclipseCon/OSGi DevCon 2012)Last week Tim Diekmann and I presented an overview of the new specifications that are part of the OSGi 5.0 Enterprise Release. You can find this presentation <a href="http://www.slideshare.net/bosschaert/the-os-gir5enterpriserelease">online at this link</a>.<br />
<br />
Draft releases of the OSGi R5 specs can be downloaded from here:<br />
<ul><li>Core <a href="http://www.osgi.org/download/osgi.core-5.0.0-pfd.pdf%20" target="_blank">http://www.osgi.org/download/osgi.core-5.0.0-pfd.pdf </a></li>
<li>Enterprise <a href="http://www.osgi.org/download/osgi.enterprise-5.0.0-pfd.pdf%20" target="_blank">http://www.osgi.org/download/osgi.enterprise-5.0.0-pfd.pdf </a></li>
</ul>The actual final specifications will be made available not too long from now. They are currently in the voting process at the OSGi Alliance. Except for some typos and minor formatting issues the final specs are identical to the above EA drafts.David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com0tag:blogger.com,1999:blog-4030657773074828717.post-83729576844840708502012-02-07T08:06:00.000+00:002012-02-07T08:06:34.094+00:00OSGi Cloud Workshop at EclipseCon/OSGiDevCon 2012Many people are seeing how well OSGi fits conceptually with Cloud Computing. Its modularity is frugal on memory, and provides isolation. Additionally it focuses components on a particular task, which makes them better maintainable too. Furthermore, OSGi dynamicity makes it possible to create Cloud components that react to changes in the cloud environment in a natural way. They can be dynamically configured, reconfigured and an OSGi Framework can be dynamically provisioned and re-provisioned as well!<br />
<br />
Over the past while the OSGi Cloud Working Group has been looking at how OSGi can be enhanced to provide additional support for Cloud Computing. This has resulted in a requirements document called <a href="https://www.osgi.org/bugzilla/attachment.cgi?id=17">RFP 133</a>.<br />
<br />
At this point in time we need to discuss which of these requirements should be tackled first? Is it Discovery in the Cloud? Or Metadata? Or Management or maybe something else?<br />
At the same time we should embrace any existing standards in this area and certainly not attempt to reinvent the wheel!<br />
<br />
This discussion is the topic of the <a href="http://www.osgi.org/DevCon2012/HomePage#cloud">Second OSGi Cloud Workshop</a> which is held this year at the EclipsCon/OSGiDevCon venue on Thursday March 29 at 9am.<br />
<br />
It is set to be a morning with some presentations (the lineup currently is: Paremus, JClouds, eBay and RedHat/JBoss), a demo, and a lot of time for discussion. Entrance is <b><i>free</i></b> - you don't need an EclipseCon pass, but you do need to register as numbers are limited (see here also for details on the location of the venue): <a href="http://osgi-cloudworkshop-2012.eventbrite.co.uk/">http://osgi-cloudworkshop-2012.eventbrite.co.uk</a><br />
<br />
Oh, and just to be sure: EclipseCon/OSGiDevCon 2012 has moved and is in Washington/Reston this year!David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com0tag:blogger.com,1999:blog-4030657773074828717.post-7782802262600592482012-01-06T08:55:00.000+00:002012-01-06T08:55:57.160+00:00JavaSE 8 Modularity, Project Jigsaw and OSGiOne of the requirements for the JavaSE 8 module system is to <a href="http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12#osgi-support">provide support for and be able to integrate with OSGi</a>. I am therefore very happy to see that a new OpenJDK project is being proposed to focus on precisely this: Project Penrose. Tim Ellison posted the proposal here: <a href="http://mail.openjdk.java.net/pipermail/discuss/2012-January/002320.html">http://mail.openjdk.java.net/pipermail/discuss/2012-January/002320.html</a><br />
<br />
They're still looking for initial supporters, authors and committers, so if you're interested in helping out just sign up!<br />
<br />
BTW I posted before on this topic, see here: <a href="http://osgithoughts.blogspot.com/2011/05/java-se-8-modularity-requirements.html">http://osgithoughts.blogspot.com/2011/05/java-se-8-modularity-requirements.html</a>David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com2tag:blogger.com,1999:blog-4030657773074828717.post-59771012295421741822011-11-10T10:37:00.000+00:002011-11-10T10:37:55.569+00:00New OSGi Alliance membership stuctureThe OSGi Alliance is where all the OSGi specs are developed as a collaboration effort of a number of companies (and sometimes invited researchers). To be able to contribute to specs you need to be a member. There are a number of reasons for this but probably the most important one is proper handling of IP flow.<br />
<br />
In the past a number of people have told me that they would be interested in taking part in the specification work at OSGi but they simply could not afford the membership. Well for those people there is good news today. The OSGi Alliance has moved to a new membership structure where much cheaper options to become a member are available. Also the size of a company is taken into account at certain levels where smaller companies (under 250 employees) pay less.<br />
<br />
There is also an entirely new type of 'low-fee' membership: Contributing Associate (which replaces the old Adopter Associate). Being an Contributing Associate is much more useful than Adopter Associate was as Contributing Associates can send up to 2 delegates to Expert Group meetings (such as the <a href="http://www.osgi.org/EEG">Enterprise Expert Group</a>) where they can fully participate in the development of RFPs and RFCs, which ultimately can become OSGi specifications.<br />
Any existing Adopter Associates are automatically moved to Contributing Associate, so they can start contributing right now! (well, you need to sign some docs, but that's all).<br />
<br />
Ideally you want stuff like this to be free, but as any Standards Development Organization, the OSGi Alliance (which is a non-profit organization) has operating costs and the membership fees are used for that. As a representative on the Board of Directors I will always make sure that any money in the organization is used appropriately.<br />
<br />
I'm personally very happy to see the OSGi restructuring finally taking place. I expect that it will open the door to more participation, especially from the large number of smaller companies who are successfully using OSGi in the field. The OSGi technology is great, but great things can always be improved. Doing this in the OSGi Alliance means that those improvements will be embodied in specifications and specifications ultimately lead to choice as multiple implementations can co-exist so that users will be free from vendor lock-in. <br />
<br />
For all the details of the new membership structure see here: <a href="http://www.osgi.org/About/Join">http://www.osgi.org/About/Join</a> and here: <a href="http://www.osgi.org/About/Benefits#compare">http://www.osgi.org/About/Benefits#compare</a><br />
Alternatively, feel free to contact me at <a href="mailto:david.bosschaert@gmail.com">david.bosschaert@gmail.com</a> if you have questions, I may not be able to answer all of them but I can always point you at the person who does.<br />
<br />
For a list of current OSGi specifications and their implementations see here: <a href="http://en.wikipedia.org/wiki/OSGi_Specification_Implementations">en.wikipedia.org/wiki/OSGi_Specification_Implementations</a>David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com0tag:blogger.com,1999:blog-4030657773074828717.post-43301046002354749582011-10-11T20:11:00.000+01:002011-10-11T20:11:56.107+01:00OSGi Enterprise Specification Early Access DraftA new Early Access Draft containing RFCs aimed at the upcoming OSGi Enterprise Specifications has been made public. The following RFCs are expected to be part of the OSGi Enterprise Release next year: <br />
<ul><li>RFC 112 OBR</li>
<li>RFC 152 Subsystems</li>
<li>RFC 167 java.util.ServiceLoader support</li>
<li>RFC 169 JMX updates</li>
</ul>In addition, the EA draft contains a number of RFCs related to the Core and Compendium specifications.<br />
You can find this draft on the OSGi website here: <a href="http://www.osgi.org/download/osgi-early-draft-2011-09.pdf">http://www.osgi.org/download/osgi-early-draft-2011-09.pdf</a>David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com1tag:blogger.com,1999:blog-4030657773074828717.post-88819845020314651662011-07-12T21:44:00.001+01:002011-07-13T08:56:45.099+01:00JBoss Application Server 7 is out - with OSGi support!JBoss AS7 has been released today - an amazingly fast and lightweight Application Server with built-in OSGi support. Just deploy your OSGi bundles and go!<br />
<br />
For more information see the main AS7 page: <a href="http://www.jboss.org/as7.html">http://www.jboss.org/as7.html</a><br />
Or have a look at the <a href="https://docs.jboss.org/author/display/AS7/Getting+Started+Developing+Applications+Guide">quickstarts page</a>!<br />
<br />
The OSGi support in AS7 implements the OSGi 4.2 core specification. Thomas Diesler has contributed most of the code, and I have implemented some bits and pieces in there too... Lets us know what you think or if you find an issue. The forums are here: <a href="http://community.jboss.org/en/jbossosgi">http://community.jboss.org/en/jbossosgi</a> and more details on the project can be found here: <a href="http://www.jboss.org/jbossas/osgi">http://www.jboss.org/jbossas/osgi</a>David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com0tag:blogger.com,1999:blog-4030657773074828717.post-79666671020625147142011-06-28T08:54:00.002+01:002011-06-28T09:09:08.450+01:00The need for ModularityThe title of this blog is not new - it has been used by many other blogs and articles in the past, but Rod Johnson seems to think that Modularity not really needed any more so I decided to reuse the title and take a look at why we really need Modularity.<br />
<br />
In this age of Cloud Computing where hardware utilization and energy consumption are being highly optimized you will find that more and more service providers are moving towards a multi-tenancy model where multiple deployments are co-located on a single platform. Whether these deployments are from different providers or from the same provider is the choice of the deployer, but the end-result is a situation where multiple deployments share a single platform. In such cases modularity is an absolute must as without it there is a reasonably big chance that the system won't work. This is because deployables might depend on incompatible versions of the same library, which means that in order to work, they need to be isolated from each other. Or, a deployable might depend on a library that also happens to be used by the platform provider, this is an even harder case which requires the platform itself to be developed in a modular fashion so that it's details don't bleed into the user-space.<br />
Scenarios like this require modularity and in the case of Java this modularity is provided through OSGi and/or many application servers. Additionally, modularity can also be found in many non-appserver systems that allow plugins to be installed.<br />
<br />
Further benefits of modularity relate to memory footprint and performance. A modular system can make intelligent decisions about its memory usage, where only modules that the end user actually needs are loaded. This makes it possible for a fully featured server to have a tiny runtime footprint if only a small portion of it is actually used. And all of these benefits have performance benefits too: you'll save a lot of time if you're only loading the modules you actually need rather than pre-loading the entire system as a single entity.<br />
<br />
But even if you don't need modularity for side-by-side versioning, isolation or performance just yet, there are additional benefits associated with using a modular approach in your development. I think that even for small projects it's not a bad idea to start out by using Modularity. It's true - getting a modular project off the ground takes a larger initial effort compared to the 'traditional' approach. But that cost is quickly earned back once the project grows a little bigger. Once your project is structured to support modularity, it becomes much more maintainable, easier to understand and to extend while 'traditional' approaches tend to become much harder to maintain as they grow in size.<br />
See the following diagram, adapted from a blog by Hal Hildebrand:<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1DcChBhfiklBEvyrH9J3t46hbiW632Dg8oLekq279Pea9f48stxEQbYEj122oA3eSbv7yDkzZQxMpC5G5LcNkUxa7hl8m1I6o99YmZzaye21qyv0tS4iWrS94S1BvZciJYmGVf14QxOw8/s1600/chart.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="175" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1DcChBhfiklBEvyrH9J3t46hbiW632Dg8oLekq279Pea9f48stxEQbYEj122oA3eSbv7yDkzZQxMpC5G5LcNkUxa7hl8m1I6o99YmZzaye21qyv0tS4iWrS94S1BvZciJYmGVf14QxOw8/s400/chart.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Cost of Software Maintenance</td></tr>
</tbody></table>The investment in a Modular Architecture earns itself back quicker than you think.<br />
<br />
Using a modular approach together with a service oriented architecture*) gives your system highly cohesive entities with a clear responsibility. This makes it easier to identify what parts are affected when a system needs to be enhanced or changed. Changes for a particular feature are often more localized to a specific set of modules, which enables better parallelization of development and will ultimately make your developers more productive.<br />
<br />
So Modularity is highly desirable for a number of reasons and the best place to get modularity today is by taking an OSGi Framework, as OSGi has been providing Modularity as well as an excellent Services Framework to Java for over 12 years and is standardized in the <a href="http://www.osgi.org/Specifications/HomePage">OSGi specifications</a>.<br />
<br />
Part of the choice for a particular development architecture is always the consideration regarding tooling support. With OSGi the following tools are popular:<br />
<ul><li><a href="http://www.eclipse.org/downloads/packages/eclipse-classic-37/indigor">The Eclipse PDE</a> with <a href="http://www.eclipse.org/tycho/">Maven Tycho</a></li>
<li><a href="http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html">Maven Bundle Plugin</a></li>
<li><a href="http://www.aqute.biz/Bnd/Bnd">Bnd</a> and <a href="http://bndtools.org/">Bndtools</a></li>
</ul>Additionally, <a href="http://netbeans.org/">Netbeans</a> and <a href="http://www.jetbrains.com/idea/">IntelliJ</a> have OSGi Support. While tools can always be improved the above toolsets are quite usable. Especially the Maven Bundle Plugin is <i>very</i> popular in the Open-Source world and many, many examples can be found that show its use.<br />
<br />
To conclude, Rod Johnson says that especially on the server side, using a non-modular system is better for customers. This seems like a highly incorrect statement to me. Modularity is needed <i>especially</i> on the server side, as without it your deployments become fragile, especially if you have more than one deployment on that server...<br />
<br />
*) Note that by saying 'service oriented architecture' I'm not implying a <i>distributed</i> SOA. Using services within a single process is highly valuable and works great in combination with modularity to avoid tight coupling. Yes, services open the door to distributing parts of your application, but that's really a different topic...David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com4tag:blogger.com,1999:blog-4030657773074828717.post-64587386807810694522011-06-07T19:59:00.000+01:002011-06-07T19:59:26.414+01:00OSGi Enterprise Specification Early Access Draft available!An early access draft for the upcoming OSGi Enterprise Specifications has just been made available. This is really interesting stuff and it shows what we've been working on in the Enterprise Expert Group over the last year or so. Although still work in progress, some of these specifications will be included in the next OSGi Enterprise Release which is currently planned to be released during the first half of 2012.<br />
<br />
The main theme for the Enterprise Release is around Subsystem/Application support and OBR (the OSGi Bundle Repository). These are covered in RFC's 152 and 112. Together they greatly improve the way you can define and distribute, assemble and install OSGi applications and I'm really looking forward to the moment that these specs are finished and broadly implemented.<br />
<br />
Additionally you can find in the draft: RFC 146 JCA support, two new Blueprint specifications and an update to the JMX specification (chapter 124 in the Enterprise Release 4.2).<br />
<br />
Finally there is RFC 167. This is a new RFC that I've been working on. It intends to fix a small but quite annoying issue: the fact that java.util.ServiceLoader() and META-INF/services use generally don't work in OSGi. You can work around it, <a href="http://coderthoughts.blogspot.com/2008/03/using-jersey-jsr311-inside-osgi-with.html">as I've blogged about in 2008</a>, but it's ugly. Using RFC 167 this issue can be addressed so that any non-OSGi code that uses this pattern can work in OSGi without too much hassle. I've been working on <a href="http://aries.apache.org/modules/spi-fly.html">an implementation of this in Apache Aries</a>, if you're interested in trying it out.<br />
<br />
Note that the specifications are not yet final so significant changes might still occur. Also, feedback is welcomed! You can leave comments here on my blog or write an email to <a href="http://mail.osgi.org/mailman/listinfo/osgi-dev">the osgi-dev mailing list</a>.<br />
<br />
You can find the EA draft here: <a href="http://www.osgi.org/download/osgi-early-draft-2011-05.pdf">http://www.osgi.org/download/osgi-early-draft-2011-05.pdf</a>David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com1tag:blogger.com,1999:blog-4030657773074828717.post-69314489339356235512011-05-25T22:14:00.000+01:002011-05-25T22:14:47.653+01:00Java SE 8 Modularity RequirementsMark Reinhold posted the requirements for the Module System in JavaSE 8 here today: <a href="http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12">http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12</a> . And, I won't deny it, I was part of the group that worked on getting these requirements formulated, although I don't fully agree with all of them, but more on that below.<br />
<br />
There are many, many good requirements in this document and Java will certainly gain from having these realized - if this is done in an open and inclusive manner.<br />
<br />
So what does this mean for OSGi? OSGi is a widely used, mature, modularity standard today, existing for 10+ years.<br />
Well, the good news is that the new requirements are not incompatible with OSGi. There is actually <a href="http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12#osgi-support">a specific requirement around the necessity for OSGi to be able to interact with the JavaSE modules</a>.<br />
<br />
Many of the requirements mentioned in the document are already supported by OSGi today. The file format that defines the modules will most likely not be the MANIFEST.MF file that is used by OSGi today, but another file of some sort. OSGi will support this new mechanism to declare the module as well in the future; the semantics are the same, the format will be slightly different.<br />
<br />
Another good thing is that once modularization is part of Java SE 8, moving to OSGi will be easier than it is today. The biggest stumbling block for migrating an existing system to OSGi today is often the modularization of a system that wasn't created in a modular way in the first place. It's not an issue with OSGi per se, but with modularity as a concept. If you have existing code that is non-modular, it can be difficult to modularize it. With JavaSE 8 this problem will appear earlier in the development cycle which should help people design their systems in a modular way from early on. If you need more than the basic JVM module system then you can move to OSGi taking your existing JavaSE 8 modules and they will just work as-is - so migration will be a breeze. Then you can enhance the modules to take advantage of the OSGi benefits (see below).<br />
<br />
Why not take OSGi as-is?<br />
Well, this would be nice. And it should be quite possible to take a (possibly reduced) OSGi framework and make that the module system for Java SE 8. But to a certain degree it's an implementation detail. The important thing is that the Java SE 8 Module System is a well-defined standard. Whether JRE implementations take OSGi as the basis for their module system or write their own from scratch is up to them.<br />
<br />
Does OSGi still add value? Absolutely! Here are some points:<br />
<br />
<ul><li><b>dynamicity and lifecycle</b>: OSGi modules are dynamic; you can add, remove and update modules from a running framework. It allows patching applications without taking them down! (I have demo'ed this many times) This will probably not be possible in the JavaSE 8 modules.</li>
<li><b>advanced service registry</b>: the OSGi Service Registry is much richer than the Java SE java.util.ServiceLoader class. It allows filtering for services on additional metadata (beyond the interface name), supports multiple instantiation modes and, again, is dynamic: services can come and go.</li>
<li><b>richer dependency metadata</b>: OSGi has an extremely rich metadata model that supports specifying dependencies in many ways. It does support module-level dependencies (as is proposed in the Mark's requirements doc) through the Require-Bundle header. However, most people who have been working with OSGi for the last 10+ years have realized that pure module-level dependencies are inferior to declarative dependencies such as the ones provided by OSGi's Export-Package and Import-Package. Since OSGi 4.3 <i>generic</i> capabilities and requirements are also supported, which allows you to create your own dependency system.</li>
<li><b>many other OSGi specifications</b>: there are many OSGi specifications that describe useful things which can be used on top of any OSGi framework. See the <a href="http://www.osgi.org/Download/Release4V42">compendium and enterprise specifications</a> for the details.</li>
</ul><br />
<br />
Where are the disagreements?<br />
They're actually spelled out in the requirements document.<br />
<br />
<ol><li><a href="http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12#source-form-metadata-in-modular-jar-files">The form of the module definition</a>. Having module metadata in a file different from MANIFEST.MF is fine, in my opinion. MANIFEST.MF is a near text-file format with some strange limitations. A proper DSL would be nice for module definitions. I don't see the value, however in compiling that information into some binary format. It has been invaluable to me many times in the past to be able to open an OSGi bundle, look at the manifest and see exactly from that information what the module definition is. Compiling the information into a binary format will make it harder to see the module definition and it might also make life harder for tools that work with the module system.</li>
<li><a href="http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12#non-java-source-file-names">The file extension of the module definition</a>. Some argued that the module source definition should be in a .java file and because it's in a .java file there should be a compiled .class file in the resulting Jar file. However, I think that the structure of a module definition <i>screams</i> for a specific DSL that might be quite different from ordinary Java. Especially the <a href="http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12#extensible-module-declarations">extensibility requirement</a> makes a DSL much more natural than a traditional .java source file. I think the module definition should be in META-INF/module.jmod or something like that. Then it becomes natural to migrate that file as-is to the resulting jar. In a sense the existing MANIFEST.MF does cover most of the requirements. Sure, it has some issues (esp. the 76 chars-per-line limit) but it's clear, simple and extensible - and - it is readable by humans in the Jar file.</li>
</ol><br />
Conclusion<br />
I congratulate Mark Reinhold and all others involved in this for providing the basic requirements and design proposal that will make OSGi work nicely with the JavaSE 8 module system. OSGi will extend the basic JavaSE 8 modules and both systems will work with each other to form a layered design.David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com2tag:blogger.com,1999:blog-4030657773074828717.post-13110807529428241182011-05-18T08:32:00.000+01:002011-05-18T08:32:12.983+01:00Nice magazine about OSGiThe people behind the Jax conferences have created a PDF magazine with a focus on OSGi. There's some good articles in there, so definitely worth a read!<br />
<br />
Table of Contents:<br />
<ul><li><b>Introduction to OSGi</b> by Jerome Moliere</li>
<li><b>What's new in Core 4.3</b> by BJ Hargrave and Peter Kriens</li>
<li><b>Developing with BndTools</b> by Marcel Offermans and Alexander Broekhuis</li>
<li><b>OSGi a la Carte</b> by Valentin Mahrwald and Holly Cummins</li>
<li><b>OSGi and JPA</b> by Dmytro Pishchukhin</li>
<li><b>Cure for Complexity</b> (Business focus) by Richard Nicholson</li>
<li><b>Enterprise OSGi</b> by Tim Diekmann and myself</li>
</ul>Lots of topics, from Core to Enterprise to Business and also information about popular OSGi projects and developing for OSGi! The download process is a little involved, but it took me only a few seconds to get it. You can get the PDF here: <a href="http://jaxenter.com/java-tech-journal/JTJ-2011-04">http://jaxenter.com/java-tech-journal/JTJ-2011-04</a>David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com0tag:blogger.com,1999:blog-4030657773074828717.post-9471998495336792372011-04-29T08:33:00.000+01:002011-04-29T08:33:59.843+01:00Enterprise OSGi in JBoss AS7As many of you know, I have been working on OSGi support in the JBoss Application Server for the past year now. My colleagues at JBoss/Red Hat and I have built an OSGi Framework from the ground up with as focus the best possible integration with the Application Server.<br />
<br />
AS7 has been OSGi-enabled since its Alpha1 release and over the past few weeks Beta's have been pushed out on a bi-weekly basis. It's starting to look really good!<br />
<br />
Next week at Red Hat Summit/JBoss World in Boston I'll be presenting and demoing the current state of things w.r.t. to Core OSGi, Enterprise OSGi and OSGi/AS integration in AS7. My session is on Friday at 11am: <a href="http://www.redhat.com/summit/sessions/jboss.html#38">http://www.redhat.com/summit/sessions/jboss.html#38</a> - hope to see you there!David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com2tag:blogger.com,1999:blog-4030657773074828717.post-43081139340115391572011-03-25T03:02:00.001+00:002011-04-21T16:00:11.878+01:00OSGi 4.3 core proposed final draft now availableThe OSGi 4.3 core specification proposed final draft if now publicly available!<br />
<br />
New and noteworthy:<br />
<ul><li>Generified Framework API </li>
<li>Generic Requirements and Capabilities</li>
<li>New BundleWiring API</li>
<li>New Bundle and Resolver Hooks</li>
<li>New Weaving Hoooks</li>
</ul><br />
Get it here: <a href="http://www.osgi.org/Download/File?url=/download/osgi.core-4.3.0-pfd.pdf">http://www.osgi.org/Download/File?url=/download/osgi.core-4.3.0-pfd.pdf</a><br />
<br />
Update - the final 4.3 Core spec is now public: <a href="http://www.osgi.org/Download/Release4V43">http://www.osgi.org/Download/Release4V43</a>David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com0tag:blogger.com,1999:blog-4030657773074828717.post-7076734507884994462011-02-15T14:40:00.000+00:002011-02-15T14:40:53.320+00:00OSGi Cloud Computing RFP 133I'm quite excited by the work that is being done in the OSGi Cloud Working Group recently. In this working group we are looking at what role OSGi standards can play in a Cloud Computing environment. Currently we're focusing on the possible requirements in <a href="https://www.osgi.org/bugzilla/show_bug.cgi?id=114">RFP 133</a>. Both OSGi Alliance members as well as non-members are involved in defining this document.<br />
<br />
If you're interested, have a look at the RFP. It's available as an attachment to this bug in the public OSGi Bugzilla system: <a href="https://www.osgi.org/bugzilla/show_bug.cgi?id=114">https://www.osgi.org/bugzilla/show_bug.cgi?id=114</a>. Feel free to comment!<br />
<br />
If you're interested in becoming more involved, join the OSGi Cloud Working Group mailing list: <a href="https://mail.osgi.org/mailman/listinfo/cloud-workshop">https://mail.osgi.org/mailman/listinfo/cloud-workshop</a>.David Bosschaerthttp://www.blogger.com/profile/13786738766478890804noreply@blogger.com5